OIC Throw New Fault Explained

Share

Introduction

Oracle Integration Cloud Throw New Fault is one of the most critical features in OIC Gen 3 for handling errors in enterprise integrations. In real-world implementations, integrations rarely run perfectly—API failures, validation errors, missing data, and external system downtime are common. As a consultant, the difference between a stable integration and a chaotic one often comes down to how effectively you handle faults.

In Oracle Integration Cloud (OIC), fault handling is not just about catching errors—it’s about controlling the behavior of integrations, providing meaningful error responses, and ensuring business continuity. The Throw New Fault action plays a central role in this process.

This article provides a deep, practical understanding of Throw New Fault in OIC, including real-world usage, architecture, implementation steps, and best practices based on actual project experience.


What is Throw New Fault in Oracle Integration Cloud?

In OIC Gen 3, Throw New Fault is a fault handling action used to:

  • Explicitly raise a custom error within an integration
  • Stop execution of the current flow
  • Return a structured fault message to the calling system (especially in synchronous integrations)

Think of it as a controlled exception mechanism, similar to throwing exceptions in programming languages like Java.

Why it matters

Without Throw New Fault:

  • Errors may remain unhandled
  • Users receive generic or unclear messages
  • Debugging becomes difficult
  • Downstream systems may behave unpredictably

With Throw New Fault:

  • You define custom fault messages
  • You ensure consistent error responses
  • You improve integration reliability

Real-World Integration Use Cases

Use Case 1: Validation Failure in Employee Data Integration

In an HCM integration:

  • Input payload contains employee details
  • Mandatory fields like Email or Department are missing

Instead of proceeding and failing later:

👉 Use Throw New Fault to immediately stop execution and return:

{ “errorCode”: “VALIDATION_ERROR”, “message”: “Email is mandatory for employee creation” }

Use Case 2: External API Failure Handling

Scenario:

  • OIC calls a third-party payroll API
  • API returns HTTP 500

Instead of passing raw error:

👉 Catch the fault and throw a new business-friendly error:

{ “errorCode”: “PAYROLL_SERVICE_DOWN”, “message”: “Payroll service is currently unavailable” }

Use Case 3: Business Rule Enforcement

Scenario:

  • Employee salary exceeds allowed limit
  • Business rule violation

👉 Throw custom fault:

{ “errorCode”: “BUSINESS_RULE_VIOLATION”, “message”: “Salary exceeds allowed band” }

Architecture / Technical Flow

In OIC, fault handling works through Scopes and Fault Handlers.

Flow Explanation

  1. Integration execution starts
  2. A Scope contains logic (mapping, invoke, etc.)
  3. If an error occurs:
    • Control moves to the Fault Handler
  4. Inside Fault Handler:
    • You can log error
    • Transform error
    • Use Throw New Fault

Key Components

Component Description
Scope Logical container for steps
Fault Handler Handles errors within scope
Throw New Fault Raises custom error
Global Fault Handles unhandled errors

Prerequisites

Before implementing Throw New Fault:

  • OIC Gen 3 instance configured
  • Basic integration created (App Driven or Scheduled)
  • Knowledge of:
    • Mapping
    • Scope usage
    • Fault handling basics

Step-by-Step Build Process

Let’s walk through a real implementation scenario.

Scenario

You are building an integration:

  • Input: Employee data
  • Validation: Email must not be empty
  • If invalid → Throw New Fault

Step 1 – Create Integration

Navigate to:

Home → Integrations → Create

  • Select: App Driven Orchestration
  • Provide:
    • Name: Employee_Validation_Integration

Step 2 – Add Trigger

  • Choose REST Adapter
  • Define request payload:
{ “name”: “John”, “email”: “” }

Step 3 – Add Scope

Drag and drop Scope action.

Inside Scope:

  • Add validation logic (using Switch or Assign)

Step 4 – Add Validation Condition

Use Switch Activity:

Condition:

string-length($request/email) = 0

If TRUE → go to fault


Step 5 – Configure Throw New Fault

Inside the IF branch:

  1. Drag Throw New Fault
  2. Configure:
  • Fault Name: ValidationFault
  • Fault Type: Business Fault
  • Fault Message:
{ “errorCode”: “VALIDATION_ERROR”, “message”: “Email is mandatory” }

👉 This ensures clean, structured error response.


Step 6 – Configure Fault Handler (Optional but Recommended)

Click on Scope → Fault Handler

Add:

  • Assign → Capture error details
  • Logger → Log error

Step 7 – Save and Activate

  • Click Save
  • Click Activate

Testing the Technical Component

Test Payload

{ “name”: “John”, “email”: “” }

Expected Response

{ “type”: “ValidationFault”, “title”: “Validation Error”, “detail”: “Email is mandatory” }

Validation Checks

  • Integration stops execution
  • No downstream calls executed
  • Error is returned immediately
  • Logs show fault details

Common Errors and Troubleshooting

1. Fault Not Triggering

Issue: Throw New Fault not executed

Cause: Incorrect condition in Switch

Fix: Validate XPath expression


2. Generic Error Returned

Issue: Instead of custom error, default OIC error appears

Cause: Fault not properly mapped

Fix: Ensure fault message is defined correctly


3. Integration Continues Execution

Issue: Flow continues after error

Cause: Throw New Fault placed outside correct branch

Fix: Place it inside conditional logic


4. Incorrect Fault Structure

Issue: Consumer system fails to parse error

Cause: Improper JSON structure

Fix: Follow consistent error schema


Best Practices

1. Always Use Business-Friendly Messages

Avoid:

NullPointerException

Use:

Employee email is missing

2. Standardize Error Structure

Use consistent format:

{ “errorCode”: “”, “message”: “”, “timestamp”: “” }

3. Use Throw New Fault for Controlled Failures

Use it when:

  • Business validation fails
  • API response needs transformation
  • Custom logic requires termination

4. Combine with Scope-Based Fault Handling

Best pattern:

  • Scope → Fault Handler → Throw New Fault

5. Log Before Throwing Fault

Always log error details:

  • Payload
  • Error message
  • Integration name

6. Avoid Overusing Throw New Fault

Do not use for:

  • Minor warnings
  • Non-critical validations

Real Consultant Insight

In one real project involving Oracle Fusion HCM and Payroll integration, the absence of proper fault handling caused:

  • Payroll failures
  • Duplicate employee records
  • Data inconsistencies

After implementing:

  • Scope-based error handling
  • Throw New Fault for validation

Result:

  • 70% reduction in integration failures
  • Faster issue resolution
  • Improved user confidence

Summary

Oracle Integration Cloud Throw New Fault is a powerful feature that enables:

  • Controlled error handling
  • Custom fault responses
  • Improved integration stability

In OIC Gen 3, mastering this feature is essential for building enterprise-grade integrations. It ensures that errors are not just handled—but handled intelligently and consistently.


FAQs

1. When should we use Throw New Fault in OIC?

Use it when you want to explicitly stop execution and return a custom error message, especially for business validations and controlled failures.


2. What is the difference between Raise Fault and Throw New Fault?

  • Throw New Fault → Used for custom business errors
  • Raise Fault (system fault) → Used for system-generated exceptions

3. Can Throw New Fault be used in asynchronous integrations?

Yes, but it is most effective in synchronous integrations, where the response is returned immediately to the caller.


Additional Reference

For deeper understanding, refer to official Oracle documentation:

https://docs.oracle.com/en/cloud/paas/integration-cloud/index.html


Share

Leave a Reply

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