process& subprocess with receive task never completes

[jeanhelou]

Hello,

I tried the following very simple workflow:
[attachment=1]receive_task_bug.png[/attachment]

In my understanding, when completing usertask1 (User Task) the workflow should be completed. However the following java test code fails :

@Deployment(resources = { "workflow/TestProcess2.bpmn20.xml" })    @Test    public void should_complete_process() {        ProcessInstance processInstance = runtimeService.startProcessInstanceByKey(RESTART, new HashMap<String, Object>());        Assert.assertNotNull(processInstance);        List<Task> list = taskService.createTaskQuery().processInstanceId(processInstance.getId()).list();        for (Task task : list) {            taskService.complete(task.getId());        }        List<ProcessInstance> list1 = runtimeService.createProcessInstanceQuery().processDefinitionKey(RESTART).list();        Assert.assertTrue(list1.isEmpty());    }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Is this a bug, am I missing something ?
I added the test case, the test workflow and the spring context to this post  just in case

thanks

[gutlez]

I might be wrong in my interpretation of your diagram, but if you complete both the User Task and the Receive Task, both will be started again.

So…
Your code
List<Task> list = taskService.createTaskQuery().processInstanceId(processInstance.getId()).list();
        for (Task task : list) {
            taskService.complete(task.getId());
        }
Completes both tasks, which should cause the subprocess to restart.

If your final end event was a terminate instead, it should cause all your tasks to be ended.

If your code only completed your manual task, you would still have the Receive Task open, and your process would not be completed.

If your branching gateway were exclusive rather than parallel, then you would need to identify which flow was active, and completing the active manual task would complete the process.

I think what you are trying to model is a Boundary Receive Interrupting event, which I don't think Activiti supports (yet), which would cancel the manual task upon receipt of a message, and then restart it.

[jeanhelou]

"Receive Task" is a Java receive task (http://activiti.org/userguide/index.html#bpmnJavaServiceTask) it creates an execution instance but is not counted as a pending task.

In my test case, the list of tasks contains only one task (user task) and does not complete the receive task. You can easily verify this by adding the following assertions

Assert.assertEquals(1,list.size());

before the for loop, and potentially adding

list = taskService.createTaskQuery().processInstanceId(processInstance.getId()).list();
Assert.assertTrue(list.isEmpty());
after the for loop.

you will find that the process is not restarted and only the user task is visibler from a taskQuery

[trademak]

Hi,

When you use a fork parallel gateway, this means you also need a join parallel gateway.
So in your example the process will never finish because you don't have a join parallel gateway.

Best regards,

[jeanhelou]

I tried with this, still doesn't complete .. I obviously don't want to activate the error end signal when my process complete normally …
[attachment=0]receive_task_2.png[/attachment]

[jeanhelou]

Should I open a bug for this ?

[amuthuse]

This is not a bug.

You are using the following Query to fetch the open tasks,

List<Task> list = taskService.createTaskQuery().processInstanceId(processInstance.getId()).list();

This will give list of user tasks only. This will not give you the receive task.

The recevie task is not a user task. The receive task is more of a wait node in your process. Till you explicitly signal the execution, your subprocess will still be active and be waiting for the signal.

But as per your process diagram, even if you signal it, you are trying the re-enter the sub-process, not sure what you try to achieve with this. Probably you might want to have exclusive gateway not the parallel gateway.

[jeanhelou]

The process shown is a trivial example to show what I am trying to accomplish and to make it easy to test and reproduce.  I have ten user tasks, I want to be able to restart the workflow at the start from any point if a critical information changes. This is what the receive task is here for. It will allow me to reopen the workflow at the start.

My problem however is that I would like the workflow to actually COMPLETE when all the user tasks are marked as completed and have that CANCEL the receive task. I can't seem to be able to do that. In a previous answer  trademak said it was because there was no path from the task to the workflow end, but he didn't provide an example model to fix my problem, hence my followup proposal which doesn't work either.
Is there a way to complete the process and cancel the receive task without triggering the error condition ? Are you certain it is not a bug if such a way doesn't exist ?

[jeanhelou]

There may be another way to model this which I am not aware of, I would absolutely welcome any suggestion.

[gutlez]

I think what you are trying to model is a boundary interrupting message event.
I'm not sure if Activiti supports this at this point.

See http://tynerblain.com/blog/2006/08/22/bpmn-intermediate-messages2/ for more description.

Your boundary event would be on the subprocess, catching a message, which would then interrupt the subprocess and restart it.