BICC vs. the New Data Extraction Tool: What's Actually Changing in Oracle Fusion

The Data Extraction tool is designed as the modern, high-performance successor to the Business Intelligence Cloud Connector (BICC). While both tools serve the same core purpose—moving bulk data out of Oracle Fusion for use in downstream systems like data warehouses—they differ significantly in their underlying architecture, performance, and user experience.

The following are the key differences between BICC and the Data Extraction tool:

1. Data Source and Application Load

• BICC: Queries the live transactional database of Oracle Fusion Applications. Because of this, large BICC extracts can compete for resources with the live application, creating high load and potentially impacting transactional performance.

• Data Extraction Tool: Queries a Read-Optimized Data Store (RODS), which is a continuously refreshed replica of the transactional data. This isolation means the tool has near-zero load on the core application database, allowing for faster and more reliable extractions without affecting live users.

2. Performance and Scalability

• Performance: BICC is rated as having "Medium" performance, whereas the Data Extraction tool is rated as "Very High".

• Incremental Support: Both tools support incremental (delta) extracts. BICC has offered this for years against the live database. The Data Extraction Tool also supports full and incremental extracts, but runs them against the replicated RODS layer — meaning incremental extraction adds no additional load to the transactional database, which isn't guaranteed with BICC's live-database queries.

• Execution Models: The new tool supports both synchronous processing for small, immediate requests and asynchronous/batch processing for high-volume scheduled pipelines.

3. Query Language and Schema

• Query Language: BICC uses standard extract definitions often based on BI Publisher-style report definitions. The Data Extraction tool uses BQL (Business Object Query Language), a language purpose-built for this extraction layer.

• Schema Type: BICC utilizes complicated views, while the Data Extraction tool leverages a business object data model with "clean" business and extraction views that simplify data organization.

  The Data Extraction tool is being extended to support data extraction for integration use cases, where SQL queries can be modeled as business object queries against the Read-Optimized Data Store. These extract queries can be defined across multiple entities and include filter conditions to produce the required data shape for integration requirements.

  An AI Agent, Data Extraction Query Transformer, is available to convert SQL statements into extract queries. These extract queries can be executed on demand in synchronous mode within integrations or included as part of the existing asynchronous data extracts.

  For data extraction from Oracle Fusion Applications, use Read-Optimized Data Store based data extraction instead of Oracle Analytics Publisher.

4. User Experience and Interface

• User Interface: BICC uses a legacy UI, while the Data Extraction tool features a modern, Redwood-based experience.

• Ease of Use: The new tool is designed for self-service with a point-and-click interface for selecting pillars (e.g., Supply Chain & Manufacturing), functional areas, and specific attributes.

5. Data Delivery and Coverage

• Output Delivery: BICC can be configured to push data directly to an external Storage Cloud (like an OCI bucket). Currently, the Data Extraction tool's native output lands in Universal Content Management (UCM); moving these files to an OCI bucket requires a custom automation layer.

• Object Coverage: BICC is a proven tool with established coverage across Fusion. The Data Extraction tool is in its initial release phase with growing coverage—Oracle is actively expanding support module-by-module.

  For the full deep dive  see the companion long-form post 

Summary Comparison Table

Feature	BICC	Data Extraction Tool
Data Source	Live Fusion Database	Read-Optimized Data Store (RODS)
Performance	Medium	Very High
Load on Apps	High	Near-zero
Query Language	Extract Definitions	BQL (Business Object Query Language)
UI	Legacy	Redwood
Schema	Complicated views	Clean business object views
Native Output	UCM or External Cloud Storage	UCM (Requires automation for OCI)

Tags : Oracle Fusion Cloud , Oracle RODS,Read-Optimized Data Store,Data Extraction Tool,Oracle BICC,BICC Migration,Oracle Autonomous Data Warehouse,Oracle ADW,BQL

Oracle RODS and the Data Extraction Tool: A Quick Primer

Oracle Fusion Cloud is rolling out a new architecture for bulk data extraction, and if you're running BICC pipelines today, it's worth understanding where this is headed.

RODS (Read-Optimized Data Store) is a continuously refreshed replica of Fusion's transactional data, built on Autonomous AI Lakehouse technology. Oracle GoldenGate replicates changes from the live Fusion database into RODS in near real-time. The point is separation: extraction workloads run against this isolated copy instead of competing with live business transactions on the production database.

Oracle RODS and the Data Extraction Tool: A Practical Guide for Fusion Data Teams

If you run Oracle Fusion Cloud Applications and have spent any time building extraction pipelines with BI Cloud Connector (BICC), you've probably run into the same tension: BICC is reliable, but it's batch-oriented, and large extracts can compete for resources with the live application. Oracle's answer to this is a new architectural layer called RODS (Read-Optimized Data Store), paired with a new customer-facing Data Extraction Tool. This post walks through what both are, how they fit together, and how they compare to the extraction tools most Fusion teams already know.

download copy is available in our linkedin Post - https://tinyurl.com/mv8k6sck

Youtube link our channel post - https://youtu.be/uaQ93AOaxDg?si=PV6XCz7L9ZN87NcN

What Is RODS?

RODS stands for Read-Optimized Data Store. It's built on Oracle Autonomous AI Lakehouse technology and is designed specifically for high-volume, read-intensive workloads. Rather than being a customer-facing product in its own right, RODS is best understood as an architectural layer — a continuously refreshed, read-optimized replica of Fusion's transactional data, sitting alongside the live application database.

The core idea is separation of concerns: extraction workloads should never compete with live transaction processing. Traditionally, reporting and integration tools like BICC, REST APIs, or BI Publisher either query the live Fusion database directly or are constrained to scheduled batch windows. RODS solves this by giving extraction tools an entirely separate environment to query, one that's kept in sync with Fusion but isolated from operational traffic.

FDI or OAC-to-Fusion? Choosing the Right Path for Oracle Fusion Analytics

 If Oracle Fusion Data Intelligence (FDI) comes with prebuilt pipelines, a ready-made star schema, and out-of-the-box dashboards — why would anyone still connect Oracle Analytics Cloud (OAC) directly to Fusion and build reports from scratch?

It's a fair question, and one we hear often from clients evaluating their Fusion analytics roadmap. The honest answer is: both approaches are valid — they just solve different problems. At BizInsight, we've implemented both, and this post breaks down when each one makes sense, so you can make that call with your eyes open instead of defaulting to whichever one a vendor pitched first.

The Two Flavors, in One Sentence Each

An IT Architect's Guide to Implementing the Oracle Analytics Cloud AI Agent

What happens after the Business Analyst hands you the design — ADW views, ODI pipelines, dataset governance, security, and everything the agent needs to actually work in production.

This is Part 2 of a two-part series on OAC AI Agent design. Part 1 — The Business Analyst's Guide — covers discovery, dataset field design, knowledge document structure, and supplemental instructions from the BA perspective. This blog picks up where the BA handoff package ends and focuses on the IT Architect's implementation responsibilities.

If you have read Part 1 of this series, you know that a Business Analyst's job is to define what the OAC AI Agent needs — the questions it must answer, the fields it requires, the policies it must reference, and the vocabulary it must understand. A well-executed BA design produces a complete handoff package: field specifications, derived metric formulas, knowledge document drafts, vocabulary maps, and supplemental instructions ready to paste into OAC.

Download complete Guide from our linkedIn Page

The IT Architect's job is to make that design technically real — and to make it trustworthy at scale. Not just for the first agent, but for every agent the organisation will build after it. That requires a different mindset than building a dashboard or a report. It requires thinking about data lineage, pipeline governance, security boundaries, and the architectural foundation that determines whether AI answers can be trusted at all.

This blog covers the seven technical implementation decisions that separate a production-grade OAC AI Agent from a demo that works once and breaks in real life.

The core risk to understand upfront: An OAC AI Agent will give confident, fluent, well-formatted answers regardless of whether the underlying data is correct, governed, or complete. The agent has no way to tell the user "I am not sure about this number." It answers with the same confidence whether the data is perfect or wrong. The IT Architect's job is to ensure the data behind the agent is never the thing that fails.

What are the three essential components for a successful OAC AI agent?

A successful Oracle Analytics Cloud (OAC) AI Agent is built upon three essential components that function as the actual "product," while the agent itself is merely the container. These three components are:

Oracle OAC AI Agent : The Real Work Is Not Configuring the Oracle Analytics Cloud AI Agent

A Business Analyst's perspective on what actually makes an OAC AI Agent work — and what most implementations get wrong.

Oracle has made it genuinely easy to create an AI Agent in Oracle Analytics Cloud. Navigate to Create, select AI Agent, choose a dataset, paste some instructions, upload a document. You can have an agent running in under twenty minutes.

I know because I built one.

And here is what I learned quickly: the ease of setup is a trap.

The agent I built in twenty minutes could not answer half the questions I asked it in plain English. It answered the same question differently depending on how I phrased it. And when I rephrased those same questions using the exact field names from the dataset, it answered correctly every time.

The agent was not broken. The design was incomplete.

The three components that actually determine whether an OAC AI Agent works

An OAC AI Agent is built from three components — a governed Dataset, a Knowledge Document, and Supplemental Instructions. Oracle's configuration screen makes all three look equally simple to set up. They are not equally simple to design.

The Dataset is not just a table you point the agent at. It is a carefully designed flat view where every field is named in business language, every categorical value is meaningful without a lookup table, and every derived metric is pre-calculated using your organisation's specific business formula. A dataset designed for reporting will work for an AI Agent — but only if it was designed thoughtfully. Most datasets in production Oracle environments were not.

The Knowledge Document is not a policy PDF you upload. It is a retrieval index. The agent does not read it — it retrieves the most relevant chunks when a question touches on policy or business rules. A document written for human reading retrieves poorly. A document written for retrieval — short sections, specific rules, no cross-references, no legal language — retrieves accurately and produces answers that cite the right policy section every time.

The Supplemental Instructions are the bridge between how your business users speak and how your data is structured. Before writing a single instruction, the most valuable exercise a Business Analyst can do is build a vocabulary map — left column is what users say, right column is what the data contains. Every row in that map is a candidate instruction. The 6,000 character limit forces you to prioritise ruthlessly — which is exactly the right discipline.

Who should own this design work?

This is fundamentally a Business Analyst's responsibility — not an IT task. A BA who understands the business domain, can extract requirements from stakeholders, and can translate business language into data specifications is the right person to design all three components. IT implements the dataset in ADW and configures OAC. The BA defines what that implementation must deliver.

I have written a detailed guide covering the full design process — discovery questions, dataset field design principles, knowledge document structure, supplemental instruction frameworks, validation approach, and the IT handoff package a BA should produce.

If you are planning to build an OAC AI Agent — or if you have already built one and it is not performing as expected — the guide is worth reading before you touch the configuration screen again.

Read the full guide here: 

Shriram Gupta is an Oracle Solution Architect at BizInsight Consulting specialising in Oracle Analytics Cloud, Autonomous Data Warehouse, and Oracle E-Business Suite. Subscribe to this blog for practical Oracle implementation insights.

Tags: Oracle Analytics Cloud  |  OAC AI Agent  |  Business Intelligence  |  Oracle EBS  |  OCI GenAI  |  Business Analyst  |  Dataset Design  |  Knowledge Management  |  RAG  |  Supplemental Instructions

A Business Analyst's Guide to Designing OAC AI Agent components That Make It Work

A Business Analyst's Guide to Designing OAC AI Agent components That Make It Work

By Shriram Gupta  |  Oracle Solution Architect  |  BizInsight Consulting

Oracle has made it genuinely easy to create an AI Agent in Oracle Analytics Cloud. Navigate to Create, select AI Agent, choose a dataset, paste some instructions, upload a document. You can have an agent running in under twenty minutes. I know because I built one.

Download complete guide from our linkedin Page

But here is what I learned quickly: the ease of setup is a trap. The agent I built in twenty minutes could not answer half the questions I asked it in plain English. It answered the same question differently depending on how I phrased it. It gave me numbers I could not trust. And it had no idea what a late payment meant in the context of my organisation's AP policy — even though that definition was fundamental to everything the business needed.

The configuration of an OAC AI Agent is not the hard work. The design of the three components that feed it — the Dataset, the Knowledge Document, and the Supplemental Instructions — is where most implementations succeed or fail. And that design work is fundamentally a Business Analyst's responsibility, not an IT task.