Page 169 -

5 Exception Handling 159
description of how it is implemented and deployed (including examples) can be
found in Chap. 11.

5.4.1 The Worklet Exception Service

The Worklet Exception Service uses the same repertoire and Ripple-Down Rule
(RDR) set framework as the Worklet Selection Service (see Chap. 4 for a detailed
description of the framework), and can handle both expected and unexpected excep-
tions when they occur at runtime. For each anticipated exception (an event that
is not expected to occur in most instances and so is not defined as part of the
“main” business logic of the specification), a set of repertoire-member exception
handling processes, known as exlets (which are defined in the YAWLeX language
using a graphical editor and may include worklets as compensation processes), may
be defined for handling the event, to be dynamically incorporated into a running
workflow instance on an as-needed basis. That is, for any exception that may occur
at the task, case, or specification level, a repertoire of exlets may be defined and
maintained, with the most appropriate one system-selected at runtime based on the
context of the case and the type of exception that has occurred. Further, worklets
that are invoked as compensation processes as part of an exception handling process
are constructed in exactly the same way as those created to support flexibility, which
in turn are constructed in the same way as ordinary, static YAWL process models.
In the occurrence of an unanticipated exception (i.e., an event for which a han-
dling exlet has not yet been defined), either an existing exlet can be manually
selected (reused) from the repertoire, one may be adapted on the fly to handle the
immediate situation, or a new exlet constructed and immediately deployed while
the parent workflow instance is still active, so in each case allowing execution of
the process that raised the exception to take the necessary action and either con-
tinue unhindered, or, if specified in the exception handler, to terminate, as required.
Crucially, the method used to handle the new exception and a record of its context
are captured by the system and immediately become an implicit part of the parent
process model, and so a history of the event and the method used to handle it is
recorded for future instantiations, which provides for continuous evolution of the
process while avoiding any need to modify the original process definition.
The Exception Service has been designed so that the enactment engine, besides
providing notifications at certain points in the life-cycle of a process instance,
needs no knowledge of an exception occurring, or of any invocation of handling
processes – all exception checking and handling is provided by the service.
Although the Exception Service uses the same repertoire and dynamic rules
approach as the Selection Service, and extends from the Selection Service and so
is built on the same framework, there are, however, two fundamental differences
between the two subservices. First, where the Selection Service selects a worklet as
the result of satisfying a rule in a rule set, the result of an Exception Service rule
being satisfied is an exlet. Second, while the Selection Service is invoked for certain