Undefined variables in BPMN task input

This seems to be a small topic, but I feel I’m still doing it wrong.

The question itself is - how to properly define a variable in BPMN > Task > Input (for example), when that variable may not exist? For example, if that variable is only created on a side branch of the model.

image

Yes, the ObjectUtils will not work (currently trying what comes to my mind). I tend to use something like

${expression.getVariable(myVar) != null ? expression.getVariable(myVar) : null}

but this is something that I would wish to reduce.

Any ideas?

Hi @Draakzward,

which distribution of Camunda do you use?

If you provide

@Component
public class ObjectUtils {

public Object defaultIfNull(Object var, Object default) {
...

in a Spring environment, your expression should be ${objectUtils.defaultIfNull(ipAdress, "1.2.3.4")}

Hope this helps, Ingo

1 Like

Hi @Ingo_Richtsmeier ,

Camunda 7.
I do realize that there is ObjectUtils, and it has the defaultIfNull. But my question was in the direction of the Modeler. If I try to provide it with a variable in input or gateway, which doesn’t exist (wasn’t declared/defined/set), I’m getting an error.

I can go with the null check, but wanted to find something less technical to use on the modeler side.

Hello my friend!

As our master Ingo reported, you could provide the component in spring and use the method to call it in the Camunda modeler, but as you are needing something directly in the modeler, without involving new components in spring, I believe that the way you use it currently is the more suitable.

I also use it in a similar way to yours, but I use it with “hasVariable()”.
${execution.hasVariable("myVar") ? execution.getVariable("myVar") : null}

William Robert Alves

1 Like

Thank you. I do understand that @Component ObjectUtils is a possibility, I was hoping that maybe I have missed something in the EL language and there is a more simple approach (it is harder to read such variables… plus easier to make a mistake if a non-tech person would like to make a change).

I did find that, unless I want a substitute value (and not just a null) I can go with a smaller call:

${execution.getVariable("myVar")} 

which behaves different from

${execution.getVariable(myVar)} 

which will cause an exception and requires the !=null ? same call : null

So that’s an option.

1 Like

I’m going to suggest going a slightly different direction…

On your start event, define all variables that you need to use in your flow with their default values. Overwrite their values on any “side-path” that you take. Then, since your “mandatory” variable has a value, you can simply use it.

1 Like

I am likely mistaken here (sorry, I don’t have enough actual executable experience…) but the second call looks like a double-replacement.

If you have variable “myVar” set to “otherVar”, then the first call would return “otherVar” while the second call would return the value of “otherVar”.

If variable “myVar” isn’t set, then the first call would return null and the second call would throw a NPE, since you’re asking for the value of the variable null (which obviously doesn’t exist)

Thought about that one as well. But that brings a new headache called “I created a task, which sets a value to this variable. I see that I cannot change it - bad BE! Go and fix form-submit and everything in that 100 step model”(just to realize that the person managed to make a mistake in the submit, and the default value is being used (been there).

It does look strange. But (for some reason) it returns the value of the variable on both cases - with and without the " (unless tomorrow my brain will sound a “Whoops”).

As experiments shown, Camunda is quite resourceful when it comes to making your head hurt. I don’t remember how many attempts I’ve made, but never managed to pass FileValue (with its additional info about file name and mime-type) as the value of an Input variable - always the byte[](unless you want to pass the name and call the getVariableTyped).

That’s the truth!

1 Like