Retry Exception Case

[Anonymous]

I am trying to improve the resiliency of a process by ensuring that where certain types of exceptions arise, a new item is created within the process work queue to retry the case. Within the "Mark Exception" Object there is an Flag input to Retry the case which I have set to "true" however when the exception occurs, the process marks the exception but does not add anything to the work queue. It seems that there may be a fault with this part of the object. I do not want the case to be retried immediately therefore I would not want to simply incorporate a retry loop into the process. Can anyone offer any assistance? Thanks, Gavin

[ivan.gordeyev]

Gavin, This is caused by ""maximum attempts"" set in queue settings. You can check this by going to System Manager > Workflow > Work Queue Configuration - Select your queue and check 'Maximum attempts'. If set to one, then a new item cannot be added. Increase it to the required number and it will work. Please note, when a new item is generated, it instantly becomes locked by the process, this item you can defer until a specific time or simply by one hour using Defer with 'Now()+MakeTimeSpan(0,1,0,0)'.

[VivekMalhotra]

Above solution will work if all items with exception must be retried; however, if certain cases needs to be retried, you could unlock by ""Defer"" operation instead of ""Mark Exception"". If you need management reports of all exceptions, you could tag this item with exception information prior to defer state. Good luck.

[TetsujiJunicho]

This is informative topic!

[Anonymous]

Thanks both. Changing the WorkQueue settings seems to have resolved the issue. A decision stage is built into the process to ensure that only certain types of exceptions are retried.

[rajbhino_rajama]

If I understand correct ""Maximum Attempts"" applies to all the items configured in the queue. Can this value be configured only for specific items in the queue or using decision stages in the process based on exception is the only recommended design?

[Anonymous]

Rajbhino - thanks to others here and some further reading my understanding is that BP is configured to retry ALL exceptions if Maximum Attempts > 1. Therefore I need to build a decision to read the exception reason or type, feeding into separate Mark Exception objects with retry set to ""True"" or ""False"" as appropriate.

[Anonymous]

This functionality is frustrating me at the moment. I seems that if you set the maximum retries to greater than 1 then BP will retry ALL exceptions regardless of what settings you have.. For instance Set Exception at Cleanup causes an item to be retried. I have a decision stage on our exceptions path to determine if an item about to be marked exception should be retried, and I have two Mark Exception stages, one with Retry True and one with Retry False, and if the bot actually follows this path then it works fine, but I do NOT want exceptions at cleanup to be retried. Those could be at any stage in the process! We bubble up exceptions and catch them on the main page to take them down an exception handling path, but of course exceptions set at cleanup do not follow this path. I wonder if that is the only thing I need to cater for, or are there other scenarios where BP is going to retry an item without express permission? This functionality could really be improved. I want total control over what items get retried. Otherwise I need to look at a different solution for this, and defer is not a good option because it messes up reporting.