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.

clip_image003 Blog clip_image005 Twitter clip_image004 LinkedIn image[7][2][2][2] Facebook clip_image002[8][4][2][2][2] Wiki

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

About Jürgen Kress
As a middleware expert Jürgen works at Oracle EMEA Alliances and Channels, responsible for Oracle’s EMEA Fusion Middleware partner business. He is the founder of the Oracle SOA & BPM and the WebLogic Partner Communities and the global Oracle Partner Advisory Councils. With more than 5000 members from all over the world the Middleware Partner Community is the most successful and active community at Oracle. Jürgen manages the community with monthly newsletters, webcasts and conferences. He hosts his annual Fusion Middleware Partner Community Forums and the Fusion Middleware Summer Camps, where more than 200 partners get product updates, roadmap insights and hands-on trainings. Supplemented by many web 2.0 tools like twitter, discussion forums, online communities, blogs and wikis. For the SOA & Cloud Symposium by Thomas Erl, Jürgen is a member of the steering board. He is also a frequent speaker at conferences like the SOA & BPM Integration Days, JAX, UKOUG, OUGN, or OOP.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: