Hello Team,
What would be the case if we have mansion retry scope in both the orchestrator queue and config file, which is a priority here, either orchestrator queue retry or config retry?
Thank you
Minal P
@minal.patil
If both the Orchestrator queue and the config file have a retry scope defined, the priority would depend on how your automation is designed and implemented. Here are a few scenarios to consider:
- If you are using the Orchestrator queue as a source of transactions for your automation process and have configured a retry scope within the queue item properties, then the retry settings specified in the queue will take precedence. The automation will follow the retry behavior defined in the queue item, regardless of the retry settings in the config file.
- On the other hand, if you have implemented a custom retry mechanism within your workflow using the config file, and the retry logic is independent of the Orchestrator queue, then the retry settings defined in the config file will take precedence. The automation will adhere to the retry logic specified in the config file, regardless of the queue’s retry settings.
it’s an interview question.
which is a BOT to consider 1st, either orchestrator queue retry or config retry?
Hi @minal.patil
if you have a process with a large number of transactions or require fine-grained control over individual transaction retries, Orchestrator queue retry is a good choice. On the other hand, if you prefer a more centralized and consistent approach to retries, or if your process is relatively simpler, config retry can be a suitable option.
It’s worth mentioning that in some cases, a combination of both methods may be appropriate. For example, you can leverage Orchestrator queue retry for critical or high-priority transactions, while using config retry for less critical ones.
Hope it helps!!
The priority is given to the retry number given in the Orchestrator. Must be 0 if working with Orchestrator queues. If > 0, the robot will retry the same transaction which failed with a system exception. Must be an integer value.
Hope this helps,
Best Regards.
@minal.patil
In an automation solution, when deciding which retry mechanism to consider first, whether Orchestrator queue retry or config retry, it depends on the specific requirements and design of the solution. However, a general approach is to prioritize the Orchestrator queue retry over the config retry.
The reason for this is that the Orchestrator queue retry provides a built-in and centralized retry mechanism specifically designed for transactional processing. The queue retry allows you to define the number of retries, retry intervals, and other retry-related parameters at the transaction level. It offers better visibility, monitoring, and management of individual transactions, making it suitable for handling failures and ensuring reliable processing.
On the other hand, the config retry typically refers to a custom retry mechanism implemented within the automation workflow using configuration settings. This retry mechanism is more generic and can be applied to various parts of the automation process. It allows you to define retries based on specific conditions or criteria for different actions or activities.
Considering the above, the Orchestrator queue retry is often considered first because it provides transactional control and monitoring, ensuring reliable processing of individual items. The config retry can be used as a supplementary retry mechanism for broader scenarios where specific actions or activities require custom retry logic.
During an interview, it is essential to demonstrate your understanding of both retry mechanisms and their benefits. You can explain the prioritization of Orchestrator queue retry due to its specialized nature and centralized control, while also acknowledging the flexibility and customization provided by the config retry for broader retry scenarios.
Thank you sir for help.
1 Like
Thank you sir for help.
@minal.patil welcome.
Thank you for help.
This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.