Oracle BICC Data Extraction Capabilities & Limits

TL;DR

• Bottom line: Oracle BICC (BI Cloud Connector) is the primary mechanism for bulk outbound data extraction from Oracle Fusion Cloud Applications. It extracts data from pre-built Public View Objects (PVOs) into compressed CSV files stored on UCM or OCI Object Storage. Use it for scheduled batch extraction of high-volume analytics and integration data. [src1, src2]
• Key limit: 5GB maximum file size per extracted CSV — files exceeding this are silently truncated while the job is marked successful, delivering incomplete data with no error indication. Configure split file size to 1-2GB to stay safe. [src2, src4]
• Watch out for: The 5GB silent truncation is the single most dangerous BICC behavior. BICC reports the job as completed successfully even when output files are incomplete. Always validate row counts post-extraction. [src4]
• Best for: Scheduled bulk extraction of Oracle Fusion data (ERP, HCM, SCM, CX) for data warehousing, analytics, and integration pipelines exceeding 100,000 records/day. [src1, src7]
• Authentication: Oracle Fusion Cloud SSO credentials with ESS Administrator + BIA_ADMINISTRATOR_DUTY + OBIA_EXTRACTTRANSFORMLOAD_RWD roles; JWT token authentication available for API-driven scheduling. [src1, src8]

System Profile

Oracle BICC is a native data extraction tool embedded in Oracle Fusion Cloud Applications (ERP, HCM, SCM, CX, and Procurement). It provides pre-built data stores called "offerings" that map to functional areas. Each offering contains one or more Public View Objects (PVOs) — specifically, ExtractPVOs designed for bulk extraction efficiency. BICC is NOT a general-purpose API — it is purpose-built for scheduled, high-volume outbound data movement to external systems. This card covers BICC extraction only (outbound). For inbound data loading, see the FBDI card. [src1, src7]

API Surfaces & Capabilities

BICC is not a traditional API — it is a managed extraction service with a console UI, SOAP API for scheduling, and REST API for job management. Data is extracted from pre-built PVOs and written to storage targets as compressed CSV files. [src1, src2, src4]

Rate Limits & Quotas

Per-Extract Limits

Scheduling Limits

Storage Limits

Authentication

BICC requires Oracle Fusion Cloud credentials with specific roles provisioned. For API-driven scheduling, JWT token authentication is available. [src1, src8]

Authentication Gotchas

• Three separate roles required: ESS Administrator (scheduling), BIA_ADMINISTRATOR_DUTY (BICC operations), and OBIA_EXTRACTTRANSFORMLOAD_RWD (file download from UCM). Missing any one silently reduces capabilities without clear error messages. [src1]
• For OCI Object Storage target, the BICC service account also needs OCI IAM policies granting manage objects in compartment on the target bucket — a separate permission layer from Fusion roles. [src8]
• SSO-enabled environments require OAuth 2.0 or JWT authentication for API access — basic auth is blocked. Configure an API Authentication Provider in Security Console. [src8]

Constraints

• 5GB silent truncation: BICC marks the extraction job as successful even when a CSV file is truncated at 5GB. There is no error, no warning, and no indication of data loss. You must independently validate row counts post-extraction. [src2, src4]
• ExtractPVOs only for integration: OTBI reporting PVOs are visible in BICC but are NOT designed for bulk extraction. Using them causes severe performance degradation — up to 10x slower — and may cause Fusion performance issues. [src7]
• No real-time capability: BICC is batch-only. Minimum practical interval is 4 hours. For sub-minute latency, use Oracle ERP Cloud REST API or Business Events. [src1, src4]
• CSV+gzip only: Output format is compressed CSV exclusively. No JSON, XML, Avro, or Parquet output. [src2, src5]
• One extract job per offering at a time: Cannot run two extracts of the same offering concurrently. A second request queues behind the running job. [src1]
• Incremental requires LastUpdateDate: For incremental extraction to work, the selected PVO columns must include LastUpdateDate or equivalent temporal columns. Not all PVOs support incremental extraction. [src7]
• No cross-offering transactional consistency: Extracting from multiple offerings runs as separate jobs with no snapshot isolation between them. [src1]

Integration Pattern Decision Tree

START -- Need to extract bulk data from Oracle Fusion Cloud
|-- What's the data volume?
|   |-- < 1,000 records/day
|   |   |-- Need real-time? --> REST API (different card)
|   |   |-- Batch OK? --> BICC works but may be overkill
|   |-- 1,000-100,000 records/day
|   |   |-- BICC is the right tool
|   |   |-- Use incremental extraction to minimize volume
|   |-- > 100,000 records/day
|   |   |-- BICC is required -- REST API cannot handle this volume
|   |   |-- Configure split file size = 2GB, parallel degree = 8
|   |   |-- Validate row counts post-extraction (5GB truncation risk)
|-- What's the target system?
|   |-- Oracle ADW / OCI Data Lakehouse
|   |   |-- Use OCI Object Storage target (native integration)
|   |-- Third-party data warehouse (Snowflake, BigQuery, Redshift)
|   |   |-- OCI Object Storage --> external stage or S3-compatible fetch
|   |-- On-premise data warehouse
|   |   |-- UCM WebDAV download or OCI Object Storage with VPN
|-- Extraction frequency?
|   |-- Once (initial load) --> Full extract, split at 2GB, 20h+ timeout
|   |-- Daily --> Incremental extraction with prune time
|   |-- More frequent than daily --> Minimum 4h interval recommended
|-- Functional areas?
|   |-- Financials --> Financial Analytics offering
|   |-- Procurement --> Procurement Analytics offering
|   |-- HCM --> HCM Analytics offering
|   |-- Cross-functional --> Multiple offerings (no transactional consistency)

Quick Reference

Step-by-Step Integration Guide

1. Configure BICC external storage target

Set up OCI Object Storage as the extraction target (recommended over UCM for new deployments). [src3, src8]

1. Log into Oracle Fusion Cloud as admin
2. Navigate to: Tools > BI Cloud Connector
3. Go to: Manage Extracts > Configure External Storage
4. Select: Oracle Cloud Infrastructure Object Storage
5. Enter: Tenancy OCID, User OCID, Fingerprint, Private key (PEM), Region, Namespace, Bucket name
6. Test Connection > Save

Verify: Navigate to Manage Extracts > External Storage tab. Status should show "Connected".

2. Select data store offerings and PVOs

Choose the functional area and specific view objects for extraction. Use ExtractPVOs only. [src1, src7]

1. In BICC Console: Manage Extracts > Select Offerings
2. Choose offering (e.g., "Financial Analytics")
3. Select specific ExtractPVOs (avoid OTBI PVOs)
4. Select required columns (include LastUpdateDate for incremental)
5. Set split file size: 2GB
6. Set parallel degree: 4-8

Verify: Selected PVOs appear under the offering with column selections saved.

3. Run initial full extract

Run the first full extraction to establish the baseline dataset. [src1, src2]

1. In BICC Console: Manage Extracts > Create Extract
2. Select offering, Extract type: Full
3. Storage target: OCI Object Storage
4. Timeout: 20 hours (for large initial loads)
5. Click: Submit > Monitor under Monitor Extracts

Verify: Job status shows "Completed". Download manifest and verify row counts match expected totals.

4. Set up incremental extraction schedule

Configure recurring incremental extracts for ongoing data sync. [src1, src7]

1. In BICC Console: Manage Extracts > Schedule
2. Extract type: Incremental
3. Recurrence: Daily (or every 4+ hours)
4. Prune time: 2 hours
5. Start time: During Fusion maintenance window

Verify: Scheduled job appears under Monitor Extracts. After first scheduled run, incremental files contain only changed records.

5. Download and validate extracted files

Retrieve files from OCI Object Storage and validate completeness. [src5, src6]

# List extracted files in the BICC bucket
oci os object list --bucket-name bicc-extracts --prefix "data/" --output json

# Download manifest and data files
oci os object get --bucket-name bicc-extracts --name "data/manifest.json" --file manifest.json

# Validate row count matches manifest
MANIFEST_COUNT=$(jq '.rowCount' manifest.json)
ACTUAL_COUNT=$(zcat extracted_file.csv.gz | wc -l)
echo "Manifest: $MANIFEST_COUNT, Actual: $((ACTUAL_COUNT - 1))"

Verify: Manifest row count equals actual CSV row count minus 1 (header). If actual is lower, file was truncated.

Code Examples

Python: Download and validate BICC extracts from OCI Object Storage

# Input:  OCI config, bucket name, extract prefix
# Output: Downloaded CSV files with row count validation

import oci  # oci>=2.119.0
import gzip
import json
import os

def download_bicc_extract(config_file, bucket_name, prefix, output_dir):
    """Download BICC extract from OCI Object Storage and validate."""
    config = oci.config.from_file(config_file)
    object_storage = oci.object_storage.ObjectStorageClient(config)
    namespace = object_storage.get_namespace().data

    objects = object_storage.list_objects(
        namespace, bucket_name, prefix=prefix
    ).data.objects

    manifest = None
    csv_files = []

    for obj in objects:
        local_path = os.path.join(output_dir, os.path.basename(obj.name))
        response = object_storage.get_object(namespace, bucket_name, obj.name)
        with open(local_path, "wb") as f:
            for chunk in response.data.raw.stream(1024 * 1024):
                f.write(chunk)
        if obj.name.endswith("manifest.json"):
            with open(local_path) as f:
                manifest = json.load(f)
        elif obj.name.endswith(".csv.gz"):
            csv_files.append(local_path)

    # Validate row counts against manifest
    if manifest:
        for csv_path in csv_files:
            with gzip.open(csv_path, "rt") as f:
                actual_rows = sum(1 for _ in f) - 1  # subtract header
            expected = manifest.get("rowCount", "unknown")
            status = "OK" if actual_rows >= int(expected) else "TRUNCATED"
            print(f"{os.path.basename(csv_path)}: expected={expected}, actual={actual_rows} [{status}]")
    return csv_files

Python: Trigger BICC extract via SOAP API

# Input:  Oracle Fusion SOAP endpoint, credentials, offering name
# Output: Extract job ID for monitoring

import requests  # requests>=2.31.0
from xml.etree import ElementTree

def trigger_bicc_extract(fusion_url, username, password, offering_name):
    """Trigger a BICC incremental extract via SOAP API."""
    soap_url = f"{fusion_url}/biacm/ws/BIACMService"
    soap_body = f"""<?xml version="1.0" encoding="UTF-8"?>
    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                      xmlns:typ="http://xmlns.oracle.com/apps/biacm/types">
      <soapenv:Header/>
      <soapenv:Body>
        <typ:submitExtractRequest>
          <typ:offeringName>{offering_name}</typ:offeringName>
          <typ:extractType>INCREMENTAL</typ:extractType>
        </typ:submitExtractRequest>
      </soapenv:Body>
    </soapenv:Envelope>"""

    response = requests.post(
        soap_url, data=soap_body,
        headers={"Content-Type": "text/xml; charset=utf-8"},
        auth=(username, password), timeout=120)
    response.raise_for_status()
    root = ElementTree.fromstring(response.text)
    job_id = root.find(".//{http://xmlns.oracle.com/apps/biacm/types}jobId")
    return job_id.text if job_id is not None else None

cURL: Monitor BICC job status

# Input:  Oracle Fusion URL, credentials, job ID
# Output: Job status (RUNNING / COMPLETED / FAILED)

# Check job status
curl -s -u "bicc_user:password" \
  "https://your-instance.fa.us2.oraclecloud.com/biacm/api/v1/jobs/${JOB_ID}/status" \
  -H "Content-Type: application/json"

# List all BICC files in OCI Object Storage bucket
oci os object list --bucket-name bicc-extracts --prefix "data/" --output table

# Check for files approaching 5GB truncation limit
oci os object list --bucket-name bicc-extracts --prefix "data/" \
  --output json | jq '.data[] | select(.size > 4000000000) | {name, size}'

Data Mapping

BICC Output File Structure

Data Type Gotchas

• Date/time values are extracted in UTC regardless of Fusion user timezone settings. Target systems must handle UTC-to-local conversion. [src2]
• Number fields with high precision may lose precision in CSV serialization. Validate decimal places in target. [src5]
• Multi-byte characters (CJK, Arabic) in CSV are UTF-8 encoded. Ensure target systems parse gzipped CSV with UTF-8 encoding explicitly. [src2]
• NULL vs empty string: BICC represents NULL as an empty field in CSV. This is indistinguishable from an actual empty string without schema metadata. [src5]

Error Handling & Failure Points

Common Error Conditions

Failure Points in Production

• 5GB silent truncation delivering incomplete data: BICC marks jobs as "Completed" even when CSV output is truncated at 5GB. No error is logged. Fix: set split file size to 2GB; implement post-extraction row count validation. [src2, src4]
• Extract timeout on initial full load: Default 10-hour timeout insufficient for large VOs. Fix: increase timeout to 24+ hours; partition extraction by ledger/business unit. [src7]
• UCM storage exhaustion blocking all extracts: BICC files on UCM never auto-clean. Fix: implement automated cleanup via UCM WebDAV API; or migrate to OCI Object Storage with lifecycle policies. [src3]
• Stale incremental baseline after offering reset: Resetting an offering's last extract date clears the incremental baseline, causing the next "incremental" to extract everything. Fix: monitor row counts after any offering reset; temporarily reduce split file size. [src7]
• OTBI PVO causing Fusion performance degradation: Teams selecting OTBI reporting PVOs instead of ExtractPVOs. Fix: audit PVO selections -- ExtractPVO names follow *ExtractPVO or *BICVO pattern. [src7]

Anti-Patterns

Wrong: Using OTBI reporting PVOs for BICC extraction

-- BAD: Selecting OTBI PVO for bulk extraction
-- These PVOs join transactional tables, degrade Fusion performance for all users
Selected PVO: FscmTopModelAM.FinancialAnalysisAM.TransactionHeaderPVO
Result: 10x slower extraction, Fusion UI sluggish

Correct: Use designated ExtractPVOs

-- GOOD: Use the purpose-built ExtractPVO for the same data
-- ExtractPVOs read from denormalized views optimized for bulk extraction
Selected PVO: FscmTopModelAM.FinExtractAM.ApInvoicesExtractPVO
Result: Fast extraction with minimal Fusion performance impact

Wrong: Setting split file size to 5GB

-- BAD: Maximizing split size to reduce file count
-- Split file size: 5GB
-- A PVO producing 5.1GB will be silently truncated to 5GB
-- You lose data with a "Completed" status and no error

Correct: Set split file size to 2GB with post-extraction validation

-- GOOD: Keep split size well under the 5GB ceiling
-- Split file size: 2GB
-- A 5.1GB extraction produces three files: 2GB + 2GB + 1.1GB
-- All data preserved, no truncation risk
-- Always compare manifest rowCount vs actual CSV row count

Wrong: Running BICC extracts every 30 minutes

-- BAD: Treating BICC like a real-time integration
-- Schedule: Every 30 minutes
-- Previous extract may not finish, queue buildup,
-- Fusion performance degrades under continuous extraction load

Correct: Use 4+ hour intervals for BICC; REST API for real-time

-- GOOD: Right tool for the right interval
-- BICC schedule: Every 4-6 hours (or daily for most use cases)
-- For sub-hour data needs: Use Oracle REST API
-- For real-time events: Use Oracle Business Events / webhooks

Common Pitfalls

• Not validating row counts post-extraction: BICC's 5GB truncation is silent. Every extraction pipeline must compare manifest row counts against actual CSV row counts. Automate this check. [src2, src4]
• Selecting unnecessary columns from PVOs: Every additional column increases row width and file size, increasing truncation risk. Select only needed columns. [src2]
• Ignoring prune time for incremental extracts: Too narrow (0h) risks missing records changed during extraction. Too wide (48h) causes excessive re-extraction. Recommended: 2-4 hours. [src7]
• Running initial full load during business hours: Full extracts consume significant Fusion resources. Schedule during weekends or maintenance windows. [src1, src4]
• Not cleaning up UCM storage: BICC files on UCM never auto-delete. Full UCM blocks ALL BICC extracts across all offerings. Implement cleanup schedule or migrate to OCI Object Storage. [src3]
• Assuming cross-offering consistency: Extracting from multiple offerings simultaneously does NOT guarantee snapshot consistency. Implement reconciliation logic in your target system. [src1]

Diagnostic Commands

# Check OCI Object Storage for BICC extract files
oci os object list --bucket-name bicc-extracts --prefix "data/" --output table

# Validate extracted file sizes (check for files approaching 5GB)
oci os object list --bucket-name bicc-extracts --prefix "data/" \
  --output json | jq '.data[] | select(.size > 4000000000) | {name, size}'

# Download and inspect manifest for row counts
oci os object get --bucket-name bicc-extracts \
  --name "data/manifest.json" --file /tmp/manifest.json
cat /tmp/manifest.json | jq '.'

# Count rows in extracted CSV to detect truncation
zcat extracted_file.csv.gz | wc -l

# Check BICC job status via Fusion REST
curl -s -u "admin:password" \
  "https://your-instance.fa.us2.oraclecloud.com/biacm/api/v1/jobs?status=RUNNING" \
  -H "Accept: application/json" | jq '.'

Version History & Compatibility

When to Use / When Not to Use

Important Caveats

• The 5GB silent truncation is the single most critical risk in any BICC integration. Every BICC pipeline MUST include post-extraction row count validation. This is not optional. [src2, src4]
• BICC is outbound-only. It cannot write data back into Oracle Fusion. For bidirectional sync, you need BICC (outbound) + FBDI or REST API (inbound). [src1]
• Extraction performance varies significantly based on Fusion instance load, PVO complexity, and concurrent user activity. [src4]
• OCI Object Storage is the recommended storage target for all new BICC deployments as of 25B. UCM remains functional but Oracle is investing in OCI OS features. [src3]
• BICC PVO coverage is not uniform across Oracle Fusion modules. Some newer modules may have limited ExtractPVO availability. [src1, src7]
• Rate limits and file size limits are subject to change with Oracle quarterly releases. Always verify against current release documentation. [src1, src2]