Skip to Content

This blog does not show any standard feature of XI – it’s just for some of you to think how some things could be done a little bit faster with our favourite middleware product ๐Ÿ™‚

As some of you know (it was also mentioned in my book: XI: New book: Mastering IDoc Business Scenarios with SAP XI) that in SAP standard it’s possible to specify IDOC’s package size in Partner Profile configuration (transaction WE20). Just like shown on the picture below. 


But what does it mean in terms of XI/PI ? If any of you ever tried creating IDOC RFC server using SAP JCO libraries (available under you know that if you specify the package size and collect mode all IDOCs (in this case 500) will be send in one RFC call. On the other hand XI/PI internally splits them and creates one XI message from one IDOC (even if they come from in one RFC). With some modifications you can revert this process and see all IDOCs in one XI message just like shown on the screen below. 



What does it mean in terms of performance (as this is the only criterium for which that test was made). I did only a small test but it shows a dramatic improvement in terms of XI processing. Have a look at the table below.    


Some info about the test:

1. I only checked a few test cases

2. My test landscape if far from perfect (tests values show avarage time of message processing based on a few same samples) 

3. Time taken into account is only processing time on Integration Engine (AWF not included) 

4. Messages didn’t have any mapping (so there might be even more improvement with that) 



If we could only use packaging with IDOC sender adapter:

1. Message processing on IE would be much, much faster 

2. Think how many less resources would we need if we had a mapping (with packaging we’d just need to call the mapping one – without that we need to call it once per IDOC…). I’m sure if I had any mapping involved that differences in processing time would be even greater. 

3. Another great thing – if we need to collect IDOCs in standard we need to use a BPM (with collect pattern) which is very memory consuming (apart from time consuming) process. If we could use IDOC packaging on the sender IDOC adapter there is no need for any BPM as the messages are already collected.


I’m sorry I’m not posting a code for this enhancement but it involves a repair (it’s not any user exit etc.) and it’s not that easy as it might sound (you also need to think about IDX5 etc.). Furthermore I’d rather SAP would add the same to XI/PI standard so we woundn’t have to do any enhancements like that.


What can we do?  

We can always post a Development request and hope that one day we will see this feature in XI/PI ๐Ÿ™‚

To report this post you need to login first.


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

  1. Former Member
    Oh yes, this is a long standing open issue. I guess the old design deciosion to keep things easy (as in duplicate detection, routing, splitting, merging, delay, status tracking) bite back on the XI team, and it is time to implement the batch processing model all the normal RFC- or batch-integrated external tools have been using for years.

    BTW: the old IDOC (inhouse) tunneling mode of XI, is that still available and does work with that batch setting, too?

  2. Former Member
    I am sure it would turn out to be a very useful feature if SAP adds this IDOC packaging feature in the sender IDOC adapter. Quite a few colleagues of mine have faced challenges when dealing with a very high volume of IDOCs in their client environment. They workaround this volume issue by creating a file-port in SAP, write the IDOC-XML out to a file, then they use the sender file adapter, poll these files(containing IDOC-XMLs using NFS etc), by using the “IDOC package” as the outbound Message interface, there by able to club IDOCs in one message using the “recordsets per message” feature of sender file adapter.
    Lot of clients use XI as a data migration tool as well(knowingly or unknowingly!!), there by forcing XI consultants to find workarounds to get XI to handle thousands of IDOCs, it will definitely be a relief if this feature is introduced.
    Good , you write about this and hope some one in SAP will positively respond.


    1. Michal Krawczyk Post author
      hi Saravana,

      that’s exactly my point – we need packaging but why use file port? we should be able to do it in standard as I did with my enhancement so that eveyrone will know that XI is the best to work with SAP interfacing technologies like IDOCs ๐Ÿ™‚

      thank you for the comment – great to hear from you:)


  3. Former Member
    Thanks and it is very nice to point out this requirement to SAP.
    This is a very long time requirement.. Let us see how it works out from SAP.

    Regards, Krishna

    1. Michal Krawczyk Post author

      >>> Let us see how it works out from SAP.

      exactly ๐Ÿ™‚ as if my developement for this requirement could speed it up so much (as per table) maybe SAP’s would be even much faster ๐Ÿ™‚


  4. Former Member
    Hi Michal,

    This is #1 on my wish list as well. It’s difficult to recommend XI to clients for medium/high volume IDoc scenarios knowing this limitation.

    Splitting IDoc packages into individual messages is required  to SAP certify an IDoc adapter, but most existing 3rd party adapters also provide the option to either maintain the package or to re-collect the messages prior to processing.

    I’m surprised that this hasn’t been added to XI yet because this is a common pain point on XI IDoc projects.

    Thanks for bringing this up. Hopefully we’ll see this supported in a future version.


    1. Michal Krawczyk Post author
      hi Jesse,

      I was actually amazed how simple it was
      for me to add this functionality via a little
      modification but of course without SAP blessing
      it will be difficult to show it to all clients
      since it’s not a “user exit” but a little repair..

      anyway I need this like air in “XI standard”
      so cannot wait ๐Ÿ™‚


  5. Former Member
    Hi Michal,
    thanks for your input and the comments of the community!
    We see that there is room for improvement and this topic is at the moment under investigation. I can not state yet, if there will be SAP standard solution and when.
    Next to speed a SAP standard solution must cover all related topics like: ACK, HopList, Guid handling, Size controll,…. and must not have negative impacts on the running customer scenarios.
    Feel free to come back to me on the status of investigations for this topic if you do not get news until end of Q1/2008.

    Thanks and best regards,


    1. Hi Holger,

      Any news on this topic. We are looking forward to have this feature.

      Tim Shen

  6. Former Member
    Hello Michal,

    It has already been told but once again this functionnality is really great and is expected by many XI/PI consultants, congratulation for this work !

    Do you know if it will be available as a PI 7.1 standard or will we need to wait for EhP 1 ?

    Thanks & regards !

    1. Former Member
      Hi guys,

      The Idoc packaging is part of EhP1 for PI 7.1. I have tested this already in our internal system.

      By the way: EhP1 for PI 7.0 is out now.

      Best regards

  7. Former Member
    Hi Michael,

    This is a great blog, and I’m very glad to hear that this functionality is in EP1.

    I have a question regarding the packet size in ECC6.0.  I realize this is slightly off topic, but I figured it was better than sending you an unsolicited e-mail.

    Is it possible to dynamically specify the packet size that gets set in ECC?

    For example, lets say I want to send data outbound once per day – is there a way to have ECC always send a single packet to PI in that once per day interface, regardless of size?


  8. Former Member
    Hi Subhashish,

    Can you please tell what is the maximum package size possible? In WE20 we can select maximum 9999, In my project the package size can go upto 2000 so I wanted to know if it will be a performance problem.


Leave a Reply