Oracle Fusion data, from discovery to production — in about two months.
Start with a free SQL editor to discover your Fusion data. Map your EBS R12 queries to the PVOs you need. Deploy a generated pipeline into your own AWS, Azure or GCP — and monitor every run. On average, teams go from discovery to a production pipeline in about two months.
FROM gl_ledgers
FETCH FIRST 100 ROWS ONLY
-- runs through BI Publisher, results in seconds
| NAME | LEDGER_CATEGORY_CODE | CURRENCY_CODE |
|---|---|---|
| US Primary Ledger | PRIMARY | USD |
| UK Primary Ledger | PRIMARY | GBP |
| US Secondary (IFRS) | SECONDARY | USD |
WHERE Status = 'ACTIVE'
LIMIT 100
-- the exact PVO your pipeline delivers, via BICC
| SUPPLIERID | SUPPLIERNAME | STATUS |
|---|---|---|
| 300000101134 | Acme Corp | ACTIVE |
| 300000203847 | Global Industries | ACTIVE |
SELECT ai.invoice_num, ai.invoice_amount, pv.vendor_name
FROM ap_invoices_all ai JOIN po_vendors pv
ON pv.vendor_id = ai.vendor_id
| R12 TABLE | FUSION PVO | MODULE |
|---|---|---|
| AP_INVOICES_ALL | InvoiceHeaderExtractPVO | Payables |
| PO_VENDORS | SupplierExtractPVO | Procurement |
? "bill rate"
-- 615K described columns across 4,545 PVOs
| PVO | COLUMN |
|---|---|
| BillingTransactionExtractPVO | PjbBillTransactionsBillRate |
| RevenueDistributionExtractPVO | RevenueDistributionPEOBillRate |
| InvoiceDistributionExtractPVO | InvoiceDistributionPEOBillRate |
- DiscoverExplore tables & PVOs in the SQL editor
- Map R12Turn R12 queries into selected PVOs & YAML
- DeployGenerated kit, customized, in your cloud
- MonitorAlerts, delivery checks, row-count reports
SQL Editor
Free. Query Fusion tables through BI Publisher and PVOs through BICC, find any column, or paste R12 SQL to find its PVOs — in the browser or on the desktop.
Explore the editor →PVO Selector
Find the right PVOs from 4,545 — from R12 queries, tables or a column name — and pick the columns. Your selection becomes the YAML model.
See the selector →Deployment
Select your PVOs and get a deployment kit for AWS, Azure or GCP — about 90% ready, fully customizable, monitored, and running entirely in your cloud.
How we deploy →One editor, both ways into Fusion data
Other tools give you table SQL. FusionConvergeX also lets you query the PVOs your data warehouse is built on — and tells you which one holds the column you need.
Table SQL in seconds
Write SQL against Fusion tables and views. Queries run read-only through Oracle BI Publisher with your own credentials — no desktop tools, nothing to install.
FreePVO SQL — only here
SELECT * FROM pvo:… queries the exact BICC extract a pipeline delivers, so what you validate in the editor is what lands in your lakehouse.
"Which PVO has that field?"
Search 615,000 described columns across 4,545 PVOs and 22 modules. Find the source in seconds instead of digging through documentation.
FreeFind PVOs from R12 SQL
Paste an EBS R12 query and see the Fusion PVOs it needs — each R12 table mapped to its PVO and module, ready to add to your model.
FreeSelect exactly the PVOs and columns you need
The hardest part of Fusion data isn't moving it — it's knowing where it lives. The PVO Selector, built on our BICC catalog, turns 4,545 PVOs into something you can search, understand and pick with confidence — and your selection becomes the YAML model and the deployment kit for your cloud.
PVO Explorer
Browse all 4,545 PVOs across 22 modules and their BICC offerings, with 615K columns described in plain language — primary keys and incremental watermark columns flagged.
SQL & base tables behind each PVO
See the Oracle SQL a PVO generates and the Fusion tables it reads. Go from a table you know to the PVO that exposes it — and back.
BICC job builder
Pick PVOs and columns, then generate BICC data stores and jobs from a version-controlled model — including default-off columns other tools silently drop.
Schema versions & diff
Track every PVO's columns across Oracle releases and instances. See what was added, removed or renamed before a quarterly update breaks a load.
Flexfields per environment
Map descriptive flexfield segments per client and instance so custom fields arrive with business names — and removed segments are flagged, not failed.
Star-schema library
489 subject-area star schemas — facts, dimensions and joins across Financials, HCM, SCM and Projects — ready to model your warehouse. Browse the library →
From your R12 queries to a running Fusion pipeline
You already know which data your reports need — it's in years of EBS R12 SQL. FusionConvergeX turns that knowledge into the PVOs, model and incremental loads you need in Fusion.
Identify the PVOs from R12 SQL
Bring your existing R12 queries and reports. We map the EBS tables and columns they use (AP_INVOICES_ALL, PA_EXPENDITURE_ITEMS_ALL, …) to Fusion tables and the PVOs that expose them — and flag what has no Fusion equivalent.
Model it as YAML
The result is a version-controlled YAML model: modules, groups, PVOs, the exact columns, primary keys, watermark columns, delete handling — and the dependencies between groups, which set the load order. Review it in a pull request and ship it through CI/CD; BICC jobs are generated from it, never hand-built.
Incremental, managed outside BICC
We keep each PVO's watermark in our own registry and drive every extract with an explicit time window — so loads don't depend on BICC's cached extract date, full reloads are one command, and stalled watermarks self-heal.
Land it as a star schema
Start from 489 Fusion subject-area star schemas — facts, dimensions and join keys — to shape the warehouse your R12 reports are rebuilt on.
modules: - name: project_accounting groups: - group: projects_l1 depends_on: [enterprise_setup_l0] pvos: - pvo: FscmTopModelAM.PrjExtractAM.PjfBiccExtractAM.ProjectExtractPVO target_table: project primary_key: [ProjectBasePEOProjectId] watermark: [ProjectBasePEOLastUpdateDate] delete_mode: soft columns: [ProjectBasePEOProjectId, ProjectBasePEOSegment1, …] # from R12: PA_PROJECTS_ALL (segment1, name, project_status_code)
Why a model, not clicks
- Every column choice is reviewed and versioned
- Rebuild any BICC job exactly — including default-off columns
- Dependencies live in the YAML (
depends_on) and drive load order automatically - True CI/CD — the same YAML promotes from DEV to TEST to PROD through your pipeline
- Traceability from each Fusion column back to the R12 query that needed it
A true CI/CD pipeline architecture — for your Fusion data
Because the whole pipeline is defined in YAML — PVOs, columns, keys, watermarks, dependencies, schedules and destinations — it lives in git and ships like software. No console clicks, no configuration drift, every change reviewed and reversible.
- CommitAdd a PVO or column in YAML, open a pull request
- ValidateAutomated checks: schema, keys, watermarks, dependency order
- Deploy DEVPipeline builds BICC jobs from the model and runs it
- PromoteSame YAML to TEST and PROD — only environment settings change
- Roll backRevert the commit; jobs are rebuilt exactly as before
Prove the data before you build the pipeline
Most Fusion data projects lose weeks building jobs for PVOs that turn out to be empty, too wide or missing a column. SELECT * FROM pvo:… answers those questions in minutes — against the exact extract your pipeline will run.
-- 1. Is the data really here, and how much? SELECT COUNT(*) FROM pvo:BillingTransactionExtractPVO -- 2. Which columns are actually populated? SELECT * FROM pvo:ExpenditureItemExtractPVO LIMIT 500 -- 3. Does it match what the R12 report showed? SELECT ProjectBasePEOSegment1, ProjectBasePEOName FROM pvo:ProjectExtractPVO WHERE ProjectBasePEOSegment1 = '4588804' -- 4. Will incremental work? Check the watermark SELECT MAX(ProjectBasePEOLastUpdateDate) FROM pvo:ProjectExtractPVO
LastUpdateDate column moves and the primary key is unique — the two things incremental loads depend on.From Fusion to your lakehouse — every run verified
Production-grade extraction built on Oracle's own BICC, delivered to the cloud you already run.
Incremental, tracked outside BICC
Our own per-PVO watermark registry drives an explicit time window on every extract — only what changed is pulled, full reloads are one command, and stalled watermarks self-heal.
Dependencies managed in YAML
Declare depends_on between groups once in the YAML model. PVOs then fire in waves in that order, so reference data lands before the facts that depend on it — and the load stays gentle on your network.
Verified delivery
After every run, each PVO is checked end-to-end. Anything that didn't reach every destination triggers an alert, and you get a per-PVO row-count report.
Multiple environments
Fan the same extract out to DEV, TEST and QA — or any set of destinations — from one pipeline.
Schema change tracking
See which columns Oracle added, removed or changed between releases before they break a downstream job.
Flexfields handled
DFF segments are mapped per client and instance, so custom fields arrive with meaningful names.
Deploy in your cloud — with code you own
Select your PVOs, get a deployment kit that is about 90% done, and customize the rest. Deploy it yourself or with our help — either way everything runs in your account, under your policies, with your keys.
Select your PVOs — get the code to deploy them
Once your PVOs are selected, FusionConvergeX generates a complete deployment kit for AWS, Azure or GCP: infrastructure templates plus the pipeline code, wired to your YAML model. It covers roughly 90% of a production deployment out of the box.
The rest is yours to shape. It's plain, readable code in your repository — adapt it to your naming standards, networking, security policies, target schemas or schedules, and extend it however your organization needs.
- Infrastructure-as-code — landing storage, serverless functions, scheduler, secrets and least-privilege roles (e.g. Terraform, CloudFormation, ARM)
- Extraction & delivery code — BICC job generation, incremental watermark registry, dependency-ordered waves, multi-destination delivery
- Your YAML model + CI/CD wiring — the PVOs, columns, keys and dependencies you selected, ready to validate and promote through your CI/CD pipeline
- Monitoring — failure alarms, per-run delivery checks and row-count reports
- Operator CLI —
fcxandbicc-pipelinecommands for building jobs, firing loads, watermarks and recovery - Runbook — full loads, re-deliveries, rollbacks and day-2 operations
Assess & design
Pick the modules and PVOs from the discovery work, agree cadence (from weekly to every 30 minutes), target platforms and environments.
Provision with infrastructure-as-code
The generated kit creates the landing storage, serverless functions, scheduler, secrets and least-privilege roles in your AWS, Azure, GCP or OCI account — templates you review and adjust first.
Connect Fusion & your lake
Register BICC external storage, store BICC and storage credentials in your vault, and wire delivery to ADLS, S3, GCS, Databricks or Snowflake — one or many environments.
Load the YAML model
The reviewed YAML model — PVOs, columns, keys, watermarks and dependencies — generates every BICC job. No hand-built jobs to drift.
Full load, then incremental
A controlled full load seeds each table, then the watermark registry takes over and incrementals run on schedule in dependency-ordered waves.
Monitor & hand over
Alarms on any failed push, a delivery check and row-count email after every run, telemetry to your lake, and a runbook for your team — with support when you want it.
Run every pipeline task from the command line
The deployment kit ships with the same CLIs we use in production — fcx and bicc-pipeline — so your team can build jobs, fire loads, fix watermarks and check results without opening a console. Script them, schedule them, put them in CI.
# build every BICC job from the reviewed YAML model $ fcx job create-from-yaml --all --model pvo_model.yaml # preview, then apply the schedule for a module $ bicc-pipeline schedule plan $ bicc-pipeline schedule apply # fire an incremental load for a whole cadence bucket $ fcx fire --cadence every_2h # inspect or fix a PVO's watermark $ fcx watermark show ProjectExtractPVO $ fcx watermark seed ProjectExtractPVO "2026-09-01 00:00:00" # full re-extract of one PVO, then check the row count $ fcx backfill ProjectExtractPVO $ fcx rowcount ProjectExtractPVO --date 2026-09-26 # re-send a delivered run to your lake $ bicc-pipeline republish
fcx job create-from-yamlfcx describe <pvo>Generate BICC jobs from YAML; inspect any PVO's columns.bicc-pipeline schedule plan | apply | curatefcx schedule status | enable | disablePlan, apply and pause cadences safely.fcx fire [--cadence]fcx backfillbicc-pipeline runIncremental loads, full reloads, on demand.fcx watermark show | seed | resetOwn the incremental state outside BICC.bicc-pipeline rewind | replay | republishfcx cleanup-schedulesRe-run, re-deliver and tidy up after an incident.fcx rowcountbicc-pipeline status | historyRow counts, run status and history per PVO.Plus project commands to discover PVOs, plan an extraction, generate deployment artifacts and compare schemas across releases.
Oracle Fusion to Azure, Databricks, AWS and Snowflake — every 30 minutes
Finance, projects, HR, procurement, supply chain and tax data flows from Oracle Fusion Cloud into customers' Azure and AWS data lakes, Databricks and Snowflake on a 30-minute incremental cadence — 550 PVOs and around 3 million rows a day. Load order comes from dependencies declared in the YAML model, the same extract fans out to several environments at once, and every run is verified end-to-end with a per-PVO row-count report.
How it compares
| SQL-only tools | Per-row ETL connectors | FusionConvergeX | |
|---|---|---|---|
| Table SQL on Fusion | Yes | No | Yes — free |
| SQL against PVOs | No | No | Yes — free |
| Column-level data dictionary | Limited | Limited | 615K columns |
| Incremental pipelines to your cloud | No | Yes | Yes |
| Dependency-ordered loads (YAML) | No | Varies | Yes |
| Per-run delivery verification | No | Varies | Yes |
| Pricing | Per user | Per row / volume | Flat |
Your data stays in your cloud
Built on Oracle's standard, supported interfaces — no database-level access, no data copied to us.
Start free. Pay for pipelines, never per row.
- Table SQL via BI Publisher
- PVO SQL via BICC
- 615K-column data dictionary
- Query history & CSV export
- 1 tenant, 2 instances
- Everything in SQL Editor
- Incremental PVO pipelines, as often as every 30 min
- Azure, AWS, Databricks, Snowflake
- Dependencies managed in YAML
- Delivery checks & row-count reports
- Schema diff & DFF handling
- 3 tenants, 6 instances
- Unlimited tenants & instances
- Private deployment option
- Monitoring dashboard
- Priority support & SLA
- Custom integrations
Use it online — or on your desktop
Same editor, catalog and pipelines either way. Start in the browser in a minute; install the desktop app when you want a native workspace.
Web app
Nothing to install. Sign up, connect your Fusion instance read-only, and query from any browser.
Open in browsermacOS
Native desktop app for Apple Silicon and Intel Macs. Download from your account after sign-up.
Get the Mac appWindows
Installer and portable versions for Windows 10 and 11 (64-bit). Download from your account after sign-up.
Get the Windows appLearn from teams who extract Fusion data every week
Tested answers to the BICC and PVO problems that cost data teams days.
What actually controls a BICC incremental extract
Why rows keep coming back — and why a “full load” can return 43 rows instead of 225,903.
TroubleshootingORA-00918 on a BICC extract? Curate the columns
How wide PVOs break, and the column-list fix that makes them run.
TroubleshootingColumns missing from your extract? Check isPopulate
The default-off columns that silently disappear when jobs are rebuilt.
Pipelines · ProductionFusion to Azure or Databricks: a production checklist
Ordering, network load, delete detection and verifying every delivery.
Questions
Is the SQL editor really free?
Yes. Table SQL, PVO SQL and the data dictionary are free for one tenant. You only pay when you want automated pipelines into your cloud.
What's the difference between table SQL and PVO SQL?
Table SQL runs directly against Fusion tables and views through BI Publisher and returns in seconds — ideal for ad-hoc questions. PVO SQL (FROM pvo:…) runs a BICC extract of a Public View Object — the same object your data warehouse loads — so you can validate exactly what a pipeline will deliver.
Do I need Oracle admin access?
No. A Fusion user with BICC and BI Publisher access is enough. Everything uses Oracle's standard REST and SOAP interfaces — no database access.
Which clouds can pipelines deliver to?
Azure Data Lake (ADLS Gen2), AWS S3 and the lakehouses built on them, including Databricks and Snowflake. One pipeline can deliver to several environments at once.
What happens if a delivery fails?
Runs are only marked complete when every file reached every destination. Anything else raises an alert within minutes, and the post-run report lists exactly which PVOs need attention.
Which Fusion modules are covered?
All 22 — Financials, Projects, HCM, Procurement, Supply Chain, Manufacturing, Sales, Service and more: 4,545 PVOs in total.
Query Fusion free today. Land it in your lakehouse when you're ready.
Sign up in a minute — connect with your own Fusion credentials, read-only.