Integrating BI Publisher with OBIEE and E-Business Suite

Explain the common integration patterns connecting BI Publisher with OBIEE subject areas and Oracle E-Business Suite/ERP data sources.

BI Publisher rarely stands alone. It is usually the document engine downstream of a semantic layer or a transactional application.

Using an OBIEE subject area as a BI Publisher data source is like having the same trusted accountant (the RPD) prepare numbers for both the boardroom dashboard and the printed annual report — one source of truth feeding two different output formats, instead of two accountants who might disagree.

Key Concepts

Against an OBIEE subject area. A data model can use a subject area as its source rather than SQL:

    data model source: subject area "Sales"
      -> the data model issues logical SQL
      -> the BI Server applies the model and the security

Which is the important consequence. The report inherits the RPD's definitions and its row-level security.

    raw SQL     you write the joins, and you write the security,
                and they may not match the dashboards
    subject area  one definition of revenue; the user sees their
                own rows automatically

So a pixel-perfect statement produced this way agrees with the dashboard, because both went through the same model. Two definitions of revenue in one organisation is the problem this avoids.

The cost is that you are limited to what the subject area exposes, and the generated logical SQL is less controllable than SQL you write.

Inside EBS. BI Publisher is embedded: a data model with a SQL query or a PL/SQL package, a template, and the whole thing registered as a concurrent program.

    executable -> concurrent program -> submitted from a responsibility

So it appears in the Standard Request Submission screen like any other program, with its parameters. That is how EBS replaced Oracle Reports without users noticing.

Inside Fusion. The same engine, with data models over Fusion's own sources, delivering the statutory documents and payment files.

The pattern across all three. One rendering engine, several places it is embedded, and the same skills — data models, templates, bursting — transfer directly between them.

The choice to state. Use a subject area where the report should agree with the dashboards and inherit their security. Use SQL where the report needs something the model does not expose, or where the performance of hand-written SQL matters — and accept that you now own the security and the definitions within it.

What the interviewer is probing.1. "How does BI Publisher use an OBIEE analysis?" Probing: the integration. Stalls: "It cannot." Moves up: as a data source, so the analysis supplies the data with RPD security applied and BI Publisher supplies the pixel-perfect layout.

2. "Why is that better than a raw SQL data model?" Probing: the argument. Stalls: "It is not." Moves up: it inherits the business model and row-level security, so the formatted report cannot show more than the user may see.

3. "How does it integrate with EBS?" Probing: the practical knowledge. Stalls: "It does not." Moves up: as a concurrent program output type, with the data definition and template registered against the program and managed by responsibility.

4. "What is the security consideration when embedding?" Probing: the depth. Stalls: "None." Moves up: a SQL data model bypasses the RPD entirely, so row-level security must then be enforced in the query itself.