ARFCSDATA table — ARFCSDATA - transactional RFC payload storage

One row in ARFCSDATA represents a segment of the serialized function call data belonging to a single queued transactional RFC (tRFC), identified by a transaction ID (TID). When an application issues an asynchronous RFC call with commit control (a tRFC), the kernel serializes the function module name and its parameters and writes that payload here so the call can survive a restart and be replayed if the first delivery attempt fails. A small call fits in one row; a large call (a big IDoc packet, a bulk interface call, a mass update) is split into several rows that share the same TID and are reassembled in sequence when the call is finally executed against the target system. The table is purely plumbing for the RFC queue mechanism, not business data, and its rows disappear once the LUW is confirmed as executed.

Always restrict on MANDT first, then on TID; there is no useful secondary index for browsing this table by content because the payload field is a raw/long text blob, not searchable business data. Never select against ARFCSDATA without a TID already in hand from ARFCSSTATE - a full scan on a busy system can be enormous and the rows are meaningless without their header. The normal path is to find the problem TID through the tRFC monitor first, then, only if the standard tools do not give enough detail, look up the raw segments for that specific TID.

Symptom: a call has been sitting in the tRFC monitor for hours with status 'to be executed' or 'transmission error'. Take the TID shown there, select ARFCSSTATE where MANDT = client and TID = that value to confirm the destination and retry count, then select ARFCSDATA on the same TID. If rows exist and reassemble to a plausible payload, the call is genuinely still queued and waiting on the target system or destination. If ARFCSDATA returns no rows for a TID that still exists in ARFCSSTATE, the payload has been lost or purged and the entry is orphaned - it cannot be replayed.

ARFCSDATA is Basis-level kernel infrastructure, not application data, and it is unchanged in shape on S/4HANA. It was never a candidate for CDS compatibility views because there is no business consumption of it; it exists purely to support the tRFC delivery guarantee. The same cleanup and monitoring mechanisms that applied on ECC still apply.

Basis or the interface/integration team owns this table, its growth, and any cleanup job that runs against it. Functional consultants may need to check it while chasing a stuck IDoc or a failed interface call, but should raise the TID to Basis rather than deleting or editing rows directly, since the delivery guarantee depends on ARFCSSTATE and ARFCSDATA staying consistent with each other.

ARFCSSTATE carries the status, destination and retry information for the same TID and is the table to check first. TRFCQOUT and TRFCQIN cover the qRFC queue variant of the same mechanism. EDIDC and EDIDD sit downstream when the queued call is actually an outbound IDoc packet riding on tRFC. The transactional RFC monitor (SM58) is the normal tool for viewing and acting on these entries; nobody should be editing ARFCSDATA through generic table display tools as a first resort.