[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-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 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