Persistence
The tSM Process Engine primarily uses a relational database to store runtime and historical information about process definitions, instances, tasks, variables, and more.
For historical data (ACT_HI_* tables), you can optionally select Elasticsearch instead of the relational database. Elasticsearch is more efficient for time-based queries, advanced analytics, and Index Lifecycle Management (e.g., automatic archiving or deletion of aged data).
Since historical data can grow significantly, retention policies (Data Aging) are essential. You can configure automatic cleanup or archival to manage database size effectively.
In a typical tSM deployment, each microservice that uses the process engine has its own database instance or schema. This ensures process runtime data is isolated and dedicated to the respective service (e.g., ticketing, ordering).
1. Database Schema overview
- Repository Tables (ACT_RE_*): Store static (read-only) definitions of processes, decisions, forms, etc.
- Runtime Tables (ACT_RU_*): Track in-flight data (process instances, tasks, jobs, etc.).
- Identity Tables (ACT_ID_*): Usually store user, group, and tenant information—but unused in tSM because user management is external to the process.
- History Tables (ACT_HI_*): Keep historical (audit) data for completed or past operations; can be partially or fully offloaded to Elasticsearch in tSM 2.0+.
- General Tables (ACT_GE_*): Contain engine-level properties, schema logs, and large binary data.
- Custom (ACT_TSM_*): A special table (
act_tsm_planned_task
) introduced by tSM for additional scheduling features.
2. Repository Tables (ACT_RE_*)
These tables contain static definitions and metadata related to deployments, process definitions, decision definitions, and case definitions (if used).
Table Name | Description | Usage in tSM |
---|---|---|
act_re_deployment | Stores metadata about deployments (e.g., deployment name, time). | Used for versioning process/decision resources. |
act_re_procdef | Holds BPMN process definition metadata (version, key, name). | Core for BPMN processes in tSM. |
act_re_case_def | CMMN case definition metadata. | Unused in tSM (case management is disabled). |
act_re_camformdef | Stores deployed forms (if using embedded forms). | Unused in tSM (tSM has special Form Designer instead). |
act_re_decision_def | DMN decision definition metadata. | Decision tables. |
act_re_decision_req_def | Tracks requirement relationships between decision definitions (DMN dependencies). | Used if referencing multiple DMN files for complex decision logic. |
3. Runtime Tables (ACT_RU_*)
These tables maintain in-flight (active) process data, including tasks, variables, events, incidents, and more.
Table Name | Description | Usage in tSM |
---|---|---|
act_ru_execution | Tracks active process executions (process instances and sub-executions). | Core runtime table: holds state of running processes. |
act_ru_task | Stores user tasks of active process instances (assignee, due date, etc.). | Used for human tasks in tSM workflows. |
act_ru_variable | Holds runtime variables for processes and tasks (names, types, values). | Core for storing variables; references act_ge_bytearray for large data. |
act_ru_event_subscr | Stores event subscriptions (messages, signals) waiting to be triggered. | Used to handle external events or triggers in a process flow. |
act_ru_incident | Tracks runtime incidents (errors, failed jobs, etc.). | Useful for error handling; logs issues during runtime. |
act_ru_job | Holds timer and asynchronous jobs pending or scheduled by the engine. | Key for scheduling tasks or retrying failures. |
act_ru_jobdef | Template definitions for recurring jobs (created at deployment). | Enables repeated timers/asynchronous tasks. |
act_ru_batch | Records batch operations (mass operations like migrations or cancellations). | Used for async processing of large sets of process instances. |
act_ru_authorization | Manages runtime authorizations within the engine (Flowable/Camunda feature). | Unused in tSM. |
act_ru_identitylink | Links users/groups to tasks/processes (e.g., candidate assignments). | Users / User Groups assigned to a task . |
act_ru_filter | Stores filters (for tasks, processes, etc.) commonly used by UI queries. | Unused in tSM. |
act_ru_ext_task | Tracks external tasks if using an external task pattern (e.g., workers pulling tasks). | Storage of external tasks. |
act_ru_case_execution | Runtime info for CMMN case execution. | Unused in tSM (case management is off). |
act_ru_case_sentry_part | Tracks sentry parts for CMMN case execution. | Unused in tSM (case management is off). |
act_ru_meter_log | Logs runtime metrics (engine performance, usage). | Useful for monitoring. |
act_ru_task_meter_log | Logs metrics specifically for tasks, including pseudonymized assignees. | Helps analyze task performance and user workload. |
4. Identity Tables (ACT_ID_*)
tSM uses external user management, so these tables (common to BPM engines) remain unused in most tSM installations.
Table Name | Description | Usage in tSM |
---|---|---|
act_id_user | Stores user account data (username, password, etc.). | Not used; external. |
act_id_group | Stores group data (e.g., role definitions). | Not used; external. |
act_id_membership | Maps users to groups. | Not used; external. |
act_id_info | Additional user info (tokens, user profile details). | Not used; external. |
act_id_tenant | For multi-tenancy identification. | Not used; external. |
act_id_tenant_member | Maps tenants to users/groups. | Not used; external. |
5. History Tables (ACT_HI_*)
These tables track past or completed data for audit and reporting. From tSM 2.0, you can store this data in Elasticsearch instead (recommended for large workloads). If you continue to use relational history, these tables are populated accordingly.
Table Name | Description | Usage in tSM |
---|---|---|
act_hi_procinst | Records completed/terminated process instance data (start/end time, initiator, etc.). | Core historical process data. |
act_hi_actinst | Historical record of activity instances (each BPMN activity executed). | Used for auditing process flow. |
act_hi_taskinst | Stores task instance history (start time, end time, assignee). | Key auditing table for tasks. |
act_hi_varinst | Logs variable changes over time (name, type, value). | Auditing variable evolution. |
act_hi_attachment | Records task attachments historically. | If tasks have attached files or references. |
act_hi_comment | Logs comments added to tasks or process instances. | Useful for an audit trail of user inputs. |
act_hi_decinst | Historical entries for DMN decisions (when decisions are evaluated). | Key if using decision tasks. |
act_hi_dec_in | Logs input data for historical decision instances. | Detailed DMN input auditing. |
act_hi_dec_out | Logs output data for historical decision instances. | Detailed DMN output auditing. |
act_hi_caseinst | Historical info about case instances (CMMN). | Unused in tSM (case management off). |
act_hi_caseactinst | Historical info about case activities. | Unused in tSM. |
act_hi_batch | Records completed batch operations (linked to act_ru_batch ). | Audits large-scale batch changes. |
act_hi_detail | Stores form properties or other detailed logs (e.g., variable details) for auditing. | Helpful for fine-grained historical data. |
act_hi_ext_task_log | Logs history of external tasks (if using external task patterns). | Only relevant if external tasks are enabled. |
act_hi_identitylink | History of identity link changes. | Not used if external identity mgmt is enforced, but table may exist. |
act_hi_incident | Logs resolved incidents historically. | Audits error/failure events after resolution. |
act_hi_job_log | Tracks job lifecycle (creation, execution, retries, failures). | Useful for diagnosing job behavior over time. |
act_hi_op_log | Operational logs for administrative actions (e.g., user creation, process definition edits). | Often unused in tSM if user management is external, but can capture engine ops. |
6. General Tables (ACT_GE_*)
These tables store global or engine-level data, including schema versions, properties, and large binary objects.
Table Name | Description | Usage in tSM |
---|---|---|
act_ge_bytearray | Contains large binary data (e.g., file attachments, variable values). | Referenced by runtime/history variable tables for storing big payloads. |
act_ge_property | Key-value pairs for engine configurations (e.g., schema version). | Holds critical engine settings and upgrade logs. |
act_ge_schema_log | Keeps track of schema changes over time. | Logs each DB upgrade step; important for versioning and migrations. |
7. Custom tSM Table
While most tables follow the ACT_*
naming convention, tSM also includes its own custom or extension tables. Currently, there is one such table explicitly noted:
Table Name | Description | Usage in tSM |
---|---|---|
act_tsm_planned_task | Custom table for planned tasks (scheduling info). | Stores data for scheduled tasks specific to tSM logic. |
8. Summary
- All tables listed (repository, runtime, identity, history, general, and custom) are covered.
- Identity (ACT_ID_*) and Case Management (CMMN-related) tables remain unused in standard tSM (user management and case features are external/disabled).
- For large-scale history requirements, Elasticsearch is recommended from tSM 2.0 onward.
- The
act_tsm_planned_task
table is a custom extension, supporting additional scheduling capabilities not covered by standard BPMN/DMN.
This tabular overview ensures you have a clear understanding of each table’s purpose, usage, and whether it is active or deprecated in a typical tSM environment.
Below is an updated overview of the tSM Process Engine Database Schema with an expanded introduction that clarifies how the process engine persists data, how Elasticsearch can be used for historical data, and how each microservice in tSM maintains its own database or schema.