HCI: Proceed work after exception raised and handled

Mar 23, 2018 at 11:09 AM|686 Views

Hello all,

I have a question regarding exception handling in a Splitter/gather Scenario.

I split a message consisting of several records and send the individual records to a cloud system in an extra SubProcess. In this SubProcess, an exception occurs for a record, which causes the entire processing to terminate, that is, the Gather Step is no longer called. However, the exception comes from the cloud system and occurs only sporadically. Is there a way to handle the exception within the exception sub process and continue processing so that the main process can run through to the end? At the moment, the behavior is such that processing stops completely after the exception.

I tried several approaches like using different end Message types or removing a property called "SAP_MarkMessageAsFailed" or removing all headers but nothing works.

So is there a way that the IFlow keeps working after an exception has raised?

6 Answers

I have a Looping process call that has inside an HTTP request-reply used to request the status of an object in AWS ML. When it returns OK status, the router ends the loop. The problem is that this request-reply occassionally fails because of network connection ("SSLEngine already closed").

So, I would like to keep calling this request-reply even if one of the requests fails.

Add comment

First thank you for all sharing your feedback and requirements towards these integration scenarios leveraging SAP Cloud Platform Integration and the need to continues or restart the processing of messages, e. g. after an exception process. Currently this functionality is not available. We would be more than happy to receive further information about your scenario and requirements, so that we can feed this back to our development organisation. Another option that you might consider is to leverage the retry handling via message queue handling within SAP Cloud Platform Integration; with this retry capability SAP Cloud Platform Integration will retry to process messages in case they can’t be delivered successfully to a receiver system. I understand that this does not fully support your requirements, hopefully it still helps a little bit. And BTW, the JMS capabilities are now available for any license of SAP Cloud Platform Integration, only require SAP Cloud Platform Enterprise Messaging additionally; further information can be found at https://blogs.sap.com/2018/12/12/cloud-integration-activating-and-managing-enterprise-messaging-capabilities-as2-jms-and-xi-adapters/.

Add comment

@ctapisab and Udo Paltzer - You can able to achieve your scenario like scenario 3 in the blog and instead of Content Modifier, use a Data Store to store error or Script to display error message in the Exception Subprocess also if you have multiple records in the main message then use general Splitter before this loop process in the Main Integration Process but make sure Stop on Exception is not selected in the Splitter with proper condition. One last thing to reorder your iflow like below -

It is better to decouple your Loop Local Integration Process based on your loop condition where use the Request-Reply by creating separate Local integration Process and use Exception Sub process here to catch and log.

Call this Local Integration Process has Request-Reply inside the Loop Local Integration by keeping the rest of the components in the Loop Local Integration Process.

so that message failure will be captured and continue to check the loop condition if this condition fails again then the above 2 steps will restart fresh message flow. These loop can be carried out based on your Loop Condition and Number of iterations set in the Loop Local Integration Process. I have done exactly similar in my iflow to avoid failure of Loop Local Integration Process and its working efficiently without any issues.

After a failure the processing stops and the Iflow is ended with a status 'FAIL'. I would like to be able to change status or continue processing as well. For now invoke Datastore, Queuing or ProcessDirect adapter after split. Decouple into single messages.