Camunda Team Blog

camunda BPM 7.1.0-alpha4 released - BPMN coverage, Performance & Cockpit

Written by Daniel Meyer on , under Execution category.
Today we released camunda BPM 7.1.0-alpha4. This release provides many improvements and bug fixes:
  • Process Engine:
    • BPMN coverage: 
      • Support for Non-Interrupting Event Subprocess - (CAM-112) - HOT
    • Performance Improvements:
    • Message Correlation Improvements: 
      • Added Fluent Builder & Correlation using Process Instance Id (CAM-1775)
  • camunda Cockpit (Webapplication for Monitoring & Operations):
  • Bpmn Model API:
    • Support for all camunda Extension elements & Attributes (CAM-1854)

All in all, 45 Issues were closed. Find the complete release notes in Jira.

Download camunda BPM 7.1.0-alpha4 now! Give us Feedback in the forums and via Twitter: @camundaBPM.

New camunda Cockpit Features

First, we tried to fix the caching problems many of our users experienced, see:

Let us know if you experience any problems when you upgrade camunda BPM this time. 

Second, we added some new features:

The Possibility to Filter / Search the Activity Instance Tree:



Enterprise Edition only: The Variable History Log


Enterprise Edition only: The User Task History Log


Enterprise Edition only: Visualize number of cancelled Activity Instances on Diagram:


And finally, we added the possibility to write plugins for the camunda Admin application. The camunda Admin application now features a "System" section which can be enhanced using plugins:

Finally arrived: the Non Interrupting Event Subprocess: 

We finally added support for the non interrupting event Subprocess. Actually most of the code was already added with alpha3 but we had to do some additional testing and minor fixes for Multi Instance cases before we could release it officially.

The non-interrupting event subprocess allows to react to an event (like a message, a signal or a timer) without interrupting the main flow of the process:

In the example above, if a new guest introduces himself, the main flow will not be interrupted. Executing such processes was not possible before.

For those of you interested in the implementation details: we added a new base operation (Atomic Operation) to the process engine which allows to start an activity concurrently. The same code is now also used for non interrupting boundary events which, on an abstract level, behave very similarly with one key difference: for correctly supporting event subprocesses we had to implement execution tree expansion which re-expands a compacted execution tree into a concurrency tree:

   Compacted Subtree          Expanded Subtree
   =================          ================

        ...                        ...
         |                          |
      +------+                  +-------+   Scope=tt
      |  e   |       =>         |   e   |   ConCurrent=ff
      +------+                  +-------+
          s=tt                      ^
         cc=ff                     / \
                                  /   \
                                 /     \          Both:
                          +-------+   +--------+    s=ff
                          | CCE-1 |   | PPE    |   cc=tt
                          +-------+   +--------+


Find more information in the BPMN Reference and the BPMN Implementation Reference.

Performance Improvements

We did some performance improvements in two areas:

  • Reducing the number of unnecessary selects,
  • Execution Tree Pre-fetching

In the following process we reduced the number of selects necessary for triggering the boundary event from 33 down to 8:

The testcase is part of our performance testsuite. The results can be verified using the "Sql Statement Log".

Log for alpha 3 vs. Log for alpha4
alpha4 NEW
alpha3 OLD


Performance Benchmarks show an improvement in performance of roughly 30% if the database runs on a different machine then the process engine.

Execution tree pre-fetching will fetch all the executions inside the same process instance upon the first access of an execution from the hierarchy which is not equal to the initially fetched execution. The executions will be fetched as list and we then reconstruct the complete execution tree. 

In many cases this is an optimization over fetching the execution tree lazily. Usually we need all executions anyway and it is preferable to fetch more data in a single query (maybe even too much data) then to run multiple queries, each returning a fraction of the data. 

The most important consideration here is network roundtrip: If the process engine and database run on separate hosts, network roundtrip has to be added to each query. Economizing on the number of queries economizes on network roundtrip. The tradeoff here is network roundtrip vs. throughput: multiple roundtrips carrying small chucks of data vs. a single roundtrip carrying more data.

What else is gioing on?

Matrin Schimak has released camunda BPM assert 1.0!!!!!!!!! 

Join us at our community event here in Berlin on March 18th! The Beer (and Bionade) has already arrived and is well guarded by Nastasja, our community manager!