Suppose you need to write a book on ordering process. This might include two main tasks: order registration and charging the client's credit card.
Imagine there is not enough credit in the customer's credit card when initiating a credit card transaction. In this case, we need to rollback a "Register Book Order" activity in order to avoid financial losses to the bookseller. This is where we need to have compensations in the BPEL processes. The already completed tasks can be rolled backed. In the preceding example, the BPEL process should implement necessary activities to cancel the book order during the compensation.
When using a self-contained synchronous system, all information is available during a change to simply roll the change back if an error or unexpected situation occurs. However, in a BPEL environment, things are often not self-contained, and a change needs to be committed to move on. If any error or unexpected situation occurs after this commit, a new transaction is needed to "undo" the original, as a roll back to undo the original is no longer possible. We will talk more about compensation in this chapter.
We will cover the following topics:
- Introduction to compensation in business processes
- Adding compensation handlers to a BPEL process
- Understanding long-running processes
- Understanding the concept of compensation
- How to implement a compensation in BPEL
- The structure of compensation handlers
- Compensating activities and default compensation handlers
In this section, we introduce a new sample BPEL process that models a compensation scenario. The high-level process execution is depicted in the following figure:
The registerBookOrder scope models the registration of a new book order. It includes an <empty/> activity called dummyRegisterBookOrder that simulates the registration behavior. Also, the scope contains a compensation handler, which will be discussed later in this chapter. This compensation handler discards the book order as the compensation logic. For demonstration purposes, the compensation handler also includes a <wait/> activity with a 30-seconds delay to allow time to monitor the activity, otherwise things might happen too fast to observe.
The initiateCreditCardTransaction scope models the credit card transaction related to the new book order. It includes an <empty/> activity called dummyInitiateCreditCardTransaction that simulates the credit card transaction. Similar to dummyRegisterBookOrder, this scope will also have a delay and a compensation handler (to reverse the credit card transaction).
The throwFault sequence models a fault generation within the BPEL process. For demonstration purposes, the BPEL process itself throws a fault called TriggerCompensationFault that is caught by the catchAll sequence. However, in real-life scenarios, the fault can be generated due to exceptional behaviors in the BPEL process itself, or from partner web services.
The catchAll sequence triggers the compensation logic for the
registerBookOrder and initiateCreditCardTransaction scopes.