Cloud Integration Message Monitoring: Finding Failed iFlows

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.

Read more →

SAP Event Mesh: Event-Driven Integration Explained

Point-to-point integrations create a spiderweb: every new system needs a direct connection to every system it talks to, and a change on one side ripples through all of them. SAP Event Mesh breaks that pattern. Instead of systems calling each other directly, they publish events — "order created", "invoice paid", "stock updated" — to a central broker, and any interested system subscribes. Producers don't know their consumers, and consumers don't care who produced the event. That's the core of event-driven architecture, and Event Mesh is SAP's managed implementation of it on BTP.

---

What Event Mesh actually does

At its heart, Event Mesh is a message broker as a service. Applications connect to it and do two things:

Publish — send an event to a topic (a named channel like sales/order/created) or a queue (a point-to-point channel where each message is consumed once).

Subscribe — register interest in a topic or queue and receive events as they arrive, asynchronously. The subscriber processes at its own pace; if it's down, messages wait.

The decoupling is the point. The order system publishes "order created" and moves on. Whether zero or five downstream systems care — a warehouse app, an analytics pipeline, a notification service — the publisher neither knows nor cares. Adding a new consumer means subscribing to the topic, not modifying the publisher.

Key takeaway: Event Mesh decouples applications through events — publishers emit to topics/queues and subscribers consume asynchronously. Producers never need to know their consumers.

---

Topics vs queues: which to use

Topics implement publish-subscribe: every subscriber gets a copy of each message. Use them for broadcast-style events — "price changed" needs to reach the webshop, the mobile app, and the analytics engine simultaneously.

Queues implement point-to-point: each message is delivered to exactly one consumer. Use them for work distribution — ten "invoice to process" messages spread across three worker instances, each handled once.

A common mistake is using topics for workload and queues for notifications. If exactly-once processing matters, you want a queue. If every interested party must see the event, you want a topic.

---

Protocols: how applications connect

Event Mesh speaks the standard messaging protocols, so you're not locked into SAP SDKs:

AMQP 1.0 — the workhorse for application-to-application messaging, with acknowledgments and transactions. Most Java, Node.js, and Python apps connect over AMQP.

MQTT — lightweight, designed for IoT scenarios where devices have limited bandwidth and processing power. Sensors and edge devices typically use MQTT.

REST — for simple publish/subscribe over HTTP when a full messaging client is overkill.

JMS — for Java EE applications that already speak JMS.

Because these are open standards, a non-SAP system can publish events that SAP systems consume, and vice versa. The broker doesn't care what technology sits on either end.

---

Where it fits in the Integration Suite

Event Mesh rarely stands alone. The typical pattern: Cloud Integration iFlows consume events from Event Mesh, transform and route them, then call backend systems — or publish new events back. An "order created" event arrives via Event Mesh, an iFlow enriches it with customer master data from S/4HANA, and publishes an "order enriched" event for the warehouse system.

Event Mesh + API Management is another common pair: synchronous APIs for request-response, events for everything that can happen asynchronously. The rule of thumb — if the caller needs an answer now, use an API; if it just needs something to happen eventually, publish an event.

---

Quality of service and reliability

Messaging systems offer delivery guarantees, and Event Mesh is no exception:

At-least-once — the default. Messages are redelivered until acknowledged, so consumers must be idempotent (processing the same event twice has the same effect as once). Design your handlers accordingly.

Dead-letter queues — messages that repeatedly fail processing get parked in a dead-letter queue instead of blocking the main queue forever. Monitor these; they're where integration bugs go to hide.

Message TTL — time-to-live settings expire stale events. A "flash sale started" event is worthless an hour later; TTL keeps queues from filling with irrelevant history.

---

Practical guidance

1. Design your topic hierarchy early — domain/entity/action (e.g. sales/order/created) scales; flat topic names become unmanageable past a dozen integrations.
2. Keep events small and self-describing — include enough context (IDs, timestamps, version) that consumers don't need to call back for basics.
3. Version your event schemas — adding a field is fine; renaming one breaks every subscriber. Treat events like a public API.
4. Plan for duplicates — at-least-once delivery means your consumer will eventually see the same event twice. Idempotency isn't optional.

Event-driven architecture rewards upfront design and punishes ad-hoc topic sprawl. A half-day spent on naming conventions and schema discipline saves weeks of debugging mysterious duplicate-processing bugs later.

Read more →

SAP Integration Advisor: Intelligent B2B Mapping with MIG and MAG

Ask integration consultants what eats their B2B project budgets and mapping comes up every time. Not the plumbing — the mapping. Figuring out that the partner's CST_ORD_NO is your PurchaseOrder, that their date format needs converting, that their codelist for "shipped" doesn't match yours. It's slow, expert-dependent work, and every partner is a fresh round of it.

Integration Advisor attacks exactly this problem: it proposes mappings automatically, learned from B2B standards.

---

What it does

Integration Advisor is a machine-learning-assisted mapping tool inside Integration Suite. You tell it: "map this partner's purchase order format to my system's format." It analyzes both message structures and proposes field mappings — including transformations for dates, codelists, and units — based on patterns learned from thousands of real B2B mappings.

The proposals aren't blind guesses. They're grounded in MIGs and MAGs — Message Implementation Guidelines and Mapping Guidelines — the standardized documents that describe how industries actually use EDI and XML formats. Advisor knows, for example, how an EDIFACT ORDERS message is conventionally structured and what its segments mean, so it can map a partner's variant to your canonical model with genuine understanding rather than string matching.

Key takeaway: Integration Advisor proposes B2B field mappings learned from industry standards (MIG/MAG) — turning weeks of manual mapping analysis into a reviewed starting point.

---

MIG and MAG: the knowledge base

Worth unpacking, because these acronyms get thrown around loosely. A MIG (Message Implementation Guideline) documents how a specific industry or community uses a standard message — which segments of EDIFACT ORDERS are mandatory, which codelists apply, what the business rules are. It's the "how we actually do it" companion to the raw standard.

A MAG (Mapping Guideline) goes one step further: it documents how to map between two specific formats — source fields to target fields, with transformation rules. MAGs capture mapping knowledge that consultants traditionally carried in their heads (and their personal template libraries).

Integration Advisor is trained on a large corpus of these guidelines plus anonymized real-world mappings. When it proposes that NAD+BY maps to your BuyerParty, that's not a guess — it's the accumulated weight of how the industry actually maps it.

---

How it fits the project workflow

The realistic workflow isn't "Advisor does the mapping, consultant goes home." It's:

1. Import the partner's message structure and your target structure.
2. Generate proposals — Advisor suggests field mappings with confidence indicators.
3. Review and adjust — the consultant validates, fixes the tricky 10%, adds partner-specific business rules.
4. Export the mapping for use in Cloud Integration message mappings.
5. Feed back — corrections improve future proposals.

The economics are straightforward: the first 80–90% of a mapping (the standard, boring part) gets generated in minutes; human expertise concentrates on the genuinely partner-specific remainder. On a project with dozens of partners, that's transformative. It also democratizes the work — a less experienced consultant with Advisor outperforms an expert working from a blank canvas.

---

Where it shines (and where it doesn't)

Advisor shines brightest on standards-based B2B: EDIFACT, ANSI X12, and common XML variants where MIG/MAG knowledge applies. The more standard the formats, the better the proposals.

It's less magical on fully proprietary, undocumented formats nobody's ever mapped before — there, it's an intelligent assistant rather than an oracle. And it doesn't replace understanding the business semantics: a confident-looking wrong mapping is still wrong, which is why the review step is non-negotiable.

Paired with Trading Partner Management (which owns the partner agreements) and Cloud Integration (which executes the mappings), Advisor completes the B2B toolchain: agree with the partner, generate the mapping, execute the flow — each capability doing what it's best at.

---

Reading confidence scores

Advisor ranks proposals with confidence indicators — treat them as triage, not truth. High-confidence mappings (standard segments, well-trodden codelists) usually need only a glance. Medium-confidence ones deserve a real review: the structure matched, but a semantic judgment call is hiding in there. Low-confidence mappings are Advisor saying "I found something" — verify from scratch. A practical rule: review everything once, but spend your time inversely to the confidence score. The fastest teams clear high-confidence mappings in bulk and concentrate expertise where the score is lowest.

---

Teaching it your conventions

Advisor learns from corrections. When you fix a proposal — "no, in our partner community that segment means X" — that feedback improves future proposals for your tenant. This compounds: the first partner's mapping takes the longest, the twentieth goes noticeably faster, because the system has absorbed your community's conventions. It's worth being disciplined about corrections rather than working around bad proposals silently; every uncorrected workaround is training data lost.

---

The business case

Put numbers on it for the project sponsor. Manual B2B mapping typically runs days to weeks per partner-message combination, almost all of it senior-consultant time. Advisor compresses the mechanical portion to hours, leaving review and edge cases. On a 50-partner rollout, that's the difference between a mapping workstream measured in quarters and one measured in weeks — and it de-risks the schedule, because the long tail of "partner 37's weird ORDERS variant" stops being a timeline threat and becomes a half-day review task.

Key takeaway: SAP Integration Advisor turns B2B mapping from a blank-canvas expert task into a review-and-refine workflow, grounded in MIG/MAG standards knowledge. Use it for every standards-based partner mapping — your project timeline will thank you.

Read more →