Outbound tRFC Queue Stuck or Not Processing

The complaint usually arrives as 'orders placed this morning still have not appeared in the warehouse system' or 'the cloud portal shows nothing since 9am, but we know postings were made'. Sometimes it is phrased as a specific document: 'this sales order has been sitting for three hours'. Nobody mentions tRFC by name at this stage. A functional consultant checks the source document, finds it saved and released correctly on the sending side, and only then escalates to Basis or integration support, who open SM58 or SMQ1 and see a growing backlog of entries in one queue, all with the same age as the oldest failed one, none of them moving.

In SM58, filter the specific queue name over the affected time window and sort by execution date; the oldest entry's status and return code is the actual root cause, and its timestamp marks exactly when the backlog started. Compare that timestamp against SM21 and ST22 on the target system, and against the Cloud Connector connection log if BTP routing is involved, to confirm the failure is connectivity, authorization, or data, not a coincidence of load.

When the first LUW fails on bad business data, the fix is a data correction on the source side, not a system change: correct the underlying document or master data, then retrigger the specific LUW rather than mass-retrying the queue. When the cause is a dead or misconfigured RFC destination, correcting the destination is a configuration change made directly in the client, and if it must be replicated across systems it goes through transport of the destination definition; this is a Basis-owned change. When the target system or client is locked, the fix is operational (unlock, communicate maintenance window) and not something the queue itself needs touched for. When authorization is missing for the technical user, the fix is a role or authorization assignment in the target system, typically transported through the usual authorization change path. When the scheduler is stopped, restarting the QOUT/QIN scheduler registration clears the backlog without touching any individual entry. Only after the root cause is fixed should the first LUW be reprocessed or, if genuinely obsolete, deleted with functional sign-off.

The reflex fix is deleting the blocked queue entries in SM58 or SMQ1 to 'clear the backlog', or repeatedly hitting execute LUW without reading the error text. Deleting entries discards real business transactions silently; downstream systems never receive them and reconciliation breaks days later when someone notices missing postings. Repeated blind retries against a dead destination or locked target just generate more dumps and RFC timeouts without changing the outcome, and can mask the fact that the scheduler itself has stopped.

Basis and integration teams own the RFC destination, gateway, and scheduler health. Functional teams own the business data inside the failing LUW. The handover note should state the queue name, the TID of the first failed entry, its exact error text, whether the destination tested clean, and whether it is safe to delete versus needing correction and replay.