Multiple output variables for decisions using literal expressions

Hello!
I have some complex logic that is decomposed into multiple decision tables and decision expressions, and then a single decision expression that combines the results from all of them. I need to use the result from this combining decision in another decision table.

The problem is that I can only have one output variable with a simple type, but really need to retrieve 2 or more different fields from the combining decision (I need to use them in a final decision table as inputs)

Now the alternative might be to use a decision table with multiple output columns, but unless I am missing something this will force me to repeat the code in each output column with minor modifications, like this:

Output1={ combining code}.result.field1
Output2={ same combining code as in Output1}.result.field2

This will also run the same computation twice which might be expensive (we use custom FEEL functions with some REST stuff).

Is there some way to solve this problem without repetition and duplicate computation? I think it could be a nice feature request to be able to return a context object from a literal expression and then the DMN engine could use keys and values from this object as output variables. Then these output variables will be automatically available in the next decision table (that depends on this decision literal expression) from the DRD graph.

Note: we use Camunda DMN engine only in a standalone Java service, without BPMN, and trigger the decision evaluation from Java code.
Thank you!

Hi @Dmitrii_Davidyuk,

interesting question.

it could be a nice feature request to be able to return a context object from a literal expression

This is possible. You’re not limited to the given types in the drop-down. You could select none, or just type something else in the field.

then the DMN engine could use keys and values from this object as output variables. Then these output variables will be automatically available in the next decision table

No. This is not compliant to the DMN spec. The result of a literal expression is one variable. The variable can be complex (i.e. a context) but it is just one variable.

In the dependent decision, you could access parts of it by using result.field1 and result.field2. It doesn’t evaluate the decision twice.

Does this help you?

Best regards,
Philipp

Hi @Philipp_Ossler, thank you, this helps. I didn’t realize you could leave the Type field empty.
Follow-up question, if I enter something else in the Type field (e.g. context), DMN engine prints this warning in the logs:

DMN-01006 Unsupported type 'context' for clause. Values of this clause will not transform into another type.

Can we encounter any errors because of this warning? Do we need to do something to resolve this?

You can simply ignore this warning. It will not apply any type checking because the type is unknown.

If you really want to get rid of the warning then you could implement a custom type transformer. Have a look at the docs: Data Types in the DMN Engine | docs.camunda.org

OK, thank you for your help!