Considerations for a Process Exception Language
The insights gained in this body of work in relation to the identification and handling of exceptions provide the basis for a general exception handling language for processes. Here, we propose a set of primitives for addressing exceptions that might arise during process execution and present a mechanism for integrating these primitives with the process model more generally. It then demonstrates the applicability of this approach to exception handling through a working example.
The conceptual model presented earlier identified three key dimensions to handling an exception. These dimensions provide the basis for the primitives in the exception language illustrated in Figure 2. Symbols 1-4, 8 and 12-14 are derived from the actions for dealing with the current work item from Figure 1, symbols 5-7 and 9-11 are derived from the options for dealing with other work items currently active in the same and other cases and symbols 15 and 16 correspond to the two forms of recovery action that can be undertaken. These primitives can be assembled into sequences of actions that define exception handling strategies. These sequences can also contain standard YAWL constructs although we do illustrate this capability here.
Figure 2: Exception Handling Primitives
The interlinkage of exception handling strategies based on these primitives and the overall process model is illustrated in Figure 3. A clear distinction is drawn between the process model and the exception handling strategies. This is based on the premise that the process model should depict the normal sequence of activities associated with a business process and should aim to present these activities precisely without becoming overburdened by excessive consideration of undesirable events that might arise during execution.
Exception handling strategies are able to be bound to one of five distinct process constructs: individual tasks, a scope (i.e. a group of tasks), a block, a process (i.e. all of the tasks in a process model) and a process environment (i.e. all of the process models in a given environment). The binding is specific to one particular type of exception e.g. work item failure or constraint violation. It may also be further specialised using conditions based on elements from the data perspective e.g. there may be two exception handling strategies for a task, one for work items concerned with financial limits below $1000, the other with limits above that figure. Exception handling strategies defined for more specific constructs take precedence to those defined at a higher level e.g. where a task has a work item failure exception strategy defined and there is also a strategy defined at the process-level for the same exception type, then the task-level definition is utilised should it experience such an exception. The primitives provide flexibility for a describing wide range of exception handling stratedgies, although the actual contents of a specific strategy will generally be determined by the type of exception that it is associated with. Table 1 gives an indication of the approaches that are meaningful for each exception type.
Figure 3: Exception Handling in Relation to Workflow Processes
In order to illustrate the application of these concepts, we present an example based on the order fulfillment process illustrated in Figure 4 using the YAWL process modelling notation. In this process, orders are taken from customers, and a picking slip for the required items is prepared and subsequently used to select them for the warehouse. At the same time, the customer's credit is checked and shipping is organised for the order. When all of these tasks are complete an invoice is prepared for the customer and the goods are then packed and despatched whilst the customers account is updated with the outstanding amount. The order details are then finalised and filed.
Figure 4: Order Despatch Process
Figure 5(A) illustrates two alternative exception handling strategies for the check credit work item. The first of these is used when the amount of credit required is less than $100. It involves suspending the work item, advancing to the next work item and starting it. In summary, the credit check work item is skipped and control is returned to the process at the commencement of the next work item. For situations where the credit required is $100 or more, the current work item is suspended, the execution point is rewound to the beginning of the work item and it is recommenced.
Figure 5(B) shows the exception handling strategy for the pick order work item where the deadline for its completion is exceeded. In general, the aim is to despatch orders within 48 hours of them being received. Where this deadline is not met, recover involves suspending the current work item, reassigning it to another resource, running a compensation task that determines if the order can be despatched to the customer within 48 hours (and if not applying a small credit to the account), the the pick order work item is restarted with the new resource.
Figure 5: Exception Handling Strategies - Order Despatch Process
Figure 5(C) illustrates the resource unavailable handling strategy. Where the required resource is a data resource, this involves stopping the current work item, going back to its beginning and restarting it. This strategy is bound to the process model i.e. by default, it applies to all work items. In the event where the unavailable resource is a human resource (i.e. the person undertaking the work item), the recovery action is also shown in Figure 5(C) and involves suspending the work item, reassigning it to another person and then restarting it from the beginning.
Figure 5(D) indicates the exception handling strategy when an account frozen trigger is received by any of the tasks in the current process. In this situation, the recovery action is to stop the current work item and all other work items in the process and to undertake a rollback action which involves undoing all changes which have occurred right the way back to the beginning of the case. In other words, any work that has been undertaken on despatching goods to the customer is completely undone.
Finally, Figure 5(E) illustrates the recovery action that is taken when the order value constraint is exceeded for the take order task. In this case the strategy is simply to stop the work item and all other work items (if any) in the process.
Previous - Survey of Exception Handling Capabilities
Next - Related Work