Process Traceability

It is important for organizations to know exactly what happened to their business processes. All decisions that the process engine takes are stored in the Trace Database. This means that years later, a business can inspect why certain decisions were made within the process.

The following actions result in an automatically created entry in the trace database:

Action	Action name	Description
Case Created	caseCreated	A new process has been initiated.
Case Completed	caseCompleted	A process has been completed, active nodes are deleted from the database.
Case Profile Updated	caseProfileUpdated	New data has been mapped to the process instance, leading to changes in the case profile.
Condition Opened	conditionOpened	A condition node has reached in the process, the status is open (waiting to be completed or canceled)
Condition Triggered	conditionTriggered	A condition node with the status open, has become TRUE
Message Event Opened	messageEventOpened	A message event has become relevant in the process engine. It will get the status opened, meaning it is listening to incoming events
Message Event Received	messageEventReceived	A message event has been sent to a case. This might lead to an Event Triggered when it is processed.
Event Triggered	eventTriggered	An event with the status open in the process engine, has been triggered. This could lead to a next action in the process engine.
Task Canceled	taskCanceled	A task has been canceled by a user (Cancel event has been triggered on task execution)
Task Completed	taskCompleted	A task has been completed (OK event has been triggered on task execution)
Task Opened	taskOpened	A task has become relevant. It will get the status open in the database and can be executed
Task Deleted	taskDeleted	A task has been deleted because it is no longer deemed relevant for the current state in the process
Timer Opened	timerOpened	A timer has become relevant in the process. It will be scheduled to trigger the case on a given timestamp.
Timer Triggered	timerTriggered	A timer has been completed (given time has been expired). The process has been triggered.
Task opened	decisionTaskOpened	A new instance of an ad-hoc task is created. If available, the decision that was made to open this task, is logged.
Task closed	decisionTaskClosed	An instance of an ad-hoc task is closed when the precondition will turn into FALSE. If available, the decision that was made to close this task, is logged.
Split nodes	decisionSplitNode	A process has passed a split node and has taken one or more paths based on one or more decisions. The decision that was made, is logged.
Timer expired	decisionTimerStarted	When a timer event expires, the logic is stored as a decision. Both in sequence and ad-hoc.
Conditional event evaluates to TRUE	decisionConditionTriggered	When a conditional event evaluates to TRUE, the logic is stored as a decision. Both in sequence and ad-hoc.

Some actions might lead to multiple events. For example, when an ad-hoc task has been opened, it will lead to a taskOpened event (with information about the task) and a decisionTaskOpened event. The latter will explain the information that lead to the precondition of the task to evaluate to TRUE.

Each trace event leads to a a list of stored values in the database. In the table below, the stored attributes (if applicable) for each trace event can be found:

Action Name	userid	username	caseid	processname	nodeid	taskid	decisiongraph	assignedroles	duedate	customfield_ [NAME]	displayname	assignedusers	displayname:[LanguageCode]	exitevent	exittype	triggeredby messageevent	triggeredby task	eventname	messagedata_ [NAME]	messageeventid	messageeventname	exitname	profile
caseCreated
caseCompleted
caseProfileUpdated
conditionOpened
conditionTriggered
messageEventOpened
messageEventReceived
eventTriggered
taskCanceled
taskCompleted
taskOpened
taskDeleted
taskStarted
timerOpened
timerTriggered
decisionTaskOpened
decisionTaskClosed
decisionSplitNode
decisionTimerStarted
decisionConditionTriggered

Attribute types in the trace events

The decision graph is stored following the XSD specification for the Decision Model and Notation, as defined by the Object Management Group. This specification can be found here: http://www.omg.org/spec/DMN/Current. OMG defines three levels of conformance. Blueriq follows conformance level 1. More details on how Blueriq uses the XSD schema can be found here: Creating an XML Decision Requirements Graph

The profile is an export of the whole profile at the end of the task execution. It is stored as a XML blob in the database.

Several elements will be stored in multiple lines in the database. For example the customfields (one line for each custom field value), displayname (one for each language) and messagedata (one line for each value in the message event dataset).

Space shortcuts

Page tree

Attribute types in the trace events

1 Comment

Unknown User (m.schadd)