SMQ1 — qRFC Outbound Queue Monitor
SMQ1 displays the outbound queued RFC (qRFC) queues on the system where data originates, showing every LUW waiting to be transferred to a receiving destination in strict FIFO order per queue name. It is the first place to check when BW delta extraction, LO cockpit postings, or any qRFC-based transfer appears stuck before it even leaves the source system.
This page covers SMQ1, the outbound qRFC monitor used to diagnose stuck or failing queue entries between a source system and a receiving system, most commonly seen in LO cockpit and BW delta extraction troubleshooting. It focuses on distinguishing outbound blockage from inbound blockage and on what is safe to do with a stuck LUW versus what causes silent data loss.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,037 words
Purpose
SMQ1 is the monitor for the outbound side of queued RFC. Every queue name groups a set of LUWs (logical units of work) that must be delivered to a receiving system in exactly the order they were created; qRFC guarantees sequence within a queue, not across queues. The structural fact that causes most confusion: because processing is strictly FIFO within a queue, one LUW in error state (SYSFAIL, CPICERR) blocks every entry queued behind it in that same queue, even if those later entries have nothing wrong with them. Consultants who look only at the failing entry and ignore the queue depth behind it underestimate the backlog. SMQ1 only shows what has not yet left the sending system; once transferred, tracking continues on the receiving system in SMQ2.
When it is used
SMQ1 is reached for whenever a queued transfer appears stalled at the source: BW delta extraction where records posted in the source client via LO cockpit never show up in the BW delta queue, IDoc-style qRFC transfers between application systems, or any custom qRFC-based interface. The consultant checks SMQ1 on the sending client first, because if the queue is clean there the problem is downstream (network, RFC destination, or the receiving system's SMQ2/inbound processing). RSA7 is used afterward to confirm whether the delta queue in BW actually received the data; LBWQ is checked earlier in the chain to see whether the extraction queue on the source even released the LUWs into qRFC in the first place.
How to use it in practice
- Log on to the correct system and client - the sending side, not BW, since SMQ1 only shows outbound queues local to that system.
- Run SMQ1 and review the queue overview list: queue name, number of LUWs, and status (READY, RUNNING, SYSFAIL, CPICERR, NOSEND).
- Double-click a queue to expand its LUW list and read the error text on the failing entry.
- Check the assigned RFC destination for that queue and confirm connectivity separately in SM59.
- Decide whether to activate the queue for retry or escalate before deleting anything, since deletion is irreversible.
Key data objects
- TRFCQOUT - outbound qRFC queue entries, one row per LUW segment, including queue name, destination, and processing status.
- ARFCSSTATE - underlying tRFC call state that qRFC builds on, holding the transaction ID and current call status.
- ARFCSDATA - the actual serialized function call data for each LUW, read when an entry is replayed or inspected.
- QRFCLOGGING - logging of qRFC administrative actions such as activation, deletion, or destination changes on a queue.
How to prove it in the data
In SE16, open TRFCQOUT filtered on QNAME for the queue in question and check the status field for entries showing SYSFAIL or CPICERR rather than EXECUTED. A growing count of entries against a stable QNAME over time, compared against the timestamp of the last successful transfer, confirms the queue is backing up rather than merely being slow. Cross-check the transaction ID found there against ARFCSSTATE to see the underlying tRFC call status and the target destination it was addressed to.
ECC vs S/4HANA
SMQ1 is unchanged on S/4HANA; qRFC remains the same mechanism and the transaction still displays the same outbound queue list and LUW detail. There is no dedicated Fiori app that replaces it, and troubleshooting still runs through the classic monitor. Newer migration and data transfer tools may surface their own queue status screens, but underlying LO cockpit and generic qRFC traffic is still diagnosed here.
Common pitfalls and how to diagnose them
- SYSFAIL blocking the queue - the first LUW in error state stops everything behind it regardless of queue depth; read the error text before touching anything, since it usually points to an authorization failure, a lock timeout on the target, or an expired RFC user password rather than a data problem.
- Queue sits in READY and never moves to RUNNING - the qRFC scheduler for that destination is not active or was deregistered; this is checked and corrected through the qRFC registration transaction, not by repeatedly refreshing SMQ1.
- Checking the wrong system - SMQ1 shows outbound queues local to the logon system; a queue that looks clean here can still be stuck on the receiving side, which only shows in SMQ2 on that other system, so confirm which side is actually blocked before escalating.
- Deleting a stuck LUW as a reflex fix - deleting removes that unit of work permanently; for BW delta extraction this can produce a silent gap in the delta queue that reconciliation will not automatically catch, so deletion of business-relevant entries needs functional sign-off first.
- Continuously growing queue with no errors shown - usually means the receiving destination is unreachable or overloaded rather than a fault in qRFC itself; verify the destination in SM59 and check load on the receiving system before assuming the queue mechanism is broken.
Whose problem this is
Basis owns RFC destination health, connectivity, and qRFC scheduler activation. Functional or BW handles the decision on whether a stuck LUW can be safely retried or must be deleted, since that decision affects business data completeness. A good handover states the queue name, LUW count, error text, destination, and whether any entries were already deleted before Basis was engaged.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/smq1ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.