I’m using the Re-Framework to develop a process and I’m facing a problem with the retry queue items.
I’m forcing a System Exception while processing an item. Then, it closes the application, starts the applications and starts to work again on the item that stopped. After the whole list is processed (including the item that failed), it goes back to this item and tries to process it again.
As you can see in the below image, it should be good after the status is successful and it shouldn’t create a new queue item as I think it does.
You are correct!. ideally it should not add an entry. but to add more light to this situation, we need more info. screen shot at different processing stage. Failed, successful , and item recreated.
current screen shot does not convey the process flow or the situation u want to explain
I think that my problem is related with the “MaxRetryNumber” of config file that is > 0 and I also have “Auto-Retry” on the queue configuration a True.
@megharajky,
When we are creating a queue, it will ask about the “Unique Reference” and “Auto-Retry” only. And the Unique Reference doesn’t consider the queue items that retry.
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
As you can see on the above image, (where is the arrow), the status changes to Successfully.
And I was trying with limit to 1 in Orch and 0 in config file.
Note: I turned off the “Auto-retry” when creating the queue and when the processing of an item crashes, it closes everything and starts again, and process the item that failed. Don’t understanding the “auto-retry”… I’ll search about it
Hey guys, so just to be clear here, is Orchestrator is actually retrying successful transactions? if so is it actually retrying the successful transaction in orchestrator, or has it seemingly created a duplicate which it has tried instead (you mentioned duplicates above)?
NB - for the purposes of your testing, keep all the auto retry functions turned off, so that you can see exactly when it is displaying unknown behavior
Auto-retry function of Orchestrator queue only works with items that has System Error. If the item encounters a BusinessRuleException, then auto-retry will not function. So if you want your transaction item to stop in your specific scenario while having an auto-retry, you could throw a BusinessRuleException.
Closing of the applications and restarting back to InitAllApplications is a normal behavior when using ReFramework if you encounter a System Error.
Going to the Handle System Error sequence under SetTransactionStatus workflow, you could see below that it has an invoked CloseAllApplication workflow.
In that case ,how do i limit the auto retry functionality of Orchestrator ?
Suppose i am adding items to queue and then after getting transaction item from the queue when i am processing that transaction item ,then i am getting a system exception in Process.Xaml file, the bot is then going back again to the Init state and repeating the same stuff again .
Now how can i limit this looping to max 3 times and then it should stop ,otherwise currently it is just repeating the same stuff again and again like infinite loop.
There’s two retry mechanisms, which I find using both is most effective. One is when you create the Queue, you can set the retry numbers. And, the second is within the ReFramework.
Please look over the documentation on the ReFramework, cause this will be mentioned I believe. There should be a setting in the Config.xlsx called MaxRetryNumber. If this is set to 0, if I remember right, it will not use retries inside the ReFramework and only rely on the Queue retry mechanism. If you want the ReFramework to also perform the retries, you should be able to set this to your desired number, however I can’t remember if this is bugged or not.
You can look up using the Universal Search at where it increments the retry and checks if it is < MaxRetryNumber. This will give you a better understanding at which point this is determined. Let me know if you can’t find where this happens and I will look it up and help further.
Ok. I forgot to mention this . I have given max retry number in config file as 0 and queue retry in orchestrator as 1 . But still when system exception occurs in process.xaml, it keeps repeating the same stuff ,which is :- going to init state retrying the queue item ,again throwing system exc. and again the same process as in infinite loop.
If it’s repeating the same transaction, you need to check where it gets the next transaction. Assuming you get it from the Queue, I believe the condition is: transactionItem is Nothing
Therefore, if the transactionItem is not assigned to Nothing when the exception occurs and/or max retry is hit, then it will keep on the same transaction. So my suggestion would be to check the Set Transaction Status workflow to ensure that transactionItem is assigned to Nothing when either the MaxRetryNumber is zero or MaxRetryNumber is hit. This condition may already be there, but maybe it’s missing the part to assign the transaction item back to Nothing, so it can get the next transaction.
ashokkarale
Anil_G
Yoichi
yangyq10
postwick
chandreshsinh.jadeja
aravindbalineni123
Parvathy
aya
PRASHANT_GABHANE