Page 282 -

278 M. Adams
of codelets are distributed as part of the default environment. Perhaps the most inter-
esting of these is ShellExecution, which provides for any program to be executed in
the external operating system environment (i.e., outside the immediate YAWL envi-
ronment), using application names and parameters passed as data values within the
automated task associated with the codelet.
The Connection Handler manages user sessions. This component checks logon
credentials, and creates and maintains sessions with end users. A timer is also main-
tained for each session, and times out after a period of inactivity (by default 60 min,
but this value may be modified via a configuration setting). Each time a user inter-
acts with the service, their session is checked for currency, and if valid, the inactivity
timer is reset.
Every runtime action taken by a user or the service on a work item is logged
by the Event Logger component, so that a process history is kept for all cases. All
changes in resource status (e.g., “Allocated” to “Started”) are logged, as well as user
actions such as delegation and reallocation. Data values describing the participant,
the work item, the action, and the timestamp are kept. Log records can be accessed
via Interface W, and may be incorporated with the engine’s process logs to reveal a
detailed process execution history for each case.
Finally, the Persistence Engine saves all runtime objects, updating them as nec-
essary, to ensure a copy of “live” cases and their associated data are permanently
backed up so that the entire runtime environment can be recreated in the event of a
server shutdown and restart.

10.5 Initial Distribution

When the engine notifies the service of an enabled work item, the service undertakes
to distribute the work item to resource(s) using the resourcing specifications for the
task from which the work item was created, as specified at design time. The process
followed by the service is shown in the flowchart in Fig. 10.7.
The first step is to retrieve the resource map applicable to the work item. A
Resource Map is an object created by parsing the task’s resourcing specification,
and describes how the work item’s resourcing decisions are to be made, as well as
performing the actual distribution process. For all specifications created in YAWL
versions prior to 2.0, there will be no resource map available, as specifications based
on older schemas had no knowledge of the Resource Service. In such cases, the work
item is offered to all participants (i.e., each participant in the organizational model
will see the work item in their Offered queue) and the distribution process com-
pletes. If the specification is based on the YAWL 2.0 schema, then each task will
have a designated resourcing specification (a default specification of User–User–
User initiated interaction points is applied to any task that has not been explicitly
designated a resourcing specification at design time).
Once the resource map is available, it is first checked to determine if a participant
has piled the work item. If so, the work item is immediately started and placed on