When using Orchestrator Queues I want to update log and send email when hitting last retry on system exception

[charliefik (Clark Coleman)]

Hi All,

I have a process which is picking items from an orchestrator queue. The process should send an email to support and update a log file saying item failed and the exception.message etc. but only if the item has hit the MAX number of retries.

I was going to put the email and update code into the exception catch of the try-catch in the process transaction state of the framework.

In there is a SetTransactionStatus

In SetTransactionStatus there is something that determines if you are using orchestrator queues

and then defining what the retry number is.

After that there is a RetryCurrentTransaction component which does check whether the max retries have been reached (down the left hand side path).

But this is based on the config file MaxRetryNumber which should be set to 0 for orchestrator queue based processes (should be using the queue retry value in orchestrator to determine how many retries). Also that path will never be taken because the top decision box determines whether the left branch will be entered based on the same MaxRetryNumber from the config which again will be 0 for orchestrator queues.

I can’t see anywhere that is checking to see if we are on the last retry of an orchestrator queue item.

So finally my question is where do I put code that I only want to run when it is the last orchestrator queue retry (NOT non orchestrator queue item retry) and do I have to add another config max retry number value for orchestrator queue based processes for this situation? (something like OrchestratorQueueMaxRetries in the config file as I don’t know how to extract that value programmatically from orchestrator)

Many thanks (for reading through all that)

[Jeroen_van_Loon]

The trick here is detection.
If you use the Orchestrator retry mechanism, not the config variation which is used in the workflows as you posted, it is the orchestrator which is creating the new queue item when the set transaction status is set to failed, and changing the failed status to retried.

Transaction 1 (New)
→ get transaction item
Transaction 1 (in Progress)
→ epic fail
Transaction 1 (failed)
→ Orchestrator checks retries
Transaction 1 (retried)
Transactin 1.2 (New)

etc etc.

This is not checked in the REFramework, since from its point of view it is just a new queueitem, with the same reference.

You can build in your own part in the robot retry sub-sequence. The branch you are looking at is the top right branch: retry transaction → No (cint(in_Config(“MaxRetryNumber”))>0)

There you can build a check by using a get queueitems activity, using your current reference as a filter, and use some sort of count on either failed or retried status and deduct if it is the last or not. (You should know the retry threshold from your queue configuration).

After that t is a simple set of activities to log/mail your exceptions.

[charliefik (Clark Coleman)]

Hi Jeroen,

Thanks very much for the suggestions.

I think for me the easiest way is going to add another config item OrchestratorMaxRetries and just set that to the same value as the retry number in Orchestrator, and then in set transaction status I will check the io_RetryNumber and see if it is greater than Cint(in_Config(“OrchestratorMaxRetries”).tostring) at which point I will do the email and update log file etc