Event-driven integration in 2026

Contoso Motor Co.'s integration estate started as Process Orchestration on XP1: exactly 64 integrated configurations, about 25 of them IDoc, moving to SAP Integration Suite in waves after hypercare. Those are mostly point-to-point, request-driven flows: an order goes to Lakeside, an invoice comes back. Alongside them, a second style has grown since go-live: SAP S/4HANA business events published to a broker, consumed by extensions such as the fleet order notifier and the fleet customer onboarding process. Theo, the integration lead, now owns both, and this course is about the second: the brokers, their topics and queues, the contracts, and how to test the integration layer.

The business events course in the BTP track (sap-btp-303) covered events from the extension developer's side: the CloudEvents envelope, idempotent consumers, ordering and dead messages in consumer code. This course looks from the integration architect's and tester's side: which broker, how topics and queues are designed, how event contracts are versioned, how S/4HANA is wired to the broker, and which tests prove the integration layer before anyone tests a consumer.

Where events fit next to APIs and IDocs

Events do not replace the other styles. They change who knows about a change: instead of every interested system asking S/4HANA, S/4HANA announces the change once, and the broker delivers it to every subscriber. The integration architect's job is to keep that broker landscape simple, governed and testable.

SAP's brokers in 2026

SAP positions advanced event mesh as complementing the basic broker for more demanding scenarios, and SAP's Event Mesh documentation points customers toward migration to advanced event mesh; SAP announced migration support from the SAP Event Mesh default plan in its Q1 2026 Integration Suite highlights. Product packaging and names change often in this area, so check the current SAP Help and your contract before committing. Contoso started small with the Event Mesh capability, one broker instance per stage, as the business events course described.

Roles around the broker

Event-driven integration spreads responsibility across teams, so Contoso writes it down. Theo's integration team owns the brokers, topic conventions, queues, subscriptions, DMQs and monitoring. Producer teams own their events: Kenji's team for custom RAP events, SAP for standard events, with Theo's team configuring the S/4HANA side. Consumer teams (Elena's warranty app, the fleet notifier, the BPA onboarding process) own their processing and their idempotency. Priya owns the test strategy across all three, and Sam owns the Basis side: channels, technical users and system copies. When an event goes missing, this split tells the incident manager whom to call first.

What is driving Theo's review

• More consumers. Three event consumers in the first year, five more planned. Every new consumer needs a queue, a subscription and tests.
• Wave 2 in Monterrey. Company code 1910 and plant 1910 Monterrey add Mexican consumers, and the plant team wants local event processing that keeps working when the WAN link is slow.
• Recovery needs. Elena's warranty analytics consumer wants to reprocess a week of events after a bug fix, which the current setup cannot do.
• Contracts. Two consumers broke when a custom event added a renamed field. Nobody had a catalog of who consumed what.

What goes wrong

• Events as a replacement for everything. A request that needs an answer now is an API call, not an event.
• No owner for the broker. Queues are created by each project and never cleaned up.
• Testing only consumers. Subscriptions, stage separation and dead message routing are tested by nobody.