While I was watching today a video of Jakob Freund talking about „Camunda in the cloud„, I understood better the simple process modelled by my colleagues and me a couple of days ago. In this speech at the BPMCon 2016 he was talking about clients, who used Camunda, not being interested in the zero code case as much as the other advantages of BPM. Most of them see the ability to distribute work easily, handling events, asynchronous processing and the visibility of the process in the case of „Workflow“ as the most important advantages.

From my developer point of view, he is completely right. On one hand, BPM helps us to talk to our customers. On the other hand, it helps us in development a lot when we have to route tasks or data to other people or systems. The visualization helps developers to understand the application behavior, simplifies the operation of an application, helps even to structure code during development and much more. Especially, through the digitalization we will get much more scenarios in which applications will talk to each other or processes which are started by events from mobile phones or things. BPM and, therefore, Camunda can be one approach to prepare for future by anticipating changes and adapting quickly and flexibly to changes on process side.

In our process we took advantage of event handling, which is offered by BPMN 2.0 but in the simplest way.


What I mean is, we modelled just one Start- and two End-Events. The process can be started with only two pieces of information, namely the message to be post on slack and the name of the author writing this message. We didn“™t provide any API to call and start this process in Camunda. We just used the Camunda REST API for that. The URL would be:


Also using a JSON body:

    "name": {"value" : "Muster Human", "type": "String"},
    "text": {"value" : "this is a test message", "type": "String"}

DMN Table

One of my favorite automations in this process is the DMN Table. We decided to create a black list with forbidden words, which are not allowed to get published on slack channels. So we would fill our table with rules checking for forbidden words in the message.


As you can see we use Juel as the expression language for defining the rules. This is just our preference as Java developers. You could use FEEL or any other language supported by the Camunda engine.

We check for null or empty string in the first rule of the table. This can also be done in other ways. You could do this check before the table is invoked. We decided to put this as a rule on the table for more visibility and demonstration purposes. There is one disadvantage with that though. The Camunda engine would evaluate every rule in a DMN Table, regardless of the output of any rule and the hit policy of the table. That means you have to make every rule null safe in order to avoid exceptions. To see an example, just check out the rules in the above table.


Approve message

At the beginning of this blog entry we said asynchronous processing is a big advantage of BMPN 2.0. We use a user task for a human check of every message to be post on slack. While we can argue if it“™s meaningful or not, this is a demo and it achieves its purpose as an example of asynchronous processing that should be done by a human. Also an advantage: you can easily assign different tasks to different people and distributing work as you want.

Send Rejection

As there are quite a few sorts of tasks available in BMPN 2.0 we tried to be as specific as possible when modelling. In this case, if a message contains forbidden words or it is not approved by the approver, the message is rejected and the token passes through the „Send rejection“ Task. We could leave this task as a normal service task but we chose to model it as a „Send task“ to be more accurate. At the moment this tasks only logs out the denial of posting the message. But it could as well notify somebody or write some auditing data.

Push message to slack

Now it“™s time for the second most interesting tasks in this case. The first one was the DMN Table. I am talking about the „Push message to slack“ task. Functionally it should do a REST call with two parameters: name and text. So you probably are asking yourself, where is the interesting part?

Well, we didn“™t use any Java code here to make the REST call. Instead we used the Http Connector provided by the Camunda engine. Using the http connector is much more elegant and easier than doing a REST call in Java. Nevertheless, testing is extremely time consuming, especially, when using the framework Wiremock. It is not that easy to get it running, which is why we used SoapUI in the end. So, be aware, if you use a Http Connector component, testing might be challenging.


If you could take only three important topics from this blog entry, according to us those would be:

  1. In many cases you don“™t need an extra (REST) API. Just use the API of the Camunda engine to minimize the workload. The security issue must be considered here.
  2. DMN Table is easy to use for automatically checking rules and perfectly integrated in the Camunda engine. Just keep in mind EVERY rule will be evaluated.
  3. Http Connectors are really handy to configure in the model. Furthermore is this e great feature for fans of „zero code“ solutions. Testing this scenario is much more difficult though than making and testing the http call in Java.
Alle Beiträge von Erzen Hyko

Schreibe einen Kommentar