Acknowledgement: Many thanks to my colleagues Sam Derbyshire and Ben Brunswick at Fujitsu for their help and inspiration for writing this post.
Happy Path – the route through a process where a developer would always like their integration token to follow.
Every integration developer
In a world without errors, exception handling would not be needed, but we do not live or work in that world. We work and operate in a world where networks break, people change OIC Connection endpoint passwords without telling you and expected results from queries are far from that!
So instead we need to think about worse case scenarios. Those “what-ifs” and circumstances that “will never happen”, but always do.
Whenever I start building an integration I do it from the perspective of “what is the worst thing that could happen?”, and think of ways to prevent that from happening…or at least give myself and the Support Techs a fighting chance to get back to a status quo. That falls into 2 basic requirements: knowing about the error, and being able to do something about it.
You see, man, we like to feel
we can get out of trouble,
quicker than we got into it.
Oddball, from the movie “Kelly’s Heroes”
Oracle give you, by default, the ability to capture exception details and have them sent to your Support email in-box of choice. This may be all that you and your customer require. You can easily configure it under:
OIC Console Home > Settings > Integrations > Notifications
Simply check the ‘Integration Errors’ box, add a list of recipients, press Save, and you’re done. The ‘Integration error report’ email will list out all the errors raised every 5 minutes.
The biggest strength to this simple approach is that it is a very blunt instrument; but that is also it’s biggest weakness. It doesn’t differentiate between what type of error it is, and OIC doesn’t give you a sub-category exception type that you can route exception notifications through to different email recipients.
Using this approach does present you with a nice email from OIC, detailing the reason for the exception. Although not the prettiest of emails, it does give you a link to the ‘Track Instances’ page so you can take a look at where the integration threw the fault.
This default ‘Integration Errors’ notification may be good enough for many customers. Not only does it alert you, but it puts the ‘unhandled exception’ into the Errors page in OIC (Home > Monitoring > Integrations > Errors), and from here you can Abort or Resubmit the process if allowed, and if the Integration is in right Active state.
What if we wanted to send a nicer email? What if we wanted to only send an alert under certain circumstances? Let’s explore a bit into those questions. I created 4 simple test Integrations, and I’ve left the seeded ‘Integration Error’ notification on for each case, and set the REST service invocation (ping Connection) to fire a GET request that will always fail with a HTTP 406 error.
No Handler (Test 1)
Let’s consider an integration with no specific exception handler.
The above integration process contains no Scopes, nor any Global Fault handling. As basic an Integration as you can get.
Global Fault Handler Only (Test 2)
The same basic integration as above, but this time with a Global Fault defined.
The Global Fault just sends a notification email to a user, with some custom information.
Scope Fault Handler, With Global Fault (Test 3)
For Test 3, we add a Scope around the pingConnection invoke.
We have a Global Fault defined, as we did for Test 2, and this if is exercised it will send a notification. We also have for Test 3 a Fault Handler for the Scope set around a possible REST service API Invocation Error.
In the Fault Handler for any possible API Invocation Errors, we have a notification configured.
Scope Fault Handler, with Rethrow and Global Fault (Test 4)
This next pattern is similar to the above, but this time the Scope Fault Handler for the API Invocation Error has a ‘Rethrow’ action.
Testing: The Results
The table below shows the results we get under the various exception handling scenarios.
The scenario that is of greatest interest to us is the integration that has a Scope Fault Handler, but no Rethrow action. Oracle Integration Cloud takes the view that if you handle an exception in a integration then you must know about it, or at least expected that it was a possibility. That means that if you handle an exception in a flow then is it really an exception? You expected, and then handled, the unexpected – job done!
As the ‘Scope Fault Handler, but no Rethrow action’ is classed by OIC as ‘not really an exception as you have handled it’, it also does not add it to the Errors page under Monitoring. Only the Integrations that throw unhandled, or rethrow exceptions end up there.
The other thing of note is what the ‘Rethrow’ action does in reality. It throws the exception up to the next level, whether that is a parent (outer) scope, or up to the Global Fault handler (if there is one).
The image above shows a scope within a scope (Outer Scope). Each scope having a Fault Handler defined, and both rethrowing the exception up. The Inner Scope (the APIInvocationError fault handler) rethrowing it to the Outer Scope, then the Outer Scope rethrowing it via its Fault Handler (inset in the above image) to the Global Fault handler.
Summary
Choosing the right exception handling strategy is not easy. Each integration pattern and connection may potentially give you cause to think about ‘who needs to know?’, ‘what do they need to know?’ and ‘do we need the ability to abort or resubmit’ the failed Integration (if possible).
I hope that this small detour into the world of fault handling in OIC is a useful reference for you.
Until next time…
Note to self 