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 continue to look at exception/error handling mechanisms to capture and manage integration faults. In particular, we will look at the Scope 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: Global Fault Handler
• 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.

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, following my post about global fault handlers (here) it’s important to consider… what if we want to iterate through many records and must continue even if one of these records fails? i.e, you don’t want your integration flow to stop where an error to an individual record occurs – there is no sequential processing requirement perhaps. Instead, we want it to move on to the next logical step within the integration flow.

To achieve this, we can use the fault handler at scope level. The scope of the integration flow activity can catch the error and move ahead, avoiding the previously seen abrupt termination of the flow. The diagram below shows this:

NOTE – Even if an action is inside a scope, if the error is not handled by the scope the error will propagate out to the global fault handler as we saw in my earlier post

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 Scope Handler	Yes, From the Global Fault Handler	Yes
02	Scope Fault Handler	Yes, From the Scope Fault Handler	No

No Scope Handler

In the below integration flow, we:

1. Assign a value to a variable
2. Enter a scope which iterates the following logic in a while loop (where variable is <=5):
   • IF the value of the assigned variable is equal to 3 THEN invoke the FTP adapter (which will fail)
   • ELSE increment the value of the assigned variable by 1
3. Complete flow (same as the diagram above)

I have not defined any logic in the scope fault handler (therefore it is empty), but I do have a custom email notification configured within the global fault handler. 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 received a notification email, but it is from the global fault handler, not a scope fault handler (because I didn’t define one) – which means that test #1 is successful.

Below, we see the flow failure:

Here we see the execution of the global fault handler:

Here we see the email generated by the global fault handler:

Scope Fault Handler

Next, I use the same integration flow logic in which I:

1. Assign a value to a variable
2. Enter a scope which iterates the following logic in a while loop (where variable is <=5):
   • IF the value of the assigned variable is equal to 3 THEN invoke the FTP adapter (which will fail)
   • ELSE increment the value of the assigned variable by 1
3. Complete flow (same as the diagram above)

This time, I define logic within the scope 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 succeeded status:

Why does this happen? Well.. as I have gracefully handled the error, Oracle Integration assumes that all is under control and that the integration processed as expected. Therefore it is very important that you have a good mechanism in place to identify and deal with errors that might occur in this flow. The benefit of this approach is that we avoid the abrupt termination of the integration workflow and the other data items that are being processed can continue despite a single record error.

Below we see the flow failure:

Below we see an email generated from the scope handler: