Bursting: Splitting and Delivering Reports at Scale

Explain how BI Publisher's bursting engine splits a single large report into per-recipient documents and delivers each via different channels automatically.

Bursting runs the data model once, splits the result by a key, and delivers a separate document to each recipient.

It's like a mail room that receives one giant stack of company-wide mail, automatically sorts it by addressee, stuffs each person's specific pages into their own envelope, and sends each envelope via whatever method that person prefers (post, courier, or digital) — all without a human manually sorting a single page.

Key Concepts

It is the feature that makes BI Publisher an enterprise tool rather than a template engine.

Without it.

    run the report per customer -> 5,000 submissions
    or one giant PDF -> split and email it by hand

With it.

    one run
      split by CUSTOMER_ID
      -> 5,000 documents, each emailed to its own address

The bursting definition is a query, and this is the part worth understanding.

    SELECT customer_id           AS "KEY",
           'template_invoice'    AS "TEMPLATE",
           'PDF'                 AS "OUTPUT_FORMAT",
           'EMAIL'               AS "DEL_CHANNEL",
           email_address         AS "PARAMETER1",
           'accounts@us.com'     AS "PARAMETER2",
           'Your invoice'        AS "PARAMETER3"
      FROM customers ...

Each row says, for one key: which template, which format, which channel, and the channel's parameters.

So delivery is data. A customer who wants PDF by email and another who wants a fixed-width file by FTP are two rows, not two configurations. Adding a customer changes nothing in the report.

Channels. Email, FTP and SFTP, printer, fax, WebDAV, and the file system.

The template can vary per recipient too, which is how one run produces an English invoice for one customer and a localised one for another.

What to get right.The split key must match the data model's grouping. Bursting by customer requires the XML grouped by customer; otherwise the split produces empty or duplicated documents.

Delivery failures. One bad email address should not stop the run. The job history records per-recipient outcomes, and that list is the thing to monitor — a burst that "completed" with two hundred delivery failures reports success.

Volume. Five thousand documents is five thousand rendering operations and five thousand emails. Schedule it where that load is acceptable, and check the per-master-row query setting first, since that is usually what makes it slow.

What the interviewer is probing.1. "What does a bursting query have to return?" Probing: the mechanics. Stalls: "The data." Moves up: one row per burst key with the delivery method, address, template and locale for that group.

2. "What is the main operational benefit?" Probing: the value. Stalls: "Speed." Moves up: one scheduled run produces and delivers thousands of personalised documents, instead of a job per recipient.

3. "What is the risk you must control?" Probing: the practical warning. Stalls: "None." Moves up: sending the wrong document to the wrong recipient — the burst key and the delivery address must come from the same validated source.

4. "How do you test bursting safely?" Probing: the discipline. Stalls: "In production." Moves up: redirect delivery to an internal address in non-production, because a clone with live addresses will email real customers.