Improve performance of IDoc inbound processing for very large number of IDocs

[Former Member]

Hi there,

not sure if this is the right place to discuss this topic, but there is no ALE forum as fare as I see.

We are using RBDAPP01 in a 6.0 system to post very large numbers of IDocs frequently. We know SAP note 399271 and collective list 89471 but this one points to notes which are not longer available. The IDocs are COND_A as well as MATMAS (Number of IDocs > 250.000). The program is scheduled in batch with a package size of 100 now and does not use parallel processing. It is running in parallel to dialogues and other batch. The number of batch processes and even dialogue processes for this task is limited.

Even if there is no parallel processing, several IDocs are not picked up during the run and need to collect them in a later run. Parallel processing and also collecting small packages will probably cause more problems with this since the processing time of the packages is too long and IDoc creation overloads jobs processing them during their creation.

Processing is too slow for the number of IDocs and slows down during runtime of the job.

We are not sure about the procedure using IDocs itself and we are not sure, if there is a chance to improve, if we stay with it.

How would you post regular (not within a migration) large numbers of pricing updates and material masters? Is an alternative without using IDocs so much faster that any additional efforts replacing the lost functionality fore monitoring and resume what comes with IDocs will not result in the same performance problems?

And if we stay with IDocs: How to deal with the large numbers and avoid that jobs are running for too many hours and that running jobs are slowed down significantly during its runtime?

Thank you very much for your hints.

[former_member595583]

Hi,

Did you figure out answer of this, i am also looking for something similar as i need to post around 15 million pricing records(via interface, not migration as its not a cutover task its preodic refresh.