Need some guidance on BO4 Scheduled Rpts, Events, Chaining, Retries

[Statey603]

We have some Crystal Rpts that are in groups and run daily. The groups consist of 2 to 4 reports each and are chained together using Events. For example, Group A has 3 reports: A-1, A-2 & A-3. Report A-1 is scheduled to run weekly [S,M,T,W,T,F,S] at 9:30pm [essentailly a daily rpt grp]. Report A-1 has an output Event [named A-1 success] for successful execution. Report A-2 is also scheduled to run at the same time but in addition has an input Event [A-1 success] and an output Event [A-2 success]. Report A-3 is also scheduled to run at 9:30pm with Event [A-2 success] as an input. I did NOT configure any Retries when creating the Schedule Instances, leaving the default value of 0.

This past weekend, our Oracle database server went down on Sunday, Aug 17th. On Monday morning, Aug 18, I checked and the first report in each rpt group attempted to run but could not reach the database. The report A-1 history showed a Failure for Aug 17th and the instance had a Next Run Time of 9:30pm on Aug 18th (as expected).

The downstream reports in each group did not execute on Aug 17th. I assume because their input Event was never detected (as expected). The Next Run Time for these reports was still Aug 17th at 9:30pm. I crossed my fingers and all reports executed successfully on Aug 18 at 9:30pm and the Next Run Time for all was back to the expected value.

I was pleased to find that everything ran, but realized that I am not quite sure how schedules and events and retries work. the past date Next Run Time is what has be confused.

On Aug 18 at 9:30pm, would the downstream reports [that showed a Next Run Time of Aug 17] still be waiting for the input trigger event 24 hours later?
Did the Aug 17 scheduled instance expire and increment to the next day?

I am really hoping that someone might be able to shed light on this so I can document this for others.

I appreciate any prior experience, comments, suggestions, etc.


Thanks,
Bill

 

[briangriffin]

You're correct - I'm not sure it's documented anywhere, but if a report is based on an event, and that event does not occur prior to the next scheduled instance, it will skip that event-based instance. In other words, if the server had been down for five days, the report would only run once, not five times.

 

[Statey603]

Thanks. I wish there was documentation to explain the inner workings of Schedules and Events.
I noticed that there is a Retry option when scheduling and as mentioned above used the default of 0. My guess is that this would have kept trying to re-fire the report until either A) the input event was reeived and the report ran or B) the next schedule time was reached.

I still welcome any other words of wisdom concerning these matters.

Thanks again Brian Griffin.
Any relation to my hero Peter Griffin?


- Bill

 

[briangriffin]

Giggity.

I always set retry to 3 with an interval of 360 - no particular reason. But it sometimes pays off - once in awhile I'll come in and there will be a failure notification for one of the overnight reports, but when I look in history it shows success. Some process, probably a backup, has locked the input filestore directory just at the moment the report kicks off, and by the time the retry comes around the directory is available again.