Skip to Content
Technical Articles
Author's profile photo Vipul Khullar

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

Authors: Vipul Khullar & Ayush Kumar

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

Before we deep dive into the technical implementation details of the SAP Event Mesh service, it is paramount to understand the general overview of the event-driven architecture and how SAP Event Mesh in BTP enables the same.

What is Event-Driven Architecture and why should we care about it?

Let’s take an example from day-to-day life. You take your car out for a ride and you encounter a signal which is red, what do you do, you apply the brakes and stop the car.
Again when the signal turns green, you put your leg on the accelerator and start moving.

In this example, your actions are dictated based on the signal. Red light is an event signal to stop the car and is similar to a green light to move.

This is the very basic foundation/essence of the event-driven architecture, that is you don’t react until and unless an event occurs.

In the current world and the industry requirement, a consumer does not prefer to work with a strongly coupled solution. Event-driven architecture provides us the advantage to decouple our solution and communicate with any system only through events. This means that the systems are no longer required to know each other.

Raising the event is not the same as calling an API because, in an API call, we need to decide the end systems, but the events are just raised and now the broker can take care of routing it.

The advantage of such events is that once it is raised it can be consumed by any consumer who wishes to, without requesting it explicitly in real-time.

 

Event%20Driven%20Architecture

Event-Driven Architecture

 

Generic use cases for Event-Driven Architecture are as follows:

  1. Communication between different microservices – Information can be efficiently shared between independent micro-services without the need for tight coupling.
  2. Data replication between different systems – Save events (create, change and delete) can be consumed by different services/systems at once.
  3. Parallel processing – A single event can trigger multiple processes which execute asynchronously.
  4. Resilience via redundancy – If the consumer service is not available, the data persists with the broker until the service is live again.

 

How does SAP Event Mesh fit in? 

Sap Event Mesh is a fully managed service by SAP that allows you to communicate between different systems, applications, or services using event/messages allowing us to decouple our solutions at different levels/services.
It acts as a central message broker/messaging service which captures the messages when and where the event is raised. Now it’s up to the end consumer on how it is going to consume those events. It can be done via SAP Cloud Integration, some Webhooks, CAP-based applications, etc.

Since SAP Event Mesh is responsible for the delivery of the messages, the sender need not worry about the endpoints. Hence, they can perform their functions without worrying about the end systems.

Use SAP Event Mesh to:

  • Support event-driven architectures and microservices.
  • Publish business events from SAP and non-SAP sources across hybrid landscapes from the digital core to extension applications
  • Build event-driven extensions and integrations and subscribe to events from core SAP systems to enable cloud-native extensions and integrations to respond to the latest business developments in real-time
  • Part of the SAP Integration Suite and SAP Extension Suite to implement extension and integration scenarios in guided and at the same time flexible approaches

SAP%20Event%20Mesh%20Use-Case%20Architecture

SAP Event Mesh Use-Case Architecture

 

In this blog post, we tried to explain event-driven architecture, its use cases, and how the SAP Event Mesh service in BTP facilitates event-driven architecture.

In the next few blog posts in the series, we will talk in detail about the SAP Event Mesh service in SAP BTP and how it caters to single-tenancy and multi-tenancy scenarios.

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 – Single Tenancy & Multi-Tenancy Explained

Assigned Tags

      4 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Thorsten Hapke
      Thorsten Hapke

      Many thanks Vipul for this excellent introductory blog. I am wondering what are the differential aspects compared to KAFKA? Why has it been decided not to use this widespread and proven technology? In particular what is the performance for high data volumes and high number of requests?

      Author's profile photo Ayush Kumar
      Ayush Kumar

      Hi Thorsten Hapke I haven't found any reason anywhere in the event mesh wiki or help regarding how the high volume data transactions happen in Event Mesh and how the performance is impacted.
      But one thing which I have observed in one of my poc is that if you create very large volume of data very frequently then the event mesh setup sometime starts giving connection errors stating the reason of resource units or max parallel connections allowed.
      I am just taking a guess, I have not yet drilled down to the bottom of the problem.

      If I am not wrong I guess there is a new offering called advanced event mesh.
      Need to explore that before I make any comment on comparing the capabilities of event mesh and kaffka.

      Best Regards
      Ayush

      Author's profile photo Ahmed Ali Khan
      Ahmed Ali Khan

      Not sure if I am comparing apples with oranges but I am still confused with event mesh, we were using OData services for all these kind of requirements, How it would be different?

      Author's profile photo Ayush Kumar
      Ayush Kumar

      Hi Ahmed Ali Khan odata service and event mesh both are for different purpose.
      If I am not mistaken you are viewing them both as a method to simply transfer data/resources from one microservice to another but that's not the case.
      Odata services are a synchronous mechanism to send/receive data whereas Event-driven architecture is for asynchronous calls.

      Event Driven Architecture is generally prefered in microservices which already have a separation of domain/responsibilities hence blocking any one of them is for other microservice to act is simply waste of resources.

      I Hope this clarifies things for you.
      Best Regards
      Ayush