
Topics, Queues und Subscriptions in SAP Event Mesh
Topic, Queue und Subscription sind drei verschiedene Objekte. Was jedes davon tut, in welcher Reihenfolge sie angelegt werden, wie der Namespace in die Namen eingeht und welche Wildcards in Subscriptions erlaubt sind.
Eine Nachricht wird publiziert, die Queue bleibt leer, und der Consumer findet die Queue nicht, die im Cockpit angelegt wurde. Beide Fehler haben dieselbe Ursache: Topic, Queue und Subscription sind drei verschiedene Objekte, und die Reihenfolge, in der sie angelegt werden, entscheidet darüber, ob eine Nachricht gespeichert oder verworfen wird. Dieser Beitrag erklärt, was jedes der drei Objekte tut, wie der Namespace in die Namen eingeht und welche Wildcards in Subscriptions erlaubt sind.
Was Topic, Queue und Subscription tun
Ein Topic ist die Adresse, an die publiziert wird. Es wird nicht angelegt; es existiert, sobald eine Nachricht darauf gesendet wird, und es speichert nichts. Laut SAP müssen Abonnenten eines Topics aktiv sein, wenn die Nachricht gesendet wird, sonst geht sie verloren (SAP-Tutorial zu Queues und Queue Subscriptions (öffnet in neuem Tab)).
Eine Queue wird im Event Mesh Cockpit angelegt, hat einen Namen und speichert Nachrichten, bis ein Consumer sie abholt. Alles, was mit Zuverlässigkeit zu tun hat, hängt an der Queue: Warten, Redelivery, Dead Message Queue.
Eine Subscription verbindet beide. Sie wird an der Queue gepflegt und legt fest, welche Topics die Queue einsammelt. Mehrere Queues können dasselbe Topic abonnieren; jede erhält dann eine Kopie der Nachricht.
Daraus folgt der Grund für die leere Queue: Wird auf ein Topic publiziert, für das keine Queue eine Subscription hat, wird die Nachricht verworfen. Sie erreicht auch nicht die Dead Message Queue, denn die gehört zu einer Queue, und eine Queue war nicht beteiligt.
Reihenfolge beim Anlegen
Weil das Topic nichts speichert, muss die Queue mit ihrer Subscription existieren, bevor die erste Nachricht publiziert wird:
- Queue im Event Mesh Cockpit anlegen
- Subscription auf das Topic an dieser Queue anlegen
- Publizieren
Beim Testen ist die umgekehrte Reihenfolge der häufigste Fehler. Wird zuerst eine Testnachricht publiziert und danach die Subscription angelegt, ist die Nachricht ohne Fehlermeldung verloren; die Suche nach der Ursache beginnt dann im Adapter oder in den Berechtigungen, wo kein Fehler liegt. Das gilt auch für jeden später ergänzten Empfänger: Er erhält Nachrichten erst ab dem Zeitpunkt, an dem seine Subscription besteht.
Der Namespace ist Teil jedes Namens
Jede Service-Instanz von Event Mesh ist ein Message Client mit einem Namespace, der im Service Descriptor festgelegt wird. Der Namespace ist ein dreiteiliges Präfix wie acme/crm/prod, und laut SAP tragen alle Queues und Topics des Message Clients dieses Präfix (SAP-Antwort zum Service Descriptor (öffnet in neuem Tab)). Er hat zwei Funktionen: Er macht Namen im Subaccount eindeutig, und er ist die Berechtigungsgrenze, denn die Regeln im Service Descriptor legen fest, auf welche Namen der Client publizieren und lesen darf. Der Reiter View Rules im Cockpit zeigt diese Regeln je Instanz (SAP-Tutorial (öffnet in neuem Tab)).
Das Präfix wird nicht automatisch ergänzt. Beim Anlegen einer Queue im Dialog Create Queue bleibt das Feld Namespace standardmäßig auf None; die Queue wird dann ohne Präfix angelegt und kann von keinem Client dieses Namespace verwendet werden. Das Infofeld Final Queue Name would be zeigt den vollständigen Namen, den der Consumer später eintragen muss. Umbenennen ist nicht vorgesehen; eine Queue mit falschem Namespace wird gelöscht und neu angelegt.
Wir empfehlen, Entwicklung, Test und Produktion über getrennte Namespaces zu trennen statt später im Consumer zu filtern, und Queues nach dem Event zu benennen, das sie einsammeln, nicht nach dem heutigen Empfänger. Ein Namespace, der System, Umgebung und Zweck enthält, bleibt ohne Nachschlagen lesbar.
Wildcards in Subscriptions
Ein Topic-Name besteht aus Segmenten, getrennt durch Schrägstriche, etwa acme/crm/prod/customer/created. Eine Subscription muss nicht jedes Topic einzeln abonnieren; sie kann Wildcards enthalten. Die für Ihre Instanz gültige Syntax zeigt der Subscription-Dialog im Event Mesh Cockpit an. In Event Mesh sind das zwei Zeichen:
+ersetzt genau ein Segment.acme/crm/prod/customer/+erfasstcreated,updatedunddeletedmit einer Subscription.*steht am Ende für alle folgenden Segmente.acme/crm/prod/*erfasst alles unterhalb dieses Pfades, unabhängig von der Tiefe.
SAP Integration Suite, advanced event mesh verwendet eine andere Syntax: dort steht * für eine Ebene und > am Ende für alle folgenden Ebenen (SAP-Tutorial zu advanced event mesh (öffnet in neuem Tab)). Wer Subscriptions aus advanced event mesh oder aus MQTT (#) übernimmt, erhält in Event Mesh keine Treffer.
Weiterlesen
Passende Beiträge
SAP Event Mesh auf der BTP: Voraussetzungen, Kosten und die häufigsten Fehler
Björn OstermannThema: SAP ConsultingDer Aufbau von Event Mesh ist an einem Tag erledigt. Aufwand entsteht bei Entitlements, Role Collections und der Eventverarbeitung. Was der Service macht, was Sie dafür benötigen und was er kostet, erfahren Sie in diesem Beitrag.
Diagnose in SAP Event Mesh: welche Anzeige was aussagt
Björn OstermannThema: SAP ConsultingBei entkoppelten Integrationen gibt es keine durchgehende Fehlermeldung. Welche vier Anzeigen in Event Mesh und Integration Suite was aussagen, wie ein Test ohne Quellsystem funktioniert und wie der Vergleich der Zähler die Suchrichtung festlegt.
Der Ingress-Flow: vom Event in die Event-Mesh-Queue
Björn OstermannThema: SAP ConsultingDer Ingress-Flow nimmt ein Event an und publiziert es unverändert in eine Queue. Welche Aufgabe er hat, welcher Sender-Adapter zum Quellsystem passt, wie der AMQP-Receiver-Adapter konfiguriert wird und wie Sie prüfen, ob ein Event in der Queue ankommt.
Termin buchen
Ereignisgesteuerte Integration geplant?
Sprechen Sie uns an. Wir unterstützen bei Aufbau, Eventverarbeitung und Error Handling.
- 30 Minuten
- unverbindlich