Camunda BPM Supports DMN 1.3 End-to-End

Camunda BPM product supports DMN 1.3 now end-to-end (from deployment to end user).
This release adds support in Cockpit for DMN 1.3, the next version of the DMN standard. If you edit and deploy DMN diagrams in Cockpit which use earlier versions of DMN, they will automatically be migrated to DMN 1.3.

The Camunda engine already supports the DMN 1.3 namespace since the last alpha release, so there are no more steps required to migrate. Make sure you have the latest alpha version of Camunda Modeler installed to edit DMN 1.3 files locally and read all about in the Modeler’s blog post.

Failed Activity ID in Cockpit

With the first alpha of 7.13, we included the id of the failed activity in jobs and incidents for quicker root causing of failures (see the related blog post). To find the exception root causes even faster, you can now view the Failed Activity in the Cockpit Job log.

The new attribute can be found in these tables:

the Process Instance Jobs tab

the Incidents tabs

the History Job logs

Progress on the Camunda Rest API OpenAPI Documentation

This alpha brings even more additions to the OpenAPI documentation started in Camunda 7.13-alpha2. Now, you can also
find documentation on the following endpoints:

Condition

Deployment

Engine

External Task

Message

Metrics

Process Instance

Signal

Schema Log

Task

Version

If you are interested in our progress or if you want to check out the documentation, please feel free to download the
JAR file here.

More Fine-Grained Historic Task Permissions

The example process shown below has two tasks. The token starts waiting in Evaluate Yourself, and
the task is assigned to the employee Steve. When Steve enters his self-evaluation and completes
the task, the token moves further to Evaluate Employee, and the task is assigned to Steves manager
Kate.

Previously, Steve couldn’t look up his self-evaluation after completing the task. With this release,
an additional historic task read permission is granted when a user is assigned to a task that allows
seeing the task-related history data (i. e., variable, detail & identity link log history).

You can enable the feature with the help of a process engine configuration flag:

Deployment-Aware Batch Operations

With this release, all batch operations that work on process-related elements, e.g. process instances, are deployment-aware.

Since Monitor Jobs do not need any deployment-related resources anymore with this release as well,
only Seed Jobs and Execution Jobs are affected by this. Technically, seed jobs and execution jobs will receive a deploymentId so deployment-aware job executors can pick up those jobs of a batch that need to be executed on their nodes.

The deployment id of the seed job is chosen from a list of involved deployments. The list of deployments involved in a batch is derived from the elements of the batch operation, e.g. for chosen process instances the deployments their process definitions belong to are fetched. Execution jobs only contain elements of the same deployment and are bound to it as well.

Make sure to check our Update Guide for further details on this feature with regards to version updates.