XES

Trace: » xesstandardextensions


|

Meta

XES Standard Extensions

This page contains information on Standard Extensions that are not covered yet by the IEEE 1849-2016 XES Standard Definition.

Artifact Lifecycle Extension

The Artifact Lifecycle extension has been approved on December 5, 2018 by the XES Working Group. See the extension for the attributes defined by it.

The Artifact Lifecycle extension allows for events to relate to transitions in the lifecycles of multiple business artifacts, which are key conceptual entities that behave according to state-based transactional lifecycle models. We present a definition of the concepts of the extension, discuss how it relates to the standard lifecycle extension, and provide an example event log.

Software Communication and Software Telemetry

The Software Communication and Software Telemetry extensions have been approved on November 20, 2017 by the XES Working Group. See the extensions for the attributes defined by them.

The Software Communication extension supports recording IP-based communication for relating events across software applications. The Software Telemetry extension supports the recording of basic performance profile related resource utilizations commonly used in many software profiler tools. The resource utilizations covered in this extension are: CPU usage, thread usage and memory usage.

Software Event

The Software Event extension has been approved on September 22, 2017 by the XES Working Group. See the extension for the attributes defined by it.

During the execution of software, execution data can be recorded. With the development of process mining techniques on the one hand, and the growing availability of software execution data on the other hand, a new form of software analytics comes into reach. That is, applying process mining techniques to analyze software execution data. To enable process mining for software, event logs should be capable of capturing software-specific data.

A software event log is typically recorded at the method call level during software execution. Events generated at this level reference a specific point in the software source code. The Software Event extension captures this event location information, together with some basic runtime information related to this location.

Micro

The Micro extension has been approved on January 21, 2016 by the XES Working Group. This extension defines the following event attributes:

XES Attribute key Definition XES dataype Occ. Allowed values, examples, other constraints
micro:level Event level int 1 A positive integer
micro:parentId Id of parent event id 0-1 May not be present if level equals 1. Must be present for all other levels. If present, then this event must have a level that is one higher than the event with the specified id.
micro:length Number of child events int 0-1 The number of child events, that is, the number of events that have this event as parent event. If not present, the number of child events must be retrieved from the event log.

Many current Business Process Management Suites (BPMS) can define nested activities in order to provide a summary view and an abstract flow by hiding the nested activities. The nested activities may also be called sub activities, micro activities, sub process, and so on. Several BPMSs support nested activities. Examples of nested activities include executions of web services, web pages, and manual processes. For example, in IBM BPM, a process designer first defines an abstract flow of activities. Then he selects one of the activities, moves to the nested activity view, and defines web pages that actually conduct the selected parent activity.

In order to correctly analyse the behaviour of such nested activities, the execution of every nested activity must be recorded in an event log. For this reason we use the XES micro extension. The micro extension assumes that every event has an id through the identity extension. As such, the micro extension requires the identity extension. The micro extension then assigns a required level and an optional parent ID to each event. These attributes and their values must be interpreted as follows:

  • If the parent ID is present, then the event has the event with that ID as parent. The event must be at the next-higher level than this parent, that is, if the parent is at level 𝑋, then the event must be at level 𝑋+1.
  • If the parent ID is not present, then the level must be 1, that is, the lowest level. Only events at the lowest level have no parent.

For sake of convenience, we also introduce an optional length attribute, which holds the number of child events, that is the number of events that have this event as parent event.