Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 
Authors: ak47_ & vipul.khullar

This is the second blog post in the SAP Event Mesh – Deep Dive series.

Previous blog post in this series

[Blog Post] SAP Event Mesh Event-Driven Architecture Explained 

This blog post demonstrates a rest-based implementation for SAP Event Mesh service in Single-tenant and Multi-tenant environments. But, before we begin with the example, you might want to get some basic understanding of the SAP Event Mesh common terminologies. Please refer to the Blog BTP Event Mesh Advanced Concepts | SAP Blogs for the same.

What is Single tenancy?

The end users are called tenants as they don’t own the entire service permanently, but they use it. In a single-tenant environment each tenant has its own copy of the software, and services which are not shared by other tenants, hence no concept of sharing of resources is applicable.
Hence implementing Event Mesh is straightforward in a single-tenant environment.
You can refer to the blog below for a rest-based implementation

Your First End-to-End Tutorial of Event Mesh on SAP Business Technology Platform (China, Shanghai Re...

Also, you can refer to the CAP documentation for the same
for java-based implementation: capire - Messaging (

For node-based implementation: capire - Messaging (

What is Multi-Tenancy?

In a multi-tenant environment, the software and services are shared between multiple tenants such that no tenant is the sole owner of the service/software. This allows us to share our resources instead of having a dedicated resource per user running even if a user is not making full use of that.

The main challenge in implementing SAP Event Mesh in a multi-tenant environment is that you don’t have control over the Event mesh setup of the subscriber.
The only thing under your control is your provider instance for the Event Mesh thus how do you isolate your events from other tenants and how do you make the consuming tenant read the incoming event.

Multi-Tenancy in SAP Event Mesh(Image taken from Event Mesh Help Document)


This is relevant only when you are creating a SaaS-based application on BTP.

In Multi-Tenancy, the Event Mesh service instance type should be “type: reuse”. This allows the instance to be consumed by multiple tenants.

  1. Now when raising an event, we need to send this event to the same tenant which has tried to generate this event. Thus, we need to authorize our Event Mesh instance against the tenant server not with the provider.
    Thus doing so we can maintain tenant isolation.

  2. Now to consume the events which are raised, the subscriber tenant needs to allow the namespaces which are provided by the provider to be able to read them (will be useful when you try to listen to it using any service, for example, Cloud Integration flows which is under the purview of subscriber tenant, not the provider tenant).

"emname": "<message-client-name>", // fill in your message client name
"namespace": "<your-namespace>", // fill in your namespace
"version": "1.1.0",
"instancetype": "reuse", // this line is the key difference
"options": {
"management": true,
"messagingrest": true,
"messaging": true
"rules": {
"queueRules": {
"publishFilter": [
"subscribeFilter": [
"topicRules": {
"publishFilter": [
"subscribeFilter": [

Service Descriptor for the Event Mesh Instance in the Provider Account


Once you have subscribed to a multi-tenant(SaaS-based) application (in the subscriber tenant) you will see a bunch of tiles (not necessarily the same as that of the Image represented Below). The one with the type of subscription is the one that gets created when you subscribe to the multi-tenant application.


Message Clients


Open the tile (with the type subscription ) and create a queue, you can use any queue name and it will automatically append the namespace of the subscriber to it for you.

For this example we will use the following names:

QueueName : QueueForBlog

TopicName: TopicForBlog


Queue Dashboard


Create Queue


Queue Created


Subscribe to a Topic


Now we have configured our queues and topics so, let’s see an example using postman to send the messages to the subscription queue and read it from the subscription queue


OAuth 2.0 Configuration


Notice that we are using the Subscriber Tenant Token URL.

Note: To extract this token URL in our code, you can use a parameter called “iss” in the JWT token. You can try for yourself using this link JSON Web Tokens - or any other JWT token decoder of our choice.

Note: any “/” in the topic name or Queue Name must be changed with %2F.

Send Payload to Event Mesh using Topic we created above


Check Queue Status after Message is Sent


Now let's confirm if this is the right message by reading the queue “QueueForBlog”.


Consuming the Message using the Queue


Let’s check the Event Mesh queue to make sure this event is consumed and removed from the queue.

Queue Status after Message Consumption


The above examples just present a rest-based implementation to understand SAP Event Mesh in simple terms. However, we can avoid all this hassle using the CAP framework as it takes care of all the things for us.


In this blog post, we saw a rest-based implementation of the SAP Event Mesh service in SAP BTP and how it caters to single-tenancy and multi-tenancy scenarios.
Refer to the Rest API section of the SAP Event Mesh service if you want to explore more rest-based possibilities.

In the next few blog posts, we will see CAP JAVA-based implementation of SAP Event Mesh service, and how we can connect SAP Event Mesh service to SAP Integration Suite in both single-tenant and multi-tenant environments.

Please do like the blog post, if you find the content helpful. Also, do share your comments and inputs, if any.

Next blog post in the series: [Blog Post] SAP Event Mesh – CAP based implementation of SAP Event Mesh in a Single-Tenant Scenario ...



1 Comment