Controls and Transactions

Business processes in WebLogic Integration are transactional in nature. Every step of a process is executed within the context of a JTA transaction. To learn about how transactions work within a business process, see Transaction Boundaries.

Some integration controls are transactional. This means that the control is able to participate in transactions within a business process. Whether or not a control is transactional depends on both the underlying resource and the specific control implementation. Also, transactional behavior differs depending on whether the control call is synchronous or asynchronous. To learn about synchronous or asynchronous operations in business processes, see Building Synchronous and Asynchronous Business Processes.

If the control and associated resource are transactional, the resource participates in the current process transaction
If the control and associated resource are not transactional, changes to the resource occur outside the scope of the current transaction and changes are not rolled back in case of failure

The process transaction is never propagated to the resource
Asynchronous control calls are buffered by default
Asynchronous call to the resource are not enqueued until the transaction is committed
On rollback, asynchronous messages are de-queued

The Process control is a special case, since it involves processes calling subprocesses.

The transaction is always propagated to the subprocess
An un-handled exception in a subprocess causes the shared transaction to be marked as rollback only. In this case, both the subprocess and the calling process are rolled back.
Setting the process property onSyncFailure=rethrow on the subprocess overrides this behavior and results in the following:

Failure does not force a rollback
Subprocess throws an exception
Calling process catches the exception, just as with any other control exception

The transaction is not propagated to the subprocess
The message is buffered on the subprocess' queue
The subprocess runs in its own transaction
The control call is successful if the message is properly enqueued on the subprocess' queue
Failure of the subprocess is not communicated to the calling process. For example, an unhandled exception causes the subprocess to fail but the caller process is not notified

Application View (if JCA adapter is transactional)
ebXML
Message Broker
MQSeries
Process (see the previously listed qualifications)
RosettaNet
WLI JMS
Worklist

File
Email
Http
Service Broker
TPM

Good Practice in Creating Web Service Controls for a Business Process Application

When you call Web Service controls asynchronously from business processes, it is recommended that you buffer the asynchronous call. After creating the Web Service control, specify that the asynchronous calls from the business process to the control are buffered. By doing so, you ensure that the message sent from the business process to the Web service is enqueued. An asynchronous call to a resource marks the boundary of a transaction in your business process; a call to a resource is not enqueued until the transaction is committed. In other words, by buffering the call to the resource, you ensure that the transaction is committed before any response from the resource is attempted. If you do not buffer the call, your business process must wait for the HTTP acknowledgement to occur before the transaction is committed, leaving open the possibility that the resource attempts to respond to the business process before the HTTP acknowledgement occurs.

Using Integration Controls

Controls and Transactions

Good Practice in Creating Web Service Controls for a Business Process Application

Related Topics