SMQ2 — Inbound qRFC Queue Monitor
SMQ2 displays inbound qRFC queues on the receiving system - the entries (LUWs) waiting to be processed there. It is the mirror image of SMQ1, which shows the same transport from the sending side. Used when delta loads, IDoc transfers, or extraction feeds into BW appear stuck despite the source system reporting the data as sent.
This page covers SMQ2, the inbound qRFC monitor used to diagnose stalled data transport between a sending system and BW or any receiving system. It focuses on how queue serialization causes a single failed entry to block everything behind it, and how to tell a genuinely stuck transfer from one that already finished and was cleared from the queue.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,119 words
Purpose
SMQ2 shows the inbound side of qRFC (queued RFC) transport - the queue entries that have arrived at a system and are waiting to be executed there. The structural fact that causes most confusion: SMQ1 and SMQ2 are not two views of one queue, they are two different transactions running on two different systems. SMQ1 on the source shows what has been sent (outbound); SMQ2 on the target shows what has arrived and is pending execution (inbound). A queue can look empty and healthy in SMQ1 while SMQ2 on the receiving side shows the same queue name sitting in SYSFAIL. In BW extraction scenarios this matters because the extraction queue (fed by LBWQ) and delta queue (RSA7) sit on the source side, while the BW/S4 target system's inbound qRFC queue is what SMQ2 on that system actually shows.
When it is used
SMQ2 gets pulled up when a delta or IDoc-based transfer has clearly left the source (extraction job finished green, RSA7 or LBWQ show the records gone) but the data never lands on the target, or a BW process chain hangs waiting on a request that never completes. It sits downstream of RSA3/RSA7 diagnostics on the source and upstream of the BW monitor (RSMO) on the target - if RSMO shows a request stuck with no error and no progress, SMQ2 on the target system is the next stop, not RSA1. It is a transport-layer check, not a data-content check; it answers whether the payload arrived and executed, not whether the payload was correct.
How to use it in practice
- Call SMQ2 on the receiving system, in the client where the transfer is expected to land.
- Enter the queue name pattern (often derived from the source system logical name) or leave blank to list all inbound queues.
- Execute and review the status column: READY, RUNNING, SYSFAIL, CPICERR, NOSEND.
- Double-click a queue in error status to expand its LUW list and see the function module being executed and the return code.
- Use the menu option to display the LUW's error text, or jump to the linked short dump in ST22 if the timestamp lines up.
- Only after root cause is fixed, use the option to reprocess the queue; deleting the failed LUW without understanding it discards that transfer permanently.
Key data objects
- Queue status table (accessed via SMQ2, not a single fixed table name a consultant should query directly) - holds the current state (READY, SYSFAIL, etc.) per queue name and LUW.
- Queue payload storage - holds the serialized function module call and parameters for each LUW; not normally read directly, only through the transaction's own display.
- qRFC log - retains a trace of queues that have already completed and been removed from the active list, used to confirm a transfer actually finished rather than vanished.
How to prove it in the data
Do not query the qRFC storage tables directly with SE16 to draw conclusions - their internal layout changes across releases and misreading the raw payload table is a common source of wrong diagnoses. Instead run SMQ2 itself, filter by the queue name for the affected transfer, and read the status and LUW count. If the queue no longer appears at all, check the qRFC log display reachable from within SMQ2 for that queue name and timestamp window to confirm it processed and was cleared rather than never having arrived.
ECC vs S/4HANA
SMQ2 is unchanged on S/4HANA; qRFC remains the underlying transport for IDoc-based and several classic extractor-based interfaces. There is no dedicated Fiori app for generic qRFC monitoring. Where extraction has moved to the ODP framework, queue-based transport is bypassed for that specific data source, but qRFC still underlies CO-PA, LO, and other classic extractors, so SMQ2 stays relevant for those flows regardless of release.
Common pitfalls and how to diagnose them
- Serialization block - qRFC processes LUWs within a queue strictly in order. One failed entry blocks every entry queued behind it under the same queue name, even if those later entries are unrelated and would succeed on their own. Check the first failed LUW in the list first; fixing it and reprocessing usually clears the rest automatically.
- SYSFAIL misread as data error - a SYSFAIL status commonly means the function module call itself failed (missing authorization for the background user, RFC destination not reachable, target table locked) not that the business data was wrong. Open the linked error text before assuming the extractor logic is at fault.
- Queue appears empty but nothing arrived - a queue that finished successfully is removed from the active SMQ2 list, which looks identical to a queue that was never created. Always check the qRFC log for the queue name before concluding the transfer silently vanished; the two situations have opposite remedies.
- Wrong client or wrong system - queues are client-specific and system-specific. Checking SMQ2 in the wrong client, or checking it on the source system instead of the target, produces a false all-clear. Confirm which system is meant to be receiving before spending time on the queue list.
- Reflex delete of a stuck LUW - deleting a failed LUW to unblock the queue permanently discards that transfer. It should only be done after confirming the business data can be reloaded from source; otherwise the gap has to be found and manually reprocessed later.
Whose problem this is
Basis owns qRFC infrastructure, RFC destinations, and background user authorizations that most SYSFAIL entries trace back to. Functional or BW consultants identify which queue, which LUW, and which business process it corresponds to. A good handover states the queue name, the LUW timestamp, the status shown, and the process chain or interface it feeds, so Basis is not left guessing which of many queues matters.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/smq2ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.