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:
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:
Use Case 3: Business Rule Enforcement
Scenario:
- Employee salary exceeds allowed limit
- Business rule violation
👉 Throw custom fault:
Architecture / Technical Flow
In OIC, fault handling works through Scopes and Fault Handlers.
Flow Explanation
- Integration execution starts
- A Scope contains logic (mapping, invoke, etc.)
- If an error occurs:
- Control moves to the Fault Handler
- 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
- Name:
Step 2 – Add Trigger
- Choose REST Adapter
- Define request payload:
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:
If TRUE → go to fault
Step 5 – Configure Throw New Fault
Inside the IF branch:
- Drag Throw New Fault
- Configure:
- Fault Name:
ValidationFault - Fault Type: Business Fault
- Fault Message:
👉 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
Expected Response
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:
Use:
2. Standardize Error Structure
Use consistent format:
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