you can access the results of a required decision in the literal expression by name. For example, if the required decision is a decision table with an output “foo” then you can access the result by name “foo”.
Does this help you?
Can you please provide an example?
OK. I found the problem, but I have no idea, how to solve it.
This is the DRD: collectMessages.dmn (4.0 KB) [Update]
The groovy-skript works fine, as long as both ‘sub-rules’ are containing a least one entry.
A testcase with the variables ‘sub_1_1’ and ‘sub_1_2’ set to false would have no matching rule and therefor no ‘result_1’ will be available. So the expression will break with ‘groovy.lang.MissingPropertyException: No such property: result_1 for class: Script1’.
I believe, that ‘collection values’ is bad by design, this would also fail with an regular decision table trying to access the ‘sub-list’.
The skript is ugly but seems to work:
def liste = []
if (binding.hasVariable('result_1')) { liste.addAll(result_1) }
if (binding.hasVariable('result_2')) { liste.addAll(result_2) }
return liste
If you have required decisions which may have no result then you have to deal with it. Your script is a good solution for now. I know that it’s a bit ugly and unhandy but we see the problem and try to improve that in the future. Maybe, we can support DMN context or something like this…
In general, I don’t think “collection values” is bad design. Currently, you just miss the right tools to handle them in a smooth way.
Thanks for your reply. From my ‘java-side’ point-of-view, the collection-values are ‘no good design’. That list of whatever (Map<String, Object> is fine) should not be null, it should be empty.
Null is OK for hit-policy ‘first’, if there is no ‘first’ than the result is null. But for ‘collection’, the result should never be null, it should always be a list, maybe empty.
That is, what I meant with ‘bad design’. That’s my opinion. I believe, that an empty list is all ‘tool’ you need.
Of course I do not, if null in this case is the logically ‘dmn-engine’ point-of-view.
PS:
Something dmn-context-context would be script-language-independent and more straight-forward, so feel free to implement it…
I understand your point of view from a programmer perspective:
But the DMN specification says:
A decision table may have no rule hit for a set of input values. In this case, the result is given by the default output value, or null if no default output value is specified.
Another case:
Underlaying DMN-table with two result-columns:
tempText | tempMeta
Rule-1 |
Rule-2 |
Rule-3 | metainfo
The literal expression (groovy) should now do some analysis on a list of results (hit policy ‘rule order’).
A context-dump offers this result: binding.variables.each {k,v -> println "$k = $v"} variableContext = [tempMeta:["metatext" ], tempText:["Rule-1", "Rule-2", "Rule-3"]]
So in groovy, there a two independent lists and there is no way to know, to which entry ‘metatext’ does belong.
Java behaves different, here you get a list of maps, so the both columns of a rule a mapped together, even if one is null.
I found no way to resolve this (without preventing nulls in both columns… which a not a good solution.