We often want to include a BPEL process in the calling transaction, and this recipe shows how to modify the BPEL process to do this.
In JDeveloper, open the project that has the BPEL process that we want to make part of the calling transaction.
- Switch to Source View.
In JDevelper, open
composite.xmlthat contains the BPEL process and click on the Source tab at the bottom of the diagram:
- Add a Transaction Required property.
Find the component that corresponds to the BPEL process in Source View; the component name attribute will be the same as the name of the BPEL process. Add a property called
bpel.config.transactionwith the valuerequiredto the component, as shown in the following code:<component name="TransactionIDProcess" version="1.1"> <implementation.bpel src="TransactionIDProcess.bpel"/> <property name="bpel.config.transaction" many="false" type="xs:string">required</property> </component>
The BPEL process will now participate in the same transaction as the caller of the process.
When creating a BPEL process with sync delivery in SOA Suite 11.1.1.6 and higher, we can specify the transaction attributes of the BPEL process as required or requiresNew. This sets the bpel.config.transaction property.
The bpel.config.transaction property has two values:
These properties define the transaction semantics of the BPEL process to which they are applied. Any JCA adapters, such as a database or JMS adapter, can also be executed in the same transaction context as the BPEL process.
When executing, the BPEL engine keeps track of which activities have occurred by updating the state in the dehydration database. This updating of the process state is done in the same transaction context in which the BPEL process is being executed. This keeps the state of the BPEL process in sync with the state of the resources used by the BPEL process. These updates are only committed when the process is dehydrated or a RequiresNew process is completed. One way in which this can occur is following a call to a non-idempotent partner link.
The BPEL engine uses a separate transaction context to keep a record of which steps were attempted; this is used to update the database with logging information and means that even if the BPEL process transaction rolls back, it will be possible to see what activities were executed before the rollback. This aids in debugging a failing BPEL process.