Hi, I have a question regarding Orchestrator queues and retries.
More specifially I’m wondering if there is a way to get “Max # of retries” (the one you set when creating a queue in Orchestrator) from within the UiPath Studio ReFramework. I’m aware that there in the Config.xls is a MaxRetryNumber constant, but to my understanding this Constant is only if you are not using Orchestrator queues… right?
When digging a bit in the ReFramework I found this check under Robot Retry in SetTransactionStatus.xaml:
cint(in_Config(“MaxRetryNumber”))>0. Where is the MaxRetryNumber initialized? Does it come from the Excel-Config or from the Queue?
The reason I’m asking is that I want to send an email when something goes wrong, but only on the final retry.
Right now I’m doing like this:
if TransactionItem.RetryNo = 1 (I have set the max retry for the transaction to 1 in Orchestrator).
– Send Outlook Acitivity
But perhaps there is a better way to do this than hardcoding the max retry no?
Hi. I think you answered your own question, because it’s in the Config.xlsx file (or should be) as a constant. There should be another variable built in the Framework that increments by 1 each time an exception occurs so that variable should be compared with the constant ( in_Config(“MaxRetryNumber”) ).
The condition could look like this: retryNumber <= cint(in_Config(“MaxRetryNumber”))
You might need to use the transition that exits from the current transaction, which should have a condition like this: retryNumber > cint(in_Config(“MaxRetryNumber”))
then you can do a Send Outlook activity
So it enters that transition if it has met the maxRetryNumber, and perform additional tasks like sending the email. This transition might already be in the ReFramework.
Also, retryNumber should be re-initialized to 0 at the start of each new transaction, if it isn’t already.
I hope that helps, but I am more of a visual person and am not exactly looking at the ReFramework as I post this. I’m hoping I can atleast provide the basic understanding of how the retry logic should work.
If you have additional questions, I can look into it further, and also if you could provide some screenshots or something, that will help us more visual people
Thank you for the fast reply Clayton. Sorry if I formulated myself badly or if I misinterpred your reply now, but english is not my primary language.
The constant MaxRetryNumber in Config.xlsx is 0, as it should be when using Orchestrator (the comment for this constant says “Must be 0 if working with Orchestrator queues. If > 0, the robot will retry the same transaction which failed with application exception. Must be integer”).
In Orchestrator I have set Max # Retries like this:
And this works, the transaction is retried once… and on the last retry I’m sending a mail by checking if TransactionItem.RetryNo = 1… which also works fine. The thing I don’t like is hardcoding “1”. But if I understand you correctly I can just do like this instead:
You can create another constant in your Config.xlsx and use that instead. Or just use the MaxRetryNumber, but you’ll need to adjust your ReFramework slightly.
In any case, “MaxRetryNumber” in cint(Config(“MaxRetryNumber”)) should be found in the Config.xlsx file, and you can use any name for it in the Excel file.
Since you are using the Queues, I see that .RetryNo represents the Queue retry I’m assuming, so what you can do is create a transition from the Process state to the Exit state with the condition that you showed right there to compare .RetryNo with “MaxRetryNumber”, then place your Send Outlook inside that transition under the condition.
That sounded like an elegant solution using transitions, I will try that. Thanks again you for your time Clayton, best regards and have a nice weekend.
Out of interest would you know if we can create queues? For instance when I run a process the bot makes a Queue in Orchestrator without me having to log into Orchestrator and create one manualy?
Hi @ClaytonM,
I am unable to understand how is retrynumber and maxretrynumber related?
Since one is related to queue and other will be used when you don’t use auto retry.
How can I check if it is the last run in case of using autoretry in queue since, we are unaware about the maximum times it will try.
Hi,
When you create the Queue in Orchestrator to be used by your project, there is a setting for Number of retries. So, that is how you set the Max number when using the Queue.
You can also get the Retry number from the transaction in the code, like TransactionItem.RetryNo
So basically, you have the option to increment the retry number during the local job run using the MaxRetryNumber, or you can turn that off and use the retry number from the Transaction and let the Queue handle it. Or, if you make optimizations, you can use both, which in many cases is more efficient - where it performs local retries as well as Queue retries.
Ya, you are right. There’s not a good way to get that Max Retry Number, but using the Orchestrator HTTP Request is probably not too difficult to possibly get that info.
For me, I’ve never needed that number. What I do, though, is detect that it’s the last transaction, then I get the Failed transactions, so I can send them in a notification.
The answer for your question was already posted by @msan . His solution is very easy and practical, and he also gave an excelent .xaml for that, so you can just download it. Give it a look at his first post on this topic.
I built my own framework because I can’t stand REF, and in my template I get the retry setting (true/false) and max retries using Orchestrator HTTP Request. Then when a transaction fails I look at the RetryNo property. This allows me to determine if a failed item will be retried by the queue, and based on this I can control whether to log the item or not, include it in emails or not, etc.
For example, why email the user that their item failed if we already know it will be retried? Only the final failure should be emailed/logged/etc.
Couldn’t agree more. We have tweaked the standard REF in my company and I added this functionnality as well. Only send e-mail for exception that reaches the max n° of retries. And in summary at the end process we send a report and there is no mention of unsuccessfull transaction if transaction is on success after a retry.