Hello,
I have query regarding the number retry happens in REFramework.
Assuming the below values, How many time will it retry?
Retry Value in Config : 3
Retry Value in Orchestrator : 4
Thank you in advance for any help you can provide.
Regards,
Geet M
The Queue retry is a different mechanism as the REF. Essentially when a queue item changes to Failed status, Orchestrator will set it to Retried status and add the item again as New status, so your process can pick it up again.
The Retry mechanism in the REF will retry the item but not trigger the Retries in Orchestrator. So let’s say you retry an item 3 times in your code then it changes to Failed, then Orchestrator will set it as Retried, and when your process picks up the item again, it will peform retries 3 times again. It would basically do 9 retries (3 times 3), because you would have your Queue do 3 retries and the code would do 3 retries. I think many devs will have the code set to not do retries and let the Queue handle. On the other hand, I believe the localized retries along with the Queue retries is actually a good way to go about it, because some processes require many retries and will clutter up your queue. So, by setting your code to retry let’s say 5-10 times and have a lower retry for Queues, will allow it to handle those random application exceptions locally, and if it still fails, then attempt to process the item potentially on another machine or robot user.
Hi @iamgeet,
So think of the retry in this way in REFramework.
Your queue setting is at orchestrator and if robot has a value for retry in your config file the robot will choose your config retry value. The closest value (file closer than orchestrator)
So the robot in your case will do 3 retries + 1 original try per item.
If you did not use config file setting then it would have done 4 retries + 1 original try per item.
When I tried, it was considering the orchestrator value.
And, I am not get sure what is the correct answer to my question.
As you said,
The Retry mechanism in the REF will retry the item but not trigger the Retries in Orchestrator.
So let’s say you retry an item 3 times in your code then it changes to Failed, then Orchestrator will set it as Retried, and when your process picks up the item again, it will peform retries 3 times again.
It would basically do 9 retries (3 times 3), because you would have your Queue do 3 retries and the code would do 3 retries.
So, my query here is “the code would do 3 retries” means it is picking value from config or we as developer has handled to retry for 3times?
Moreover, my query was what if we have retry value in the config file also to retry.
Hi @iamgeet,
I spoke too soon. There is an additional layer of logic which I skipped to mention, but the config file gets the last say on retires in REFramework and not the queue settings.
You can refer to the RetryCurrentTransaction in the REFramework and its inputs and outputs.
Background
QueueRetry
io_RetryNumber
Further both QueueRetry and io_RetryNumber are sent to RetryCurrentTransaction.xaml
RetryCurrentTransaction
First checks if the Config max retry is larger than 0 Convert.ToInt32(in_Config("MaxRetryNumber"))>0 if yes
Then it checks io_RetryNumber >= Convert.ToInt32(in_Config("MaxRetryNumber"))
Only if the previous check failed, i.e. io_RetryNumber is lesser than MaxRetryNumber will the queue settings end up incrementing io_RetryNumber with 1
Answer:
So coming back to your question. Config values trigger all the main retry logic in REFramework.
If you want queue retry setting to be the main retry logic, you have to set MaxRetryNumber = 0 in config.xlsx. This is also shown in the description.
You can sure decide which one you want to use (we generally ignore the queue settings)
If you choose Orchestrator Queue Setting = x retries, then remember to set config —>MaxRetryNumber = 0
If you choose config file to set MaxRetryNumber, just ignore the Queue Setting for retries, it will be ignored anyways in REFramework.
Hope this clears your doubt. I know its a lot to take in, but you can refer the screenshots.
Hi @iamgeet,
If you are using queues, you need not mention any value in config file, value specified in orchestrator will get picked. Even if both are specified, still queue value would be given preference when used.
This value in config is only required when there are no queues and in that retry is required for system exception.
I am also attaching Re-framework documentation file below, this will help you understand its working more in detail, you can go through this, would be helpful to gain deep understanding on re-framework working.
REFramework documentation.pdf (507.8 KB)
Regards
Sonali
Thank you all for your inputs.
Lastly, When I tried after keeping the values both in config as well as orchestrator, just to understand which value the robot picks for retry in this given scenario.
So, yes the REFramework considered the value mentioned in the orchestrator instead of config.
Regards,
Geet M
Hi @iamgeet,
Glad to hear that 
Now that this issue is resolved, I would suggest to mark solution so this topic can be closed.
Regards
Sonali
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.
