TRFCQOUT table — Outbound qRFC Queue Table
TRFCQOUT holds one row per unit of work waiting in an outbound queued RFC (qRFC) queue, linking a queue name and transaction ID to the destination it must be sent to. It backs the SMQ1 outbound queue monitor and is the table to check when asynchronous outbound traffic to ALE partners, IDocs, or BTP-integrated systems is delayed or stuck.
This page covers TRFCQOUT, the table underlying the outbound side of the qRFC queue mechanism used for serialized asynchronous RFC calls, including IDoc distribution and integration traffic to cloud systems. It explains what a row represents, how to join it to the tRFC status and destination tables, and the diagnostic mistakes made when reading a stuck queue.
Published 15 Sept 2026· 963 words
What it stores
One row represents a single logical unit of work (LUW) registered in an outbound queue for queued RFC processing. Each LUW carries a transaction ID identifying the underlying tRFC call, a queue name that determines the strict processing order relative to other LUWs in the same queue, and the RFC destination the payload is ultimately addressed to. The table is the control layer that SMQ1 reads to show queue status, position, and whether an entry is waiting, running, or blocked. It does not hold the actual payload data; that lives elsewhere. Applications register queue entries here when they need guaranteed, ordered, asynchronous delivery to a receiving system rather than a synchronous call.
Key fields
- MANDT - client the queue entry belongs to; every read must be client-restricted
- QNAME - queue name assigned by the calling application; entries sharing a queue name are processed strictly in order, one at a time
- TID - transaction ID of the underlying tRFC LUW; the join point to the tRFC status and payload tables
- DEST - RFC destination the queued call is being sent to, pointing at an entry in the destination table
How it joins the data model
- TRFCQOUT-TID = ARFCSSTATE-TID (status of the underlying tRFC call)
- TRFCQOUT-TID = ARFCSDATA-TID (actual serialized payload for that LUW)
- TRFCQOUT-DEST = RFCDES-RFCDEST (destination definition, host, and connection type)
- TRFCQOUT-QNAME compared against TRFCQIN-QNAME across systems when tracing a queue end to end from sender to receiver
How to read it safely
Always restrict on MANDT first; this table is shared across all clients on the instance and an unrestricted read pulls in unrelated application traffic. After client, restrict on QNAME or a QNAME prefix pattern if the application uses a naming convention, since that is the only reliable way to isolate one integration scenario from thousands of unrelated queue entries. Avoid full scans in production; volumes fluctuate heavily depending on how fast queues drain, and a table that looks small at 9am can be enormous during a batch peak. Do not restrict on DEST alone as a first filter, because the same destination can serve many unrelated queues.
How to prove it in the data
To confirm a specific IDoc or interface message is genuinely stuck in the outbound queue rather than already delivered, take the queue name reported by the business process (often visible in the message's status record or in SMQ1 itself), restrict TRFCQOUT by MANDT and that QNAME, and check whether an entry still exists and what position it occupies. If the queue name has zero rows here, the LUW has already left the queue and the delay is downstream, not in qRFC.
ECC vs S/4HANA
The qRFC mechanism and TRFCQOUT carried forward into S/4HANA unchanged in concept and largely unchanged in structure; it remains the transport layer under much of the asynchronous ALE, IDoc, and integration traffic that now also feeds cloud-side processes through BTP integration scenarios. SMQ1 and SMQ2 remain the standard monitoring transactions. No CDS compatibility view is generally needed for this table because it is an operational queue table, not a business or reporting entity.
Common pitfalls
- Assuming a stuck queue means the receiving system is down: qRFC processes each queue strictly in sequence, so one failed LUW at the front of the queue blocks every later entry even if the receiver is healthy and later entries would succeed on their own
- Deleting or editing rows directly via a table browser to clear a backlog: this desynchronizes the queue from its underlying tRFC status entries and can leave orphaned or duplicated payload; queue entries must be managed through SMQ1, not raw table maintenance
- Treating an empty result for a queue name as proof nothing was ever sent: processed entries are removed from the active queue table, so absence here after the fact proves nothing about history, only about the current backlog
- Reading DEST as a permanent routing fact: destinations can be renamed or repointed without the queue name changing, so an old queue entry's DEST may not reflect where a resend would actually go today
- Confusing qRFC queue entries with plain tRFC calls visible in the transactional RFC monitor: qRFC is built on tRFC but adds strict ordering per queue name, and troubleshooting one does not substitute for troubleshooting the other
- Assuming queue name format reveals the sending application: naming conventions are set by whichever module or interface registered the queue, and vary between ALE/IDoc traffic, workflow, and integration scenarios connecting to BTP or middleware
Whose problem this is
Basis or the middleware/integration team owns queue health, retry configuration, and clearing of stuck LUWs. Functional consultants supply the business context: which document, message, or interface run corresponds to the affected queue name. Persistent blockages that keep recurring for the same interface usually need the integration team that built or maintains the outbound scenario, not a repeated manual unblock.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/trfcqoutERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.