Event-Driven Item Synchronization from Oracle Fusion Product Development Hub to Oracle E-Business Suite

As organizations modernize product data management, Oracle Fusion Product Development Hub (PDH Cloud) is increasingly positioned as the enterprise master for item definitions, while Oracle E-Business Suite (EBS) continues to support downstream execution for manufacturing, inventory, and legacy operational processes.

This hybrid landscape introduces a critical requirement:

Every item created or updated in Fusion PDH Cloud must be reliably and consistently reflected in Oracle EBS.

This blog presents a production-grade, event-driven integration architecture that addresses this requirement using:

• Oracle Fusion Product Development Hub as the single source of truth
• Oracle Integration Cloud as the PaaS orchestration layer
• Oracle Autonomous Transaction Processing (ATP) for validation and error management
• Oracle E-Business Suite PDH as the downstream consumer system

Architectural Principles

Fusion PDH Cloud as the Authoritative Master

All items — across all item classes — are created and maintained in Fusion PDH Cloud. This includes both transactional updates and occasional mass updates. Oracle EBS does not act as a co-master and does not initiate item changes.

This clear ownership model:

• Eliminates bidirectional conflicts
• Simplifies reconciliation
• Establishes a clean system-of-record boundary

Oracle Integration Cloud as the PaaS Control Plane

OIC is used strictly as an integration control plane, responsible for:

• Subscribing to Fusion PDH business events
• Orchestrating REST and database interactions
• Managing retries, fault handling, and tracking
• Providing operational visibility

OIC is intentionally not used for heavy validation or persistence, ensuring integrations remain lean, readable, and supportable.

Oracle ATP as the Validation and Error Management Layer

Oracle ATP is introduced as a decoupled validation and control layer between SaaS and EBS. Its role is critical in this architecture.

ATP is used to:

• Validate item attributes required by EBS
• Apply custom attribute-group mappings between Fusion PDH and EBS PDH
• Enforce enterprise-specific business rules
• Persist processing status and error details
• Support deterministic reprocessing

A centralized GLOBAL_ERROR table is used to log all integration failures, enabling both manual and automated recovery.

End-to-End Integration Flow

 Detailed Integration Flow

Step 1: Item Creation or Update in Fusion PDH Cloud

When a user creates or updates an item in Fusion PDH Cloud, a business event is published. These events are Oracle-supported, versioned, and designed for downstream consumption.

Step 2: OIC Subscribes to PDH Business Events

Using the Fusion Adapter, OIC subscribes to item Create and Update events. At this stage:

• The event payload is captured
• Minimal inspection is performed
• No assumption is made that the payload is complete

This keeps event handling lightweight and resilient.

Step 3: Item Data Enrichment via REST API

Because business events do not contain the full item definition required by EBS, OIC invokes the Fusion REST API: /fscmRestApi/resources/11.13.18.05/itemsV2  (GET)

This call retrieves:

• Complete item attributes
• Item class and lifecycle details
• Attribute groups and extensible attributes

This ensures that downstream systems always receive a current and authoritative item snapshot.

Step 4: Validation and Error Handling in Oracle ATP

The enriched payload is passed to ATP, where validations are performed, including:

• Mandatory attribute checks for EBS
• Custom attribute-group mappings
• Cross-reference and code validation
• Business rule enforcement

All errors are logged in the GLOBAL_ERROR table with:

• Item identifier
• Event type
• Error code and message
• Processing status
• Timestamp

This design prevents transient integration errors from being lost in OIC fault queues.

Step 5: Item Creation / Update in Oracle EBS

For validated records, OIC invokes a PL/SQL wrapper in EBS that calls the supported public API:EGO_ITEM_PUB.Process_Items

This ensures:

• Compliance with EBS PDH business rules
• Proper lifecycle handling
• Supportability during upgrades
• Data integrity across EBS modules

Direct table manipulation is intentionally avoided.

Step 6: Retry and Recovery Strategy

The solution supports two complementary retry mechanisms:

• Manual Reprocessing
  Support teams can correct data issues and re-trigger processing from ATP using batch identifiers.
• Scheduled OIC Reprocessing
  A scheduled OIC job periodically scans ATP for failed records and retries eligible transactions.

This hybrid strategy supports both transactional updates and occasional mass updates without creating retry storms or duplicate processing.

Need help with OIC / ADW/SaaS Integrations/EBS? Contact Bizinsight Cosulting Inc at 
Email us : inquiry@bizinsightinc.com
https://www.bizinsightinc.com/