Who Is About to Read the Business Logic Behind Your OBIEE Reports?

‍MetaKarta is sponsoring Oracle AI World, October 25 to 28 at The Venetian in Las Vegas. Here is what we're bringing for Oracle customers, partners, and integrators.

Suppose a finance analyst asks an agent for last quarter's net revenue. The agent queries the Oracle database and answers $39.8M. The Oracle OBIEE dashboard the CFO opens every Monday says $41.2M.

Both numbers are correct for the logic behind them. The dashboard applies a net revenue calculation that lives in the RPD, fed by an ODI mapping that reclassifies two order types before the load. The agent read the schema, and the schema holds neither the calculation nor the reclassification.

The definitions your business runs on live in OBIEE's semantic models and the code underneath them

Oracle shops built their reporting on Oracle OBIEE and Oracle Analytics Server, with Oracle Data Integrator (ODI) and PL/SQL underneath. That reporting platform is two products under one name, and each keeps its own semantic model.

The analyses and dashboards descend from Siebel Analytics (and nQuire before it), and they read their logic from the RPD. BI Publisher began in Oracle E-Business Suite as XML Publisher, and its reports read from Publisher data models. A data model can query the RPD's subject areas or run its own SQL straight against the database, and the second path carries logic that never passes through the RPD.

Some teams built mostly on the RPD, some on Publisher, and plenty on both. Where both are in use, net revenue can be defined twice, in two formats, often by two teams, and keeping those definitions in agreement is manual work. Over the years the RPD, the Publisher data models, the load rules in ODI packages, and whatever got added in a PL/SQL script became the working definition of revenue, margin, and headcount.

In many shops the people who built that logic have moved on. The reports still run, so the team leaves them alone, and the logic stays where it was written. The schema an agent reads doesn't contain it.

An analyst who gets a wrong number files a ticket. An agent that gets a wrong number acts on it.

Every road out of OBIEE comes with a rebuild estimate

Some teams are heading to Oracle Analytics Cloud. Others are moving to Microsoft Fabric, Snowflake, or Databricks, or running several of them at once. Each is a reasonable destination, and each arrives with the same default plan: rebuild the semantic model by hand in the new platform's native format.

That work is expensive and slow, and the result is usually slightly wrong, because the definitions get recoded by people working from reports instead of from the original logic. Migrations also fail from the other side. Without a map of what depends on what, a schema change cascades into production before anyone sees it coming.

MetaKarta reads the Oracle estate you already run and stitches it into one lineage graph

MetaKarta harvests each Oracle product with its own bridge: Oracle Database and PL/SQL scripts from 10g to 19c, Oracle Data Integrator from 11.1.1.6 to 12c, and OBIEE 10.x through Oracle Analytics Server 12.2.1.4. The OBIEE and Oracle Analytics Server bridge reads both halves of the platform: the RPD with its analyses and dashboards, and the BI Publisher data models and reports. The connections each bridge captures are then stitched against the harvested database schemas.

A dashboard column traces back through the RPD, and a Publisher report column back through its data model, then through the ODI mapping and the PL/SQL to the source table, at column level. Lineage by design, not by observation. MetaKarta parses the code that defines each transformation, so the trace includes the job that didn't run last quarter.

With both paths in one graph, you can put the RPD's net revenue and the Publisher data model's net revenue side by side and see where their logic splits. That's the comparison teams running both products have been doing by hand, one report at a time.

Lineage, catalog, governance, and semantics read from the same shared metadata repository, so each harvested definition is searchable and carries its version history without a sync job between tools. That repository can itself run on Oracle Database 12c, 18c, 19c, or 23ai.

What agents read decides which number they act on

MetaKarta MCP gives AI applications one server with two toolsets. Metadata Management Tools return governed lineage, catalog, and governance metadata. Semantic Hub Tools return compiled context and deterministic SQL.

Lineage traces from the source to the governed definition the agent consumed, so you can find where a wrong answer came from. Context Sandbox then tests the question against live data and shows the grounding before an agent ever sees it. Test the claim yourself, on your data, with the grounding visible.

Semantic Hub compiles the model you already built into Oracle Analytic Views and the platforms next to Oracle

Semantic Hub, MetaKarta's semantic compiler capability, reverse-engineers the semantic model in the OBIEE RPD and brings it into the shared metadata repository as a governed starting point. You model it in Semantic Hub Language (SHL), an open-source, YAML-based language, reconcile duplicate definitions of the same metric, and version the result in Git.

Then it compiles. One governed model becomes native Oracle Analytic Views, Power BI semantic models, Tableau logical models, Snowflake Semantic Views, and Databricks Metric Views, before any query is issued. Write once, compile anywhere.

The compiled artifacts belong to the platform they run on. We don't sit in your query path. We've already compiled into your database and tools. Remove us tomorrow. Your definitions stay.

The agent in the opening scene reads the compiled definition and returns the number the dashboard shows. Same deterministic answer in both AI and BI with proven accuracy.

What this means for Oracle customers, partners, and integrators

For Oracle customers running OBIEE or Oracle Analytics Server, the first result is a lineage map of your own estate, across the RPD and BI Publisher, and a governed copy of your RPD semantic model, in hand before any migration decision gets made. Oracle Analytic Views is one of the compile targets, so the Oracle platform you run today can receive the same governed definitions as the platforms next to it.

For partners and integrators, scoping a migration can start from a harvested inventory of what exists and what depends on what, including the Publisher reports that often get missed in a dashboard-first estimate, which gives the estimate a fact base. The compiled output is native to each target platform, so the customer owns it when the engagement ends.

MetaKarta comes from nearly 30 years of OEM metadata infrastructure embedded in the products of Microsoft Purview, Informatica from Salesforce, IBM, Oracle, and Qlik Talend. The 400+ native connectors cover Oracle alongside the rest of the estate, from legacy to modern and from on-premises to cloud.

Bring an OBIEE question to the booth

The logic in your RPD, your Publisher data models, your ODI mappings, and your PL/SQL is worth keeping, and agents are about to make it matter more. MetaKarta traces it end to end, governs it once, and compiles it into Oracle Analytic Views and the platforms next to Oracle.

We're at Oracle AI World, October 25 to 28, at The Venetian Convention and Expo Center, booth #1034.

Can't make Las Vegas? Get in touch to learn more about how MetaKarta traces Oracle lineage end to end and compiles your OBIEE semantic model into Oracle Analytic Views and the platforms next to Oracle.

‍