A DCR XML Log format is defined in an XSD Schema which can be accessed here.

This document proposes an XML format for serializing DCR runs. Recording traces comes up in several contexts:

  • Input for the “Simulation Log” in the simulator in the portal
  • Input for the swimlane visualiser
  • Output of the path analyser
  • Data structure for saved simulations
  • (Potential) data structure for DCR logs in a process mining context

The format below attempts to cater to all of these.

One could imagine a log format that is relative to a DCR graph. Such a format would not need to represent explicitly roles or labels, as these would be reconstructible from said DCR graph. The present format *does not* attempt such minimality, opting rather to be complete enough for all of the above purposes.

2, 4, and 5 does not have such a context DCR graph.

NB! A log processor must preserve labels and nodes not mentioned in this document.

Log format

A log is a collection of traces:



[ entries ]





The log has an optional attribute called “logtype” which can be either “log” or “scenario”. A “log” comes from an IT system like DCR Open Case Manager or KMD WorkZone. A “scenario” comes from the DCR portal.

Trace format

A trace is a sequence of entries, where an entry is either an <event> element, an <advance> element, the former indicating the execution of an event, the latter that time advanced, a <note> element, a trancation element or a <subprocess> element.

The <trace> element has the following attributes:

  • Mandatory attributes
    • initTime – initialization time of trace
    • id=”19-1234″
    • created – created date of the trace
  • Optional attributes
    • title=”my very first trace”
    • description=…
    • content=… – the context in which the trace is executed
  • For scenarios – the following attributes are mandatory
    • isAccepting – true/false
    • percentage=”7″ – how often does this trace occur in the overall list of traces (scenario log)
    • type – required, neutral, forbidden (scenario log)
    • isScenario – true/false (scenario log)

The <event> element has the following attributes. Attributes not explicitly
marked as “mandatory” are optional.

  • id=”A”. The id of the event to execute. Mandatory.
  • timestamp=”2017-04-27T09:55:45.4412580+02:00″. The physical time in [ISO 8601](https://en.wikipedia.org/wiki/ISO_8601) of the execution of the event.
  • user=”Thomas”. A string identifying the user requesting the execution of the event. The interpretation of the string is implementation specific.
  • userid=”1234″. A string identifying the user uniquely. If prefixed with “portal:” it is a userid from the DCR portal.
  • role=”doctor”. The role under which the user executed the event. Multiple roles are permitted and must be separated by commas. Each role must be a “role” of the (an) underlying DCR process.
  • label=”Administer medicine”. The DCR label of the event.
  • missedDeadline=”2017-04-27T09:55:45.4412580+02:00″. This attribute indicate that the event was executed after a deadline which is provided.
  • data=”9″. The data-value supplied as input.
  • ‘type’=”int”. If data is provided the internal C# data type must be present so log verification knows the type of data

The <advance> element has the following attributes.

The <note> element has the following attributes.

  • id=”A”. The id of the event to execute. Optional.
  • comment=”this is a comment”. A comment entered by the end user. Optional.
  • timestamp=”2017-04-27T09:55:45.4412580+02:00″. The physical time in [ISO 8601]

The <transaction> element has the following attributes.

  • id=”A”. The id of the event to execute
  • timestamp=”2017-04-27T09:55:45.4412580+02:00″. The physical time in [ISO 8601

Inside the transaction element any other element, i.e. <event> can occur. This is used for DCR Forms.

The <subprocess> element has the following attributes

  • id=”A”. The id of the subprocess to execute
  • timestamp=”2017-04-27T09:55:45.4412580+02:00″. The physical time in [ISO 8601]

Moreover, the <advance> element admits the “timestamp” and “user” attributes, with syntax, requiredness and semantics as for the `event` element.


<trace id=”19-1234″ title=”My very first trace” percentage=”90,00″  initTime=”2020-01-02T15:39:25.4577929Z” context=”…”>

<event id=”A” label=”Administer medicine” data=”‘8cc'” type=”string”/>

<event id=”T” label=”Receive permission” timestamp=”2017-04-27T09:55:45.4412580+02:00″ />

<note id=”A” comment=”I do not understand why this event is still in the task list” />

<event id=”Process[0].A” label=”Initiate investigation” user=”Morten Marquard” role=”Doctor” timestamp=”2017-04-27T09:55:45.4412587+02:00″ />

<advance delta=”P0Y0M7D” />

<transaction id=”Form”>

<event id=”Amount” label=”Please enter amount” user=”Morten Marquard” role=”User” data=”123456″ timestamp=”2017-04-27T09:55:45.4412587+02:00″ />

<event id=”GDPRConsent” label=”Please accept GDPR” user=”Morten Marquard” role=”User” data=”true” timestamp=”2017-04-27T09:55:45.4412587+02:00″ />


<advance delta=”P0Y0M5D” user=”Thomas Hildebrandt (hilde@itu.dk)” timestamp=”2017-04-27T09:55:45.4412580+02:00″ />



Two types  of DCR XML Logs

  1. Scenario Log
  2. Instance log

Add definion – todo

Changes to DCR XML

We propose replacing the current “log” element with “trace”, conforming to the above specification. This proposal loses backwards compatbility on two counts:

  • Current DCR xml does not have a ‘trace’, using instead a ‘log’ element for the same purpose.
  • Current DCR uses the attribute “timeStamp” rather than “timestamp”

Ad (2). The “timestamp” attribute loses backwards compatibility with existing formats; however, as “timestamp” is an [english word](https://en.oxforddictionaries.com/definition/timestamp), the name `timestamp` is not camel-case but a spelling error.

We propose, for backwards compatibility, that the Engine correctly reads the trace-less log format and the name “timeStamp”, but always emits the new format.