Fault handling in OIC by Jan Kettenis

This article discusses how fault handling in Integrations works for the Oracle Integration Cloud, and some best practices on how to use it, including consuming Integrations in Structured Processes.

Updated on August 6 2020 after discovering that in the explanation of Fault Return parts of the text were duplicated while others were missing.

Special thanks to Greg Mally of the Oracle A-Team for his valuable input.

As this is a lengthy article I will start with the conclusion including what I consider to be the best practices, so if you trust me you can stop right there

Best practice is to always put an Invoke activity in a Scope. In case you need to handle a fault in a specific way, it is sufficient to add a Default (Fault) Handler only, unless you need to handle different back-end faults differently.

In the Fault Handler use the Fault Return option to throw a fault coming from the back-end service to the consumer of the Integration for three reasons:

1. It gives you maximum control over the way the fault is returned to the consumer. For example, only with Fault Return will you be able to return the HTTP 4xx or 5xx status code from the back-end service as-is to the consumer of a REST Integration.
2. With that it allows you to wrap the fault from the back-end services in one single type of fault thrown to the consumer, making fault handling by the consumer as simple as possible. For example, in case of a modeled SOAP Fault returned to a Structured Process, it now suffices to add one single Boundary Error Event for the modeled fault to handle all business faults in the process.
3. On the Monitoring tab the integration instance that handled the fault from the back-end service is itself flagged as “Succeeded” (instead of “Errored”), which strictly speaking is correct as the integration did what it had to do (don’t blame the messenger). After all, the actual fault happened in the back-end service. So instead of unnecessarily alarming the operator of OIC (which caused no issue), Operations should look at either the consumer or the back-end service to find out what went wrong.

In other words, Fault Return is the easiest way to return faults thrown by the back-end service(s) in a consistent way. This is can be very convenient for your consumer. Read the complete article here.

PaaS Partner Community

For regular information on Oracle PaaS become a member in the PaaS (Integration & Process) Partner Community please register here.

Blog Twitter LinkedIn Facebook Wiki

Technorati Tags: SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress