Reading time: 6 minutes
In the first article of this blog series Expose your data in a fast and reliable way in real time with SAP BTP you could learn about the solution that helps your organization to be in sync. Now you will be presented with more details about the SAP Event Mesh implementation used in this scenario.
In current IT world that we all live, learn, buy and work in it’s essential to make things easier and optimized. Many parties, systems and services are integrated and talk to each other therefore making all beforementioned things more simple and effortless for the users, customers, organizations and people who work there. A lot of things happen behind the scenes by the integration with the APIs (Application Programming Interfaces). To give one example, now it needs just a few clicks for the customer to order a product from the seller and then for the seller to arrange the shipment without any human contact. When we look into this more closely we will see many different services connected to each other. There is a shop, a vendor, a shipping company etc. involved, each with its own IT environment.
There are many different ways and protocols to integrate two separate systems with each other and discussing them is out of scope of this article. I’d like to focus more on the direction of the communication and its origin instead of the technicalities. One can distinguish two scenarios: request- and event-based.
In the request-based communication, service A queries service B by sending a request related to a specific resource. Service A originates the communication. This scenario works well when you expect that data in the resource you’re querying is changing dynamically and constantly rather than due some event and you need to keep it up to date.
Figure 1.1: Request-based communication
However, when the data is changed rather seldomly due to some event happening in the background, it’s not optimal to query service B multiple times repeatedly. In this case it’s better to use event-based communication. In event-based scenario service A will be notified by service B when the event occurs.
Figure 1.2: Event-based communication
This is where SAP Event Mesh comes into picture. SAP Event Mesh (previously called SAP Enterprise Messaging) enables to implement event-based communication in the integration scenarios. It’s a cloud based service available through SAP Business Technology Platform. You can learn more technical details about SAP Event Mesh from a great series of blogs from Andrzej.
To have a better understanding of SAP Event Mesh possibilities let’s have a look at example given in the first blog of this series. SAP Event Mesh plays an important role in this scenario – every time a sales order is created in the S4 system (in other words when specified event occurs) it distributes the message to the integration platform. In the next step integration platform queries the S4 system to get the details about the ordered product – request-based communication is used. Also, after sales order with product details is saved in HANA Cloud database new event is emitted and SAP Event Mesh again notifies integration platform. Otherwise there would be a need to query HANA Cloud database about the product in question to eventually sent a notification to Slack that new sales order was created. That would require many request-response messages to be sent over.
What’s important to note is that event-based communication ensures scalability of solutions designed in this way. It’s extremely easy to add additional applications to the integration scenario when needed. It’s also worth mentioning that event-based communication is asynchronous. It means that the message isn’t lost when the receiving system is unavailable. It’s stored by the sender until receiver becomes available. That assures successful delivery of the messages.
Now, I think you know why and when it’s useful to implement SAP Event Mesh in your integration scenarios.
1. About COALESCE, Left outer join, NULL and the link between them
2. Discover approval level in MM Flexible Workflow agent determination BAdI