Introduction
Default error handling in Oracle Integration Cloud is one of the most critical concepts every integration consultant must understand. In real-world implementations, integrations rarely run perfectly—failures due to API timeouts, data issues, authentication errors, or downstream system failures are very common.
If you don’t design proper error handling, your integrations will fail silently, making troubleshooting extremely difficult and impacting business operations.
In this blog, we will go deep into default error handling in OIC, how it works internally, and how consultants leverage it in production-grade integrations.
What is Default Error Handling in OIC?
Default error handling in OIC refers to the automatic mechanism provided by the platform to catch and process runtime faults when no explicit fault handler (scope or global) is defined.
In simple terms:
- If an error occurs in an integration
- And you have NOT defined any fault handling logic
- OIC automatically triggers the default fault handling behavior
This behavior includes:
- Stopping the integration execution
- Logging the error in tracking
- Returning a fault response (for synchronous integrations)
- Marking the instance as failed
This is especially relevant in OIC Gen 3, where observability and error diagnostics have improved significantly.
Why Default Error Handling is Important
From an implementation perspective, default error handling acts as a safety net.
Key Importance
- Ensures no error goes unnoticed
- Provides diagnostic details in the OIC console
- Helps in debugging during development
- Acts as fallback when custom handlers are missing
However, relying ONLY on default handling in production is a bad practice, which we will discuss later.
Real-World Integration Use Cases
Let’s look at how default error handling appears in real projects.
Scenario 1 – ERP Invoice Integration Failure
A REST integration sends invoices to Oracle Fusion ERP.
- API fails due to invalid payload
- No scope fault handler defined
- OIC default handler:
- Marks instance as failed
- Logs error message: 400 Bad Request
👉 Impact: Business team cannot process invoices until issue is fixed manually.
Scenario 2 – HCM Worker Sync Failure
Integration between Oracle Fusion HCM and third-party payroll:
- Downstream API timeout occurs
- No retry or fault handling implemented
- Default handler:
- Stops execution
- Logs timeout exception
👉 Impact: Employee data sync fails silently unless monitored.
Scenario 3 – File-Based Integration Error
File is read from FTP and processed:
- Incorrect file format
- Mapping fails
- Default handler logs transformation error
👉 Impact: File processing stops entirely.
Architecture / Technical Flow of Default Error Handling
Let’s understand how OIC processes errors internally.
Execution Flow
- Integration starts execution
- Activities are executed sequentially
- If an error occurs:
- OIC checks for Scope Fault Handler
- If not found → checks Global Fault Handler
- If not found → triggers Default Error Handling
Default Handling Behavior
- Exception captured internally
- Error message stored in:
- Activity Stream
- Tracking Instance
- Integration instance marked as:
- FAILED
Error Details Available
- Fault name
- Fault reason
- Stack trace (in some cases)
- Activity where failure occurred
Prerequisites
Before working with default error handling, ensure:
- Access to Oracle Integration Cloud instance
- Integration created (App Driven or Scheduled)
- Connections configured (REST, SOAP, FTP, etc.)
- Basic understanding of:
- Scopes
- Fault handlers
- Tracking
Step-by-Step: Understanding Default Error Handling in Action
Let’s simulate a failure to observe default behavior.
Step 1 – Create Integration
Navigate:
Home → Integrations → Create
- Type: App Driven Orchestration
- Trigger: REST Adapter
Step 2 – Add Invoke Action
- Add REST Invoke
- Configure endpoint with invalid payload requirement
Step 3 – Skip Fault Handlers
Important:
- Do NOT configure:
- Scope Fault Handler
- Global Fault Handler
Step 4 – Activate Integration
- Save
- Activate
Step 5 – Test Integration
Send request:
“invoiceNumber”: “123”,
“amount”: “INVALID”
}
Testing the Technical Component
Expected Result
- Integration fails
- Status: FAILED
Where to Check Errors
Navigate:
Home → Monitoring → Tracking → Instances
Open failed instance:
You will observe:
- Error message
- Fault details
- Failed activity
Validation Checks
- Verify error message clarity
- Identify failing activity
- Check payload data
Common Errors Observed in Default Handling
| Error Type | Description |
|---|---|
| 400 Bad Request | Invalid input payload |
| 401 Unauthorized | Authentication failure |
| 500 Internal Server Error | Backend failure |
| Timeout | API not responding |
| Mapping Error | Data transformation failure |
Common Implementation Challenges
1. Lack of Visibility
Default handling logs errors but:
- No notifications
- No alerts to business users
2. No Retry Mechanism
Default handler:
- Does NOT retry failed transactions
3. No Custom Error Messages
End users receive:
- Technical error messages
- Not business-friendly
4. Data Loss Risk
If integration fails:
- No compensation logic
- No rollback
Best Practices for Using Default Error Handling
As a consultant, you should NEVER rely solely on default error handling in production.
1. Always Implement Global Fault Handler
- Capture all unhandled exceptions
- Log custom messages
2. Use Scope-Level Fault Handling
- Handle errors at granular level
- Example:
- API retry logic
- Alternative processing
3. Enable Notifications
- Email alerts
- Integration with monitoring tools
4. Log Business-Friendly Messages
Instead of:
“HTTP 500 Internal Server Error”
Use:
“Invoice creation failed due to ERP unavailability”
5. Implement Retry Logic
- Use scope + loop
- Retry API calls for transient failures
6. Track Critical Fields
- Enable business identifiers
- Example:
- Invoice Number
- Employee ID
7. Use Fault Policies (Advanced)
- Configure retry rules
- Handle SOAP faults effectively
Expert Consultant Tips
From real project experience:
- Always test failure scenarios, not just success paths
- Use structured logging strategy
- Maintain error catalog for integrations
- Document all failure points
- Monitor failed instances daily
Summary
Default error handling in Oracle Integration Cloud is a built-in fallback mechanism that ensures all unhandled errors are captured and logged.
However, in real-world enterprise implementations:
- It should NOT be the primary error handling strategy
- It should be treated as a last line of defense
A well-designed integration must include:
- Scope fault handlers
- Global fault handlers
- Retry mechanisms
- Notification frameworks
By combining these with default handling, you can build robust, production-ready integrations.
FAQs
1. What happens if no fault handler is defined in OIC?
OIC automatically uses default error handling, which logs the error and marks the integration as failed.
2. Can we customize default error handling?
No, default handling cannot be customized. Instead, you should implement global or scope fault handlers.
3. Is default error handling sufficient for production?
No. It is only a fallback mechanism. Production integrations must include custom error handling strategies.
Additional Reference
For deeper understanding, refer to official Oracle documentation: