nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

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

receive_task_bug.png

activiti_receive_task.zip

Find more posts tagged with

Comments

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();<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for (Task task : list) {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; taskService.complete(task.getId());<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }

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
<br>Assert.assertEquals(1,list.size());<br>
before the for loop, and potentially adding

<br>list = taskService.createTaskQuery().processInstanceId(processInstance.getId()).list();<br>Assert.assertTrue(list.isEmpty());<br>

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]

receive_task_2.png

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.

jeanhelou

Thanks for your answer, the restart actually works with the current design. But your solution does sounds like I am looking for. I'll check if it is supported by activiti.
In the mean time, I asked a specialist at our company and he was able to come up with the following which actually achieves the behaviour I was looking for. It still seems like a hack to me but hopefully it will help someone else.
[attachment=0]Redo_fixed.png[/attachment]

Redo_fixed.png

jeanhelou

Checking Activiti's user guide I found http://activiti.org/userguide/#bpmnSignalEventDefinition which sounds like it could work. I'll test it asap

amuthuse

This approach has two drawbacks,

1. Unless you mark both the boundary error events as 'cancel activity', your other executions will still be hanging around in the database. You can query act_ru_execution table and verify it.

2. As I understand from your diagram, Flow from Task 1 to Task 7, is a normal business flow. And you end up you end up marking as a error end. Which might raise questions from the business users.

I do have a similar usecase in my application, ( ie, while the process is undergoing, at any point of time, the associated application data might get changed and hence we need to redo some of the activities which are already completed based on older application data). But till now, I couldnt come up with a proper process solution using activiti.

I hope the experts out here would give a better suggestion…

jeanhelou

We are studying the following to replace our current method :
[attachment=0]restart_signal.png[/attachment]
This uses a signal boundary event to avoid creating a receive task. Since it's the receive task which remains active when the subprocess reaches the end event.

we intend to used this with
<br>RuntimeService.signalEventReceived(String signalName, String executionId);  <br>To only restart the process we want to restart.

restart_signal.png

jeanhelou

For information the above solution works perfectly. it allows the process and subprocess to complete normally. Huge thanks to Gut Lez for his suggestion