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:
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:
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.
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.