Camunda BPM execution and variable scope misunderstanding

6
votes

I work with the camunda BPM process engine and think it is important to understand some concepts. At the moment I struggle a little bit with the concept of Process Executions and Variable Scopes.

To understand what happens during a process execution I designed the following demo process and marked the activities inside the same execution with the same color. I could do this because I debugged the execution id inside each activity.

enter image description here

I understand most of it. What surprised me is that an input parameter opens a new execution (Task 1.3). Thanks meyerdan for clarification on this.

What I do not understand is that "Task 2.2" is inside the same execution of "Task 2.1". A quote from the camunda documentation about Executions is

Internally, the process engine creates two concurrent executions inside the process instance, one for each concurrent path of execution.

So I would have exepcted that Task 2.1 / Task 2.2 and Task 3.1 each live inside an own execution.

Is anyone able to explain this?

My main motivation to understand this is the impact it has on process variable scopes. I did not figure out so far what the Java API methods

VariableScope#getVariable / VariableScope#setVariable

VariableScope#getVariableLocal / VariableScope#setVariableLocal

really do. I first thought that the "Local" variants only refer to the current execution and the other ones only refer to the process instance execution - but that seems to be only half of the truth. These are getters and setters where I miss JavaDoc painfully ;-) Bonus points for also explaining this!

Thanks!

You will find the process in a Maven project with an executable JUnit test on GitHub.

1
javabusiness-process-managementcamunda
While this does not answer the question, you may find this wiki entry interesting: github.com/camunda/camunda-bpm-platform/wiki/PVM-Execution-Tree. Note that the execution tree and its structure is not documented in the official documentation. That is, because it is an internal concept and can change. Also it does not map 1:1 to concepts defined in BPMN, so it is rather hard to understand. In your concrete case, two concurrent executions are only created when the first concurrent activity becomes active. Any further concurrent activity just adds one more concurrent execution. – thorben
I understand that this may not be a satisfying answer, as executions are somehow part of the API and also relevant to understand variable handling. The root of all this is the early days of the engine in which the decision for the execution concept was made. It cannot be changed easily for reasons of backwards compatibility. – thorben
@thorben Your comment is highly appreciated and - at least - confirmed my observations. Do not hesitate to provide it as answer. Finally still strugelling with the impact of get/set Variable(Local) on Scopes. Can set variables with "Local" and get it back without "Local" and vice versa. Strange for me at the moment. – FrVaBe
Local always means operating on the execution directly addressed by the operation. Non-local means operating on the execution directly addressed by the operation or the closest ancestor execution that possesses the variable (or if none such execution exists, the root execution aka process instance). This is what we try to document in the link provided by Falko. – thorben
@thorben Finally found the explanation about the methods and their meaning - sorry I must have overlooked that several times ;-( - Please provide your comments as answer so that I can accept it. - And of course Thanks a lot! – FrVaBe

1 Answers

3
votes

Have a look at Variable Scopes and Variable Visibility

A quote from the documentation (Java Object API) about the setVariable method:

Note that this code sets a variable at the highest possible point in the hierarchy of variable scopes. This means, if the variable is already present (whether in this execution or any of its parent scopes), it is updated. If the variable is not yet present, it is created in the highest scope, i.e. the process instance. If a variable is supposed to be set exactly on the provided execution, the local methods can be used.