SXMB_MONI — PI/XI Integration Engine Message Monitor

SXMB_MONI is the message monitoring transaction for the ABAP-based Integration Engine inside SAP PI/XI. It displays the header, pipeline steps, and payload versions of every XML message that entered the Integration Engine, along with status flags for success, error, scheduled, or waiting. The one structural fact that causes most confusion: SXMB_MONI only shows what passed through the ABAP Integration Engine pipeline. Messages that were routed and processed entirely inside the Java Adapter Engine, or messages handled by SAP Cloud Integration (CPI), will not appear here, or will appear only as a partial record if they touched the ABAP stack briefly. Consultants coming from a CPI background often search SXMB_MONI for a cloud iFlow message and find nothing, not because the message failed silently but because it was never in scope for this transaction.

SXMB_MONI is reached for when a classic PI/PO scenario fails or behaves unexpectedly: IDoc to file, proxy to proxy, SOAP to RFC, or any scenario configured through the Integration Directory using the ABAP-based Integration Engine pipeline. It sits downstream of sender adapter processing and upstream of receiver adapter delivery. It is the right tool when someone reports a business document that never arrived at the target system and the interface is a known PI scenario. It is the wrong tool for a pure CPI iFlow (use the cloud integration monitor instead), for a direct point-to-point web service call bypassing PI (use SOAMANAGER or the receiving system's own logs), or for an IDoc that never left the source system (use WE05 or WE02 first to confirm it was even sent).

Run SE16 on SXMSPMAST and filter on the interface name and date range reported by the business user, checking the status field for error or scheduled rather than success. Note the message GUID from the matching row, then look up the same GUID in SXMSPFPAY to pull the raw payload for the pipeline version in question, which confirms whether the data reaching PI already contained the fault or whether the fault was introduced during mapping. If no row exists for the expected time window, the message never reached the Integration Engine and the search needs to move to the sender system or the Adapter Engine, not deeper into SXMB_MONI.

SXMB_MONI itself is unchanged on an S/4HANA system running SAP PI/PO on premise; it still behaves exactly as it did in classic ECC-plus-XI landscapes. The larger change is strategic rather than technical: new integration builds are steered toward SAP Integration Suite and Cloud Integration (CPI), where monitoring is done through a Fiori-based Message Monitoring application entirely outside the ABAP stack and outside SXMB_MONI's scope. A consultant supporting a hybrid landscape needs both tools and should not assume one supersedes the other.

Pipeline, adapter, and queue failures are Basis or integration-team territory; mapping logic errors and payload content issues are functional or integration-developer territory. A good handover states the message GUID, the interface name, the exact pipeline step that failed, and whether the same message reprocesses cleanly in a test resend, so the receiving owner does not have to re-run the whole search from scratch.

For IDoc-based interfaces routed through PI, WE05 and WE19 confirm whether the IDoc left the source system and let a test IDoc be replayed independently of PI. WE20 and WE21 confirm the partner profile and port configuration that determine whether an IDoc is even eligible for XI routing. SPROXY is the counterpart on the ABAP proxy side, used to confirm the proxy structure matches what the pipeline expects to receive. Reading these alongside SXMB_MONI separates a PI pipeline problem from a sender-side configuration problem.