Page 257 -

9 The Runtime Environment 251
(or handler) of the event. The Custom Service will typically deal with the announce-
ment event by requesting that the work item be checked-out of the Engine. Both the
event and the checkout request are performed via Interface B. When the Engine
receives a check-out request from the service, it will attempt to start the enabled
work item.
When an enabled work item is started, it decomposes or splits into two or more
discrete work items. First, a parent work item is created and maintained by the
Engine; its purpose is to manage the progress of all the work item instances cre-
ated for the task (referred to as child instances). For single instance tasks, exactly
one child is created, while for multiple instance tasks, as many child instances are
created as required for the parameters set for the task at design time. The parent
work item is given the status IsParent. As each child instance completes, the par-
ent instance takes note of its completion – when all of the child work items have
reached a completion status and, for multiple instance tasks, when the completion
threshold has been reached (a parameter that describes the minimum number of
child instances that must complete before the task can be considered complete), the
parent work item instance also completes, at which point the task is marked as com-
pleted and a token is produced in its output place, allowing the process control-flow
to continue.
Further, when an enabled work item of a multiple instance task is started and
decomposed into a parent and a number of children, the children are each given
the status Fired. Then, exactly one child is moved from Fired to Executing status
(where there are multiple children, one is chosen at random to become Executing).
This means that, regardless of whether the task is single or multiple instance, only
one child is ever started for a check-out request, while the remaining instances (i.e.,
in the case of a multiple instance task) are left at the intermediate Fired status, and
must each be explicitly started before they are moved to Executing status.
To summarize, the “execution” statuses are:
IsParent: Denotes that instance of a work item that oversees the execution of the
other (child) instances. When all child instances have completed, and in the case
of multiple instance tasks, when the completion threshold has been reached, the
parent also completes, allowing the process to continue as per its control-flow.
Executing: Each work item that is successfully started is given Executing status.
For multiple instance tasks, only one (indiscriminate) child is initially started via
a check-out request; the other child instances are initialized at that time and given
Fired status, and must be individually started to move each to Executing. Thus,
Executing status denotes that the work item has started and is being processed by
a designated Custom Service.
Suspended: A work item with a status of Enabled, Fired,or Executing may
be suspended. Basically, a status of Suspended blocks a work item from being
progressed to a status subsequent to the status it had at the time it was sus-
pended. So, an enabled work item, when suspended, cannot be fired; a fired
work item cannot be executed; an executing work item cannot be completed.
Suspension is typically used to “hold” a process in its current state, while, for
example, some compensatory action is taken following an exception. Note that