Hi Anirban,
I assume you use one stored procedure to update header table in database and another Stored procedure to update Item table.
On analysis, I was able to understand why it starts updates in the tables again.This is because all the Statements execute from within a message so even if one of them fail, the JDBC retry happens. This can be manipulated at 2 places.
One in the adapter in ID.
receiver JDBC adapter Advanced mode: Number of retries of database transaction on SQL error - 0 and another in RWB, comm channel monitoring -> Choose the particular adapter-> settings-> Maximum number 0 and choose overwrite.
Coming back to your solution, at runtime, the 5 StatementName calls execute as separate LUWs.
I assume you use one stored procedure to update header table in database and another Stored procedure to update Item table.
If you have to make this work, it has to execute as one LUW and not separate.
however, In the current design, this is how I think you can make it work.
The stored procedure for item table should be written such that if any of the insert fails, then delete the other line items (say for that Order) from the item table as well as the header line in the Header table assuming line item table and header table share the key field (say Order number). Likewise, if the header table update fails, delete the line items from the item table.You will need to suggest this to the database team and see if they can code it that way.
From PI perspective, you will get the error in PI in this case with no retries. If it was because database was down,then the message can be resent from RWB; else cancelled and transaction keyed in ECC with correction.
Hope it works.
Ambrish
PS: this solution should be implemented only on staging table. I won't recommend on actual DB tables.