Data flow vs Workflow

Hi @mdizzleforizzle,

We’ll have to clarify storing/accessing an object as a process variable. In a JavaDelegate implementation, you have the four API methods #setVariable, #setVariableLocal, #getVariable, and #getVariableLocal. Both set methods may override existing variables.

#setVariable sets a variable and attaches it to the top-most variable scope (for the exact semantics, see the docs link Rob provided).

#getVariable retrieves a variable from the closest variable scope in its parent hierarchy. I.e. it first checks if the current execution has the variable, if yes, then return it. If not, then look at the parent and so on.

#setVariableLocal sets a variable and attaches it to the Execution object that executes the service task. If that is the same execution that executes the next task, then you are able to access the variable there. If this is the case depends on the process model you have and in particular on whether task A is a scope. An activity becomes a scope for various reasons, for example because events can be received in its context (i.e. a boundary event is attached) or if it has a variable input/output mapping. For every activity that is a scope, the process engine creates an extra execution and destroys it (including attached variables) after the activity has finished. In that case, the parent of the scope execution is going to execute the next activity.

#getVariableLocal gets a variable without considering the parent hierarchy.

Since the considerations regarding #setVariableLocal deal with internal concepts that are not straight forward, I recommend to use #setVariable over #setVariableLocal if you do not need variables with the same name at the same time within a process instance. If you cannot use #setVariable, I suggest you post an example process model and code and we discuss that.

Cheers,
Thorben

1 Like