Hi,
Someone please tell me how retry mechanism works in a very simple way in RE-Framework?
I’m really confused on this!
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.
1 Like
Hey sorry, I not asked the definition. I need the logice they are using RE-Framework. Which i can explain easily in Interview!
- Retry Scope: A Retry Scope is set up in the RE-Framework around activities that might fail due to temporary issues like network glitches, web page loading delays, etc. The Retry Scope contains the activities that need to be retried if they encounter an exception.
- Configurable Parameters: The Retry Scope is configured with two main parameters:
- Retry Count: The number of times the activities within the Retry Scope will be retried.
- Retry Interval: The time delay between each retry attempt.
- Exception Handling: When an activity within the Retry Scope encounters an exception (e.g., timeout, element not found), the Retry Scope catches the exception.
- Retry Attempts: The Retry Scope then retries the failed activity based on the number of retries specified in the Retry Count parameter. It waits for the specified Retry Interval before attempting the next retry.
- Success or Failure: If the activity succeeds within the allowed number of retries, the automation continues with the next steps. If the activity continues to fail even after all retries, the automation flow follows the exception handling process (logging the error, taking a screenshot, etc.) and moves on to the next part of the workflow.
- Handling Endlessly Failing Activities: In practice, the Retry Count should be carefully chosen, as setting it to an excessively high value could lead to an endless loop of retries for an activity that is consistently failing due to an unrecoverable issue.
When you are creating the queue you can provide the Max of retries in the Orchestrator.
Check the below image for better understanding.
Hope it helps!!
In RE-Framework, the retry mechanism can be configured both in the Config file and in the Queue items.
- Retry in Config file:
- In the Config file (Config.xlsx), you can define the maximum number of retries for a specific transaction. This means that if a transaction fails, the robot will automatically attempt to retry it a certain number of times before moving on to the next transaction.
- Retry in Queue items:
- In the Queue items (Queue.xlsx), you can also set the number of retries for individual transactions. This allows you to customize the retry behavior for different types of transactions or processes.
By combining these two retry mechanisms, you can control how many times the robot tries to process a failed transaction, ensuring that the automation is robust and can handle temporary issues or errors gracefully.
To understand properly just open retrytransactionstatus.xaml and see the xaml…
It has only 4 conditions in it
First check if retry number is provided in config or not
If provided will check if the current retry number is max or more retries are there
If more are there then it check if it is queue based retry or a config based…if queue based retry is taken care in queue and it would increment transaction number…if config based it would incremnet retry number but not the transaction jumber so that same transaction repeats again
Just have a loom at reuired xaml and it would be clear
Cheers
2 Likes