RE Framework Performer: understanding Retry and TransactionNumber

Help
, ,
1

Hi fellow devs

I am having trouble understanding Retrying and TransactionNumber role in Perfomer:

  1. 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).
  2. 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)?
  3. 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:

image
image666×701 72.5 KB

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?)

  1. 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:

image
image770×555 52.7 KB

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?

image

Thanks for help and understanding these difficult concepts

1 Like
2

Hey guys, can anyone help me out here? I know there is a lot of text, but I would appreciate even if just some of the questions get some explanation

3

Hi @salladinne,
Have you checked our official documentation about re-framework?

1 Like
4

Did you reach any conclusion reg. this? I have the exact same question…

5

Hi @david.fredriksson

Welcome to forum, like what is ur main doubt

Like the queue retry mechanism in case of system exception?

6

I have the exact same question as above. I can’t describe it better than it’s already done. When using local robot retry: how should the process “know” when to proceed with the same transaction (retry) and when to fetch a new? As described above, there is nothing in the part of the workflow that controls “Get Transaction Data” depending on retry or not. In my case, this is executed each time so no retries happens - it only gets the next transaction instead.

7

Actually u are taking why in queue transactionnumber is increasing in retry is it right?

@david.fredriksson

8

The transactionumber is not increasing on retry. Only on successful, on business exceptions or when max retries has been reached.

9

Hi @david.fredriksson

Mostly when we are working with queue, it will increase transactionno by one

But when you are not working with queue, it will retry that transaction again and again only after that it will.go.to next Transaction

Queue retry is different from normal retry

Hope it helps

Nived N :robot:

10

It’s not really answering main question that started this thread, but thanks anyway.

11

Hi,

When we have set in Orchestrator “Auto-Retry” as greater than zero, then for any system exception, Orchestrator will automatically add a New Queue Item to the Queue with status “New”, having “RetryNo” set to ‘1’.
So the Set transaction status workflow (RetryCurrentTransaction workflow) - in system exception after checking variable QueueRetry is incrementing Transaction Number to 1. This way it will eventually pick that New item (added by Orchestrator for retry). And code will check for “Transactionitem.RetryNo” to keep track of how many retires can be done.