SAP Event Mesh for the SMBs

Following the series of blog posts related to the event-driven architecture for SAP Business ByDesign, it’s time to discuss the message-driven approach, and why it matters when it comes to systems integration and SMBs.

Message Broker

Suppose you have a scenario where there’s a core ERP and several other solutions, satellite systems, in-house developed applications and even few legacy ones that, for some reason, still need to exchange data in different levels and requirements. Somehow every single system in that landscape needs to talk to each other.

At first you might think on building 1:1 systems’ specific integration. It means that, if in total there are, let’s say 6 solutions to integrate, in the worst case scenario you will need to build 15 tailor-maid, very specific interfaces, meaning every system will have to know exactly where the others are sitting and how precisely communicate to them – resulting in high development and maintenance costs, raising a very complex environment to support. It becomes even more complex as new systems are added to the landscape.

Another architecture strategy, instead, is to decouple the communication between those applications, services and systems, and let them talk to a central message broker, so they only need to learn how to integrate to this main service:

Besides the fact that it reduces costs and streamlines maintenance, it allows a fluid data exchange, improves performance by enabling asynchronous communication and leverages scalability to the overall landscape.

In other words and straight to what really matters in this blog series context: it allows partner’s solutions to subscribe for events on SAP Business ByDesign, so they can act on latest changes on their customers’ business asynchronously on their own pace.

The SAP Event Mesh

The SAP Event Mesh is the message broker service we are going to leverage for our samples. It is a fully-managed service that runs in the Cloud Foundry environment of the SAP Business Technology Platform, and allows us to handle messages properly as needed.

We are able to create topics, queues and webhooks so the core ERP, as an example, can produce messages and applications subscribe to business-relevant updates and react as required, on their own pace. Queues can subscribe to topics; and webhooks subscribe to queues.

The simple architecture diagram below summarizes the main elements of a typical deployment and how they connect to each other:

You may also want to have it even simpler and configure only queues, so producers and consumers post and get messages directly to/from them, without having to manage topics or webhooks.

The service supports the following standard messaging protocols:

• HTTP Rest
• AMQP – Advanced Messaging Queueing Protocol;
• MQTT – Message Queueing Telemetry Transport;

EM Cockpit

Business and platform users can configure the service through the EM Cockpit in a browser, although it’s also available via cf cli commands.

Here’s how the EM Cockpit looks like as of today:

Security

Each service instance relates to an OAuth client that is created automatically by the platform, and those credentials are part of the service key that you manually creates for your instance. Before interacting with the service either producing or consuming messages, you must obtain an OAuth token.

Here’s a cURL sample on how to get the token, produce a message on an specific queue and consume it:

1. First we need to generate a token based on the Service Key credentials:

   curl --location --request POST 'https://<subaccount>.authentication.eu10.hana.ondemand.com/oauth/token?grant_type=client_credentials&response_type=token' \
   --header 'Content-Type: application/x-www-form-urlencoded' \
   --header 'Authorization: Basic <base64 of client secret and client ID>'​

2. Then you may post your message:

   curl --location --request POST 'https://enterprise-messaging-pubsub.cfapps.eu10.hana.ondemand.com/messagingrest/v1/queues/<Queue_Name>/messages' \
   --header 'x-qos: 0' \
   --header 'authorization: Bearer <replace_with_the_token>
   --header 'Content-Type: application/json' \
   --data-raw '<replace_with_your_message>'​

3. And here’s how you consume a message from the queue:

   curl --location --request POST 'https://enterprise-messaging-pubsub.cfapps.eu10.hana.ondemand.com/messagingrest/v1/queues/<Queue_Name>/messages/consumption' \
   --header 'x-qos: 0' \
   --header 'Authorization: Bearer <replace_with_the_token>
   --data-raw ''​

Prepare yourself for the next chapter

Go ahead and complete now the following tutorials so you can activate the SAP Event Mesh in your SAP Business Technology Platform account, create a queue and test a message being produced and consumed:

• Tutorial 1: Messaging Concepts
• Tutorial 2: Creating EM Instance
• Tutorial 3: Managing Queues
• Tutorial 4: Test Queues (send/receive)

You will also need to know about the webhooks subscriptions, so you can trigger you application or service whenever there’s a new message produced on an specific queue.
Here is the guide: Manage Webhook Subscriptions

⚠️Important: in the next blog post I will explain and publish the code of a Partner Application prototype that consumes messages generated by SAP Business ByDesign Customer Invoices in a queue, generates Electronic Invoices issued by Tax Authority and updates the customer invoice with the authorization ID.

Finish the tutorials above and complete the webhook guide so you can successfully deploy the upcoming prototype. 🤓

EDIT: If you got your SAP Event Mesh environment set up, then you are ready to deploy the Electronic Invoice sample. Try it out!

EDIT 2: SAP Cloud Platform replaced by Business Technology Platform, and SAP Enterprise Messaging by SAP Event Mesh. See more here.

Stay tuned!