ARFCSSTATE table — tRFC LUW status table
ARFCSSTATE holds the status record of a single transactional RFC (tRFC) call queued for asynchronous execution, one row per LUW identified by its transaction ID. It is the status counterpart to the payload table ARFCSDATA, and it underlies both classic tRFC monitoring in SM58 and qRFC queues built on top of tRFC.
This page covers ARFCSSTATE, the status table behind SAP's transactional RFC (tRFC) mechanism, which many BTP and middleware integrations rely on for asynchronous calls. It focuses on how to read the table safely, how to prove an interface failure against it, and the mistakes consultants make when they try to use it as a source of truth for interface health.
Published 15 Sept 2026· 950 words
What it stores
One row represents the current status of a single tRFC logical unit of work (LUW) - one queued or executed asynchronous RFC call, identified by a transaction ID (TID). The status carried here reflects whether the LUW is still recorded and waiting, currently executing, successfully executed, or has failed and is subject to retry or manual intervention. The actual function module name and parameters are not stored in this table; they live in the companion table ARFCSDATA, joined by the same TID. This table is relevant to BTP integration work because many transport paths into and out of an SAP system - IDoc dispatch, BAPI-based calls fired asynchronously, and some middleware adapters - use tRFC as the underlying execution mechanism, so a stuck or failing interface often traces back to a row here.
Key fields
- MANDT - client the LUW was recorded under
- ARFCTID - the transaction ID uniquely identifying the tRFC LUW; the join key to the payload table
- ARFCDEST - the RFC destination the call is queued against
- ARFCSTATE - the status of the LUW (recorded, ready, executed, error, retry-exhausted, and similar states surfaced in SM58)
- ARFCTIME - timestamp the record was created or last updated
- ARFCUSER - the user under whose session the call was originally recorded
How it joins the data model
- ARFCSSTATE-ARFCTID = ARFCSDATA-ARFCTID (status record joins to the actual call payload and function module by transaction ID)
- ARFCSSTATE-ARFCDEST = RFCDES-RFCDEST (resolves the queued destination to its connection configuration)
- ARFCSSTATE-ARFCTID relates conceptually to entries in TRFCQOUT/TRFCQIN when qRFC queueing is layered on the same LUW
- ARFCSSTATE joins indirectly to EDIDC/EDIDD when the failing LUW is carrying IDoc dispatch, via the calling program and destination rather than a formal key
How to read it safely
Client-dependent table, MANDT is always the first restriction. In systems with heavy interface traffic this table can carry a large number of rows, and successfully executed LUWs are typically cleaned up on a schedule while failed ones accumulate, so an unrestricted select can be expensive and misleading. Always narrow by ARFCDEST and by ARFCSTATE before pulling rows, and add a time window on ARFCTIME. In practice this table is read through the SM58 tRFC monitor rather than direct table browsing in production, because the monitor also decodes the status codes and links straight to the payload.
How to prove it in the data
Symptom: calls to a specific RFC destination are not arriving on the target side. Select ARFCSSTATE restricted by ARFCDEST equal to that destination and ARFCSTATE in the error or retry states, ordered by ARFCTIME descending. Take the ARFCTID values returned and look them up in ARFCSDATA to see the function module and parameters that failed. If the rows show a connection-level error rather than a data error, the fault is in the destination configuration, not the interface payload.
ECC vs S/4HANA
The table exists in the same shape in S/4HANA. The tRFC kernel framework was not redesigned as part of the S/4HANA transition, and S/4HANA still relies on it for asynchronous RFC transport underneath IDoc processing, some BAPI-based calls, and qRFC queues used by various middleware adapters. There is no compatibility CDS view exposed for this table since it is infrastructure, not application data.
Common pitfalls
- Reading an empty or near-empty result as proof the interface is healthy - successfully executed LUWs are usually deleted quickly by cleanup jobs, so absence of rows only means nothing is currently stuck, not that throughput was normal
- Confusing tRFC status here with qRFC queue status shown in SMQ1/SMQ2 - qRFC layers its own queue semantics on top of tRFC, and this table only reflects the underlying LUW, not the queue sequencing
- Deleting rows directly to clear a stuck call - this can orphan the matching row in ARFCSDATA or leave the transport in an inconsistent state; the safe path is deleting or executing through the SM58 monitor function
- Treating one row as one business document - a single LUW can bundle multiple IDocs or multiple calls depending on how the sender packaged them, so counting rows does not give a document count
- Repeatedly retrying a failing LUW without checking the payload in ARFCSDATA or the target system log first - if the root cause is a wrong destination, missing authorization, or a target-side lock, blind retries just regenerate the same error and grow the table
Whose problem this is
This is Basis and technical integration territory, not a functional module owner's data. Whoever administers RFC destinations and monitors SM58 handles the actual failure diagnosis and retry decision. Functional or integration consultants surface the symptom - a stuck or failing interface call - and pass the relevant ARFCTID along rather than manipulating this table directly.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/arfcsstateERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.