Understanding the BPM Transaction Model

This section explains how transactions are handled in business process management (BPM) applications, including the following topics:

For an overview of transactions, and details describing transaction processing and EJBs, see Programming WebLogic JTA in the WebLogic Server documentation set, available at the following URL:

How a Transaction Is Started

The following three actions, which trigger the WebLogic Integration process engine to begin or resume its execution of a workflow, may mark the start of a new transaction:

Whether or not an API method call also starts a new transaction depends on whether the calling application currently has a transaction context. If an external transaction context currently exists (that is, if the application has created a transaction using JTA or has inherited a JTA transaction), the WebLogic Integration Enterprise JavaBean (EJB) uses it; otherwise, the EJB container automatically creates a new transaction in which to execute the call. With one exception (the Audit EJB), all EJB methods in the public API use container-managed transactions with the TX_REQUIRED transaction attribute.

Both XML and time-based events always start a new transaction.

Note: The WebLogic Integration Worklist application executes user commands by calling methods on the Worklist EJB within a discrete transaction. When you work with tasks in the WebLogic Integration Worklist application, the EJB container creates an encompassing transaction in which to execute each command. For example, the EJB container creates one transaction in which to execute a task, another in which to mark a task as done, a third in which to reassign a task to another user or role, and so on.

How the Transaction Is Committed

To understand how the transaction is committed, you need to understand:

Each topic is described in detail in the following sections.

How a Workflow Instance Is Processed

When first instantiating a workflow, WebLogic Integration executes the Created actions for all tasks in the workflow. It then processes the Start nodes, as follows:

The progress of the transaction after the initial instantiation depends on how the template definition is defined. Activation events propagate outward along the paths emanating from the point of origin, according to the built-in processing rules for each node type.

The following table describes the processing rules for each node type.

How a Workflow Instance Reaches a Quiescent State

When processing a workflow, the process engine returns control to the system once there are no more actions to execute synchronously—that is, when the workflow instance enters a quiescent state, in which it waits for the next request.

The workflow instance enters a quiescent state when the following conditions are true:

When an action instantiates a subworkflow, all work performed by the subworkflow up to the point at which it enters a quiescent state (if ever) occurs within the same transaction as the calling workflow. This work typically includes execution of actions in all called Start nodes, activation of all successor nodes associated with each Start node, and the actions associated with each successor. This processing propagates through the subworkflow, resulting in either completion or quiescence, according to the rules previously described. If the subworkflow runs to completion (that is, if it does not quiesce), the Completed actions in the parent workflow are also performed within the same transaction. If the Completed actions include an action to mark a task (for example, the parent) as complete, processing continues, the MarkedDone actions are performed, and successor nodes are activated.

How Exceptions Are Handled

When the process engine catches or throws an exception, the decision to commit or roll back the transaction depends on the following two factors:

The active exception handler can perform associated corrective actions and identify one of the following methods with which to proceed:

If the user transaction has not already been set for rollback only and the exception is recoverable (in other words, if the exception is a workflow warning), and the exception occurred while an action was being processed or an event variable was being set, the system allows the exception handler to decide the outcome. Otherwise, the system sets the user transaction for rollback only, invokes the active exception handler, and then rethrows the exception.

If an application enlists a BPM EJB in an external transaction and this EJB throws an exception that does not result in the user transaction being set for rollback only, the transactional behavior is defined by the application. On the other hand, if the BPM call succeeds, there is no guarantee that the transaction will be committed by the external application (or by the EJB). An exception or other error condition may occur subsequently, resulting in the rollback of the entire transaction.

How to Force a New Transaction to Start

For example, you can force a workflow instance to enter a quiescent state by defining one of the following task actions:

Examples of Transactions

When business operations are executed within a workflow instance, the following factors help determine whether the business operations are treated as a single transaction or as multiple transactions:

The following sections provide examples of workflows that are defined such that business operations are specified as part of the actions of one single task, and the actions of multiple tasks. Each example illustrates the scenarios as both a single transaction and/or multiple transactions.

Example 1: Business Operations Defined as Actions in One Task

For the first example, suppose that you want to execute three EJBs both as separate business operations and as part of the actions of a single task. Based on how you define the task properties, the three business operations can be treated as a single transaction or as multiple transactions.

Single Transaction

To have the specified business operations treated as a single transaction, the following example shows how you might define the task actions on the Activated Actions tab in the Task Properties dialog box.

Figure 7-1 Transaction Example: One Task, Single Transaction

Multiple Transactions

To have the specified business operations treated as multiple transactions, the following example show how you might define the task actions on the Activated and Executed Actions tabs in the Task Properties dialog box.

Figure 7-2 Transaction Example: One Task, Multiple Transactions

Example 2: Business Operations Defined as Actions in Multiple Tasks

For the second example, suppose you want to invoke three EJBs as separate business operations, and as actions in three separate tasks. Again, based on how you define the task properties, the three business operations can be treated as a single transaction or as multiple transactions.

Single Transaction

For this example, consider the following workflow template.

Figure 7-3 Transaction Example: Multiple Tasks, Single Transaction

If these statements are true, then the workflow instance does not enter a quiescent state before the execution of any business operation, and all three business operations are treated as a single transaction.

Multiple Transactions

For this example, consider the following workflow template.

Figure 7-4 Transaction Example: Multiple Tasks, Multiple Transactions

If these statements are true, then EJB1 and EJB2 are treated as a single transaction, and EJB3 is treated as a separate transaction.