Are input / output variable name collisions an expected problem when using drools with DMN? if yes how do I best avoid them?

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)?


  • Re: Is my observation correct?

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.

*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.*

Read more here:

Content Attribution

This content was originally published by morechilli at Recent Questions - Stack Overflow, and is syndicated here via their RSS feed. You can read the original post over there.

%d bloggers like this: