
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.
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).
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.
Weil das Topic nichts speichert, muss die Queue mit ihrer Subscription existieren, bevor die erste Nachricht publiziert wird:
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.
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). 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).
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.
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/+ erfasst created, updated und deleted mit 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). Wer Subscriptions aus advanced event mesh oder aus MQTT (#) übernimmt, erhält in Event Mesh keine Treffer.
Weiterlesen
Termin buchen
Sprechen Sie uns an. Wir unterstützen bei Aufbau, Eventverarbeitung und Error Handling.
Schreib uns oder buche direkt ein kurzes Meeting.