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.
How Data Gets Into RODS
Capture — GoldenGate reads changes (inserts, updates, deletes) from the Fusion transactional database's redo logs, without querying live tables directly.
Trail/transport — captured changes are written to trail files and shipped to the target environment.
Apply — a Replicat process applies those changes into the Autonomous AI Lakehouse environment that constitutes RODS.
It's worth being precise with terminology here: Oracle describes this as "near real-time" replication, not literally instantaneous. Log-based CDC inherently introduces some lag — typically seconds to low minutes — between a transaction committing in Fusion and that change being queryable in RODS. For most reporting, analytics, and integration workloads this lag is negligible, but it does mean RODS is not a synchronous mirror, and it's not the right source if you need to reflect a transaction that was committed a second ago.
Where RODS Shows Up Today
RODS isn't a single feature — it's infrastructure that different parts of Fusion are building on top of, at different paces:
Sales / CX: Pipeline Management leverages RODS directly and requires RODS to be enabled in the environment.
HCM: Spectra Services is the HCM data extraction framework built on RODS replication. Customers need to confirm with Oracle's Center of Excellence (CoE) that the Spectra platform, including RODS replication, is provisioned in their pod.
SCM, Financials, and other pillars: rather than a dedicated named feature, these pillars are gaining access to RODS through the general-purpose Data Extraction Tool, which is being extended module by module.
Enter the Data Extraction Tool
If RODS is the storage/replication layer, the Data Extraction Tool is the customer-facing application built on top of it. In Oracle's own Setup Manager it's labeled as a Redwood-based feature for extracting application data from a read-optimized data store, and it's explicitly positioned as a modern alternative — and eventual successor — to BICC.
What Kind of Tool Is This, Really?
It's tempting to reach for familiar analogies, and it's worth being precise about which ones fit:
Not like OTBI or BI Publisher. OTBI and BIP are reporting tools — they exist to present data to humans, as dashboards, ad-hoc analyses, or formatted documents (invoices, payslips, PDFs).
Not like SQL Developer. SQL Developer is a general-purpose SQL client connecting to any Oracle database, running arbitrary SQL, with no built-in object or security model beyond raw grants.
Closest sibling: BICC. Like BICC, the Data Extraction Tool exists purely to move bulk data out of Fusion for downstream systems — data warehouses, integrations, lakehouses. It's extraction-for-systems, not reporting-for-humans.
The key differences from BICC are the query language and the data source: instead of BICC's extract definitions, you write queries in BQL (Business Object Query Language), and instead of querying the live Fusion schema, extracts run against RODS.
The Query Language: BQL
BQL is the query language purpose-built for this extraction layer, replacing the BI Publisher–style report definitions BICC integrations often relied on. Recognizing how much existing investment organizations have in BI Publisher reports and custom SQL, Oracle has also introduced a Data Extraction Query Transformer Agent — an AI-assisted tool that converts existing SQL into BQL and validates the converted query against the target schema before execution. Future releases are expected to add SQL performance assessment, helping teams spot optimization opportunities before migrating.
Building an Extract: The Basic Flow
Creating an extract is largely a point-and-click process within a Redwood page:
Choose your business pillar (e.g., Supply Chain & Manufacturing) and drill into the functional area and object (e.g., Order Management → Sales Orders Extract).
Select the specific fields/attributes to include.
Optionally apply filters to narrow the data set, and rename columns to match downstream requirements.
Choose your output format — CSV (default) or JSON.
Save the extract definition, then either run it on demand, schedule it for recurring execution, or export it between environments.
The tool also supports Descriptive Flexfields (DFFs) and Extensible Flexfields (EFFs), so custom attributes can be included alongside standard Fusion fields — an important detail for any organization with heavily customized Fusion configurations.
Two Execution Models
The Data Extraction Tool supports two distinct execution modes:
Synchronous processing — for smaller data requests, with results returned within the same transaction. Suitable for focused, immediate retrieval.
Asynchronous/Batch processing — for larger volumes, submitted and monitored as a background job. This is the model that matters for scheduled, high-volume pipelines (e.g., a recurring SCM or Financials extract).
What You Get Back
Enabling It
The tool is off by default. To turn it on:
An administrator enables it via Fusion Setup Manager — it currently appears under the Manufacturing offering, and once enabled shows up under Tools.
A Support Request (SR) must be submitted to Oracle, with Category set to Custom Reports and Analytics and Subcategory set to Data Extraction.
Security/role setup (job and duty roles) needs to be completed before use.
Coverage: Growing, but Not Complete
Because the tool is still in its early release phase, coverage across modules and business objects is expanding quarter over quarter rather than complete from day one. As of one recent release, Oracle reported support for over 1,100 business objects, with more than 600 BICC public view objects mapped to equivalents — with the next release expected to push those numbers to roughly 1,650 objects and 900 mapped BICC views, extending across ERP, HCM, SCM, and CX. If you're planning a migration from BICC, checking object-level parity against your existing extract definitions is a necessary first step, not an afterthought.
Getting Data Into OCI Object Storage: The Missing Piece
A natural question for teams migrating off BICC is: "BICC can drop extract files straight into my OCI bucket — can the Data Extraction Tool do the same?"
The answer is subtly different. Unlike BICC, which can be configured to write directly to an external Storage Cloud container, the Data Extraction Tool's native output lands in UCM. Getting the file into your own OCI Object Storage bucket requires building a small automation layer around the tool's REST APIs:
Create the extract definition once, through the Data Extraction Tool UI (name, output format, objects/attributes, filters).
Submit execution via the Batch Processing REST API, authenticated through IDCS OAuth (client ID/secret plus service credentials).
Poll the job until it completes.
Download the resulting file from Fusion/UCM.
Upload it to your OCI bucket using the OCI SDK.
This is a documented, supported pattern — but it's a pipeline you build and own, not something that happens automatically the way BICC's native storage cloud integration does.
Authentication: Still Fusion-Gated
Whether you're calling the Batch API for extraction or trying to automate the whole pipeline end to end, the Data Extraction Tool's APIs are authenticated through Fusion's identity provider (IDCS OAuth) — there is no raw database connection to RODS exposed to customers, and there never will be, by design. RODS is Oracle's internal replication target, not a customer-facing database endpoint. Community reports suggest the token-acquisition flow for fully headless/non-interactive callers is still maturing, so if you're building unattended automation, it's worth confirming the supported OAuth client setup with Oracle Support or your CoE contact rather than assuming a smooth path.
Comparing the Extraction Options
The Data Extraction Tool and BICC solve the same problem — moving data out to other systems — but the newer tool does it by reading from a replicated, isolated data layer (RODS) instead of the live application, using a different query language (BQL) and a REST-driven execution model.
Applying This to a Real Pipeline
Consider a common pattern: two BICC jobs (SCM and Financials), each running every three hours, landing extract files in OCI Object Storage, followed by DBMS Scheduler jobs that load those files into an Autonomous Data Warehouse (ADW), where they're transformed into dimensional tables.
Migrating this pipeline to the Data Extraction Tool would only replace the first hop:
Fusion (SCM + Financials)
→ GoldenGate replication → RODS
→ Data Extraction Tool (BQL query, Batch API) → output in UCM
→ [automation: download from UCM, upload to OCI bucket]
→ DBMS Scheduler jobs (unchanged) → ADW staging → dimensional model
Everything downstream of the extraction hop — DBMS Scheduler jobs, ADW staging tables, dimensional transformation logic — stays structurally the same, since the output format (CSV) is unchanged. What does need rebuilding:
Extract definitions, migrated from BICC's format into BQL (potentially assisted by the Query Transformer Agent).
The delivery hop into OCI, since this isn't native to the new tool and needs a small custom pipeline (Batch API → download → OCI SDK upload).
Object-level coverage verification, to confirm every BICC view object currently in use has a mapped equivalent in the Data Extraction Tool before cutting over.
Given the tool is still early-release and opt-in, a sensible migration approach is to treat it as a pilot: migrate a lower-risk extract first, confirm the OCI delivery pattern works end to end, validate output correctness against the existing BICC extract, and keep BICC running in parallel until confidence is established.
Key Takeaways
RODS is infrastructure, not a product — a GoldenGate-replicated, read-optimized copy of Fusion data built on Autonomous AI Lakehouse technology, designed to keep extraction workloads off the live transactional database.
The Data Extraction Tool is BICC's eventual successor, not a competitor to OTBI or BI Publisher — it's built for moving bulk data to other systems, not for human-facing reporting.
It queries RODS, never the live Fusion tables, and there is no direct database connection exposed to customers — access is always mediated through Fusion's Redwood UI or REST APIs, secured by IDCS OAuth.
Output is CSV or JSON, delivered to UCM — getting files into your own OCI bucket currently requires a custom automation layer around the Batch API, unlike BICC's native storage cloud integration.
Coverage is growing quickly but isn't complete — verify object-level parity against existing BICC extracts before planning a full cutover.
Adoption today is opt-in and early-stage — enablement requires a Support Request, and a phased pilot approach is the safer path for production pipelines.
