Explain Oracle Reports vs BI Publisher in Oracle Applications

41 / 60

Reportingbeginner

Oracle Reports vs BI Publisher

Understand the evolution from Oracle Reports to BI Publisher as EBS's primary reporting engine

Oracle Reports built the query and the layout as one object, in Reports Builder, stored as a binary file. BI Publisher separates them, and that separation is the entire argument.

BI Publisher's data-model/template separation is like a mail-merge system for business reports: the mailing list (data model) stays the same regardless of whether you're printing formal letters, postcards, or address labels (different templates) — you design each output format once and reuse the same underlying data feed indefinitely.

Key Concepts

    Oracle Reports   one RDF file: query + layout, in one proprietary
                     tool, edited by a developer
    BI Publisher     a data model producing XML
                   + a template formatting it, built in Word or Excel

Why the split matters, concretely. One data model can drive several templates:

    invoice data model
      -> invoice.rtf     a formatted PDF for the customer
      -> invoice.xls     a data dump for the finance team
      -> invoice_eText   a flat file for EDI

Same query, three outputs. In Oracle Reports each of those is a separate report with its own copy of the query — and when the query changes, three copies have to change.

Templates are built in Office. A layout change — move a field, add the logo, change the wording — is made in Word by whoever owns the document, and uploaded.

With Oracle Reports that required Reports Builder, a developer, and a deployment. The difference in who can make a change is what shows up in practice.

Output formats. PDF, Excel, HTML, RTF and eText for fixed-position files, natively. Oracle Reports handled PDF and printing well and the rest badly.

eText is worth naming: it produces fixed-width or delimited files to a specification, which is what bank payment files and EDI formats need.

From a user's point of view nothing changed. A BI Publisher report is registered as a concurrent program and submitted the same way, with the same parameters and the same request screen.

So a migration from Oracle Reports to BI Publisher is invisible to the business, which is why it can be done report by report rather than as a project.

The practical caveat. A complex Oracle Reports layout with intricate formatting does not convert automatically. The query transfers easily; the layout is rebuilt, and a dense statutory form takes real effort.

The answer to "why migrate". Not "it is newer". The data-and-layout separation removes duplicated query logic, the output formats cover what the business actually asks for, and layout changes stop requiring a developer.

What the interviewer is probing.1. "Which would you build a new report in?" Probing: currency. Stalls: "Oracle Reports." Moves up: BI Publisher — Oracle Reports is legacy, and BI Publisher separates data from layout so business users can change the template.

2. "What is the key architectural difference?" Probing: the central point. Stalls: "The tool." Moves up: BI Publisher splits a data model from one or more templates, so one dataset drives PDF, Excel and text output.

3. "What is the migration path for an old report?" Probing: the practical question. Stalls: "Rewrite it." Moves up: reuse the query as the data model and rebuild the layout as an RTF template, which is usually faster than it sounds.

4. "When is Oracle Reports still encountered?" Probing: honesty. Stalls: "Never." *Moves up:* in older EBS instances with heavily customised layouts that nobody has funded replacing.