We are excited to announce that Camunda BPM Platform 7.12.0 is now available.
The release includes many new capabilities. Here are some of the highlights:
You can download Camunda 7.12.0 for free or run it with Docker.
Also included in the release:
- Spring Boot Starter 3.4.0, which relies on Spring Boot 2.2.1 by default
- Assert 5.0.0 for convenient testing of processes in Java
- Node.js External Task Client 1.3.0 for JavaScript developers
- Java External Task Client 1.3.0, which can be embedded in Java applications
You can read all about these releases in the dedicated blog post.
For a complete list of the changes, please check out the release notes
and the list of known issues.
And for patched security vulnerabilities, see our security notices.
If you want to dig deeper, you can find the source code on GitHub.
Enhanced BPMN Execution
Camunda BPM 7.12.0 includes significant improvements around BPMN process execution.
You can model all the features mentioned below with the version 3.5.0 of Camunda Modeler.
Trigger BPMN Errors and Escalations from User Tasks
In some cases, a human task worker cannot complete an assigned task – for instance, because an unforeseen error
occurs, or a decision needs to be escalated.
Starting in 7.12, it’s possible to trigger BPMN Error and Escalation events from user tasks via the Java or REST APIs.
The sample process shown below has an Error event, as well as an Escalation Boundary event, attached to the user task “Review annual report”:
The following example shows how to trigger a BPMN Error via REST API:
POST /task/482g036/bpmnError
{
"errorCode": "invalid-data-error",
"errorMessage": "The data provided for the report is invalid.",
"variables": {
"reportId" : {
"value" : "PLR-233",
"type": "String"
}
}
}
The REST API request triggers an Error for the user task 482g036
with the code invalid-data-error
,
a message and passes a variable reportId
.
You can read more here:
- Trigger BPMN Errors and Escalations from User Tasks
- REST API for Errors & Escalations
- BPMN Event Form Buttons & Example
- Form Lifecycle & Events
Time-triggered Listeners for User Tasks
For a manual task, it is sometimes necessary to automatically trigger certain actions after
a specific amount of time (e.g. for escalation, reassignment, email notifications, etc.).
Starting in 7.12, the Workflow Engine can execute Time-triggered Listeners for user
tasks in your processes.
For example, the following process contains a Time-triggered Listener for the user task “Pick Items”:
The Time-triggered Listener will call the task Listener Class com.example.ReassignListener
after one hour.
You can configure the Listener in Camunda Modeler as follows:
You can read more here:
Update Listeners for User Tasks
Properties of a manual task may change over time. To react accordingly to changes, it may
make sense to trigger specific actions automatically. For instance, to notify an assigned
task worker when a due date is set or updated.
This release features Update Listeners for user tasks.
The following process contains an Update Listener for the user task “Check invoice”:
The Update Listener calls the Task Listener class com.example.NotifyAssigneeListener
as soon as the task is updated.
You can configure the Listener in Camunda Modeler as follows:
You can read more here:
Additional BPMN Execution Features
Improved Operations
This release introduces powerful features to improve operations such as annotating
operation logs with comments or contextual logging for processes.
Annotate Operation Logs with Comments
Operation logs are helpful for auditing manual operations. However, the logged technical
information might be not enough to understand the specific reason that an operator
performed a specific operation.
Camunda BPM 7.12.0 makes it possible to annotate logs with a comment to put the operation in the
correct business context and make later auditing easier.
In Cockpit and Admin, it’s possible to annotate the logs of an already performed
operation with a comment:
Additionally, when modifying a process instance, you can directly add a comment:
You can read more here:
Contextual Logging for Processes
When it comes to debugging, it’s key to link logs of the workflow engine to the context
in which the respective process execution took place. For instance, when an exception
occurs in a Java delegate, it can be very helpful to trace it back to the affected
process instance.
This release leverages the Mapped Diagnostic Context (MDC) technique
of SLF4J to link logs to the respective process execution context. To make use of this new feature,
you need to add the context placeholder %X
to the logging pattern.
Here’s what the configuration will look like when using the Logback implementation:
<configuration>
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>
%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} {%X} - %msg%n
</pattern>
</encoder>
</appender>
...
</configuration>
The configuration shown above produces the following log output:
08:12:05.212 [camundaTaskExecutor-3] WARN org.camunda.bpm.engine.jobexecutor {activityId=bill-customer, processDefinitionId=billing-process:1:216698df, processInstanceId=298e7511} - ENGINE-14006 Exception while executing job 33c54b1a:
java.lang.RuntimeException: Invocation of billing service failed!
at com[...]BillingService.lambda$performBilling$0(BillingService.java:29)
at org.camunda[...]JavaDelegateInvocation.invoke(JavaDelegateInvocation.java:40)
...
With the help of the log output, we can easily see that the exception occurred while
executing the instance 298e7511
from the process definition billing-process:1:216698df
inside the activity bill-customer
.
You can read more here:
- Process Data Context
- Configure the Logging Context Parameters
- Mapped Diagnostic Context (MDC) by SLF4J
Additional Operations Features
Stronger Security
We continuously strive to improve the security of Camunda BPM.
Protection against Malicious Variable Values
The Workflow Engine allows the exchange of structured process data from untrusted
sources in the form of JSON and XML.
The deserialization of JSON and XML data from untrusted sources is prone to
exploitation. When the provided data is malicious, arbitrary code can be executed
inside the Java Virtual Machine (JVM).
Camunda BPM 7.12.0 includes an all-new security mechanism to prevent the Workflow
Engine from deserializing malicious JSON and XML data.
By default, common Java types like list or map structures are whitelisted. When a
malicious JSON or XML variable value with a non-whitelisted Java type is stored,
the Workflow Engine rejects the variable value from being deserialized. You can
extend the whitelist with your custom Java types.
You can read more here:
Additional Security Features
Additional Supported Environments
Camunda BPM 7.12.0 introduces support for new environments:
- Support for Java 13
- Ready-to-use Docker Images that are based on OpenJDK 11 (LTS)
- Support for WildFly Application Server 17 and 18
You can read more here:
Retired Environments
Camunda BPM 7.12.0 discontinues support for older versions of legacy application servers and database systems.
Additionally, Java 7 is no longer supported.
Dropping support of legacy environments enables us to support new technologies and provide a secure product.
For more details, please read about the Changes in Supported Environments.
And Much More
There are many smaller features and bug fixes in the release that are not 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 spot at the free release webinars, which are offered in German and English.
Your Feedback Matters!
With every release, we strive to improve Camunda BPM. This is only possible with your feedback! Feel free to share your ideas and suggestions with us.
You can contact us via the Camunda user forum.