Call Activity Variable gets overwritten by Parent Process

Flowable Engine
1

Hey,
we are working with a 3rd Party Software using Flowable as the Workflow Engine.
We are upgrading the product, including the upgrade from activity 5.15 to flowable 6.6.0.

We now have a Problem using our Call Activities they way we used to.
So we have a main Workflow, calling a “callActivity” and passing some variables like this:

<callActivity id="flowable.MyWorkflow" name="flowable.MyWorkflow" calledElement="MyWorkflow">
      <extensionElements>
        <flowable:in source="test1" target="internalTest1"/>
        <flowable:in source="test2" target="internalTest2"/>
      </extensionElements>
</callActivity>

The variable “internalTest1” is not used in the parent workflow and does not exist.
The variable “internalTest2” tho, is existant and has a value in the parent workflow.
So if we try to get “internalTest2” in the child process/callActivity by using:

execution.getVariable("internalTest2")

we will get the value of the parent process instead of getting the value it was set to (so speaking in “parent process terms” it should have the value of “test2”)
When reading “internalTest1” tho, we will get the value it was set to during creation of the callActivity

When getting all variables using:

execution.getVariables()

“internalTest2” exists only once and has the value of the parent process.
On the side, the getVariablesLocal() is empty.

This used to work in activity. What are we missunderstanding?

If we change the name of the “in” variable from “internalTest2” to let’s say “myNewlyCompletlyUniqueVariable2” it will work correctly. The problem is, these workflows are calling each other in many complex ways and we can not guarantee that there will be no collisions in other circumstances.

How are we supposed to handle this issue?

2

Hi Dimi,
I have just tried to reproduce your issue with version 6.7.2 and am not able to.
The variable contexts are isolated as expected.
Can you export a (set of) process models that demonstrate the issue, or test with the 6.7.2 release.
Thanks,
Greg

3

Hey :slight_smile:

First of all thank you very much for your quick answer.

unfortunately we are not able to use another version than 6.6.0, since it is build into the third party product we are using. But we rebuild a situation like this in “plain” flowable 6.6.0 , and we are NOT able to reproduce it. The same example in the third party still breaks. So it seems to be a third party problem, somehow messing with flowable.

We will go into Contact with the third party Devs, so for now I think this problem is “solved” regarding flowable.

4

Sorry to hear that Dimi,
Is it possible to tell me the product so I can correlate the issue if they reach out to us (Flowable)?
Might make it faster (I actually have an idea what may be happening, but it is likely the fix is needed in their environment).
Regards,
Greg

5

Sorry for taking a while needed to talk this through with the team :slight_smile:
We are using Forgerock IDM 7.2.1 migrating from a prior version that used activiti.
We allready got in contact and we hope to get some help very soon. We could replicate the issue there even in “stock” version, but don’t have the problem in flowable “standalone”. You could not replicate it either so we are pretty sure it’s a problem with IDM.

Thanks a lot again,
Dimi

1 Like
6

@Dimi.K
You should try this with Flowable 6.8 (the version IDM uses) standalone. I am testing parent process-subprocess communication and I have a similar problem. I don’t believe this issue is related to IDM