Integration Styles in OIC Gen 3: Complete Guide with Examples
Integration Styles in OIC Gen 3: A Complete Guide
Oracle Integration Cloud (OIC) Generation 3 provides a flexible platform for connecting Oracle applications, third-party SaaS applications, databases, APIs, files, and on-premises systems. One of the most important decisions when building an integration in OIC is selecting the right integration style.
The integration style determines how an integration starts, how messages are processed, and what type of business scenario the integration is designed to handle. Oracle’s current OIC Gen 3 documentation groups the primary styles into Application, Schedule, and Event integrations.
In this guide, we will understand OIC Gen 3 integration styles, their use cases, differences, examples, and best practices.
What Are Integration Styles in OIC Gen 3?
An integration style defines the mechanism that triggers an integration and establishes the overall model for processing data.
In simple terms, ask:
“What causes this integration to run?”
The answer usually points you toward the appropriate integration style:
- A business application or API request triggers it → Application Integration
- A scheduled time triggers it → Schedule Integration
- A business event published by another integration triggers it → Event Integration
Oracle documentation describes the choice in terms of what starts the integration: a business activity/application change, a schedule or on-demand execution, or an event published by another integration.
Integration Styles Available in OIC Gen 3
The major integration styles are:
| Integration Style | Trigger | Typical Use Case |
|---|---|---|
| Application | Application event or business object | Real-time/API-based integration |
| Schedule | Defined schedule or manual execution | Batch and periodic processing |
| Event | Published business event | Event-driven integration |
Important: Older OIC terminology such as App Driven Orchestration and Scheduled Orchestration is still commonly used in tutorials and projects. In current OIC Gen 3 documentation, these are referred to as Application and Schedule integration styles.
1. Application Integration
An Application Integration is used when an integration needs to be triggered by an application, business event, or business object.
This is the style you would typically choose when an external application needs to invoke OIC through an adapter such as REST or SOAP, or when an application event needs to initiate processing.
Oracle describes application integrations as integrations triggered by an event or business object and notes that they support orchestration capabilities such as Switch, For-Each, Assign, mappings, callbacks, and End actions.
Example
Suppose an organization has an external HR application and Oracle Fusion HCM.
When a new employee is created in the HR application:
External HR Application
|
| REST API
↓
OIC Gen 3
|
| Data Transformation
↓
Oracle Fusion HCM
The integration can:
- Receive the employee request.
- Validate the incoming data.
- Transform the employee information.
- Call Oracle Fusion HCM.
- Return an appropriate response.
Common Use Cases
Application integrations are useful for:
- REST API integrations
- SOAP integrations
- Real-time application-to-application communication
- Employee synchronization
- Customer synchronization
- Order processing
- Invoice processing
- Oracle Fusion integrations
- Third-party SaaS integrations
Key Features
Application integrations can support:
- REST and SOAP triggers
- Synchronous processing
- Asynchronous processing
- Complex orchestration
- Conditional routing
- Loops
- Assign activities
- Data transformation
- Fault handling
- Callbacks
2. Schedule Integration
A Schedule Integration runs based on a defined schedule instead of being triggered by an incoming application request.
This style is particularly useful for batch processing and periodic jobs.
Oracle provides scheduling capabilities that allow integrations to run at defined frequencies or to be executed on demand.
Example: Nightly Invoice Processing
Imagine a retail organization that generates invoice files every night.
The process could look like this:
Invoice Files
|
↓
OIC Scheduled Integration
|
↓
Read & Validate Files
|
↓
Transform Data
|
↓
Oracle Fusion ERP
The integration might be scheduled to run every day at 1:00 AM.
Common Use Cases
Schedule integrations are commonly used for:
- Daily data synchronization
- Payroll processing
- Invoice processing
- File-based integrations
- Data migration
- Scheduled reports
- Periodic database synchronization
- Batch processing
Scheduling Options
Depending on the business requirement, an integration can be scheduled to run:
- Every few minutes
- Hourly
- Daily
- Weekly
- At a specific date and time
- On demand
OIC also provides capabilities for starting, pausing, editing, and monitoring schedule integration runs.
When Should You Choose Schedule Integration?
Choose a Schedule Integration when:
- The process does not need to run immediately.
- Data is processed periodically.
- Files need to be picked up at regular intervals.
- A batch job is required.
- The source system cannot initiate the integration.
3. Event Integration
An Event Integration is designed for event-driven architectures.
Instead of waiting for an API request or a scheduled execution, the integration starts when a business event is published.
Oracle’s OIC Gen 3 documentation explains that event integrations allow events to be created and selected for publishing and subscribing. Events can be defined using JSON or XML schema files.
Example: Supplier Update
Suppose a supplier is updated in an Oracle application.
The business event can trigger OIC:
Oracle Fusion Procurement
|
| Supplier Updated Event
↓
OIC Gen 3
|
↓
Event Integration
/ \
↓ ↓
Notification External System
The downstream systems can then process the event without requiring a traditional scheduled job.
Common Business Events
Examples include:
- Employee created
- Supplier updated
- Purchase order created
- Invoice approved
- Customer created
- Order status changed
The exact events available depend on the applications and integrations involved.
Advantages of Event-Driven Integration
Event-driven architectures can provide:
- Faster response to business changes
- Loose coupling between systems
- Near-real-time processing
- Better scalability for event-based workflows
- Reduced dependence on polling
Application vs Schedule vs Event Integration
Understanding the differences between these styles is essential for OIC developers.
| Feature | Application | Schedule | Event |
|---|---|---|---|
| Trigger | Application/event/business object | Schedule or manual run | Published business event |
| Typical processing | Real-time | Batch | Event-driven |
| API trigger | Yes | No direct incoming trigger | Not the primary model |
| Scheduled execution | No | Yes | No |
| Complex orchestration | Yes | Yes | Integration-dependent |
| Best for | Real-time applications | Periodic jobs | Business events |
| Example | Employee API | Nightly invoice job | Supplier update event |
How to Select the Correct Integration Style
Before creating an integration, ask these questions.
Question 1: Does another application need to call OIC?
If yes, consider an Application Integration.
Example:
CRM → REST API → OIC → ERP
Question 2: Should the integration run at a specific time?
If yes, consider a Schedule Integration.
Example:
Every night at 1 AM
↓
OIC Integration
↓
Process invoice files
Question 3: Should the integration react to a business event?
If yes, consider an Event Integration.
Example:
Supplier Updated
↓
Business Event
↓
OIC
↓
Notify downstream systems
Step-by-Step Example: Creating an Application Integration
Let’s consider a simple employee integration.
Step 1: Open Integrations
Navigate to the Integrations section in your OIC Gen 3 instance and select the option to create a new integration.
Step 2: Select the Integration Style
Choose:
Application
Depending on the OIC interface and documentation terminology, you may see application-driven terminology associated with this style.
Step 3: Configure the Trigger
For example, select a REST Adapter as the trigger.
Define the request structure.
Example:
{
"employeeName": "John Smith",
"department": "Finance",
"email": "[email protected]"
}
Step 4: Add Business Logic
Use the integration canvas to:
- Validate the request
- Transform the payload
- Add conditions
- Perform lookups
- Handle errors
Step 5: Configure the Target
Add an Oracle Fusion HCM Adapter or another appropriate target connection.
Step 6: Map the Data
Map the incoming employee fields to the target application’s required fields.
For example:
employeeName → Person Name
department → Department
email → Email Address
Step 7: Test the Integration
Send a test request and verify:
- Trigger execution
- Mapping
- Target invocation
- Response
- Error handling
Step 8: Activate and Monitor
Once testing is successful, activate the integration and monitor its execution from the OIC monitoring interface.
Typical OIC Gen 3 Architecture
A common enterprise integration architecture can look like:
Source Systems
|
+---------+---------+
| |
REST SOAP
| |
+---------+---------+
|
↓
OIC Gen 3
|
+---------+---------+
| |
Transformation Business Logic
| |
+---------+---------+
|
↓
Target Systems
|
+----------+----------+
| |
Oracle Fusion Database
OIC provides adapters, mapping capabilities, integration logic, and monitoring to connect these systems.
Real-World Examples
Example 1: Employee Synchronization
Requirement: Whenever an employee is created in an external HR system, create the corresponding employee in Oracle Fusion HCM.
Recommended style: Application
HR System
↓
REST
↓
OIC
↓
Transformation
↓
Fusion HCM
Example 2: Daily Financial File
Requirement: Process financial files received every night.
Recommended style: Schedule
File Server
↓
Scheduled OIC Integration
↓
Read File
↓
Validate
↓
Transform
↓
Fusion ERP
Example 3: Supplier Event
Requirement: Notify a downstream application when supplier information changes.
Recommended style: Event
Supplier Update
↓
Business Event
↓
OIC Event Integration
↓
Downstream Application
Best Practices for OIC Integration Design
Choosing the integration style is only the first step. Good integration design also requires proper architecture and operational practices.
1. Choose the Trigger Carefully
Always identify what actually starts the business process.
Do not use a scheduled integration simply because it is easier to build if the business requirement is genuinely event-driven or real-time.
2. Keep Integrations Modular
Avoid creating one extremely large integration containing every business process.
Instead, divide functionality into logical, reusable integrations where appropriate.
3. Use Appropriate Error Handling
Implement proper fault handling and consider:
- Business faults
- System faults
- Retry requirements
- Notifications
- Logging
- Error recovery
4. Validate Data Early
Validate incoming data before invoking downstream systems.
This helps prevent unnecessary calls and makes troubleshooting easier.
5. Use Lookups for Maintainable Value Mapping
When values differ between applications, use OIC lookups where appropriate instead of hard-coding mappings throughout the integration.
6. Monitor Integrations
Regularly monitor:
- Successful executions
- Failed executions
- Processing times
- Errors
- Integration throughput
Monitoring is particularly important in production environments.
Common Mistakes to Avoid
Mistake 1: Using Schedule Integration for Everything
Not every integration needs polling.
If a reliable business event can trigger the process, an event-driven approach may be more appropriate.
Mistake 2: Using Complex Orchestration for Simple Routing
If an integration only needs straightforward routing, avoid unnecessary complexity.
Mistake 3: Ignoring Error Handling
An integration that works only when everything goes perfectly is not production-ready.
Mistake 4: Hard-Coding Environment-Specific Values
Avoid hard-coding URLs, credentials, IDs, and other environment-specific values wherever configurable artifacts or appropriate OIC features can be used.
Mistake 5: Poor Naming Standards
Use meaningful integration names and identifiers.
For example:
CreateEmployeeIntegration
SyncCustomerToERP
ProcessDailyInvoices
SupplierEventNotification
Meaningful names make monitoring and support easier.
OIC Gen 2 vs OIC Gen 3 Terminology
If you have worked with earlier versions of Oracle Integration, the terminology can initially be confusing.
In OIC Generation 2, you may encounter terms such as:
- App Driven Orchestration
- Scheduled Orchestration
- Publish to OIC
- Subscribe to OIC
- Basic Routing
In OIC Gen 3, Oracle’s current documentation presents the primary styles as:
- Application
- Schedule
- Event
Oracle specifically notes that capabilities associated with Publish to OIC and Subscribe to OIC in Generation 2 are available through the event model in OIC Gen 3. An integration that publishes an event can be created as an application integration, while an integration subscribing to a published event can be created as an event integration.
This terminology difference is important for developers migrating from OIC Gen 2 to Gen 3.
Interview Questions on OIC Integration Styles
1. What are integration styles in OIC Gen 3?
Integration styles define how an integration is triggered and the general execution model. The primary OIC Gen 3 styles are Application, Schedule, and Event.
2. When would you use an Application Integration?
Use it when an application or business activity needs to trigger the integration, particularly for API-driven and real-time application integrations.
3. When should you use a Schedule Integration?
Use it when processing should occur according to a defined schedule or when batch processing is required.
4. What is an Event Integration?
An Event Integration subscribes to published business events and starts processing when the relevant event occurs.
5. Can OIC Gen 3 support both real-time and batch integrations?
Yes. Application integrations can support application-driven processing, while Schedule integrations are designed for scheduled execution. Event integrations support event-driven architectures.
6. Which integration style should be used for nightly file processing?
Generally, a Schedule Integration is appropriate.
7. Which style is suitable for an API-based integration?
Generally, an Application Integration is appropriate.
Conclusion
Understanding Integration Styles in OIC Gen 3 is fundamental for anyone working with Oracle Integration Cloud.
The most important concept is simple:
Application Change/API Request
↓
Application
Scheduled Requirement
↓
Schedule
Business Event
↓
Event
Use Application integrations when an application or business activity should initiate the process, Schedule integrations for periodic or batch processing, and Event integrations when the architecture should react to published business events.
Selecting the right integration style at the beginning can improve the integration’s maintainability, scalability, monitoring, and overall architecture.
For official reference, see Oracle’s current documentation on Using Integrations in Oracle Integration 3.
