Page 296 -

292 M. Adams
worklet, which contextually handles one specific task in a larger, composite process
activity. Each worklet is a complete extended workflow net (EWF-net) compliant
with Definition 1 of the YAWL semantics. Each worklet instance is dynamically
selected and invoked at runtime and may be designed and provided to the Selection
Service at any time, even while a parent process instance is executing, as opposed
to a static subprocess that must be defined at the same time as, and remains a static
part of, the main process model.
An extensible repertoire of worklets is maintained by the service for each task
in a specification. Each time the service is invoked for a work item, a choice is
made from the repertoire based on the contextual data values within the work item,
using an extensible set of Ripple-Down Rules (cf. Sect. 11.10) to determine the most
appropriate substitution.
The work item is checked out of the Engine, the corresponding data inputs of
the original work item are mapped to the net-level inputs of the worklet, and the
selected worklet is launched in the Engine as a separate case. When the worklet has
completed, its output data is mapped back to the original work item, which is then
checked back into the Engine, allowing the original process to continue.
The worklet executed for a task is run as a separate case in the Engine, so that,
from an Engine perspective, the worklet and its parent are two distinct, unrelated
cases. The Worklet Service tracks the relationships, data mappings, and synchro-
nizations between cases, and creates a process log that may be combined with the
Engine’s process logs via case identifiers to provide a complete operational history
of each process instance.
Worklets may be associated with either a single instance or a multiple instance
atomic task. Any number of worklets can form the repertoire of an individual task,
and any number of tasks in a particular specification can be associated with the
Worklet Service. A worklet may be a member of one or more repertoires, that is,
it may be reused for several distinct tasks within and across process specifications.
In the case of multiple instance tasks, a separate worklet is launched for each child
work item. Because each child work item may contain different data, the worklets
that substitute for them are individually selected, and so may all be instances of
different worklet specifications.

11.2.2 The Exception Service

Virtually every process instance (even if it follows a highly structured process defi-
nition) will experience some kind of exception (or deviation) during its execution. It
may be that these events are known to occur in a small number of cases, but not often
enough to warrant their inclusion in the process model; or they may be things that
were never expected to occur (or perhaps never even imagined could occur). In any
case, when they do happen, since they are not included in the process model, they
must be handled “off-line” before processing can continue (and the way they are
handled is rarely recorded). In some cases, the process model will be later modified
to capture this unforeseen event, which involves an often large organizational cost