Alle Beiträge
Integration

S/4HANA Events mit EMIS, Teil 2: EMIS auf der BTP einrichten

In Teil 1 haben wir Konzepte, Architekturschichten und die Protokollwahl besprochen. Dieser Teil richtet die BTP-Seite ein, bevor in Teil 3 das S/4HANA-System an die Reihe kommt. Am Ende steht eine empfangsbereite EMIS-Instanz: Capability aktiviert, Message Client konfiguriert, Queue angelegt, Topic-Subscription gesetzt.

Voraussetzungen

  • SAP Integration Suite Standard- oder Premium-Edition (EMIS ist nicht im Free Tier und nicht in Trial-Accounts verfügbar)
  • Rolle Integration_Provisioner für die Capability-Aktivierung
  • Rolle EventMeshManageBroker (enthalten in der Role Collection EventMeshAdmin) für die Broker-Initiierung
  • Subaccount mit aktiviertem Cloud Foundry, darin ein Space
  • Entitlement SAP Integration Suite, Event Mesh mit Plan message-client im Subaccount

Falls das Entitlement fehlt, muss es zunächst im Subaccount unter "Entitlements" ergänzt werden. Eine Schritt-für-Schritt-Anleitung von SAP dazu findet sich in der Enable-Now-Übung zu Entitlement und Capability.

Wer die grundlegenden Event-Mesh-Konzepte nochmal nachlesen möchte: das SAP-Tutorial Learn Messaging Concepts gibt einen guten Überblick.

Schritt 1: Capability aktivieren und Message Broker initiieren

Im Integration Suite Launchpad unter "Manage Capabilities" (beim Erstaufruf "Add Capabilities") den Haken bei "Manage Business Events" setzen. Das entspricht der Event-Mesh-Capability. Nach "Activate" erscheint die EMIS-Kachel auf der Startseite.

EMIS-Kachel im SAP Integration Suite Launchpad nach der Capability-Aktivierung
Die EMIS-Kachel im Integration Suite Launchpad nach erfolgreicher Aktivierung der Capability „Manage Business Events".

Wichtig: Die Capability-Aktivierung allein reicht nicht. Beim ersten Öffnen der EMIS-Capability erscheint ein Einrichtungsbildschirm mit den Broker-Spezifikationen (Spool-Größe, max. Nachrichtengröße usw.). Hier muss einmalig "Activate" geklickt werden, um den Message Broker zu starten. Das ist eine One-Time-Activity pro EMIS-Instanz. Ohne sie lassen sich weder Queues noch Message Clients anlegen.

Für diesen Schritt wird die Rolle EventMeshManageBroker benötigt, die Teil der Role Collection EventMeshAdmin ist. Fehlt sie, zeigt die EMIS-Kachel keine Buttons, und in der IS-Navigation erscheinen keine Event-Mesh-Einträge.

Kurze Konzeptpause: drei Objekte, ein Zweck

Wer zum ersten Mal mit EMIS arbeitet, begegnet drei Begriffen, die eng zusammengehören:

Message Client ist das Verbindungsobjekt zwischen einem Sender oder Empfänger und dem EMIS-Broker. Jede Anwendung, die Events schickt oder empfängt, bekommt ihren eigenen Message Client mit eigenem Namespace. Der Namespace folgt der Konvention <orgname>/<clientname>/<uniqueID> (genau 3 Segmente, je max. 24 Zeichen), zum Beispiel myorg/s4h/01. Er kennzeichnet den eigenen Adressraum im Broker.

Queue ist der persistente Speicher für Nachrichten. Sie hält Events vor, bis ein Consumer sie abholt, und übersteht kurze Ausfälle auf Consumer-Seite. Ohne Queue gehen Events verloren, wenn gerade kein Consumer aktiv ist.

Topic-Subscription verknüpft ein Topic-Pattern mit der Queue. S/4HANA veröffentlicht Events auf Topics wie myorg/s4h/01/ce/sap/s4/beh/businesspartner/v1/BusinessPartner/Created. Das Präfix ce/ kommt vom CloudEvents-Standard. Die Topic-Subscription mit dem Pattern myorg/s4h/01/* leitet alles unter diesem Pfad in die Queue. Ohne diese Verknüpfung landen Events im Broker, aber niemand sammelt sie auf.

Das folgende Diagramm zeigt, wie diese drei Objekte auf der BTP-Seite zusammenspielen — eine Detailansicht der EMIS-Schicht aus dem Teil-1-Architekturüberblick:

Detaildiagramm der BTP-Seite: Message Client mit Namespace-Konfiguration verknüpft Queue und Topic-Subscription im EMIS-Broker
BTP-seitiger Aufbau im Detail: Message Client, Queue und Topic-Subscription bilden zusammen den empfangsbereiten EMIS-Broker. Eigene Darstellung auf Basis der SAP-Dokumentation.

Schritt 2: Message Client anlegen

Der Message Client wird nicht in der Integration Suite UI, sondern im BTP Cockpit angelegt: Subaccount › Services › Instances › Create.

Im Dialog:

  • Service: SAP Integration Suite, Event Mesh
  • Plan: message-client
  • Instance-Name: frei wählbar, z.B. cfSpace-emis-client

Der nächste Schritt fragt nach optionalen JSON-Parametern. Hier kommt der Service Descriptor ins Spiel. Ohne ihn kann der Message Client weder senden noch empfangen, weil keine Zugriffsregeln hinterlegt sind:

{
  "namespace": "myorg/s4h/01",
  "rules": {
    "topicRules": {
      "publishFilter": ["${namespace}/*"],
      "subscribeFilter": ["${namespace}/*"]
    },
    "queueRules": {
      "publishFilter": ["${namespace}/*"],
      "subscribeFilter": ["${namespace}/*"]
    }
  }
}

Hinweise zu den Feldern (vollständige Syntax in der Service Descriptor Syntax-Doku):

  • namespace: Legt den Namensraum fest. Konvention: <orgname>/<clientname>/<uniqueID>, genau 3 Segmente.
  • rules.topicRules.publishFilter: Auf welche Topics darf der Client publizieren? Laut SAP-Empfehlung: immer im eigenen Namespace bleiben, also ${namespace}/....
  • rules.topicRules.subscribeFilter: Welche Topics darf der Client konsumieren?
  • rules.queueRules: Gleiche Logik für direkte Queue-Operationen. SAP empfiehlt, auf Topics statt direkt auf Queues zu publizieren.
  • ${namespace} ist ein Platzhalter, der beim Anlegen durch den konfigurierten Namespace ersetzt wird.

Nach dem Speichern erscheint die Service Instance in der Cockpit-Liste und der Message Client in der Integration Suite UI unter Configure › Event Mesh im Tab Overview.

Schritt 3: Queue anlegen

In der Integration Suite UI unter Configure › Event Mesh, Tab Queues, auf "Create" klicken.

Name: Frei wählbar, max. 164 Zeichen. Erlaubt sind Buchstaben, Zahlen, _, ., - sowie / als Segment-Trenner. Empfehlenswert ist ein sprechender Name wie s4h-businesspartner-events oder einer, der sich am Topic orientiert, z.B. sap/s4/beh/businesspartner/v1/BusinessPartner.

Access Type: Für die meisten Szenarien ist NON EXCLUSIVE richtig: mehrere Consumer teilen die Queue im Round-Robin-Verfahren. EXCLUSIVE reserviert die Queue für genau einen Consumer.

Properties, die einen Blick wert sind:

Eigenschaft Default / Max Wann anpassen?
Queue Size 1,5 GB / 1,5 GB Bei hohem Event-Volumen Monitoring einplanen
Message Size 1 MB / 1 MB Fix in EMIS; größere Payloads müssen vor dem Senden aufgeteilt werden
Max Unacknowledged Messages konfigurierbar Verhindert, dass ein langsamer Consumer die Queue blockiert
Max Redelivery Count 0 / 255 0 = unbegrenzte Wiederversuche; sinnvoll in Kombination mit Dead Message Queue
Max Time-to-Live 7 Tage / 7 Tage Nach Ablauf werden nicht konsumierte Nachrichten gelöscht

Dead Message Queue (DMQ): Eine separate Queue, in die Nachrichten wandern, die den Redelivery-Count überschritten haben oder deren TTL abgelaufen ist. Die DMQ muss zuerst als eigene Queue angelegt werden, bevor sie hier auswählbar ist. Für produktive Szenarien empfohlen.

Schritt 4: Topic-Subscription anlegen

In der Queue-Detailansicht den Tab Subscriptions öffnen und "Create" klicken. Hier wird das Topic-Pattern eingegeben, dessen eingehende Nachrichten in diese Queue geleitet werden sollen.

Für alle Business-Partner-Events:

myorg/s4h/01/ce/sap/s4/beh/businesspartner/v1/BusinessPartner/*

Das * am Ende fängt alle Subtypen (Created, Changed, ...) unter diesem Pfad. Ein breiteres Pattern, das alle S/4-Events des Clients einschließt:

myorg/s4h/01/*

Der Namespace-Teil (myorg/s4h/01) muss zum Namespace des Message Clients passen. Das ce/-Segment ist der CloudEvents-Präfix, den S/4HANA automatisch einfügt.

Der Topic-String muss mindestens zwei Segmente haben und darf maximal 150 Zeichen und 20 Segmente lang sein.

Schritt 5: Smoke-Test ohne S/4HANA

Bevor S/4HANA ins Spiel kommt, lässt sich der Setup direkt in der UI testen.

In der IS-Navigation unter Test › Event Mesh den angelegten EMIS-Client auswählen, dann die Queue oder ein Topic aus dem abonnierten Bereich wählen und eine einfache JSON-Payload senden.

Unter Monitor › Event Mesh ist die Nachricht anschließend zu sehen. Erscheint sie dort, sind Capability, Message Client, Queue und Topic-Subscription korrekt verdrahtet.

Kommt keine Nachricht an, lohnt sich ein Blick auf den Namespace im Service Descriptor und darauf, ob das Topic-Pattern in der Subscription den verwendeten Topic-String tatsächlich abdeckt.

Was kommt in Teil 3?

Die BTP-Seite steht. Teil 3 kümmert sich um das S/4HANA PCE-System: Netzwerk-Freischaltung für den ausgehenden HTTPS-Verkehr, Daemon-User, Rollen und Zertifikat-Import via STRUST. Das sind die Vorarbeiten, bevor der Channel in /n/IWXBE/CONFIG konfiguriert werden kann. Teil 4 deckt dann das Channel-Setup in /n/IWXBE/CONFIG ab, inklusive des Service Keys und eines bekannten Caveats (SAP Note 3461547).

Quellen