Blog 4: Modelling Exceptions in Integration Flows (SAP Cloud Platform Integration)
Hello Integrators!
In this blog, I shall explain how to model exceptions in Integration Flows.
What is Exception Handling?
On a technical definition, exception handling is the process of responding to the occurrence, during message processing, of exceptions. There exists scenarios where you want to control the exception process. For example, during a message processing you want to log all the exceptions in a specific location or server; or you want to modify the exception message sent back to the receiver; and so on.
An exception is handled by saving the current state of execution in a predefined place and switching the execution to a specific subroutine known as an exception sub-process. Exceptions can occur during any of the message processing step – Mapping execution error, Content Routing error, and so on.
How To Model Exception Handling in SAP Cloud Platform Integration?
You model exceptions as a sub-process in the integration flows. To add an exception sub-process to the integration flow, choose Exception Subprocess from the palette. And drop the sub-process into the integration process. Note: The sub-process should not be connected to any of the elements of the integration flow.
In the Integration flow above, when any exception occurs in the message processing – the sub-process is executed.
How does the Exception sub-process work?
Consider the integration flow that we just saw: A SOAP sender sends messages to the integration flow (It is designed to fail at the mapping!) . When an exception occurs in the message processing – the sub-process is called. In the sub-process, we modify the details of the fault message.
Observe the following:
- We have included the following tag ${exception.message} in the Content Modifier step.
- We have used Message End in the exception sub-process.
So – when we send a SOAP message, we get the following response:
Again, observe the following:
- The response comes in the SOAP Body
- You can get more details on exception using ${exception.message} or ${exception.stacktrace} elements.
If I change the End Message to an Error End, the response structure shall change. The exception shall go as part of the SOAP fault message.
Optionally, you can choose to send the exception message to another endpoint.
Example – the sample integration flow we just saw has been modified to to send the exceptions to an SFTP location –
That is all for the exception sub-process! Try it out, and let us know if you have any questions.
Best Regards,
Sujit
Very good to know. Thanks for sharing
Hi Che,
Thanks for the nice comment.
Best Regards,
Sujit
Hi Sujit - If I want to have multiple exception blogs on particular pipeline step is that possible if so how to invoke the appropriate exception block in that case ?
Also is it possible to catch the exception and continue the remaining process/pipeline steps in the process flow ?
Thanks Again
Rajesh
Hello Rajesh,
You can try using the gateway step to check the exception details and handle it differently in one single exception handler, as it is not possible to add more than one exception handler to an iFlow.
Also I do not think it is possible to continue alternate processing flow in case of an exception, you may try adding the required processing steps inside the exception handler itself and see if it works for you.
Regards,
Diptee
Yes, this is possible. Assuming the exception occurs in a local process while the further processing required occurs in the main process, one can use a splitter in the local process. Steps:
Your message (as returned from the exception handler) can now be continued to process on in the main process.
If you actually have to repeat steps within your local process you can just split on your resource. E.g. if you have a body: <message><resource></resource><resource><resource/></message> split on resource.
Note that if stop on exception is checked, you cannot proceed with processing your message in the main flow.
Kind regards,
Kevin
Kevin,
Your proposal was perfect.
I have an IFlow that requests a register using a GET method for a HTTP REST service to find if it exists in legacy system, then i have to insert (POST) it or change (PUT) there but the GET method raise a 404 error when the register doesn't exists.
To solve it, first I tried to use the exception subprocess but even if the register was created successfully after the POST method, the final message body was the Error 404 raised on GET requisition.
Then I used the Splitter and Gather with the GET request between then, like you told before, and thats worked fine.
Thanks a lot for helping.
Thats solved my problem.
Regards
Rafael Chagas
Thank you Sujit for the detailed information.
Really really helpful as i am starting with HCI.
Regards,
Debasis
Hello Sujit and Everyone,
We have requirement as below.
we have around 60+ integrations in our tenant and mail notification should be triggered immediately to our support mail box when each message failure occurring in HCI for all these integrations.
Any other ways to configure this Exception sub process in common place/integration in HCI tenant and accessing this in all these integrations, instead of configuring this Exception sub process explicitly in all these 60+ integrations.?
Plz let me know if any other solutions as well if it will work out here.
Regards,
Deva
Hi Devaraj,
Did you get any solution for the above requirement. I have same requirement.
Thanks & Regards
What about handling an error and continuing the process?
We process multiple records in one iflow using a general splitter - however some of them may fail in the target system.
If I catch an exception returned by the target system (soapfault) in my exception subprocess I have to end it with either End Message or Error End - which in both cases will stop further processing! And I do not want that - I want to send an email from within the exception subprocess and move on to the next item in my splitter - is that not possible in HCI ?
Did you solve this? I am facing the exact same issue and do not fine a solution to it. Especially, because a gather step does raise an exception as well (some XML Parsing error).
We used below solution to handle this issue:
So we have main flow (MF) which calls Target system (TS) multiple times (using general splitter). We've created additional flow (AF) in HCI which is used only for calling TS. So E2E it looks like:
MF -> AF -> TS
Now, whenever TS returns an error, AF catches this error in Exception Subprocess and prepare nice response for MF. Something like:
<AFresponse>
<status>ERROR</status>
<description>${exception.message}</description>
</AFresponse>
MF checks status node and in case of ERROR we have router to send an email. If status is SUCCESS we're continuing processing other records.
Hope that helps!
Thank your for your feedback 🙂 I will give this a try.
Hi Daniel,
Did you solve this? I still didn't get the last part of Pawel's explanation.
Anyone had a situation where the exception.detail is not available? And tried to add a router condition to check for this, like ${exception.detail} = null ?