HCI: Proceed work after exception raised and handled

[cca4c]

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?

Best regards!

[former_member572840]

Hi Christopher,

were you able to resolve this issue?

Currently I'm searching for same thing and got nothing.

Best regards,

Roza

[UdoPaltzer · Accepted solution]

Hello together,

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

Best regards, Udo

[digirolamocristian60 · Accepted solution]

Hello Udo,

I was wondering whether after 2 years SAP planned to enhance SCPI capabilities to handle exceptions in a try-catch-alike way. At the moment if an exeption occurs within an iflow, the message terminates (no matter if you catch or let the error to occur, the message won't keep on working).

There's no standard way to avoid that unless you decouple your iflow in N iflows (so the main iflow calls a secondary iflow with a process direct connector and if an exception occurs there you can catch it but the main iflow will resume its course) or unless you code your step within a try-catch block.

Both ways detract a lot from your development.

It'd be great to have an intuitively usable exception block.

Cristian

[former_member198979]

@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 -

1. 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.
2. 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.

[Jingjie]

Hi, Hemachandan,

I am interested at your approach how the looping condition will be checked and the looping subprocess will continue running when the looping subprocess runs into error.

My scenario is as follows: I could like to implement a retry mechanism when the HTTP call to external system in the main process runs into timeout. This retry should happens e.g. 3 times. I build the looping module for the retry in the exception process in the main process. This looping module will call the looping subprocess which will set up the same HTTP call. However, when the timeout exception happens in the looping subprocess, the looping module will be stopped without checking the looping condition any more. Could you please explain in more detail how your approach could be applied to my scenario? or Does it fit at all?

Thanks in advance!

Jingjie

[christian102094]

Hello community,

I'm having a very similar problem. Here is my scenario:

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.

Best regards.

[adityawsharma]

Hi All,

I had a similar issue wherein the SCPI API to query Credentials with URL - <TMN URL>/api/v1/UserCredentials('<Credential Name>') was throwing 404 error. I need to create credentials if do not exist and move to next step to use these newly created credentials.

To get past this issue, I used Process Direct adapter, handled exception and within exception sub-process created credentials and returned to main flow. This caused the next step in main iFlow to be executed correctly.

Hope this helps.

Thanks,

Aditya

[jasonwilliams]

Hi all,

I had a very similar issue. I was making REST calls to create or update an object in a destination system. I wanted to perform an optimistic Update (as no Upsert operation/service was available) and most operations would be Updates. However whilst we can use CamelHttpResponseCode to act on the response code, the iFlow raises an exception and all subsequent processing needed to be handled in the Exception flow. Rather than put the Create call from the exception handler, I opted for a work around and perform a filtered (I can't even query the entity directly for the same reason) query before I decide whether to create or update. This is less efficient, but it works and at this point I haven't had the time to determine whether putting the Create Local process call (or equivalent Process Direct) in the Exception Handler is worthwhile or indeed feasible. Personally I don't like the idea of having nested or possibly looping functionality in an Exception handler. Perhaps it is just my Java development background asserting itself, but it doesn't seem like the correct thing to do. Maybe I am just misunderstanding how exception handlers work in this scenario, but I would hope for options to continue processing in the main flow after 'handling the exception' and determining it was an expected behaviour (like missing data) rather than a technical exception.

Regards,

Jason

[christian102094]

hemachandan.as , udo.paltzer thanks for the suggestions. I tried what suggested about the loop local process with no successful results, but nevertheless I got it working by the following workaround:

Instead of using the HTTP adapter, I did the call in a groovy script, by using the httpclient and httpcore libraries of apache.

A tip in case somebody needs to use this libraries, is that the httpclient is 4.1.3 and httpcore is 4.1.4 in the HCI tenant.

[former_member456686]

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.

[Sriprasadsbhat]

Hello Chris,

Click on Splitter and uncheck the Stop On Exception.

Regards,

Sriprasad Shivaram Bhat

[cca4c]

Hi Sriprasad Shivaram Bhat,

thank you for your answer, I already checked that option, but this checkbox handles the exception processing within the splitting branches. So with your solution, the process runs to the gather step and stops there. I need a way to make the IFlow run to the designed end after the gather step.

Regards,

Christopher

[former_member27621]

We are also stuck on the same issue. Were you able to figure it out?