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
- decision condition … the matching
rowshould 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.
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.
test condition-columns are an amount of the different character types to exist in the given password.
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.
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:
Is it possible to achieve this in "plain"
DMN or is this besides the specification?
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.
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.
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
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.
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.