Guarantee EOIO Processing in File-RFC-RFC-IDoc Scenario

[Former Member]

Looking for some opinions on the following set up we've got. We're trying to build QoS EOIO on a scenario that goes File Sender->RFC and then RFC->IDoc. My question is basically have we effectively ensured that our scenario will be EOIO from file to IDoc. We want the first record in the file to always be the first created IDoc, the 10th record in the file to always be the 10th IDoc created etc..... We also want to make sure that if we encounter an error at any point that all subsequent processing stops and waits until the problem is resolved. We've successfully completed some steps but my biggest concern is in the area between where XI sends the data to SAP1 via RFC and the resulting return RFC from SAP1. I'm thinking we may not be quite there yet and would be interested to hear what others thought.

We're on SP15. The scenario goes like this (no BPM):

1) We have a legacy system LEG1 that we pick files up from using the Sender File adapter. This step will take the file from LEG1 into XI and map it to an SAP remote function on SAP system SAP1. We set QoS on the file adapter to EOIO. Our interface determination for the File to RFC component is set to QoS of "Maintain Order at Runtime".

2) XI makes the RFC call to SAP1 (6.20) using an RFC receiver adapter. The called function then processes the data and returns the data back to XI using another remote function call. This function call is of type tRFC where we call the function "in background task" and issue a commit after the RFC call.

3) We receive the data into XI from SAP1 using the RFC sender adapter. XI maps it to our IDoc layout and sends it onto another SAP system called SAP2. Again here our interface determination QoS is set to "Maintain Order at Runtime".

4) XI passes the IDoc onto SAP2 (7.00) using a receiver IDoc adapter. The paramter Queue Processing is turned on.

[henrique_pinto]

First of all, RFC Sender does not have EOIO QoS. So, even if you guarantee EOIO in 1st part of your scenario, 2nd part is unknown.

The configuration in Interface Determination that you've made is basically for when you have several inbound interfaces being determined at interface determination (and you want to maintain the order in which they were inputed).

What kind of information does the sender RFC gather in order to trigger the IDOC?

Would it be possible to trigger the IDOC directly from the File?

Is it possible to use ABAP Proxies instead of RFCs (they have EOIO at sender side).

Even if you guarantee EOIO during Integration Server processing, you can't guarantee anything about the processing time inside SAP1 system, so your Idocs can be triggered in different order of the input files. Unless you have file -> IDoc scenario, I don't see how you can assure that.

Regards,

Henrique.

[Former Member]

Henrique,

Appreciate the feedback. I really wasn't sure what the config in the interface determination was really used for so thanks for clearing that up. I have a question about your statement where you say RFC Sender does not have EOIO QoS. If the function module that calls the RFC back to XI uses qRFC rather than tRFC would that ensure EOIO QoS? I realize there is no setting on the RFC Sender but I didn't know if maybe I could control it with qRFC.

As for why we don't go direct to IDoc... we have to go to SAP1 to get some organizational data that doesn't reside in our legacy system and is defined in SAP1. I realize there are other ways to redesign this but we're not in a position to do that at this time. Hopefully in a later updated. As for ABAP Proxy that too isn't available as SAP1 is on a 6.20 system.

Again thanks for your response.

[henrique_pinto]

About EOIO in qRFCs, actually this is quite a polemic topic.

There is something you could do, allright, but it is controversial whether you could properly call it "EOIO" or not.

Refer to this thread for further discussion:

Supposing you call the other RFC before you commit work in the receiver RFC, and supposing you could have EOIO at 2nd RFC (sender RFC), all these assumptions could mean that you would guarantee EOIO end-to-end. But they are just assumptions.

You have to try it and stress test the scenario to guarantee the validity of this design.

One other approach would be a BPM with all steps in one single transaction (check BPM transaction handling). The steps would be:

File -> sync RFC -> Idoc

where the response of RFC should be the necessary information for triggering the IDoc, and all send steps would be in EOIO mode (set queue name in Send steps). Also, file sender adapter QoS should be set to EOIO.

But I'm also not sure that this will guarantee EOIO end-to-end (possibly not...)

Good luck.

Regards,

Henrique.

[Former Member]

Hi Shaun !!

I think that using ABAP Proxy for the 2nd step will be the best, instead of RFC, I mean ABAP Proxy-> IDOC, you also can export the current RFC definition and import it as external definition to create the message interface for the abap proxy structures generation. ABAP Proxy sender allows you to specify the queue id and send using QoS = EOIO.

Regards,

Matias.