CMMN Deprecation & Removal

Why CMMN is being removed

Adoption data shows marginal usage of the CMMN notation. EximeeBPMS is concentrating investment on BPMN, Human Workflow, and business orchestration. Case management patterns remain fully supported through BPMN — see the mapping table below.

This change applies to both the Open Source and Enterprise editions, though not at the same time — see the Enterprise Edition note above.

1. Detect CMMN usage

Check three categories of data in your database: deployed definitions, active instances, and historic data.

PostgreSQL / Oracle

-- (1) Deployed CMMN definitions
SELECT COUNT(*) AS deployed_case_definitions FROM ACT_RE_CASE_DEF;

-- (2) Active case instances (a row with no PARENT_ID_ is a top-level instance, not a sub-execution)
SELECT COUNT(*) AS active_case_instances
FROM ACT_RU_CASE_EXECUTION
WHERE PARENT_ID_ IS NULL;

-- (3) Historic CMMN data
SELECT COUNT(*) AS historic_case_instances FROM ACT_HI_CASEINST;
SELECT COUNT(*) AS historic_case_activity_instances FROM ACT_HI_CASEACTINST;

Interpreting the results

2. Handling active case instances

If the query in step 1(2) returned a result greater than 0, finish or close those instances on version 1.3.0 before upgrading:

• Java API: caseService.withCaseExecution(caseInstanceId).close().execute() (or .complete() / .terminate(), depending on the modeled flow).
• REST API: POST /case-instance/{id}/close, /complete, or /terminate.

1.4.0 behavior when ACT_RU_CASE_EXECUTION is not empty: the 1.3-to-1.4 migration halts before making any schema changes, with an error along these lines:

Cannot upgrade to 1.4: active CMMN case instances exist in ACT_RU_CASE_EXECUTION.
This migration drops CMMN history and runtime tables unconditionally; 
complete or terminate all active case instances before upgrading.

Recognize this message in your runbooks. Exactly when you see it depends on how your deployment applies schema migrations: for setups with automatic schema updates enabled, this coincides with engine startup; for setups where migrations are applied as a separate step (a CI/CD job, a DBA-run script), it surfaces there instead.

What to do when you see this error: the migration halts before making any schema changes, so your database is left exactly as it was — there is nothing to roll back or repair. Finish or close the remaining active case instances as described above, then re-run the same migration step again; it will re-check ACT_RU_CASE_EXECUTION and proceed normally once the count is 0.

3. Fate of historical data

The migration deletes CMMN data unconditionally — there is no data-preservation guarantee. Once the fail-fast check in step 2 passes (no active case instances), the migration drops:

• Deployed case definitions: ACT_RE_CASE_DEF
• Historic data: ACT_HI_CASEINST, ACT_HI_CASEACTINST
• Any remaining CMMN runtime tables: ACT_RU_CASE_EXECUTION, ACT_RU_CASE_SENTRY_PART

along with CMMN-specific columns on several shared runtime/history tables. This is irreversible — there is no downgrade script and no separate, opt-in cleanup step: the deletion happens as part of the migration itself, every time.

Important consequence: the REST history endpoints for case data are removed in 1.4.0 along with the rest of the CMMN REST API (see Impact on REST clients). Organizations that need to retain CMMN history (for example, for retention or audit requirements) must export it before upgrading — there is no way to recover it afterward, from the REST API or by querying the database directly, since the tables themselves are gone. Run something like this against your 1.3.0 database, and save the results, before starting the upgrade:

SELECT ci.*, aci.CASE_ACT_ID_, aci.CASE_ACT_NAME_, aci.CREATE_TIME_, aci.END_TIME_
FROM ACT_HI_CASEINST ci
LEFT JOIN ACT_HI_CASEACTINST aci ON aci.CASE_INST_ID_ = ci.CASE_INST_ID_
ORDER BY ci.CASE_INST_ID_, aci.CREATE_TIME_;

4. Deployment validation

1.4.0 behavior: deploying a package that contains a .cmmn, .cmmn10.xml, or .cmmn11.xml file results in the whole deployment being explicitly rejected with a clear error — files are never silently skipped.

Audit your deployment artifacts before upgrading — search your repositories and CI/CD pipelines for CMMN files:

grep -rl --include="*.cmmn" --include="*.cmmn10.xml" --include="*.cmmn11.xml" .
find . -iname "*.cmmn" -o -iname "*.cmmn10.xml" -o -iname "*.cmmn11.xml"

Smoke-test your whole environment: setting eximeebpms.bpm.cmmn-enabled=false in 1.3.0 (see step 1) lets you verify deployment behavior before the actual upgrade.

5. Impact on embedded engine code

The following public Java API classes and interfaces are marked @Deprecated as of 1.3.0 and will be removed in 1.4.0. To find usages in your code, search for references to the classes below, or compile with -Xlint:deprecation.

Embedded-engine users who implement CaseExecutionListener / CaseVariableListener, or call CaseService directly, will get compile errors after upgrading to 1.4.0 — removing these references is a prerequisite for the upgrade.

6. Impact on REST clients

The following REST endpoints disappear in 1.4.0 (marked @Deprecated as of 1.3.0, with Deprecation: true and Sunset response headers per RFC 8594):

If your client is generated from the published OpenAPI specification, you will not see CMMN there — these endpoints were never part of the public OpenAPI spec. If you call these paths manually or from Javadoc-based documentation, use the list above.

7. Mapping CMMN patterns to BPMN

The table below is a starting point, not a mechanical recipe — CMMN patterns do not map 1:1 onto BPMN.

8. Feedback channel

If you have questions about migrating your specific CMMN use case, reach out via GitHub Discussions / the issue tracker before planning your 1.4.0 upgrade — every report of production CMMN usage will be reviewed individually.