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

Question

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.

Answer 1

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: use EOIO on Sender RFC and outbound ABAP proxy calls
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.