OIC Gen 3 - Error handling | OIC Error Hospital | Global and scope level fault handlers | Fault and End actions

Why we need to implement error handling / designing beyond the happy path:

• What happens When don't implement fault handling logic of any kind. By default every error occurs runtime, deliver to the OIC error hospital which is part of the oic runtime environwmnt, hosting all your deployed integrations, this can include any faults like runtime or business faults, request timeouts, invalid payloads, internal error etc.
• When error hospital catches a fault,  the integration flow stops or terminated immediately
• If you work on the projects, it will show on the observe page.
• If the integration is sync app driven and fault happens, the error hospital sends the same fault details to the client.
• All the errors are visible in the visibility secrion >> error page.

Instead of allowing the error hospital to catch every fault, we can intentionally catch all fault using the global and scope fault handlers.

Best practice Examples of error handling:

1. Log the error but continue with the integration flow.
2. Invoke a secondary service for backup processing.
3. Log the error and then terminate the integration flow
4. Invoke another service for notification or error handling processing.
5. Reply to the integration glow's client with a custom error response.
6. Send an email notification to an external stakeholder or an internal administrator.
7. Invoke an OIC  process to initiate a process workflow involving manual intervention.

Implementing Global Fault handler:

1. By default, there is default global fault handler, where it has re-throw fault action which rethrows the fault to OIC error hospital.
1. All uncaught faults and errors go to global fault handler
2. Throw new fault from scope fault handler
3. Re throw fault from scope fault.handler.
2. Change the default handling logic apt for your integration like 
1. add logger, 
2. email notification.
3. Map custom data for a fault return for sync integrations
4. Mitigate the error contion with alt logic
5. Invoke an error handling service(another oic integration or external service)

Global fault handlers End actions;

1. Re throw fault : it will send the fault to error hospital, 
2. Throw new fault: it will send a custom fault details to error hospital
3. Stop:  Terminate the integration flow, no error hospital will be involved. Separate fault handling logic wii be there before the stop action.
4. Fault return:  explicitly sending the business faults to the client for sync service. No error hospital is involved.
5. Return : fault mitigation logic, invoking a backup service, then send the normal.data to the client. No error hospital is involved.

For each invoke , try to create a scope and define scope fault handler.

Faults occurring within handlers are caught up by the next higher handler.

Inner scope >> outer scope >> global >> error hospital

Scope or global fault objects will be created to fetch fault details in the failt handler.

Note: 

For my project, I have followed as below:

1. For each invoke>> take it in one scope and in the default fault handle >> throw new fault with code, reason and details.
2. In global fault handler >> we have send the the global failt details to data dog SaaS application for further support.
3. We have created a lookup like common_error_details_lookup where it captures the key, error type, error code, reason and details. Using the key like 'UCMUPLOADFAILED' we can fetch custom error details.