Your iFlow deployed successfully, the first test message went through — and then silence. Did the messages keep flowing? Did one fail at 3 AM? In production integration, message monitoring is where you spend half your operational life, and knowing exactly where to look separates a five-minute diagnosis from a five-hour one.
Where monitoring lives
The SAP Integration Suite landing page organizes capabilities into three areas, and the names tell you their job:
Design — where you build iFlows in the Web UI. Not where you monitor.
Discover — the catalog of prebuilt integration packages from SAP and partners. Not where you monitor.
Monitor — this is it. Processed messages, message logs, payloads, and error details all live under Monitor → Integrations → All Artifacts (or Message Processing Logs in older terminology).
The single most common beginner mistake is hunting through Design for runtime information. Design shows what the iFlow should do; Monitor shows what it actually did.
Key takeaway: Runtime message status lives under Monitor → Integrations, not in the Design view. Processed, failed, and in-progress messages are all inspected there.
Reading the message processing log
Each processed message gets a log entry with a status. The ones that matter:
Completed — the message flowed through all steps successfully. Green, boring, exactly what you want.
Failed — something threw an error. Click into the entry for the error details: which step failed, the exception message, and often the payload at the point of failure.
Processing — the message is currently in flight. A message stuck in Processing longer than expected usually means a downstream system isn't responding (a hung HTTP call, a locked queue).
Discarded / Cancelled — the message was intentionally dropped, often by a filter or router step. If volumes look wrong, check whether a filter condition is too aggressive.
Diagnosing a failed message
When a message fails, work through this sequence:
1. Open the failed entry and read the error at the failed step — the exception text usually names the problem (mapping error, authentication failure, HTTP 500 from the receiver).
2. Check the payload at the failure point. Mapping errors almost always trace to unexpected input data — a missing field, a wrong date format, an unescaped special character.
3. Look at the step before the failure, not just the failed step. A Content Modifier that set a wrong header two steps earlier is the real culprit more often than the step that threw.
4. Check the message attachments and headers — authentication tokens, correlation IDs, and dynamic configuration values live here.
For transient failures (a backend briefly unavailable), the retry option reprocesses the message without rebuilding anything. For data errors, fix the payload or the mapping first — retrying the same bad data just fails the same way.
Payloads and logging levels
By default, Cloud Integration logs message headers and step-level trace information, but full payload logging is controlled by the log level on the iFlow. If you can't see payload content in a failed message, the iFlow's trace/log level is likely set too low — bump it to Trace for debugging, then back down for production. Payload logging has a performance and storage cost; leaving Trace on permanently in a high-volume production iFlow is a classic operational mistake.
Proactive monitoring
Waiting for someone to notice failures is not a strategy:
Alert rules — configure alerts on failed message counts or specific error patterns so the team hears about problems before the business does.
Dashboard widgets — the Monitor overview shows message volumes and error rates at a glance. A sudden drop in Completed messages is often the first sign of an upstream outage.
Correlation IDs — when one business transaction fans out into multiple messages, correlation IDs let you trace the whole chain. Set them deliberately in your iFlows rather than relying on auto-generated IDs.
The goal is boring operations: failures get caught by alerts, diagnosed in minutes from the message log, and retried or fixed before anyone outside the integration team notices. That only happens if you know where Monitor lives and what the statuses mean — which, now, you do.