Page 222 -

7 The Architecture 215
7.3.4 Worklet Service

The Worklet Service is a term used to refer to two separate but complementary ser-
vices: a Selection Service, which enables dynamic flexibility for process instances,
and an Exception Service, which provides facilities to handle both expected and
unexpected process exceptions (i.e., events and occurrences that may happen during
the life of a parent process instance that are not explicitly modeled) at runtime.
In essence, a worklet is a (typically small) YAWL workflow specification that
has been designed to execute as a substitute for an enabled work item, so that it
contextually handles one specific task in a larger process instance. At design time,
any task may be associated with the Worklet Selection Service to enable dynamic
flexibility for that task. At runtime, on receiving notification from the Engine of
a work item-enabled event, the Worklet Selection Service selects an appropriate
worklet from a repertoire of worklets defined for that task, by applying a set of
extensible rules to the context of the work item and its parent case. The work item
is checked out of the Engine via Interface B, the corresponding data inputs of the
work item are mapped to the selected worklet, which is then loaded (via Interface A)
and launched (via Interface B) in the Engine as a separate case (the Engine has
no knowledge of the relation between the parent case and the worklet instance).
When the worklet completes, the service receives a CaseCompleted notification,
and then maps the worklet’s output data to the output data of the original work item,
which is then checked back into the engine, allowing the original process instance
to continue.
The Worklet Exception Service extends from the Selection Service and uses the
same repertoire and dynamic rules approach to provide detection and handling sup-
port for process exceptions that may occur during the life-cycle of a case. Instead of
worklets, the Exception Service maintains a repertoire of exception handling pro-
cesses (called exlets) for each specification, which are selected and invoked in the
event of an exception occurring, to perform any required actions and compensa-
tions defined. While the Selection Service is invoked for certain nominated tasks
in a process, the Exception Service, when enabled, is invoked for every case and
task executed by the Engine, and will detect and handle up to ten different kinds of
process exception.
As part of an exlet definition, a process modeler may choose from various actions
(such as canceling, suspending, completing, failing, and restarting) and apply them
at a work item, case, and/or specification level, using a graphical tool. Also, any
compensatory actions can be performed by adding a worklet to the exlet definition.
By providing an external exception handling service, the original parent process
model only needs to reveal the actual business logic for the process, while the
repertoire of exlets grows as new exceptions arise or different ways of handling
exceptions are formulated. Table 7.1 summarizes the differences between the two
subservices in terms of the interface used and the action returned from a service
selection.
In addition to Interface B, the Worklet Service also listens for notifications passed
by the Engine through Interface X when the Exception subservice is configured to