Event-driven architecture: publishers, brokers, consumers

Great Lakes Fleet Services wants to know the moment an order changes: a new delivery date, a quantity cut, a block for credit. Contoso's first instinct was to let the fleet order status app ask SAP S/4HANA every five minutes. That works for ten orders and fails for ten thousand: most calls find nothing new, the interesting change still arrives up to five minutes late, and every new consumer adds more load on the ERP. An event-driven architecture (EDA) turns the direction around. The system where something happens announces it once; everyone who cares is told.

Business changeMaria changes the delivery date on a sales order for Great Lakes Fleet Services in CMP
Event source publishesS/4HANA emits a SalesOrder Changed event: a small message saying what happened, to which object, when
Broker routesThe event broker receives the event on a topic and copies it to every queue subscribed to that topic
Queue holdsThe fleet notifier's queue keeps the event until the consumer takes it and acknowledges it
Consumer reactsThe fleet order notifier on SAP BTP reads the current order and informs the fleet portal

One business change, announced once, delivered to whoever subscribed.

The Sign-Off Table · thesignofftable.com/academy/sap-btp-303

The vocabulary

SAP's architecture guidance defines an event as a significant change in state, such as a sales order being created or a business partner being changed. The event source (or publisher, or producer) is the system where it happened; in an SAP landscape that is usually a back end such as SAP S/4HANA. The event broker is the intermediary that routes events in a publish-subscribe way. Event consumers subscribe to the broker and are informed when events occur; they range from extension apps on SAP BTP to complete back ends.

Inside the broker, two more words matter. A topic is the address an event is published to, for example a path that names the business object, the event type and the version. A queue belongs to a consumer and stores events until that consumer has processed them; a subscription connects a queue to one or more topics. Topics fan out; queues persist. If the fleet notifier is down for maintenance, its queue keeps collecting events and nothing is lost, which is the decoupling that makes EDA attractive.

Topics fan out and queues persist: one published event is copied to every subscribed queue, and each queue holds it until its own consumer is done.

The Sign-Off Table · thesignofftable.com/academy/sap-btp-303

	Synchronous API call	Event
Who starts it	The consumer asks	The source announces
Coupling	The caller must know the provider and wait for it	Source and consumers only know the broker and the event format
When the other side is down	The call fails; the caller must retry	The queue holds events until the consumer returns
Timing	Immediate answer	Near real time, but asynchronous: no answer to the source
Good for	Reading data, commands that need an answer now	Notifying many parties that something happened

Request-response versus events. Most real designs use both.

The Sign-Off Table · thesignofftable.com/academy/sap-btp-303

Notification events and data events

SAP distinguishes two kinds of payload. A notification event carries little more than the key of the changed object; SAP's sample business partner event carries only the business partner number. The consumer then calls an API to read the current state. A data event carries the relevant business data in the event itself. Notification events keep payloads small and avoid copying sensitive data through the broker; data events save the follow-up API call but make the event format a bigger contract. Most SAP S/4HANA standard events are notification-style, so most consumers combine an event with an API call.

The envelope: CloudEvents

SAP uses the open CloudEvents specification, a Cloud Native Computing Foundation project, as the common envelope for its events. Every event carries a few context attributes: specversion (1.0), type (for example sap.s4.beh.salesorder.v1.SalesOrder.Changed.v1), source (which system produced it), id (which occurrence this is), and usually time and datacontenttype, followed by the data payload. The specification requires producers to keep source plus id unique for each distinct event; lesson 3 builds the duplicate handling on that rule.

A CloudEvents envelope around a notification payload: the context attributes identify the event, and source plus id must be unique per distinct event.

The Sign-Off Table · thesignofftable.com/academy/sap-btp-303

Batch or scheduled readOne consumer, no urgency: a nightly extract or scheduled API read is simpler

Synchronous APIOne consumer needs an answer now: call the API

EventsMany consumers, near real time, no answer needed: publish once, subscribe many

Events plus APIMany consumers that also need current details: notify by event, read by API

Choosing between events and APIs.

The Sign-Off Table · thesignofftable.com/academy/sap-btp-303

What would you do?

Grace asks why the team does not simply let the fleet order status app call S/4HANA every minute instead of adding a broker. Which answer best captures the trade-off?

Key points

An event is a significant change in state; the source announces it once.
Brokers route events by topic; queues persist them per consumer; subscriptions connect the two.
Notification events carry keys; data events carry data. Many S/4HANA events are notifications.
SAP uses CloudEvents: specversion, type, source, id, time, data; source plus id identifies one event.
Use events for many consumers and near real time; combine with APIs for details.

The vocabulary

Notification events and data events

The envelope: CloudEvents

Lesson check