gs.eventQueueScheduled not triggering events after several days

[DiStrapps]

We've got a process whereby we can email the customer through Service-Now to ask a question, then if there's been no reply after five working days (7 actual days), a reminder is sent, then after 10 working days (15 actual days) the incident is closed.

We do this via a business rule which has the instructions

gs.eventQueueScheduled("incident.reminder5.req",current,gs.getUserID(),gs.getUserName(),current.u_reminder_5_days);
gs.eventQueueScheduled("incident.reminder10.req",current,gs.getUserID(),gs.getUserName(),current.u_reminder_10_days);

Each triggers a script action. The five day action says

gs.eventQueue("incident.reminder5",current,gs.getUserID(),gs.getUserName());

and works fine, and the email is sent. The 10 day one, which closes the incident and sets resolution and closure codes says

gs.eventQueue("incident.reminder10",current,gs.getUserID(),gs.getUserName());

and does not trigger. If I change the timings to 5 and 10 minutes, they both work fine, so I know the script actions and events do actually work.
So it does appear that it's the 15 day delay that is causing the schedules event to not trigger.

Is there anywhere I can see the Scheduled event queue, to check that my 15 day forward event is still there? Or does anyone know whether there's a limit to how far ahead you can set up scheduled events?

Many thanks
Di

[DiStrapps]

I think I've answered my own question.

What seems to be happening is that the reminder events get logged when the button is pressed (or email is sent). The event then sits in the event log but doesn't actually trigger until the scheduled time. The field 'process on' on table sysevent holds this date / time.

Events seem to get deleted after exactly one week. Thus the reminder is sent, then the triggering event is deleted, never to be seen again.

I need to change this so that the one week event sets up the next week's reminder.

[martijn3]

sysevent is a table with rotation configured (1Day, 7 times).
This means that events get deleted 7 days after they have been created. Not the luckiest choice if you ask me, but this is how it is. This means that you need to find a way to register the events less than 7 days before they should fire. We're currently facing the same challenge. Options that I see:
* Create a separate table that keeps track of events that are fired somewhere in the future: check the events when they are inserted, delete them if they are in the future and put them back 1 day in advance in the actual sysevent table:
To recreate the event, you will need following information from sysevent:
* name (of the event)
* parm1
* parm2
* table + instance (to get the gliderecord that you need to fire the event for)
With that, you should be able to create another call when it is time.

Not sure what to do with the "old" sysevent record though; maybe it will not fire when you mark it as processed but maybe it is safer to delete it.

[DiStrapps]

Great post, thanks for this.

We're just using this for an email reminder, so we're tempted to simply change the reminder to 6 days and 12 hours for now.

I'll certainly keep your suggestion in mind if we decide that it has to be exactly 7 days (or more).