Event-driven integration with SAP Event Mesh

What is event-driven integration?

Event-driven integration flips the usual direction of control. Instead of one system calling another and waiting, an application emits a business event, a statement that something happened, and any interested system subscribes and reacts. The publisher does not know or care who the consumers are. This publish/subscribe model is what gives event-driven architecture its defining property: loose coupling.

Events are one of the three integration styles in SAP Integration Suite, alongside APIs and messaging. For how they fit together, see the SAP Integration Suite complete guide.

When should I choose events?

Quick answer: choose events when the same business moment matters to several systems and you want them to react in near real time without the source orchestrating each call.

Classic examples: an order is created and inventory, finance and a partner portal all need to know; a master-data record changes and several downstream systems must update. The contrast with APIs is simple:

Most landscapes use all three. The skill is choosing per interface rather than forcing one style everywhere.

Event Mesh vs Advanced Event Mesh

SAP offers two eventing capabilities, and they are not the same thing.

SAP has highlighted migration support from SAP Event Mesh (the default plan) toward Advanced Event Mesh, which signals the direction of travel. If you are starting a significant event-driven programme, factor Advanced Event Mesh into the plan. The gated guide on SAP Advanced Event Mesh goes deeper.

How do topics work, and why are they risky?

Events are published to topics, named channels that consumers subscribe to, and Advanced Event Mesh supports hierarchical topics with dynamic routing and filtering so brokers deliver only the events a consumer cares about. A topic is an interface contract. Because consumers depend on the topic structure and the event schema, changing a topic can break systems you do not own and may not even know about. This makes topic design a governance concern:

• Catalogue topics and event schemas, which the event portal in Advanced Event Mesh is designed to help with.
• Treat topic and schema changes as high-risk when consumers are outside your team.
• Version events rather than silently changing their shape.

What does guaranteed delivery and replay give me?

Advanced Event Mesh provides guaranteed delivery, persistence and replay. In practice this means an event is not lost if a consumer is briefly down, and a consumer can replay past events to catch up or when it is newly added. This is what makes event-driven integration dependable rather than best-effort, and it is a key reason larger landscapes adopt Advanced Event Mesh over basic eventing.

What does event-driven integration demand of design?

Loose coupling has a cost: you lose the immediate, synchronous confirmation an API gives you. Design accordingly:

• Idempotent consumers: events can be delivered more than once, so processing the same event twice must be safe. This is the same idempotency principle as in retry design.
• Observability: because no single call ties it together, invest in correlation, distributed tracing and monitoring so you can follow an event across consumers.
• Schema discipline: a clear, versioned event schema is what keeps consumers stable over time.

What are the event-driven anti-patterns?

• Treating topics as throwaway, then breaking unknown consumers with a rename.
• Non-idempotent consumers, which duplicate work on redelivery.
• Events as disguised commands, tightly coupling publisher and consumer and losing the benefit.
• No schema governance, so consumers break when an event quietly changes.

How do events fit with S/4HANA?

SAP S/4HANA emits business events that flow through the eventing capabilities, letting you react to business moments in near real time. Combined with released APIs for request-response, this gives a clean-core landscape both pull and push integration. The API side is covered in S/4HANA Public Cloud integration and SAP API Management.

How do I design good event schemas?

Quick answer: model events around business facts, keep them stable and versioned, and include enough context to be useful without being a full data dump.

An event is a contract with consumers you may not control, so schema design matters. Model events around meaningful business facts (OrderCreated, ShipmentDispatched) rather than technical table changes. Include the key identifiers and enough context for common consumers, but resist turning the event into a full record export, which couples consumers to your internal model. Version events explicitly so you can evolve them without breaking subscribers, and publish the schemas, which is exactly what the event portal in Advanced Event Mesh is designed to support. Good schema discipline is what keeps an event-driven estate stable as it grows.

When should I choose Advanced Event Mesh over basic eventing?

SAP has signalled migration support from Event Mesh toward Advanced Event Mesh, so for a new, significant event-driven programme, Advanced Event Mesh is the forward-looking choice. The gated guide on SAP Advanced Event Mesh goes deeper into the architecture.

How do I make event-driven integration observable?

The hardest part of event-driven architecture is seeing what happened, because no single call ties the flow together. Invest in three things: a correlation identifier carried on every event so you can trace a business transaction across consumers; distributed tracing, which Advanced Event Mesh supports, to follow events through brokers; and monitoring and alerting on consumer failures and backlogs. Observability is not optional in event-driven systems; it is what makes them operable.

How do events and APIs work together in practice?

Events and APIs are not rivals; they play different roles in the same process. A typical pattern: an API handles a synchronous request such as submitting an order, and once the order is created, an event notifies inventory, finance and fulfilment to react independently. This combines the immediate confirmation of an API with the loose coupling of events, and it is a natural fit for the S/4HANA Public Cloud architecture where both released APIs and business events are available.

What format do SAP business events use?

Quick answer: SAP business events follow the CloudEvents specification, a vendor-neutral standard that puts consistent metadata, such as the event type, source, ID and time, around the business payload.

Using a common envelope matters more than it first appears. Consumers can route, filter and deduplicate on standard attributes without parsing the business data, and events from SAP and non-SAP producers can share the same tooling. The event ID is particularly useful: consumers can use it to detect duplicates, which matters because most brokers deliver at least once. When you design your own custom events, adopt the same envelope rather than inventing a house format.

Should events carry the data, or just a notification?

Quick answer: notification events are small and safe but force consumers to call back for details; data events carry the payload and decouple consumers further, at the cost of larger messages and stricter schema governance.

Many standard S/4HANA events are notification-style, so plan for the callback: consumers typically receive the event and then read the current state through a released API. That pattern also protects you from processing stale data, because the callback always returns the latest version.

A scenario: one sales order, three consumers

Quick answer: publish once, subscribe many times, and let each consumer own its own queue, retry and failure handling.

When a sales order is created in S/4HANA, the warehouse needs to prepare picking, the CRM needs to update the account view, and analytics wants the order for near-real-time reporting. With point-to-point integration, that is three interfaces S/4HANA must call and wait for. With events, S/4HANA publishes one sales-order event to a topic. Each consumer has a durable queue subscribed to that topic, so if the CRM is down for maintenance its queue simply fills and drains later, while the warehouse carries on unaffected. Adding a fourth consumer next year means one new subscription, with no change to S/4HANA. This is the decoupling event-driven architecture promises, but it only holds if each consumer is idempotent and monitored.

When should I not use events?

Quick answer: avoid events when the caller needs an immediate answer, when a strict transactional guarantee across systems is required, or when there is only ever one consumer and a simple API call would do.

Credit checks, price lookups and availability checks need a synchronous response, so they belong on APIs. Flows that require all-or-nothing consistency across systems need explicit compensation design whichever style you choose, and events make that harder to reason about, not easier. And an event broker for a single, stable consumer adds infrastructure and monitoring without adding value. For how APIs fit alongside events, see the Integration Suite pillar, and for deeper broker design, the gated Advanced Event Mesh guide.

The takeaway

Use events for loose coupling and real-time propagation, APIs for request-response, and messaging for reliable asynchronous delivery within a flow. Govern topics like the interface contracts they are, lean on guaranteed delivery and replay for dependability, and design idempotent, observable consumers. Return to the complete guide for the full architecture.