I’m sending a Message via the rest api. That message contains a process variable in json format.
An ExecutionListener attached to the boundary event can read and access that process variable successfully.
However, that process variable is not stored in the VariableScope of the process. That process variable is not
listed in cockpit and is also missing when querying the variables for a process via the rest api.
Explicitly storing that variable to the execution instance in the ExecutionListener makes no difference.
final String cancelationDateVariable = “date_of_cancelation”;
//The value that was sent via the message is read successfully here.
final String cancelationDate = getStringValue(execution, cancelationDateVariable).get();
Is that intended behaviour?
Is that an immutable VariableScope or a temporary ExecutionEntity that is provided via message handling?
So far I have to guess, but this is probably expected behavior. Due to the boundary event a second scope execution is created. Thus, you have the process instance execution scope A and a scope execution B for the activity, where B is a child of A. The variable could be contained in B and therefore you cannot access the variable, when you query the variables for a process via the rest api.
Thanks for the process definition. It is the case as I already mentioned in my previous post: a new scope execution is created.
If you need the variable in the process scope after all, you could already declare it in the start event. Then you should see the variable in cockpit and query it via rest api.
Would a previously declared variable hold the value that the message carried then?
That would only work if the temporary variable scope of the child process would inherit references of all
the variables declared in the parent variable scope and alter the inherited variables rather then “declaring” it’s
own.
If the message M1 carries a variable V1, then at the receiving end a variable scope is created that uses V1 of the parent scope if it exists or creates it’s own V1 if it doesn’t.
Yes, exactly! That’s how it works. A subexecution inherits the scope and, hence, can access/alter all the variables of its parent execution. So when you declare the variable in the process scope and then overwrite the variable in the boundary event, the variable is also changed on the process level.
I wonder why I never stumbled across this in the documentations,
because it seems to be a very basic concept.
But it’s probably my fault, because I haven’t read the docs thoroughly enough.
Altering the variables inherited from the parent scope probably happens within a transaction.
So if a sub process is interrupted by a message, and that sub process alters an inherited/shared variable,
that alteration is probably rolled back right?
