1

[Blog Post] SAP Event Mesh – Single Tenancy & Multi-Tenancy Explained

 1 year ago
source link: https://blogs.sap.com/2022/05/15/blog-post-sap-event-mesh-single-tenancy-multi-tenancy-explained/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
May 15, 2022 5 minute read

[Blog Post] SAP Event Mesh – Single Tenancy & Multi-Tenancy Explained

Authors: Ayush Kumar & 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 Region) | SAP Blogs

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%20in%20SAP%20Event%20Mesh

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.

  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": [
                "${namespace}/*"
            ],
            "subscribeFilter": [
                "${namespace}/*"
            ]
        },
        "topicRules": {
            "publishFilter": [
                "${namespace}/*"
            ],
            "subscribeFilter": [
                "${namespace}/*"
            ]
        }
    }
}

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-Client.png

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

UIDashboard.png

Queue Dashboard

Create%20Queue

Create Queue

MicrosoftTeams-image-3-1.png

Queue Created

createtopic.png

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%202.0%20Configuration

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.png

Send Payload to Event Mesh using Topic we created above

MicrosoftTeams-image-5-1.png

Check Queue Status after Message is Sent

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

Consume.png
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.

consumed.png

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.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK