db (I) adapter user guide says,
Each dbAdapter opens a single session to the database. All operations are executed using dynamic SQL, and are committed after the integration component script is finished executing.
Is there any means by which the user can explicitly control the transaction across multiple integrtion component scripts invocation and either commit or rollback the transaction?
Does JDBC or any other database adapter support this
Perhaps the Join adapter would facilitate this?
Out of curiosity, what’s the nature of your integration that a single business transaction consists of multiple events?
When an ECO is released in the PDM, the BOMs need to be integrated into the ERP system.
Typically a ECO contains 100’s of BOMS.
The ECO is too huge to be mapped onto a single event. Instead the BOMs are the units.
At the target end the requirement is to integrate all the BOMs released in an ECO or none.
Hence the need to have transactions across multiple integration components.
We already have the integration in place for JDE for there exist business functions that support explicit user defined transactions.
The target ATC controls the transaction.
Makes sense.
How do you know when you have received the last BOM for a given ECO?
Seems like an alternative solution might be to collect incoming BOMs to a temp area. Once all are received, copy/move them to the “real” table.
Yes , However I dont know the size of ECO object or numbers of BOM but another alternative is to use Event with Struct arrays. Each member of the Array will be a BOM. The Source ATC can fill the values in Struct{} and the Target ATC can then break it up into Individual BOM and make an Insert / update into the Target System Or Execute the business Logic.
However if the size of ECO is HUGE then Alternately Store the BOMS in the intermediate database tables and once all the BOMs are stored then insert/update the first BOM event in the ERP this shud then generate the Functional Acknowledgement which will carry the Unique ECO number which in turn triggers the retrieves the next BOM from Intermediarte database and the process repeats till there aren’t any more BOMs for that ECO.
I have just attempted but there cud be better solns 
What are you using to do the insert/update to the target system? If it is an intelligent adapter, you don’t need to have the target ATC break up the BOMs. Keep them together and you’ll get the transactionality you’re looking for.