2/1/2016 1:13:03 PM

General performance problems when processing a high volume of IDocs in SAP

General performance problems when processing a high volume of IDocs in SAP-All dialog work processes are used up processing IDocs.Performance problems when processing IDocs immediately.Delays sending outbound IDocs (IDocs "stuck" in status 30).Delays posting inbound IDocs (IDocs "stuck" in status 64).Entries queued up on the sending side in transaction SM58(function module IDOC_INBOUND_ASYNCHRONOUS) with the status "Transaction Recorded". Status 64 No resources,immed. processing not possible.you are attempting to process a high volume of IDocs in the foreground.

Solution for General performance problems when processing a high volume of IDocs in SAP.

The "Trigger Immediately" or "Transfer IDoc Immed." options should not be used for high volume, noncritical messages as this can often lead to resource problems. Instead where possible you should use background processing.


Configure program RBDAPP01 (inbound) / RSEOUT00 (outbound) to run very

specifically for high volume message types on your system. Schedule regular runs of reports RBDAPP01 & RESOUT00. These can be run for IDoc Type and/or Partner etc.. (you can configure these reports to run for example every 10 minutes or as often as required).

Then change the processing mode for the IDocs in question as follows:

For inbound:

Go to transaction WE20 -> Select Partner Select Inbound Message Type and change the processing method from "Trigger Immediately" to "Trigger by background program".


For Outbound:

Go to transaction WE20 -> Select Partner Select Outbound Message Type and change the processing method from "Transfer IDoc Immedi." to "Collect IDocs"

What will happen then is that these IDocs will be processed via scheduled runs of reports RBDAPP01 / RSEOUT00 in batch mode. This should then leave the  majority of dialog work processes free for users and mission-critical processes. Hence you will no longer encounter the resources problems you are currently experiencing.

The only other option would be to try increasing the number of available dialog work processes. However when there are a large number of IDocs being processed this is not a practical solution.

Note:

1) Regardless of how you process Idocs (foreground or background) the number of dialog work processes must be greater than or equal to the total of the number of update and background processes per application server and must be configured across all operation mode switches.

2) Inbound Parallel Processing (RBDAPP01): It is important to understand that when scheduling RBDAPP01 to process inbound Idocs the parallel processing option effects how the Idocs are handled.

If parallel processing is enabled then the inbound processing of the application uses one free DIALOG work process for each IDoc packet on the application server ('asynchronous RFC' is used for this). This means that the packets can be processed in parallel. If several IDoc packets have been selected, then the IDoc processing could still occupy all the dialog processes on the application server. In this case you may need to increase the packet size / schedule RBDAPP01 to run more frequently to reduce the burden placed on dialog work process resources on the receiving system.

If parallel processing is not enabled for RBDAPP01 then the selected IDocs will not be processed in parallel. This means that each IDoc packet will be passed to the application in turn. Only one dia work process will then be used for this action on the application server.

3) Outbound IDocs sent via RFC (RSEOUT00): If the partner profile points to a tRFC port (RFC destination) then the packet size parameter in the outbound partner profile controls how many Idocs are transferred in each RFC call. Each RFC call uses a single dialog work process. What this means is, the larger the packet size the more Idocs are sent with each RFC call. This in turn would mean less dialog work processes are required to send the selected Idocs (but it would take longer to transfer these larger IDoc packets).


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


COMMENTS