|
Diagnosis Procedure
If the backlog consists of outbound qRFC calls, then you should checkthe qRFC outbound MTEs for problems with queues. If there are suchproblems, then you should determine (using the analysis methods) whetherthe backlog of calls belongs to the blocked queues or not. If not, thequeue blockage is unimportant. If so, then you could run into databasespace problems if there is a lot of activity in the affected queues andthe number of entries waiting in the ARFCSSTATE table continues to grow. If the backlog consists of qRFC calls but no relevant qRFC outboundqueues are blocked, then monitor the backlog to be sure that it isreduced as calls are processed serially in the destination system(s) orexternal component(s). Note: if you have CRM or BW installed in your installation, then thebacklog of qRFC calls may be normal. Both of these components manageqRFC activity themselves, and both accumulate calls in the outboundqueues in status RECORDED before triggering the execution of the callsthemselves. If the calls belong to CRM or BW queues, then you shouldjust monitor the backlog to make sure that it does not grow so largethat it causes DB space problems and to make sure that it isperiodically reduced. If the backlog has occurred because of communication (CPICERR) orprocessing (SYSFAIL) problems, then see the information on these typesof alerts, below. If no queues are blocked, then you should check whether any of theproblems described in SAP notes 378903 or 366869 apply to your inboundqRFC calls. If not, then you should monitor the backlog to ensure thatit is reduced over time. You should also take steps to ensure that thissystem can process the incoming qRFC calls more rapidly so that largebacklogs of inbound qRFC calls do not occur. To correct the problem, you need to check the communications link to thedestination. Aside from network problems, other likely causes of aCPI-C error include incorrect destination information in transactionSM59, inactive gateway process in the calling or in the destinationsystem, incorrect CPI-C implementation in an external component, andinactivated destination system or component. You will find informationon the cause of the problem in transaction SM58 or in the tRFC and/orqRFC analysis methods. The status message associated with an alertcontains the identifying TID, function, and user associated with a call.If the call is an ALE call, then see the ALE monitoring tree for helpin correcting the problem. Once the communication link is re-established, tRFC or outbound qRFCcalls that are still being retried are processed automatically. If acall is no longer being retried, then you can trigger processing of theLUW (logical unit of work) that includes the call in transaction SM58 orin the analysis method. If inbound or outbound qRFC calls have been affected, then check thequeue 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 muchactivity on the queues, then the calls waiting in the queues couldaccumulate to such an extent that you run into database space problemson this system and/or on the calling system. To correct the problem, you should consult with the users responsiblefor the tRFC or qRFC transactions. The call and the LUW cannot becompleted until the programming error has been corrected. If inbound or outbound qRFC calls have been affected, then check thequeue 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 muchactivity on the queues, then the calls waiting in the queues couldaccumulate to such an extent that you run into database space problemson this system and/or on the calling system. You can correct SYSLOAD problems by increasing the number of serversavailable for processing tRFC / outbound qRFC calls. Do this withtransaction RZ12. |