In some scenarios it is necessary to collect IDocs. This can be done with BPM, as Pooja Pandey's blog shows. IDOCs (Multiple Types) Collection in BPM This works perfect when each BPM collects only few IDocs, for example 100 IDocs per hour. Depending on your hardware you might run into performance issues, when you try to gather more than 1000 IDocs per hour with one single BPM.
Another idea for collecting IDocs consists in using standard functionality of the IDoc. Instead of sending the IDoc directly to the XI via the IDoc adapter, you can download the IDocs gathered in a file with XML format. This file can now be uploaded by the sender file adapter. As the XML structure is the same as the IDoc adapter produces, there is no change of the behaviour of the message, besides there no single IDoc inside, but multiple IDocs instead.
As first step you go to WE21 and create an XML file port in the application system. Apply here a function module for creating the file name. You can use a standard module or a self-written module.
With WE20 you assign the port to an outbound IDoc.
Schedule report RSEOUT00 with a variant where you assign the IDoc type, the xml port and the number of IDocs which shall be collected.
The report collects all IDocs in one file, until the "Maximal number of IDoc" is reached. When you have for example 2400 IDocs and you set "Maximal number of IDoc" to 1000, you receive 3 files, two with 1000 IDocs and one with 400. Inside the file there is one IDoc tag for each IDoc.
Do not gather too many IDocs into one file. The file size should be considered carefully. Too large files might cause memory leaks, when your hardware is not sufficient.
The files can be uploaded by the sender file adapter. When you collect IDocs of the same type, the Mapping can be done the same way as for IDocs processed by the IDoc adapter.
Update 02/11/08:
With PI 7.0 EhP1 and PI 7.1 EhP1 the new feature of IDoc packaging in sender IDoc adapter will replace the workaround.
See the release note here.
33 Comments
