Camunda is an enterprise platform for workflow and decision automation.

Since I had time, and wanted to learn about Camunda, I implemented a pilot project with this versatile tool.

See https://camunda.com/.

Installation

To get started, I installed first the Modeler, which is a desktop application. This goes without problems (Windows, Linux).

Then the installation of the server, i.e. the Community Platform is more difficult since it needs Tomcat. I did not want to install Tomcat and its dependencies on my Windows system, so I went for the complete Docker installation which encapsulates everything on Linux. Using Docker is not so easy on Windows for me.

The downside of using Docker is that the camunda platform came with some example processes, which are nice to learn from, but are in the way when progressing.

Get started

Next, I followed the “Getting started” on the website, which teached me how to draw a BPMN process, a DMN decision table, and incorporate that with pieces of Java code crafted in Eclipse with Maven.

The Camunda documentation is good, but it seems to totally lack an explanation of the possibilities of the UI of the Modeler. For instance, what does it mean to fill in the field Form Key as shown in this screenshot? Experimenting showed me that when you leave this field empty, you get a generated internal form, and when it is filled in, an externally created form is expected at a given link.

Pilot process

After the Getting Started, it dawned on me that I do not know how to draw BPMN so that it is executable. So, I started implementing an example process.

This process can be executed completely!

Starting via REST

Starting a new process instance via the REST interface with SoapUI. This works very good, the possibilities of SoapUI are endless, and the user interface is not too hard to get started.

Starting via Form

Starting a new process instance via the auto-generated form in the Camunda web-application.

Service Tasks

All service tasks in my process are executed in Java. I did not really implement the sending of notifications here, but only the Java function that receives the process data and completes the task afterwards.

Decision

The decision task is controlled by a DMN diagram and table. The decision table creates a few new process variables, which are used further in the process in the Inclusive Gateway: there are 1 to 3 different reviewer groups in this process, depending on its type variable.

Manual Task

The manual tasks are executed by users from a given group. There are 5 different groups in this process, and I created one test user in every group. The authorisations are set correctly in the Camunda Admin app, so that they only see what is needed to execute their tasks (and not more).

Variables

Every step in the process, variables are added, e.g. to store the text of a sent mail. In the Camunda Cockpit app you can see all the variables, and the state of the process, i.e. what (or who) is the process waiting for.

Conclusion

In these last days, I learned a lot about Camunda, but also about the other used tools and technologies. What I have seen, I like a lot.

Still, I have some questions that require further experimenting:

• What would it take to put this as a solution in production? And then I do not mean the technical stuff like servers and deployment, but more: how much fine-tuning would the application need before we can tell the potential users to start using it?
• There is also the possibility to define process steps in CMMN - is this as useful as BPMN and DMN?
• How do we improve the usability of the UI to implement e.g. progressive disclosure and dependend fields?