Noteworthy new Features and Changes in 7.6:

  • The isExecutable attribute is mandatory
  • Manual activation rule defaults changed
  • DMN namespace change

Database Updates

Every Camunda installation requires a database schema update.

  • Check for for your database that are within the bounds of your update path.Locate the scripts at $DISTRIBUTIONPATH/sql/upgrade in the pre-packaged distribution (where $DISTRIBUTION_PATH is 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 $DATABASENAME_engine_7.5_patch?.sql.

  • Execute the corresponding update scripts named

    • $DATABASENAME_engine_7.5_to_7.6.sql
      The scripts update 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 update 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., 7.6.X where X > 0. The procedure is the same as in step 1, only for the new minor version.

Full Distribution

The following steps are required:

  • Update 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 update. This guide assumes you have unpacked the distribution to a path named $DISTRIBUTION_PATH.

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 update is not required when migrating from 7.5 to 7.6.

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 any of the following:

  • camunda-engine-spring
  • camunda-engine-cdi
  • camunda-ejb-client
  • …
    There are no new mandatory dependencies for process applications.

Standalone Web Application

If the standalone web application is in use, the current artifact must be replaced by its new version.

  • Undeploy the current version of the standalone web application
  • Update the database to the new schema as described in the databaseupdate section
  • Reconfigure the database as described in the 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:

Application with Embedded Process Engine

This section is applicable if you have a custom application with an embedded process engine.

Update 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:

  • camunda-engine
  • camunda-bpmn-model
  • camunda-engine-spring
  • …
    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 update.

Custom Mapping of the Decision Result

With Camunda 7.6, the type of the decision result has changed from DmnDecisionTableResult to . If the decision result of a business rule task or a decision task is processed by an ExecutionListener or a CaseExecutionListener (i.e., ), 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.