Mark a transaction as failed, increase retry counter and postpone its reprocessing in UiPath process

Question

Is there a way to mark as transaction as failed and get orchestrator to increase the retry counter but at the same time, postpone the transaction from being processed by, let’s say 2h?

In my scenario, I’m looking for some data in a database and if not found, I want to mark the transaction as failed and increase the retry to 1 in orchestrator and I want this failed transaction to be postpone for a couple of hours.

Assuming the database eventually gets updated with the relevant data an hour later, when the orchestrator triggers the relevant bot and attempts to reprocess the transaction 2 hours later, it will be successful.

If on the other hand, the database still doesn’t contain the data and 2 hours have elapsed, the transaction will fail again and I need orchestrator to increment the retry to 2 and it will postpone it for another 2 hours.

Finally, if the data is still not there 2 hours later (i.e. 6 hours has elapsed), I want the transaction to fail again, increase the retry to 3 and stop attempting to process it assuming it has reach its max number of retries as set on the queue in orchestrator. It probably will send an email to notify an admin.

A few things I don’t understand:

Why is a business exception not retried. To me, the above scenario, is a business rule that failed (i.e. data not found in database) but if I understood what the “Set Transaction Status” workflow states, it will not retry to re-process a business rule exception. Makes no sense to me, well, at least based on my scenario.

Does that mean that the only way to increase the retry counter in orchestrator, is to generate a system exception? This just doesn’t feel right, nor do I want to take a snapshot as per SetTransactionStatus when dealing with this kind of exception. Am I missing something??

Also when calling the postpone activity, I can see that it’s changing the transaction status from ‘failed’ to ‘new’ which isn’t ideal either but could live with it if necessary. What’s important to me here is that the retry counter does not get reset in orchestrator when this is called but since the status is changed from failed to new when calling the postpone activity, I’m concerned that it will reset the counter which would be a problem.

I haven’t checked yet if the number of retries remains when calling the Postpone activity as I haven’t gone through an entire process just yet.

What is the correct way to achieve this? Can this be achieved?

Thanks

PS: Apologies for the lengthy post but I thought I’d provided as much detail as possible.

UPDATE-1

@kwoxer suggested this might be a duplicate question, but I don't believe it is.

The post enter link description here deals with what happens to the statuses when transaction is created and some activity is called to change the status but it doesn't address how to handled a failed business rule and how to deal with retries.

As mentioned, not finding "data" and wanting to retry a few hours later should be achievable using built-in functionality while still being treated as a business rule exception, while also relying on a retry counter so that this operation does not carry on forever.

It should also give you more control as to what should happen to a status i.e. Postponing a failed transaction should be a valid and the status should not be reset to "New" or at least you should have the option to what the status should be set to.

I've posted a potential "work-around" in my reply to @kwoxer but I think it's ugly and really wish there was a way to deal with this with built-in functionality and I'm hoping someone might suggested something I may have missed or a better work-around.

Thanks.

Answer 1

There is no solution so far. You cannot use the Transaction status in Orchestrator to handle further process runs.

Instead you could do something else. Create a trigger that let the process run 3 times at 2, 4 and 6 o'clock via:

Now after the first run at 2 fails with a business error you write the number of retries to any file. But actually with hard coding the process run via cron job you don't need that. Anyway when the process is starting you simply check that file and so you have your own mechanics to handle business process errors.

It's not exactly what you wanted but the best work-around until UiPath implements something similar. But there is nothing in their pipeline right now.

---

Another idea would be using the queue instead of writing it down to a file. But the queue does not support custom flags. So if the flags that are given via Set transaction status are enough, better take that.