Overview
Runtime entities contain read-only information relating Bizagi’s process and cases internal data.
Runtime entities are created by default in each project; you may not create additional entities nor add or modify their attributes.
|
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.
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).
•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 BPMN elements that the case has enabled, for example, user tasks, service tasks, events or timers. It is a collection of elements with its name, resolution date, its type, among others. In turn, it contains other collections described below: the statuses that each BPMN element has gone through, the list of performers 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>
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.
•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.
•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.
•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.
Last Updated 12/12/2024 12:06:10 PM