cancel
Showing results for 
Search instead for 
Did you mean: 

process& subprocess with receive task never completes

jeanhelou
Champ in-the-making
Champ in-the-making
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
14 REPLIES 14

jeanhelou
Champ in-the-making
Champ in-the-making
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]

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

amuthuse
Champ in-the-making
Champ in-the-making
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
Champ in-the-making
Champ in-the-making
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

RuntimeService.signalEventReceived(String signalName, String executionId); 
To only restart the process we want to restart.

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