Diagnosis in SAP Event Mesh: which view tells you what

A decoupled integration has no end-to-end error message. The ingress flow reports that it published, the consumer flow reports that it found nothing to pick up, and in between sits Event Mesh, which only knows its own counters. Cloud Integration monitors the integration flow only; queues and messages can only be monitored with the tools of the message broker. This article describes the four views that together let you narrow down any fault, and the order in which to read them.

Each of the four views answers a different question, and none of them answers all four:

• The overview in the Event Mesh cockpit. Two curves, published and consumed messages over time. It tells you whether the broker accepted a message at all.
• The queue's message count. The number of messages currently waiting, not the total processed. With an active consumer it is practically always zero, even after thousands of messages have gone through without a problem.
• Consume Messages. Pulls a waiting message from the queue and shows it to you. That tells you whether a message arrived and in which format.
• Monitoring in Integration Suite. The processing log of your flows and, for consuming flows, the polling information with the full address the flow is attached to.

You don't need a source system to test the chain. Test Messaging in the Event Mesh cockpit or the Event Mesh REST API lets you publish a message directly. What matters is where you publish it:

• Publish to the topic, and the message takes the same route as in production: namespace rules, subscription, queue. If it doesn't arrive, the subscription or the namespace is wrong.
• Publish straight to the queue, and you bypass the subscription. The test then only shows that the queue exists and is writable; it says nothing about routing.

Undeploy the consumer flow before testing. While it runs, it picks up every test message immediately and the message count never moves.

If the flow reports success and the queue stays empty, comparing the two curves in the cockpit overview tells you where to look:

• Published rate rises, consumed rate stays flat, queue empty. The broker accepted the message and discarded it because no queue had a matching subscription. The fault is in the addressing: topic name, namespace or subscription. Authorization and network are ruled out.
• Neither curve moves. The broker never saw the message. The fault is upstream of Event Mesh: in the flow, the adapter or the credentials.

When you do get an error message, it doesn't name the cause, but it does name the layer to look in.

Two checks go beyond the table. For a 401, request a token directly from the token endpoint in the service key, as described in the SAP tutorial; if that works, the credentials are fine and the fault is in the adapter configuration. For amqp:not-found, the polling information in monitoring shows the full address the consuming flow is attached to; compare it with the name in the cockpit and a typo or a missing namespace becomes obvious without opening the adapter.

The AMQP receiver adapter can send to a queue or to a topic. We recommend publishing straight to the queue whenever there is exactly one receiver. That bypasses topic routing, delivery is unambiguous, and a wrong subscription or namespace can no longer discard a message. Decoupling is unaffected, because it comes from the queue: redelivery, the dead message queue and switching the receiver off all work as before.

Only when several receivers need the same message do you need the topic. In that case, the topic scheme and the subscriptions belong on the list of things to settle before the first deployment.