Robot Retry Workflow

[Kyrylo_Kondrashov]

Hello.
I am having some trouble with understanding Robot Retry Workflow in Handle System Error in Advanced Training.

So. If we use Queue, the MaxRetryNumber is must be 0. The no branch is execute, robot log no retry and increment Transaction number. But why? From Orchestrator training I understood that the failed item will be send to the Robot to be reprocessed. So is it should have a new Transaction number?

The next question is about MaxRetryNumber. Based on template logic we can work with queue and have this variable greater than 0. But in flow decision if item is queue item we just increase the Transaction number and don’t change Retry Option. Would it not make an endless loop?

Thanks in advance

[loginerror (Maciej Kuźmicz)]

Hi @Kyrylo_Kondrashov

You should look closely into the difference between the two types of retries: local one and orchestrator queue one.

Local retry is configurable in the Config.xlsx file of the framework and will cause the transaction to be retried upon system error (if configured as greater than 0 in the config file).

Orchestrator queue retry will retry the transaction based on the setting in Orchestrator, see here for more information:

Studio Activities Used with Queues

[Kyrylo_Kondrashov]

Thanks. But still I don’t understand this part of Robot Retry workflow.

It looks like we are working with Queue item without using Orchestrator. But I thought it is impossible.

[loginerror (Maciej Kuźmicz)]

My mistake, I edited out my previous comment that the transaction number doesn’t increase upon queue retry.

Basically, you are right that it is impossible to work with a queue item without Orchestrator (well, technically not impossible, but let’s not go there ).

However, the basic principles of retrying are this:

• for non-queue items, the transaction number will NOT be increased and it will simply be retried by the framework
• for queue items, the transaction status will be set to Failed and the item will have to be fetched again from the queue to be processed → this is why the transaction number is incremented at the end, as this act of fetching the queue item again will be considered a new transaction

I hope it is clearer now. This bit of flow is in the the framework slightly above the place from your screenshot and shows how it is done:

[Kyrylo_Kondrashov]

Ok. Thank you very much.

[FranciscoAraujo (F.Araujo)]

Hello @loginerror

Could you please help me on the below topic??

ReFramework - Retry queue items

at second point, after it processed, can u please check whether the status of that item is updated to ‘Sucess’ from ‘Failed’ . If the status is not updated, it will retry again [ based on no of re-try attempt ] Also try with retry attempt limit to 1 in orchastrator and 0 in config file and check please

Thank you in advance

Francisco