SAP Clean Core Enterprise Event-Driven Architecture: Event Mesh, Kafka & CloudEvents Guide

1. The Strategic Shift to Enterprise Event Streams

In legacy SAP implementations, cross-system data synchronization relied heavily on batch RFCs, batch IDocs, or polling OData queries. These synchronous and batch methods create tight coupling, database contention, and point-to-point integration fragility.

Under the SAP Clean Core Strategy, integration shifts to real-time asynchronous event streaming. SAP S/4HANA emits lightweight notifications whenever state changes occur (e.g. Sales Order created, Business Partner updated), which are published through SAP Event Mesh / Advanced Event Mesh (Solace) and federated into enterprise Apache Kafka / Confluent Cloud clusters.

2. Dual-Write Elimination via Transactional Outbox

A common architectural trap is attempting to make HTTP calls or publish directly to a message broker from inside an ABAP LUW or RAP determination. If the broker call succeeds but the SAP database transaction fails (or vice versa), the system enters an inconsistent state.

The Transactional Outbox Pattern solves this dual-write problem:

• Inside the RAP save_modified sequence, the business document and a corresponding event record are inserted into the local database within the same database commit.
• An asynchronous poller or SAP Event Mesh daemon continuously reads uncommitted outbox records and publishes them with guaranteed at-least-once delivery.

3. CloudEvents 1.0 Specification Conformance

To ensure enterprise consumer agnostic interoperability across multi-cloud systems (AWS, Azure, Google Cloud, Salesforce), SAP events must conform to CNCF CloudEvents 1.0:

{
  "specversion": "1.0",
  "id": "urn:uuid:6c9b6342-8921-4f11-9a72-132d7809a41e",
  "source": "/default/sap.s4.beh/PRD_100",
  "type": "sap.s4.beh.salesorder.v1.SalesOrder.Created.v1",
  "time": "2026-10-29T15:30:00Z",
  "datacontenttype": "application/json",
  "data": {
    "SalesOrder": "0010002931"
  }
}

4. Deterministic Kafka Partitioning & FIFO Guarantees

Kafka guarantees ordering only within a single partition. To ensure that an order's updates (Created -> Changed -> Invoiced) are processed chronologically:

• Set the Kafka record.key to the business entity primary key (e.g. SalesOrderNumber).
• Kafka's default murmur2 hashing ensures all events for that specific order land in the exact same partition.