The Process Choreographer component of WebSphere Business Integration Server Foundation V5.1 (hereafter referred to as Server Foundation) provides the ability to choreograph intra-enterprise and inter-enterprise services using business processes, which can involve both human and IT resources. Process Choreographer supports running Business Process Execution Language (BPEL) processes in a J2EE™ environment, and lets you combine business process technology with other services that are offered by J2EE architecture and available in Server Foundation.
A business process in Process Choreographer interconnects several so called "activities". An activity can have several types. A very important activity type is the Invoke activity, which is used to invoke Web services which could be implemented as, for example, an EJB™ component or another process.
Figure 1. Activities in Process Choreographer
Business processes can take days, months, or even years to complete, depending on the process, so it is possible that individual activities can complete (in terms of committed transactional control) prior to the completion of the whole process. If an event or an error occurs which causes the process to cancel, the already completed activities need to be undone. Compensation support is required to accomplish this.
This article describes what compensation is and how to model it in several process scenarios using WebSphere Studio Application Developer Integration Edition. This information can help a business process modeler introduce compensation into existing processes. Basic information on modeling business processes within WebSphere Studio Application Developer Integration Edition (hereafter referred to as Integration Edition) and running them in Server Foundation can be found in the WebSphere Studio Information Center. (See Resources.)
(The compensation functionality in Server Foundation is not an implementation of the BPEL compensation specification, although it serves a comparable purpose.)
Compensation in Process Choreographer
Using the Integration Edition BPEL Process editor, the business process modeler combines activities to one business process. By editing process and activity properties, the modeler controls the behavior of compensation for this process.
Compensation is used to undo already completed activities of a process. Once compensation is triggered, the entire process is compensated. That is, if it runs, it compensates all activities of the process which have been run and completed.
Which actions need to be compensated is specified by the activity: an Invoke activity has a service defined which is invoked during the forward processing of the activity. For the purposes of compensation, such services are called "forward services" or "do services" of the activity. An activity can also have a service defined which is invoked during the compensation of the process. This "compensation service" is responsible for undoing the actions performed by the forward.
Figure 2. Activities with services defined
The compensation service is pretty similar to other services, in that it is a Web service and needs an input message. The compensation service needs to be an operation which reverses the changes done by the forward service of the Invoke activity.
Forward services of invoke activities that have a compensation service defined, as well as the compensation services themselves, have to be synchronous with respect to the Web Services Invocation Framework (WSIF) binding. That is, the service is invoked by a request/response operation, and the result of the service is returned to the caller immediately via this operation; this invoke happens without the use of callback mechanisms. Invoking an EJB operation is therefore meant to be synchronous. An invoke via a JMS binding is therefore meant to be asynchronous, because the request is put to a queue and the processing of the reply is triggered by sending a message to another queue.
The input message to the compensation service is a snapshot of given variable data at the point in time that the corresponding forward service completed successfully. You can specify an input message for the compensation service explicitly. If you decide not to do this, the Process Choreographer engine will use the parts of the input and the output message of the forward service as input for the compensation service. (See Resources.)
The information returned by the compensation service, its output message, does not have any affect to the process and is therefore discarded by the Process Choreographer engine. Since a compensation service has an associated, unchangeable input message at the time it is run, its output message can never be used, for example, as input to another compensation service.
Let us look at a travel booking process that consists, for example, of the following services:
- Book a hotel.
- Reserve a car.
- Book a flight.
- Send a confirmation letter.
Figure 3. Travel booking process
Assuming that the hotel and car reservation of the process completed successfully and that these results are already committed, suppose the flight reservation failed and you need to undo the successfully completed reservations to get the system back to its consistent state. This can be done by adding compensation services.
In the travel booking process, the following forward and compensation services could be defined:
Table 1. Forward and compensation services for travel booking process
| Invoke activity name | Forward service | Compensation service |
| BookHotel | bookHotel | cancelHotelReservation |
| ReserveCar | bookCar | cancelCarReservation |
| BookFlight | bookFlight | cancelFlightReservation |
| SendConfirmation | sendConfirmationLetter | sendCancellationAndExcuseMeLetter |
Figure 4 shows the definition of the forward service for the BookHotel invoke activity.
Figure 4. Forward service for BookHotel invoke activity
Figure 5 shows the compensation service defined in the Compensation property pane of the BookHotel activity.
Figure 5. Compensation service for BookHotel invoke activity
Defining compensation services does not ensure that compensation is triggered in case of an appropriate failure. A "Compensation Sphere" must be available to actually start compensation, the existence of which is controlled by a process property named Compensation Sphere. During process execution time, the compensation services are registered with the Compensation Sphere. The Compensation Sphere is then responsible for invoking the registered compensation services when compensation is triggered.
Figure 6. Compensation Sphere
The Compensation Sphere is specified at the process level (Figure 7).
Figure 7. Compensation Sphere setting
There are several ways to set the Compensation Sphere setting. In Figure 7, we want to ensure that a Compensation Sphere is available, so Requires New is selected, telling the server to create a new Compensation Sphere for this process. (With Not Supported, the process would run without any Compensation Sphere, meaning that compensation would never be run, even if compensation services are defined.)
When the travel booking process runs, the compensation services associated with the successfully executed forward services are registered with the Compensation Sphere, along with their input messages. It is assured, therefore, that the compensation services of only the already completed forward services will be called if compensation is necessary.
If the business process completes successfully, no compensation is needed, and all registered compensation services are deleted.
If compensation is triggered, the compensation services are called in the reverse order of their registration by the Compensation Sphere. Compensation is completed when all registered compensation services are called successfully.
Figure 8. Compensation services triggered
If a failure occurs during invocation of a compensation service, compensation processing for this process is stopped and needs human interaction to be restarted. This is done using the repair console of business process Web client, discussed further in The repair console.
Compensation related properties in a business process
The compensation behavior that will be used for a process and its activities is determined and set up during process modeling time. In this section, we will summarize the process and activity properties that control compensation behavior.
These properties in the Integration Edition BPEL Process editor affect compensation:
- Execution Mode (process property)
- Autonomy (process property)
- Compensation Sphere (process property)
- Activity Takes Part in Transaction (activity property).
The execution mode of a process can be long-running or microflow. The execution mode is not a compensation-specific property, but it does have an effect on compensation behavior. Let's begin with long-running processes. To set the execution mode in the Integration Edition BPEL Process editor, select Process is long-running in the Server Property pane of the process (Figure 9).
Figure 9. Set execution mode
A long-running process is intended to be interruptible; this is achieved by persistent process states and the ability to compose the activities of the process under several transactions. A long-running process, therefore, is meant to be a set of chained navigation transactions. A navigation transaction is used by the Process Choreographer engine to perform, for example, variable updates. In addition, a navigation transaction may span the operation of an invoked service, but it does not have to. An invoked service can also run under its own transactional control, which is the case, for example, if an EJB operation is called with a transactional behavior set to RequiresNew in its deployment descriptor. If compensation is triggered, it needs to cope with either forward services that did not take part in the navigation transaction running at this time, or forward services that had already been committed.
Figure 10. Long-running, interruptible process
The microflow process execution mode means that the whole process runs in one transaction. A microflow is a short-running operation which is not interruptible and does not persist any process state. If a failure occurs during microflow processing that affects a rollback of the navigation transaction, all forward services running under this transaction are rolled back. Compensation needs only to cope with forward services that either did not take part in the navigation transaction, or had non-transactional work to be compensated.
Figure 11. Short-running, non-interruptible microflow process
Processes can be nested, meaning that one process can control another process during its execution. During process modeling time, you specify under which autonomy this invoked process runs. There are two kinds of autonomy: peer and child. The specification of autonomy of the process is not compensation-specific, but it does have an effect on compensation.
A peer, or autonomous, process lives on its own; that is, the calling process does not propagate context or lifecycle operations, such as terminate or delete, to the peer process. Invoked as peer, the process is responsible for compensation itself, meaning that it must have its own Compensation Sphere.
The autonomy specification is applicable only to long-running processes. Autonomy is specified on the Server Property pane. (See Figure 9.)
Figure 12. Long-running with peer autonomy
If an invoked process runs with an autonomy child, the child process takes part in the Compensation Sphere of its parent process. A microflow is considered to be a dependent child process. A long-running process with a one-way operation interface must always be a peer process.
Figure 13. Microflow with child autonomy
A process which is not invoked by another process is called a top-level process. A process which invokes another process with autonomy set to child is the parent process for this invoked process.
Figure 14. Top-level process
The Compensation Sphere is responsible for invoking the compensation services that are registered to it, as defined by the Compensation Sphere property. For example, a Compensation Sphere can be responsible for all compensation services within the process and within its invoked processes. A Compensation Sphere can also be disabled, so that no compensation will take place regardless of whether compensation services have been specified.
There are four values that can be set for Compensation Sphere, specified in the process' Server Property pane in Integration Edition (see Figure 9). The values that are available are closely tied to the execution mode and autonomy properties, as shown in Table 2.
Table 2. Compensation Sphere property values
| Compensation Sphere property value | Description | Applies to |
| Not Supported | The process does not create a Compensation Sphere. Compensation is disabled in this case. | Long-running processes |
| Supports | The process does not create a Compensation Sphere, but does participate in a Compensation Sphere, if available from its parent process. If there is no Compensation Sphere available, compensation is disabled. | Long-running processes and microflows |
| Required | The process creates a Compensation Sphere if it is not invoked from a parent process. If the process is invoked from its parent process, it does take part in the Compensation Sphere of the parent process. If the parent does not have a Compensation Sphere, an exception is thrown, since this value requires Compensation Sphere. | Long-running processes and microflows |
| Requires New | The process creates a Compensation Sphere. | Long-running processes |
Activity Takes Part in Transaction
The Activity Takes Part in Transaction property tells the Process Choreographer engine whether its corresponding forward service participates in the navigation transaction of the Process Choreographer engine.
Compensation needs to know if the forward service is part of the navigation transaction, because the service must not be compensated if it is rolled back within the navigation transaction. The Activity Takes Part in Transaction property, therefore, has an impact on the compensation behavior as long as the navigation transaction is not committed. If the navigation transaction is committed and the business process fails later on, then the compensation services of the transactional forward services must be invoked, as well as the non-transactional ones (all compensation services registered with the Compensation Sphere).
Figure 15. Activity Takes Part in Transaction property
Set the Activity Takes Part in Transaction property if the forward service runs within the navigation transaction of the process. For example, invoking a microflow (or an EJB operation) which has its transaction attribute in the deployment descriptor set to Required is an example of when this flag needs to be checked. This flag should be unchecked for EJB operations that have its transaction attribute in the deployment descriptor set to RequiresNew, or when non-transactional activities are performed. (See Resources for more information on the Activity Takes Part in Transaction property.)
In our example, the forward service of the BookHotel invoke activity is an EJB operation with a transaction attribute set to Required and the Activity Takes Part in Transaction property is checked in the Compensation property pane of this activity.
Figure 16. Compensation properties
The forward service of the SendConfirmation invoke activity sends a confirmation email. This operation can not be rolled back within the navigation transaction of the process, an so Activity Takes Part in Transaction property is unchecked, as in Figure 17.
Figure 17. Compensation properties
Conditions to run compensation in a BPEL process
Compensation of a process is triggered by several indicators:
- In a long-running process, compensation runs if one of the following occurs:
- A fault reaches the process-level fault handler, or is not explicitly handled.
- Generic Process Choreographer API provides a method to terminate a process instance. You can specify whether compensation should happen during terminate: terminate(String PIID, boolean doCompenation).
- In a microflow process, compensation runs if:
- The transaction in which the microflow runs rolls back. The services which did not run in the transaction must then be compensated.
Process states during compensation
For long-running processes you can see the state in which the process resides using the business process Web client:
- Compensating
When compensation is triggered in a long-running process. Compensation is ongoing. - Compensated
When the compensation is completed. - Indoubt
If a failure occurs during compensation processing; the process now needs manual repair to get finished, using the business process Web client repair console. (See The repair console.)
Microflow processes and their states are not persisted, and therefore you will not see running or finished microflow processes with the business process Web client. However, if a failure occurs during microflow compensation, you can use the business process Web client repair console to manually finish compensation processing.
Compensation in several process scenarios
In this section, we will show several process scenarios and describe how compensation should be modeled for each, focusing on the specification of Compensation Sphere, compensation service, autonomy, and the Activity Takes Part in Transaction flag.
Figure 18. The activities compensation service and its input
Compensation in top-level long-running processes
The value of the autonomy flag in top-level processes does not matter for compensation. To set up compensation in a top-level, long-running process, apply the following values:
- Compensation Sphere
Enable compensation by setting the Compensation Sphere property to Requires New or Requires; disable it by entering Not Supported or Supports. - Compensation Service
When the long-running process fails, every forward service which needs to be undone must have a compensation service with its input message defined. - Activity Takes Part in Transaction
As mentioned above, select this property if the forward service runs within the navigation transaction of the process.
Compensation in top-level microflow processes
As mentioned, the value of the autonomy flag does not matter for compensation. For microflows, only two Compensation Sphere properties are supported. Apply the following values to set up compensation:
- Compensation Sphere
To enable compensation, set the Compensation Sphere property to Requires; disable it by setting it to Supports. - Compensation Service
A microflow always runs in one navigation transaction. If this transaction rolls back, all changes made by the forward services executed within this transaction are also rolled back. Because of this, only forward services that are not executed within the navigation transaction of the process need compensation services with its input messages defined. - Activity Takes Part in Transaction
As mentioned earlier, select this property if the forward service runs within the process' navigation transaction. In the case of a top-level microflow, it makes sense to specify only compensation services for forward services that do not run under the control of the navigation transaction. Doing this, the Activity Takes Part in Transaction flag should be unchecked in every case where a compensation service is defined.
Figure 19. Activity Takes Part in Transaction setting
Compensation in an invoked peer process
This section describes how compensation works in a process which is invoked with autonomy set to peer from another process.
A microflow is always invoked as a dependent child. Therefore, an invoked process with autonomy of "peer" is always a long-running process.
- Compensation Sphere
Enable compensation by setting the Compensation Sphere property to Requires New, and disable it by entering Not Supported. If compensation is enabled, this autonomous peer process will open its own Compensation Sphere. That is, the parent process runs in a different and independent Compensation Sphere than the peer process. When the parent process starts compensation, the compensation services of this peer process will not be invoked. - Compensation Service
Every forward service which needs to be undone when the long-running process fails needs to have a compensation service with its input message defined. - Activity Takes Part in TransactionAs specified above, select this property if the forward service runs within the navigation transaction of the process.
Compensation in an invoked long-running child process
Below are the compensation settings for a long-running process that is invoked with autonomy set to child from another process.
First, though, it is important to know that a long-running process that is invoked through an asynchronous (one way) interface runs under autonomy peer every time, even if autonomy child was specified at process modeling time. A general example of this is the invoking of a long-running process from a microflow; since microflows are only able to invoke long-running processes asynchronously, these invoked processes are always peers. The behavior of compensation in this process is described in the previous section.
The following values apply only to long-running child processes that have been invoked by a long-running process through a synchronous interface:
- Compensation Sphere
A child process takes part in the Compensation Sphere of its parent. The Compensation Sphere property is used in this case to tell the Process Choreographer engine whether the child process must have an enabled compensation (meaning, an available Compensation Sphere), or if it can cope with a disabled compensation. If the child process is designed in a way that it must have a Compensation Sphere, the Compensation Sphere property must be set to Requires. If the parent process does not provide a Compensation Sphere in this case, a fault is thrown to tell that the child process cannot run without one. If the child process is designed in such a way that it does not matter whether or not its parent has a Compensation Sphere, the Compensation Sphere property should be set to Supports. - Compensation Service
Every forward service that needs to be undone when the long-running process fails must have a compensation service with its input message defined. - Activity Takes Part in Transaction
Select this property if the forward service runs within the navigation transaction of the process.
Compensation in an invoked microflow child process
A microflow process which is invoked from another process always runs with autonomy child. To enable compensation:
- Compensation Sphere
A child process takes part in the Compensation Sphere of its parent. In this case, the Compensation Sphere property is used to tell the server whether the child process must have enabled compensation (meaning, an available Compensation Sphere), or if it can cope with disabled compensation.- If the child process is designed in such a way that it must have a Compensation Sphere, the Compensation Sphere property must be set to Requires. If the parent process does not provide a Compensation Sphere in this case, a run time fault is thrown to indicate that the child process cannot run without one.
- If the child process is designed in such a way that it does not matter whether its parent has a Compensation Sphere or not, the Compensation Sphere property should be set to Supports.
- Compensation Service
The forward services that are not executed within the navigation transaction of the child process need compensation services with its input messages defined. If the top-level process of the child microflow process is long-running, every forward service that must be undone needs to have a compensation service with its input message defined. This is because a microflow child can be executed and commited within a transaction in the long-running process. If the long-running process would need to be compensated later on, then all the services of the invoked microflow child are already committed and, therefore, must be compensated -- not just the ones that don't run in the navigation transaction. - Activity Takes Part in Transaction
Select this property if the forward service runs within the navigation transaction of the process.
Figure 20. Invoking compensation with a child process
When compensation is triggered, the Compensation Sphere invokes all compensation services registered to it in reverse order. After successful completion of a compensation service, the service is removed from the Compensation Sphere and the next compensation service is invoked.
If an error occurs during the execution of a compensation service, the Compensation Sphere stops compensation processing for this process instance. If the process is long-running, the process instance is set to state "Indoubt". For long-running processes and microflows, the business process Web client provides an interface to manually repair compensation processing:
- Select Undo Actions in Error in the navigation pane of the business process Web client to get a list of all compensation services that failed. You can now mark a compensation service and decide whether to retry the service, skip it, or to stop compensation completely for the process instance that this compensation service is in.
- Select Retry to invoke the failed compensation service again. If the service completes successfully, all the following compensation services registered with the corresponding Compensation Sphere are invoked, and compensation runs until it completes or until another compensation service fails.
- Select Skip to remove this compensation service from the corresponding Compensation Sphere; this compensation service is not invoked and compensation resumes with the next compensation service that is registered to the Compensation Sphere. Compensation runs until it completes or until another compensation service fails.
- Select Stop to remove all registered compensation services, including the failed one, from the corresponding Compensation Sphere. Invocation of the remaining compensation services is skipped and compensation is therefore complete.
Figure 21. Undo Actions in Error
Assume that our sample travel booking process fails due to an exception in the SendConfirmation activity. The activities BookHotel, ReserveCar, and BookFlight therefore need to be compensated, and so the Compensation Sphere calls their associated compensation services. Now assume that the compensation service of ReserveCar also fails. Since the travel booking process is long-running, the state shown in the business process Web client is In doubt:
Figure 22. Compensation service state
To see the failed compensation service, select the Repair Compensation button or the Undo Actions in Error link in the navigation pane (Figure 23).
Figure 23. View failed compensation service
The activity name of the failed compensation service will be displayed. By selecting one of the available action buttons, you will be able to repair the compensation problem.
This article explained how to define compensation for a BPEL process, described compensation behavior in long-running processes and in microflows, and showed how to repair failed compensation services.
- WebSphere Information Center
- Business Process Execution Language for Web Services version 1.1
- WebSphere Business Integration Server Foundation Process Choreographer
- How is the compensation service input message assembled?
- What does the "Activity takes part in transaction" flag mean on the compensation panel?
- 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.
Comments (Undergoing maintenance)





