Transaction and Error handling in Mediator 11g

Question

Hi Experts/Gurus/All,
We have following scenario in Mediators :-
For Inbound Interfaces :-
M1-->M2-->M3
M1 calls M2 and M2 calls M3
There are 3 mediators, Mediator#1(M1),Mediator#2(M2) and Mediator#3(M3)
M1 performs a FIle Read and do a ABO-->OAGIS conversion
M2 performs routing
M3 performs a OAGIS -->ABO(JDE E1) conversion.
Now,we are in middle to decide the Fault Handling Mechanism for this case.
M1 is Asynchronous , M2 is Synchronous and M3 is also Synchronous.
Question is :
1. M1 will start a new Transaction,Do M1 will propogate the same transaction to M2 which,as being Synch,propogates the same transaction to M3 ?
2. How will the commit and Roll back will be taken care of?
3. What if M1 errors out?
4. Whatif M2 errors out?
5. What if M3 errors out?
In question 3,4 and 5:
What will happen will the Full Transaction ? If M3 erros out,would the Entire Transaction Propogated by M1 will be roll back?
Also ,How about Error handling in this case:
Do I need to create seperate fault-policy.xml and fault-binding.xml for M1,M2 and M3 ?
Another Scenario is of OUTBOUND interfaces :-
M1-->M2-->M3
M1 calls M2 and M2 calls M3
However , M1,M2 and M3 are all Asynchronous.
In this scenarios how would I handle following :-
1. If M2 Errors out,I need the entire Interface which comprises of M1-->M2-->M3 to roll back?
2. If M3 Errors out,I need the entire Interface which comprises of M1-->M2-->M3 to roll back?
3. Seperate Transactions means I have to create seperate fault-policy.xml and fault-mapping.xml to handle errors?

Answer 1

Hi,
You could create a package, and use the OdiSqlUnload to export the data into a flat file (csv) from snp_check_tab, then amend it. Then create an interface to load the data from the flat file to your tables, either via external tables or SQL Loader.
Question is, why are you amending data going from source to target? there surely has to be something wrong with the Architecture (especially if you are getting errors in production). If you amend data, so that it is different in source as it is in target, then when it comes to regression testing, this will never match.
The errors should go be fixed at source, and either you, or the business should have access to do so.
Cheers
Bos