Oracle Fusion Cloud ERP and Google BigQuery integration

What moves between them

Oracle Fusion invoices, purchase orders, payments, and GL journal entries flow into BigQuery on a configurable polling schedule, typically every 5 to 15 minutes. Each record is inserted as a new row in the target BigQuery table, keyed by Oracle's internal object identifiers to avoid duplicates on retry. GL account combinations are preserved as structured columns so BigQuery queries can filter and aggregate by ledger, cost center, and account. The integration is unidirectional: data moves from Oracle Fusion into BigQuery only. BigQuery tables are append-only from the connector's perspective, so historical records are retained for audit and restatement purposes.

How ml-connector handles it

ml-connector stores both OAuth credential sets encrypted and refreshes the Oracle Fusion bearer token when an API call returns 401 Unauthorized. The integration polls the Oracle Fusion REST endpoint on a BullMQ-driven schedule, filtering records by LastUpdateDate to detect new and updated transactions since the last poll. Each invoice, PO, payment, and GL journal is transformed into BigQuery columns: Oracle GL account combinations are mapped to individual columns so analytics queries can GROUP BY account or cost center, invoice lines are denormalized with their parent invoice header details so BigQuery can join and aggregate by supplier or invoice date without additional lookups, and service account JWT signing is automated on every request to BigQuery. Rate limits are not publicly documented for Oracle Fusion, but ml-connector backs off on 429 responses and retries with exponential jitter. Every record inserted carries a ml-connector-generated timestamp and audit ID so failed batches can be identified and replayed without duplicating already-loaded rows.

A real-world example

A mid-market manufacturing company runs Oracle Fusion Cloud ERP for invoicing, procurement, and general ledger. The finance team also uses BigQuery as their central data warehouse for analytics, budgeting models, and BI dashboards. Before the integration, the team exported Oracle Fusion reports weekly, transformed them in scripts, and loaded them into BigQuery staging tables by hand. Reconciliation happened offline in spreadsheets. With Oracle Fusion and BigQuery connected, invoice and PO data flows every 5 minutes, GL journals post automatically after each period close, and the BI dashboards update in real time. Month-end reconciliation now starts with accurate, current data already in BigQuery, and the weekly export-transform-load cycle is gone.

What you can do

• •Stream Oracle Fusion invoices and invoice line details into BigQuery, denormalized for direct BI dashboard consumption.
• •Load purchase orders and their line items with supplier reference and currency details into BigQuery for procurement analytics.
• •Extract GL journal headers and lines with account combinations, cost center codes, and posting status into BigQuery for financial reporting.
• •Authenticate both systems with OAuth 2.0 service account flows, refresh tokens automatically on expiry, and handle Oracle Fusion pod-specific URLs.
• •Poll on a configurable schedule, retry failed batches with exponential backoff, and maintain an audit trail so records can be replayed if a load fails.

Questions

Which direction does data move between Oracle Fusion and BigQuery?

Data flows from Oracle Fusion into BigQuery only. Invoices, purchase orders, GL journals, and payments are extracted from Oracle Fusion and appended to BigQuery tables. BigQuery is the analytics sink, not a source of transactions back into Oracle Fusion. Historical records are kept in BigQuery for restatement and audit purposes.

How does the integration handle Oracle Fusion's pod-specific URLs and lack of webhooks?

ml-connector accepts the full customer pod URL and region from your Oracle Fusion instance configuration, since there is no shared base address. Because Oracle Fusion has no outbound webhooks, the integration polls the REST API on a configurable schedule (typically every 5 to 15 minutes), filtering by LastUpdateDate to detect new and updated transactions since the last run.

What happens if BigQuery returns an error or the service account JWT expires?

ml-connector automatically signs a new JWT with the service account private key and refreshes the access token on expiry (every 3600 seconds). If a BigQuery insert fails, ml-connector retries with exponential backoff and jitter, and every record inserted carries an audit ID so you can identify and replay failed batches without creating duplicates in BigQuery.