Prioritise Queue Retry Mechanism

Feedback Orchestrator
1

In my robots I use the REFramework in combination woth Orchestrator queues almost all the time as a standard.
It makes even simple workflows managable and predictable and it works great.

Except…
I allow a queueitem to be retried on a (system) exception. Again this works great as a basis. The downside is that sometimes I need to process my queueitems in a first-in-first-out order as a strict businessrule. Since this is the queue default supports this this, again, works great.

Though, as soon as a system error occurs, the Orchestrator turns the failed queueitem into a retried queueitem, and clones the original as the item to be retried, to the back of the queue. Therefor (virtually) killing the original upload order and disrupting my fancy first in-first out order.

I want to stay away from the ‘internal’ retry of the REF since I want to reprt on failures in the orchestrator, so for retries I depend on this mechanism. I can work around it, but not without deviating far from the REF standard. And sticking to the standards is in the long run much more sustainable in terms of knowledge transfer and maintainability.

It would be a great feature to have an option when enabling he Orchestrator Queue Retry, to set wether a retry is to be put in the back of the queue, or directly next in line of it’s original position in the queue (so 1st of the ‘new’ items).

Love to hear your thoughts on this.

1 Like
3

@Jeroen_van_Loon

Agree with you on this

There is one work aroung that you can do by using queues only…

By default I believe your queue items are added with normal priority…

Instead of using queue auto retry mechanism…use a different queue addition of the failed items …

  1. Create a specific content in the queue item say retrycount and first time make it 0

  2. in the process transaction state inside the system exception catch block or in the set transaction status xaml, system exception sequence …you can include a if condition to check if the retry count max is reached or notCint(transactionitem.SpecificContent("retrycount").ToString)<Cint(in_Config("maxretrycount).ToString)

  3. On then side use add queue item activity and add the same item again but now increment the retry count so retrycount specific content will be Cint(transactionitem.SpecificContent("retrycount").ToString)+1 and the priority to be set as high…so that this is picked first and if max retry count is reached then no item is added as per if condition

Hope this helps

Cheers

4

Thanks for your suggestion.
But as stated I know how to work around it. It’s that I don’t ‘want’ to have to work around it, in order to maintain a standard through all workflows without creating too much overhead.

Therefor I would like to suggest it as an extention of the existing out-of-the-box retry mechanism of Orchestrator queues.

1 Like
5

@Jeroen_van_Loon

This is not a too much over head…just as maxsystemexception has been included in latest versiosn we have ability to save this also as template and use this…just like maxretry you can set 0 in config to work normally and any number to work for retry…

Agree with you on auto mechanism as well…but to come from the queue side the problem would be there is no way for queue to understand if the new item needs to be added at lst or immediately…as for fee cases we might need last as well and as per first in first out also …the retries would be last but not the first one

But agree with your point of view…lets see what can be done on thai front

Cheers

7

Hello all,

In order to add my 2 cents…
I had same behavior needed in one of my automation.
Items in queue are in a given order and needs to be followed, if not it can cause business issues.

Also auto retry managed by orchestrator is very usefull, but as you said if an item fails and is retryed, same item is recreated with “New” status but at the end of the queue.
I also don’t wanted to managed it myself because I want to stay standard.

A very easy and functionnal way to handle it on my side, was to play with “Deadline” property of items.

I use bulk add queue items but before I do a loop for each item of my datatable,
and I take the current index +1 to put in the deadline property of my items ( DateTime.Now.AddMinutes(currentIndex+1).
Also my items are ordered by their entry in the queue but also with the deadline property.

And because get next queue items follows a rule of checking priority then deadline, it will process the same transaction again even if it was added at the end because of a retry, cause deadline with remain the same.

So no changes to framework, very little change to do in your dispatcher to add the deadline property.

Hope this helped,
Best regards

1 Like