Alle Beiträge
Integration

S/4HANA Events mit EMIS, Teil 1: Konzepte, Architektur und Protokollwahl

EMIS ist Event Mesh direkt in der SAP Integration Suite: kein separates Service-Abonnement, Nachrichten in dauerhaften Queues, eine einheitliche UI für Producer und Consumer. Dieser erste Teil der Reihe erklärt, was hinter dem Kürzel steckt, wie die Architektur aussieht und welches Consumer-Protokoll für typische S/4-Szenarien die richtige Wahl ist.

Was ist EMIS und was ändert sich gegenüber dem bisherigen Event Mesh?

EMIS steht für Event Mesh in SAP Integration Suite. Das Messaging-Konzept, das bisher nur als eigenständiger BTP-Service existierte, ist direkt in die Integration Suite integriert. Das hat für den Projektalltag drei wesentliche Konsequenzen:

  • Wer die Integration Suite mit Standard- oder Premium-Edition nutzt, aktiviert EMIS als Capability, ohne eine zusätzliche Subscription zu buchen.
  • Das bisherige Event Mesh (Standalone) ist nicht abgekündigt, bleibt aber für neue Projekte die zweite Wahl.
  • Advanced Event Mesh (AEM) auf Solace-Basis bleibt das Angebot für sehr hohe Durchsatzanforderungen und reifere Event-Architekturen. In der SAP-Positionierung ist EMIS die in die Integration Suite eingebettete Capability für typische Integrationslasten; AEM ist separat lizenziert für höhere Durchsätze und reifere EDA-Szenarien.

Die folgende Tabelle zeigt die wichtigsten Unterschiede auf einen Blick. Den jeweils gültigen Funktions- und Limit-Stand von EMIS (maximale Nachrichtengröße, Spool-Kapazität, unterstützte Protokolle pro Release) dokumentiert SAP Note 3461547 als kanonische Referenz.

Event Mesh Standalone EMIS Advanced Event Mesh
BTP-Service Eigene Subscription Teil der IS-Entitlements Eigene Subscription (optional)
Protokolle (Consumer) AMQP, REST, MQTT AMQP, REST/Webhook, MQTT AMQP, MQTT, REST, WebSocket
Max. Nachrichtengröße 1 MB 1 MB (Spool gesamt 2 GB) Konfigurierbar
Zielgruppe Bestehende Projekte IS-Kunden, neue Projekte Hoher Durchsatz, reife EDA
Upgrade-Pfad zu AEM Möglich, aber aufwendig Migrationspfad verfügbar -

EMIS startete im Juni 2024 mit AMQP-only; REST/Webhook und MQTT kamen mit dem Q3-2024-Release hinzu. Aktuell gültige Limits und Protokoll-Verfügbarkeit laut SAP Note 3461547 prüfen.

Warum eventgetrieben? Typische Use-Cases aus S/4HANA

Klassische S/4-Integrationen laufen synchron: System A ruft an, System B antwortet sofort. Das funktioniert für interaktive Szenarien gut, stößt aber bei Massenverarbeitung und verteilten Landschaften schnell an Grenzen:

  • Massenverarbeitung ohne Engpass: Hunderte Buchungsbelege, Bestandsänderungen oder Geschäftspartner-Anlagen pro Minute würden im synchronen Modell zu einem stetigen API-Call-Strom. Ein Message Broker puffert die Last und entkoppelt Producer von Consumer.
  • Lose Kopplung: Ist das Zielsystem kurz nicht erreichbar, bleibt die Nachricht in der Queue erhalten. Der Consumer verarbeitet sie, sobald er wieder verfügbar ist, ohne dass der Producer es merkt oder Fehlerbehandlung implementieren muss.
  • Fan-out an mehrere Consumer: Soll ein S/4-Event gleichzeitig in einen CPI-iFlow, ein BI-Tool und eine mobile App fließen, übernimmt EMIS das Fan-out über mehrere Queue-Subscriptions.
  • Situational Awareness in Echtzeit: Downstream-Systeme reagieren auf Änderungen im Kernsystem, sobald sie eintreten, anstatt auf Batch-Jobs oder periodisches Polling zu warten.

S/4HANA stellt eine wachsende Anzahl an Standard-Events bereit; den verbindlichen, release-spezifischen Katalog pflegt SAP im SAP Business Accelerator Hub. Die häufigsten Ausgangspunkte für EMIS-Projekte sind:

  • sap.s4.beh.businesspartner.v1.BusinessPartner.Changed.v1 - Geschäftspartner-Anlage und -Änderung
  • sap.s4.beh.materialdocument.v1.MaterialDocument.Posted.v1 - Wareneingang, Warenausgang, Umbuchung
  • sap.s4.beh.salesorder.v1.SalesOrder.Created.v1 - Neuanlage eines Verkaufsbelegs
  • sap.s4.beh.purchaseorder.v1.PurchaseOrder.Changed.v1 - Bestellungsänderungen
  • Eigene Custom-Events über ABAP-Entwicklung (RAP-Objekte, Business Add-Ins)

Die Topic-Namen folgen dem CloudEvents-Namensschema. Den release-spezifischen Katalog der verfügbaren Events pflegt SAP im SAP Business Accelerator Hub; systemseitig lassen sich die verfügbaren Topics über die Suchhilfe in Transaktion /IWXBE/INBOUND_CFG bzw. /IWXBE/OUTBOUND_CFG einsehen.

Architekturüberblick: Von S/4 PCE bis zum Consumer

Der Nachrichtenfluss gliedert sich in drei logische Schichten:

High-Level-Architektur: S/4HANA PCE sendet Events über das EEE Framework an EMIS auf der BTP, von dort per AMQP oder Webhook an CPI und weitere Consumer.
High-Level-Architektur: Nachrichtenfluss von S/4HANA PCE über EMIS bis zum Consumer. In Teil 2 bauen wir dieses Diagramm weiter aus und betrachten die einzelnen Komponenten detaillierter. Eigene Darstellung auf Basis der SAP-Dokumentation.

Schicht 1: S/4HANA Private Cloud (Producer)

Business-Logik erzeugt ein Domain Event. Das Enterprise Event Enablement Framework (EEE) nimmt das Event entgegen und übergibt es an den ABAP Daemon (Daemon-Session) - einen ABAP-Hintergrundprozess, der die Verbindung zu EMIS hält und Nachrichten zuverlässig sendet. Der Daemon wird bei Channel-Aktivierung in /IWXBE/CONFIG automatisch angelegt; kundenseitig ist lediglich ein Daemon-User mit der Rolle SAP_IWXBE_RT_XBE_DAEMON vorzubereiten. Monitoring erfolgt über SMDAEMON.

Bei S/4HANA Private Cloud (RISE/PCE) ist eine weitere Voraussetzung an SAP zu adressieren, per Service Request:

  1. Outbound-Pfad nach BTP freischalten: PCE-Systeme senden ausgehenden Verkehr durch einen SAP-verwalteten Proxy. Für HTTPS-Verbindungen zu den EMIS-Endpunkten (Token-Endpoint und AMQP-WebSocket, beide Port 443) muss SAP die Zielhostnamen im Proxy explizit erlauben. Ohne diese Freischaltung scheitert die Channel-Aktivierung in Transaktion /IWXBE/CONFIG mit einem Verbindungsfehler, unabhängig davon, wie korrekt SM59 und OAuth-Client konfiguriert sind.

Dieser Schritt und wie der Service Request formuliert wird, sind das zentrale Thema von Teil 3.

Schicht 2: EMIS auf BTP (Broker)

EMIS empfängt das Event und legt es in einer Queue ab. Queues sind persistent: die Nachricht bleibt erhalten, bis ein Consumer sie verarbeitet und mit einem expliziten Acknowledgement bestätigt. Über Topic-Subscriptions lassen sich mehrere Queues mit demselben Nachrichtentyp verknüpfen - ein Event landet dann automatisch in mehreren Queues, was den Fan-out auf verschiedene Consumer ermöglicht. Die EMIS-UI bietet ein einfaches Monitoring: aktive Nachrichten, Consumer-Status, Fehlerübersicht.

Schicht 3: Consumer

  • SAP Cloud Integration (CPI) mit AMQP-Sender-Adapter: Der Adapter hält eine persistente Verbindung zu EMIS und subskribiert die Queue. EMIS pusht eingehende Nachrichten auf dieser Verbindung, der iFlow wird unmittelbar gestartet. Das Acknowledgement erfolgt nach erfolgreich abgeschlossenem iFlow.
  • REST/Webhook: EMIS liefert das Event aktiv an einen konfigurierten HTTPS-Endpunkt. Einfach einzurichten, aber ohne die Durability-Garantie einer Queue.
  • Third-Party-Systeme: Jede Anwendung mit AMQP- oder REST-Unterstützung kann Events direkt konsumieren.

Das richtige Protokoll wählen: AMQP, Webhook oder MQTT?

Auf der Producer-Seite (S/4 zu EMIS) gibt es keine Protokollentscheidung: das EEE-Framework sendet immer per HTTPS an den AMQP-Endpunkt von EMIS. Die Protokollwahl liegt auf der Consumer-Seite.

AMQP (empfohlen für CPI und Enterprise-Consumer)

Das Advanced Message Queuing Protocol ist die robusteste Option. Der CPI-Adapter öffnet eine persistente AMQP-Verbindung und subskribiert die Queue; EMIS pusht eingehende Nachrichten unmittelbar. Der iFlow startet, verarbeitet die Nachricht und sendet erst danach das Acknowledgement. Erst mit dieser Bestätigung wird die Nachricht aus der Queue gelöscht. Auch wenn CPI kurzfristig nicht verfügbar ist oder ein iFlow fehlschlägt, bleibt die Nachricht erhalten und wird beim nächsten Versuch erneut zugestellt. Für die Konfiguration des AMQP-Sender-Adapters braucht man drei Werte aus dem EMIS-Service-Key: den AMQP-Hostname (Feld messaging[amqp10ws].uri), Port 443 und den Pfad /protocols/amqp10ws. Der OAuth 2.0 Client Profile in Transaktion OA2C_CONFIG lautet dabei IWXBE/MGW_MQTT, auch für AMQP-basierte Kommunikation.

REST/Webhook

EMIS pusht Events aktiv an einen konfigurierten HTTPS-Endpunkt. Das ist die einfachste Variante für serverlose Consumer, externe SaaS-Systeme oder schnelle Prototypen. Nachteil: Durability liegt bei EMIS selbst; wenn der Zielendpunkt dauerhaft nicht erreichbar ist und das konfigurierte Retry-Limit überschritten wird, greift Dead-Letter-Verhalten (Details laut SAP Note 3461547). Für kritische Integrationen ist AMQP vorzuziehen.

MQTT

Ein leichtgewichtiges Publish-Subscribe-Protokoll, ursprünglich für ressourcenbeschränkte IoT-Geräte entwickelt. In klassischen S/4-Integrationsszenarien die seltene Ausnahme - relevant wenn MES-Systeme, Edge-Devices oder Maschinen Events direkt konsumieren sollen.

AMQP REST/Webhook MQTT
Typischer Consumer CPI, Enterprise-Backends Externe REST-APIs, SaaS IoT, Edge-Devices
Nachrichten-Durability Ja (Queue mit Acknowledgement) Nein (Retry-Limit) Nein (QoS 0)
Retry bei Consumer-Ausfall Automatisch (Nachricht bleibt in Queue) EMIS-seitig konfigurierbar -
Konfigurationsaufwand Mittel Gering Gering

Voraussetzungen und Lizenzfragen

Auf BTP-Seite:

  • SAP Integration Suite mit Standard- oder Premium-Edition. EMIS ist in diesen Editionen enthalten, muss aber als Capability aktiviert werden.
  • Subaccount-Entitlement für den Service-Plan default (Broker-Initialisierung) und message-client (Producer/Consumer-Binding) der Event Mesh Instance. Die Prüfung erfolgt im BTP Cockpit unter "Entitlements". Service-Bindings können als Standard-Secret (binding-secret) oder X.509-zertifikatsbasiert (mTLS) ausgestellt werden.
  • BTP Trial: EMIS setzt einen Enterprise-Account mit Standard- oder Premium-Edition der Integration Suite voraus und ist im Trial-Subaccount nicht verfügbar (SAP Help: Voraussetzungen).

Auf S/4HANA PCE-Seite:

  • S/4HANA Release 2022 oder neuer empfohlen; neuere Releases liefern mehr Standard-Events und stabilere EEE-Framework-Versionen. Den exakten Mindeststand für spezifische Event-Typen gibt SAP Note 3461547 an.
  • Administrativer User mit Rolle SAP_IWXBE_RT_XBE_ADM für die Channel-Konfiguration in /IWXBE/CONFIG.
  • Daemon-User mit Rolle SAP_IWXBE_RT_XBE_DAEMON vorbereitet; Outbound-Pfad per Service Request bei SAP beantragt (Details in Teil 3).

Was kommt als nächstes?

Die Grundlagen sind damit geklärt. In den folgenden Teilen wird es konkret:

  • Teil 2 zeigt, wie du EMIS auf der BTP einrichtest: Capability aktivieren, Message Client anlegen, Queue und Topic-Subscription konfigurieren, Service Key generieren.
  • Teil 3 deckt alles ab, was auf S/4HANA PCE vorzubereiten ist, bevor die eigentliche Konfiguration beginnt: Zertifikat-Import via STRUST, Daemon-User, und den Service Request für die Outbound-Freischaltung.
  • Teil 4 verbindet beides: SM59-Destination, OAuth-Client-Konfiguration (OA2C_CONFIG), Channel-Anlage in Transaktion /IWXBE/CONFIG, Outbound Binding und das erste Event, das in der EMIS-Queue landet.

Wer bereits eine ähnliche Implementierung mit dem Standalone Event Mesh kennt: Der technische Pfad auf S/4-Seite ist identisch. Was sich ändert, ist ausschließlich die BTP-Seite - EMIS statt separater Event-Mesh-Subscription, alles in einer IS-Oberfläche.

Weiterführende Quellen