BI Publisher bursting is not working, and your finance team is back to manually emailing reports. Bursting is the BI Publisher feature that automatically splits a single report into multiple outputs—one per supplier, one per business unit, one per cost center—and delivers each output to the right recipient via email, FTP, or a content server. When it works, it saves hours of manual distribution. When it breaks, it breaks silently: the report runs successfully, but the bursted outputs never arrive.

I have debugged BI Publisher bursting failures across Oracle Fusion implementations ranging from straightforward AP check printing to complex multi-entity financial statement distribution. The problem almost always falls into one of four categories: delivery channel configuration, bursting query errors, SMTP issues, or template problems.

Problem 1: Delivery Channel Not Configured or Misconfigured

BI Publisher bursting requires a delivery channel to be set up for each delivery method you want to use. If you are bursting via email, the email delivery channel must be configured at the BI Publisher server level. If you are bursting to an FTP server or content server, those delivery channels need their own configuration. A missing or incorrect delivery channel is the single most common cause of bursting failure.

How to check

  1. Navigate to BI Publisher Administration: Navigator > Tools > BI Publisher (or Reports and Analytics > Browse Catalog > Administration).
  2. Go to the Delivery tab. You should see delivery channels listed for Email, FTP, Content Server, and any others your organization uses.
  3. For email delivery, verify the SMTP server settings: server hostname, port number, authentication credentials, and the “From” email address. A common mistake is using an SMTP server that requires TLS on port 587 but configuring BI Publisher to connect on port 25 without encryption.
  4. Test the delivery channel by sending a test email from the BI Publisher administration page. If the test email does not arrive, the delivery channel is the problem.

The fix

For Oracle Cloud (SaaS) customers, the email delivery channel is typically managed by Oracle, but you may still need to configure specific settings through Oracle Support. If your organization uses a custom SMTP relay, submit an SR to configure the relay settings. For on-premises or hybrid deployments, configure the SMTP settings directly in the BI Publisher administration page. Ensure the SMTP server allows relay from the Oracle Fusion application server’s IP address.

Problem 2: Bursting Query Returns No Results or Wrong Results

The bursting definition in BI Publisher includes a “bursting query”—a SQL or data model query that tells BI Publisher how to split the report and where to deliver each piece. This query must return the correct splitting key (e.g., supplier ID, business unit) and the delivery address (e.g., email address) for each split. If the bursting query returns no rows, bursting produces no output. If it returns wrong addresses, the outputs go to the wrong recipients or fail delivery.

Common bursting query issues

  • Splitting key does not match the data model. The bursting query’s splitting key must correspond exactly to a field in the report’s data model. If the bursting query splits by VENDOR_ID but the data model uses SUPPLIER_ID (a common rename in Oracle Fusion), the split will not work. BI Publisher will not find matching records to split on and will generate a single unsplit output or no output at all.
  • Email address column is null. The bursting query returns rows, but the email delivery address column contains null values for some or all rows. This happens when the query joins to a contact table that has no email on record for certain suppliers or employees. BI Publisher skips rows with null delivery addresses without logging an error.
  • Query references a table the BI Publisher user cannot access. In Oracle Fusion, the BI Publisher data model runs under a specific database user context. If the bursting query references tables or views that this user does not have SELECT access to, the query silently returns zero rows.

How to debug

  1. Open the report’s bursting definition in the BI catalog. Navigate to the report, open Properties, and go to the Bursting tab.
  2. Copy the bursting query and run it independently (using the BI Publisher data model SQL execution feature or a test data model) to see what it returns.
  3. Verify that the splitting key values in the query output match the splitting key values in the report data model output.
  4. Verify that every row has a non-null delivery address.

Problem 3: SMTP Configuration and Email Delivery Failures

Even when the delivery channel is configured and the bursting query is correct, the actual email delivery can fail due to SMTP-level issues. These failures are especially tricky because BI Publisher may report the burst as “successful” from its perspective—it handed the email to the SMTP server—but the SMTP server rejected or silently dropped the message.

Common SMTP issues

  • Sender address rejected. The “From” address configured in the BI Publisher delivery channel is not authorized to send through the SMTP server. Many corporate SMTP servers enforce SPF or DKIM validation and will reject emails from unrecognized sender addresses.
  • Attachment size limit. Bursted reports are sent as email attachments (PDF, Excel, etc.). If the attachment exceeds the SMTP server’s maximum message size, the email is rejected. This is common with large reports that burst to PDF—a 50-page PDF per business unit can easily exceed a 10 MB email limit.
  • Recipient address validation. The SMTP server validates recipient addresses and rejects emails to addresses it considers invalid or non-existent. If the bursting query pulls email addresses from stale data (terminated employees, closed supplier contacts), delivery fails for those recipients.
  • TLS/SSL handshake failure. The SMTP server requires encrypted connections, but the BI Publisher delivery channel is configured for plain-text SMTP. Or vice versa: BI Publisher is configured for TLS but the SMTP server does not support it on the configured port.

How to diagnose

Check the BI Publisher job history for the bursting job. Navigate to the report’s job history and look at the delivery status for each bursted output. If the status shows “Delivery Failed,” the error message usually indicates whether it was an SMTP rejection, a connection timeout, or an authentication failure. If the status shows “Delivered” but the email never arrived, the issue is downstream (SMTP server accepted but did not deliver, or corporate email filtering intercepted the message).

Problem 4: Template Errors Causing Bursting Failures

BI Publisher uses RTF, Excel, or XSL-FO templates to format the report output. When bursting, each split of the report is rendered through the template independently. If the template has conditional logic that fails for certain data combinations, the rendering will fail for those splits even if it succeeds for others.

Common template errors

  • Null handling in template fields. The template references a data field that is null for certain splits. For example, a supplier report template that displays the supplier’s tax ID—if some suppliers have no tax ID on record, the template may throw a rendering error for those splits.
  • Conditional logic errors. RTF templates use form fields with XSL expressions for conditional logic. A typo or syntax error in a conditional expression may not surface when the report runs for a single entity but causes rendering failures when the data varies across bursted splits.
  • Template and data model mismatch after changes. Someone modified the data model (added or renamed fields) but did not update the template. The template references fields that no longer exist in the data model. The report runs without bursting (showing blanks for the missing fields), but bursting fails because the rendering engine encounters unresolvable field references during the split processing.

The fix

Test the template with sample data from each bursting split individually. Download the report’s XML data output, filter it to a single split key value, and run it through the template in BI Publisher’s template preview. Repeat for several split key values, especially those where bursting failed. Fix null handling by wrapping field references in null-check conditions. Update the template to match any data model changes.

When to Get Expert Help

BI Publisher bursting involves multiple moving parts—data model, bursting query, delivery channel, SMTP configuration, and template rendering. When the issue spans multiple layers or when bursting works for some recipients but not others, diagnosing the root cause requires someone who understands the entire BI Publisher stack in Oracle Fusion. A Reporting Sprint can audit the bursting configuration end-to-end and resolve the issue in 3–5 business days. You get working automated report distribution, not a manual workaround.