Activiti 6: Dynamic activityId and triggering a receive task

[donovanmuller]

So, struggling a bit to get this working as expected

We have multiple processes for different work flows, some contain either 1 or more receiveTasks

<receiveTask id="receivetask1" name="Receive Task"></receiveTask>
‍‍‍

The test process we created : [startEvent->scriptTask-> receiveTask -> scriptTask -> endEvent]

The below code will start the process and trigger successfully as we pass in the id of "receivetask1".

                log.info("Starting process…");
                ProcessInstance processInstance = runtimeService.startProcessInstanceByKey("myProcess");
 
                Execution execution = runtimeService.createExecutionQuery()
                        .processDefinitionKey("myProcess")
                        .processInstanceId(processInstance.getId())
                        .activityId("receivetask1")
                        .singleResult();
 
                log.info("Execution id : " + execution.getId() + " - " + execution.getParentId() + " - " + execution.getActivityId());
 
                runtimeService.trigger(execution.getId());
                log.info("…Done.");
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

The problem is we don't always know the receiveTasks`s id, or there could be more than one in the process.

Questions

1. Is there anyway to look up the id during runtime? Almost same as looking for the current user task and then trigger the task
 
2. did runtimeService.trigger(execution.getId()) replace runtimeService.signal(execution.getId())?
 
3. i see from previous posts in using rs.signal(e.id) needed a while loop with sleep in case it isn't yet available. Is this still needed?  <a href="https://github.com/Activiti/Activiti/blob/activiti6/modules/activiti-camel/src/main/java/org/activit...">example from camel component</a>

[jbarrez]

1. Yes, you can use an ExecutionQuery, which will return you executions with a certain activityId.
You can introspect the process definition structure (and thus determine if it's a receive task) using the ProcessDefinitionutil.getBpmnModel(processDefinitionId) method.

2. Correct. 'signal' was a bad name, which has a specific meaning in BPMN 2.0, thus we renamed it to trigger to avoid confusion.

3.Depends on where you call it, but yes, if the process has async pieces then that is probably needed.
We will add a feature soon that will solve that problem: it will be possible to send out an event that is only sent when the transaction has finished and the execution can be triggered.