Thesis: Error Handling in BPMN

Project Overview - Error Handling Enforcement in BPMN

The execution of a business process often includes multiple entities. These entities are not under the control of the process and because of the intricacies of the real-world, their behavior is not always expected. This is why, although a business process may have a single ideal execution path, in practice, many executions will encounter events that lead the process off this path, whether errors or missing deadlines. Error handling is not a favorite issue for programmers or analysts. They often focus on the likely or ideal business scenarios, and end up ignoring the handling of diverse error conditions.

The goal of this project is to make it easier to build complete business process that have appropriate built-in responses to various common and less common error conditions. The difficulty of this task stems from the fact that such support requires identifying "generic" errors. However, often the semantic of errors stems from the specifics of the business process. The main contributions of this project are (1) We have identified a number of process schema that are generic, simple, intuitive, and common. Within these processes schema, we have identifies a set of generic errors. (2) We have implemented in the Prosero architecture tools that make it easier to enforce error handling when such constructs are used and to "remind" designers of the existence of these error conditions. We briefly describe these ideas, which are described in more details in this web site.

We have identified standard process patterns that occur within business processes. For example, one such pattern is ReceiveVerifyReply. This pattern starts when the process receives a message that requires verification of information, e.g., verification of shipment address. A verification process ensues, and the result is sent back to the message sender. There are many instances of this pattern within standard processes, and there are numerous standard errors that can arise when such a pattern occurs. The process we provide is the following: when defining a new process, the user can instantiate a sub-process schema, and this schema has error conditions built-in. This way, the designer will be made aware of the error conditions that require handling. These error path are already built into the BPMN model of this process template. Please see the Constructs section for more details.

A different type of error occurs when we execute an activity with a missing precondition. In general, there are various preconditions to an activity, and in current practice, they are not defined formally. Moreover, some of the preconditions are external to the process, i.e., there is no way of validating them using just the data passed within the process. However, there is a special class of preconditions that can be supported. We call them constraint "tokens". For example, when we receive an invoice, we expect the price used in this invoice to correspond to the price we received in the initial quote. Thus, we provide a simple mechanism for annotating certain values with constraints that are then verified automatically at run-time. In this case, we will verify that the price is the same as in the quotation. This will be done by annotating the price with an appropriate constraint that refers to data used elsewhere in the process. See the Tokens sections. The implementation section describes our implementation.

Various issues are left for future work, such as identifying pattern instances in existing processes (so that we can make the designer aware of the corresponding error conditions) and errors that stem from composition of multiple concurrent execution path.

The problem

Example: let's assume we have a billing business process. The billing includes a "credit-check" activity. If the credit is good do this… if the credit is bad do that…

But, what if the credit is neither?

The "credit-check" service unavailable.
The credit ID is unknown.
Return message is unrecognized.

The solution

Thesis