This post outlines the architectural evolution from Oracle E-Business Suite (EBS) to Oracle Fusion Cloud regarding how shipping data is processed.
In the legacy EBS environment, the Interface Trip Stop (ITS) serves as a manual batch program that pushes shipment information to inventory, order management, and invoicing. Conversely, Oracle Fusion utilizes an event-driven architecture where background services and Supply Chain Orchestration handle these updates automatically. This modern approach replaces the singular ITS job with multiple scheduled ESS processes to improve scalability and reduce performance bottlenecks. For integration architects, this shift requires a move away from batch monitoring toward managing business events and fulfillment states. Ultimately, the comparison serves as a guide for users transitioning to the cloud by mapping old concurrent programs to their new automated equivalents.
How does Fusion's event-driven architecture improve upon EBS batch processing?
Oracle Fusion’s shift from batch processing to an event-driven, service-oriented architecture represents a major modernization of how data moves between supply chain modules. By replacing the monolithic Interface Trip Stop (ITS)program used in EBS with automated background services, Fusion addresses several historical bottlenecks.
The improvements can be categorized into four key areas:
1. Elimination of Manual Intervention
In Oracle EBS, the Interface Trip Stop (ITS) is a manual batch concurrent program. If it doesn't run or fails, data simply sits in staging tables, often requiring a user to manually re-run the process. In contrast, Fusion’s architecture is fully automated. Once a shipment is confirmed, background services and the Supply Chain Orchestration (SCO) engine trigger the necessary downstream updates across Inventory, Order Management, and Costing without manual triggers.
2. Improved Reliability and Failure Handling
A significant pain point in EBS batch processing is that failures often leave data "stuck" in interface staging tables, making troubleshooting difficult. Fusion improves this through:
Automatic Retry Mechanisms: Background jobs are designed to retry automatically, reducing the need for technical intervention.
Orchestration Monitoring: Instead of checking database flags or interface tables, users monitor orchestration states and fulfillment lines, which provide much clearer visibility into exactly where a process stands.
3. Scalability and Performance
EBS batch processing is subject to performance bottlenecks because one program (ITS) handles multiple heavy tasks—updating shipping, inventory, order management, costing, and invoicing all at once. Fusion breaks these tasks into microservice-like background jobs. For example, specific processes like Process Inventory Transactions and the Cost Accounting Processor handle focused tasks independently, allowing for better scalability and faster overall processing.
4. Real-Time Integration via Business Events
EBS relies on database-level interfaces for integration, which are inherently slower and harder to monitor. Fusion’s event-driven model uses Business Events and REST APIs. This allows for real-time visibility, as integrations (often through Oracle Integration Cloud) can be designed around specific fulfillment orchestration states or business events as they happen, rather than waiting for a batch job to complete.
Summary of Improvements
How do automatic retry mechanisms work in Fusion orchestration?
In Oracle Fusion Cloud, automatic retry mechanisms are a core feature of its event-driven and service-oriented architecture, designed specifically to address the manual bottlenecks found in Oracle EBS.
Based on the sources, these mechanisms function in the following ways:
1. Integration with Background Services
Unlike the manual batch programs in EBS, Fusion processes are broken down into microservice-like background jobs. These services are designed to run automatically. When a transient failure occurs—such as a temporary resource lock or a processing delay—the system is built to re-attempt the task without requiring a user to manually restart a concurrent program like the Interface Trip Stop.
2. Orchestration-Based Processing
The retry logic is embedded within the Supply Chain Orchestration (SCO) and Order Management Orchestrationengines. Instead of data simply getting "stuck" in a staging table (a common problem in EBS), the orchestration engine manages the state of the transaction. If a service fails, the orchestration process can trigger retries to move the transaction to the next fulfillment orchestration state.
3. Reducing Manual Intervention
In EBS, interface failures often required technical teams to manually fix data in staging tables and re-run batch jobs. Fusion’s automatic retries aim to eliminate this "manual intervention" by allowing the system to recover from minor errors independently.
4. Monitoring the Process
While the retries happen automatically in the background, their progress and eventual success or failure are monitored through specific work areas rather than just database tables:
Supply Chain Orchestration Work Area: Provides visibility into the status of supply requests and their orchestration states.
Scheduled Processes (ESS): Shows the status of the underlying background jobs, such as Process Inventory Transactions or the Cost Accounting Processor.
Order Management Fulfillment Lines: Allows users to see if an order line is progressing or if it has encountered an error that requires attention after the retry attempts are exhausted.
By shifting to this automated model, Fusion provides better scalability and higher reliability compared to the batch-dependent architecture of EBS.
