soalicious: OIC - ways of throwing or handling faults

Monday, August 2, 2021

OIC - ways of throwing or handling faults

There are following 4 ways we can throw or handle fault in an integration:

No fault handling
ReThrow fault
Throw new fault
Fault return

No Handling:

This is only applicable when you don’t have any requirement to handle any fault in a special way. You just let it happen and in case of a synchronous integration let it return he fault details to the consumer.
But the concern is what fault details we are receiving from OIC that is not the actual fault as thrown by the back-end service. For example, in case the REST back-end service throws a HTTP 404 Not Found, a REST Integration will throw a HTTP 500 Internal Server Error with the actual fault code (404) “hidden” in the errorDetails.title.
There is no strict standard for it, different back-end systems may have significant differences in the way they throw faults, using different elements, providing a different level of detail. For this reason, in case of a SOAP fault a SOAP Integration will have the original fault details wrapped in CDATA,

Example of rest fault: we can see OIC is throwing error as 500 internal server error but the original fault 404 is hidden in the errorDetails.title:

{

"type" : "http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5.1",

"title" : "Internal Server Error",

"detail" : "Internal server error. Please contact oracle support for details.",

"errorCode" : "500",

"errorDetails" : [ {

"type" : "UnMappedFault:execute",

"instance" : "NA",

"title" : "Fault Details : \n<nstrgdfl:APIInvocationError xmlns:nstrgdfl=\"http://xmlns.oracle.com/cloud/generic/rest/fault/REST/GetEmpDetails\"><nstrgdfl:type/><nstrgdfl:title/><nstrgdfl:detail/><nstrgdfl:errorCode/><nstrgdfl:errorDetails><nstrgdfl:type>http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.5</nstrgdfl:type><nstrgdfl:title>Not Found</nstrgdfl:title><nstrgdfl:errorCode>404</nstrgdfl:errorCode><nstrgdfl:errorPath><![CDATA[GET https://jsonplaceholder.typicode.com/1users/1 returned a response status of 404 Not Found]]></nstrgdfl:errorPath><nstrgdfl:instance><![CDATA[{}.The HTTP 404, 404 Not Found, and 404 error message is a Hypertext Transfer Protocol (HTTP) standard response code, in computer network communications, to indicate that the client was able to communicate with a given server, but the server could not find the resource that was requested. Carefully re-examine the target endpoint that is being called. ]]></nstrgdfl:instance></nstrgdfl:errorDetails></nstrgdfl:APIInvocationError>\n:Application Error",

"errorPath" : "NA",

"errorCode" : "NA"

} ]

}

ReThrow Fault:

In this case the fault is thrown to the higher scope without modification. If there is no higher scope, then in case of a synchronous integration the consumer will get the fault as-is and with that the result is the same as when you did nothing.

You use Rethrow Fault when you need to do some steps before raising the fault, like populating a log message or sending an email, but you have no need for a specific way of handling the fault otherwise.

Throw New Fault:

Using Throw New Fault action, we can throw new or custom fault other than the one you caught.

This will give us the opportunity to configure the values of the errore details sub elements. We can throw fault code , reason and details to the higher scope where it will be handled. Customizing the faults, we can represent a clearer view of errors to the consumer or support folks .

In case of REST service, you can introspect the HTTP error details.title to lookup the original fault and map them accordingly.

Fault Return:

Fault returns are the same like for Throw New Fault. It provides the more control over the fault returned to the consumer.We can use fault return for the following cases: