Database Schema

When the modeler is enabled (cibseven.webclient.modeler.enabled: true), the webclient requires a database schema to store diagrams, forms, and user sessions. The required tables must be created before startup. The webclient can connect to and use the database, but it does not create, update, or validate the schema itself (ddl-auto: none).

When the modeler is disabled (cibseven.webclient.modeler.enabled: false), its persistence components are disabled with it. If no other feature of the webclient stores data — the enterprise chat does — then no datasource configuration or database connection is required at all, as JPA is not initialized.

Schema creation is the responsibility of the parent application (e.g. cibseven-bpm-run). Refer to the parent application’s documentation for the DDL scripts and migration tooling it provides.

Database Tables

Table	Description
mod_processes_diagrams	Stores BPMN and DMN diagram metadata and the raw XML
mod_forms	Stores form schemas as JSON
mod_user_sessions	Tracks open editing sessions per user
mod_diagram_usage	Associates a user session with a specific diagram
mod_form_usage	Associates a user session with a specific form
mod_element_templates	Stores reusable element template definitions
mod_folders	The folders diagrams and forms are organized in. Each row names its parent, so the table holds the whole tree; a row without a parent is a folder at the top level. Required from 2.3.0
mod_processes_diagrams_aud	Stores one snapshot of a diagram per save, so earlier states can be browsed, restored and compared. Written only by the enterprise edition; the community edition leaves it empty
mod_revinfo	Numbers those snapshots and records when each was written. Enterprise Edition only
chat_messages	Stores real-time chat messages per room. Deleted messages are soft-deleted: the content is cleared and the row is retained as a tombstone, marked by deleted_at, so that polling clients learn about the deletion. Enterprise Edition only.
chat_presence	Tracks active users per chat room for the long-polling transport. Each row is a heartbeat record refreshed on every poll; stale entries are purged automatically. Enterprise Edition only.

Schema Updates

The modeler tables are part of the engine schema, so they are updated with it. Follow the database schema update guide — either the Liquibase changelog or the $DATABASENAME_engine_$X_to_$Y.sql scripts — rather than applying modeler DDL by hand.

2.2 to 2.3

The long-polling chat transport added two schema changes, both applied by the 2.2-to-2.3 changelog entry and by the $DATABASENAME_engine_2.2_to_2.3.sql scripts:

• the chat_presence table
• the deleted_at column on chat_messages

A 2.2 installation that already used the chat over the websocket transport needs this update before switching to longpolling: without chat_presence and deleted_at, presence and deletion events cannot be served from the database.

Folders

The modeler organizes diagrams and forms in folders from 2.3.0, which the same update applies:

• the mod_folders table
• a folder_id column on mod_processes_diagrams and on mod_forms, each with a foreign key to mod_folders
• a folder named General, and every existing diagram and form filed into it

The models of an installation that is updated therefore keep working and appear together in one folder, rather than in a list that has nowhere to belong. The id of that folder is written out in the update script rather than generated, so the same statement can both create it and file the models into it on every database.

Diagram snapshots

From 2.3.0 the enterprise edition writes the diagram snapshots itself, where earlier versions had Hibernate Envers write them. This needs no schema change and no migration: mod_processes_diagrams_aud and mod_revinfo keep the shape they had, snapshots written by 2.2 stay readable, and snapshots written by 2.3 have the same columns filled.

What does change is that spring.jpa.properties.hibernate.integration.envers.enabled no longer has any effect and can be dropped from the configuration — including from the Helm values, where it was set for the webclient deployment. Leaving it in place is harmless: nothing reads it any more.

Supported Databases

Refer to Prerequisites for supported database versions.