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 (öffnet in neuem Tab). Dieser Beitrag beschreibt die vier Anzeigen, die zusammen jeden Fehler eingrenzen, und die Reihenfolge, in der sie gelesen werden.

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.

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

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.

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

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

Der AMQP-Receiver-Adapter (öffnet in neuem Tab) 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.