OIC Fault Handler Guide

Share

Introduction

In any enterprise integration landscape, handling failures is just as important as processing successful transactions. Oracle Integration Cloud Fault Handler plays a critical role in ensuring that integrations built in Oracle Integration Cloud (OIC Gen 3) are resilient, traceable, and production-ready.

In real-world implementations, integrations rarely run 100% successfully—network issues, API failures, data mismatches, and timeouts are common. Without proper fault handling, these failures can disrupt entire business processes.

This guide provides a deep, implementation-focused understanding of fault handling in OIC, including design strategies, configuration steps, testing, and best practices based on actual project experience.


What is Oracle Integration Cloud Fault Handler?

A Fault Handler in OIC is a mechanism used to catch, manage, and respond to runtime errors that occur during integration execution.

Instead of letting an integration fail abruptly, a fault handler allows you to:

  • Capture the error details
  • Execute alternate logic
  • Notify stakeholders
  • Retry or compensate transactions

Types of Fault Handling in OIC

Type Description
Global Fault Handler Handles errors across the entire integration
Scope Fault Handler Handles errors within a specific scope
Fault Throw Explicitly raises a fault
Re-throw Fault Passes error to higher-level handler

Real-World Integration Use Cases

1. Payroll Integration Failure Handling (HCM → Payroll System)

In a project integrating Oracle Fusion HCM with a third-party payroll system:

  • Employee data failed due to invalid bank details
  • Fault handler captured error
  • Logged failed records in a staging table
  • Triggered email notification to HR

2. Invoice Integration (ERP → External Vendor API)

While integrating Oracle Fusion ERP:

  • External API returned HTTP 500 error
  • Fault handler triggered retry logic
  • After 3 failures, created incident in ticketing system

3. Order Processing Integration (SCM → Warehouse System)

In Oracle Fusion SCM:

  • Data mapping error caused transformation failure
  • Scope-level fault handler isolated the issue
  • Continued processing other records without stopping entire batch

Architecture / Technical Flow of Fault Handling

Understanding how fault handling works internally is critical.

Flow Overview

  1. Integration executes steps sequentially
  2. Error occurs (API failure, mapping error, timeout)
  3. OIC identifies nearest fault handler:
    • Scope-level first
    • Then global-level
  4. Fault handler executes defined actions
  5. Integration either:
    • Recovers
    • Terminates gracefully
    • Re-throws fault

Key Components

  • Scope Activity – Defines logical blocks
  • Fault Handler Section – Attached to scope or integration
  • Fault Object – Contains error details (fault.name, fault.message)
  • Logger / Notification – Used inside handler

Prerequisites

Before implementing fault handling, ensure:

  • Access to Oracle Integration Cloud (Gen 3 instance)
  • Basic understanding of:
    • Integrations (App Driven / Scheduled)
    • Mappings
    • Connections (REST/SOAP)
  • Email or notification setup configured
  • Logging mechanism (DB/ATP/File/ERP tables)

Step-by-Step Build Process

Let’s walk through a practical implementation of fault handling.


Step 1 – Create Integration

Navigation:

Navigator → Integrations → Create

  • Select: App Driven Orchestration
  • Name: Employee_Data_Sync

Step 2 – Add Business Logic

  • Add Trigger (e.g., REST Adapter)
  • Add Invoke (External System API)
  • Add Mapping

At this stage, your integration is functional but lacks error handling.


Step 3 – Add Scope for Controlled Execution

Drag a Scope Activity and place your invoke + mapping inside it.

Why?

👉 Scope allows localized fault handling without affecting entire integration.


Step 4 – Configure Scope Fault Handler

Click on the scope → Go to Fault Handler tab

Add a fault handler.

Inside Fault Handler:

  1. Assign Activity
    • Capture fault details
    • Example:
      • errorMessage = fault.message
      • errorCode = fault.name
  2. Logger Activity
    • Log error:

      Employee Sync Failed: ${fault.message}
  3. Notification Action
    • Send email to support team

Step 5 – Add Global Fault Handler

Scroll to bottom of integration → Add Global Fault Handler

Use this when errors are not handled in scope.

Example Actions:

  • Log critical error
  • Send escalation email
  • Create incident record

Step 6 – Implement Retry Logic (Optional but Recommended)

Inside fault handler:

  • Use Switch Activity
  • Condition:

    retryCount < 3
  • Re-invoke API
  • Increment retry counter

Step 7 – Save and Activate

  • Click Save
  • Click Activate

Testing the Fault Handler

Test Scenario

Input Payload:

{ “employeeName”: “John”, “bankAccount”: “” }

Expected Behavior

  • External system rejects request
  • Fault triggered
  • Fault handler executes:
    • Logs error
    • Sends email
    • Stores failure record

Validation Checks

  • Check Tracking → Instances
  • Verify error message
  • Confirm email received
  • Validate retry logic (if implemented)

Common Errors and Troubleshooting

1. Fault Handler Not Triggering

Cause:

  • Error occurs outside scope

Fix:

  • Add global fault handler

2. Missing Fault Details

Cause:

  • Not mapping fault variables correctly

Fix:

  • Use:
    • fault.name
    • fault.reason
    • fault.details

3. Infinite Retry Loop

Cause:

  • No retry limit

Fix:

  • Always define retry counter

4. Integration Stops Completely

Cause:

  • Fault not handled

Fix:

  • Add proper scope-level handling

Best Practices from Real Projects

1. Always Use Scope-Based Fault Handling

Never rely only on global fault handler.

✔ Helps isolate failures
✔ Improves maintainability


2. Centralized Error Logging

Store errors in:

  • ATP DB
  • ERP tables
  • Logging service

3. Standard Error Framework

Create reusable logic:

  • Error codes
  • Error messages
  • Notification templates

4. Avoid Over-Retrying

Limit retries to:

  • 2–3 attempts
  • Use exponential backoff

5. Use Meaningful Tracking

Enable business identifiers:

  • Employee ID
  • Invoice Number

6. Notify Smartly

Avoid spamming:

  • Use aggregated alerts
  • Critical-only notifications

Real Consultant Insight

In one production implementation, lack of proper fault handling caused:

  • 2000+ failed payroll records
  • No alert to business team
  • Manual correction effort of 3 days

After implementing structured fault handlers:

  • Errors were auto-captured
  • Notifications triggered instantly
  • Recovery time reduced by 80%

👉 Fault handling is not optional—it is mandatory for production-grade integrations.


Summary

The Oracle Integration Cloud Fault Handler is a powerful feature that transforms integrations from fragile to enterprise-ready.

Key takeaways:

  • Use scope-level fault handlers for granular control
  • Always implement a global fallback handler
  • Capture and log errors systematically
  • Use retry logic carefully
  • Design integrations assuming failures will happen

Mastering fault handling is one of the key skills that differentiates a beginner from an experienced OIC consultant.


FAQs

1. What is the difference between global and scope fault handler?

  • Scope fault handler handles errors within a specific block
  • Global fault handler handles unhandled errors across the integration

2. Can we retry a failed API call in OIC?

Yes. You can implement retry logic using:

  • Switch activity
  • Counter variable
  • Re-invoke pattern

3. How do we log errors in OIC?

You can log errors using:

  • Logger activity
  • Database insert (ATP)
  • ERP staging tables
  • External logging services

Additional Reference

For deeper understanding, refer to official Oracle documentation:
https://docs.oracle.com/en/cloud/saas/index.html


Share

Leave a Reply

Your email address will not be published. Required fields are marked *