Diagnose in SAP Event Mesh: welche Anzeige was aussagt

Bei einer entkoppelten Integration gibt es keine durchgehende Fehlermeldung. Der Ingress-Flow meldet, dass er publiziert hat, der Consumer-Flow meldet, dass er nichts abgeholt hat, und zwischen beiden steht Event Mesh, das nur seine eigenen Zähler kennt. Cloud Integration überwacht nur den Integration Flow; Queues und Nachrichten werden ausschließlich mit den Werkzeugen des Message Brokers überwacht. Dieser Beitrag beschreibt die vier Anzeigen, die zusammen jeden Fehler eingrenzen, und die Reihenfolge, in der sie gelesen werden.

Vier Anzeigen, vier Aussagen

Jede der vier Anzeigen beantwortet eine andere Frage, und keine beantwortet alle:

Übersicht im Event Mesh Cockpit. Zwei Kurven: publizierte und konsumierte Nachrichten über die Zeit. Sie zeigt, ob der Broker eine Nachricht angenommen hat.
Message Count der Queue. Die Zahl der wartenden Nachrichten, nicht der insgesamt verarbeiteten. Bei einem aktiven Consumer steht der Wert praktisch immer auf null, auch wenn tausende Nachrichten fehlerfrei verarbeitet wurden.
Consume Messages. Holt eine wartende Nachricht aus der Queue und zeigt sie an. Damit wird geprüft, ob eine Nachricht ankommt und in welchem Format.
Monitoring der Integration Suite. Das Verarbeitungsprotokoll der Flows und, bei konsumierenden Flows, die Polling Information mit der vollständigen Adresse, an der der Flow hängt.

Vier Anzeigen in Event Mesh und Integration Suite und die Frage, die jede beantwortet — Vier Anzeigen und die Frage, die jede beantwortet.

Testen ohne Quellsystem

Für den Test der Kette wird kein Quellsystem benötigt. Über Test Messaging im Event Mesh Cockpit oder über die REST-API von Event Mesh lässt sich eine Nachricht direkt publizieren. Entscheidend ist das Ziel:

Wird auf das Topic publiziert, nimmt die Nachricht denselben Weg wie im Betrieb: Namespace-Regeln, Subscription, Queue. Kommt sie nicht an, stimmen Subscription oder Namespace nicht.
Wird direkt auf die Queue publiziert, wird die Subscription umgangen. Der Test zeigt dann nur, dass die Queue existiert und beschreibbar ist; über das Routing sagt er nichts.

Vor dem Test wird der Consumer-Flow undeployed. Solange er läuft, holt er jede Testnachricht sofort ab, und der Message Count bleibt auf null.

Testnachricht auf das Topic prüft das Routing, auf die Queue nur die Queue — Test auf das Topic prüft das Routing, Test auf die Queue nur die Queue.

Nie angekommen oder angenommen und verworfen

Meldet der Flow Erfolg und bleibt die Queue leer, trennt der Vergleich der beiden Kurven in der Cockpit-Übersicht zwei Suchrichtungen:

Publizierte Rate steigt, konsumierte Rate bleibt flach, Queue leer. Der Broker hat die Nachricht angenommen und verworfen, weil keine Queue eine passende Subscription hatte. Die Ursache liegt in der Adressierung: Topic-Name, Namespace oder Subscription. Berechtigung und Netzwerk sind ausgeschlossen.
Keine Kurve steigt. Der Broker hat nichts gesehen. Die Ursache liegt vor Event Mesh: im Flow, im Adapter oder in den Zugangsdaten.

Publizierte und konsumierte Rate: angenommen und verworfen oder nie angekommen — Zwei Kurvenbilder, zwei Suchrichtungen.

Fehlermeldungen nennen die Schicht

Erscheint eine Fehlermeldung, nennt sie nicht die Ursache, aber die Schicht, in der zu suchen ist.

Fehlermeldung, Schicht, nächster Schritt

Meldung	Schicht	Nächster Schritt
401 Unauthorized	Zugangsdaten	Token direkt am Token Endpoint anfordern; Client ID und Secret aus dem Service Key prüfen
amqp:unauthorized-access	Berechtigung im Namespace	Publiziert oder gelesen wird außerhalb der Regeln des Service Descriptors; Namespace-Präfix und View Rules prüfen
amqp:not-allowed	Objekt außerhalb der Berechtigung	Meist eine Queue ohne Namespace; Final Queue Name im Cockpit mit dem Adapter vergleichen
amqp:not-found	Ziel existiert nicht	Polling Information im Monitoring mit dem Namen im Cockpit vergleichen; häufig ein Topic-Name im Feld Queue
Flow completed, Queue leer	Adressierung	Kurven in der Cockpit-Übersicht vergleichen; bei steigender publizierter Rate Subscription und Topic-Name prüfen

Zwei Prüfungen gehen über die Tabelle hinaus. Bei einem 401 wird ein Token direkt am Token Endpoint aus dem Service Key angefordert, wie im SAP-Tutorial beschrieben; funktioniert das, sind die Zugangsdaten in Ordnung und der Fehler liegt in der Adapterkonfiguration. Bei amqp:not-found zeigt die Polling Information im Monitoring die vollständige Adresse, an der der konsumierende Flow hängt; der Vergleich mit dem Namen im Cockpit macht Tippfehler und fehlenden Namespace sichtbar, ohne den Adapter zu öffnen.

Bei einem Empfänger direkt in die Queue publizieren

Der AMQP-Receiver-Adapter kann an eine Queue oder an ein Topic senden. Wir empfehlen, bei genau einem Empfänger direkt in die Queue zu publizieren. Das Topic-Routing wird dann umgangen, die Zustellung ist eindeutig, und ein Fehler in Subscription oder Namespace kann keine Nachricht mehr verwerfen. Die Entkopplung bleibt erhalten, weil sie an der Queue hängt: Redelivery, Dead Message Queue und das Abschalten des Empfängers funktionieren unverändert.

Erst wenn mehrere Empfänger dieselbe Nachricht benötigen, ist das Topic erforderlich. Dann gehören Topic-Schema und Subscriptions zu den Dingen, die vor dem ersten Deployment festgelegt werden.