So far we have learned how to perform data manipulations, loops, and external service invocations synchronously and asynchronously. Imagine what will happen when the BPEL process invokes an external web service which is not available at the moment. In such a situation, the BPEL process could lead to an erroneous state. How can the BPEL process manage those generated faults and avoid such unexpected states?
WS-BPEL 2.0 provides fault handlers that come to the rescue. It tells the BPEL process how to perform when such an error occurs. In this chapter, we will learn about fault handling capabilities in a WS-BPEL 2.0 process.
In this chapter, we will cover the following topics:
- Introducing faults and fault handlers
- Adding fault handlers to business processes
- Understanding the fault handlers
- Different fault signaling techniques
- Ending and terminating a BPEL process due to a fault
Business processes are not intended to be a self-contained application. They are intended to cooperate with other existing remote services and to provide a service with much higher business value. So the WS-BPEL 2.0 specification provides constructs to satisfy these semantics.
Thus, a business process written in WS-BPEL 2.0 is capable of external web service invocations and manipulates the data based on the business logic. Speaking of such behavior, during the execution of the business process, it could lead to unexpected behaviors due to errors in the business logic, unexpected inputs, or unexpected behaviors in the environment. For example, an external web service may return a negative value where the client BPEL process expects a positive value. We explain some of those causes more specifically in the next section. Let's first see what sort of potential faults can be generated in a business process execution environment.
When a business process communicates with external web services, this communication happens over a network. This communication is prone to unexpected errors due to unreliability in the transport infrastructure.
The external web service may be unavailable or the web service may be moved to a new location without notifying the business process. So the business process infers it as a service unavailability.
When the external web service changes, the agreed communication contract with the business process can be changed without notification. For example, the security policy or the WSDL representation of the external web service can be changed without any prior notification. This leads to the breaking of the agreed relationship between the business process and the external web service.
The external web service itself can throw errors based on its implementation. And those faults can be propagated back to the business process. We normally call them WSDL faults. We will discuss this type of fault more deeply in an upcoming section.
The business process can generate faults due to its business logic. These faults can be twofold:
- Logical (explicit) errors: One category of faults is defined by the business process developer. So, for example, if the input variable carries an unexpected value, the business process developer can declare a fault within the business logic. And then the business process should be responsible to take care of that fault. Logical errors are also known as business faults.
- Execution errors: The other category of faults is generated by the BPEL runtime. Hence execution errors are also known as runtime faults. Suppose, when a variable is assigned some data, the BPEL runtime generates a fault if the variable is uninitialized. Some of these errors have to be handled at design and development time. The rest of it has to be dealt with at runtime.
Now, we have a high-level view of the possible faults that can be generated during the life cycle of a business process.
We discussed the potential categories of faults that can be generated in a business process execution environment. In order to deal with them, the WS-BPEL 2.0 specification provides a notion called fault handler, which is used to define the fault handling behavior for a particular fault. In the Time for action – adding fault handlers, section we demonstrate how to declare and configure a fault handler. In the next What just happened? section, we explain the fault handler in more detail. So let's move on to the sample business process, which declares a fault handler.
In this exercise, we demonstrate how to declare a fault handler and how it is triggered. We will use the sample BPEL process (book warehousing process) from Chapter 5, Interaction Patterns in BPEL. Then, in the next exercise, we extend the book warehousing process to cover more aspects in fault handling and signaling. Thus, we improve the book warehousing process by adding a fault handler to the external web service invocation and signal the fault back to the client of the BPEL process.
Let's remember the example, named book warehousing process, which we introduced in Chapter 5, Interaction Patterns in BPEL.
Workflow of the book warehousing process
In this exercise, we will generate a simple fault based on the content of the input. If the value of incoming message of the BPEL process is equal to error, then the BPEL process will generate an error.