The database schema of the process engine consists of multiple tables. The table names all start with ACT. The second part is a two-character identification of the use case of the table. This use case will also roughly match the service API.

• ACT_RE_*: RE stands for repository. Tables with this prefix contain ‘static’ information such as process definitions and process resources (images, rules, etc.).
• ACT_RU_*: RU stands for runtime. These are the runtime tables that contain the runtime data of process instances, user tasks, variables, jobs, etc. The engine only stores the runtime data during process instance execution and removes the records when a process instance ends. This keeps the runtime tables small and fast.
• ACT_ID_*: ID stands for identity. These tables contain identity information such as users, groups, etc.
• ACT_HI_*: HI stands for history. These are the tables that contain historical data such as past process instances, variables, tasks, etc.
• ACT_GE_*: General data, which is used in various use cases.

The main tables of the process engines are the entities of process definitions, executions, tasks, variables and event subscriptions. Their relationship is shown in the following UML model.

Process Definitions (ACT_RE_PROCDEF)

The ACT_RE_PROCDEF table contains all deployed process definitions. It includes information like the version details, the resource name or the suspension state.

Executions (ACT_RU_EXECUTION)

The ACT_RU_EXECUTION table contains all current executions. It includes information like the process definition, parent execution, business key, the current activity and different metadata about the state of the execution.

Tasks (ACT_RU_TASK)

The ACT_RU_TASK table contains all open tasks of all running process instances. It includes information like the corresponding process instance, execution and also metadata such as creation time, assignee or due date.

Variables (ACT_RU_VARIABLE)

The ACT_RU_VARIABLE table contains all currently set process or task variables. It includes the names, types and values of the variables and information about the corresponding process instance or task.

Event Subscriptions (ACT_RU_EVENT_SUBSCR)

The ACT_RU_EVENT_SUBSCR table contains all currently existing event subscriptions. It includes the type, name and configuration of the expected event along with information about the corresponding process instance and execution.

Schema Log (ACT_GE_SCHEMA_LOG)

The ACT_GE_SCHEMA_LOG table contains a history of the database schema version. New entries to the table are written when changes to the database schema are made. On database creation the initial entry is added. Every update script adds a new entry containing an id, the version the database was updated to and the date and time (timestamp) of the update.

To retrieve entries from the schema log, the SchemaLogQuery-API can be used:

List<SchemaLogEntry> entries = managementService.createSchemaLogQuery().list();

Metrics Log (ACT_RU_METER_LOG)

The ACT_RU_METER_LOG table contains a collection of runtime metrics that can help draw conclusions about usage, load and performance of CIB seven. Metrics are reported as numbers in the Java long range and count the occurrence of specific events. Please find detailed information about how metrics are collected in the Metrics User Guide.

The default configuration of the MetricsReporter will create one row per metric in ACT_RU_METER_LOG every 15 minutes.

Task Metrics Log (ACT_RU_TASK_METER_LOG)

The ACT_RU_TASK_METER_LOG table contains a collection of task related metrics that can help draw conclusions about usage, load and performance of the BPM platform. Task metrics contain a pseudonymized and fixed-length value of task assignees and their time of appearance. Please find detailed information about how task metrics are collected in the Metrics User Guide.

Every assignment of a task to an assignee will create one row in ACT_RU_TASK_METER_LOG.

Entity Relationship Diagrams

The following Entity Relationship Diagrams visualize the database tables and their explicit foreign key constraints, grouped by Engine with focus on BPMN, Engine with focus on DMN, Engine with focus on CMMN, the Engine History and the Identity. Please note that the diagrams do not visualize implicit connections between the tables.

Engine BPMN

Engine DMN

Engine CMMN

History

To allow different configurations and to keep the tables more flexible, the history tables contain no foreign key constraints.

Identity