Consuming the Message using the Queue
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.
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 (cloud.sap)
For node-based implementation: capire - Messaging (cloud.sap)
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.
Implementation:
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.
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
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
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 - jwt.io or any other JWT token decoder of our choice.
Note: any “/” in the topic name or Queue Name must be changed with %2F.
Now let's confirm if this is the right message by reading the queue “QueueForBlog”.
Let’s check the Event Mesh queue to make sure this event is consumed and removed from the queue.
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.
Conclusion:
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 ...
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 (cloud.sap)
For node-based implementation: capire - Messaging (cloud.sap)
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)
Implementation:
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.
- 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. - 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": [
"${namespace}/*"
],
"subscribeFilter": [
"${namespace}/*"
]
},
"topicRules": {
"publishFilter": [
"${namespace}/*"
],
"subscribeFilter": [
"${namespace}/*"
]
}
}
}
Service Descriptor for the Event Mesh Instance in the Provider Account
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 - jwt.io 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”.
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.
Conclusion:
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 ...
- SAP Managed Tags:
1 Comment
