Joel Schäufele
What is SAP Event Mesh?
SAP Event Mesh is a cloud-based service on the SAP Business Technology Platform (SAP BTP), used to implement event-driven architectures within SAP environments.
SAP Event Mesh serves as a central component of an IT landscape, enabling events to be published and responded to as needed. This allows events to be exchanged between systems in real time – flexibly and without the need for rigid, fixed connections between them.
What is an event?
An event is a notification that something specific has occurred. In an SAP context, this could be the creation or update of a business partner, or the processing (creation, picking, dispatch, etc.) of an order. Currently, over 400 different events can be triggered by more than 20 different SAP systems and published via SAP Event Mesh.
The format and structure of events are not SAP-specific; instead, they follow the specification from CloudEvents, an open-source project hosted by the Cloud Native Computing Foundation. This ensures cross-vendor interoperability and reduces implementation efforts. The example below – showing an updated business partner – illustrates such an event, which includes contextual information (sender, ID, timestamp, etc.) along with the actual event data:
In this example, the data field contains the ID of the updated business partner. It is then up to the respective receiver to decide how to handle this information and respond.
All events offered by SAP systems can be found and viewed on the SAP Business Accelerator Hub.
What is event-driven architecture?
Traditionally, a target system queries the sender system for the latest data, doing so at regular intervals via classic interfaces. For example, in the case of business partners, a target system might run a job that regularly queries the S/4 system for updates or newly created business partners (e.g. hourly or daily), and then transfers them accordingly.
As an alternative to this pull approach, the S/4 system can employ a push approach, actively transmitting changes to the target system at regular intervals. However, both methods lead to rigid point-to-point communication, where the sender and receiver are tightly connected and need to wait on each other. This setup is not only less flexible but also increases implementation efforts and creates dependencies on other systems – and potentially on other teams as well.
In recent years, asynchronous communication has become increasingly common. Here, although systems remain closely linked, processing takes place with a time delay via a message queue.
The following example illustrates how the S/4 system proactively sends a notification about a new business partner to a message queue, from which the target system retrieves the message. Regardless of the target system’s processing status or availability, the process is considered complete from the sender’s perspective – an approach commonly referred to as “fire and forget”.
Responsibility for further processing thus lies with the target system; this can occur either in near real-time – with minimal delays – or hours, or even days, later. While this reduces the direct dependency between systems, the communication is still explicitly defined and remains relatively rigid.
With event-driven architecture, processing is based on events. This means that the sender proactively notifies an event broker (event mesh) in real time whenever a change occurs in the system – a process known as a “Publish Event”. Each published event has a defined type and is published via a so-called “topic”. For example, when dealing with business partners, the topic could be defined as “BusinessPartner/Changed”. Target systems can then subscribe to this topic in the event broker (“Subscription”), and whenever an event with that topic is published, the broker delivers it to the subscribed system.
The message broker therefore plays a central role in this setup, handling both configuration and routing. If a receiver is not available, the event is typically persisted in the broker and delivered at a later time.
When event-driven architecture is used, systems are fully decoupled and can respond to events as needed. As the IT landscape evolves and new consumers are added, they can simply subscribe to existing topics – no changes are required on the sender side.
How does SAP Event Mesh work?
SAP Event Mesh is an event broker provided as part of the SAP Business Technology Platform. The below protocols are available for integration:
- AMQP (Advanced Message Queuing Protocol)
- MQTT (Message Queuing Telemetry Transport)
- REST APIs (Representational State Transfer Application Programming Interfaces)
The following concepts are available in Event Mesh for configuration: queues, topics, and queue subscriptions.
The following concepts are available in Event Mesh for configuration: queues, topics, and queue subscriptions.
QUEUes
A queue enables message exchange between applications. Each receiver is assigned a dedicated queue that persists messages and forwards them accordingly. Messages can either be sent directly to the queue by a sender or delivered via a topic the queue is subscribed to.
QUEUES
A queue enables message exchange between applications. Each receiver is assigned a dedicated queue that persists messages and forwards them accordingly. Messages can either be sent directly to the queue by a sender or delivered via a topic the queue is subscribed to.
QUEUes
A queue enables message exchange between applications. Each receiver is assigned a dedicated queue that persists messages and forwards them accordingly. Messages can either be sent directly to the queue by a sender or delivered via a topic the queue is subscribed to.
Topics
A topic allows the sender to publish events. Using filters, receivers can define which topics they want to subscribe to. Topics are not persisted – if no receivers are registered when a new event is published, the event is discarded.
Topics
A topic allows a sender to publish events. Using filters, receivers can define which topics they want to subscribe to. Topics are not persisted – if no receivers are registered when a new event is published, the event is discarded.
Topics
A topic allows a sender to publish events. Using filters, receivers can define which topics they want to subscribe to. Topics are not persisted – if no receivers are registered when a new event is published, the event is discarded.
QUEUE subscriptions
This concept is the recommended approach when using SAP Event Mesh. Senders publish their events to one or more topics, with each receiver having a dedicated queue subscribed to the relevant topics. This means that when events are published (via topics), all messages are directly persisted in the respective receiver queues and subsequently processed.
This ensures reliable delivery – even if the receiver is temporarily unavailable – and enables flexible connections between senders and receivers without creating dependencies between them.
QUEUE subscriptions
This concept is the recommended approach when using SAP Event Mesh. Senders publish their events to one or more topics, with each receiver having a dedicated queue subscribed to the relevant topics. This means that when events are published (via topics), all messages are directly persisted in the respective receiver queues and subsequently processed.
This ensures reliable delivery – even if the receiver is temporarily unavailable – and enables flexible connections between senders and receivers without creating dependencies between them.
How SAP Event Mesh compares to other SAP solutions
In addition to Event Mesh, SAP also offers products like Advanced Event Mesh and Cloud Application Event Hub.
SAP Advanced Event Mesh is offered as part of the SAP Integration Suite and provides significantly broader capabilities than Event Mesh, including advanced management and monitoring features. This makes it especially valuable for large-scale event-driven architectures.
SAP Cloud Application Event Hub is the newest addition to the portfolio, specialising in connecting SAP Cloud and BTP applications. It provides an easy-to-use solution that requires minimal configuration effort.
Interested?
Interested in learning more about event-driven architecture in the SAP landscape? Feel free to get in touch – no strings attached.
Whether you’re seeking to build internal expertise through a workshop or need guidance implementing an event-driven strategy, we’re here to support you.
Interested in learning more about event-driven architecture in the SAP landscape?
Whether you’re seeking to build internal expertise through a workshop or need guidance implementing an event-driven strategy, we’re here to support you.
Get in contact today – no strings attached!
Articles recommended for you
Event-driven architecture (2) – SAP Event Mesh: a case study
This case study demonstrates how SAP Event Mesh automates invoice generation and triggers follow-up actions in real time.
Event-driven architecture (3) – A deeper look at SAP solutions
In this blog post, we take a closer look at SAP Advanced Event Mesh and SAP Cloud Application Event Hub, explaining their differences and use cases.
