Update from 7.18 to 7.19
This document guides you through the update from Camunda Platform
7.19.0 and covers the following use cases:
- For administrators and developers: Database updates
- For administrators and developers: Full distribution update
- For administrators: Standalone web application
- For administrators: Web apps revalidate authentications every five minutes
- For administrators: Set Job Retries Asynchronously
- For developers: Camunda external task client JS update
- For developers: Job executor priority range properties type changed
- For developers: Java External Task Client: Deprecated exception types removed
- For developers: Consolidated REST API responses for a missing process engine
- For developers: Multi-Tenancy enabled for User operation logs
- For administrators and developers: Update to WildFly 27 Application Server
This guide covers mandatory migration steps and optional considerations for the initial configuration of new functionality included in Camunda Platform 7.19.
Every Camunda installation requires a database schema update. Check our database schema update guide for further instructions.
This section is applicable if you installed the Full Distribution with a shared process engine.
The following steps are required:
- Update the Camunda libraries and applications inside the application server.
- Migrate custom process applications.
Before starting, ensure you have downloaded the Camunda Platform 7.19 distribution for the application server you use.
This contains the SQL scripts and libraries required for the update. This guide assumes you have unpacked the distribution
to a path named
Camunda libraries and applications
Choose the application server you are working with from the following list:
Custom process applications
For every process application, the Camunda dependencies should be updated to the new version. Which dependencies you have is application- and server-specific. Typically, the dependencies consist of the following:
There are no new mandatory dependencies for process applications.
Standalone web application
If you use a standalone web application, replace the current
.war artifact with its new version.
Take the following steps to complete the update:
- Undeploy the current version of the standalone web application.
- Update the database to the new schema as described in the database update section.
- Configure the database as described in the installation section.
- Deploy the new and configured standalone web application to the server.
Web apps revalidate authentications every five minutes
Previously, after a user logged into the web apps, the authentication cache was valid for the lifetime of the HTTP session, which has security implications.
With this release, we introduced a time to live for the authentication cache, configured to five minutes by default. This new default might lead to a higher load on your database.
You can read how to configure the time to live to a smaller interval or restore the legacy behavior (disable the authentication cache time to live) in the documentation about Web Applications.
Set Job Retries Asynchronously
We have extended the Set Job Retries Batch Operation. There are now new options that allow to set the due date of a job while also setting the number of retries. Please bear in mind that the usage of new features during a rolling update leads to unexpected behavior and therefore must be avoided: When a set retries batch with due date is created during a rolling update, due dates might or might not be set depending on the executing engine (old/new engine).
Camunda external task client JS update
We always strive to keep up with established standards and reduce technical debt which is why we decided to move away from CommonJS in favor of ECMAScript modules (ESM).
This means that the latest 3.0 version of the Camunda external task client JS
is now a pure ECMAScript module. Furthermore, the minimum required NodeJS to run the client is version 18.
If your project is already using ECMAScript modules then you can update to this version without any problems.
However, if your project uses the CommonJS module system then you have the following choices:
- If the package is used in an async context, you could use
await import(…) from CommonJS instead of
- Transpile the module into CommonJS using babel for instance.
- Convert your project to ECMAScript Modules.
Job executor priority range properties type changed
The two dedicated job executor priority range properties jobExecutorPriorityRangeMin and jobExecutorPriorityRangeMax have been change to primitive type
long. That allows for the properties to be configured for every process engine configuration. Respectively their default values changed to
Java External Task Client: Deprecated exception types removed
In 7.18, we deprecated the exception types
With this release, we removed the exception types as announced in the migration guide from 7.17 to 7.18.
Please make sure to adjust your business logic accordingly.
Consolidated REST API responses for a missing process engine
Up until 7.19, the behavior of the REST API varied from endpoint to endpoint regarding the error message you receive when the defined named process engine cannot be found. We consolidated this behavior, so every endpoint now issues the same exception with status code 400 and the message “No process engine available”.
Multi-Tenancy enabled for User operation logs
Tenant information is populated for User operation logs from 7.19 onwards, user operation logs created prior will stay as they are. If tenant check is enabled in the process engine, a tenant membership check will be performed for the following operations:
- User operation log query
- Deleting a user operation log
- Adding/Clearing a user operation log annotation
In case you want to avoid tenant check, please refer to Disable the transparent access restrictions.
Update to WildFly 27 Application Server
With this release, we support WildFly 27, the new default pre-packaged WildFly distro. It replaces Java EE with Jakarta EE APIs. If you prefer to stay on WildFly ≤26 or JBoss EAP 7, you can still download the Java EE compliant modules, web application, and REST API.
To work with Wildfly 27, consider the following when migrating your process applications and replacing artifacts on the application server:
Migrate process applications
- Replace Java EE class references (
javax.*) with Jakarta class references (
- You might have a look at
- You might have a look at
- Replace Camunda class references:
- Replace Camunda Maven dependencies:
Replace artifacts on the application server
You can find the new artifacts either in the current WildFly distribution or in the
- Camunda WildFly Subsystem under
Replace web application (Cockpit, Admin, Tasklist, Welcome) deployment
Replace the artifact
Replace REST API deployment
Replace the artifact