Best Practices for Application Exception Notification

Help Studio
, , ,
1

Hi @ll,

I have a process that handles a lot of transactions.

Some of them run into a application exception.

Using the automatic retry of orchestrator, they get retried.

Unfortunately sometimes the retry does not help, and the transaction item stays failed.

Is there any best practice how to handle those ‘final’ application exceptions?
While there is the possibility to use the review function of orchestrator, I would like to inform the subject matter experts about the failed transaction item, so that they can use their manual fall back strategy on this specific item right after the last failure.
I cannot put this notification into the try-catch of the RE-Framework, since it would not allow an automatic retry through orchestrator.

Any ideas or experience on this issue?

Thanks in advance and regards

2

Hello @RPraschma

May I know what is the cause of the application exception? Is it like timeout from application side? Will the retry of the same activity work or do you want to mark the transaction as retry?

I’d you can fix this by retrying the same activity that caused the failure, we can simply introduce the global exception handler…

Other option is, to use the retry scope so you can retry a specific set of activities in case of failure and depending on the result, we can alert the respective people.

3

Hi @Lahiru.Fernando,

thanks for your input.

I think you misunderstood.
I am not looking for a technical solution how to handle the application exception.
For this question please consider the exception as not handeble.
It is either an application event that the developer did not catch (e.g. an unexpected pop up) or just a timeout of the application.

I just want to know how to handle the finally failed transaction item on a procedural level.

Should I write a workflow that will look through the transaction items, and handle all items, that are failed + application?
Should I integrate the subject matter experts into the orchestrator process?
Any other way I am not aware of?

Regards

4

Have you considered incorporating the global exception handler to your workflow?

You could retry the failed transaction/step immediately, rather than recording it as failed in Orchestrator. That way, you are adding a little more context to the error. So if the same error occurs after 3 retries for example, you can be sure that it is an error that can be addressed simply by rerunning the transaction and can then be confirmed as a Failure on Orchestrator.

1 Like
5

I already have a try-catch or global handle in place.
I would like to have a best pratice for a confirmed application failure on an transaction item.