All topics
33 / 55
Publisherintermediate

Scheduling & Job Management

Explain how BI Publisher schedules recurring report jobs, manages job history/retries, and integrates with enterprise schedulers.

Scheduling makes BI Publisher a production system rather than an on-demand tool. Month-end packs, nightly summaries and bursting runs all depend on it.

It's like a well-run kitchen's prep schedule board: each dish (report) has its own prep time slot, someone checks off when it's done (job history), and if a dish burns (job failure), the head chef gets notified immediately and a backup batch is started (retry) rather than the restaurant just running out at dinner service.

Key Concepts

1
A scheduled job captures everything a run needs.
    the report
    parameter values for this schedule
    output formats
    destinations
    the recurrence
2
Recurrence covers once, hourly, daily, weekly, monthly, and custom calendars — including the patterns finance actually asks for, such as the last working day of the month.
3
Job history is what makes it operable. Each run records its status, duration, output and any delivery failures, and the output is retained so it can be retrieved without rerunning.
4
That retention matters: "send me last month's pack again" should not mean regenerating it from data that has since changed.
5
Retries and failure. A failed job can retry automatically. The setting worth thinking about is whether a retry is safe — a report is idempotent, so usually yes; a job that also updates a flag somewhere may not be.
6
Notifications on failure, and this is the one that is skipped. A scheduled job that fails silently is discovered when somebody asks where their report is.
7
Configure a notification on failure — and, for anything that matters, on success too, because a job that stopped being scheduled at all produces no failure notification either.
8
Parameter handling for recurring jobs. A monthly job cannot hardcode the month. Parameters are either relative — driven by a date expression — or supplied by the data model defaulting to the current period.
9
Hardcoding a date in a schedule produces a report that is correct once and wrong every month after.
10
Integration with an enterprise scheduler. BI Publisher's own scheduler handles time-based recurrence. It does not know that the report must wait for the ETL to finish.
11
    BIP scheduler       "at 06:00"
    enterprise scheduler "after the warehouse load completes"
12
Where the dependency matters — and for a report over freshly loaded data it always does — the enterprise scheduler triggers the report through the API, and the BIP schedule is not used. A report scheduled for 06:00 that runs against a load which finished at 07:00 is a report of yesterday's data, and it looks entirely normal.
13
What the interviewer is probing.1. "What does the BI Publisher scheduler give you?" Probing: the purpose. Stalls: "Timing." Moves up: recurring runs with parameters, multiple delivery channels, a job history and the ability to resubmit a failed job.
14
2. "Where do you look when a scheduled job failed?" Probing: the practical skill. Stalls: "Rerun it." Moves up: the job history and its diagnostic log, which separates a query failure from a delivery failure.
15
3. "What is the usual cause of a delivery failure?" Probing: experience. Stalls: "The report." Moves up: the channel, not the report — an expired credential, a full FTP target, or a mail server rejecting the attachment size.
16
4. "What capacity consideration applies?" Probing: the operational angle. Stalls: "None." Moves up: jobs scheduled at the same hour compete with each other and with interactive users, so stagger them.
Use cases:schedulingjob-managementoperations