OIC Throw vs Rethrow Fault

Introduction

In any enterprise integration project, error handling is not optional—it is critical. When working with Throw New Fault and Rethrow Fault in Oracle Integration Cloud (OIC Gen 3), consultants often face challenges in designing robust exception handling mechanisms that are both user-friendly and maintainable.

This blog dives deep into how Throw New Fault and Rethrow Fault work in OIC, when to use each, and how they behave in real-world integration scenarios. If you’re building production-grade integrations, understanding these two fault handling actions is essential.

What is Throw New Fault and Rethrow Fault in OIC?

In OIC, fault handling is implemented using Scope-level fault handlers. Within these handlers, you can explicitly control error propagation using:

Throw New Fault

• Used to create and raise a completely new custom fault
• Allows you to define:
  • Custom fault name
  • Custom fault message
  • Custom payload (optional)

Rethrow Fault

• Used to propagate the original fault as-is
• Does not modify the fault
• Useful when you want upstream systems to receive the same error

Why This Matters in Real Projects

In real implementations, improper fault handling leads to:

• Unclear error messages for business users
• Difficulty in debugging integrations
• Loss of original error context
• Poor audit and monitoring experience

A well-designed fault handling strategy ensures:

• Better observability
• Clear communication with consuming systems
• Faster issue resolution

Real-World Integration Use Cases

Scenario 1: HCM Data Validation Failure

An integration loads employee data into HCM. If:

• Mandatory fields like Email or Department are missing

Solution:

• Use Throw New Fault

• Send a business-friendly message:

  “Employee record missing mandatory email address”

Scenario 2: External API Failure

An OIC integration calls a third-party payroll API which returns a 500 error.

Solution:

• Use Rethrow Fault
• Preserve original API response for debugging

Scenario 3: File-Based Data Load (FBDI)

During FBDI load:

• Backend job fails with error logs

Solution:

• Catch fault → Transform message → Throw New Fault

• Provide user-friendly message like:

  “Payroll batch load failed. Please check ESS logs.”

Architecture / Technical Flow

Here’s how fault handling works internally:

1. Integration executes steps
2. Error occurs in:
   • Invoke
   • Assign
   • Mapping
3. Control moves to Scope Fault Handler
4. Inside handler:
   • You choose:
     • Throw New Fault
     • Rethrow Fault
5. Integration response is sent back

Prerequisites

Before implementing fault handling:

• Access to OIC Gen 3 instance
• Integration created (App Driven / Scheduled / Orchestration)
• Basic understanding of:
  • Scopes
  • Variables
  • Assign activity
  • Tracking fields

Step-by-Step Implementation in OIC

Step 1 – Create Integration

Navigate to:

Home → Integrations → Create → App Driven Orchestration

• Name: EmployeeSyncIntegration
• Pattern: App Driven Orchestration

Step 2 – Add Scope

Drag and drop a Scope activity.

Inside Scope:

• Add:
  • REST Adapter call
  • Mapping logic

Step 3 – Add Fault Handler

Click on Scope → Click + under Fault Handlers

You will see options:

• Catch All
• Specific Fault

Choose:

• Catch All

Step 4 – Implement Throw New Fault

Inside fault handler:

1. Drag Assign Activity
2. Create variables:
   • faultName = CustomValidationFault
   • faultMessage = "Employee data validation failed"
3. Drag Throw New Fault Activity

Configure:

• Fault Name: CustomValidationFault
• Fault Reason: Use variable
• Fault Data: Optional JSON/XML payload

Step 5 – Implement Rethrow Fault

Alternative approach:

Instead of Throw New Fault:

1. Drag Rethrow Fault Activity
2. No additional configuration required

This will:

• Send original error upstream

Step 6 – Save and Activate

• Click Save
• Click Activate

Testing the Fault Handling

Test Case 1 – Validation Failure

Input Payload:

Expected Behavior:

• Scope fails
• Fault handler triggers
• Throw New Fault sends:
  • Custom message

Test Case 2 – API Failure

Simulate:

• External API down

Expected Behavior:

• Rethrow Fault returns:
  • Original HTTP error
  • Status code
  • Response payload

Validation Checks

• Check Activity Stream
• Verify Error Message
• Confirm Tracking ID
• Validate response payload

Key Differences: Throw New Fault vs Rethrow Fault

Common Implementation Challenges

1. Losing Original Error Context

If you use Throw New Fault without logging:

• Original error is lost

Solution:

• Log error before throwing new fault

2. Overusing Rethrow Fault

Leads to:

• Technical errors exposed to business users

Solution:

• Use Rethrow only for system-level faults

3. Poor Error Messages

Example:

“Error occurred”

Solution:

• Always provide meaningful messages

4. Missing Fault Scope

If Scope is not used:

• Fault handler won’t trigger properly

Best Practices from Real Projects

1. Use Hybrid Approach

• Business Errors → Throw New Fault
• System Errors → Rethrow Fault

2. Always Log Before Throwing

Use:

• Logger activity
• Tracking variables

3. Standardize Error Messages

Define format:

Example:

4. Use Fault Codes

Instead of plain text:

• Use structured fault codes
• Helps in monitoring dashboards

5. Avoid Deep Nesting of Scopes

Too many scopes:

• Complex fault handling
• Hard to debug

6. Design for Monitoring

Ensure:

• Faults appear clearly in:
  • OIC Dashboard
  • Insight reports

Expert Consultant Tip

In large enterprise integrations (especially HCM/ERP), I always implement:

• Centralized Error Framework
• One reusable fault structure across integrations

This improves:

• Consistency
• Maintainability
• Debugging speed

Summary

Understanding Throw New Fault and Rethrow Fault in OIC Gen 3 is critical for building enterprise-grade integrations.

• Use Throw New Fault for business-friendly errors
• Use Rethrow Fault for preserving technical issues
• Always log before throwing
• Design fault handling with clarity and consistency

A well-designed error handling strategy can significantly reduce production issues and improve user experience.

For deeper reference, consult Oracle official documentation:
https://docs.oracle.com/en/cloud/saas/index.html

FAQs

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

Use it when you want to send custom business-friendly error messages instead of technical errors.

2. Does Rethrow Fault modify the original error?

No, it sends the exact same error without any changes.

3. Can I log errors before throwing a new fault?

Yes, and it is highly recommended to capture original error details before using Throw New Fault.