Page 260 -

254 M. Adams
Specs: The set of specifications currently loaded in the Engine
WorkItems: Stores a full set of internal descriptors for each active work item
WorkItemTimer: This table stores a record of each timer that has been started
for a work item, but has not yet expired
YIdentifiers: A YIdentifier object is essentially a token in a YAWL net, and
stores information identifying itself with its parent case instance
When a server restarts, case instances are reconstructed from the data held in
these tables by the Case Restorer component. Each case is rebuilt in a predefined
sequence to ensure that all necessary objects and data structures are available, so
that it can successfully start executing from the point of last persistence.

9.7 Logging

An important consideration for any workflow environment is the generation of pro-
cess logs, that is, the recording of data and events that describe the execution of
each process. Process logging plays two fundamental roles: (1) it provides an audit
trail of interactions between the workflow Engine and its environment; and (2) it
represents a historical archive of process executions, which may later be analyzed
for insights into the operation of specifications (cf. Chap. 17).
The Engine generates process logs that detail each executing case from com-
mencement to completion (or cancelation), the enabling of each work item and each
of its status changes through to completion (or cancelation), and all changes made
to work item and net data values. It also provides for configurable logging, that is,
the logging of user-defined data attributes, values, and descriptors associated with
certain parts of the process data that may prove of interest at a particular site or for
a particular process specification.
The process of writing data to the process logs is achieved via a Hibernate inter-
face, in the same manner as that used by the persistence tables. This means that the
process logs can be written to any data source that can be configured for the Hiber-
nate framework. Each log entry is formulated by creating a log object, populating it
with the appropriate data, and then passing the object to the framework for insertion
into the data source.
The physical structure of the process logs, and the methods made available for
its interrogation via Interface E, are built with a view towards both the requirements
4
of log analysis by external tools such as ProM , and for ease of data retrieval by
custom services and applications.

9.7.1 Process Log Relational Schema

Figure 9.6 depicts a relational schema for the Engine’s process log, and shows
primary key fields as bolded text. The unique identifiers for the NetInstance and

4 www.processmining.org