05 CIF Troubleshooting

1

2

3

4

5



In transaction SMQR and SMQS you can see the resources available according to the settings of the rdisp/rfc* parameters. Call transaction SMQR and select ‚Goto„ >> ‚QRFC resources„. The result displays displays the number of work processes that can be used for processing the RFC request.



If DIA W Ps for tRFC/qRFC are constantly exhausted (DIA-WPs for tRFC/qRFC = 0), this indicates a resource problem. Either the RFC resources are not sufficient suff icient to accommodate the load or the qRFC processing is too slow. Note that the number of available resources in the system is a snapshot which relates to the load status of the system.



For tRFC and qRFC calls, the tRFC layer reacts r eacts by switching to synchronous RFCs RFCs instead of tRFCs or qRFCs. When the RFC is executed synchronously synchronously no further processes are needed for RFC processing. After finishing the processing for asynchronous tRFCs the program may again obtain free fr ee resources for further asynchronous tRFC calls.



To avoid overload situation the application can check the currently available resources using function module TH_ARFC_REQUESTS before calling RFCs.

6



The profile parameter rdisp/rfc_check rdisp/rfc_check can be used to strengthen the usage of quotas. Commonly, the problem is that only asynchronous asynchronous RFC calls will heed to the quotas being set. If there is a synchronous RFC call which is placed from within an asynchronous RFC, RFC, the quotas will not be adhered to by the synchronous RFC call.



By setting the parameter rdisp/rfc_check rdisp/rfc_check to 2, this will change. Any RFC cascade that starts with an asynchronous RFC call will be handled as if all of the RFCs in the cascade where asynchronous asynchronous RFC calls. You can even increase the value to 3 which would result in ALL RFCs being forced f orced to adhere to the quotas being set. However, this setting must be tested carefully, because it may result in resource r esource shortage by means of free dialog work processes.



RFC parameters may be changed dynamically (transaction RZ11 or via RFC server groups transaction RZ12) if resources are continuously exhausted. However, the changes are lost during restart.



Wrong configuration of CIF setting/parameters and lack of resources can slow down the CIF transfer/process or even worst, block the whole system.

7



The parameter 'rdisp/rfc_min_wait_dia_wp' 'rdisp/rfc_min_wait_dia_wp' indicates how many dialog work processes cannot be blocked using RFC. This prevents all dialog processes being occupied by parallel RFC requests. The default value is 1.



If 10 dialog work processes are configured on an instance (rdisp/wp_no (r disp/wp_no_dia _dia = 10) and the parameter rdisp/rfc_min_wait_dia_w rdisp/rfc_min_wait_dia_wp p is set to 2, maximal 8 dialog processes can be used for processing tRFC/qRFC call. In either case, 2 dialog processes are kept free for „real‟ dialog activities.



In the system, this can be verified as follows:





Determine the AS group which is assigned to the QIN scheduler (transaction SMQR)



Verify RFC parameter settings for this AS group (transaction RZ12 => choose corresponding AS group)



Determine the number of configured DIA work processes (Min. no of free W Ps) Attention: This number is taken from the active operation mode, not necessarily from the instance profile !

These numbers are visible in transaction SMQR => Goto => QRFC Resources.

8



To avoid that all available RFC resources are used by one user, the parameter rdisp/rfc_max_own_used_w rdisp/rfc_max_own_used_wp p can be set. When a user issues an RFC call it is checked how many processes the user has already occupied (RFCs or online dialog steps). The value is specified as a percentage of the configured dialog work processes. The default value is 75.



Example: There are 10 dialog work processes configured. If parameter rdisp/rfc_max_own_used_w rdisp/rfc_max_own_used_wp p is set to 50, maximal 5 dialog processes can be used by a certain RFC user / application at the same time. This is the minimum of the number of dialog work processes than can be used for tRFC/qRFC (10-2=8) and the share defined by rdisp/rfc_max_own_used_wp rdisp/rfc_max_own_used_wp (50 % of 10 = 5).



In the system, this can be verified as follows: 

Determine the AS group which is assigned to the QIN scheduler (transaction SMQR)



Verify RFC parameter settings for this AS group (transaction RZ12 => choose corresponding AS group)



Determine the number of configured DIA work processes (Max. no of WPs used) This number is taken from the active operation mode, not necessarily from the instance profile ! Attention:



The available resources are visible in transaction SMQR => Goto => QRFC Resources. Note that the number of available resources in the system is a snapshot which relates to the load status of the system.



It is reasonable and recommended to restrict the resources for one RFC user / application because there may be other applications working with RFC calls and occupy dialog work processes, for example IDoc processing.

9



If the parameter rdisp/rfc_use_quotas is set to 1 the RFC resource parameters are used. You should NEVER change the default value. If the parameter is set to 0, then you can no longer work with the parallel RFC since no server can be determined for the next RFC.



The parameter rdisp/rfc_max_queue is percentage of the RFC entries that are allowed in the dispatcher queue until no further resources are given to RFC processing. However, However, the elements in the dispatcher queue are only increasing significantly if all work processes are used. Vice versa, as long as work processes are free, the dispatcher queue is (almost) empty. Therefore, as long as other RFC parameters are set, this parameter is not effectively ef fectively controlling controlling RFC load.



The parameter rdisp/rfc_max_login and rdisp/rfc_max_own_login are percentages of the logins of a single RFC user and the total of all RFC users compared to the maximum number of logins allowed. allowed. A dialog user usually stays logged on for a long time, usually all the time while working with the SAP System. Therefore, the number number of total connections allowed is usually much higher than the work processes configured. An RFC user however, however, usually logs off, of f, when the RFC is processed. The total connections of RFC users is close to the number of active work processes processing RFCs. Therefore, this parameter is not effectively controlling RFC load as long as other parameters are set.



For more information on these parameters see SAP note 74141.

10

11

12



The data constellation inside the CIF queue varies widely and depends highly on the objects types and on the business process triggering the transfer.



Number of queues = Number of entries:





1. possibility: Each object is sent in a separate queue and and one LUW uses exactly one queue. There are no (or only few) dependencies between between the queues so that the QIN scheduler can start the LUWs with a high parallel degree. There There is no (very low) risk that errors in queue processing block each other (no serialization). If the processing is too slow, a resource bottleneck can be assumed.



2. possibility: There is one LUW containing a huge number of objects that are using separate queue names each. In this case, the QIN scheduler cannot start the LUW in parallel (1 LUW => 1 work process). The processing of this large LUW may be not successful (timeout).

Number of queues APO) shows data concerning the data volume and the performance on the timely basis specified in the user settings (per minute, hour, day or month).



The data is shown for the following documents: purchase documents (purchase orders and purchase requisitions), in-house production (planned orders and production orders), planned independent requirements, stocks, sales documents, inspection lots, reservation items, GI-posted document items, location products and locations (master data).

33



The data from CIF cockpit can be downloaded into MS excel file. Based on this format, the data can be prepared in various ways. Doing so, a good overview about the object types transferred per time frame (hours, day) is obtained. Peaks in CIF traffic are clearly visible.

34



The transaction ST13 provides an extended qRFC m onitoring included in tool CMO system monitoring. The transaction ST13 is contained in the component ST-A/PI - Application Servicetools.



Note that this is an expert tool which requires the preconditions mentioned above. It is preferable to be used for VTO tests and not recommended recomm ended for permanent usage.

35



The CMO system monitoring can be started upon request with a default runtime for the next 7 days. The system ID is filled by default with the current RFC destination. There are a couple of key figures measured and recorded (CPU utilization, m emory consumption, number of active work processed etc.).



The TRFCQIN snapshot counts and records the following figures: 

Number of entries in status SYSFAIL / CPICERROR



Number of entries in status READY



Number of entries in status RUNNING



Beside this, the number of entries are counted per object type for the m ost common types: CFCO, CFEP, CFIP, CFLD, CFPO, CFTO, CFPLO, CFFCC, CFPPO, CFRSV, CFSHP, CFSLS, CFSTK.



The extended qRFC monitoring itself is activated by flag ‚with QRFC -counter„. This will force the QIN and QOUT scheduler respectively to count the processed LUW s (inbound and outbound) and the number of queue entries per LUW .



 All key figures are recorded will be done with a period period of 60 seconds.

36



The figures recorded by CMO system monitoring can be displayed upon request on a daily basis. The flags for the corresponding c orresponding key figures have to be activated; otherwise they will not be displayed.



If several application servers (instances) are c onfigured, the figures can be displayed separatly by activating the flag ‚details of all application servers„.



If several systems involved in qRFC processing, these can be monitored m onitored and displayed displayed seperatly.

37



This example shows the result of a volume test for f or CIF outbound processing. The figures were downloaded to Excel.



In this slide you can see the real outbound scheduler throughput.

38

39



Traditional behavior: The algorithm the QIN scheduler is using to activate LUWs that do not have a predecessor does not allow a uniform usage of the maximum number of work processes that are available available for f or rfc. Once the quota is reached the QIN scheduler waits until at most 10 work processes are still active with rfc-processing before the next LUWs are activated. This leads to the following structure of active rfc work processes when the quota allowed 363 work processes at maximum. The time interval from one peak to the next is around 20 s. The threshold was defined with the absolute value 10



Improved behavior: behavior: The threshold value can be set using the static profile prof ile parameter rfc/inb_sched_resource_threshol rfc/inb_sched_resource_threshold. d. This parameter is available available as of certain kernel patch levels (see the Note 1115861).



SAP Note 1115861 provides a correction to get a more uniform population of the work processes after resource bottlenecks considering considering the threshold. That will enhance the speed of the QIN scheduler up to 50%.

40



If performance problems occur occur when a large number of CIF queue q ueue entries in the inbound queue is processed by the standard QIN scheduler, you can use the /SAPAPO/CIF_EMRG_QINSCHED /SAPAPO/CIF_EMRG_QINSCHED program to process these CIF queues.



Note that you should only use the program in emergencies ( e.g. post processing CIF entries after upgrade ). Do not use this program as standard to substitute the QIN scheduler.



Report /SAPAPO/CIF_EMRG_QINSCH /SAPAPO/CIF_EMRG_QINSCHED ED is in standard as of SCM 5.0. See SAP note 869399 for details.



For CIF outbound emergency scheduler see SAP Note 1055902. It is currently

available as of SCM 2007.

41

42

43

44

45

46

47