Pinned topic Bug in Repeatable Intermediate Timer Event
I am using IBM BPM v 8.0.0.
I have a scenario, where my task, here say, 'Activity' is due in 3 hours (Due in = 3 hours set in Implementation). X duration of time before due-date, in my example, 1 minute, I wish to send a single reminder mail to the assignee.
In the attached image, I have given a screenshot of the issue.
1 minute before the due-date, more than 200 tokens of task, 'Email' was created - On account of which I recvd the same number of E-mails. Thus, In less than 2 minutes, my inbox was flooded with more than 200 emails.
Can someone please tell me how to work around this Bug?
And, also maybe address this issue.
Re: Bug in Repeatable Intermediate Timer Event2013-03-22T12:29:28Z in response to SystemAdminI suspect that you might be misunderstanding what repeatable does, because that's the exact behavior I would expect given what you have configured. I'll go into the details of that in a second, but since you say "a single reminder email", I think all you need to do is uncheck the repeatable box and it will work as you intend. (What behavior were you looking for with repeatable?)
The way repeatable works is that when the timer fires (and this really only makes sense for timers without "interrupt activity" so the system won't let you use both) the system immediately recreates (i.e. repeats) the timer as soon as it fires. For example, if you had a timer that triggered "twenty minutes from now", if repeatable is checked every time the time fires a new timer will be created. Allowing you to do things like "send a reminder every twenty minutes".
But in your case when the timer "repeats", it still has the same due date of 1 minute before the task is due. So every time the timer "repeats" the new timer will have the same due date. Which means that that will also be due and fire immediately fire. Creating a new token. Which will flow to send email and create a new task. And this will just repeat as fast as the event manager can create new tokens. Creating the scenario you describe.
Re: Bug in Repeatable Intermediate Timer Event2013-03-23T04:00:29Z in response to SystemAdminHi David,
Thank you for the response. It was very well explained.
In my actual application, I wish to send a Reminder mail in an interval of every One day 3 days prior to Due Date. (i.e if due date = 27/3, then sending a reminder mail on the 24/3 ,25/3, 26/3 )
That was the reason why I had intended to use repeatable.
Can you please Explain to me, how I can achieve that functionality?
kolban 10000004463314 PostsACCEPTED ANSWER
Re: Bug in Repeatable Intermediate Timer Event2013-03-23T14:55:46Z in response to SystemAdminI think the core to the question is to understand that there are two concepts:
1. When does the time start ticking
2. How long does the timer tick for before it is fired
If we say that "T" is the time when the task is due then we want to fire the event at:
T - 1 days
T - 2 days
T - 3 days
If all we wanted to do was fire the event once, we could say "Before Due Date, Before Difference = 3 days"
However, we want it to keep on firing. A bit of thought seems to say:
Calculate custom date = T - 4 days
And then we define the fire events as:
"After Custom Date, After Different = 1 day, Repeatable"
This says that the timer will start ticking at T - 4 days for 1 day (which will be T - 3 days). At this point the timer will fire. Since it is repeatable, this will become the new start time and the timer will again start ticking for 1 day etc etc
Re: Bug in Repeatable Intermediate Timer Event2013-03-24T23:31:24Z in response to kolbanYou could do it the way Neil suggests. But, frankly, I would implement it as three separate timers rather than making it repeatable.
A) That reduces code. Rather than having to figure out custom times, you just can use the out of the box drop boxes for when they should fire.
B) It is much easier to understand for people looking at the BPMN: there's no visual indicator otherwise for "this can fire up to three times".
C) You are soon likely to get the requirement to have three different things happen for the three emails. i.e. they will want the first email to be a simple reminder, the second email to be harsher, and the third email to go to both them and their boss. Having three separate timers is the best way to support that user story.
D) You don't have to worry what happens after the third timer. With a repeatable timer it will repeat forever. It order to get it to repeat only three times you'd either have to set your fourth timer some very far time in the future or otherwise hack the timer.
Re: Bug in Repeatable Intermediate Timer Event2013-04-01T10:15:21Z in response to SystemAdminNeil & David,
Thank you So much for the 2 different approaches that ul have provided me with. It has really helped clear my concept w.r.t intermediate Timer events & I used Different timers with which it did finally work.
WilliamTanner 270004XATP12 PostsACCEPTED ANSWER
Re: Bug in Repeatable Intermediate Timer Event2013-05-16T05:59:45Z in response to SystemAdmin
I'm experiencing an issue in 8.0.1 where I untick "Interrupt activity" and "Repeatable" is automatically ticked.
I then untick "Repeatable", so neither box is ticked. When i click away from the intermediate timer event, then click back the "Repeatable" box is ticked again.
Is this expected behaviour? Ie you have to select either "Interrupt activity" or "Repeatable"?
I'm trying to have both boxes un-ticked so I can send one reminder at a custom date, that doesn't repeat and doesn't interrupt the flow.
AndrewPaier 2700040K2Q711 PostsACCEPTED ANSWER
Re: Bug in Repeatable Intermediate Timer Event2013-05-16T15:36:31Z in response to WilliamTanner
This feels like a problem that the engineers didn't realize they were creating when they attempted to unify the various events. In 7.5 and earlier there were separate widgets to drag in for message, timer, and error events. I think that "timer" used to support not being repeatable back in 7.5, but I could be wrong. Now, I can understand how "repeatable" is required when you don't allow "interrupt activity" since there is still a token on the Event since the task is active. The question is, do we still have the infinite loop behavior?
So, I setup the attached model with the time set to "1 minute after start of step". When I did that the timer appeared to trigger every minute. So it seems to take "start of step" to really be "When the timer token was created" since a new one is created every time the old one move forward.
I think tried to make the number of minutes into a variable. The first one is 1 minute and on the post of the timer, I changed it to 15. This also appeared to work. Hooray!
Now, what about the "before end of step" problem? I changed the timer for that. Unfortunately this did the "infinite loop" thing and when we passed that time it just started creating the 2nd task over and over. Not good.
But, can I trick it with the delay code? I used a variable set to 1 (minute) before due date and, on the post of the timer, set it to -100,000 (without the comma). Success! The timer fired, but then did not trigger again. (I didn't wait 100,000 minutes to see if it would fire again...)
Zhongtao Gao 110000SSQN1 PostACCEPTED ANSWER
Re: Bug in Repeatable Intermediate Timer Event2013-11-20T02:49:17Z in response to WilliamTanner
It's a bug in BPM 126.96.36.199 and has been fixed in 188.8.131.52. Please see JR45637 for details.
WilliamTanner 270004XATP12 Posts