cancel
Showing results for 
Search instead for 
Did you mean: 

Call activity (but not a subprocess) multiple times

lars1
Champ in-the-making
Champ in-the-making
I have the following activiti flows:
mainflow
default-process
process-type-a
process-type-b

'mainflow' will call 'default-process' twice (using Call Activiti, not subprocess). Once with an input param 'type-a' and once with the param 'type-b'
The default-process will execute a few steps, and then call another activiti based on the value of the input param. Thus, the first instance of 'default-process' will call 'process-type-a', the second one will call 'process-type-b'

When I test this flow, the second call seems to fail (the one that call 'process-type-b'). Instead, it executes 'process-type-a' again, but when I debug and look at the value of the input var when the process 'default-process' is executed, it says it has the correct value : 'type-b'

Any suggestions why this is, and how I can correct this?
9 REPLIES 9

jbarrez
Star Contributor
Star Contributor
I would need to see some process XML to better understand what you're doing

lars1
Champ in-the-making
Champ in-the-making
oké, I'll try to explain it a little better with some xml

I have a main process. This process will call the "subProcessBase" twice (in parallel), but with a different parameter value for the var processKey

The subProcessBase will call another subProcess (typeA or typeB) based on the value of processKey

When I test these processes, the process typeA will be called twice, typeB will not be called at all.

<process id="mainProcess">
<callActivity id="callSubProcessTypeA"  calledElement="subProcessBase">
   <extensionElements>
  <activiti:in sourceExpression="typeA" target="processKey"></activiti:in>
   </extensionElements>
</callActivity>
<callActivity id="callSubProcessTypeB"  calledElement="subProcessBase">
   <extensionElements>
  <activiti:in sourceExpression="typeB" target="processKey"></activiti:in>
   </extensionElements>
</callActivity>
</process>

<process id="subProcessBase">
<callActivity id="callSubProcess"  calledElement="${processKey}">
</callActivity>
</process>

<process id="typeA">
</process>

<process id="typeB">
</process>

jbarrez
Star Contributor
Star Contributor
That should indeed just work … so I'm smelling a bug there.

Could you pour it into a unit test so I can verify it at my side?

lars1
Champ in-the-making
Champ in-the-making
I made a small testcase demonstrating this. Hope this helps.
See attachment

lars1
Champ in-the-making
Champ in-the-making
Any news on this issue? I don't know if this has been submitted as a bug, but I think this is a real issue so it would be a shame to just ignore this.

urgelacko
Champ in-the-making
Champ in-the-making
Any update on this? I have the same issue.

When I run the process once everything seems alright. But if I run it multiple times, the following executions calls the sub activity with the value of the variable from the first execution. I have logged the variable just before the CallActivity element, and it contains the correct value.

Maybe will there a bugfix in 5.10?

urgelacko
Champ in-the-making
Champ in-the-making
Any update on this? I have the same issue.

When I run the process once everything seems alright. But if I run it multiple times, the following executions calls the sub activity with the value of the variable from the first execution. I have logged the variable just before the CallActivity element, and it contains the correct value.

Maybe will there a bugfix in 5.10?

I have debugged into the CallActivityBehavior class, and I found that the following statement generates the problem:

if ((processDefinitonKey == null) && (processDefinitionExpression != null)) {
      processDefinitonKey = (String) processDefinitionExpression.getValue(execution);
}

After the first run, the processDefinitonKey is not null, so it wouldn't reevaluate the processDefinitionExpression. I have thought the CallActivityBehavior should be constructed in every new processInstance scope. Otherwise it should be stateless.
Am I wrong somewhere? If yes, what should I do different?

Thanks in advance!

frederikherema1
Star Contributor
Star Contributor
This has indeed been fixed: http://jira.codehaus.org/browse/ACT-1156, so it will be in 5.10 Smiley Wink

urgelacko
Champ in-the-making
Champ in-the-making
This has indeed been fixed: http://jira.codehaus.org/browse/ACT-1156, so it will be in 5.10 Smiley Wink

Great news! Big thanks for the reply.
Keep up the good work Smiley Wink