Please note that Patch Level Updates are only provided to enterprise customers, they are not available in the community edition.

Check the for more information or get your free trial version.

Reading this Guide

In this guide, a number of variables are used to denote common path names and constants:

  • $DATABASE: the target database platform, e.g., DB2, MySql etc.
  • $DISTRIBUTION_PATH: the path of the downloaded pre-packaged Camunda BPM distribution, e.g., camunda-bpm-tomcat-$PLATFORM_VERSION.zip or camunda-bpm-tomcat-$PLATFORM_VERSION.tar.gz for Tomcat etc.
  • $PLATFORM_VERSION: the version of the Camunda BPM platform you want to install, e.g., 7.1.0.

Database Patches

Between patch levels, the structure of the database schema is not changed. The database structure of all patch releases is backwards compatible to the corresponding minor version. Example: the database schema of all 7.3.x versions is backwards compatible to the 7.3.0 schema.

The one exception to this are bugs in the database schema itself. If you are affected by such a bug, you have the option to run a patch script.Patch scripts are shipped inside the distribution at the following location: $DISTRIBUTIONPATH/sql/upgrade, named: engine$VERSIONpatch$Ato$B.If you do choose to apply a database patch, then you must apply all patch scripts that are within the bounds of your update path. This means if your current patch version is and you update to X.X.5 you have to execute all patch scripts first where $AX.X.1 and $BX.X.5.

Each patch script contains a comment what the fixes are related to and a link to the corresponding issue.

The following list is an overview of all currently available patch scripts:

Special Considerations

This section describes noteworthy changes between individual patch levels.

Reason: Passing EL expressions in a task query enables execution of arbitrary code when the query is evaluated.

The process engine no longer evaluates these expressions by default and throws an exception instead. The pevious behavior can be re-enabled by setting the process configuration enableExpressionsInAdhocQueries to true.

See the user guide on security considerations for custom code for details.

You can now configure, if you forbid the usage of Java serialization format, when passing object variables in their Java serialized representation.

The new defaults to true, but can be configured to false in Camunda engine configuration.

Following use cases are affected:

  • REST API:

{
"value" : "ab",
"type" : "Object",
"valueInfo" : {
"objectTypeName": "com.example.MyObject",
"serializationDataFormat": "application/x-java-serialized-object"
}
}

  • Java API:

You can disable Java serialization usage with the help of this configuration parameter:

Groovy version

In the historic process definition diagram it is possible to select time periods for which activity instance badges are displayed.

By default the displayed timer period is set to ‘today’ but can be extended to show badges of ‘this week’, ‘this month’ or the ‘complete’ history.

This feature can be configured in two ways:

  • The default timer period can be changed to ‘this week’, ‘this month’ or ‘complete’

History cleanup can be parallelized

As of v. 7.8.7, history cleanup can be parallelized, which leads to creation of several jobs in the database. For this reason:

  • call to HistoryService#cleanupHistoryAsync does not guarantee to return correct Job object in return and you should not rely on the returned value any more.The same valid for REST call POST /history/cleanup
  • HistoryService#findHistoryCleanupJob is deprecated (as well as GET /history/cleanup/job), one should use HistoryService#findHistoryCleanupJobs instead.

    Full Distribution

This section is applicable if you installed the with a shared process engine. In this case you need to update the libraries and applications installed inside the application server.

Please note that the following procedure may differ for cluster scenarios. Contact our support team if you need further assistance.

  • Shut down the server
  • Exchange Camunda BPM libraries, tools and webapps (EAR, RAR, Subsystem (JBoss), Shared Libs) - essentially, follow the for your server.
  • Restart the server

    Application With Embedded Process Engine

In case you use an embedded process engine inside your Java Application, you need to

  • update the Process Engine librarayin your dependency management (Apache MAven, Gradle …),
  • re-package the application,
  • deploy the new version of the application.

    Standalone Webapplication Distribution

In case you installed the Standalone Webapplication Distribution you need to

  • undeploy the previous version of the webapplication,
  • deploy the new version of the webapplication.

    Applying Multiple Patches at Once