tRFC: React to alerts

What causes this issue?

This message describes how to respond to transactional RFC and queued
tRFC alerts.

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?

The following kinds of alerts can be triggered:
<ZH>Too many tRFC calls:</> If the backlog has occurred because of slow
processing of tRFCs in an external component, then you need only monitor
the backlog to ensure that is it is reduced. You should also try to
improve the performance of the external component or destination system.
If the backlog consists of outbound qRFC calls, then you should check
the qRFC outbound MTEs for problems with queues. If there are such
problems, then you should determine (using the analysis methods) whether
the backlog of calls belongs to the blocked queues or not. If not, the
queue blockage is unimportant. If so, then you could run into database
space problems if there is a lot of activity in the affected queues and
the number of entries waiting in the ARFCSSTATE table continues to grow.
If the backlog consists of qRFC calls but no relevant qRFC outbound
queues are blocked, then monitor the backlog to be sure that it is
reduced as calls are processed serially in the destination system(s) or
external component(s).
Note: if you have CRM or BW installed in your installation, then the
backlog of qRFC calls may be normal. Both of these components manage
qRFC activity themselves, and both accumulate calls in the outbound
queues in status RECORDED before triggering the execution of the calls
themselves. If the calls belong to CRM or BW queues, then you should
just monitor the backlog to make sure that it does not grow so large
that it causes DB space problems and to make sure that it is
periodically reduced.
If the backlog has occurred because of communication (CPICERR) or
processing (SYSFAIL) problems, then see the information on these types
of alerts, below.
<zh>Too many inbound qRFC calls waiting:</> Check the inbound queue
MTEs in this system to ensure that no queues are blocked. If queues are
blocked and the calls waiting belong to these queues, then you should
contact the owners of the queues and calls. If there is much activity
on the affected queues, then there is the risk that the calling system,
this system, or both systems will run into database space problems as
the calls waiting accumulate.
If no queues are blocked, then you should check whether any of the
problems described in SAP notes 378903 or 366869 apply to your inbound
qRFC calls. If not, then you should monitor the backlog to ensure that
it is reduced over time. You should also take steps to ensure that this
system can process the incoming qRFC calls more rapidly so that large
backlogs of inbound qRFC calls do not occur.
<zh>CPIC Errors:</> A CPI-C error indicates that the calling system
could not contact or could not communicate successfully with the
destination system or external component. The tRFC or qRFC call is
scheduled as a background job and is retried periodically. The number
of retries is set in transaction SM58 on in the analysis method.
To correct the problem, you need to check the communications link to the
destination. Aside from network problems, other likely causes of a
CPI-C error include incorrect destination information in transaction
SM59, inactive gateway process in the calling or in the destination
system, incorrect CPI-C implementation in an external component, and
inactivated destination system or component. You will find information
on the cause of the problem in transaction SM58 or in the tRFC and/or
qRFC analysis methods. The status message associated with an alert
contains the identifying TID, function, and user associated with a call.
If the call is an ALE call, then see the ALE monitoring tree for help
in correcting the problem.
Once the communication link is re-established, tRFC or outbound qRFC
calls that are still being retried are processed automatically. If a
call is no longer being retried, then you can trigger processing of the
LUW (logical unit of work) that includes the call in transaction SM58 or
in the analysis method.
If inbound or outbound qRFC calls have been affected, then check the
queue MTEs for any queues that have been blocked by the problem. If so,
determine (by speaking with the owners of the queues / affected calls)
whether there is much activity on the affected queues. If there is much
activity on the queues, then the calls waiting in the queues could
accumulate to such an extent that you run into database space problems
on this system and/or on the calling system.
<zh>SYSFAIL errors:</> A SYSFAIL error means that an error occurred
while running a tRFC or qRFC call. The function module in the
destination system ended abnormally with an exception. Such a call and
its associated LUW are not retried. You can get more information on the
error in transaction SM58 or in the analysis methods for tRFC and qRFC.
The status message associated with an alert contains the identifying
TID, function, and user associated with a call. If the call is an ALE
call, then see the ALE monitoring tree for help in correcting the
problem.
To correct the problem, you should consult with the users responsible
for the tRFC or qRFC transactions. The call and the LUW cannot be
completed until the programming error has been corrected.
If inbound or outbound qRFC calls have been affected, then check the
queue MTEs for any queues that have been blocked by the problem. If so,
determine (by speaking with the owners of the queues / affected calls)
whether there is much activity on the affected queues. If there is much
activity on the queues, then the calls waiting in the queues could
accumulate to such an extent that you run into database space problems
on this system and/or on the calling system.
<ZH>SYSLOAD errors:</> A SYSLOAD error indicates that not enough server
resources were available in this system to process tRFC and/or outbound
qRFC calls. The RFC system takes various measures (configurable by the
system administrator) to ensure fast processing of the SYSLOAD calls.
See SAP Note 319860 for more information on SYSLOAD processing.
You can correct SYSLOAD problems by increasing the number of servers
available for processing tRFC / outbound qRFC calls. Do this with
transaction RZ12.
<ZH>HOLD and EXECUTED status:</> These statuses can occur for inbound
qRFC calls, calls that are to be processed serially in this system. The
presence of calls with these statuses may or may not indicate errors in
your system. For more information, see SAP Notes 378903 and 366869.

Error message extract from SAP system. Copyright SAP SE.