When people say "ETL for Oracle Fusion", they usually mean one of three things: file-based bulk loads (FBDI), REST API integration, or HCM Data Loader (HDL) for HR data. Each has a different sweet spot, error model, and performance profile. This guide walks through what they are, when to use each, and the 7-stage pipeline pattern that makes any of them production-ready.
The 7 stages every Fusion data load goes through
- Extract: pull from source system (database, API, flat file).
- Profile: row counts, null rates, distinct value distributions, referential integrity checks.
- Cleanse: trim whitespace, standardise dates/numbers, handle nulls explicitly.
- Map: apply crosswalks (source value → Fusion value).
- Stage: write into the Fusion-required format (FBDI ZIP, HDL .dat file, REST JSON).
- Load: import via FBDI / HDL / REST.
- Reconcile: row counts source vs target, control totals, sample-row verification.
FBDI vs REST vs HDL — when to use each
Pick the wrong protocol and you'll fight the platform every week. Here's the rule of thumb:
- FBDI (File-Based Data Import): bulk loads of historical data, > 10k rows, financial transactions, supplier master, GL journals. Slowest per-row but highest throughput.
- REST: incremental updates, real-time integrations, small batches, custom UIs. Best error visibility — each row gets its own response. Worst at bulk volumes.
- HDL (HCM Data Loader): the only supported way to load HCM master data — workers, assignments, salary, locations. Treat HCM and Financials as different platforms with different ETL stacks.
Patterns that survive production
Anyone can write a one-off load. The patterns that survive 6 months in production all share the same three properties:
- Idempotent. Running the same load twice produces the same result. No duplicate rows, no orphan records.
- Restartable. If a 500k-row load fails on row 312,847, the restart picks up at row 312,848 — not row 1.
- Reconcilable. Every load produces a reconciliation report automatically. Source counts, target counts, control totals, sample rows — all written to a single PDF or Excel.
The 5 mistakes we see most often
- Loading without profiling. Surprises that should have been caught in week 1 surface in week 8.
- Skipping the crosswalk review. Functional leads sign off on data they haven't actually looked at.
- Treating reconciliation as optional. Every load needs a control-total report — non-negotiable.
- Using REST for bulk loads. Death by 100k requests, no rollback story when half land and half don't.
- No cutover rehearsal. The first time you execute the full process is the night of go-live. This always goes badly.
Toolchain you should have in place
- Source connector. Pre-built or custom — but it should handle delta extraction, not just full pulls.
- Profiling layer. Auto-runs on every extract, flags surprises before they reach Stage 4.
- Crosswalk store. A versioned source-to-target mapping table. Owned by functional, accessed by ETL.
- Error workflow. Every reject row gets routed to a human within 24 hours.
- Reconciliation engine. Source vs target counts and control totals, generated automatically.
- Audit trail. Who ran what, when, with what result. Required for SOX.
The Syntra ETL team has run more than 100 enterprise data migrations to Oracle Fusion Cloud. We share what we learn so your migration is faster, cleaner, and more boring than ours were.