Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 

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:

  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.

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,