Camunda:initiator plugin variable value null in CallActivity after calling it with "Asynchronous Before"

I have a use case where a CallActivity global sub process will be called by multiple users in a given workflow. It looks somewhat like this.


The multi-instance serial sub process is called with list of users. (For this demo, I use favorite Camunda users ‘john’ and ‘mary’). And in “Called Process” I have set variable calledProcessAssignee in Initiator plugin value and then use the variable for the user task with ${calledProcessAssignee}.

Now everything works fine when there are no transaction boundaries. The user task in “Called Process” will be first assigned to ‘john’ and then ‘mary’.
Problem is that when I apply “Asynchronous Before” flag on “Call to modular process” CallActivity in Initiator Test process, everything falls apart as value of calledProcessAssignee is null. I also know the probable reason that due to “Async Before” job executor takes over the execution of the process and therefore there is no formal initiator of the process.

But in ideal situation this should not be the case right? Just because, process was started asynchronously, should not change the fact that some user initiated it.

So my question is, why should value of initiator should be null when some transaction impacts it?
process.bpmn (8.2 KB)

The JavaDelegate source code is extremely simple and irrelevant to the problem therefore I have not reproduced it here. If need be, I can do that.

Thanks and Regards
Chaitanya

Hi Chaitanya - Would it work if you move the async flag to the start shape of the “Called Process” ? Also can you try with #{calledProcessAssignee} instead of ${calledProcessAssignee}

Hi Dinesh, first of all thanks for your answer.
Due to a certain requirement in my actual process I cannot remove “Async” flag on the Call Activity. But I tried with #{calledProcessAssignee} on user task inside Called Process and it still did not work. The task still remains unassigned whereas it should have been assigned to John. (Please see screenshot.)

Actually I have realized that by mixing transactions and asynchronicity, behaviour of process engine has become much more complicated. These two concepts should have been treated separately in design. But that’s a topic for a separate thread.

Regards
Chaitanya

Hi Chaitanya - I understand the constraint on moving the async flag . That said can you try to test by moving the async flag to the start shape . If that works we can get more details from the Camunda team on the behavior of async on the “Call Activity”

Hello Dinesh, you are correct. By moving the “Async Before” flag at the start event of the sub process, user task assignment works correctly. I think that’s because now the user tasks in process “Initiator Test” and “Called Process” are in same transactions and process engine can derive who the initiator was.

But I have a feeling that I would not also be able to do that in my actual process. My actual process has timers slapped on the Call Activity. And in order to get the timer details, a transaction must be committed there (because timer job for intermediate boundary event does not get created before the activity itself is created and committed) which means transaction boundary cannot be moved.

Nevertheless, now the question has become, why the behaviour of camunda:initiator plugin is restricted by a transaction boundary? Right?

Hi Chaitanya - Good to know that worked . I am suspecting the async in Call Activity is not propagating the information which might be a expected behavior . If you need to use the timer boundary you might have to model it around this issue .

@camunda - Team , can you please provide your inputs on this .

Thanks
Dinesh

Hi @chaitanyajoshi,

the initiator saved the user id in a named process variable. You have to pass the variable explicitly into the called process in the call activity https://docs.camunda.org/manual/7.12/reference/bpmn20/subprocesses/call-activity/#passing-variables.

lt will work even after a wait state.

Hope this helps, Ingo

Hello Ingo,

Currently I have set the initiator property inside the “Called Process” and expected it to function it that way. Because if I am calling this process from multiple locations then I must set the initiator in every caller instead of “Called Process” and then pass it to the “Called Process”.
But if there is no other way then I must go with this workaround.

Thanks and Regards,
Chaitanya