Requires Free Membership to View
When you register, you will start receiving targeted emails from my award-winning team of editorial writers. Our goal is to keep you informed on the hottest topics and biggest challenges faced by SAP professionals today.
Hannah Smalltree, Editorial Director
Your problem is application performance, not IDoc performance!I see that you apparently have already decided to process the IDocs in a batch run using RBDAPP01. From there on you are already beyond the interface processing and are within the application, i.e. everything that happens now is due to the processing application, in your case the SAPMV45A application. Parallel processing the IDocs is possible just by planning several RBDAPP01 simultaneous jobs. You would need an intelligent mechanism that guarantees that each jobs picks its own pile of IDocs to process. However, this will not solve your performance problem unless you have several app servers and have every job running on a separate box. There may be locking problems if the IDocs share same material master , customer master data etc, so this may become a difficult enterprise depending on the nature of your data.
I suggest you first try to analyze the IDoc processing performance to find out where the time is lost. This can be done by executing transaction SE30 or the program RBDAPP01 and a single IDoc. Then analyze the result and judge if there are sections that have a long processing time. Have a special look on user-exits and unexpectedly long database selects.
If this does not really help, there is still the old advice from Mama Blue: "Buy a bigger machine!"
This was first published in May 2003