Search this Blog

Search this Blog


Follow our Blog by Email

Thursday, December 18, 2014

Cycle 3.1 Released

We are happy to announce the release of Cycle version 3.1. Cycle is a tool which makes synchronization of BPMN diagrams between the camunda modeler and third party modeling tools possible. With this release we provide a feature which allows bpmn tool vendors to integrate their tool with camunda cycle by providing custom Connectors. The complete release notes can be found in JIRA

You can download the distribution of Cycle 3.1 from and view the source code on GitHub.


Cycle uses Connectors which implement the necessary operations to synchronize BPMN diagrams. With Cycle 3.1, we provide a way to augment Cycle with custom Connectors. Tool vendors can implement needed operations and publish a Connector which integrates their tool with camunda Cycle. This allows users of the third party tool to seamlessly work with the third party tool, integrate the changes into camunda BPM and merge changes back. We provide a repository where we list all available custom Connectors. The IBO Software GmbH already contributed a Connector for their Prometheus tool.

Tool vendors can find an example how to implement a Connector to integrate their tool with camunda Cycle in our examples repository.

In addition to the possibility to augment Cycle with custom Connectors, we also added build-in GIT support for camunda Cycle.

Diagram Rendering

Cycle displays an image of the current state of the BPMN diagram. Previously, the tool was responsible to provide this image alongside the BPMN file and keep the image file up to date. With this release we add the option to let Cycle render the bpmn diagram by using the BPMN file instead of using a provided image. This improves the integration of tools which do not provide an image themselves.

To render the diagrams, we use the awesome toolkit.

Upgrading to Cycle 3.1

If you want to use the new version of Cycle, we provide you with the necessary upgrade scripts. Please see our installation guide for information how to upgrade to camunda Cycle 3.1.

Wednesday, December 17, 2014

Getting Started: CMMN and Camunda

With Camunda BPM 7.2, we have released our very first implementation of the Case Management Model and Notation (CMMN) standard. Some people even say it is the first available CMMN implementation at all. Like BPMN, CMMN is a specification by the Object Management Group and while BPMN is a standard for modeling processes that are highly structured, CMMN is a standard for modeling cases. In contrast to processes, cases are user- and data-driven and typically are much less pre-defined in terms of execution order and required tasks.

With 7.2, it is now possible to deploy CMMN models to the engine, and interact with case instances via a rich Java and REST API. For human tasks, camunda Tasklist can be used just like it can be used for BPMN user tasks. To walk you through the development of your first CMMN application, we have compiled a getting started guide. It guides you through the following:
  • Creating a CMMN model
  • Deploying the model to Camunda BPM
  • Using camunda Tasklist to work on human tasks
  • Specifying and implementing new CMMN constructs like sentries and milestones
So now:

Thursday, December 11, 2014 releases 0.6.0 - Palette and Sub-Process Modeling

The guys are making AWESOME progress. Version 0.6.0 of the BPMN Javascript toolkit has been released today. With this release support for modeling has been greatly enhanced.

Read up on the details in Nico's Blogpost.

Friday, December 5, 2014

Camunda Modeler 2.6.1 release

It's been a while since our last eclipse Modeler release. We are happy to announce the new Camunda Modeler release 2.6.1.


Eclipse Modeler
Standalone Modeler
Indigo and Juno:

What's inside?

This release ensures compatibility of the Modeler with the latest attributes introduced in Camunda BPM 7.2.

Roman has done a great job updating the meta model of the Modeler so that BPMN 2.0 XMLs which contain i/o-mapping and script attributes can now be opened.

Additionally, we are happy that two pull requests from our great community are included in this release.

What's next?

Currently we are working on the 2.7.0 version of our Modeler, which will expose the attributes we have added with 2.6.1 on the properties panel, namely i/o mapping, scripts and asyncBefore/asyncAfter. 

Thursday, December 4, 2014

Internationalization in the Camunda BPM Tasklist

In an international open source project like ours, the users speak a huge variety of languages. When building our new Tasklist we had to adress the question of how to deal with internationalization.

Customizing Your Own Language

In addition to the default language, we added the possibility to plugin your own language for all Tasklist texts, labels, dates and date formats. You can of course use multiple languages at a time, based on the browser settings of your users. To achieve this, you simply need to add your own language file(s) to your Tasklist, without even restarting the application.

Monday, December 1, 2014

Cockpit and Deployments

The last days before I traveled to Hong Kong I built a cockpit plugin to show and delete deployments.

On my first engagement, I thought about how to clean up my database from all the failing process diagrams that I don't need any more. I asked Bernd how to get rid of the old stuff. He deleted the H2 files from his computer. That's a very fresh start. And he is now very fast in finding and installing the enterprise license key again. This could be done better in my opinion. 

On the next customer engagement I saw a test system with version 168 of the process definition to test. Someone should clean up here. But how?

What about deleting the deployment with cascade=true? Who calls the Java-API and when? An engine plugin seems too complicated for this and somehow you have to get the IDs of the deployments to delete.


In  a camunda training I saw the REST-API. Together with the fancy rest-clients, it should be easy to call  repositoryService.deleteDeployment(). But it wasn't implemented as a REST service. There wasn't even a REST  deployment service. The team built it for 7.2. But they missed the delete method. Was it a security issue? If someone is able to call deleteDeployment with cascade=true, he will delete all current process instances and even the history, too. 

But Robert told me, that there weren't any security concerns, it was just not so important for the team. So I looked at the rest-implementation how to delete process instances and made a contribution to delete deployments. 

Cockpit Plugin Archetype

In the advanced training Falko introduced the plugin archetype and with this very easy approach I quickly wrote a cockpit plugin that deletes deployments on the server side, without a graphical user interface. I installed it on my favorite Jboss 7.1.5 Enterprise version to get rid of the old deployments. I deleted them with the ID from the database and called the cockpit plugin rest service with a rest client. 
DELETE http://localhost:8080/camunda/api/cockpit/plugin/delete-deployment/default/pluginDeployment/88771df2-753d-11e4-9987-52ff20524153?cascade=true
Next task for me was a community event about cockpit plugins. I dug deeper into the structure of the files generated by the maven archetype and prepared a plugin to display the number of flow node instances of the last 30 days. You can find it on the plugin-store. For this presentation I had to find more examples of JavaScript programming, especially the date stuff. The articles of these magazine gave me an overview and introduction into the concepts of JavaScript. I had forgotten them completely during the last 13 years of java enterprise programming.

The JavaScript stuff of this plugin was straight forward. Just one file plugin.js, well prepared to get it running easily. Browsing the JavaScript code of the camunda webapp, I found that the developers divided the files into controllers and resources.

Now I created a deployment-plugin from the archetype, chose 7.2.0-alpha5 as camunda version and started to write some code.

To handle deployments in the cockpit, you should have a search for deployment by time range in the dashboard. you don't want to fill your page with 168 Versions, if you are too lazy to clean up. 

Angular JS-Stuff

To decide, which deployments can be deleted without harming the system, you need the number of running process instances for the process definitions of the deployment together with deployment times. Ok, that's a three-stage folding of three different resources. Deployment - Process Definitions - Process Instances. A deep dive into angular coding, but it went quite well. I extracted some services, and used a date-picker for selection criteria. Coffeehouses in Vienna are a good place to do this. Cafe Ritter with free Wi-Fi access or Cafe Bräunerhof where you have to be better prepared as they don't offer Wi-Fi access. Wiener Melange helps you, too.
Deployment Plugin
Screenshot of deployment plugin

Now I'm nearly finished. We decided to put it in the plugin store. The one missing piece is the refresh after coming back from the confirmation popup. To implement it in a brute force way I have to copy about 30 lines of JavaScript into a new function. Seems that I can improve my JavaScript code. To get to this point, it was sufficient to read the chapter about calling rest resources in the angular book. Now I will start reading the angular book from the beginning. 

And for 7.2 production environments, secure your rest api with the filters in your production environment.

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 :)