R/3 -> XI Idoc Collection Based On Same tRFC Call

[Former Member]

We have solution where RSEOUT00 sends idocs out in one tRFC call to a system running Mercator. These idocs represent 1 transaction if you will, and are then mapped into 1 outbound file.

I am trying to figure out what the best option to do this in XI is. The requirement is to not collect based on a deadline, but to collect based on the chunk of idocs that were released online by the user in the same RSEOUT00 transaction.

Is this possible or any suggestions to accomplish this? I do have the flexibility to customize RSEOUT00 (its already custom actually) and have been toying with the idea of sending another message that is an "all are sent" or even something like a control message with a listing of all of the idoc numbers that belong to that group, but have yet to come up with a design that I'm comfortable with as the idocs are all sent asynchronously thorugh tRFC.

Thanks

Peter

[MichalKrawczyk · Accepted solution]

Hi Peter,

try with this appraoch

/people/stefan.grube/blog/2006/09/18/collecting-idocs-without-using-bpm

and set the file adapter to get your IDOCs

more often then you will schedule RSEOUT00

Regards,

michal

-

---

<a href="/people/michal.krawczyk2/blog/2005/06/28/xipi-faq-frequently-asked-questions"><b>XI / PI FAQ - Frequently Asked Questions</b></a>

[Former Member]

I was thinking of modifying RSEOUT00 to pass out a synch RFC that kicks off the BPM. In it I include the number of IDOCs about to be released and a GUID. Then I also modify the EDI_DC40 of each IDOC and stick the GUID into one of the fields. Then my BPM will have a correlation on the GUID and a loop counter to satisfy on the number of Idocs. When I match, complete the loop and move into transformation step.

Thoughts?

[Former Member]

Hi Deepu,

I ended up using table IDXSNDPOR to retrieve the TID + the count of idocs in that TID for each of the idocs entering the BPM in the interface determination mapping before entering the BPM through RFC Lookup API. Then I did a correlation on the TID, and in my infinite receive loop I am incrementing a counter and testing the loop condition against the count of idocs. Solution is working perfectly as designed.

Only thing is that I am averaging about 1.5 to 2 seconds per IDOC collection in the BPM, which I should have been aware of up front from all of the posts about performance in this area, but decided to give it a shot anyhow. This poor performance will more than likely require a different kind of solution.

Thanks for letting me know about table IDXSNDPOR. It is a very helpful table for IDOC processing.

Peter

[Former Member]

Thanks Michael.

Actually, I've considered that solution as well. I forgot to mention that these idocs are external payment orders which can't be persisted to disk for controls purposes. They need to remain as secure as possible to change (viewing not so critical).

Anything else?

[Former Member]

Hi Peter,

If we can check the TID of the IDOC then that make your job easy..is it not ?

Because all the IDOCs send in one tRFC call will have the same TID..

Now i am trying to see what is the best way to get that...i checked standard context objects given by SAP ..it doesnot have this TID :(...

I have suggestion ..this will work for sure...however it maynot be the most optimal one...

In the BPM where you are collecting IDOCs...after the recieve..have a mapping from IDOC to a dummy message which will basically return TID....now this mapping should be an ABAP mapping ...now from the ABAP code...query the IDXSNDPOR table and get the TID for the current IDOC and return it..

Back in the BPM, check if this is a new TID or not...if it is new..we can bundle it and stop the collection...

if we have a better way to get the TID.....we can make this better...

Thanks.