Upgrade from 7.5 to 7.6
This document guides you through the upgrade from Camunda BPM
7.6.0. It covers these use cases:
- For administrators and developers: Database Upgrades
- For administrators and developers: Full Distribution Upgrade
- For administrators: Standalone Web Application
- For administrators: Updating a Tasklist Translation File
- For administrators and developers: Application with Embedded Process Engine Upgrade
This guide covers mandatory migration steps as well as optional considerations for initial configuration of new functionality included in Camunda BPM 7.6.
Noteworthy new Features and Changes in 7.6:
Rolling upgrades are supported starting at upgrades from version 7.5.x to 7.6.0. Please read the detailed documentation about the process and its limitations.
- The isExecutable attribute is mandatory
By default, the isExecutable attribute of a process is false. In Camunda BPM 7.6, process definitions without the isExecutable attribute or with the attribute set to false are not deployed to the engine. So every process which should be executed needs this attribute in the process definition to be deployed. Old processes which are deployed on an earlier version are also deployed without this attribute.
- Manual activation rule defaults changed
Default behavior of manual activation rules in CMMN is changed. If your current case definitions are based on the fact of required manual activation and you would like to keep that behavior, please adjust your case diagrams to include manual activation rules.<manualActivationRule/>Otherwise, if your case definitions do not have manualActivationRule elements, but use caseService.manuallyStartCaseExecution(caseExecutionId) to manually start executions and you would like your executions to start right away, please remove caseService.manuallyStartCaseExecution(caseExecutionId) from your code.
- DMN namespace change
The namespace for DMN 1.1 was changed after our 7.4.0 Release. The official namespace is now: http://www.omg.org/spec/DMN/20151101/dmn.xsd
Every Camunda installation requires a database schema upgrade.
Check for available database patch scripts for your database that are within the bounds of your upgrade path. Locate the scripts at
$DISTRIBUTION_PATH/sql/upgradein the pre-packaged distribution (where
$DISTRIBUTION_PATHis the path of an unpacked distribution) or in the Camunda Nexus. We highly recommend to execute these patches before updating. Execute them in ascending order by version number. The naming pattern is
Execute the corresponding upgrade scripts named
The scripts upgrade the database from one minor version to the next, and change the underlying database structure. So make sure to backup your database in case there are any failures during the upgrade process.
We highly recommend to also check for any existing patch scripts for your database that are within the bounds of the new minor version you are updating to. Execute them in ascending order by version number. Attention: This step is only relevant when you are using an enterprise version of the Camunda BPM platform, e.g.,
X > 0. The procedure is the same as in step 1, only for the new minor version.
This section is applicable if you installed the Full Distribution with a shared process engine.
The following steps are required:
- Upgrade the Camunda libraries and applications inside the application server
- Migrate custom process applications
Before starting, make sure that you have downloaded the Camunda BPM 7.6 distribution for the application server you use. It contains the SQL scripts and libraries required for upgrade. This guide assumes you have unpacked the distribution to a path named
Camunda Libraries and Applications
Please choose the application server you are working with from the following list:
The pre-built Camunda 7.6 distribution ships with Wildfly 10.1.0, whereas 7.5 ships with Wildfly 10.0.0. Camunda 7.6 is supported on Wildfly 8.2 and 10.0 such that a Wildfly upgrade is not required when migrating from 7.5 to 7.6.
Custom Process Applications
For every process application, the Camunda dependencies should be upgraded to the new version. Which dependencies you have is application- and server-specific. Typically, the dependencies consist of any of the following:
There are no new mandatory dependencies for process applications.
Standalone Web Application
If the standalone web application is in use, the current
war artifact must be replaced by its new version.
If a database other than the default H2 database is used, the following steps must be taken:
- Undeploy the current version of the standalone web application
- Upgrade the database to the new schema as described in the database upgrade section
- Reconfigure the database as described in the installation section
- Deploy the new and configured standalone web application to the server
Tasklist Translation File
The following labels must be added to the Tasklist locale file:
Have a look at the english translation file for a basis to translate.
Application with Embedded Process Engine
This section is applicable if you have a custom application with an embedded process engine.
Upgrade the dependencies declared in your application’s
pom.xml file to the new version. Which dependencies you have is application-specific. Typically, the dependencies consist of any of the following:
There are no new mandatory dependencies. That means, updating the version should suffice to migrate a process application in terms of dependencies.
This section describes changes in the engine’s default behavior. While the changes are reasonable, your implementation may rely on the previous default behavior. Thus, the previous behavior can be restored by explicitly setting a configuration option. Accordingly, this section applies to any embedded process engine but is not required for a successful upgrade.
Custom Mapping of the Decision Result
With Camunda 7.6, the type of the decision result has changed from
DmnDecisionResult. If the decision result of a business rule task or a decision task is processed by an
ExecutionListener or a
CaseExecutionListener (i.e., custom decision result mapping), then the listener has to adjusted to use the new result type. Since the type is semantically equal and provides the same methods, only the type of the result has to be changed.