1333417 - Performance problems when processing IDocs immediately



Symptom

- All dialog work processes are used up processing IDocs.
- General performance problems when processing a high volume of IDocs.
- 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".

Other Terms

Status 64 No resources,immed. processing not possible.

Reason and Prerequisites

You are attempting to process a high volume of IDocs in the foreground.

Solution

The "Trigger Immediately" \ "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.

Notes:

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 (see SAP note 74141).


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).

4) See SAP note 1862248 "Delays sending outbound Idocs (status 30) which have been configured to transfer immediately " and SAP note 1872637 " Delays posting inbound IDocs (status 64) which have been configured to trigger immediately". These notes explain in detail how to configure outbound (note 1862248) and inbound (note 1872637) Idocs for background processing.

Header Data

Released On25.07.2013 18:46:49Release StatusReleased for CustomerComponentBC-MID-ALE Integration Technology ALEOther Components

BC-MID-RFC RFC

PriorityRecommendations / Additional InfoCategoryPerformance

Validity

This document is not restricted to a software component or software component version

References

This document refers to:

Business Objects Notes1872637 Delays posting inbound IDocs (status 64) which have been configured to trigger immediately1862248 Delays sending outbound Idocs (status 30) which have been configured to transfer immediatelySAP Notes1597364 FAQ: BW-BCT: Extraction performance in source system527481 tRFC or qRFC calls are not processed384971 System parameters for high interface load74141 Resource Management for tRFC and aRFC

This document is referenced by:

SAP Notes (4)384971 System parameters for high interface load74141 Resource Management for tRFC and aRFC1597364 FAQ: BW-BCT: Extraction performance in source system527481 tRFC or qRFC calls are not processed