Runtime entities

<< Click to Display Table of Contents >>

Navigation:  Bizagi Studio > Process wizard > Data Modeling > Entity types >

Runtime entities

Overview

Runtime entities contain read-only information relating Bizagi’s process and cases internal data.

This information is available to be easily exposed for Business Insights through the BI connector, to create powerful reports.

Runtime entities are created by default in each project; you may not create additional entities nor add or modify their attributes.

 

note_pin

Runtime entities are not backward compatible. If processes are created in 11.2.5 version or above using Runtime Entities, they cannot be shared on previous versions.

 

Data model: entities and relationships of Runtime entities

 

Case / BA_CaseInfo

The main entity where Runtime entities can be navigated from is called BA_CaseInfo, from the Entities view, and Case from the Forms, Expressions and mapping view. BA_CaseInfo is the most important table of the Runtime entities, where all other relationships are created.

 

 

RuntimeEntities2

 

For every process in the project, from the application entity there is a default Process entity created automatically. Along with it there is a relationship to the Case entity. Thus, the Runtime entities must be used in the context of a case.

 

The Case entity contains an IdCase attribute that refers to the customized case number (with sequence or rule, not to the RadNumber).

 

RuntimeEntities3

 

Case status history / BA_CaseStatusHistory:

This table contains the history log of the statuses that a case has gone through, since its start until its current status. Each record contains the date and the performer that moved the case to said status. Its records are returned as a collection.

 

Activity / BA_ActivityInfo

This table contains the log of all the activities that the case has enabled. It is a collection of Activities with its name, resolution date, its type, among others. In turn, it contains other collections described below: the statuses that each Activity has gone through, the list of performes of each task, the list of performers of all activities and the reallocation activities (if any).

 

Activity status history / BA_ActivityStatusHistory

This entity contains the log of the different statuses that each activity has gone through in a case.

 

Performer history / BA_PerformerHistory

This entity contains the history of all the performers of the activities.

 

Reassignment history / BA_ReassignHistory

This entity contains the history of reassignments, if any, of the activities. It stores who the initial performer was, who was the performer to take the Task and who made the reassignment.

 

Transition history / BA_TransitionHistory: This entity lists all the different transitions that happened in a case. It stores which was the initial shape, where it transitioned to and who was responsible for the transition.

 

The following is the Runtime entities data model displaying the entities, their attributes and their relationships. Notice that it starts from the Application entity as it contains the relationship to the Case entity, which is depicted in blue.

The red lines depict one-to-many relationships and the green one is a many-to-many relationship.

 

To navigate the Runtime entities via Xpath, it is necessary to use the relationship as displayed in the diagram.

For example to obtain the list of performers of each status of the case we will use:

 

<Case.CaseStatusHistory.IdStatusPerformer.fullName>

 

RuntimeEntities1

 

 

Runtime entities How to's

In the following articles you will find how to use Runtime entities in the different modules available:

How to use Runtime entities in Forms.
Note: Runtime entities that are related to collections are not available in Forms​

How to use Runtime entities in Expressions

Using Runtime entities in Document templates (Word, Excel, Plain text)

Using Runtime entities in emails

Using Runtime entities in Connectors.

 

Considerations

Each table has an identifier attribute, that contains each record's Id, that makes it unique from the other records of the table. Three tables displayed below as an example, have their identifier highlighted. These identifiers allow each table's record to be unique. All attributes and relationships of Runtime entities are created by default. When cases are flowing, the records are created automatically, and identifiers are set automatically as well.

 

RuntimeEntities4

The IdCase attribute in most of the Runtime entities is a relationship with the CaseInfo table, not the actual IdCase of an ongoing case. For example notice the entity Activity Info: it contains an attribute called IdCase. In Studio you can see that this attribute relates the Activity Info entity with the Case Info entity, as a one-to-many relationship.

 

RuntimeEntities5

Whenever Performer is used as an attribute in the Runtime entities, it is a relationship with the WFUser table. For example in the Performer History entity, there is an attribute called idAllocation performer. It is related to the WFUser table.

 

RuntimeEntities6

Runtime entities are read only. Neither attributes can be created inside them nor relationships may be built targeting them.

 

They work from the context of a case. That is. they need a case to retrieve information.

 

They are not available from: OData, SOA, Tableau/PowerBI, RAML, OpenAPI, Experience design, Custom Columns for the Work Portal, Automatic notifications (Task notification, Cancel notification, Alarms), Jobs, Library rules, Start Forms, Query Forms, Live Processes nor Plans. Runtime entities that are related to collections are not available in Forms​.

 

The source of any information obtained from the runtime entities is the environment's database. Therefore, information saved on temporary storage, cannot be obtained through runtime entities.
 
For example, when you use an attribute related to a runtime entity case within a Start event, the case's information is not stored in the database yet, but in a temporary location because it is waiting for the user confirmation to create the case.
 
As another example, when you use an attribute associated with a task of a runtime entity on a rule execute On Enter, this information is stored in a temporary location. In case you need to access information stored on a temporary location, you can use the Me Object.