Invoke Integration in OIC

Introduction

In modern Oracle cloud implementations, Invoke Integration from another in OIC is a critical design pattern used to build modular, reusable, and scalable integrations. Instead of creating large monolithic flows, experienced consultants break integrations into smaller reusable services and orchestrate them using Oracle Integration Cloud (OIC Gen 3).

This approach is widely used in real-time integrations between Oracle Fusion applications (HCM, ERP, SCM) and external systems, ensuring maintainability and performance optimization.

In this blog, we will explore how to invoke one integration from another in OIC Gen 3, with real-world examples, architecture insights, step-by-step configuration, and best practices.

What is “Invoke Integration from Another in OIC”?

In Oracle Integration Cloud (Gen 3), invoking one integration from another means:

Calling a deployed integration (child integration) from a parent/orchestrator integration using REST or SOAP endpoints.

This allows:

• Reusability of logic
• Separation of concerns
• Better maintainability
• Independent deployment cycles

There are two primary ways to invoke an integration:

In real-world projects, REST-based invocation is preferred due to flexibility and performance.

Key Features of Integration Invocation in OIC

1. Modular Design

Break complex integrations into smaller units (e.g., validation, transformation, posting logic).

2. Reusability

Common logic like employee validation or invoice creation can be reused across multiple integrations.

3. Error Isolation

Failures in child integrations can be handled independently.

4. Parallel Processing

Multiple integrations can be invoked in parallel for performance optimization.

5. Scalability

Independent scaling of integrations based on load.

Real-World Integration Use Cases

Use Case 1 – Employee Creation Flow (HCM)

• Parent Integration:
  • Receives employee data from external system
• Child Integrations:
  • Validate Employee Data
  • Create Employee in Fusion HCM
  • Send Notification

Benefit: Each step is reusable across onboarding, transfers, and bulk uploads.

Use Case 2 – Invoice Processing (ERP)

• Parent Integration:
  • Receives invoice payload
• Child Integrations:
  • Validate Supplier
  • Create Invoice
  • Attach Documents

Benefit: Supplier validation logic reused across multiple financial integrations.

Use Case 3 – Order Processing (SCM)

• Parent Integration:
  • Receives order data
• Child Integrations:
  • Validate Inventory
  • Reserve Stock
  • Trigger Shipment

Benefit: Each function can be independently enhanced without impacting others.

Architecture / Technical Flow

Typical Flow

1. Child Integration
   • Exposed via REST trigger
   • Contains reusable business logic
2. Parent Integration
   • Uses REST Adapter to call child integration
   • Handles orchestration

Flow Representation

Key Components

• REST Adapter (Invoke)
• Trigger Integration Endpoint
• Payload Mapping
• Fault Handling

Prerequisites

Before implementing this pattern, ensure:

• OIC Gen 3 instance access
• Integration roles assigned
• Child integration is:
  • Designed
  • Activated
  • Exposed via REST/SOAP
• Endpoint URL available
• Security configured (Basic Auth / OAuth)

Step-by-Step Build Process

Step 1 – Create Child Integration

Navigate to:

OIC Console → Integrations → Create → App Driven Orchestration

Configure Trigger

• Select: REST Adapter
• Define:
  • Endpoint: /createEmployee
  • Method: POST

Define Request Payload (Example)

Add Business Logic

• Data validation
• Transformation
• Call Fusion HCM API

Define Response

Activate Integration

Step 2 – Get Endpoint URL

After activation:

• Click on Integration
• Go to Endpoints
• Copy REST endpoint URL

Example:

Step 3 – Create Parent Integration

Navigate to:

OIC Console → Integrations → Create → App Driven Orchestration

Configure Trigger

• REST Adapter
• Endpoint: /processEmployee

Step 4 – Add REST Adapter (Invoke)

Add Action:

• Drag REST Adapter to canvas

Configure:

• Connection: REST Connection
• Endpoint URL: Child Integration URL
• Method: POST

Step 5 – Configure Request Mapping

Map parent request to child request:

Step 6 – Handle Response

Map child response to parent response:

Step 7 – Add Fault Handling

• Add Scope
• Configure Fault Handler
• Log error message
• Return meaningful response

Step 8 – Activate Parent Integration

Testing the Integration

Test Scenario

Input Payload (Parent Integration)

Expected Flow

1. Parent receives request
2. Calls child integration
3. Child processes data
4. Returns response

Expected Output

Validation Checks

• Check tracking instance in OIC
• Verify payload mapping
• Validate response structure
• Ensure no fault occurred

Common Errors and Troubleshooting

1. 401 Unauthorized

Cause:

• Authentication issue

Solution:

• Verify credentials
• Check OAuth token

2. 404 Not Found

Cause:

• Incorrect endpoint URL

Solution:

• Re-copy endpoint from OIC

3. Payload Mapping Errors

Cause:

• Mismatch in schema

Solution:

• Validate JSON structure
• Check required fields

4. Timeout Issues

Cause:

• Long-running child integration

Solution:

• Optimize logic
• Use async pattern if needed

5. Fault Not Handled Properly

Cause:

• Missing fault handler

Solution:

• Add global or scope fault handler

Best Practices (From Real Projects)

1. Use REST over SOAP

REST is lightweight and easier to maintain.

2. Design Reusable Integrations

Create separate integrations for:

• Validation
• Transformation
• API calls

3. Use Meaningful Naming

Example:

• INT_EMP_VALIDATE
• INT_EMP_CREATE

4. Implement Proper Error Handling

• Always return meaningful error messages
• Log errors using tracking variables

5. Use Versioning

Maintain multiple versions of integrations:

• v1.0
• v2.0

6. Secure Endpoints

• Use OAuth for production
• Avoid exposing endpoints publicly

7. Avoid Tight Coupling

Do not hardcode URLs—use:

• Lookup tables
• Configuration variables

8. Use Parallel Execution Where Needed

Invoke multiple integrations simultaneously for performance improvement.

Real Consultant Insight

In large Oracle Fusion implementations, especially HCM and ERP integrations, this pattern becomes essential.

For example:

• A payroll integration might call:
  • Validation integration
  • Earnings calculation integration
  • Payment processing integration

Without modular design, maintenance becomes extremely difficult.

Summary

Invoking one integration from another in OIC Gen 3 is a foundational pattern for building scalable, maintainable, and reusable integrations.

Key takeaways:

• Use REST-based invocation
• Design modular integrations
• Implement proper error handling
• Follow best practices for scalability
• Always test with real payloads

This approach is widely used in real-world Oracle Fusion projects and is essential for any OIC consultant.

FAQs

1. Can we invoke integration asynchronously in OIC?

Yes. You can design fire-and-forget patterns using asynchronous integrations to improve performance.

2. Is REST or SOAP better for invoking integrations?

REST is preferred due to simplicity, performance, and flexibility.

3. Can we reuse one integration across multiple parent integrations?

Absolutely. That is the main advantage of this design pattern.

Additional Reference

For deeper understanding, refer to official Oracle documentation:

https://docs.oracle.com/en/cloud/saas/index.html