Skip to Content

Did you look at idxp and idxpw transaction? Do you have a scenario where ccBPM has to wait for long hours to aggregate Idocs? Doesn’t it hit performance? Is there a better way for handling this? Do you like to know some new feature? Read on!.

We could have come across a scenario where we have to aggregate 10 Idocs and send it to a file. All the 10 Idocs might not come at the same time. The simple solution that comes to our mind is to use a collect pattern in the ccBPM with a dead line-monitoring branch waiting for some X hrs. The problem with this approach is ccBPM has to be active until all the 10 messages are received which is memory intensive and time consuming. For Ex: 1st Idoc is triggered at 10 A.M and last Idoc is triggered at 6 P.M. ccBPM will be active once the first message is received and waits until remaining 9 idocs are reached. Or we might design a ccBPM to wait for 4 hrs and collect the idocs received within 4 hrs and post it as file. Both have a performance impact. We can get away with this bottleneck if the idoc adapter caches the idocs and sends it to a ccBPM at a single shot and we can re-design ccBPM to just wait for 1 or 2 minutes depending on the volumetric. Idoc message packages setting allows the idoc adapter caches the messages in the queue until the number specified in the maximum package entries is reached. It triggers all the entries in the queue once after the last idoc is reached.

Idoc Message Package Settings:
We have to apply the message package setting for every idoc that has to be cached in the adapter queue.
1.Pick the idoc number from idx5 transaction for the idoc that has to be processed as message package. Go to IDXSNDPOR table using SE16 or SE11 and pick up the field GUID (Message Id) for the idoc number.
2.We need to activate the Idoc message package option and that is done in idxpw transaction. We have to copy the GUID that is picked previously into the message id field of idpw transaction. Maximum Package Size tells the Idoc adapter that it has to send Idocs to the ccBPM only when it has received that many idocs. If we set it to 10 then idoc adapter caches the idocs in the queue until the last idoc is received. Once the transaction is executed successfully we can see the entries in the message filter and job through SXMB_ADM->Event Driven Message Processing.
Message Package Settings
3.We can monitor the entries in the transaction idxp .We can monitor idocs with message package settings here.
Monitor
4.Once we have configurations are done we can trigger 2 idocs and check the messages that are waiting in the queue package using tcode sxmb_moni and ccBPM instance is not created. Now trigger remaining 8 idocs from the sender systems and check the tcode idxp, which displays that there are no messages in the Idoc adapter cache and messages are successfully processed by the ccBPM and we can see the PE instance in second figure shown below.
Screen shots when 2 Idocs are triggered initially:
Check in idxp tcode
Package Queue
Screen shot when the remaining 8 Idocs are triggered:
Processed Messages

This approach is very useful as there is drastic impact in the performance. However the problem is “What happens if the 8 Idocs does not come even after 4 hrs due to some problems in the sender?”. We see all the messages stuck in the queue and file creation will be delayed which is not desired. We can schedule the SXMS_UNPACK_MESSAGES for every 4 hrs that can trigger the cached idocs even if the required number of idocs set in the package size parameter are not received by the idoc adapter. It will clear all the entries in the idoc adapter queue.
Unpack Messages
I have gone through the SAP help but did not get any useful pointers for achieving the feature. I explored it on my own and blogging as it can be useful for many. One more fascinating thing about this exercise is that I made it before XI champion michal.

To report this post you need to login first.

15 Comments

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

  1. Michal Krawczyk
    Hi,

    >>>One more fascinating thing about this exercise is

    it was on my list 🙂 but it’s great you’ve described it, I still have many more on my “secret list” so no need to worry 🙂

    blogs created by you are always quality weblogs
    so just keep writing them:) 

    Regards,
    michal 

    (0) 
    1. Anonymous
      Hi Sravya,

      Just 2 days back me and michal exchanged messages this topic….. before any of us you came out fast 🙂

      good work!!! Your blogs are good to read, keep up the good work.

      srayva/michal , i had this on my radar, but never mind,  have a long wish list tooo.

      cheers,
      naveen

      (0) 
  2. Praveen Sirupa
    Hi Sravya,

    To populate Message ID in IDXPW, how do we know it before we send the IDOC to XI?

    How can I apply this packaging only to certain IDOCs but not to all?

    thx
    praveen

    (0) 
    1. Sravya Talanki Post author
      If you have already triggered idocs previously and take the message id from the table idxsnd*.
      It applies to only idoc for which you have retrieved message id.
      (0) 
  3. Anonymous
    Sravya-

    Thanks for this nice blog. Is BPM the only way to aggregate IDOCs to be bundled in to one single file? While on the file to IDOC scenario we are able to bundle multiple IDOCs and route it as a package to SAP without BPM.

    Let me know your thoughts

    KK

    (0) 
    1. Sravya Talanki Post author
      Hi KK,
      As far I know it is not possible for the stack <=SP13.But we have new feauters of multimapping enabled in SP16.Probably you can try out with new feauters as our stack is still on SP12..:)..

      Message Packages pumps messages from Idoc adapter to integration piple line in periodic intervals or after maximum number of Idocs are reached.

      Probably you can also re-write the Idoc adapter to club all the Idocs as it z written in ABAP..:)

      (0) 
      1. Rani Bindu
        Hi Sravya,Micheal,

        We are with SP23. I see the options in IDXPW “Job period” and “Period unit”. So are these a option to setup waiting period for collecting idocs and then trigger the mapping process?.

        Also, currently we are handling one IDOC to 1FF using Graphical mapping. So do you think configuring in IDXPW will also workout for graphical mapping if we create mapping to handle multiple idoc to 1 ff scenario.

        Thanks in advance,
        Bindu

        (0) 
  4. Gopi Tiyyam
    Hi sravvya,

    Excellent blog, keep posting.

    please do make document line by line instead of writing it as single box,  so that it would be easy to read.

    Best wishes
    Gopi

    (0) 
  5. Akshay Jamgaonkar
    Hi sravya,

    We have a requirement that ,we are expecting 100 IDOCs to come.
    As i understood by your blog ,configuration has to be done only after receiving the IDOC …
    If it is the case ,would it be worth to use this in our scenario?

    Regards,
    Akshay Jamgaonkar.

    (0) 
  6. Maximiliano Colman

    Only works when one IDOC is related to 1 message, if you got 1 message with “N” IDocs does not work, PI consider the quantity of messages,not the quantity of IDocs in message

    (0) 
  7. Ha m

    Hi Experts,

     

    My scenario is like ECC– PI — BPM–PI—Third-party System. Where the BPM collects 10 IDOC based on IDOC’s generated on ID & merge as one single file. one confirmation IDOC from R/3 triggered to specify that these 10 IDOC’s are triggered on that particular ID for merge call and then process to target as one single file through PI.

    Now system is upgrading to single stack where the client do not want any BPM’s (licensing also taken like that). So please help me on this to achieve with out BPM concept.

    Thanks & Regards,

    Ham

    (0) 

Leave a Reply