Camunda Platform 7.18 Released – What’s New

By
  • Blog
  • >
  • Camunda Platform 7.18 Released – What’s New
TOPICS

30 Day Free Trial

Bring together legacy systems, RPA bots, microservices and more with Camunda

Sign Up for Camunda Content

Get the latest on Camunda features, events, top trends, and more.

TRENDING CONTENT

We’re extremely excited to announce the release of Camunda Platform 7.18

Here are some of the highlights:

You can download Camunda Platform or run it with Docker.

For a complete list of the changes, please check out the release notes. For patched security vulnerabilities, see our security notices.

If you want to dig deeper, check out the source code on GitHub.

Cockpit: Improved instance selection to avoid unintended batch operations

Previously, when performing a batch operation, Cockpit had a unified user interface to either select specific instance ids or define a query consisting of none, one, or more criteria that are evaluated to instance ids on creating a batch operation.

The old user interface had the downside in that one could unintentionally apply a batch operation by the selection type query. This would end up affecting a huge amount of instances and lead to a situation that is difficult to roll back.

With this release, we improve the user interface by introducing a new configuration option called Choose selection type. You can either opt for Instance, which is also the default, or Query.

When you choose the selection type Instance, you can select each instance one by one while you need to select at least one instance before proceeding to the confirmation step. When you choose Query, Cockpit shows a warning explaining that the batch operation would affect all instances matching the filter and that this might be potentially dangerous and must be reviewed carefully.

We applied this new pattern to all views in Cockpit, where you can create multi-instance batch operations: Migration Page, Modification Modal, Restart Modal, and on the Batch Operation Page.

batch operation instance selection

Cockpit: Easier navigation of high batch operation volumes

In a production environment with many deployed processes and even more running process instances, your operators may run many batch operations to intervene. Keeping an overview of who started what can be challenging.

In 7.18 we are making it easier for operators to track the batch operations they started by redesigning the batch operations page. We add the following new features that make it easier to navigate through the batch jobs and to find the ones you are looking for:

  • The In Progress batches table displays the user name and start time attributes
  • In the batch details, both in progress and historic batches have a new property called executionStartTime. It shows the time when the execution of the first job in the batch has started.
  • The In Progress batches table has new search options where you can filter by user and start date. You can also show/hide batches with or without failures easily.
  • The details view for ended batches, you can find a new button for removal. Use it to clean up your batch history and keep the amount of data manageable.

navigation of high batch operation volumes

MDC logging features

As an addition to the already present list of parameters for the logging context, 7.18.0 adds the following new parameters: 

  • loggingContextActivityName
  • loggingContextProcessDefinitionKey
  • loggingContextEngineName

Including the process engine name in the log output is particularly helpful in a multi-engine setup. This way it is clear from the log entry from which engine it originates. Additionally, you can now also include the activity name and the current process definition key. These new context parameters will make analyzing log files even easier.

You can find more information about how to configure the logging output format to contain process data as well as an overview of the available parameters in our documentation.

Camunda Forms in Tasklist: Populate select options via process data

Starting with this release, you can bind the available options of select components to a variable.

With this, Camunda Forms shows available options dynamically based on process data (variables).

The feature is available for these components: Select, Radio Buttons, Checklist, and Taglist.

Perform the following REST API request to start a process instance with two variables that populate select options of a Camunda Form:

`POST /process-definition/key/my-process/start`
 
```json
{
  "variables": {
    "my-checklist-options": {
      "value": "[\"check1\", \"check2\", \"check3\"]",
      "type": "Json"
    },
    "my-taglist-options": {
      "value": "[\"tag1\", \"tag2\", \"tag3\"]",
      "type": "Object",
      "valueInfo": {
        "objectTypeName": "java.util.ArrayList",
        "serializationDataFormat": "application/json"
      }
    }
  }
}
```

Based on these variables, Tasklist renders the following Camunda Form with its respective select options:

form select components

Read more about this feature in the User Guide or in the documentation about Camunda Modeler

Exception error codes

Sometimes, an error occurs when you call the Camunda 7 Java or REST API.

Reading the error message might help a human being to understand the root cause of the problem. However, evaluating error messages in an automated way is not a good idea since:

  • The message might change with newer versions.
  • Relying on fragments of the message can be error-prone.

This is why we introduced static exception codes your business logic can rely on to determine specific problems and react accordingly. Look up our built-in error codes in our glossary. We may add new codes for more error classes in the future.

You can also define your custom error codes by registering a custom code provider or assigning them to your exceptions thrown from the delegation code.

Read more about this feature in the User Guide and learn how to access error codes via Java, REST, Open API and the JavaScript or Java External Task Client.

Filter and order tasks by last updated

The task query API lets users find and filter tasks by many different query criteria. With the upcoming release, we will add one more to the Java and REST task query API: filter by last updated.

For example:

taskService.createTaskQuery()     
  .updatedAfter(myDate)     
  .orderByTaskUpdatedAfter()     
  .asc()     
  .list();

This call will return all tasks which were last updated after (excluding) the specified date (myDate) and sorted by when they were last updated in ascending order. This comes in handy when your application holds a list of tasks and you need to keep them up to date. Now you can restrict the results to only those tasks that changed after the previous request.

When are tasks updated?

Users can change the state of a task in many ways. Direct changes to the properties of a task, like setting a new assignee or adding a description, are obvious. But other entities that are tied to the task can also change. Adding an attachment to a task will not change the task entity itself; instead, it will link the new attachment object to the existing task. This is also considered to be a change to the task entity. Other examples could be adding a comment to a user task or creating/updating a local task variable.

All these operations will fire an update event within the task event lifecycle. Users can already write task listeners that perform operations every time a special event occurs. The new query API property is based on the same event. Find more information on the task event lifecycle in the documentation.

WebSphere Liberty

This feature is only available in the Enterprise Edition of the Camunda Platform Runtime. Test it out with a Free Trial.

This minor release extends the list of supported application servers with WebSphere Liberty, an application server focused on modularity, developer friendly, and designed for microservices. As of Camunda Platform 7.18, IBM WebSphere Liberty 22 is supported for a shared engine setup. Visit the Manual Installation guide for further information on how to configure the application server for Camunda Platform 7.

New supported environments

  • PostgreSQL 14
  • Amazon Aurora PostgreSQL compatible with PostgreSQL 11 (also supported as of 7.17.6+)
  • H2 2.1
  • IBM WebSphere Liberty 22

Retired supported environments

  • IBM DB2 11.1
  • PostgreSQL 10
  • Amazon Aurora PostgreSQL compatible with PostgreSQL 10
  • Microsoft SQL Server 2014
  • WildFly Application Server 13
  • JBoss EAP 7.0 / 7.1
  • Oracle WebLogic Server 12c (12R2)

Watch the release webinar

The Camunda Product Management Team and Camunda Tech Experts are happy to introduce you to the new features of Camunda Platform 7.

Join us for this live webinar, as we’ll talk about the new features in Modeler, Automation Platform, and Optimize. We’ll also leave some time for a Q&A session to answer all your questions.

Join the Camunda Platform 7.18 Release Webinar

Your Feedback Matters!

With every release, we strive to improve Camunda Platform 7, and we rely on your feedback to do so. Feel free to share your ideas and suggestions with us. You can contact us on our Camunda Community Forum.

Try All Features of Camunda

Related Content

We're streamlining Camunda product APIs, working towards a single REST API for many components, simplifying the learning curve and making installation easier.
Learn about our approach to migration from Camunda 7 to Camunda 8, and how we can help you achieve it as quickly and effectively as possible.
We've been working hard to reduce the job activation latency in Zeebe. Read on to take a peek under the hood at how we went about it and then verified success.