You are viewing the documentation for Blueriq 17. Documentation for other versions is available in our documentation directory.
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).
Overview
Content Tools
1 Comment
Unknown User (m.schadd)
Thanks, I updated the link.