Whilst on the box, using Oracle Integration Cloud (or OCI Integration) appears very simple – it’s just drag & drop right?! - It’s important to understand the basics (and understand them well) to ensure that your design is robust. In this blog series, I am writing articles about key functionality and/or concepts within the product that are critical to the successful of your OCI Integration implementation. I should note that that most (if not all) of these posts in the series will be relevant for both Oracle Integration Cloud Gen2 and Oracle Integration 3. Where there is a variance, I will try to make that as clear as possible.

In this post, we will start to look at exception/error handling mechanisms to capture and manage integration faults. In particular, we will look at the Global Fault Handler – what it is and how it should be used.

If you have not yet seen other posts in this series, check them out here:

• Creating an Oracle Integration 3 Instance in Oracle Cloud
• OCI Integration Fundamentals: Versioning
• OCI Integration Fundamentals: Scope Fault Handling
• More to follow (I will update this post with all relevant posts once they are created)

For official OCI Integration documentation, visit here.

---

What is a Fault Handler?

When an error arises within an integration flow, fault handlers are components of the integration flow that can capture relevant information and execute pre-defined actions to handle the integration fault in the most appropriate way. Typically, fault handlers are not executed in a “happy path” scenario, but to build robust integrations, if you integration is going to fail for any number of reasons, it’s important that it does so graciously, and of course, that you are notified about it. This can improve the resilience and consistency of your integration by promoting centralized error management.

OCI Integration provides fault handlers at both a global level and a scope level. Global Fault handlers are available to the overall integration flow – they are the last resort to capture faults in your integration. If you are more familiar with other types of development then this is the “super catch block” or the “WHEN OTHER ERROR”. If there are any un-handled errors at a scope level or error that occur in logic which is not contained within a scope block, they bubble to the global fault handler (good design ensures that your errors are handled at a scope level!)

On the other hand, Scope fault handlers are used to handle errors that occur during the integration flow which resides within a scope block. You can have separate handlers for different named faults defined based on the invokes/triggers/actions within your flow logic that resides within a scope block. When you create a scope block, a default handler is also generated which can be used as a “catch-all” for that scope block. If an error within the scope block is not handled by a specific fault handler or if the fault is a generic fault, it will be handled by the default handler instead.

Note – upcoming post regarding scope fault handlers

Why is Fault Handling Important?

Of course, we do not design and build integrations and want them to have faults. A world in which no faults ever happen and exception/error/fault handling is not needed sounds like a pretty nice place to be – but, to be 100% clear – this world does not exist.

It is important that integration designers and integration developers think about all eventualities and of course, about those worst case scenarios that “will never happen” but generally you will find that they always do find a way to manifest themselves, one way or another.

Without teaching you to suck eggs (excuse the English colloquialism!), integration fault handling is crucial in software development for reasons such as:

• Maintaining System Reliability – Integration involves connecting components, services and systems that may well have their own set of vulnerabilities or potential errors. Good fault handling will help to prevent against cascading failure and therefore helps to maintain system reliability by preventing failures from propagating and causing widespread issues.
• Enhancing User Experience – Graceful handling of faults improves user experience. Rather than displaying unhelpful technical error messages or causing a solution to abruptly crash, faults that are handled well can provide error messages that are meaningful to the user.
• Troubleshooting & Debugging – Effective fault handling (and good audit frameworks – future post) aids developers and technical support professionals during development, testing and maintenance of a solution. Well-handled faults provide clear indications of where and why an error has occurred, facilitating quicker identification and ultimately, quicker resolution of issues.
• System Resilience – Ideally, systems should be resilient enough to recover from faults and continue to function as they were intended to do so in the first place.
• Error Logging & Monitoring – Fault handling is very closely linked to auditing (and good audit frameworks – future post). When a fault occurs, this should involve logging of the errors and exceptions that have been encountered which is very useful for monitoring and analyzing system health (for example, identifying patterns of failure). This can support by enabling you to introduce proactive measures which may help to mitigate similar faults in the future.

“Teaching you to suck eggs” – refers to a person giving advice to another person in a subject with which the other person is already familiar (and probably more so than the first person).

Show Me!

Before I show you, it’s important to note that in the event of a fault in an integration, the default response is to go to the “Global Fault Handler” to perform a user defined action such as notifying of the error via email and then the flow is stopped abruptly in error state. In this situation the flow will not move on to the next logical step – the diagram below shows this:

In a situation where we cause an integration flow to error (purposefully) and create logic within a fault handler which sends an email notification reporting the error, The expected outcomes are as follows:

Test #	Implemented Fault Handling	Email Produced?	Fault Shown in Monitoring?
01	No Handler	No	Yes
02	Global Fault Handler	Yes	Yes

No Handler

In the below integration flow, we first assign a value to a variable, and then use an FTP Adapter invoke, followed by a logger action (which will fail) before completing the flow (the same as in the diagram above).

I have not defined any logic in the global fault handler (therefore it is empty). So, when I run the integration – remember, I purposefully made the integration flow error – I am presented with the following screenshot which outlines an integration instance in failed status & I have not received a notification email (because I have not defined one) – which means that test #1 is successful.

Below we see the flow failure:

Global Fault Handler

Next, I use the same integration flow logic where I first assign a value to a variable, and then use an FTP Adapter invoke (which will fail), followed by a logger action.

This time, I define logic within the global fault handler which sends an email notification in the event of an integration flow failure (note this is very basic).

When I run the integration, remembering that I purposefully made the integration flow error – I am presented with the following screenshot which outlines an integration instance in failed status.

Below we see the flow failure:

But, test #2 is not successful unless I receive an email notification. You guessed it, I received one: