Clean Core Architecture Guide #47

SAP Advanced Event Mesh (AEM) & Clean Core Event-Driven Architecture

⏱️ 14 min read 🏢 Enterprise Architectural Blueprint 🔄 Updated for S/4HANA 2023 & Cloud

Core Architectural Mandate: In a modern Clean Core enterprise, asynchronous event notification replaces point-to-point synchronous RFC/BAPI connections and batch polling jobs. SAP Advanced Event Mesh (AEM, powered by Solace) provides the high-performance event backbone connecting S/4HANA core systems to BTP side-by-side apps, hyperscalers, and edge brokers.

1. SAP Event Mesh vs. SAP Advanced Event Mesh (AEM)

While standard SAP Event Mesh is designed for basic cloud-to-cloud pub/sub scenarios, large enterprise landscapes require SAP Advanced Event Mesh (AEM). Powered by Solace broker technology, AEM unlocks extreme scale, global multi-cloud event distribution, dynamic message routing (DMR), and guaranteed delivery.

Architectural Dimension	Standard SAP Event Mesh	SAP Advanced Event Mesh (AEM / Solace)
Underlying Engine	Proprietary RabbitMQ/Cloud Foundry base	Solace PubSub+ Enterprise Event Broker
Throughput / Scale	Up to ~1,000 msg/sec	Up to 28,000,000+ msg/sec
Multi-Cloud & Hybrid Mesh	Restricted to SAP BTP regions	Dynamic Message Routing (DMR) across AWS, Azure, GCP & On-Prem
Topic Filtering Engine	Basic exact string matching	*Hierarchical topic levels with '' and '>' wildcards**
Event Replay Buffer	Not supported	Time-Travel Event Replay (hours to days) for zero-loss recovery
Protocol Support	REST, AMQP 1.0, MQTT 3.1.1	REST, AMQP 1.0, MQTT 3.1.1/5.0, JMS, Solace SMF, WebSocket

2. Enterprise Hierarchical Topic Taxonomy

A clean core event-driven architecture requires a strict, standardized topic taxonomy. Unlike Apache Kafka topics (which represent physical log partitions), Solace/AEM topics are virtual routing addresses included in message headers that cost zero compute overhead.

// Formal SAP CloudEvents Topic Standard:
// <organization>/<source_system>/<domain>/<entity_type>/<action>/<version>

sap/s4/ce/sd/SalesOrder/Created/v1
sap/s4/ce/sd/SalesOrder/Changed/v1
sap/s4/ce/sd/SalesOrder/Cancelled/v1
sap/s4/ce/fi/JournalEntry/Posted/v1
sap/s4/ce/mm/PurchaseOrder/Approved/v1

Solace Dynamic Wildcard Subscriptions

Downstream consumers do not need separate queues for every event variant. They provision a single consumer queue and bind wildcard subscriptions:

sap/s4/ce/sd/SalesOrder/*/v1: Subscribes to all state transitions (Created, Changed, Cancelled) for Sales Orders.
sap/s4/ce/sd/>: Subscribes to the entire Sales & Distribution domain hierarchy.
sap/s4/ce/*/JournalEntry/Posted/v1: Catches journal postings across all SAP finance source instances globally.

3. Native RAP CloudEvents Publishing in S/4HANA

In Clean Core, the ABAP RESTful Application Programming Model (RAP) provides first-class native event modeling. Developers declare events directly inside the Business Object Behavior Definition (BDEF):

managed implementation in class zbp_r_salesorder unique;
strict ( 2 );

define behavior for ZR_SalesOrder alias SalesOrder
persistent table zorder_table
lock master
authorization master ( instance )
{
  create; update; delete;

  // Declare Clean Core Event
  event Created parameter ZA_SalesOrder_Created;
}

Inside the RAP Behavior Implementation class, the event is raised atomically within the save_modified phase before database commit:

CLASS lhc_salesorder IMPLEMENTATION.
  METHOD save_modified.
    IF create-salesorder IS NOT INITIAL.
      RAISE ENTITY EVENT zr_salesorder~Created
        FROM VALUE #( FOR ord IN create-salesorder (
          %key = ord-%key
          SalesOrderNumber = ord-SalesOrderNumber
          TotalAmount      = ord-TotalAmount
          CurrencyCode     = ord-CurrencyCode
        ) ).
    ENDIF.
  ENDMETHOD.
ENDCLASS.

Deep-Dive into Enterprise SAP EDA & Clean Core

Explore complete architectural patterns for SAP Advanced Event Mesh, Transactional Outbox implementations, CloudEvents 1.0 specifications, and CAP microservice consumers in The SAP Enterprise Architecture Suite.

Get the Full Architecture Suite (FLASH80 - 80% Off) →

4. Automated SEMP v2 Queue Provisioning

To prevent operational drift, AEM broker resources should be provisioned via Infrastructure-as-Code (IaC) using the Solace SEMP v2 REST API. Below is the automated payload to create an enterprise consumer queue with a 5-retry limit and Dead Letter Queue (DLQ) rerouting:

POST /SEMP/v2/config/msgVpns/production-vpn/queues
Host: aem-broker.s4.cloud:8080
Content-Type: application/json
Authorization: Basic <credentials>

{
  "queueName": "Q_BTP_CAP_ORDER_PROCESSOR",
  "permission": "consume",
  "ingressEnabled": true,
  "egressEnabled": true,
  "accessType": "non-exclusive",
  "maxMsgSpoolUsage": 10000,
  "respectTtlEnabled": true,
  "maxRedeliveryCount": 5,
  "deadMsgQueue": "DMQ_DEAD_LETTER_EXHAUST",
  "subscriptions": [
    { "subscriptionTopic": "sap/s4/ce/sd/SalesOrder/*/v1" }
  ]
}

5. Event Replay & Zero-Loss Disaster Recovery

One of the most powerful capabilities of SAP AEM is Event Replay. Traditional message queues discard messages once acknowledged. If a downstream BTP CAP application encounters an unhandled bug during a batch run, previously processed events are permanently lost.

With AEM, administrators can configure a 7-day persistent Replay Log. If an issue occurs, the consumer queue can "rewind" to any specific timestamp (e.g., 2026-10-29T02:00:00Z) and re-stream all events into the patched application with guaranteed ordering.

Summary Architecture Checklist

✅ Zero Synchronous Cross-System Calls: S/4HANA core never blocks waiting for external third-party responses.
✅ CloudEvents 1.0 Standard: All events conform to standard CNCF CloudEvents headers (id, source, specversion, type).
✅ Hierarchical Virtual Topics: Topic publishing is distinct from physical queue storage.
✅ Dead Letter Quarantine: Every production queue is backed by an automated DMQ with monitoring alerts.

← Back to Interactive AEM Architect Tool