DMN : When to use vs DB

BPMN & Modeling Discussion & Questions
1

Hi all,

How viable would DMN be for the following project requirements?

A. # of Input Columns > 30

B. # of Rules per table, can be > 1000

C. Some Rules = Reusable Object

i.e. create rule in one dmn file, and reference it in another file.

Am thinking the following would be required to do this in DMN

  1. Create Rule via Modeller
  2. Map, store and index UID for reuse (presumably store into some DB)
  3. Fetch rule (via DB then DMN engine)
  4. Insert into another DMN in user-defined order
  5. Save and re-deploy

D. Search for Rule

  • by UID
  • by Annotation
  • Input Column Value or Range of

E. Externalise DMN Decision Service

  • If externalising Camunda 8’s DMN engine, would this use another Zeebe cluster?
  • How much remote interaction is possible with C8’s DMN engine via Zeebe’s gRPC API?

================
Thanks for your time.

2

Hi @dred,
I am happy to take a closer look on your use-case!

Generally speaking, DMN can be used for a variety of different use-cases. In the end is usually simplifies the BPMN diagram a lot.
To answer you questions I wonder how stable the rules are you want to capture. If they change frequently and are driven by business users this would be a perfect scenario for a DMN table or even a decision requirements diagram featuring multiple of these :slight_smile: .

I am not sure whether I completely understand why you want to use it together with a relational database though. Maybe you can elaborate a bit more on that topic.

P.s.: No need to externalise Camunda 8’s DMN engine…

3

To answer the question about Zeebe gRPC endpoints for the DMN engine.
According to the documentation I do not find any way to trigger a standalone decision.
You would always need to embed it in a process model.

4

Hi @Hafflgav, thanks for looking at this closer.

DMN to simplify BPMN flows and allow more responsive changes looks great, yet need to see what the constraints to its usage are too.

Taking our reusability requirement

I gather that reusability in the DMN world can mean:

  1. reusing the DMN file (and its entire DRD contents) or
  2. reusing values, variables or functions (within a given DRD only)

The challenge is how to reference a rule defined in one DMN file, in another… I don’t think this is possible in Camunda or other vendors out-of-the-box…

If so, perhaps we can solve by extracting data from the DMN file (UID, annotations, even values) and storing in CSV or JSON for example. Then in a modified GUI, reference any given rule, copying in values on demand before saving the new DMN file.

This would not interfere with rule execution per se (as it’s still DMN), but allow for even more responsive business rule management …

5

Yes, when it comes to reusability you can either

  • Reuse a DMN table, literal expression (which is part of a bigger DRD)
  • Reuse the complete DRD

You cannot reuse a single rule which is part on one DMN table in another.
At this point I would ask why you want to achieve something like this. If you want to have the same type of rule in two separate tables, these can be merged into one.

Having done so, you can always reference to another DMN table based on the output in the larger DRD. Just to align on wether we are talking about the same thing I have added a screenshot below.
image

Now let’s quickly check out the plan you have mentioned:
Generally speaking, DMN is serialised in XML. Before deploying a DMN table to the engine you could run a script extracting data from the file and modifying the DMN tables as needed.

Example of the XML representation:

 <rule id="DecisionRule_08nz8pq">
        <description/>
        <inputEntry id="UnaryTests_0adgp9c">
          <text/>
        </inputEntry>
        <inputEntry id="UnaryTests_1jzpweh">
          <text>"Salaried"</text>
        </inputEntry>
        <inputEntry id="UnaryTests_17itih0">
          <text>"Premium Package"</text>
        </inputEntry>
        <inputEntry id="UnaryTests_0dgmj4d">
          <text>&lt;90</text>
        </inputEntry>
        <outputEntry id="LiteralExpression_1xwbye7">
          <text>"Too Low Income"</text>
        </outputEntry>
        <outputEntry id="LiteralExpression_1s5g29d">
          <text>"yellow"</text>
        </outputEntry>
      </rule>

Though I am not sure whether this workaround is worth it :smiley:
Let me know if you want to chat about this topic.

Best,
Thomas

6

Primarily want to achieve:

  1. multiple tenants
  2. each can share 1+ rules with other tenants, at their discretion only
  3. if shared, take the reference of the rule and insert into the other tenant’s table / formula or DRD (ideally refresh values if the master reference changes)

Had considered the proposed DRD structure when there is a default / fallback / final decision to take, but this would still not solve 2. & 3 unfortunately (the need for a rule created by a particular tenant to be inserted into another’s table or DRD safely, with appropriate viewing and editing restrictions).

In theory could achieve with a modified GUI, parsing the XML and a single DRD. This would not easily solve the next requirement.

Secondly key :

If above ETL capability was there the files would still be stored as DMN hence executable by the engine and there’d also be a mirror reference data source.

It’d allow performant searches per se if stored in an appropriate DB like Mongo or Redis. Do doubt how performant traversing dmn folders and parsing the xml documents within would be for this second purpose (e.g. “find all rules with input or output values in range of XYZ” across XX tenants and YY services, loading each dmn into memory each time).

That is … unless the rules loaded into the DMN Engine were exposed via an API with similar performance to db queries.

====

These are two must have requirements. Was quite keen on DMN, but unfortunately can only have it for these use-cases if it can be supplemented in this or a similar way

7