DMN is more than Decision Tables

Hi,

The addition of DMN decision tables to the modeller is a great thing and the usability is really great! Thanks a lot for that.
But there’s more to DMN than “just” decision tables: Business Knowledge, Input Data, Decisions, Knowledge Source. Is there a chance that these will be included in the modeller within the next months ? So we’d be able not to only model the rules but also their surrounding eco-system and interdependency. Especially Knowledge Source would be interesting - be it only to reference regulatory documents or paragraphs. Also chaining of Decisions / Business Knowledge would be a great asset e.g. to calculate discounts.
Or did I miss something ?

Regards,
Michael

Hi Michael,

we plan to support more DMN for the next release 7.6. Currently, we focus on requirements between decisions (i.e. a decision required another decision - both are decision tables). We want to implement it in the DMN engine as well as for the Camunda modeler. Beside that we may support input data and knowledge sources in the modeler if the people want to use it for documentation.

Currently, we don’t plan to support Business Knowledge Models since we are not sure how people want to use it. Do you have use cases where you need them? If yes please describe the use cases.

Best regards,
Philipp

That’s good news, thank you for responding so fast.

Yes, input data and especially knowledge sources would help us in documenting rules to connect them to regulatory documents/paragraphs. Otherwise we’d have to set-up a separate meta-data structure for these. Also the possibility to add additional meta-data to Decisions would help (e.g. owner, version, …)

If we’d go by the book regarding Business Knowledge, I’d refer to a quote:
Decisions and Business Knowledge are equivalent in their ability to contain detailed decision logic, but encapsulating it in Business Knowledge allows it to be reused by different Decisions. Also note that the only purpose of Business Knowledge is to represent decision logic, while a Decision has additional properties such as the decision owner and decision maker. Therefore, Decisions have a documentation purpose as well.” (Kimon Batoulis, open.hpi.de)

But if you plan to make DT’s refer other DT’s in version 7.6, although it might not be 100% compliant to the above definition, it surely would be practical enough. The use case I had in mind was the re-usability of rules and hierarchical chaining of decisions (e.g. to have various rules to calculate discounts - based on various conditions which can not be merged into one rule - and aggregate them in a “central” rule which is called from the code).
Kind regards,
Michael

Hi Philipp,

one feature we currently desire in development is to support decisions with a higher complexity that should not be modelled with a table. We have simple scripts like e.g. JavaScript in mind that might be corresponding to a Business Knowledge element in DMN (if I got the spec right). At the moment we are planning to create a service beside the Cammunda DMN engine to realize this. This has the downside of course that you cannot build up a network of decisions like possible with a DMN diagram.

An alternative could be a Business Knowledge element that can call a web service since we could cover a lot with that, incuding the situation of executing a script.

It would be interesting to learn what you think about this.

Regards
Jochen

Hi Jochen,

I’m not at Camunda but in my opinion the approach where a component in DMN calls a webservice is not the right one. DMN should receive all data it needs to execute rules and come to a result - it must not become active by itself and collect data. This would be a flawed design in my opinion.
But chaining decisions is certainly the most important missing feature. It would be cool to model them in DRD’s (Decision Requirement Diagrams).

Cheers,
Michael

Hi Michael,

the specifications allows that a decision has multiple required decision. You can also find this in their XML example. So it should be possible to have a hierarchical chaining of decisions without business knowledge models. If you have an example where you definite need business knowledge models, please describe it in detail and we can discuss it.

@Jochen, currently we focus on decision tables because they are easy to use and can cover a lot of problems. So in the first iteration, we will not support any other decision logic than decision tables.

BTW, I agree with @neuweiler and you should collect the data before evaluating the decisions (e.g. using a BPMN processs -> decision flow).

Best regards,
Philipp

4 Likes

@neuweiler, I’m actually with you. I had in mind that the service is only depending on the input fields passed to it from the DMN context. the service would just be an expression of pure business logic.The upside would be flexibility in what Business Knowledge might represent from a product point of view. I however also fear this requires a lot of discipline to keep the purity of the service, which is definitelly a downside.
The proposal about web services is actually nothing we desire at the moment - was merely an idea that came up, thinking about possible use cases for the product as requested by Philipp.

@Philipp_Ossler, sure! We will provide this out-of-band in this case. In the first place I wanted to share our use case of having business logic where expression as a table would be a rather improper choice, of course hoping it might be entering the roadmap ;). But, learning this is not going to be the case in the first iteration is also valuable for us, thus we can keeping the focus on our current approach. Thanks!

@Philipp_Ossler, there’s no real need to use Business Knowledge in our cases. We only have the need to chain and re-use decision logic. If that’s possible with Decisions only, we’re fine. I just participated in a BPM/DMN training of open.hpi.de and they followed a very strict interpretation where re-used decision logic must be moved into Business Knowledge. But if the specs allow both, you probably don’t need to follow a puristic approach. It’s gotta work in the end but of course it’s a good idea to also stick to the standard - what you guys appear to do pretty well from what I can tell.

@Jochen, sorry, didn’t want to misinterpret you. To achieve what you want to do, might it be possible to use JUEL or even JS in a pre-/post-processor of the rule engine? Have a look at https://docs.camunda.org/manual/latest/user-guide/dmn-engine/embed/ - I’m pretty sure there’s room for a little workaround until it’s implemented in the product. (I might be wrong though as I’m pretty new to camunda).

@neuweiler I’m not offended at all - you just made clear, concerning the suggestion about the web service, that I missed some detail that I consider important as well. I would also say that its better to take care the the data flow is visualized in the DMN diagram. The idea about the web service just came to me because I though it might be a solution from a produc perspective to cover a lot of needs (by basically delegating the responsibility to provide a solution in terms of a web service to the consumers). but I guess this is prone to be abused to introduce “hidden” inputs not visualized by the DMN diagram.

About your suggerstion concerning JUEL: I’m not a user of JUEL. I did have a quick research but didn’t find much. Yet, I gut an impression that the language is limited to simple expressions without a control structure. If that’s true, that would make the decisive difference:
We basically have a few cases where its more efficient for both to write a short script instead of defining a table (for the majority of cases tables are fine). Apart from table size if there is an strong interdependency between the output values it might also impact the effort of maintaining the definitions where the alternative to compute output by a script in a plain and simple way might exist. It is however most probable that in those cases the script language needs to provide control structures in order to be useful in this context.

Update: I wrote a blog post about how to use more DMN in Camunda: https://blog.camunda.com/post/2018/11/dmn-scala-extension/

2 Likes