CPI is a wonderful technology for B2B scenarios helping us connecting different systems, organize and transform data. As with connecting different systems, we may also at times need to process exceptions when things don’t follow the way we expect them to.
This blog provides a beginner level insight into handling an exception in CPI.
CPI has the capability to handle exceptions. However, the way the exceptions are handled may be a little different than a beginner might expect. It was definitely different than what I expected 🙂
As a traditional ABAP developer, I was expecting to catch the exception and route the control to the subsequent steps in the main iFlow. But, exception handling in CPI by design does NOT return to the main flow after an exception is raised.
For example, in the below flow, I’m expecting an exception at “Get gvCounter” step. But once the control proceeds to Exception process, the control does not return to the main integration flow to process the rest of the steps.
Solution option
How could the exception sub-process be routed back to the main flow?
One solution option is to group the subsequent processes in the main flow into a sub process and invoke the sub process within the Exception flow.
By granularizing the main process into sub processes, we can deviate the exception flow to process the remaining steps in the Integration flow.
Overview of the steps
- Define the rest of the process flow as a local integration process as “remainingFlow“
- invoke the “remainingFlow” from the exception handling flow
- Add another step to invoke “remainingFlow” after the step that throws the exception. This is because we need the “remainingFlow” to be processed even when there is no exception.
Step 01 – defining the “remainingFlow”.
Step 02 – Define an exception process and invoke “remainingFlow” from the exception process.
In my example, I’m expecting an exception at the Get persist variable step “Get gvCounter”. So, I’m defining an exception handling process to handle the error when the variable gvCounter is not persisted before.
Step 03 – I also need to make sure that the “reminingFlow” is processed even when there is no exceptions.
So, I’m invoking the “reminingFlow” in my main flow as well.
After deploying, we can see the remainingFlow is invoked irrespective of whether there is an error or not.
Concluding Thought
The solution discussed here could be one among the many options. Any experienced developers are welcome to suggest any other methods you know to process the rest of the Integration steps after an exception is raised.
Also feel free to comment any SAP blogs or learning paths that would help learning Integration suite.
Here are some helpful links that I follow to learn Integration Suite: