SAP Event Mesh

Event Mesh lets applications emit events (e.g. "sales order created") that other applications subscribe to and react to, without direct coupling. This event-driven style enables real-time, loosely-coupled integration, an application reacts to what happened rather than being called directly, complementing request/response APIs.

• Publish/subscribe messaging.
• Business events (e.g. from S/4HANA) as triggers.
• Decoupling of producers and consumers.
• Scalable, asynchronous reactions.

One clarification that saves confusion: Event Mesh is the messaging service, and the events it carries mostly originate as business events published by SAP applications. Those are enabled and configured in the source system rather than written, so a large part of adopting event driven integration is discovering what the applications already emit before building anything.

The distinction is not a technical detail. It changes who has to know about whom, which is the whole architectural argument.

In a request model, the caller knows the receiver, calls it, and waits. Adding a second consumer means changing the caller. If the receiver is down, the caller has a problem.

In an event model, the producer announces that something happened and does not know or care who is listening. A sales order was created. Adding a second consumer changes nothing in the producer. If a consumer is down, the event waits in its queue.

The producer's job ends at publishing. That is the freedom and it is also the discipline: an event describes a fact that has already happened, in the past tense, and it must not assume what anybody will do about it. An event named "create the delivery" is a request wearing an event's clothes.

Topics are how consumers select what they want, usually a hierarchical name so a subscriber can take one event type or a whole branch. Queues hold events for a consumer so nothing is lost while it is unavailable.

What you give up is the immediate answer. There is no response, so the producer cannot know whether anything succeeded, and any workflow needing confirmation has to model that as a second event coming back.

Event Mesh is a service on the platform, configured in the browser: message clients, queues, topic subscriptions and the credentials applications use to connect.

On the SAP side, business events are emitted by the applications themselves. S/4HANA publishes a catalogue of standard events, enabled and configured rather than coded, and cloud products such as SuccessFactors and Ariba do the same. That catalogue is the practical starting point, because using a standard event costs configuration and inventing one costs development.

Consumers can be almost anything: an application on the platform, an integration flow in Integration Suite, or a system outside SAP entirely, connecting over standard messaging protocols.

The design question is where the event goes first. A consumer subscribing directly is simplest. An integration flow subscribing and then fanning out gives you transformation, filtering and error handling in one place, which is usually worth it once more than one consumer exists.

Use Event Mesh for event-driven scenarios, reacting in near real time to business events across decoupled systems (e.g. triggering a downstream process when an order is created). It complements APIs and IDocs and is central to modern, responsive integration architectures.

And when not to. If the caller needs an answer, use a synchronous API. If the volume is a nightly file, use a file. If two SAP systems already exchange the document reliably as an IDoc, moving it to events buys little. Event Mesh earns its place when the number of interested consumers is unknown or growing, and when loose coupling is worth more than certainty about who received what.

• Topic naming. Hierarchical and stable, because consumers subscribe to it and renaming breaks them silently. This is worth designing before the first event ships.
• How much the event carries. A thin event with just an identifier means consumers call back for detail. A fat event carries everything and couples the producer's data model to its consumers.
• Ordering and duplicates. Messaging generally guarantees at-least-once delivery, not exactly-once, so consumers must tolerate a repeat.
• Who watches the queues. A queue with no consumer fills and eventually rejects, and nobody notices until it does.

Events shift work from build time to run time, and the operational side is where an event architecture succeeds or quietly fails.

Queue depth is the number to watch. A queue growing steadily means a consumer is slower than the producer, or has stopped. That is the earliest signal available and it is often the only one, because nothing errors.

Dead letter queues hold messages that could not be processed after retries. They need a person and a routine, or they are a hole things fall into.

Replay is the question to answer before you need it. Can a consumer that was broken for a day reprocess what it missed, and is doing so safe. If reprocessing an event creates a duplicate record, the answer is no, and the consumer needs to be idempotent before that day arrives.

Schema change is the slow risk. Adding a field is usually safe. Removing or renaming one breaks consumers you may not know about, which is the cost of the decoupling you wanted. Versioning the topic or the payload is how that is managed.

Knowing who subscribes matters more than it seems. The producer deliberately does not know, so somebody has to keep a register, or a change is made blind.

The payload is the contract, and it is the hardest part to change later.

Thin or fat. A thin event carries an identifier and a type: sales order 4711 was created. Consumers call back for whatever they need, which keeps the producer's data model private and costs a round trip. A fat event carries the order, which is convenient and couples every consumer to that structure.

Most designs land on thin plus a few widely useful fields, so that simple consumers need no callback and complex ones fetch detail.

Identifiers must be stable and meaningful across systems. An event carrying an internal number nobody else can resolve is not much use.

Include a timestamp and a version. The timestamp lets a consumer detect out-of-order arrival. The version lets the payload evolve without breaking anyone.

Do not include what should be looked up. Denormalised data in an event is a snapshot that ages, and consumers will treat it as current.

• Wrong tool for the integration style.
• Ignoring monitoring/error handling.
• Point-to-point instead of governed integration.

• Events that are really commands. Naming one after what the consumer should do recreates the coupling events exist to remove.
• No dead letter handling. A message that cannot be processed has to go somewhere a person will look.
• Assuming order. Two events about the same object can arrive out of sequence, and a consumer that assumes otherwise corrupts its own state. See REST integration and JDBC for the synchronous alternatives.

Publishing an event is the easy half, and designing topics, queues and consumers that stay decoupled as the landscape grows is the part you do in the course.

The design test worth applying to any event is whether its name describes something that already happened. If it describes what somebody should do next, it is a request, and modelling it as an event will recreate the coupling you were trying to remove.