Page 145 -
P. 145
134 M. Adams
of human involvement – at the “coal-face,” as it occurs – greatly simplifies the
capturing of contextual data. Thus RDR allows the construction of an evolving,
highly tailored local knowledge base about a business process.
4.6 The Selection Process
The worklet approach allows for two related but discrete areas of dynamic and flex-
ible workflow to be addressed: dynamic selection of tasks and exception handling
with corrective and compensatory action. A conceptual synopsis of the selection
process is dealt with in this section; exception handled in Chap. 5.
When a YAWL specification is created in the Editor (cf. Chap. 8), one or more of
its tasks may each be associated with a corresponding repertoire of worklets from
which one will be selected as a substitute for the task at runtime. Each task asso-
ciated with the Worklet Service has its own particular repertoire, and its members
may be found in a number of other repertoires. Along with the specification, a cor-
responding RDR rule set is created, which defines the conditions to be evaluated
against the contextual data of the case instance. That is, each task may correspond
to a particular “tree” of RDR nodes within which are referenced a repertoire of
worklets, one of which may be selected and assigned as a substitute for the task
dynamically. Not all tasks need be linked to a repertoire – only those for which
worklet substitution at runtime is desired.
Each task that is associated with a worklet repertoire is said to be “worklet-
enabled.” This means that a process may contain both worklet-enabled tasks and
non-worklet-enabled (or ordinary) tasks. Any process instance that contains a
worklet-enabled task will become the parent process instance for any worklets
invoked from it.
Importantly, a worklet-enabled task remains a valid (ordinary) task definition,
rather than being considered as merely a vacant “placeholder” for some other activ-
ity (i.e., a worklet). The distinction is crucial because, if an appropriate worklet for
a worklet-enabled task cannot be found at runtime (based on the context of the case
and the rule set associated with the task), the task is allowed to run as an “ordinary”
task, as it normally would in a process instance. So, instead of the parent process
being conceived as a template schema or as a container for a set of placeholders, it
is to be considered as a complete process containing one or more worklet-enabled
tasks, each of which may be contextually and dynamically substituted at runtime.
It is possible to build for a task an initial RDR rule tree containing many nodes,
each containing a reference to a worklet that will be used if the conditional expres-
sion for that node and its parent nodes are satisfied; alternately, an initial rule tree
can be created that contains a root node only, so that the worklet-enabled task runs as
an ordinary task until such time that the rule tree is extended to capture new contex-
tual scenarios (which may not have been known when the process was first defined).
Thus, the worklet approach supports the full spectrum of business processes, from
the highly structured to the highly unstructured.