Der Ingress-Flow in SAP Event Mesh: Aufgabe, Aufbau, Test

Eine ereignisgesteuerte Integration mit SAP Event Mesh besteht aus zwei Integration Flows. Der erste nimmt das Event an und legt es in eine Queue, der zweite holt es dort ab und schreibt es ins Zielsystem. Dieser Beitrag behandelt den ersten, den Ingress-Flow: welche Aufgabe er hat, wie er aufgebaut wird und wie Sie prüfen, ob ein Event in der Queue ankommt.

Was der Ingress-Flow macht

Der Ingress-Flow hat eine Aufgabe: ein Event annehmen und es unverändert in eine Queue publizieren. Er enthält kein Mapping, keine Anreicherung und keine Prüfung gegen das Zielsystem. Das Zielsystem kennt er nicht.

Die beiden Flows referenzieren sich nicht; verbunden sind sie nur über den Namen der Queue. Wird der Consumer-Flow undeployed, nimmt der Ingress-Flow weiter Events an, und die Queue speichert sie, bis der Consumer wieder läuft.

Ingress-Flow und Consumer-Flow, verbunden nur über den Namen der Queue — Zwei Flows, verbunden nur über den Namen der Queue.

Der Sender-Adapter richtet sich nach dem Quellsystem

In der SAP Integration Suite bezeichnet der Sender-Adapter die Seite, die den Flow auslöst, und der Receiver-Adapter die Seite, an die der Flow sendet. Sender ist also nicht das System, das die Daten besitzt, sondern das, was den Flow startet. Beim Ingress-Flow ist das die Quelle des Events, beim Consumer-Flow ist es die Queue.

Welcher Sender-Adapter passt, hängt davon ab, was das Quellsystem anbietet:

HTTPS, wenn das Quellsystem einen Webhook aufruft
Timer, wenn der Flow nach Zeitplan eine Schnittstelle abfragt
SFTP, wenn Dateien in einem Verzeichnis abgelegt werden
ProcessDirect, wenn ein anderer Integration Flow das Event liefert

Der Eingang darf sich ändern, ohne dass der Consumer-Flow angefasst wird. Ein Quellsystem, das heute Dateien ablegt und morgen einen Webhook aufruft, ändert nur den Sender-Adapter des Ingress-Flows.

Vier Sender-Adapter als Eingang, AMQP-Receiver-Adapter als Ausgang in die Queue — Vier Eingänge, ein Ausgang.

Der AMQP-Receiver-Adapter sendet an die Queue

Der Ausgang ist bei jedem Ingress-Flow gleich. Der AMQP-Receiver-Adapter sendet die Nachricht an die Queue in Event Mesh. Für Event Mesh wird der Adaptertyp AMQP WebSocket verwendet, die Anmeldung erfolgt mit OAuth2 Client Credentials (SAP Help Portal).

Die Zugangsdaten stammen aus dem Service Key der Event-Mesh-Instanz. Er enthält Host, Token Endpoint, Client ID und Client Secret; in der Integration Suite werden sie unter Security Material als OAuth2 Client Credentials hinterlegt und im Adapter referenziert.

Die Queue muss vor dem Deployment existieren. Cloud Integration legt keine Queues an; sie werden im Event Mesh Cockpit angelegt, inklusive Namespace. Der vollständige Name der Queue ist der einzige Vertrag zwischen Ingress-Flow und Consumer-Flow, deshalb sollte er das Event beschreiben und nicht den heutigen Empfänger: acme/crm/prod/customer.created bleibt gültig, wenn statt einem zwei Systeme konsumieren.

Aufbau in vier Schritten

Die Reihenfolge beginnt beim Ausgang, weil der Adapter auf eine existierende Queue und vorhandene Zugangsdaten verweist.

Vom leeren Flow zur gefüllten Queue

1.Queue anlegen

Im Event Mesh Cockpit eine Queue anlegen und den vollständigen Namen inklusive Namespace notieren. Der Consumer-Flow verwendet später exakt diesen Namen.

2.Service Key erzeugen

Für die Event-Mesh-Instanz einen Service Key erzeugen. Client ID, Client Secret und Token Endpoint in der Integration Suite unter Security Material als OAuth2 Client Credentials hinterlegen.

3.Sender- und Receiver-Adapter setzen

Den Sender-Adapter nach dem Quellsystem wählen (HTTPS, Timer, SFTP, ProcessDirect). Als Receiver-Adapter AMQP WebSocket mit den hinterlegten Credentials und der Queue als Ziel konfigurieren.

4.Deployen und mit Testnachricht prüfen

Den Flow deployen, eine Testnachricht über den Endpoint senden und im Event Mesh Cockpit prüfen, ob der Zähler der Queue auf 1 steht.

Warum keine Fachlogik in den Ingress-Flow gehört

Wir empfehlen, den Ingress-Flow auf Annahme und Publizieren zu beschränken, auch wenn ein kleines Mapping an dieser Stelle bequem wäre. Sobald der Ingress-Flow etwas über das Zielsystem weiß, ist die Entkopplung aufgehoben: Ändert sich dort ein Feld, muss der Eingang angepasst und neu deployed werden, und in dieser Zeit werden keine Events angenommen.

Liegt das Event unverändert in der Queue, kann der Consumer-Flow umgebaut, neu deployed oder durch einen zweiten ergänzt werden, während Events weiter eintreffen. Mapping, Anreicherung und Validierung gehören in den Consumer-Flow, der das Zielsystem kennt.

Zuständigkeiten von Ingress-Flow und Consumer-Flow — Was in den Ingress-Flow gehört und was in den Consumer-Flow.

Prüfen, ob ein Event in der Queue ankommt

Ein erfolgreiches Deployment zeigt, dass das Artefakt installiert ist. Ob eine Nachricht die Queue erreicht, zeigt es nicht: Cloud Integration überwacht nur den Integration Flow, Queues und Nachrichten werden ausschließlich mit den Werkzeugen des Message Brokers überwacht. Der Nachweis ist deshalb der Zähler der Queue im Event Mesh Cockpit.

Consumer-Flow undeployen. Solange er läuft, holt er jede Nachricht sofort ab, und der Zähler der Queue bleibt auf null.
Testnachricht über den Ingress-Flow senden. Den Endpoint des Flows mit einem HTTP-Werkzeug aufrufen. So durchläuft die Nachricht denselben Weg wie im Betrieb, einschließlich der Zugangsdaten im AMQP-Adapter. Ein Test über die Funktion Test Messaging im Event Mesh Cockpit oder über die REST-API von Event Mesh prüft dagegen nur Queue und Subscription, nicht den Flow.
Zähler der Queue prüfen. Steht er auf 1, funktioniert die Kette vom Eingang bis zur Queue. Bleibt er auf null, obwohl der Flow Erfolg meldet, liegt der Fehler zwischen Flow und Event Mesh, in der Regel im Adapter oder in den Zugangsdaten.

Über Consume Messages im Cockpit lässt sich die Nachricht anschließend aus der Queue lesen und das Format prüfen.