Introduction
In any enterprise integration landscape, error handling is not just a technical requirement—it is a business necessity. When working with Global Fault Handler in OIC, one of the most critical responsibilities of an integration consultant is to ensure failures are captured, logged, and handled gracefully without impacting downstream systems.
In modern cloud implementations using Oracle Integration Cloud (OIC Gen 3), integrations are often connected to multiple systems such as HCM, ERP, external REST APIs, and third-party services. A single failure can cascade into multiple issues if not properly handled.
This blog provides a deep, practical, consultant-level understanding of Global Fault Handler in OIC, including architecture, real-world use cases, step-by-step implementation, and best practices based on actual project experience.
What is Global Fault Handler in OIC?
The Global Fault Handler in OIC is a centralized error handling mechanism that captures exceptions occurring anywhere within an integration flow.
Instead of handling errors individually in each step or scope, the global fault handler ensures:
- Centralized error handling
- Standardized logging
- Consistent response structure
- Reduced redundancy in integration design
Key Concept
Whenever an error occurs in an integration (e.g., REST call failure, mapping issue, timeout), OIC automatically routes the execution to the Global Fault Handler, if configured.
Real-World Integration Use Cases
Use Case 1: HCM to Payroll Integration Failure Handling
A typical integration fetches employee data from Oracle HCM and sends it to a payroll system.
Scenario:
- REST API call fails due to authentication issue
Global Fault Handler Role:
- Logs error details into ATP database
- Sends email notification to support team
- Returns structured error response to calling system
Use Case 2: ERP Invoice Integration with External Vendor
Scenario:
- Invoice creation fails due to missing mandatory fields
Global Fault Handler Role:
- Captures payload causing error
- Writes error to file storage (OCI Object Storage)
- Triggers retry mechanism via scheduled integration
Use Case 3: Third-Party API Timeout Handling
Scenario:
- External API times out intermittently
Global Fault Handler Role:
- Identifies timeout error
- Routes to retry logic or alternate endpoint
- Prevents integration failure from propagating
Architecture / Technical Flow
Understanding how Global Fault Handler works internally is key for real implementations.
Execution Flow
- Integration starts execution
- Activities are processed sequentially
- Error occurs (e.g., REST failure, mapping error)
- OIC interrupts normal flow
- Control moves to Global Fault Handler
- Fault handler executes error handling logic
- Integration ends with appropriate response
Important Note
- Global Fault Handler is defined at integration level
- It captures unhandled exceptions
- Scope-level faults override global faults if configured
Prerequisites
Before implementing Global Fault Handler in OIC, ensure the following:
- Access to OIC Gen 3 instance
- Basic understanding of:
- Integrations (App Driven / Scheduled)
- Scope actions
- Assign & Logger actions
- Configured connections:
- Email (SMTP)
- REST endpoints (if required)
- Logging mechanism (DB, File, or Notification service)
Step-by-Step Build Process
Let’s walk through how a consultant actually implements a Global Fault Handler in a real project.
Step 1 – Create Integration
Navigate to:
Home → Integrations → Create
Choose:
- App Driven Orchestration (for real-time integrations)
Provide:
- Name:
EmployeeSyncIntegration - Trigger: REST Adapter
Step 2 – Design Main Flow
Add:
- Trigger (REST)
- Invoke (HCM API / External API)
- Mapping
At this stage, do NOT add error handling inside individual steps.
Step 3 – Enable Global Fault Handler
In the integration canvas:
- Click on the Global Fault Handler section (bottom of canvas)
This opens a dedicated error handling area.
Step 4 – Add Fault Handling Logic
Inside Global Fault Handler, add the following actions:
1. Assign Action (Capture Error Details)
Capture system variables:
fault.namefault.reasonfault.details
Example:
errorMessage = fault.reason
2. Logger Action (Debugging)
Log error for tracking:
This is extremely useful during production troubleshooting.
3. Notification Action (Optional)
Send email using configured SMTP:
- To: support@company.com
- Subject: Integration Failure Alert
- Body: Include error details
4. File/DB Logging (Advanced)
Store error payload into:
- ATP Database
- OCI Object Storage
- External logging system
5. Return Fault Response
If integration is synchronous:
- Map error response back to calling system
Example response:
“status”: “FAILED”,
“errorCode”: “API_ERROR”,
“message”: “Unable to process request”
}
Step 5 – Save and Activate
- Click Save
- Click Activate
Testing the Technical Component
Testing is critical. Never assume fault handler works without validation.
Test Scenario
Input:
- Send REST request with invalid payload
Expected Behavior:
- Integration fails at invoke step
- Global Fault Handler is triggered
- Logger captures error
- Email notification is sent
- Response returned to client
Validation Checklist
- Error captured correctly?
- Logs visible in OIC tracking?
- Notification triggered?
- Response format correct?
Common Errors and Troubleshooting
Issue 1: Fault Handler Not Triggering
Cause:
- Error handled at scope level
Solution:
- Remove scope fault handler OR rethrow error
Issue 2: Missing Error Details
Cause:
- Incorrect variable mapping
Solution:
- Use system fault variables properly
Issue 3: Integration Fails Without Logging
Cause:
- Logger not configured
Solution:
- Always include logger action in fault handler
Issue 4: Email Not Sending
Cause:
- SMTP connection issue
Solution:
- Validate connection and credentials
Best Practices from Real Projects
1. Always Centralize Error Handling
Avoid writing fault logic in multiple places.
✔ Use Global Fault Handler as default
✔ Use Scope Fault Handler only when necessary
2. Standardize Error Response
Define a consistent format:
“status”: “FAILED”,
“errorCode”: “”,
“message”: “”
}
3. Log Complete Payload
In real production issues, payload is gold.
✔ Store request & response payloads
✔ Include timestamp and integration name
4. Avoid Overloading Fault Handler
Do NOT:
- Add complex business logic
- Call multiple external systems
Keep it lightweight and reliable.
5. Use Re-throw Strategy Carefully
If needed:
- Handle partially
- Re-throw for upstream handling
6. Design for Retry Mechanism
Global Fault Handler should support:
- Retry queue
- Reprocessing mechanism
7. Monitor Using OIC Tracking
Always check:
- Activity Stream
- Error logs
- Instance tracking
Real Implementation Insight (Consultant Tip)
In one ERP integration project, invoice failures were silently ignored due to improper fault handling. After implementing a structured Global Fault Handler:
- Error visibility improved by 80%
- Support tickets reduced drastically
- SLA compliance improved
The key takeaway:
Error handling is not optional—it is part of integration design.
Summary
The Global Fault Handler in OIC is a powerful feature that enables centralized and consistent error handling across integrations.
By implementing it properly, you can:
- Improve system reliability
- Reduce debugging time
- Enhance monitoring and alerting
- Deliver production-ready integrations
For any serious OIC implementation, a well-designed Global Fault Handler is non-negotiable.
FAQs
1. What is the difference between Global and Scope Fault Handler?
- Global Fault Handler: Handles all unhandled errors in integration
- Scope Fault Handler: Handles errors within a specific scope
2. Can we have both Global and Scope Fault Handlers?
Yes. Scope handler takes precedence. If not handled, Global handler executes.
3. Is Global Fault Handler mandatory?
Not technically mandatory, but strongly recommended for all enterprise integrations.
Additional Reference
For deeper understanding, refer to official Oracle documentation:
https://docs.oracle.com/en/cloud/saas/index.html