Could someone clarify why variables set through the input mapping of an embedded subprocess are not limited to that specific subprocess but instead become accessible in the parent process as well?
In the input mapping for each subprocess, I’ve defined a variable called “myVariable.” In the first subprocess, this variable is set to 1, and in the second subprocess, it’s set to 2.
When the process reaches the service task “do foo,” both variables remain in the process context. I expected “myVariable=1” to be accessible only within subprocess 1 and “myVariable=2” only within subprocess 2, but instead, both are still available globally.
An alternative approach would be to define the input variable separately for each individual activity within each subprocess. However, I’d prefer to avoid that approach, as well as relying on an execution listener for this purpose.
Hey @astro - I was intrigued by this because I agree with you that the local variables should no longer exist when the process reaches the service task. Local variables should not propagate to the parent scope. Could you provide more detail on how you establish the locals still exist at the service task?
I created a similar model but with a couple of timer tasks rather than service task and using the Cockpit I confirmed that the local vars had been cleaned up by the final timer task after the embedded sub-processes. I am using 7.21.
What do you mean by that? The variables have the same name. How can “both” of them be available? How do you check that? If you see them in the cockpit (history view), then you should pay attention to the scope of the variables. They might appear the same, but a closer look reveals different scopes.
