Transaction propagation from OSB to composite

Transaction context is not available by default between OSB and composite calls unless special care is taken.
OSB transaction scope/boundary depends upon below

1. Transport provider
2. QOS

Not all transport providers and all QOS semantics support transaction in OSB.We need to be particular to achieve transactions.

In this post, let's explore what is required to achieve this.We will take particular scenario and explain the steps
Scenario is OSB proxy consumes messages from JMS queue and invokes BPEL. In case of any failure either in OSB  or in BPE,L transaction should be rolled back and message should be available in JMS queue

To make above scenario statement true, we might need to develop services according to below principles

OSB design

• Use JMS XA connection factory on proxy service
• Please enable transactions on OSB proxy message handling to make sure messages are rolled back to JMS  queue.This setting essentially makes  proxy as sync service despite of original pattern

 

• If OSB proxies has error handler stages then use RaiseError action from error stage.
•  
• Make sure all publish/service call out actions in proxy flow has ‘exactly-once’ QOS otherwise they will be executed outside of transaction context 
• Do not  use "Reply with success or failure" from error handlers. This action will commit the transaction
• Create OSB business service with SOA-DIRECT transport which calls composite.Only SOA-DIRECT transport supports transactions 

Composite design

• Create composite with direct binding service exposure.Composite direct binding is compliant to SOA-DIRECT and invokes composite end point via RMI using t3/t3s protocol
• If BPEL has catch/catch all, then throw  Rollback exception to caller.If BPEL doesn’t has  catch/catch all then  system level fault handler will roll back the transaction to the caller
• If composite has fault-polices then transaction might not be rolled back to OSB in case of BPEL faults, so do not use fault-policies when planning for transaction propagation.Fault policies executes in its own thread and transaction, suspending existing transaction
• Set component  property name="bpel.config.transaction"  to “required”
• If we want to perform some tasks (DB,JMS) in BPEL outside of transaction scope then use NonXA connections