![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
WebSphere® Integration Server Foundation V5.1 provides a business process engine called Process Choreographer. Business processes can be short-lived and execute in one single transaction -- then, they are called "microflows". Nevertheless, microflows can trigger actions whose effects cannot be undone automatically if the process transaction rolls back.
This article begins with a brief review of the concept of a microflow and how services relate to transactions. Then we explain the microflow compensation itself. The section, Microflow participating in the compensation of a long-running process, shows how the compensation of a microflow can be triggered by a long-running parent process. Finally, we provide a sample that illustrates these concepts.
A basic understanding of Business Process Execution Language (BPEL) and Process Choreographer is assumed.
There are two different kinds of business processes in Process Choreographer: Microflows (or non-interruptible processes), and long-running (or interruptible) processes.
Microflows are executed in a unit of work. This means that a microflow completes either successfully as a whole, or not at all. Only after all activities that make up the microflow have completed successfully, the transaction that encloses the business process and all its transactional activities is committed. For example, if an activity in a microflow updates a row in a database table, this database update can participate in the process's transaction and is then committed (or rolled back) together with the business process.
If a transaction rollback occurs, the complete business process, including all transactional activities is rolled back, for example, the database update that was attempted in a business process activity is rolled back as well. Activities with an implementation that is not transactional remain untouched.
The following figure shows a microflow and its transaction boundaries.
Figure 1. Microflow with Transaction Boundary
Process Choreographer processes microflows in memory and in a single thread. Therefore, a microflow executes with very good performance and throughput.
Observe that in the example above, the two activities "Change RoutingNo" and "Change AccountNo" are not processed in parallel, since the complete process is executed in a single thread. In fact, parallel activities in a microflow are executed sequentially. Their execution order in the sequence is not specified. The business process engine can execute them in arbitrary order.
Also, observe that the Process Choreographer database holds no information about process instances of microflows. Since they are executed in memory, no information about the microflow instances is written to the database. All data around microflow instances is transient.
Because a microflow is executed in one single transaction, it cannot contain the following activities:
- More than one receive or pick activity
- Staff activities
- An invoke activity that invokes a request/response operation with an asynchronous binding
If your business process requires one of these features, it must be implemented as a long-running process.
Service invocations and transactions
A service invocation is called transactional with respect to the process, if its effects are completely undone upon rollback of the current transaction and if they are persistently stored upon commit.
For example, a service that is implemented by a Java entity bean's business method is transactional. When the transaction of the microflow rolls back, the changes in the enterprise bean and its underlying database table are not visible.
A service invocation is called non-transactional if its changes to the environment are visible regardless of the outcome of the current transaction.
Samples for non-transaction services are:
- Sending an email.
- A SOAP service (since http does not support transactions).
- The invocation of an enterprise bean with a transactional attribute of "requiresNew".
- A connector to a legacy system, that does not support the two-phase commit protocol.
- Writing to the file system.
A microflow is compensated if and when the current transaction rolls back. Hence, compensation in a microflow is triggered by the infrastructure, rather than by application logic. The idea of microflow compensation is to reverse the effects of non-transactional services. Microflow compensation is run during the processing of the rollback, thus, neither the effects of transactional nor non-transactional work is visible to the outside world when it comes to a rollback.
A microflow has to be enabled for compensation by setting the compensation sphere descriptor to "required". To tell the process engine what to do upon compensation, the author of a microflow can model or undo services for each invoke activity in his process. In addition, the modeler has to specify whether a forward service is transactional or not. It is important to understand that an undo service can also be tied to a transactional invoke; however, it is never regarded in pure microflow compensation. Correcting actions for transactional work is important, if the unit to compensate has long-running character as outlined in the section, Microflow participating in the compensation of a long-running process.
The undo services are run in reverse order of their forward service's completion time. Only forward services that are completed successfully are undone. For undo services, the same restrictions apply as for services in microflow in general, that is, an undo service cannot be long-running. The undo service gets one input message that represents a snapshot of a process variable taken at the completion time of the forward action. The reverse action is conceptually a one-way function, since its output is ignored.
Figure 2 shows the forward execution and compensation of the microflow "microflow_1". The microflow has four invoke activities: "A", "B", "C" and "D". The service of activity "D" throws an exception that leads to a rollback and thus to compensation. The compensation calls the undo services for "B" and "A". "C" is not compensated, since its forward action is transactional. "D" is not undone because it did not completed successfully.
Figure 2. Microflow compensation
Microflow participating in the compensation of a long-running process
As already mentioned in the last paragraph, an undo service can be specified for transactional as well as non-transactional work inside a microflow. The need of undoing transactional work also comes into play, if the decision to compensate is made after the transaction is committed. This is the case if a microflow is called from the context of a long-running process and the microflow thus participates in the compensation of its parent process.
The picture below illustrates the long-running process "long_runner". The second invoke is implemented by the microflow "microflow_1", which we already know from the microflow compensation sample. Compensation in a long-running process is triggered, if a fault reaches the process boundary, that is, if the fault is not caught by a fault handler of enclosing scopes. Let us assume that such a fault happens in the third invoke of the long-running process. At this point preceding transactions are completed and committed.
Figure 3a). Microflow called from a long-running process
The compensation contains the undo services for the first invoke in process "long_runner" together with all four undo services of the microflow. This time also the transactional service "C" has to be compensated, because the transaction of the microflow is already committed.
Figure 3b). Microflow participates in the compensation of a long-running process
Now let's implement the business process "UpdateBankInfo". This business process is used to change the bank information of customers, for example, of credit card holders. It contains the following steps:
- Start the process with an update request. You can receive and store the data about the update in a process variable. This includes the customer name, the customer's credit card number, and the new account number. Optionally, a new routing number might be included.
- Update the routing number and the account number of the customer in the respective backend system(s). Observe that these updates are transactional in our scenario. For example, we could use entity beans to access the database(s) that holds the bank information. This means that we do not have to specify an <undo> operation for the update activities. If the business process fails, the database updates will automatically be rolled back.
- After you've updated the backend system(s) successfully, the process sends a confirmation email to the customers whose bank information has been updated. Sending an email is non-transactional. This means that even though the overall business process has not completed yet (and thus, has not been committed), the email is sent. If the business process, including the database updates are rolled back, the email is still sent.
Therefore, we specify both do and undo operation for this <invoke> activity.Attention: You must not check the box "Activity Takes Part in Transaction", because the email service is not transactional.
- To demonstrate the microflow compensation feature of Process Choreographer, you can simulate a server crash after the confirmation email has been sent. You can do this by using a <throw> activity.
- To enable Compensation for the UpdateBankInfo process, select Required for the Compensation Sphere attribute. Then, if a fault reaches the outermost scope of the process and is not caught there, Compensation is triggered.
The following image gives an overview of the UpdateBankInfo BPEL process:
Figure 4. Overview of UpdatebankInfo process
When the UpdatebankInfo process is started, the following things happen under the covers:
- A new compensation sphere is created for the UpdateBankInfo process. This is because the process has the compensation sphere attribute set to required and it is started stand-alone.
- The "Receive Update Info" activity stores the process input data in the UpdateInfo variable.
- The "prepChange" activity populates the variables ChangeRoutingNoIN and ChangeAccountNoIN.
- The two invoke activities "Change RoutingNo" and "Change AccountNo" are executed. They use the data in their input variables to update the customer's bank information.
This update is transactional. - The "prep Write Email" activity populates the variable EmailIN.
- The invoke activity "Write Confirmation Email" is executed and writes an email to the customer, confirming that his bank information has been updated.
This activity is non-transactional, and we have a compensation action defined for it. Therefore, the compensation action and its input data are added to this process's compensation sphere. - In our throw activity, we simulate a Server Crash. The transaction in which the UpdateBankInfo process is executed, rolls back. This means that the change to the customer's bank information is not persisted.
- Compensation executes all compensation actions that have been registered for this instance of the UpdateBankInfo process in last-in first-out sequence.
The undo action that we defined for the "Write Confirmation Email" activity is executed. It writes another email to the customer and explains that the update failed.
You can download the WebSphere Studio Application Developer Integration Edition service project for the UpdateBankInfo BPEL process, or get an installable EAR file for the UpdateBankInfo process in the Download section below.
This article presented the concept of microflow compensation and how to define corrective actions for the side effects of microflows.
| Description | Name | Size | Download method |
|---|---|---|---|
| microflowCompensationEAR.zip file | microflowCompensationEAR.zip | .2MB | FTP |HTTP |
| MicroflowCompensation.zip file | MicroflowCompensation.zip | .1MB | FTP|HTTP |
Information about download methods
- IBM WebSphere Developer Technical Journal: Modeling compensation in WebSphere Business Integration Server Foundation Process Choreographer
- WebSphere Information Center
- Business Process Execution Language for Web Services version 1.1
- WebSphere Business Integration Server Foundation Process Choreographer
- To learn more, visit the developerWorks WebSphere Application Server zone and the developerWorks WebSphere Business Integration zone. You'll find technical documentation, how-to articles, education, downloads, product information, technical support resources, and more.
- Browse for books on these and other technical topics.
- WebSphere forums.
Product-specific forums where you can ask questions and share your opinions with other WebSphere users.
- developerWorks blogs. Ongoing, free-form columns by software experts, with space for you to add your comments.
Birgit Duerrstein works in the WebSphere Process Choreographer development team in the IBM development lab in Boeblingen. Birgit joined IBM Germany in 2002 after she completed her studies of Information Technology in Stuttgart. She is now leading the development of samples and scenarios for WebSphere Process Choreographer.
Anke Robeller works in the WebSphere Process Choreographer development team in the IBM development lab in Boeblingen. She joined IBM Germany in 1999 and works since 2001 in the development of the Process Choreographer navigation component. Anke holds a master's degree in computer science from the University of Stuttgart, Germany.
Table of contents
Local resources
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
