Error Handling in Oracle Integration Cloud

Working with customers, I get a lot of queries about Error Handling capabilities that are available in Oracle Integration Cloud. This blog will introduce you to different actions and aspects available out of the box.

The following two integration patterns are the most common patterns when we are designing integrations in OIC and they have different requirements when it comes to Error Handling. Its important to understand these aspects before we look at the OIC capabilities.

i)???????????????????App Driven Orchestration

ii)??????????????????Scheduled Orchestration

App Driven Orchestration

Orchestrated integrations can be synchronous or asynchronous types.

• Synchronous Integrations need to send a response back to the invoker as there is a requester awaiting response. These integrations, in case of error are not recoverable using OIC Error Hospital. In an error scenario, you might want to send back a readable error message. Or you might wish to just handle the error, raise an internal notification and send back a success message. e.g. you are getting new customer details, error is due to unavailability of the downstream system. You might persist the payload in a data store like database, kafka queue, file etc. and send back a success message. And have another service that is getting the data from data store and retry.
• Asynchronous Integrations: When you create an app driven orchestration such that it does not have any response, these are asynchronous integrations. As soon as the trigger receives the message, it returns a 202 Status Accepted Response to the invoker regardless whether the integration completed successfully or error out. These errors from an asynchronous integrations can be resubmitted using OIC Error Hospital, resubmission success will depend on the error type e.g. if the third party application was not accessible due to an outage, once the application is up you resubmit this and it shall complete successfully. Or an application error was thrown that you fixed in application and later resubmit the error.

Scheduled Orchestration

Scheduled Orchestrations are started at a certain predefined time/schedule or submitted manually/via API. From an error handling perspective they behave like Asynchronous calls i.e. there is no invoker application/user waiting for a direct response. Errors can be resubmitted by the OIC Error Hospital. Success of these resubmit will depend on the type of error just like we discussed above.?

In OIC we have fault handlers, think of it as try/catch. There are two level of fault handlers one at the Scope level and the other Global Fault Handler.

Scope Level Fault Handler

The scope action is essentially a collection of child actions and invokes that can have their own fault handlers. Specific fault handling (Catch a specific fault) e.g. Database level fault handler will only catch database related errors. Default Handler (Catch All), this will catch all faults. If you have not built a logic in specific fault or there is an error that has not been caught in specific fault, it will be caught in default handler. Please note, in the case of connectivity agent-based invokes, the named fault handlers are not executed. All fault handling must be done in the default fault handler. Also any variables created inside a scope action or a looping action are not directly accessible outside the scope, if you wish to set variables in a scope and want to access it outside scope, use Global Variables.

Global Level Fault Handler

Available at the overall integration flow level which acts as a super catch block. Any errors un-handled at the scope level will bubble up to the global fault handler. This functionality enables you to direct business faults back to the caller or apply business logic before sending faults to the error handling framework.

Actions in Fault Handler

Almost all Actions can be called in Fault Handlers. You can build complex logic using collections (For, Switch, While), call other integrations, processes, applications & databases, throw a different error or just return a success message. Check for various possible error codes and conditionally perform actions. Invoke a downstream endpoint and notify it of errors. You may locally invoke a process flow in Process Automation to initiate a workflow involving manual intervention for exceptional flow and resubmit the integration after fixing the data issue via process. It depends on your requirements, fault handlers allow you to build as sophisticated error handling logic as you would like as almost all actions that you use to build integration can be used here to build your error handling logic.

?Now let’s looks at some of the Actions that are specific to Error Handling framework.

Re-throw Fault Action

Re-throw fault as name suggests mainly catches the fault and throws it one level up e.g. if the integration contains a defined global fault, the error captured by the re-throw fault action in a scope fault handle will send it through the global fault. You can send failed messages to the error hospital for further analysis with a re-throw fault action. The re-throw fault action can only be placed inside the fault handler section. Integration flow gets terminated at Re-throw fault action.

Throw New Fault Action

Throw new fault allows you to create and throw your own faults in an integration e.g. you have a business error and not a technical error that you would like to return as an error. Throw New Fault action can be added anywhere in the integration. In this activity you need provide Code*, Reason, Details and Skip Condition.

???????Code is mandatory field.

???????Skip Condition allows you to provide an expression that if true the Fault will be thrown otherwise this activity is skipped and integration continues to the next action.

Fault Return Action

This returns a fault to the invoker. This activity is only available for synchronous integrations as with asynchronous flows there is no caller to return a fault to. If a trigger defines multiple faults, you are prompted to select a fault and then a mapper is added with that fault. Fault Return can be added to Scope, Fault Handler and Global Fault. It terminates the integration and return the mapped/defined fault to the invoker. You can use this activity to send a custom Error Code e.g. 404 Not Found Error instead of default 500 Internal Server Error that OIC returns in case of error.

Return Action

This returns an immediate response i.e. success back to invoker. This activity is only available for synchronous integrations as with asynchronous flows there is no caller to return a response to. You can handle error and still send a successful response i.e. 200 OK back to invoker if that is your requirement.

Stop Action

This stops the integration and returns a 202 accepted status code back to the invoker. No return message is sent to the trigger. This activity is only available for asynchronous integrations. This activity can be used anywhere in the integration and used to terminate the integration flow.

Resubmit Failed Messages

In OIC Monitoring -> Integration -> Errors you can manually resubmit failed messages. Oracle Integration does not automatically resubmit failed messages. Although you can create an integration and build a resubmit logic using APIs. Resubmission starts from the beginning of the integration.?Only asynchronous integrations can be resubmitted, synchronous integrations cannot be resubmitted. Resubmit can happen in following ways.

???????Single failed message resubmissions

???????Bulk failed message resubmissions

Once the error integrations are resubmitted and completes successfully, they no longer are visible in Monitoring -> Integrations -> Errors but you will have to go Monitoring -> Integrations-> Tracking to see their status. In case after resubmit it fails again you will find the information in Error tab.

Conclusion

Here we have tried to give you an overview of different actions and activities available in OIC when it comes to Error Handling. It is important when you are starting a project, give consideration to your error handling strategy. From OIC perspective while it provides ample actions and activities that shall allow you to build error handling framework, it comes down to the development team how best to utilize these for the said requirement.