Process Execution Event Logs

A computer-aided execution of a business processes via BPMS’s producesprocess execu- tion event logs(or shortevent logs) containing transactional details for each event occur- ring during the execution. These events are usually of a simple nature and often only comprise raw and direct information describing the state transition, but not the state of the whole system [233]. However, since the execution can span over multiple BPMS’s each individual event log can look very different. Differences can occur on many dimensions, e.g. event granularity (activity level events vs. instance level events), perspective support (whether resource, instance or other information is provided or not). Due to the differ- ences in the various log formats, efforts have been made to provide an extensible and general log format, e.g.Mining XML(MXML) [256], its successoreXtensible Event Stream

(XES) [90,258], orBusiness Process Analytics Format (BPAF) [288,293]. In the case of an execution of collaborative BPs spanning multiple different BPMS, events have to be cap- tured, filtered, and merged to one seamless log conforming to such a generic log format before further analysis (discussed in Section2.2.3) is carried out.

Events captured in a process execution log which conforms to a general log format like XES or BPAF have the following characteristics [90,293] (Table2.1contains an excerpt of an execution event log resulting from Process in Figure2.2):

Table 2.1 Excerpt of Execution Event Log resulting from Process in Figure2.2

Event ID Timestamp Instance ID Name Resource Lifecycle

296213 Thu Dec 16 11:47:27 GMT 1999 9520 Bill Account Eli Findmer complete

296214 Thu Dec 16 11:47:27 GMT 1999 9538 Bill Account Eli Findmer assign

296215 Thu Dec 16 11:47:27 GMT 1999 9520 Create Invoice - schedule

296216 Thu Dec 16 11:48:20 GMT 1999 9486 Create Invoice Mia Larson complete

296217 Thu Dec 16 11:48:20 GMT 1999 9472 Create Invoice Mia Larson assign

296218 Thu Dec 16 11:48:20 GMT 1999 9486 End Online Order - trace_end

296221 Thu Dec 16 11:48:41 GMT 1999 9468 Choose Products Webserver_Instance complete

296222 Thu Dec 16 11:48:41 GMT 1999 9468 Credit Check - schedule

296223 Thu Dec 16 11:48:50 GMT 1999 9468 Credit Check CreditServer_Instance complete

296224 Thu Dec 16 11:48:50 GMT 1999 9468 Sub Process Order - schedule

296227 Thu Dec 16 11:48:50 GMT 1999 9468 Bill Account - schedule

296233 Thu Dec 16 11:49:02 GMT 1999 9473 Sub Process Order - complete

296236 Thu Dec 16 11:49:32 GMT 1999 9540 Sub Process Order - complete

296237 Thu Dec 16 11:50:11 GMT 1999 9519 Bill Account Viktor Charmical complete

296238 Thu Dec 16 11:50:11 GMT 1999 9579 Create Invoice Viktor Charmical assign

296239 Thu Dec 16 11:50:11 GMT 1999 9519 Create Invoice - schedule

296251 Thu Dec 16 11:52:57 GMT 1999 9487 Create Invoice Chuck Tchahovsky assign

296259 Thu Dec 16 11:53:22 GMT 1999 9548 Login in known customer Webserver_Instance complete

296260 Thu Dec 16 11:53:22 GMT 1999 9548 Choose Products - schedule

296264 Thu Dec 16 11:54:38 GMT 1999 9546 Registering new customer Webserver_Instance complete

296265 Thu Dec 16 11:54:38 GMT 1999 9546 Choose Products - schedule

296266 Thu Dec 16 11:56:43 GMT 1999 9570 Start Online Order - triggered

296267 Thu Dec 16 11:56:43 GMT 1999 9570 Login in known customer - schedule

296270 Thu Dec 16 11:57:33 GMT 1999 9466 Start Online Order - triggered

296271 Thu Dec 16 11:57:33 GMT 1999 9466 Registering new customer - schedule

296274 Thu Dec 16 11:59:24 GMT 1999 9569 Choose Products Webserver_Instance complete

296275 Thu Dec 16 11:59:24 GMT 1999 9569 Credit Check - schedule

296276 Thu Dec 16 11:59:35 GMT 1999 9569 Credit Check CreditServer_Instance complete

296277 Thu Dec 16 11:59:35 GMT 1999 9569 Sub Process Order - schedule

296280 Thu Dec 16 11:59:35 GMT 1999 9569 Bill Account - schedule

296281 Thu Dec 16 11:59:36 GMT 1999 9557 Bill Account Julia Walker complete

296282 Thu Dec 16 11:59:36 GMT 1999 9474 Bill Account Julia Walker assign

• Event ID: The event’s unique identifier.

• Timestamp: The date and time, at which the event has occurred.

• Process Definition ID: If events of different processes are captured in a log, each event requires a unique identifier to the corresponding process definition the event belongs to. In Table2.1no Process Definition ID is displayed since the example log only contains events from one process definition.

• Instance ID: A Log is a record of the execution details of the instances of one or more business processes. Each event in the log represents a state transition that occurred during the execution of a process instance, i.e. all events in a log corresponding to the same instance make up atrace, which is also sometimes calledcasein literature (e.g. in [233]). TheInstance ID(orTrace ID, orCase ID) is the unique identifier that specifies to which process instance this event belongs to. Note, that an Instance ID only has to be unique in the universe of one process definition, i.e. traces of different business processes may have the same Instance ID. In fact, it can occur that traces span multiple business processes for which a shared identifier is required to analyse inter-process dependencies.

• Name: Represents the generally understood name of the event, e.g. the name of the executed activity represented by the event [90]. This event name is assumed to be a unique identifier of the BP element in the process definition this event is associated with and should not allow for duplicates. Events indicating the start and end of a process may be part of the log but may have a customised "name" entry that is not a direct reference to a BP element in the process definition (see Table2.1Event IDs 296218, 296266, and 296270).

• Resource: The name of the resource that triggered the event [90]. Similar to the name attribute it is assumed to be a unique identifier to the resource associated with the event, e.g. a unique employee id as opposed to the employee’s name. If no resource is associated with this event, this value is empty.

• Lifecycle: Events in most logs capture state transition on the activity level, i.e. events represent activity lifecycle transitions. In these cases the processing of an activity is recorded by more than one event and the corresponding transitions are captured by a lifecycle attribute. This is illustrated in Table2.1 in which Event IDs 296222 and 296223 represent two different activity lifecycles of the same activity and in- stance. MXML and XES propose a general and unified activity lifecycle based on state transitions as displayed in Figure 2.6 [90, 256]. In contrast, the BPAF activ- ity lifecycle is based on states and not on state transitions but proposes a map- ping to the MXML/XES state transition system [288, 293]. However, it consists of more states (13 vs. 7 states) and thus allows for more behaviour. Note, that the event formats of many BPMS may record behaviour less complex than enforced

Fig. 2.6 Lifecycle transitions in MXML and XES [90,256]

by the activity lifecycle of MXML/XES. For instance, a successful completion of an activity execution in the MXML/XES format requires a minimum of four events:

sched ul e →assi g n →st ar t →compl et e whereas the successful completion of the automated activity "Credit Check" is expressed by only two events in Table2.1 (Event IDs 296222 and 296223): sched ul e→compl et e. Some logs may even only contain one single event per processed activity, e.g. when the task has been com- pleted.

Since general standards like XES and BPAF are extensible, more information can be contained in the events. For instance, additional organisational data (e.g. the role the resource is associated with), additional cost data (e.g. cost and currency of the activity execution), or additional transactional data (e.g. items of an order) [90].