Page 158 -

148 M. Adams and N. Russell
or even could conceivably have been anticipated, then the modeler has apriori
knowledge of such an event, and it should therefore have been built into the model.
However, if a modeler builds all possible apriori exception scenarios into a model,
it can lead to very complex models, much of which will never be executed in most
cases. Also, mixing business logic with exception handling routines complicates
the verification and modification of both, in addition to rendering the model almost
unintelligible to most stakeholders.
Conversely, if the exception is unexpected, or could not possibly have been antic-
ipated, given the scope of knowledge of the work process available at the time the
model was designed, then the model is deemed to be simply deficient, and thus
needs to be amended to include this previously unimagined event. This view, how-
ever, tends to gloss over the frequency of such events, or the costs involved with
their correction. Such exceptions occur more frequently in processes that are very
complex and/or with a high variability. When they occur, they are normally captured
and managed manually, typically by halting process execution, which naturally has a
negative impact on business efficiency. Since most “real-world” workflow processes
are long and complex, neither human intervention nor terminating the process are
satisfactory solutions.

5.2 A General Framework for Exception Handling

This section describes a conceptual framework for exceptions that allows their for-
mat and operation to be described in a precise manner. This framework focuses
on the notion of a workflow exception in a general sense and the various ways in
which they can be triggered and dealt with. It considers an exception to be a dis-
tinct, identifiable event that occurs at a specific point in time during the execution of
a process. Generally, the occurrence of a specific exception will be detected in the
context of a work item that is currently executing. Such an occurrence is assumed
to be immediately detectable and to have a specific type. The action of dealing with
an exception that has been identified is known as exception handling and specific
strategies can be defined describing the actions that should be taken to mitigate their
effects. At the lowest level, these strategies may be bound to an individual task.
Exception handling strategies can also be recognized in relation to groups of tasks
(often described as scopes), blocks (i.e., a set of tasks at the same overall decom-
position level in a process), or entire process models. In all of these situations, the
same handling considerations apply to all the tasks encompassed within the given
process component in which the exception is experienced. The strategy for handling
an exception depends on four main factors:

1. The type of exception that has been detected
2. How the work item that detected the exception will be handled
3. How the other work items in the case will be handled
4. What recovery action will be taken to resolve the effects of the exception