SAP Event Mesh auf der BTP: Voraussetzungen, Kosten und die häufigsten Fehler

Event Mesh fehlt im Service Marketplace vieler Subaccounts, obwohl der Vertrag es abdeckt. Das ist in Projekten das häufigere Problem, denn der Aufbau des Service selbst ist an einem Tag erledigt. Aufwand entsteht vor allem bei Entitlements, Role Collections und veralteten Anleitungen, später dann im Error Handling.

SAP Event Mesh (öffnet in neuem Tab) ist der Messaging-Service der SAP Business Technology Platform. Er entkoppelt Sender und Empfänger: Ein Event wartet in einer Queue, bis ein Consumer es abholt. Dieser Beitrag ist der Überblick zu unserer sechsteiligen Serie. Was der Service macht, was Sie dafür benötigen und was er kostet, erfahren Sie in diesem Beitrag; die Details stehen in den einzelnen Teilen, verlinkt am Ende.

Ohne Event Mesh schreibt ein Integration Flow die Daten direkt ins Zielsystem. Ist SAP gerade nicht erreichbar oder der Flow nicht aktiv, geht das Event verloren. Das Quellsystem erhält einen Fehler, der Datensatz kommt nie an.

Mit Event Mesh dazwischen nimmt ein erster Flow das Event entgegen und legt es in eine Queue. Ein zweiter Flow holt es dort ab und schreibt es nach SAP. Die beiden kennen sich nicht, verbunden sind sie nur über den Namen der Queue. Das bedeutet: Ist der Empfänger deaktiviert, wenn ein Event ausgelöst wird, erhält das Quellsystem trotzdem eine positive Rückmeldung. Sobald der Empfänger läuft, wird der Datensatz in SAP angelegt.

Publiziert wird auf ein Topic, das ist die Adresse, an die ein Event geschickt wird. Gespeichert wird in der Queue, die das Topic über eine Subscription abonniert. Das Topic selbst speichert nichts: Wird darauf publiziert, ohne dass eine Queue abonniert hat, wird das Event sofort verworfen. Die Entkopplung, um die es hier geht, ist deshalb eine Eigenschaft der Queue. Teil 2 beschreibt, wie die drei zusammenspielen.

Wir empfehlen Event Mesh in praktisch jedem Integrationsprojekt, auch in kleinen, weil es die Integration skalierbar macht, und zwar in vier Richtungen.

Sie können den Empfänger umbauen, neu deployen oder ersetzen, während Events weiter eintreffen und warten; ein Wartungsfenster im Zielsystem führt nicht zu Datenverlust. Ein Event kann außerdem mehrere Empfänger bedienen: Kommt später ein Reporting, ein Archiv oder ein zweites Zielsystem dazu, hängen Sie eine weitere Queue an, ohne die sendende Seite anzufassen. Lastspitzen puffert die Queue, der Empfänger arbeitet in seinem eigenen Tempo, und ein Massenlauf im Quellsystem überlastet das Zielsystem nicht. Scheitert die Verarbeitung eines Events, betrifft das nur dieses Event; die übrigen werden weiter verarbeitet.

Dafür steigt die Komplexität: zwei Flows und eine Queue statt einer Verbindung. Wir halten das für vertretbar, weil sich keine dieser vier Eigenschaften nachträglich in eine direkte Verbindung einbauen lässt.

Unter dem Namen Event Mesh führt SAP drei verschiedene Produkte. Werden sie verwechselt, sucht man im Marketplace nach einem Service, der gar nicht lizenziert ist.

SAP Event Mesh (Standalone) ist der klassische BTP-Service. Er wird als eigener Service im Subaccount gebucht und hat ein eigenes Entitlement. Auf ihn beziehen sich die meisten älteren Anleitungen.

Event Mesh als Capability der SAP Integration Suite ist technisch derselbe Service, wird aber innerhalb der Integration Suite aktiviert statt separat gebucht. Rollen und Berechtigungen laufen dadurch über einen anderen Weg.

SAP Integration Suite, advanced event mesh ist ein eigenständiges Produkt auf Basis von Solace PubSub+. Es bringt eine eigene Konsole, ein eigenes Event Portal und deutlich größere Kapazität mit. SAP positioniert diese Variante für Szenarien mit hohem Eventvolumen, etwa verteilte Lieferketten oder Point-of-Sale (SAP-Blog (öffnet in neuem Tab)).

Ein kommerzieller BTP-Account ist Pflicht. Das Trial-Angebot hat SAP im Februar 2023 eingestellt (SAP-Ankündigung (öffnet in neuem Tab)), der Plan lite ist laut SAP Help Portal (öffnet in neuem Tab) abgekündigt. Ältere Anleitungen, die auf diesen Plänen aufbauen, enden deshalb mit einer Fehlermeldung.

Darüber hinaus benötigen Sie:

• ein Entitlement für Event Mesh im Global Account
• eine unterstützte Region
• eine aktivierte Cloud-Foundry-Umgebung im Subaccount
• die passenden Role Collections für Ihren Benutzer

Der häufigste Grund, warum Event Mesh im Service Marketplace fehlt, ist ein fehlendes Entitlement. Der Service Marketplace eines Subaccounts zeigt nur die Services, die dem Subaccount zuvor über ein Entitlement zugewiesen wurden. Das Entitlement wird im Global Account vergeben; erst danach ist Event Mesh im Subaccount sichtbar und kann dort als Service-Instanz angelegt werden. Fehlt ein Service im Marketplace, prüfen Sie deshalb zuerst die Entitlements im Global Account. Das gilt für alle BTP-Services.

SAP verkauft Event Mesh nicht als Einzellizenz, sondern rechnet es über das Verbrauchsmodell der BTP ab. Sie zahlen aus dem Guthaben, das über den Vertrag verfügbar ist. Abrechnungsgröße sind Resource Units, eine Einheit, die Verbindungen, Queues und Speicher bündelt. Ein Subaccount bekommt standardmäßig 200 davon (SAP Help Portal, Technical Constraints (öffnet in neuem Tab)), eine einzelne Instanz belegt voreingestellt 10 (SAP Help Portal, Instanz anlegen (öffnet in neuem Tab)). Für eine mittelgroße Integration ist das ausreichend.

Auf S/4HANA-Seite ist Enterprise Event Enablement (öffnet in neuem Tab) Bestandteil des Systems; das Add-on für eigene Events hat SAP für Kunden mit gültigem Supportvertrag ohne Zusatzkosten freigegeben (öffnet in neuem Tab). Eine andere Preisklasse ist advanced event mesh, das pro Event Broker und Laufzeitstunde abgerechnet wird (SAP Discovery Center (öffnet in neuem Tab)).

Belastbare Zahlen liefert der Estimator im SAP Discovery Center (öffnet in neuem Tab). Rechnen Sie dort mit der Zahl der Instanzen und Verbindungen statt mit der Zahl der Nachrichten.

Der Aufbau selbst besteht aus vier Schritten: Entitlement zuweisen, Role Collections vergeben, Service-Instanz anlegen, Queue anlegen. Mehr Zeit kosten die Entscheidungen zur Verarbeitung der Events. Sie sind Thema der einzelnen Teile der Serie; die Reihenfolge folgt dem Aufbau einer Integration:

• Ingress-Flow (Teil 1): Wie ein Flow ein Event annimmt und in die Queue legt, welche Trigger in Frage kommen und warum in diesem Flow keine Fachlogik stehen sollte.
• Topics, Queues und Subscriptions (Teil 2): Was gespeichert und was nur weitergeleitet wird, in welcher Reihenfolge die Objekte angelegt werden und welche Wildcards in Subscriptions erlaubt sind.
• Diagnose (Teil 3): Entkoppelte Integrationen haben keine durchgehende Fehlermeldung. Welche Anzeige im Cockpit was aussagt und wie ein Fehler eingegrenzt wird.
• Error Handling (Teil 4): Was passiert, wenn ein Event nicht verarbeitet werden kann, und wie verhindert wird, dass es die übrigen Events blockiert.
• S/4HANA als Event Producer (Teil 5): Wie Enterprise Event Enablement eingerichtet wird und warum Business Events nur den Schlüssel des geänderten Objekts enthalten.
• Bidirektionaler Sync (Teil 6): Wie zwei Systeme in beide Richtungen synchronisiert werden, ohne dass ein Event eine Endlosschleife auslöst.

Event Mesh ist für den klassischen SAP-Fall ausgelegt. Die maximale Nachrichtengröße liegt bei 1 MB, der maximale Durchsatz je Subaccount bei 250 KB/s (SAP Help Portal, Technical Constraints (öffnet in neuem Tab)). Für sehr große Nachrichten, Broker im eigenen Rechenzentrum oder ein Netz über mehrere Clouds wird advanced event mesh benötigt.

Auch die Business Events aus S/4HANA reichen allein nicht aus. Sie enthalten im Wesentlichen den Schlüssel des geänderten Objekts; die geänderten Daten liest Ihr Empfänger weiterhin per OData nach.