Transactional RFC and queued RFC

What causes this issue?

This monitoring tree in the CCMS alert monitor watches over activity in
the transactional RFC and queued TRFC facilities.
<ZH>Transactional RFC</> (tRFC, Remote Function Calls) is a facility for
transferring data between SAP systems or between an SAP system and an
external component. tRFC ensures the following:
that an RFC is carried out once and only once in a target system.
that all of the RFCs that are grouped into an LUW (Logical Unit of Work)
are carried out or that none of the functions is carried out.
These features of tRFC let programmers transfer data between systems
with the same safety and reliability that normal transactions allow
within a single SAP system.
<ZH>Relationship to ALE: </>ALE (Application Link Enabling), one of the
basic technologies of the SAP Business Framework Architecture, is one of
the most important users of tRFC. ALE uses tRFC as one of its methods
for echoing data changes from one system or component to another. tRFC
calls that carry the term 'IDOC' in the function name are ALE calls.
ALE provides mechanisms for recovering from errors in transferring data
between systems. You should therefore always check with the ALE
administrator before running or deleting a tRFC "IDOC" call, one that
was generated by ALE.
<ZH>Queued RFC</> (qRFC) is an enhancement of tRFC. In qRFC, tRFC calls
are serialized by means of output and input queues. <ZH>qRFC with
output queues </>ensures that (tRFC) calls are executed at the target
destination in exactly the order in which the calls were added to the
queue. Both qRFC output queue and normal tRFC calls are held in the
ARFCSSTATE table. Both types of calls are deleted from the ARFCSSTATE
table as soon as they have been executed. Calls in the ARFCSSTATE table
are therefore usually there because there was some problem in running
them, such as a communication or execution error (status CPICERR or
SYSFAIL) or a blocked qRFC output queue. qRFC input queue calls are
held in a separate table.
<ZH>qRFC with input queues </>ensures that calls coming in to a system
for a particular queue are executed in the order in which they arrive.
qRFC with input queues is used primarily as a load-control mechanism, to
prevent an RFC server from being overloaded by calls arriving in
parallel from different senders. qRFC with input queues calls are held
in table ARFCRSTATE. As with the ARFCSSTATE table, calls are usually
deleted immediately when they have been executed.

System Response

The system issues an error message and will not allow you to continue with this transaction until the error is resolved.

How to fix this error?

Monitoring tRFC activity: Normally, few or no tRFC calls should be
waiting in the ARFCSSTATE table. Further, none should show an error
condition: CPI-C Error or System Fail or System Load. There should
also be no qRFC queues that are blocked because of calls with errors.
You can check for problems using the ARFCSSTATE section of the
monitoring tree. It shows only tRFC calls.
The alert monitor's analysis methods give you access from this monitor
to the tools for tRFC and qRFC display and trouble-shooting.
Monitoring qRFC activity: The monitor reports on errors that stop
processing in inbound or outbound qRFC queues. You can also monitor the
total number of calls in the ARFCRSTATE table, in which inbound qRFC
calls for this system are held.
You should respond to a queue error alert promptly if you have CRM, APO,
BW, or other SAP New Dimensions components installed in your system. If
there is a lot of activity in a blocked queue, then the ARFCSSTATE and
ARFCRSTATE tables can quickly become large enough to cause space
problems in the database.

Error message extract from SAP system. Copyright SAP SE.