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.

How to stop Timer Event ?

sivap

Hi, all i have requirement when intiator create task after it go to review team for approve or reject. but our requirement is if no review team member claim the task with in time line of timer the task forward back to intiator. if any review team member claim the task then timer event should not work and normally next process will happen……
but here we facing problem when review member claim the task and he not approved approved the task with in the time line that time timer also start and forward task back to intiator……

if there is chance to stop or deactivate the timer event………..

Find more posts tagged with

Comments

sivap

thanks in advance for reply

frederikherema1

The main problem for this use case is the fact that a timer either cancels the activity it's attached on, or triggers independently and let's the activity live (cancelActivity=true/false). There is also no "timer condition" that allows to "not execute" a timer.

A solution I can think of is using a timer-event that DOES NOT cancel the activity initially. Rather, it runs to a service-task that checks if the timer should affect the user-task or not. If the user-task has not been claimed yet at the time the serviceTask is executed, you can throw a error-event (using BPMNError). If you add a subprocess around the user-task and service-task with a catching error-boundary-event on it (with cancelActivity=false), the BPMNError will cause the subprocess to be ended (removing the user-task altogether). You're lucky the weather is nice here in Belguim, I created a diagram-image for you to clarify: http://imgur.com/5r6T7E9

If you can't to have the review-task be assigned to the initiator rather than the review-task terminated and have a new task created for the initiator, there is a simpler solution: Have the timer-boundary event NOT cancel the user-task and add a service-task as outcome from the boundary event. There, you can inspect the assignee of the task (using delegateExecution.getEngineervices().getTaskService()….) and alter the assignee in case the assignee has not yet been set. The service-task is ended and reaches it's ow end-event, ending the "forked off" timer trigger. The user-task will remain active and will be assigned to the initiator.

ergates

OK, do I understand this correctly if the following is true:

If you have a ReceiveTask waiting for a message (let us say from JMS) you cannot attach a timer to this task to be able to handle not receiving a message without doing like you advise above?

I other words any timer you attach to such a task *must* trigger and will not be canceled if you receive a message (i.e. normal flow)?

This is very strange behavior. We are seeing this in our application right now so I guess this is by design.

One should think that having a timer that dies when normal operation of the process is resumed via Signal would be standard?

Am I missing something?

frederikherema1

If you want to have events "die" in case other events occur, take a look at the event-based gateway. Of you want to have timer-events that "die" when the userTask/receieveTask is completed, use a boundary event. When the user/receive task completes, the scope surrounding it will be destroyed, destroying any attached boundary-events.