Data flow vs Workflow

Can you provide direction for how Camunda handles data flow.

Based on some simple testing of checking execution listeners on sequences, it appears the data does not flow from one task to another.

The output from a multi instance subprocessor I would assume to be the collection but while looking at the execution listener it appears only one item is produced.

Any thoughts on this?

Hi,

Ive just written a process using lots of multi-instance tasks. In my experience, its useful to understand process variable scopes [1]

You are right in that at the process instance level you may have a collection. Within each multi-instance instance you will have an element. I found that I needed to treat the elements as ‘pass by value’ rather than pass by reference. Hence if you modify attributes on an element of the collection, you need to explicitly put the element back into the process level collection.

This forum thread may be of interest as well.

regards

Rob

[1] https://docs.camunda.org/manual/7.4/user-guide/process-engine/variables/#variable-scopes-and-variable-visibility

Might have not stated the question well.

If there are 2 tasks, Task A and Task B connected with a sequence flow . Task A processes incoming “orders” and stored as a process variable.

After Task A is completed, do the “orders” object flow through the sequence flow to Task B? Or does Task B access “orders” in the process variable scope?

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