We’re extremely excited to announce the release of Camunda Platform 7.18
Here are some of the highlights:
- Cockpit: Improved instance selection to avoid unintended batch operations
- Cockpit: Easier navigation of high batch operation volumes
- MDC logging features
- Camunda Forms in Tasklist: Populate select options via process data
- Exception error codes
- Filter and order tasks by last updated
- WebSphere Liberty
- New and retired supported environments
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.
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.
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:
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:
"value": "[\"check1\", \"check2\", \"check3\"]",
"value": "[\"tag1\", \"tag2\", \"tag3\"]",
Based on these variables, Tasklist renders the following Camunda Form with its respective select options:
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.
Filter and order tasks by last updated
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.
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.
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.