2/10/2016 9:03:36 PM

Delays sending outbound Idocs (status 30) which have been configured to transfer immediately. Too many dialog work processes are used up processing IDocs.Delays sending outbound IDocs (IDocs "stuck" in status 30).

IDoc configured as "Transfer IDoc immediately" but the IDoc status are 30. Delays sending outbound Idocs (status 30) which have been configured to transfer immediately. Too many dialog work processes are used up processing IDocs.Delays sending outbound IDocs (IDocs "stuck" in status 30). The majority of these Idocs are not being transferred to the RFC layer immediately. When you display these outbound Idocs using transaction WE02 you can see they are stalled in status 30.

There are two reason which can contribute to this issue:

1) The IDocs are locked when the send process was triggered.

2) Destination BKPF is registered in SMQS with a set maximum number of connections assigned.

What this means is that the outbound scheduler will only be assigned a maximum of 10 connections to process these outboud Idoc requests at a time. When you have a large volume of Idocs to process this leads to delays and backlogs as outbound IDoc RFC requests must wait for an available DIA work process. To remove this "max connection" restriction you can exclude destination NONE from qRFC via the parameter "No tRFC"

Solution:

Where possible the "Transfer IDoc Immed." option should not be used for high volume, noncritical messages as this can often lead to resource problems. Instead you should use background mode to send the Idocs in packets.

Taking our example of outbound Idocs INVOIC to partner LS/TESTINGOUT you need to make the following changes so that going forward these Idocs are processed in packets in the background (instead of individually in the foreground):

1) Create a variant for program RSEOUT00 specifically for message type INVOIC and partner LS/TESTINGOUT:


This is the maximum number of IDocs whioch will be transferred to the RFC layer for processing in this single execution of report RSEOUT00 and default is 5000

2) Schedule a job to run very regularly which calls RSEOUT00 using the variant generated in step 1 (for example you could run this job every 20 minutes):   

3) Launch transaction WE20 

4) Select the destination partner in question  - in this example LS/TESTINGOUT

5) Then select the outbound message type  - INVOIC

6) In the resultant screen make the following 2 changes -> A.) Select "Collect Idocs" instead of "Transfer IDoc Immed." and B) Specify a packet size (in this example we have chosen to set the packet size to 10): 


The packet size parameter controls how many IDocs are transferred in each RFC call(one dialog work process is used per RFC call). If you specify a large packet size then you will requires less work process to handle a high number of IDocs(but it will take longer to complete each RFC request).

Note that there us no "correct" packet size setting. The optimum value varies between landscapes and is influenced by factors such as available resources, business requirements etc. Generally you need to test with different packet sizes when trying to decide what value is best for your individual situation.

These INVOIC IDocs for partner LS/TESTINGOUT will be processed with the scheduled runs of report RSEOUT00 (batch mode). This should then leave the  majority of dialog work processes free for users and mission-critical processes.

If you like this blog, please share (Facebook/LinkedIn/Google+) to click below links so it will reach to others.


COMMENTS