Page 167 -

5 Exception Handling 157

take check organise ticket complete
details account bookings bookings order

Fig. 5.4 Travel bookings process

(i.e., all of the tasks in a process model), and a workflow (i.e., all of the process
models in a given workflow environment). The binding is specific to one particular
type of exception, for example, work item failure or constraint violation. It may also
be further specialized using conditions based on elements from the data perspective,
for example, there may be two exception handling strategies for a task, one for work
items concerned with financial limits below $5,000, and the other with limits above
that figure. Exception handling strategies defined for more specific constructs take
precedence to those defined at a higher level, for example, 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 utilized
should it experience such an exception.
To illustrate the application of these concepts, we present an example based
on a travel booking process illustrated in Fig. 5.4 using the YAWL process mod-
eling notation. In this process, booking requests are taken from customers for travel
requirements. Each customer has an account that is checked for available credit, and
assuming that this exists, their travel requirements are booked and ticketed before
their order is completed. In the event that they have insufficient credit, their order
is immediately finalized. In either case, the customer is advised of the outcome to
their travel request.
Figure 5.5a illustrates two alternate exception handling strategies for the check
account work item. The first of these is used when the account is in terms. It involves
suspending the work item, advancing to the next work item, and starting it. In sum-
mary, the check account work item is skipped and control is returned to the process
at the commencement of the next work item. For situations where the account is
overdue, the current work item is suspended, the execution point is rewound to the
beginning of the work item, and it is recommenced.
Figure 5.5b shows the exception handling strategy for the organize bookings
work item where the deadline for its completion is exceeded. In general, the aim is
to handle travel requests within 48 hours of them being received. Where this dead-
line is not met, recovery involves suspending the current work item, reassigning it
to another resource, running a compensation task that determines if the booking can
be resolved within 24 hours (and if not applies a small credit to the account), then
the organize bookings work item is restarted with the new resource.
Figure 5.5c 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 pro-
cess model, that is, by default, it applies to all work items. In the event where the