Variable Control


When using variables in a workflow, if you have variables in separate branches of a workflow of the same variable name and then combine these branches together (by a Joiner or Concatenate node) you end up with BOTH instances of the variable with the same name.

This now causes ambiguity as to which of the two instances will be selected later in the workflow when using this variable.

There really needs some additional nodes in the repository to address this such as a "Variable Rename" node, and also a "Variable Filter" node. Otherwise there is no way of the user addressing this issue.


Hi Simon,

I ran into this problem too. From my tests I found that the top-most in-port variables always win. For example if you have a concatenate node the flow variable of port 0 will overwrite the variable with the same name of port 1. If you would like to use the variables of port 1 instead you can draw a variable connection between the node at port 1 and the concatenate node. This way the variables of port 1 are on top of the variables of port 0 and overwrite them.



Thanks Guido,

Thats useful to know, but there needs to be a more elegant solution to this.


Can you use a Java edit variable node to with the snippet 'return $$My_Variable$$;' configured to put it into a new variable as an alternative temporary fix to rename variable(s) on the lower port?

I was waiting for someone to mention Java nodes!!!

Maybe this would work, but then I remember a post only about a week or two ago about the Java Edit Variable node causing similar issues too of not overwriting existing variables.



Always happy to oblige!

I think any node which modifies a variable looks like it has 2 copies of the variable in the out port - one is the original value, which is normally ignored, and the other the new value, which is normally what is actually used.


Dear all:

I'm happy you could sort out most of the obstacles already. Let me give you a summary on what's happing in the background if you merge two branches with ambiguous variables. There is a magic rule: The top-most input defines the value of ambigious variables. We had longer discussion on how to resolve these conflicts and that is the decision we made. The main reason for the top most input is that (a) it's simple and (b) it makes sure that a variable connection (these optional mickey mouse ears) allow you to overrule any other value assignment from an input. If, for instance, you had a Joiner node and wanted the second input to define the value of a variable that's also defined at the first input, you could define an additional red variable connection from the upstream node at the second input to the variable input of the Joiner and hence make sure its value precedes any other input.

Why are there duplicate variables in the output even if there are no side branches in the workflow? We are definining and keeping variables by using a stack of variables (and loop information) in each node. So what's visible in the "Flow Variables" tab in the output view is the stack. If a node overwrites a variable it puts a new copy of that variable with a new value onto the stack. Downstream nodes will then just see that new value when they access that variable. From a programming point this concept is useful because it allows us to "clean" the stack if it's modified in a loop (we need to restore the state of the variables after the loop end as the variables defined during the loop are only valid for the current loop iteration).

There are (almost) always two copies of a variable on the stack because (most) of the nodes define a variable during configuration (without a valid value) and during execution (with the final assignment). Since the variable from the execution phase is put on top, it defines the value that's seen by downstream nodes.

I think (and please disagree if necessary) it's confusing that you see multiple occurrence of a variable in the output view. I will open a bug report that duplicates need to be filtered; the end user should really only see the currently active value of a variable.


Thanks for the explanation Bernd, now I understand. I think for most workflow developers, seeing a list of filtered variables with their current values is less confusing. If you were to have only one view of variables, I would favor that view. If you keep the stack view perhaps renaming the tab to something like "variable stack" would be helpful.

Just a thought... the Inject Variables node performs a special function related to variables, and you might consider adding an option in the configuration dialog to specify whether the top-most (data) inport wins or the second (variable) inport wins. In most cases I would think the user's intention is to override variable values from the data port with same-named variable values from the variable port (which is not the current behavior). I understand this can also be accomplished by dragging the incoming variable connection to the mickey mouse ears of the Inject Variables node, but it's not as obvious to the developer as a configuration option.

Expanding on that thought... maybe this is getting too complicated, but if you wanted to get really flexible, perhaps you could allow the workflow developer to specify the specific inport that wins for each same-named variable (the default could be that the top-most inport wins). Would it be possible to do this at the system level so that it's independent of the node? i.e. every multi-inport node automatically contains a tab in the configuration dialog that allows one to choose which port wins for each same-named variable?