TRFCQIN table — Inbound Transactional RFC Queue Table

One row in TRFCQIN represents a single queued inbound transactional RFC call, meaning a call that reached the local system's dispatcher but was not executed on arrival, either because a suitable work process was not free, the receiving function module raised a temporary condition, or the call was explicitly scheduled for background processing. The row exists only for the lifetime of the queue: once the tRFC scheduler successfully runs the call, the entry is removed. TRFCQIN is the older, unordered tRFC queue mechanism, distinct from the named, ordered qRFC queues visible in SMQ1 and SMQ2. It is consulted when interface partners report calls as sent but not reflected downstream, when the tRFC scheduler appears stalled, or when a system shows a growing backlog of unprocessed inbound RFCs.

Always restrict by MANDT first, then by ARFCDEST or a specific ARFCTID obtained from an SM58 trace or a partner's error report; this is a queue, not a log, so a full unrestricted read is rarely meaningful. Narrow ARFCTIME to a tight window around the reported incident. Start diagnosis in SM58, which applies these same filters and translates the status codes into readable text, before dropping into SE16 for anything the transaction does not surface. Because the table only holds open work, the row count itself is the health signal: a healthy system keeps this table near empty, and any sustained growth indicates the scheduler is not draining the queue rather than indicating a data retention issue.

To confirm an inbound tRFC backlog, select TRFCQIN for the reported client and ARFCDEST, filtering ARFCSTATE to anything other than a completed/confirmed status. A nonzero result with old ARFCTIME values proves calls are genuinely stuck, not just slow. Take one ARFCTID from the result and look it up in SM58 to read the actual error text, since the table itself only exposes a status code, not the underlying failure reason.

TRFCQIN and its outbound counterpart TRFCQOUT are part of the long-standing tRFC/qRFC persistence layer inherited into S/4HANA without change in concept. There is no CDS compatibility view for it because it is a technical Basis table rather than a business data object. Day-to-day queue monitoring on S/4HANA landscapes is still usually done through the qRFC monitor transactions, but the underlying tRFC tables continue to exist and get populated for interfaces that still rely on plain transactional RFC rather than named qRFC queues.

This is a Basis or integration/interface team question, not a functional module owner's problem. Whoever administers the RFC destination (SM59) and monitors transactional traffic (SM58, SMQ1, SMQ2) triages TRFCQIN entries. Functional teams are brought in only after the RFC layer confirms the call reached the target function module and failed inside application logic.

ARFCSSTATE and ARFCSDATA are the qRFC-era header and payload tables that largely superseded plain tRFC for newer interfaces. TRFCQOUT is the outbound mirror of this table at the sending system. RFCDES holds the destination definitions referenced by ARFCDEST. IDoc-based interfaces riding on tRFC expose their business content in EDIDC and EDID4, and change-pointer based distribution uses BDCP and BDCPS, all correlated to a TRFCQIN entry through the transaction ID rather than a shared business key.