Search this Blog

Search this Blog


Follow our Blog by Email

Friday, November 28, 2014

Camunda BPM 7.2.0 Final Released

Today we announce the official release of Camunda BPM 7.2.0 Final. This version constitutes the latest production-ready release of Camunda BPM platform and will be supported with patch updates in the the Camunda Enterprise Subscription.

Camunda BPM is open source, you can download the distribution from and inspect the sources on GitHub.

Highlights of 7.2.0 Final

This blogpost provides a summary of the highlights of the 7.2.0 Release. The complete release notes can be found in JIRA.

New Tasklist

This version ships a completely redesigned Tasklist.

The Tasklist is a single page Java Script application which is developed as part of the camunda BPM community Endition (Open Source). If you are interested in the source code of Camunda Tasklist, you can find it on Github.

The tasklist layout is divided into three columns: a configurable list of filters, a list of tasks and the task details. Each column can be collapsed: for instance, once you have selected a filter, you can collapse the left column and focus on the list of tasks or an individual task. The task view itself can be maximized which gives more room for complex forms.

Task Filters represent Task Queries (which some of you may know from using the Java API or the REST Api of the process engine) which are saved to the database such that they can be executed repeatedly. Filters can be configured directly inside the tasklist:

The above image shows the "General" settings of  a filter. A filter can be assigned a name, a description as well as a color and a priority (which determines the ordering in the list of filters). The "Auto refresh" setting is interesting: if it is enabled, the filter is periodically refreshed such that users of the tasklist notice if a task is added or removed by another user or the process enigne.

It is also possible to define the criteria of the filter (which represent the actual task query):

Filters (and the task query itself, for that matter) now also support expressions which make the filters more flexible and usable by multiple users. Check the userguide for a list of useful expression language additions for filters.

We put in place a sophisticated authorization system for filters: first, you can configure which users and groups are authorized to create new filters. Users who are authorized to create filters can then share these filters with either all other users (globally) or with defined users and groups. This way users can determine which filters other users can see inside the tasklist and by extension, which kinds of tasks these other users should work on.

Finally, it is also possible to configure a list of variables which should be fetched and displayed in the list of tasks:

The result is that these variables are fetched for all tasks matched by the filter:

Besides the variables, the "task cards" in the list of tasks provide the following information:

The name of the task, the name of the process or case definition, Created Date, Due Date and Follow Up Date, the name of the assignee, the task priority and the variables configured in the filter. Since this information is fetched for all tasks in the list, we implemented a new, powerful, mediatype in the REST Api (application/json+hal). This is now available to all users of the API and allows then to fetch this complex information in a singe Rest request which is assembled by the REST Api using a constant number of database queries. In addition, resources like users and groups are cached to minimize the number of LDAP requests necessary for fetching user information.

When working on a task, users are presented a form:

The tasklist supports different kinds of forms, the screenshot above shows an HTML based "embedded form". The source code of this form can be found on GitHub. 

Support for such forms is provided through the new Camunda Javascript SDK. The SDK is developed as a separate project allowing users to use embedded forms in their own applications. The sourcecode of the SDK can also be found on Github.

Besides the form, users can inspect the history of a task:

The history is sourced from the "User Operation Log" we introduced in camunda BPM 7.1. Finally, the diagram view shows the BPMN 2.0 Diagram, highlighting the current user task in the process:

The diagram is rendered with our new Javascript Toolkit for BPMN 2.0:

We are really excited to provide this new release of Camunda Tasklist to the community. A lot of customer feedback has been distilled into this and I am looking forward to seeing how it is used.

Note that the tasklist can also be localized, a community project with localizations has already been started:

Case Management with CMMN

With 7.2.0, we introduce support for a completely new definition language called Case Management Model and Notation (CMMN).
CMMN is an emerging OMG standard for (Adaptive) Case Management. Version 1.0 is freshly released and vendor adoption starts to take off.

CMMN allows modeling Cases. A case allows humans to do work in a more or less structured way in order to achieve something. Classic examples where case management is applied are Credit Application, Customer Support Management, Document Management, and so on.

The following is a simple Example of a Credit Application Case modeled in CMMN:

The Picture above shows the graphical representation of the CMMN Model. The model also has an executable XML representation which looks like this:

With 7.2 we introduce coverage for the following CMMN contructs:

  • Stage
  • Human Task, Process Task, Case Task
  • Sentries
  • Milestones

The implementation is provided through the process engine Java API as well as the REST Api.

Process Engine Improvements for High Load Scenarios

The camunda process engine has been improved to work better in high load scenarios. First, we have done a complete rewrite of the persistence session / first level cache (formerly known as DbSqlSession). The new implementation has the following advantages:

  • Reduction of dead locks due to consistent flush ordering. Before, the ordering of the database flush (INSERTS, UPDATES, DELETES) at the end of the transaction could lead to deadlocks, the new implementation enforces that any two transactions working on the same pair of entities will flush modifications in the same order.
  • 1st level cache reuse: the first level cache will always be consistent with the database at the end of a transaction which allows us to reuse it in subsequent transactions. The cache can currently be reused in sequences of asynchronous continuations executed by the Job Executor. At the end of a transaction we flush the deltas and then reuse the cache in the next transaction, instead of throwing the memory state away and re-fetching everything from the database. This makes asynchronous continuations a lot more light-weight.
  • In the future:
    •  it may be easier to support alternative databases such as Mongo DB. We already experimented with Hazelcase (in-memory data grid) as persistence provider and it worked out.
    • we will be able to remove the limitation induced by the fact that atomic operations are executed recursively: the stack size grows limiting the number of activity instance which can be executed in a single transaction. We could now remove this in the next release if users should need this.
Next, the scalability of the Job Executor (responsible for asynchronous processing) has been improved in 7.2. Before only 1-2 nodes could consume effectively from the queue, now users can now have larger clusters.

Custom history levels: it is now possible to implement a custom history level which allows users to determine in a very fine granular way what data should be logged. This is useful for users with extreme amounts of process instances and who need to control the number of history events produced.

Performance and  scalability are continuous efforts for us. We improve them with each release because we always have customers who push the limits. I am already looking forward to the improvements we will have to do in the next release :)

Xml, Json and other Dataformats

The 7.2 release introduces support for Xml and Json Dataformats at different levels. Fist, the process enigne can now serialize Java Objects using Xml or Json out of the box.
The serialization dataformat can be configured using the new, typed variable API:

CustomerData customerData = new CustomerData();

execution.setVariable("customerData", objectValue(customerData)

We also introduce the Spin Dataformat API which provides support for parsing, writing, querying and mapping Xml and Json data. The Spin Dataformat API can be used in Expression Language as well, allowing users to directly execute XPath or JsonPath when configuring sequence flow conditions:

${XML(customer).xPath("/customer/address/postcode").element().textContent() == "1234"}

The Spin Dataformat API allows users to extend it with custom functionality or implement their own dataformats. Source code for the Spin Dataformat API is avaliable on Github.

Improved Scripting & Templating

Users can now use script languages, namely Javascipt, Groovy, JRuby and Jython. For these languages, support has been improved in the following way:
  • Compilation: the process enigne can be configured to compile (and cache the compiled scripts) these languages. This improves performance.
  • Scripts can now be used everywhere where expression language or custom Java code can be used, including Execution Listeners, Task Listeners, Sequence Flow conditions.
On top of this, we provide script engine wrappers for template engines (namely Freemarker, Apache Valocity and XSLT) which can be used everywhere where scripts are used. Template engines are useful for composing data and payload such as XML and JSON or formatting text such as Emails.

Out of the box REST and SOAP Connectors

Camunda 7.2 introduces a new API for connectors: the Camunda Connect API. Out of the box, the 7.2 Release provides support for a REST and SOAP connectors.

What makes connectors different from plain  Java delegate implementations (which you already know)?
  1. The most important difference is that connectors declare their input / output parameters. This will make it possible for us to build tooling which allows users to configure the input / output parameters of arbitrary connectors. Connector I/O is configured using variable I/O mapping (also new :) )
  2. Connectors provide a simple Interceptor API which allows users to customize connectors. This way they can implement cross cutting concerns such as logging, authentication, encryption etc.
  3. Connectors provide a more Request / Response oriented API. We may also support asynchronous connectors in the future.
Note: camunda Modeler does not yet support configuring such connector, the next release of the modeler will provide this support.

Wildfly Application Server

Wildfy application server is now officially supported in Camunda BPM 7.2. :)

Upgrading to 7.2.0 Final

We have prepared a migration guide which explains how an existing installation or application can be upgraded to Camunda 7.2.0 Final.

Enterprise Support

The 7.2 release is the basis for the next supported production release for camunda BPM. It is fully supported in the Camunda BPM enterprise subscription. Support includes Help Requests based on different SLAs as well as access to camunda BPM maintenance releases. Maintenance releases allow customers to get bugfixes for production systems based on the 7.2 codebase. While the community project will forge ahead for 7.3, we will backport bugfixes to the 7.2 branch and perform maintenance releases reserved for enterprise subscription customers.

There is a Migration Guide targeting existing Camunda BPM 7.1 installations.

Join the Release Webinars

Join us for our (free) English and German Release Webinars!


Finally I want to thank the community for the awesome contributions we keep getting, both in the form of bug fixes and improvements to the main code base as well as community extension projects.

What's Next?

  • We will release camunda Cycle 3.1 providing support for Git connector (among others) and better extensibility.
  • The documentation will be improved, including chapters on Multi Tenancy
  • And after that: Camunda BPM 7.3 :)

Tuesday, November 25, 2014

Who cares about Types? Querying with Numeric Variable Values

The final camunda 7.2 release is a stone's throw away and ships a ton of new features. One of these is the typed variable value API. You may already know the plain-value-based API that exists since the process engine's very first days. A variable can be set on an execution/task/... as follows:
execution.setVariable("var", 42);
Behind the scenes, the process engine performs some magic to squeeze numbers, booleans, or even complex Java objects into the database and return it from there on the next call:
int myLuckyNumber = (Integer) execution.getVariable("var");

With 7.2 (and the latest alpha), we introduce the typed value API. It is not a whole new API but rather of a gentle extension. Like before, the variable API is map-based and no existing code breaks. With the typed value API, performing the same task as above, it is possible to write
execution.setVariable("var", Variables.integerValue(42));
TypedValue typedValue = execution.getValueTyped("var");
You might have noticed the TypedValue which is the very core of this concept. Instead of the plain variable value, there is an intermediate object, the typed value.

What can you do with it? Assume there is a variable called "var" in four different process instances:
runtimeService.setVariable(processInstance1.getId(), "var", 42000);
runtimeService.setVariable(processInstance2.getId(), "var", (short) 42);
runtimeService.setVariable(processInstance3.getId(), "var", (long) 123123123);
runtimeService.setVariable(processInstance4.getId(), "var", 745.0d);
The four variables all differ in type and exact value. Yet, all are numeric values. In order to find all process instances with variable value > 10, the following can be written:
  .variableValueGreaterThan("var", 10).list();
Unfortunately, this returns only one process instance, processInstance1. Why? Because 42 is an integer value and the query only searches for process instances with an integer value greater than 10.

Often, this is not what users want. All values are numeric and can be compared on a conceptual level. That is where typed values come to the rescue. Now, it is possible to write the following process instance query:
  .variableValueGreaterThan("var", Variables.numberValue(10)).list();
This query returns all four process instances. The process engine detects that the types integer, short, long, and double are all subordinates of the type number. It now knows that you do not mean integers with value greater than 10 but any number value that is greater than 10.

Why should you care? Sometimes you don't know the type a variable in question has. In Cockpit, users specify a numeric value to query with. Its exact type is of little interest. While some MyBatis and SQL hacks made this possible in Cockpit before 7.2, it is now a well-defined API feature. And the best: You can use it in your own queries, wherever variable values can be specified.

That is not all to it; the typed value API has much more to offer. To learn more about it, stay tuned for the release webinar, blog posts, tutorials, and examples to follow. Of course, you can right now have a look at the documentation and discover the typed value API.

Friday, November 14, 2014

camunda BPM platform 7.2.0-alpha6 released

6 weeks after the last release we release camunda BPM 7.2.0-alpha6. The release ships

  • Tasklist
    • Flexible layout with collapsible / expandable areas
    • Enhanced Forms Support
      • Embedded Forms
        • Check Box, Select box, Date Picker
        • Advanced Scripting
        • Working with JSON-Serialized Java Objects
        • Save partially filled in form to local Storage
        • AngularJS interoperability
      • Generated Forms
      • External Forms
    • List of Tasks
      • Search by process / task / case variable
      • Navigate through list using Keyboard
    • Process Diagram is displayed (with
    • Display the value of Process / Case Variables in the list of tasks
    • Support for CMMN Human Tasks
    • Bugfixes
  • Process Engine / REST API
    • CMMN-Based Case Management
      • History for Case Instances and Case Activity Instances
      • Sentries
      • Variable Listeners
      • Transformer Extensions
    • New Typed Variable API (CAM-2903)
      • Work with both Serialized and De-serialized representation of Object Values
      • Specify Serialization Data Format for Objects (e.g. JSON, XML...)
      • Support Typed Null Values (e.g. 'Integer' with value null)
      • Better variable support in REST Api
    • Improved Support for Inclusive Gateway (OR Gateway)
    • Custom History Levels (fine grained control over the amount of Data Logged, CAM-2724)
    • Job Executor Improvements
      • First Level Cache reuse (performance boost) (CAM-2763)
      • Better Scalability and Work Distribution in clusters (CAM-2805)
    • Improved performance of Expression Language execution (CAM-2725 contribution by Jörn Horstmann, Zalado)
    • Improved HAL Support in REST Api (CAM-2940CAM-2798
    • Upgraded Mybatis dependency to 3.2.8 (Contribution by Frank Langelage)
  • Improved integration of camunda SPIN for working with XML and JSON data
    • Spin is now an optional Process Engine Plugin
    • Default provider for JAX-B or Jackson based Object Serialization
  • Improved integration of camunda Connect providing HTTP and SOAP connectors
  • Greatly improved distribution for IBM Websphere Application Server
    • Resource Adapter embedded into EAR
    • Better support for Shared Libraries
    • IBM Deployment Descriptors provide default values for deployment metadata
All in all, 217 Jira Issues were closed. See the complete Release Notes in JIRA.

alpha6 is the last alpha release before the 7.2.0 final release which is due end of this month (November). It can be considered to be the "release candidate". Almost all features planned for the 7.2.0 relase are in alpha6 and we do not expect any more major API or Database changes. (No guarantees, however :) )

Friday, November 7, 2014

Job Suspension - Powerful Operations with Camunda BPM

This blogpost is about a very powerful feature in camunda BPM for operating critical processes which are in production. Given a core process which operates under high volume, almost any problem is critical in a way. The more options you have to deal with those problem the better. I am going to show you one of those options, namely job suspension.

Tuesday, September 30, 2014

Introducing Task Filters

With Camunda BPM 7.2.0-alpha5, we introduce Task Filters. Task filters are TaskQueries which can be saved to the database so that you can run them repeatedly.

Camunda BPM 7.2.0-alpha5 released

Camunda BPM 7.2.0-alpha5 has been released. This alpha release contains

All in all, 120 issues were closed. See complete Release Notes in Jira.

Download Camunda BPM 7.2.0-alpha5 now!

Note that this may be the last alpha version before the 7.2.0-Final release which is due November 30st.

Announcing the Release Date of camunda BPM 7.2.0 GA

The next release date of camunda BPM has been finalized:

7.2.0 GA* will ship on November 30, 2014

From that date on camunda BPM 7.2 will be be supported as enterprise edition as well. 
(*General Availability)

Here are the highlights of this release:
Of course there is lots of other great stuff in this release, built by the team and our contributors

You want to know more? We will announce the release webinar dates soon on this blog.  

A note on the release date 

So far we have been communicating end of October as our release date. Due to very interesting feedback from our enterprise customers and during our community day we decided to improve the product even further based on that feedback. That's why we need to take another month.

Looking forward to a really awesome release!