Boundary Event - CancelActivity

[jonle...@gmail.com]

Hi all,

I have an email reminder (boundary event) to a task, if nobody complete the task, 3 reminders will be sent out each on every 5 days interval. For the 3rd reminder, system should close/cancel the entire flow.

How can I achieve this? I do check the cancelActivity but this will cancel the entire flow whenever trigger the 1st reminder.

Please advise.

Thanks & Cheers,
PL

[webcyberrob]

Hi PL,

Ive tried two approaches to this;

Option 1;

Use a process variable as a loop counter and use a decision gate based on the counter to determine next steps, ie repeat or cancel.

Option 2;

Use two boundary timers, one non-interrupting which repeats twice every five days. One interrupting which fires after 15 days. This branch would need to lead to a terminate event if you want the process instance to finish.

Both these approaches seem a little 'brute force', however of the two I prefer the second option. If anyone has a more elegant solution, Id love to hear about it.

regards

Rob

[Christian Lipphardt]

Hi PL,

In my opinion the second approach Rob describes it the most "expressive" one. E.g. you see in your Diagram what happens.

At the moment, the engine does not support this feature / would be hacky to do it.

Cheers

Christian

[webcyberrob]

Hi Christian,

When you say the engine does not support this feature, can you clarify which feature you refer to?

At the moment I have a small example with an interrupting & non-interrupting timer on the same task, followed by a terminate event on the appropriate branch. This works fine. However I did find that if I tried to use a Cycle ISO 8601 definition (eg R2/PT5S) on the non-interrupting timer, the behaviour was a little 'buggy' - is this the unsupported feature you were referring to?

regards

Rob

[Christian Lipphardt]

Hi Rob,

I referenced the fact that you cannot easily get the number of times a timer has been invoked.

Regarding your issue with the timers, I can confirm a strange behaviour when using timers with a retry value of <= 5 seconds.

Cheers

Christian

[Daniel Meyer]

Hi Rob, PL,

1)

There is an "optimization" in the process engine which does the following:

When creating a new timer instance, it will check whether the timer will fire before the job executor executes the next acquisition query. If true, it will immediately lock the job and add it to the job queue.

The non-interrupting timer will "chain" executions in the sense that when it fires, it will delete the job for the current timer execution and then create a new job for the next execution, calculating the date for that next execution. If the next execution date is < waitTimeInMillis, it will be locked and executed immediately.

In general, this leads to the behavior that the non-interrupting timer is not executed "every five seconds" but seemingly chained "in an endless loop" (if no upper bound  / number of max repetitions is provided).

In your case, I assume that both timers (interrupting + non-interrupting fired at the same time)

2) 

I will look into the strange behavior in combination with the Terminate End Event.

Daniel