What are the pros and cons of using FBDI vs REST API for procurement data migration?

SCM Oracle Fusion Cloud SCM
, , , , , , , ,
1

Our organization is planning a major procurement data migration to Oracle Fusion Cloud SCM 23C - approximately 500K purchase orders, 200K suppliers, and 1.5M requisition lines from our legacy ERP system.

We’re debating between two approaches: traditional FBDI template uploads versus building a custom REST API integration layer. I’ve used FBDI extensively in past projects and know it handles bulk loads well, but our integration team is pushing for REST APIs, claiming better automation and error handling.

What have others experienced with these two migration approaches for large-scale procurement data? Specifically interested in:

  • Bulk load performance and throughput
  • Error handling and retry capabilities
  • Automation potential for ongoing data synchronization
  • Complexity of initial setup and maintenance

Is there a clear winner, or does it depend on specific project requirements? Would love to hear real-world experiences from both camps.

2

We built both from day one. Used FBDI for the cutover weekend migration (historical POs, closed requisitions, supplier master data), then immediately switched to REST APIs for day-to-day operations. The key is understanding that FBDI and REST APIs often use different data structures for the same objects. For example, purchase order FBDI templates might flatten complex relationships into a single row, while REST APIs use nested JSON structures. You need mapping logic for both approaches, which doubles the initial development effort but pays off in flexibility.

3

We went through this exact decision last year for a similar-sized procurement migration. Ended up using FBDI for the initial bulk load (completed 600K POs in about 6 hours) and then REST APIs for ongoing incremental updates. FBDI is unbeatable for raw throughput, but REST gives you much better granular error handling and the ability to implement retry logic. The combination approach worked really well - use each tool for what it does best.

4

Let me share some hard numbers from a recent procurement migration to help inform your decision.

FBDI Bulk Load Performance:

In our 23C environment, we achieved these throughput rates:

  • Suppliers: 25,000 records/hour (relatively simple objects)
  • Purchase Orders: 15,000 POs/hour (more complex with line details)
  • Requisitions: 30,000 requisition lines/hour (simpler than POs)

Your 500K POs would take approximately 33 hours of processing time with FBDI, assuming no errors. Add supplier and requisition migrations, and you’re looking at 50-60 hours total for the bulk load.

REST API Throughput:

Oracle’s published rate limits for procurement REST APIs:

  • 300 requests per minute per user account
  • Each request can contain 1 object (1 PO, 1 supplier, etc.)
  • Practical throughput: ~250 objects/minute accounting for retries and throttling
  • Your 500K POs would take approximately 2,000 minutes (33+ hours) via REST API alone

However, REST API performance varies significantly based on:

  • Network latency between your integration server and Oracle Cloud
  • Payload size (complex POs with many lines process slower)
  • Concurrent API connections (you can parallelize with multiple user accounts)

Error Handling Differences:

FBDI error handling:

  • Batch-oriented: entire batch succeeds or fails
  • Error logs generated post-processing (not real-time)
  • Generic error messages often require multiple re-runs to isolate root cause
  • Failed records must be corrected and re-uploaded in subsequent batches
  • No built-in retry mechanism

Example FBDI error output:


Batch: PO_IMPORT_20250305_001
Status: Failed
Records Processed: 8,247 of 50,000
Error: Invalid supplier ID at line 8248

REST API error handling:

  • Record-level granularity: each API call succeeds or fails independently
  • Immediate HTTP response with detailed error messages
  • Programmatic retry logic possible (exponential backoff, circuit breakers)
  • Failed records can be automatically requeued without manual intervention
  • Comprehensive error details in JSON response

Example REST API error response:

{
  "status": 400,
  "title": "Bad Request",
  "detail": "Supplier ID 'SUP-9999' does not exist",
  "o:errorCode": "SUPPLIER_NOT_FOUND",
  "o:errorPath": "PurchaseOrder.SupplierID"
}

Automation Capabilities:

FBDI automation limitations:

  • Manual template preparation (Excel/CSV formatting)
  • File upload through UI or scheduled SFTP drops
  • Polling required to check batch completion status
  • Error log download and parsing needed for failure analysis
  • Difficult to integrate into CI/CD pipelines

REST API automation advantages:

  • Fully programmatic (no manual file handling)
  • Synchronous response enables real-time decision logic
  • Easy integration with orchestration tools (OIC, MuleSoft, Dell Boomi)
  • Native support in modern programming languages and frameworks
  • Fits naturally into automated testing and deployment pipelines

Complexity and Maintenance:

FBDI setup:

  • Lower initial complexity: download templates, map source data, upload
  • Template structure can change between Fusion releases (maintenance burden)
  • Limited customization options (must follow Oracle’s template structure)
  • Requires manual intervention for each migration batch

REST API setup:

  • Higher initial complexity: authentication, endpoint discovery, payload construction
  • More stable across releases (API versioning protects against breaking changes)
  • Extensive customization possible (transform data to fit your needs)
  • Fully automated execution once built

Recommendation Based on Your Requirements:

For your 500K PO + 200K supplier + 1.5M requisition line migration:

  1. Initial Bulk Migration (Cutover): Use FBDI

    • Fastest throughput for historical data
    • Simpler to prepare and execute under time pressure
    • Your volumes are manageable within a weekend cutover window

  2. Post-Go-Live Synchronization: Use REST APIs

    • Real-time or near-real-time data sync from legacy systems during parallel run
    • Superior error handling for production transactions
    • Better audit trail and monitoring capabilities

  3. Hybrid Architecture:

    • Build FBDI templates for bulk load (2-3 weeks effort)
    • Develop REST API integration layer in parallel (4-6 weeks effort)
    • Use FBDI for cutover, switch to REST for steady-state operations
    • Maintain both capabilities for future data corrections or re-migrations

Key Success Factors:

  • Don’t underestimate FBDI template preparation time - data mapping and cleansing often takes longer than the actual upload
  • REST API development requires skilled integration developers - factor in learning curve if team is new to Oracle Fusion REST APIs
  • Test both approaches in non-production environments with production-volume datasets
  • Document error handling procedures for both methods (playbooks for common failures)
  • Consider Oracle Integration Cloud (OIC) as a middle layer - provides pre-built adapters for both FBDI and REST APIs, reducing custom development

Both approaches are viable for your migration scale. The hybrid strategy gives you the best of both worlds - FBDI’s speed for bulk loads and REST API’s flexibility for ongoing operations.