Hi fellow devs
I am having trouble understanding Retrying and TransactionNumber role in Perfomer:
- How does the robot know that it should take the same Transaction Item in GetTransationData.xaml (we’re not increasing io_TransactionNumber in SetTransactionStatus.xaml) - so retry the same Transaction Item or whether it should proceed to the next one (when we actually are increasing io_TransactionNumber in SetTransactionStatus.xaml)? I see that in SetTransactionStatus.xaml after Business Rule Exception and Success path, we actually are increasing io_TransactionNumber by one (which would mean that we proceed to the next one when we go back to Get Transaction Data), but in Get Transaction Data I actually don’t see any indexing or any reference to the TransactionNumber variable/argument. The only parameters passed to the Get Transaction activity is Queue Name and output (out_TransactionItem).
- If we cannot pass TransactionNumber into Get Transaction Item, then what do we actually need it for? Is Get Transaction Item activity just taking randomly Items with New status from the specified queue? If so, then how can we stop it from taking a new one and make it take the same one (so, effectively, retrying the same Transaction Item when it’s needed)?
- I understand that you can specify retry number for each Queue from the level of Orchestrator Queue (in MaxRetry) and you can do this also using config file - also config file states that whenever you use Orchestrator Queues, we should specify the config MaxRetry always to 0. Would that mean that this workflow:
does not apply when you have hardcoded MaxRetry in Orchestrator (meaning that at Failed Status Orchestrator will automatically “recognize” the status and retry the operation the indicated number of times?)
- In the above mentioned workflow, SetTransactionStatus.xaml, in the System Error sequence, I do not quite understand the logic behind QueueRetry. First we specify, that if we do have a TransactionItem and TransactionItem is of type QueueItem - we should set QueueRetry to true, otherwise false:
However, later in the workflow, we actually go to the next transaction (by incrementing io_TransactionNumber, just like in cases when do don’t want to retry - when MaxRetry was 0 or MaxRetry was reached) instead of increasing io_RetryNumber and taking up the same Transaction Item from Get Transaction Data - so in short words: shouldn’t it be other way round after “Use Orchestrator’s retry” Flow Decision?
Thanks for help and understanding these difficult concepts