Middleware is introduced into SAP integration landscapes for good technical reasons: decoupling systems, translating protocols, centralizing error handling, enabling message transformation. None of those benefits show up in the architectural discussion about monitoring. What also gets introduced, without being explicitly evaluated, is a set of new monitoring blind spots.
A hub that processes messages correctly is invisible to the SAP system that sent them. A hub that fails is also invisible, from the SAP side. Whether the message was delivered, transformed correctly, and processed by the receiving system is something the SAP sender does not know unless the hub is monitored separately and that monitoring is designed to surface failures back to the team that owns the SAP side.
This article covers the specific ways that middleware architecture changes what can be seen, where monitoring responsibility shifts, and what design decisions at architecture time make operations across the integration boundary more manageable.
What a hub architecture actually changes about visibility
The point-to-point baseline
In a direct RFC or IDoc connection between two SAP systems, the monitoring picture on the sending side is relatively complete. SM58 shows whether a transactional RFC call was dispatched and acknowledged. BD87 shows the IDoc status at each step. If the call fails, the failure is visible in the sending system’s transaction monitors. If it succeeds, the acknowledgment confirms that the receiving system accepted the message.
This visibility is not perfect. A message acknowledged as received by the receiving system’s RFC layer may still fail at the application processing level, producing a status 51 IDoc error on the receiver that is not visible on the sender without explicit monitoring of the receiver. But the failure surface is defined and bounded. The monitoring tools available on the SAP side cover most of it.
What changes when middleware enters the picture
When a message passes through a hub, the SAP sender’s view narrows to a single data point: did the message reach the middleware successfully? If the answer is yes, the SAP system moves on. Everything that happens after that, the middleware’s processing, the transformation, the delivery to the target system, the target system’s application-level processing, is outside the SAP sender’s direct observation.
The monitoring gap this creates is proportional to how asynchronous the hub architecture is. In a fully asynchronous design, the SAP system posts a message to the middleware’s inbound queue and returns immediately. From the SAP transaction monitor’s perspective, the send was successful. Whether the downstream system received and processed the message is a question that the middleware’s monitoring must answer, not the SAP system’s.
In a synchronous hub design, the SAP system waits for a response from the middleware, which waits for a response from the target. The SAP system knows the outcome because the call either returns successfully or returns an error. Synchronous designs preserve end-to-end visibility at the cost of performance: the SAP work process holds a connection for the entire duration of the downstream call chain.
Asynchronous hubs and the dead letter queue problem
Asynchronous integration is the dominant pattern in modern SAP middleware architectures because it decouples sender and receiver performance. The SAP system is not blocked waiting for the downstream system to respond. Message processing spikes on the receiver do not slow down the SAP sender. These are genuine benefits.
The monitoring cost is that delivery confirmation moves entirely out of the SAP sender’s view. The sender knows it handed off the message. Confirmation that the message was processed by the receiver exists only in the middleware’s logs and, if the hub is well designed, in the target system’s application data.
The specific failure mode that asynchronous architectures introduce is the dead letter queue, or DLQ. When a message fails processing in the middleware after the maximum retry count is exhausted, it is moved to the DLQ. This is the correct behavior: it preserves the message for investigation rather than discarding it. The operational problem is that messages accumulate in the DLQ silently unless someone has configured an alert on DLQ depth.
A DLQ that has been accumulating messages for three days represents three days of failed message delivery that no alert flagged, because the SAP sender considered delivery successful (the message reached the hub), and the hub considered its job done (the message was moved to the DLQ per the error handling policy). The business discovers the failure when a downstream process produces incorrect or missing data.
| Watch out: Dead letter queues without monitoring alerts are the most common source of silent integration failures in hub-based architectures. A DLQ alert at a depth of one or two messages is not excessive in a production environment. Messages in a DLQ are messages that failed after exhausting retries. Every entry represents a delivery that did not happen. The alert should be treated as critical for Tier 1 message types. |
The dual monitoring requirement and where responsibility gaps form
Any integration that passes through middleware requires monitoring at two points: the sending system and the hub. The sending system confirms that the message was handed off. The hub confirms that the message was processed and delivered. Neither confirmation alone is sufficient.
In most organizations, these two points are owned by different teams. The SAP Basis or operations team monitors the SAP side. A middleware team, a BTP operations team, or an infrastructure team monitors the hub. When a message fails somewhere in the middle, the investigation requires both teams to look at their respective monitoring, compare timestamps and message identifiers, and reconstruct the failure sequence across the boundary.
The gap forms when the two monitoring environments do not share a common identifier for each message. Without a correlation ID that persists from the SAP sender through the middleware to the target system, matching a SAP-side event to a hub-side event requires timestamp alignment and manual reconciliation. This is slow and error-prone under incident pressure.
The architectural decision that eliminates this gap is requiring a correlation ID in every message from the point of origin. The SAP sender generates or includes a unique message identifier in the payload. The middleware preserves that identifier in its processing logs. The target system includes it in application-level acknowledgments. When a failure occurs, any team can search all monitoring systems using the same identifier and immediately locate the relevant events at each processing step.
Transformation failures: technically delivered, business outcome failed
Message transformation in middleware, converting an IDoc format to a REST payload, mapping field names between systems, restructuring hierarchical data, introduces a failure mode that neither the SAP sender nor the target receiver automatically detects. The transformation runs in the middleware. If the transformation produces an output that is syntactically valid but semantically incorrect, the message is delivered successfully and the target system processes it without error. The business outcome is wrong.
An order IDoc where a field mapping error causes the quantity to be copied into the price field will create a purchase order with a correct structure and incorrect values. Both the middleware and the target system report success. The error surfaces when someone reviews the purchase order and notices that the price is exactly equal to the ordered quantity, which is an implausible coincidence.
Monitoring that catches this category of failure requires payload validation at the middleware level, checking that transformed outputs contain expected field values within expected ranges, not just that the transformation completed without a runtime error. This is a monitoring requirement that belongs in the integration hub design specification, not discovered after the first production incident.
SAP Integration Suite: the monitoring interface most teams underuse
SAP Integration Suite on BTP provides an Operations view that shows message processing status, flow execution results, and error logs. It is the correct tool for monitoring BTP-hosted integration flows. It is also a tool that most SAP Basis teams have read-only access to at best and have never used in an operational context.
The more useful capability for integration monitoring is the Integration Suite OData API. It exposes message processing status, flow execution statistics, and error counts in a machine-readable format that monitoring platforms can poll and alert on. A monitoring platform configured to query the Integration Suite API every minute and alert when error rates on specific flows exceed a threshold provides the real-time hub-side visibility that the Operations view requires manual checking to achieve.
The setup requires an API client credential in the BTP subaccount with message monitoring scope, an endpoint for the Integration Suite management API, and a monitoring platform capable of querying REST APIs. Most SAP monitoring tools do not include this integration out of the box, which is why the Operations view remains a manually-checked tool rather than an alerting source. Building the API integration changes that.
| Note: When the Integration Suite is used alongside a third-party middleware platform such as MuleSoft or Boomi for specific integration patterns, the monitoring requirement extends to both platforms independently. A landscape where some integrations run on Integration Suite and others run on a third-party tool needs monitoring coverage for each platform, with correlation IDs that allow cross-platform message tracing when a business process spans both. |
Architecture decisions that make monitoring achievable
The monitoring consequences of an integration hub architecture are largely determined by decisions made during the architecture phase, not the operations phase. Three decisions have the highest impact on monitoring coverage.
First, standardize on a single integration platform for the majority of SAP message flows rather than allowing each project team to introduce their own middleware. A landscape where integrations run on five different platforms requires five different monitoring approaches, five different alert configurations, and five different escalation paths. Consolidation does not need to be immediate or absolute, but it should be the stated direction and new integrations should require explicit justification to deviate from the standard platform.
Second, define the monitoring ownership boundary explicitly in the integration architecture document. Who monitors the SAP sender side? Who monitors the hub? Who monitors the target receiver side? Who is the escalation contact when a message fails in transit? These questions have operational answers that need to be established before the first production incident, not during it.
Third, require DLQ alerting and correlation ID implementation as non-negotiable deliverables for every new integration, not optional nice-to-haves. These are not complex to implement. They are consistently omitted because they are not part of the functional requirements that drive project delivery timelines. Making them part of the integration acceptance criteria, the same way functional business requirements are acceptance criteria, ensures they are implemented before go-live rather than retrofitted after the first silent failure.
A middleware architecture designed with these three requirements met will not eliminate integration failures. It will ensure that when a failure occurs, the monitoring layer has the data needed to detect it quickly and the organizational structure in place to act on it. That is the only realistic goal for integration monitoring in a complex SAP landscape.
Redpeaks monitors SAP-side interface metrics including IDoc status, RFC queue depth, and qRFC health, and supports integration with BTP Operations API data for end-to-end integration visibility across the middleware boundary. See the integration monitoring coverage.
