Skip to Content
Author's profile photo Sujit Hemachandran

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.

 

Exception_Palette.JPG IntegrationFlow_Exception_eg.JPG

 

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.

 

Content_Modifier_Message.png

Observe the following:

  1. We have included the following tag ${exception.message} in the Content Modifier step.
  2. We have used Message End in the exception sub-process.

Message_End_event.JPG.png

So – when we send a SOAP message, we get the following response:

Message_end_payload.png

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.

 

Error_end_payload.png

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 –

Exception_Folder.JPG

That is all for the exception sub-process! Try it out, and let us know if you have any questions.

 

Best Regards,

Sujit

Assigned tags

      16 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Che Eky
      Che Eky

      Very good to know. Thanks for sharing

      Author's profile photo Sujit Hemachandran
      Sujit Hemachandran
      Blog Post Author

      Hi Che,

       

      Thanks for the nice comment.

       

      Best Regards,

      Sujit

      Author's profile photo Former Member
      Former Member

      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

      Author's profile photo Former Member
      Former Member

      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

      Author's profile photo Kevin Dekker
      Kevin Dekker

      Also is it possible to catch the exception and continue the remaining process/pipeline steps in the process flow ?

      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:

      1. Store original body in property & overwrite body with: e.g. <message></message>
      2. Split on //message & uncheck the box: ‘stop on exception’
      3. Do everything required in your local process.
      4. End with a ‘gather’ (in this case, the gather will only ‘gather’ one message’)
      5. Add exception handling, ending with a message end and processing it as you’d like

      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

      Author's profile photo Rafael Chagas
      Rafael Chagas

      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

      Author's profile photo Former Member
      Former Member

      Thank you Sujit for the detailed information.

      Author's profile photo debasis mohapatra
      debasis mohapatra

      Really really helpful as i am starting with HCI.

       

      Regards,

      Debasis

      Author's profile photo Devaraj R
      Devaraj R

      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

       

      Author's profile photo Former Member
      Former Member

      Hi Devaraj,

      Did you get any solution for the above requirement. I have same requirement.

       

      Thanks & Regards

       

      Author's profile photo Former Member
      Former Member

      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 ?

      Author's profile photo Daniel Weinberg (DUSER)
      Daniel Weinberg (DUSER)

      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).

      Author's profile photo Former Member
      Former Member

      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!

       

      Author's profile photo Daniel Weinberg (DUSER)
      Daniel Weinberg (DUSER)

      Thank your for your feedback 🙂 I will give this a try.

      Author's profile photo Former Member
      Former Member

      Hi Daniel,

       

      Did you solve this? I still didn't get the last part of Pawel's explanation.

      Author's profile photo J. Evertse
      J. Evertse

      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 ?