Check for not matching test conditions

DMN Engine
1

Check for not matching test conditions

We have the case that we have two different kind of conditions in our decision table, naming the decision condition and the test condition:

  • decision condition … the matching row should be found by this conditions
  • test condition … this conditions should apply for the decision to be 'ok', otherwise it is 'not ok'. When the decision is 'not ok' the user wants to see the not matching test conditions.

I will first show you an example to make this requirements more clear. Afterwards I'll write down the questions we have and last but not least I will show you how we tried to approach this.

Example

Please do not take this example for granted, I just tried to sketch a somewhat understandable scenario.

A user is fulfilling a registration process. The password input is checked for multiple test conditions to apply in order to be a secure password. If the test conditions do not apply the user should see the failing test condition-columns to adapt the password.

regelproblemtest
regelproblemtest783×142 3.98 KB

The test condition-columns are an amount of the different character types to exist in the given password.

The decision condition for this case is the password length and the prefered security level. Based on the decision condition the whole line should be checked. When every cell of the test condition is matching then the result should be ‘ok’ otherwise it should be ‘not ok’ and the not-matching cells should be displayed.

E.g. lGgAR6X8jG for Security level Low results in 'ok'(Line 2) because it has at least 1 number.
For Security level Medium it would be 'not ok'(Line 3) because it does not have at least 3 numbers and not at least 1 underscore. In the second case something like this should be shown:

result

Question

Is it possible to achieve this in "plain" DMN or is this besides the specification?

Our approaches

The next sections describe how we approached this use-case. Every of this approaches adds an dsl like abstraction layer over the .dmn files, where only the positive rule is defined and other parts are generated.

Are there any other approaches we could consider? Is there maybe something in DMN specified, because to me it feels just like a specific optional-flag for some columns.

1. Model the not()-cases with a "Collect"-Hit Policy

I think that this is the DMNish-way to approach this.

Every test condition-column with a value receives a not()-case row and a result-column if it failed. Then we change the HitPolicy to Collect and check in the code which columns did fail.

regelproblemtest2
regelproblemtest21370×381 10.4 KB

This results in a very big decision table but if we put an abstraction layer on top of it and are generating the 'real' table it might be okay. The performance seems to be linear for this approach, is the DmnEngine really evaluating every line?

2. Model the not()-cases as Ouput with JUEL

regelproblemtest3
regelproblemtest31632×223 10.9 KB

Even then we have a lot of duplicated statements. It can be okay with an abstraction layer on top of it, but then we have to convert the FEEL inputs for each test condition to a JUEL expression in the output which can be problematic for some cases (e.g. Ranges?).

3. Maybe optimize the 1. with links ?

It should be possible to optimize the first approach with Links. We could only model the 2 rules for ‘ok’ and ‘nok’ and generate a “validation”.dmn for every rule with the diagonal and link them . But this feels nasty.

regelproblemtest4
regelproblemtest41707×382 16.6 KB

Questions

Is there anything else we can consider to fit our requirements? Maybe DRD helps here? Has anyone already solved something like this?

Thank you in advance. :slight_smile:

2

@Robin could you use the DMN DRD feature to create a set of chained decisions? WHere you break down your checks into a series of checks and when one of them fails you can return the failure at that point?

I know you mentioned, it but i guess my quesiton is more, have you modeled it into a DRD yet?

Additionally would be good if you had a unit test to share on this: https://github.com/DigitalState/Camunda-Spock-Testing/tree/master/DMN

THen can iterate on variations and ensure you validation is still functional with the expected output

3

A colleague modeled some solution in DRD but it was somewhat fancy and I cannot reconstruct it right now without his input. I think he built a decision table like mine above with the decision conditions as input and the test conditions as output. Then for every test condition he built a separate “validator”-decision table (so 5 validator tables for my example) and linked them with DRD together. But im not completly sure about it. I will ask him to share his code with me and maybe write down his approach tomorrow when I find the time.

Im not sure if we can just chain the decisions, I need to think about that.

4

Looking at your cases I think you could just simplify your model:

Create a DMN per Security Level. Have the rule system set so all rules must pass. Then you dont need the negatives.

If a rule fails then you know what the issue was cause the specific line in the DMN would have not passed.

5

can check two values
like not(“1”,“5”)