Exception Types

It is only possible to specify handlers for expected types of exception. With this constraint in mind, a comprehensive literature review and a broad survey of surrent commercial PAIS and business process modelling and execution languages was undertaken in order to determine the range of exception events that are capable of being detected and provide a useful basis for recovery handling. These events can be classified into five distinct groups.

Work Item Failure

Work item failure during the execution of a process is generally characterised by the inability of the work item to progress any further. This may manifest itself in a number of possible forms including a user-initiated abort of the executing program which implements the work item, the failure of a hardware, software or network component associated with the work item or the user to whom the work item is assigned signalling failure to the enabling PAIS. Where the reason for this failure is not captured and dealt within the process model, it needs to be handled elsewhere in order to ensure that both later work items and the process as a whole continue to behave correctly.

Deadline Expiry

It is common to specify a deadline for a work item in a process model. Usually the deadline indicates when the work item should be completed, although deadlines for commencement are also possible. In general with a deadline, it is also useful to specify at design time, what should be done if the deadline is reached and the work item has not been completed.

Resource Unavailability

It is often the case that a work item requires access to one or more data resources during its execution. If these are not available to the work item at initiation, then it is usually not possible for the work item to proceed. Similarly, PAIS are premised on the fact that work items are usually allocated to resources (typically human) who execute them. Problems with work item allocation can arise if (1) at distribution time, no resource can be found which meets the specified distribution criteria for the work item or (2) at some time after allocation, the resource is no longer able to undertake or complete the work item. Although the occurrence of these issues can be automatically detected, they often cannot be resolved within in the context of the executing process kind may involve some form of escalation or manual intervention. For this reason, they are ideally suited to resolution via exception handling.

External Trigger

Triggers from sources external to a work item are often used as a means of signalling the occurrence of an event that impacts on the work item and requires some form of handling. These triggers are typically initiated by non-linked work items (i.e. work items that are not directly linked to the work item in question by a control edge) elsewhere within the process model or even in other process models or alternatively from processes in the operational environment, in which the PAIS resides. Although a work item can anticipate events such as triggers and provision for dealing with them can be included at design time, it is not predictable if or when such events will occur. For this reason, the issue of dealing with them is often not suited to normal processing within the work item implementation and is better dealt with via exception handling. Generally signals or some other form of processing interrupt indicate that an out-of-bound condition has arisen and needs to be dealt with. A general consequence of this is that the current work item needs to be halted, possibly undone and some alternative action taken.

Constraint Violation

Constraints in the context of a PAIS are invariants over elements in the control flow, data or resource perspectives that need to be maintained to ensure the integrity and operational consistency of the process is preserved. Ongoing monitoring is generally required to ensure that they are enforced. The implementation of routines to identify and handle constraint violations detected within the context of a process is similar to the issue of dealing with external triggers. Typically the construct that will detect and need to deal with the violation is a work item although there is no reason why the constraint could not be specified and handled at block or process level. As constraints may be specified over data, resources or other work items within a process model, the approach chosen for handling them needs to be as generic as possible to ensure that it has broadest applicability.

Previous - A Framework for Exception Handling
Next - Exception Handling at Work Item Level