What are you looking for?

Camunda BPM 7.12.0-alpha5 Released

  • Blog
  • >
  • Camunda BPM 7.12.0-alpha5 Released

Camunda BPM 7.12.0-alpha5 is here and the highlights are:

  • Comments on Process Instance Modification
  • Query for Process Definitions without Version Tag
  • Contextual Process Data in Logging
  • Improved Task Event Lifecycle
  • Change the CSRF Prevention Cookie Name
  • Support for WildFly 17 & 18
  • Discontinued Support for Legacy Environments
  • 19 Bug Fixes

You can Download Camunda for free (click on Preview Release) or Run it with Docker.

If you are interested, you can see the complete release notes.

If you want to dig in deeper, you can find the source code on GitHub.

Comments on Process Instance Modification

With the Camunda 7.11.0 release, we introduced the user operation log, which provides information about the manual changes made to your processes.

It is now possible to provide a comment directly when making process instance modifications. The comment will be added to the user operation log, providing information when the operations are audited at a later point. This option is available when modifying the process from cockpit, as well as in the REST– and Java API.

Process Instance Modification

Query for Process Definitions without Version Tag

Version tags are a great means of adding semantic version names to your process definitions.
But up until now, it was not possible to specifically and directly query for those process definitions that did not have a version tag attached.
Those process definitions can now be looked up by using the withoutVersionTag option in the process definition queries.

Using the Java API, definitions without version tag can be found by writing

List<ProcessDefinition> pdList = processEngine.getRepositoryService().createProcessDefinitionQuery()
    .withoutVersionTag()
    .list();

The REST API offers similar functionality as described in the Camunda documentation for Get Definitions and Get Definitions Count methods.

Contextual Process Data in Logging

Logs are a valuable source of information when it comes to analyzing the behavior of applications.
However, the information provided in log statements regarding the process execution context often is quite limited.

In order to provide details on the current execution context in log statements,
we now set process execution-specific data in the Mapped Diagnostic Context (MDC).

The process data is held in the MDC for the time of process execution and removed from it after the execution context is successfully left.
In case of arising exceptions upon execution, the data is kept in the MDC until the calling context,
i.e., the JobExecutor or the surrounding command, finishes its logging.

The keys at which the properties are accessible in the MDC can be defined in the
process engine configuration.

In order to access the MDC data, you need to adjust the logging pattern of your logging configuration.
An example using Logback could look as follows.

<configuration>
  ...

  <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
      <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} context:[%X] - %msg%n</pattern>
    </encoder>
  </appender>

  ...
</configuration>

By adding the context:[%X] to your configuration, all values that are present in the MDC at the time the log statement is created will be displayed.
Please refer to the manual of your logging framework for further information on how to access the MDC, e.g., the Logback documentation.

Improved Task Event Lifecycle

The Task Lifecycle in the
Process Engine has been well defined. However, there was a lack of definition in what order, and
under what conditions, are Task Events fired. This impacted the assumptions under which Task
Listeners were executed.

This alpha release improves upon the Task **Event(()) Lifecycle by defining a proper order of
firing of Task Events and adding an additional update event. It is now ensured that:

  1. On Task creation, the Task create event is fired first.
    1. If an initial assignee has been set, an assignment event is fired after the create event.
  2. When a Task property, or task-related entity (Attachment, Comment, local Task variable), is
    changed on an existing Task, an update event is fired.

    1. If the updated property is the assignee, an assignment event is also fired after the
      update event is fired.
  3. When a Task is completed, a complete event is fired, and this will be the last event, unless
    the Task is canceled through the execution complete Task Listener.
  4. If the Task is canceled, by a BPMN Error thrown inside a Task Listener, Process Instance
    deletion, or an interrupting Boundary Event/Event Subprocess, a delete event is fired, and this
    will be the last event in the lifecycle.

You can find additional details about the order and conditions of Task Event triggering in the
Camunda Task Event Lifecycle documentation.

Change the CSRF Prevention Cookie Name

When running within the same domain namespace third-party Webapps besides the Camunda BPM ones, the
CSRF Prevention mechanisms of the different Webapps may interfere with each other because they use the
same cookie name.

Starting with this release, the name of the CSRF Prevention cookie is configurable. The default name
is XSRF-TOKEN. To change the cookie name, you need to define the name on both the client- and
server-side.

You can read how to change the cookie name client-side
and server-side
in the documentation.

Support for WildFly 17 & 18

WildFly 17 and 18 are now part of the supported environments.

Discontinued Support for Legacy Environments

The following environments are no longer supported in Camunda 7.12:

  • Java 7
  • JBoss Application Server 7
  • JBoss EAP 6.1 / 6.2 / 6.3
  • WildFly Application Server 8.2
  • Oracle 10
  • PostgreSQL 9.1 / 9.3
  • DB2 9.7 / 10.1
  • Microsoft SQL Server 2008

We have carefully selected these environments based on usage statistics and end of life dates by the respective vendors. Discontinuing support for legacy environments enables us to support new technologies and to provide a secure product. For example, many frameworks and libraries that Camunda integrates with no longer work with Java 7 in their most recent versions. Dropping Java 7 on our end allows us to stay up to date.

What’s Next?

This is the last alpha version before the next minor release of Camunda 7.12.0 on November 29, 2019. Our development team is already preparing everything
for a great release packed with new features and a lot of bug-fixes. Stay tuned!

Your Feedback Matters!

With every release, we constantly strive to improve Camunda BPM. To make this possible, we are reliant on your feedback. Feel free to share your ideas and suggestions with us.

You can contact us by writing a post in the forum.

Try All Features of Camunda

Related Content

Transition from simple deployments to a fully integrated production setup smoothly.
Improve customer satisfaction while transitioning to an entirely different energy system? Not a problem with Camunda's Self-Managed migrations.
How to avoid pitfalls and make the most of FEEL for a citizen developer.