Der Ingress-Flow: vom Event in die Event-Mesh-Queue

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.

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.

In der SAP Integration Suite bezeichnet der Sender-Adapter (öffnet in neuem Tab) 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.

Der Ausgang ist bei jedem Ingress-Flow gleich. Der AMQP-Receiver-Adapter (öffnet in neuem Tab) 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 (öffnet in neuem Tab)).

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 (öffnet in neuem Tab), 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.

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

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.

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 (öffnet in neuem Tab). Der Nachweis ist deshalb der Zähler der Queue im Event Mesh Cockpit.

1. Consumer-Flow undeployen. Solange er läuft, holt er jede Nachricht sofort ab, und der Zähler der Queue bleibt auf null.
2. 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 (öffnet in neuem Tab) prüft dagegen nur Queue und Subscription, nicht den Flow.
3. 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.