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!"
Dig Deeper on SAP ABAP
Related Q&A from Axel Angeli
An SAP user wants to know how to upload data into SAP R/3 when SAP Scripting is not enabled. Continue Reading
An SAP user is receiving an error message while integrating SAP iDoc PORDCR1 for a purchase order. Continue Reading
An SAP user is having difficulty with PERNR iDoc while transporting data from SAP to an external system. Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.