Camunda BPM platform 7.9.0 is now available, and the highlights are:
- Clients for External Tasks
- History Cleanup Performance Improvements
- Transient Variables
- New Features in Camunda Cockpit
- 119 Bug Fixes
In addition, WildFly 11, JBoss EAP 7.1, Tomcat 9, and the database Maria DB 10.2 are now officially supported.
You can Download Camunda for free or Run it with Docker.
We have also released the Camunda Spring Boot Starter 3.0.0, which relies on Spring Boot 2.0.0 by default.
To see a full list of the changes, please check out our Release Notes
and the list of Known Issues.
If you want to dig in deeper, you can find the source code on GitHub.
Clients for External Tasks
If your organization uses a microservices architecture, you can (and probably do) use Camunda BPM Platform as an orchestration engine. External tasks are an excellent
choice for this use case. Camunda now provides clients for external tasks, which can be embedded in other applications and significantly simplify dealing with external tasks
in the Camunda BPM Platform.
We provide two external task clients:
- Node.js external task client for non-Java developers
- Java external task client – can be embedded in Java applications
You can find the Get Started Guide here.
Significant History Cleanup Performance Improvements
Up to this point, the history cleanup was implemented in a way such that it could only be run in one thread. This guaranteed that the history cleanup process
won’t overload the application server and the database and does not have significant impact on the process engine performance.
However, in some cases, that history cleanup is configured to be run only at night when the application is not used, thus process engine performance is not a concern.
In such cases, you can now parallelize the history cleanup process by defining degree of parallelism, which specifies the possible number of threads
simultaneously performing the cleanup.
Below, you can see the comparison of history cleanup performance running in one vs. three threads.
(The test was performed on the engine running on a standard PC and using Oracle 12 as a database)
In order to enable the feature, you should define the historyCleanupDegreeOfParallelism configuration parameter. For more information, please see
the docs.
Transient Variables
Various data accompanying the process flow are usually stored as process variables. But it is often the case that there is some raw input data
(such as a huge XML or JSON file), which must be preprocessed before being used in the process. Before version 7.9, you had to choose to either preprocess it “outside”
the process and then pass the extracted granular process variables to the engine or to implement a “data processing” step inside the process. The latter forced you
to pass the entire raw dataset as a process variable. This means that it would be stored in the database, and even if you later removed the variable, it would still
remain in history tables.
This problem can now be solved with the help of transient variables. You can pass the transient variable to the process and be sure that it
will never be persisted in the database. However, it will be accessible as a normal variable until the next database transaction commit.
Visualizing such a process:
You can start it with this REST call:
POST /message
{
"messageName" : "supportRequest",
"processVariables" : {
"requestData" : {
"value" : "[huge JSON content here]",
"type": "String"
"valueInfo": {
"transient": true
}
}
}
}
or via Java API:
runtimeService.createMessageCorrelation("supportRequest")
//true in the second parameter indicates transient variable
.setVariable("requestData", Variables.stringValue("huge JSON content here", true))
.correlate();Message correlation will start the new process instance, then the service task “Extract client data” will be executed, where the passed variable can be used to extract
client id and another data. After that, the database transaction will be committed (as the process has reached the waiting state), saving client id and other data in dedicated variables,
but requestData will cease to exist.
More information on usage of transient variables can be found in the docs.
More BPMN Features
Another super useful feature that Camunda now provides are conditional start events and sending a payload when throwing a signal.
Docker Container for Camunda BPM Platform Enterprise
A Docker Container for Camunda BPM Platform Enterprise Edition is now available. Read more in the docs here.
New Features in Camunda Cockpit
Sortable Columns
This release brings another improvement to facilitate dealing with large amounts of data: most tables in Cockpit and Admin can now be sorted based on various criteria.
In addition, sorting order is persisted so that a user does not need to sort again every time they open a certain view.
User Operation Log
The user operation log both in process definition and in process instance view now shows the user who executed a specific operation.
And Much More
There are many smaller features and bugfixes in the release that aren’t included in this blog post. The full release notes provide the details.
Register for the Webinar
If you’re not already registered, be sure to secure a last-minute spot at the free release webinars, available in German and English.
Your Feedback Matters!
With every release, we strive to improve Camunda BPM. To make this possible, we rely on your feedback. Feel free to share your ideas and suggestions with us.
You can contact us by writing a post in the forum.
Furthermore, if you have any feedback related to User Experience, things that keep annoying you, things that you think should work differently, and so on, please share your thoughts with us at https://camundabpm.userecho.com
