Extraction pattern & data flow
Every report in this catalog lands in your warehouse the same way. Rather than repeat it on each report page, here is the pattern once: source modules extract through BICC, land raw, are conformed and reconciled to source, then organized into measures and dimensions as star-schema marts that feed dashboards, financial reporting, and the AI Analyst.
The four stages
- Source · Oracle Fusion — GL, Payables, Receivables, Fixed Assets, Tax, Cash, Projects and more, held in Oracle's tables and exposed for extract as PVOs.
- BICC extract — a scheduled bulk extract lands the source tables in your own cloud storage, byte-for-byte, on your tenant.
- Warehouse — raw landing → conformed (cleaned, typed, reconciled to source control totals) → marts (facts plus conformed dimensions).
- Analytics — the same governed models drive dashboards, financial reporting, and a read-only AI Analyst. You own every layer.
Extraction methods
| Method | When to use |
|---|---|
| BICC | Bulk extract of view objects to object storage — the recommended path for an owned warehouse |
| BI Publisher | Pixel-perfect operational output, bursting, schedules |
| OTBI | Ad-hoc self-service on seeded subject areas |
| REST / SOAP | Orchestration and targeted lookups (ESS web service + metadata REST API) |
How it works
Offerings → data stores → view objects (PVOs). Full or incremental (last-extract-date + prune time, default 1440 min). Runtime filters use __DATASTORE__.<column>. Large VOs chunk by creation-date or primary key. Output: .csv data, .mdcsv metadata, .pecsv keys, .mf manifest — landed to OCI Object Storage, UCM, or Cloud Storage Service.
How we integrate
Default build: Python orchestrating the BICC ESS SOAP web service (submitRequest / getRequestState) and the REST metadata API (/biacm/rest/meta/datastores). Versioned, owned by you, no licence. Tool-agnostic — if you run Informatica, Fivetran, ADF, or Matillion we work with it.