On Novenber 30th, 2015 the team around Camunda BPM will release version 7.4 of its open source Business Process Management Platform which will include lots of improvements and new features. In this post I want to introduce two new features: DMN support and escalation events in BPMN-processes. Both can be tested already with the current Alpha2 – release.

DMN

DMN – Decision Model And Notation – is an OMG-standard for modeling business rules which was released in September 2015. Similar to BPMN 2.0 this standard defines both graphical representation and execution semantics. A decision model is decribed on two levels: Decision Requirements and Decision Logic. On the requirements level decisions are shown in relation to their influencers – Input data, Knowledge sources and Business knowledge. On the logic level Business knowlege is described in further detail for example using decision tables.
In version 7.4 Camunda BPM introduces a DMN-engine capable of evaluating decision tables according to DMN-standard. Based on bpmn.io there is a web-modeler for decision tables which can be evaluated here.

decision_table
example decision table used in Camunda’s modeler demo

In the example decison table shown above each row describes a rule, each input-column shows a condition in the current rule (AND-join). Normally rules should not overlap: One set of input values triggers exactly one rule. In the case of overlapping rules rule evaluation is guided by a Hit-Policy. Depending on the chosen policy only the first rule matching the input values might be triggered or all rules might bet triggered; in this case each rules‘ results are an entry in a result list. These are just two examples, there are more policies defined in DMN. According to the release notes hit policies are supported by Camunda’s DMN-engine but as of now the demo-modeler does not  allow to specify a policy in a decision table.

To use a decision table in a BPMN-process the dmn-file just needs to be added as a resource to a process application. Rule evaluation can then be triggered either by a Java-API-call or by referencing the decision in a BPMN rule task. This configuration is not supported by Camunda’s Eclipse-based modeler yet  so we need to do this in the XML representation of our business process. Before executing the rule task the input-parameters must be set as process variables. After the rules are evaluated the output is added in a process variable holding a map of parametes which are accessible through EL-expressions.

To unit-test the decision table together with a business process just add the dmn-file as another deployment-resource to each process test.

Escalation Events

Escalations are a means of letting a subprocess notify a parent process like in this example where our customer should receive an email to inform her that we need some more time if we dont have the ordered article in stock but need to contact our supplier.

order_process
example order process

Here the escalation event is used trigger our customers‘ notification – modeled as a non-interrupting boundary event to our subprocess. This is more a deviation from the regular process flow than an error which we used to model the case that we cannot deliver at all.

Configuring an escalation in BPMN is similar to configuring a message: First we need to define an escalation for the whole model which we then reference in our escalation events. Again we need to do this in the XML editor.

Alle Beiträge von Christoph Ortmann

Schreibe einen Kommentar