Timer event and execution local variables

Hi,
in the attached process I have a service task linked to a timer boundary event of my user task (e.g. a reminder).

The user task is performed using the rest APIs:

//GET  /task/{taskId}
//PUT  /execution/{taskExecutionId}/localVariables/{varkey}
//POST /task/{taskId}/complete

Where the localVariable set is OUTCOME=“exit”.

In the service task I’m using a JavaDelegate which sets a local variable with the same key OUTCOME=“done”

execution.setVariableLocal("OUTCOME","done")

In the outgoing flows from the exclusive gateway I have expressions that check the value of the variable OUTCOME

${OUTCOME=="exit"}

When the user task and the the timer event are created Camunda creates a new execution for the user task and uses the process instance execution for the timer.

When the conditions are evaluated Camunda obviously is reading the execution to which the sequence flow is attached (the process instance) and is finding OUTCOME=“done”.

In my opinion the user task shouldnt be moved to a child execution but must stay on the process instance execution.

If I remove the timer (and also when I have forks with parallel executions) everything works as intended.

any idea?

thank you
MarcoProcessTest.bpmn (6.4 KB)

Hi Marco,

With a boundary event attached, the user task defines a scope and therefore receives its own execution. This execution lives only for the duration of the user task instance, so it will be deleted when the task finishes, including all local variables.

I recommend to not use the #setVariableLocal API here, but rather #setVariable(String variableName, Object value) or #setVariable(String variableName, Object value, String activityId) if you have a more complex model with sub processes etc.

Cheers,
Thorben

Hi Thorben, thank you very much for your answer. What if the same key is used in other conditions? Setting it on the processInstance I’m overwriting the value and I’m not able to understand in wich scope the value changed.

e.g. see this attached process
ProcessTest (3).bpmn (10.3 KB)

Cheers
Marco