I'm doing some early experiments using drools with rules written using DMN.
In my use case the input data can be large and varied. There are also some outputs that might be passed back in during a separate call to the rules engine as inputs.
As such some of input variables may have the same name as some of my output variables. This seems to cause problems.
Specifically if I have a decision table and my output name matches anything in the the data input (whether or not the DRD tree actually accesses it) then the drools response reports an error and the output value is set to null.
Simply changing the name of my output variable fixes the issue.
However with very dynamic data such a conflict is not easy to predict.
So I would like to ask:
Is my observation correct?
Is there a common pattern to avoid such an issue (maybe some sort of variable namespacing or scoping)?
EDIT:
I may now have found a bit of the DMN standard that describes why output names and input names must not collide. I think the final decision in a graph is not special and so given that in theory a graph could exist such that any decision can be used as an input to a later decision it would not make sense for a decision output and an input on the same graph to have the same name.
From the standard https://www.omg.org/spec/DMN/1.3/PDF
As explained above, every decision, input data, and business knowledge model at the DRG level is associated with a variable used at the decision logic level. Each variable that is referenced by a decision’s expression must be associated with a required decision, required input data, or required knowledge. Also, each variable associated with the required decisions, required input data, and required knowledge must be referenced in the decision’s expression.
• If a decision requires another decision, the value expression of the required decision assigns the value to the variable for use in evaluating the requiring decision. This is the generic mechanism in DMN for composing decisions at the decision logic level.
• If a decision requires an input data, the value of the variable is assigned the value of the data source attached to the input data at execution time. This is the generic mechanism in DMN for instantiating the data requirements for a decision.
The input variables of a decision's decision logic must not be used outside that value expression or its component value expressions: the decision element defines the lexical scope of the input variables for its decision logic. To avoid name collisions and ambiguity, the name of a variable must be unique within its scope. When DRG elements are mapped to FEEL, the name of a variable is the same as the (possibly qualified) name of its associated input data or decision, which guarantees its uniqueness.
If I understand your question correctly, you are giving a try in modeling a DMN model where some DRGElement (InputData
, Decision
, ...) nodes are sharing the same name.
This is not-compliant with a valid model accordingly to the DMN standard specification, and we have checks in place with the kie-dmn-validation
module which would report this issue. The issue will be reported even before attempting to "compile" the DMN model by the Drools DMN Engine.
Demonstration:
So when you create the DMN model, if you are not respecting basic provisions fo the DMN standard Specification, we detect it with the validator module and we try to provide a sensible user message, per the screenshot above.
Please note the kie-dmn-validation
is also "embedded" while building a KJAR
with Maven using the kie-maven-plugin
and/or during CodeGen with a Kogito based projects (so the same functionality of validation is used across all build systems and platforms).