Integrationadvanced
SAP Event Mesh & Event-Driven Integration
Publish-subscribe, asynchronous event-driven integration patterns using SAP Event Mesh and CloudEvents-based messaging.
In request/response integration the caller knows who it is calling and waits for an answer. In event-driven integration the producer announces that something happened and does not know who is listening.
Event-driven integration is like a public announcement system in a train station - the announcer (producer) broadcasts 'Platform 4 delayed' to anyone listening without knowing who's actually present, and any number of travelers (consumers) can react to it independently, versus a request/response call which is like personally walking up to one specific staff member and waiting for them to answer your direct question.
Key Concepts
1
That difference is the whole topic.
2
Publish and subscribe.
S/4HANA --"SalesOrder.Created"--> topic
|--> CPI flow
|--> BTP extension app
|--> notification service3
The producer publishes to a named topic. Any number of consumers subscribe. Adding a fourth consumer
requires no change to S/4HANA, and no awareness of it.
4
SAP Event Mesh is the BTP service providing this, increasingly using the CloudEvents specification so the
envelope is consistent across sources.
5
How it differs from IDoc/ALE, which is also asynchronous. ALE distributes to explicitly configured
partners: the distribution model names who receives what. Adding a receiver is a configuration change on
the sending system.
6
Pub/sub has no such list. The producer publishes; subscription is the consumer's business.
7
What the decoupling actually buys. A downstream system that wants to know about new sales orders has
two options without events: poll on a schedule, or have somebody configure the sender to push to it.
8
Polling every five minutes means work that mostly finds nothing, and a five-minute delay. Events arrive
when the thing happens, and cost nothing when nothing happens.
9
It fits the clean-core principle. A side-by-side extension on BTP subscribes to a standard business
event and adds behaviour, without any modification to S/4HANA and without an enhancement point.
10
The core stays standard; the extension reacts. That is the pattern SAP is steering extensions towards.
11
When request/response is still right. The caller needs an answer now — a price, a credit check, whether
stock is available. An event cannot answer a question; it announces a fact.
12
events several or unknown consumers; reacting to something
that already happened; no answer needed
request/response one known receiver; an answer required before
continuing13
The cost of the pattern, which an honest answer includes. Debugging is harder. There is no call stack —
a message was published and several things happened somewhere, possibly out of order, possibly twice.
Consumers must tolerate duplicates, and tracing a business process across events needs deliberate
correlation. That is the price of the decoupling, not a flaw in the tooling.
14
What the interviewer is probing.1. "When is an event better than an API call?" Probing: the fit. Stalls: "It is faster."
Moves up: when the producer should not know or wait for consumers — fan-out, decoupling and
resilience to a consumer being down.
15
2. "What delivery guarantee should you assume?" Probing: the engineering reality. Stalls:
"Exactly once." Moves up: at least once, so consumers must be idempotent — duplicates are a design
input, not an anomaly.
16
3. "What emits events from S/4HANA?" Probing: the mechanics. Stalls: "Custom code." *Moves
up:* enterprise event enablement with released business events, published to Event Mesh without
custom triggers.
17
4. "What is the hardest part operationally?" Probing: honesty. Stalls: "Nothing." *Moves
up:* observability — tracing one business transaction across asynchronous hops needs correlation ids
and dead-letter handling planned up front.