Skip to Content

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.

image

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.

image

With WE20 you assign the port to an outbound IDoc.

image

Schedule report RSEOUT00 with a variant where you assign the IDoc type, the xml port and the number of IDocs which shall be collected.

image

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.

To report this post you need to login first.

33 Comments

You must be Logged on to comment or reply to a post.

  1. Mickael Huchet
    Hi Stephan,

    Interresting way, but in my mind the notion “Collect Idocs” inside WE20 will send ONE by ONE all collected IDocs. And you will generate several files which contains only one Idoc data. After that, inside XI, each file will be pick up by different processes, and you will have, at the outbound of XI, several files (for instance) and only one with all collected data.

    Is that right? or may I forget something?

    Mickael

    (0) 
    1. Anonymous
      Hello,

      One of the most efficient ways of handling this scenario is to use a combination of collecting idocs and BPM
      1. Collect all the idocs and send one by one to XI
      2. Collect all the incoming idocs into a single IDoc using BPM ( BPM set on infinite loop with a break condition set on time – 1min). This way the BPM will be in memory for the defined time interval.

      Cheers,
      Naveen

      (0) 
      1. Satish Chauhan
        Collect BPM is good approach, but the problem arises when the volume is high.

        BPM takes hell lot of time to push all the messages. The bottleneck is BPM queue. All the idoc messages with multiple parallet integration engine queues assigned to one BPM rfc queue. It takes more than an hour for processing 1000 idocs with collect pattern aaproach. If the volume is more than 5000 Idocs than its all luck.

        No matter what processor or XI sizing you use, you cannot improve performance by 10 %.

        We were troubled a lot with collect aaproach finally we decided the said approach last year where volume is high.

        Cheers,
        Satish

        (0) 
      2. Rani Bindu
        Hi,

        As I get from SDN posting many a times the BPM way of handling is said to be performance overhead. Kindly can you explain in details how handle the performance if we use BPM for collecting idocs.

        (0) 
  2. Satish Reddy
    Stefan,

    The weblog is very good. It explains us clearly the easiet approach for collecting Idocs. Also can we add one more criteria like 5 minutes i.e., send all the IDocs which are created with time limit 5 minutes or number of Idocs say 100. If any of the condition is true then it should execute.

    —Satish

    (0) 
    1. Stefan Grube Post author
      When you want to collect all IDocs produced within an hour, you have to schedule the report RSEOUT00 every hour.
      If you have more complex criteria and small numbers of IDocs you better use BPM.

      Regards
      Stefan

      (0) 
  3. Caterina Camurri
    Hi,
    I am using your approach in order to be able to count all the IDoc collected on recipient port, because my target message belong to a file, that wants in its trailer the total number of sent messages.
    My problem is that I have to manage the acknowledgment too in order update the IDoc status,but the file adapter on sendere side does not allow this.
    I am afraid to use BPM, cause this interface is supposed to have as max volume much more than 1000 IDoc.
    Do you have any suggestion? Is there another method to count the collected IDocs?
    (0) 
    1. Stefan Grube Post author
      If you need an ack for the IDoc, you have to go for BPM.
      After some efforts of the development, the performance of the BPM improved. So it can handle more than 1000 Idocs per hour. Apply the latest SP.

      Stefan

      (0) 
  4. ANDRZEJ DANIELEWICZ
    Hi Stefen,

    This is very useful information.

    Regarding this method I would like to ask if there are any limtations on how many/how big Idocs can be merged using this method? We want to use it, but we estimate that it may be over 500 Idocs to be merged this way (each of them may have up to 300 small segments) for one RSEOUT00 variant run.

    Are there any other limtations/risks of this method you need to be aware, when using this for a big no. of IDocs? (eg. does it impact this functionality if working in a cluster with multiple application servers?)

    Thanks in advance
    Andrzej

    (0) 
    1. Stefan Grube Post author
      The maximum size of the file depends on the hardware sizing. If the file has more then 20 MB you may run in performance issues and have to consider this while choosing your hardware. More than 200 MB might be critical.

      Regards
      Stefan

      (0) 
  5. Vasilios Triadafillis
    Nice article. 🙂
    I wonder if this one could be combined with program RBDMIDOC which in my case is used to send changed customers. As far I know RBDMIDOC creates a single Idoc for each changed customer. Having an easy way to create one single Idoc for all changed customers.
    (0) 
  6. Yash Agarwal
    Hi Stefan,

    The blog explains how we can collect many Idocs of same type and send it as a file. What if I need to read multiple Idocs (from the sender) and put only specific data in the receiver file?
    I mean reading perticular segments from different idocs and combining it into one sender file.

    Hope I am able to make myself clear.

    Thanks,
    Yash

    (0) 
  7. S V
    Hi

    I was tryinn this scenario… before that i want to ask like i can give any path in the Physical directory or it should be soe specific.

    sv

    (0) 
  8. Guna Ranjan Nallam
    Hi,
    I went through this blog and done the same in my system.  I am unable to get complete idoc strucute, i am getting only control record, pls help me if any one have diea on this

    Guna

    (0) 
  9. Sabyasachi Mohapatra
    Hi Stefan
    I have one doubt regarding about how the idocs are converted into idoc-Xml format ,that is usually done by the idoc adapter when we transfer the idocs using the trfc port.Are the idocs in the complete xml format when u r collecting it into a file prior to sending it to the integration engine of xi.could u please thru some light on this.

    Regards
    Sabysachi

    (0) 
    1. Stefan Grube Post author
      The structure of the IDoc XML in the file is the same as the structure that the IDoc adapter creates. So you can use a mapping based on the IDoc structure as usual.

      Regards
      Stefan

      (0) 
  10. Anoop Garg
    Hi Stefan,

    I am collecting multiple IDocs(~8000)in a single file. For this,I have explored option by using XML-HTTP port through which all IDocs in a single message are directly sent to Integration engine of PI and other is creating a XML-File port through which a file with information for all IDocs will be created and used further.

    Please suggest which approach would be recommonded to use in this case with pros & cons.We are working on PI 7.1 SP05.

    Regards,
    Anoop Garg

    (0) 
  11. vinodh balasubramaniam

    Thanks Stefan for this blog.

    I’m having a similar requirement in my project. I have tried to set up the following

    Partner Profile – Collect IDOC

    PORT – XML FILE Port

    Once the IDOCs generated with status ’30’. I’m trying to Execute RSEOUT00 with the Message type and Receiver PORT details. The program is picking all the IDOCs with status ’30’, but it is showing only the last IDOC in the file. It is trying to overwrite the existing records.

    Any idea, where I’m going wrong and how to generate a file with all IDOCs relevant to the selection in RSEOUT00.

    Thanks in advance for your reply.

    Regards,

    Vinodh

    (0) 

Leave a Reply