I implemented a DRD as described here: Results from multiple DMN tables - #8 by felix-mueller
The referenced decision tables collect messages, these messages should be collected by the literal expression.
I tried to test this with a DMN-JUnit-Testcase, but I can’t find a way to access the results from the ‘sub’-tables.
Any code-examples?
Hi @shp,
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?
Best regards,
Philipp
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 listeHi @shp,
it’s great that you found a solution.
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.
Best regards,
Philipp
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…
Hi @shp,
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.
In this case, the result should be null.
Best regards,
Philipp
Who cares about specifications. 
Ok. Point for you.
Am I right, that there no way to define a default value (empty list) within the modeler?
You’re right. Currently, there is no way to do it. But feel free to open a new feature request!
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.