SAP Message RT198 - Minimum number of calls with status CPICERR

Diagnosis
Here, you see the number of tRFC calls which could not be carried outbecause of a problem contacting or communicating with the destinationsystem or external component. Such calls are optionally re-scheduled asbackground processing jobs and are retried. Whether these calls areretried and how many times they should be retried is specified for eachRFC destination in transaction SM59. By default, retry of calls is inuse.
You see here only tRFC calls with communication errors. Outbound qRFCcalls, which can also have this status, are not monitored directly.Rather, the alert monitor watches over the status of the queues to whichqRFC calls belong.
You can display communication errors with the ARFCSSTATE monitor(analysis method). You will also find detailed information in the ALEmonitoring tree on CPIC error calls that were generated by ALE.

Procedure
Normally, you should see few or no calls with communication problems.However, communication problems do not necessarily represent a problem.For example, CPI-C errors may occur if a server or system is down formaintenance. If the destination is returned to service before the retryinterval runs out, then the tRFC calls are automatically processed.
For this reason, alerts because of accumulations of CPI-C errorsinitially carry the alert criticality yellow.
If the CPI-C errors are not caused by a routine and self-correctingproblem such as servicing, then you must check the network connection tothe destination server or component. In addition to actual networkproblems, CPI-C errors may be caused by:

  • an inactive Gateway process in the calling or destination system

  • an incorrect CPI-C implementation in an external server

  • incorrect data in the definition of the destination in the calling
    • system (transaction SM59).
    You can test connections to RFC destinations in transaction SM59.
    After you have corrected the problem, affected calls are automaticallyprocessed if the retry interval has not elapsed.
    Otherwise, you can trigger processing an affected LUW by hand intransaction SM58 (the analysis method for tRFC).
    Once successfully processed, calls with communication errors areautomatically deleted from the tRFC work queue and will no longer appearin this monitor.