All posts · OIC Integrations

FBDI Automation with OIC: End-to-End Walkthrough

Automating File-Based Data Import so bulk data loads stop being a manual, error-prone chore — using OIC pipelines and Fusion's ESS REST APIs.

Anurag Jangra · February 10, 2026 · 8 min read · ... views

File-Based Data Import (FBDI) is one of the most common ways to bulk-load data into Oracle Fusion — and one of the most commonly left as a manual, error-prone process. Here’s how to fully automate the pipeline using OIC.

What FBDI automation replaces

The manual process: prepare a CSV against the FBDI template, zip it, upload through the Fusion UI, navigate to the ESS scheduled process, submit the import job, wait, check results, handle errors manually. Multiply this by a finance team doing it monthly across five modules and you have a significant operational burden.

The automated pipeline components

1. Data extraction (PL/SQL or REST)

Extract source data from your origin system into the FBDI-expected format. If the source is an Oracle DB, PL/SQL packages are the cleanest approach — they can enforce the template column structure programmatically and handle data validation before the file is even generated.

2. File generation and staging

Generate the FBDI CSV content in OIC using the mapper and stage it to OIC’s File Server. Apply the required ZIP compression using OIC’s native file operations.

3. Upload to Fusion UCM

Fusion expects FBDI files uploaded to Universal Content Management (UCM). Use the Fusion Applications HCM REST API or the Content REST API:

POST /hcmRestApi/resources/latest/erpintegrations
{
  "OperationName": "uploadFile",
  "DocumentContent": "<base64-encoded-zip>",
  "DocumentName": "po_import_20260210.zip",
  "ContentType": "zip",
  "FileType": "FileLoad"
}

4. Trigger the ESS import job

After upload, trigger the scheduled process via the ESS REST API:

POST /ess/esswebapp/api/trigger
{
  "jobDefName": "oracle/apps/ess/scm/po/receiptImport,ImportPOReceipts",
  "paramList": "#NULL,#NULL,<DocumentId>"
}

5. Poll for completion and handle results

Poll the ESS job status endpoint until the job completes (Succeeded, Warning, or Error). On success, retrieve and log the import results. On error, extract the error details and route to a notification step.

Error handling specifics

FBDI errors come in two forms: job-level errors (the job itself failed to run) and record-level errors (the job ran but rejected specific rows). Both need to be surfaced differently. Job-level errors trigger an immediate notification. Record-level errors are logged to a tracking table and included in a daily error summary report.

The payoff

A monthly FBDI load that took a finance analyst half a day to execute and validate becomes a fully automated, scheduled pipeline that runs unattended — with any failures surfaced within minutes rather than discovered during month-end reconciliation.

Think Beyond the Implementation

Questions worth sitting with after reading this

01

Why is this architecture appropriate for this specific context — and where would it be the wrong choice?

02

What assumptions did we make that aren't stated explicitly? What happens if those assumptions are wrong?

03

What would break first if the requirements changed — volume doubled, a third system was added, or the deadline halved?

04

What alternatives did we reject, and why? Was the decision made on evidence — or habit?

AJ
Anurag Jangra
Oracle Cloud PaaS Consultant · OIC & VBCS Specialist

4.5+ years delivering enterprise Oracle Cloud integrations and VBCS applications across manufacturing, IT services, and financial sectors. OCI Certified — writes about real-world OIC, VBCS, SQL, and BI Publisher patterns from production experience.

Chat on WhatsApp