cancel
Showing results for 
Search instead for 
Did you mean: 

Sending a message to cancel a usertask within same process

jkuehn
Champ in-the-making
Champ in-the-making
Hi,

we have a process with two usertasks spawning after a parallel gateway. As long as usertask 1 is not completed, the user should be able to complete usertask 2. Once usertask 1 is completed, usertask 2 should be removed.

How would you model this? Our current approach:

[img]http://picture.ms/images/2013/10/08/parallelUserMessagebTPsf.png[/img]

We try to solve it using a message. The problems we are having:
* Sending a message to usertask 2 with execution.getEngineServices().getRuntimeService().messageEventReceived(MESSAGE_NAME, executionIdOfUsertask2); from servicetask successfully ends usertask 2, calls "Do some stuff" and goes to the end event. But: the process will not be finished, "Send Message to Cancel Usertask " servicetask remains active.
* Sending a message to usertask 2 with execution.getEngineServices().getRuntimeService().messageEventReceived(MESSAGE_NAME, executionIdOfUsertask2); from servicetask in a seperate thread successfully cancels usertask 2 and finishes the process the desired way, but throws ActivitiOptimisticLockingException occasionally.

Catching ActivitiOptimisticLockingException didn't work. I tried to implement a retry loop as has been suggested in another discussion, but the catch clause doesn't catch ActivitiOptimisticLockingException:


int retries = 3;
while (retries > 0) {
    try {
        runtimeService.messageEventReceived(messageName, task.getExecutionId());
        break;
    } catch (ActivitiOptimisticLockingException ex) {
        if (–retries < 1) {
            // fatal, escalate
        }

        try {
            // give some time to recover, allow other instance to finish work on process
            Thread.sleep(100);
        } catch (InterruptedException e) {}
    }
}


Do you have some hints?

Thanks, greetings, Juri
5 REPLIES 5

jkuehn
Champ in-the-making
Champ in-the-making
Small update:

ActivitiOptimisticLockingException is caught correctly, i was logging to std out and misinterpreted the output.

The ActivitiOptimisticLockingException occurs after recieving the message and executing "Do some stuff" service task. After the exception, the usertask 2 remains active. On a retry to send the message again, no exception occurrs and the process ends as desired. But the "Do some stuff" servicetask has been executed 2 times in that case.

Gateway->usertask1->servicetask send message->endevent
message event->servicetask do some stuff->endevent –> ActivitiOptimisticLockingException triggers retry –>message event->servicetask do some stuff->endevent

Can i implement some sort of queue, to avoid concurrent modifications? How to check whether a process is locked? Is there a better way to model this use case?

trademak
Star Contributor
Star Contributor
When using the parallel gateway you should make sure that you have a joining parallel gateway before you end the process. So instead of having 3 end events you should include a joining parallel gateway and 1 end event. Also instead of using a message event I think it would be better to use a boundary and a throw signal event.

Best regards,

jkuehn
Champ in-the-making
Champ in-the-making
Hi Tijs,

thank you very much for your feedback. The following model works like a charm (signal is sent using signalEventReceived(signalName, executionId) to deliver signal to the specific execution):

[img]http://picture.ms/images/2013/10/09/parallelSignal.png[/img]

Greetings,
Juri

trademak
Star Contributor
Star Contributor
Hi Juri,

Great, you could even use a signal throw event element instead of a service task to send the signal event.

Best regards,

jkuehn
Champ in-the-making
Champ in-the-making
Hi Tijs,

great to know. A good modelling can save a lot of implementation Smiley Happy In our case we want to send the signal to the usertask in the current process only. As far as i understand the intermediate signal throwing event would not suit this case, as it sends a global event. We are quite happy with your suggested solution: no async executions, no retries, clear process.

Thanks again,
Juri