S/4HANA publiziert Events über Enterprise Event Enablement ohne eigene Entwicklung. Voraussetzungen und Rollen, Channel über Service Key, Outbound Bindings, Test mit Demo-Event und Event Monitor, und warum ein Business Event nur den Schlüssel enthält.
Damit S/4HANA von sich aus meldet, wenn sich ein Geschäftspartner, ein Auftrag oder ein Produkt ändert, wird keine Erweiterung, kein BAdI und keine Zeile ABAP benötigt. Die Komponente dafür ist Enterprise Event Enablement, Bestandteil von S/4HANA. Benötigt werden eine funktionierende Ereigniserzeugung im System, ein Channel zu Event Mesh und die Freigabe der Events, die das System verlassen sollen. Dieser Beitrag beschreibt Voraussetzungen, Einrichtung, Test und die Eigenschaft der Events, die die Architektur des Empfängers bestimmt.
Enterprise Event Enablement, im System als Komponente IWXBE geführt, publiziert die Events. Erzeugt werden sie eine Ebene darunter im Business Event Handling, das auf dem Workflow-Customizing des Systems aufsetzt. Laut SAP wird das Customizing für Enterprise Event Enablement im On-premise-System über SPRO unter SAP NetWeaver gepflegt (SAP-Blog zur Fehlersuche).
Für die Fehlersuche ist diese Trennung entscheidend: Ein Event, das nie erzeugt wurde, kann nicht publiziert werden, und dann hilft keine Channel-Konfiguration. In S/4HANA Cloud ist dieser Stapel vorkonfiguriert; in On-premise-Systemen und in der Private Edition ist er zu prüfen, besonders in Systemen, die über mehrere Releases hochgezogen wurden.
/IWXBE/CONFIG, die Transaktion existiere nicht, fehlt die Komponente; meldet es fehlende Berechtigung, zeigt SU53 das fehlende Berechtigungsobjekt.| Rolle | Zweck |
|---|---|
| SAP_IWXBE_RT_XBE_ADM | Administration und Channel-Konfiguration |
| SAP_IWXBE_RT_XBE_BUSI | Fachliche Nutzung und Bindings |
| SAP_IWXBE_RT_XBE_MDT | Metadaten und Topic-Suchhilfe |
| SAP_IWXBE_RT_XBE_DAEMON | Daemon-Benutzer der Hintergrundprozesse des Channels |
Ein Channel ist die Verbindung zu genau einer Service-Instanz von Event Mesh. Er wird in /n/IWXBE/CONFIG über die Option via Service Key angelegt; Name und Beschreibung werden vergeben, der vollständige Service Key wird eingefügt (SAP-Tutorial). Das System erzeugt daraus die RFC-Destination und die OAuth-Konfiguration.
Nach dem Anlegen wird die erzeugte RFC-Destination in SM59 geprüft: Der Port muss im Port-Feld stehen. Steht er stattdessen in der Host-URL des Zielhosts, schlägt die Verbindungsprüfung fehl. Anschließend wird der Channel aktiviert und mit Check Connection geprüft; meldet das System, dass nicht alle Hintergrundjobs des Channels laufen, hilft laut SAP Deaktivieren und erneutes Aktivieren (SAP-Blog zur Fehlersuche).
Alle Schritte laufen im S/4HANA-System; der Service Key stammt aus dem BTP-Cockpit.
In /n/IWXBE/CONFIG via Service Key wählen, Name und Beschreibung vergeben, den vollständigen Service Key einfügen und speichern.
In SM59 prüfen, dass der Port im Port-Feld steht. Dann den Channel aktivieren und Check Connection ausführen; bei fehlenden Hintergrundjobs deaktivieren und erneut aktivieren.
Über Outbound Bindings oder /n/IWXBE/OUTBOUND_CFG die Topics freigeben, die das System publizieren soll.
Im Event Mesh Cockpit eine Queue anlegen und eine Subscription auf das freigegebene Topic setzen, damit das Event ein Ziel hat.
Ein aktiver Channel mit erfolgreicher Verbindungsprüfung sendet noch nichts. Laut SAP ist das Pflegen eines Outbound Bindings der notwendige Schritt, damit ein S/4HANA-System Events publiziert (SAP Help Portal). Bindings werden über Outbound Bindings in der Channel-Konfiguration oder direkt über /n/IWXBE/OUTBOUND_CFG gepflegt; die Suchhilfe listet alle Topics, die dieses System publizieren kann.
Die Topic-Namen folgen einem festen Muster, etwa sap/s4/beh/businesspartner/v1/BusinessPartner/Created/v1 (SAP-Tutorial): Objekt, Version und Ereignisart sind ablesbar, was das Abonnieren mit Wildcards vereinfacht. Eine Übersicht der verfügbaren Events mit Beispiel-Payload steht im SAP Business Accelerator Hub unter Events.
Wir empfehlen, nur die Events freizugeben, die ein Empfänger benötigt. Jedes Binding erzeugt dauerhaft Last, und ein später ergänztes Binding ist in wenigen Minuten gepflegt.
Der erste Test kommt ohne Geschäftsdaten aus: Über /IWXBE/EVENT_DEMO wird ein Demo-Event ausgelöst. Erscheint es in der Queue, funktioniert die Kette von der Komponente bis zur Subscription. Erst danach wird ein echtes Objekt geändert, etwa ein Geschäftspartner in BP. Kommt das Demo-Event an und das echte nicht, liegt die Ursache im Binding oder in der Ereigniserzeugung; die Verbindung ist ausgeschlossen.
Der Event Monitor (/n/IWXBE/EVENT_MONITOR) zeigt jedes Event mit Status, und aus dem Status folgt die Suchrichtung:
/n/IWXBE/ERROR_LOG und die Hintergrundjobs des Channels in SMDAEMON.
Die Events werden im CloudEvents-Format publiziert, einem herstellerneutralen Standard für Ereignisnachrichten. Der Inhalt besteht im Wesentlichen aus dem Schlüssel des geänderten Objekts und Metadaten: Der Empfänger erfährt, dass sich Geschäftspartner 1000123 geändert hat, nicht was sich geändert hat.
Der Empfänger benötigt deshalb weiterhin einen Lesezugriff per OData auf das S/4HANA-System. Ein Business Event ersetzt das Abfrageintervall durch eine Benachrichtigung; gelesen wird weiterhin, aber nur dann, wenn sich etwas geändert hat. Ein Empfänger, der ohne Rückfrage in das System auskommt, ist mit Standard-Events nicht möglich; dafür ist das Add-on für eigene Events vorgesehen, das Data Events mit Nutzdaten erzeugt.
Wir empfehlen außerdem, Entwicklung, Test und Produktion über getrennte Namespaces in Event Mesh zu trennen statt im Empfänger nach dem Quellsystem zu filtern.
Weiterlesen
Termin buchen
Sprechen Sie uns an. Wir unterstützen bei Aufbau, Eventverarbeitung und Error Handling.
Schreib uns oder buche direkt ein kurzes Meeting.
