Camunda 7 DMN - Groovy Expressions in Input and Output

[DaveyStones]

Hi all,

Note: For these questions, I’m using the Camunda Platform 7 Run spring boot engine as a remote engine with a side-along API that uses the Camunda REST + External Task client lib (7.19.0).

1. I have a fairly simple decision table and I need to be able to include as an output item an array of strings. This array may not be the same length for each rule. Here’s a screenshot example showing the decision table:
   

   

   Following the business rule task for this decision in my BPMN, there is a Java external task worker that is attempting to read in this array as a Java String array using this statement:

   String[] params = externalTask.getVariable("params")
   

   However, when I do this with the default expression language (FEEL), it appears to wrap the array in a Scala JavaCollectionWrapper$SeqWrapper class which cannot be deserialized as a String array directly in the Java class. I am able to get it to work if I add an execution listener to the business rule task to cast the collection as a Groovy String array and store that into the process variable context.

   This is the Groovy script in the end execution listener for the validation business rule task:

   def messageParams = execution.getVariable('validationError').get('messageParams') as String[]
   if (messageParams) {
     execution.setVariable('params', messageParams)
   }
   

   While this bandaid works, I’d much rather not have the extra execution listener. Is it possible to make the cell a Groovy language cell and construct the array such that it maintains its type when added to the SingleResult map? I’ve tried but can’t seem to get that to work; it doesn’t like the array notation.

2. Another Groovy-related question I had is for input expressions. What I’d like to be able to do is use the null-checking operator to avoid long if FEEL expressions. So instead of:
   FEEL:

   if (is defined(options) and is defined(options.optionalIndicator)) then options.optionalIndicator else null
   

   …something more concise and manageable/readable:
   Groovy:

   options?.optionalIndicator
   

   However, this doesn’t work; the expression evaluator for Groovy doesn’t seem to recognize the nested field because the input is of type json. Here is an example request I’m using to test the dmn in the remote engine:

   {
       "variables": 
       {
           "thing":
           {
               "type": "json",
               "value": "{\"type\": \"Bird\", \"alive:\" true}"
           },
           "options":
           {
               "type": "json",
               "value": "{\"optionalIndicator\": true}"
           }
       }
   }
   

   Is there a way to get the Groovy expression to evaluate the input so that it actually has child properties rather than being the Spin JSON object? Or is there a better way to do inline null checks without having that gangly FEEL conditional expression?

Thanks for all your help!

[Philipp_Ossler]

Hi.

Regarding the questions:

1. Try to cast the result to List<String>. The Scala object should implement Java’s list interface.

2. I have no idea about the usage of Groovy. But you could simplify your FEEL expression to

if options.optionalIndicator != null then options.optionalIndicator else null

Note that in further versions, the FEEL expression will become simpler by adding a new built-in function and improving the null handling in general. Stay tuned.

[DaveyStones]

@Philipp_Ossler

1. Try to cast the result to List<String>. The Scala object should implement Java’s list interface.

Where would I cast this? In the decision table column type, or in the external worker when getting the variable from the externalTask context?

@Philipp_Ossler

2. I have no idea about the usage of Groovy. But you could simplify your FEEL expression to

if options.optionalIndicator != null then options.optionalIndicator else null

Thanks for the simplification, however, if options or options.optionalIndicator are undefined, this results in a null error.

@Philipp_Ossler

Note that in further versions, the FEEL expression will become simpler by adding a new built-in function and improving the null handling in general. Stay tuned.

That’ll be very nice to have! Thanks for the update!

[Philipp_Ossler]

@DaveyStones

Where would I cast this? In the decision table column type, or in the external worker when getting the variable from the externalTask context?

Ah. This suggestion was related to the Groovy script.

@DaveyStones

Thanks for the simplification, however, if options or options.optionalIndicator are undefined, this results in a null error.

Not. In this case, the expression returns null. (Since version 7.14.0)