Can we retry a transaction from a checkpoint (based on transaction progress)?

Is there a way for me to retry a transaction in the Orchestrator from the point where it failed, by using the transaction progress as a checkpoint?

I already searched for answers to this on the forum and found similar questions here - How to recover a Process using Tags, or Status? and here - Disallow retry of transaction, but none with a satisfying answer.

1 Like

Hi @rpa_4_lyf,

While create queues we need to set Max # of retries
please find the attachment for the same

Best Regards,
Naveen

1 Like

@Naveen.Ch, but this retries the entire transaction. How do we retry only a part of it?

it will retry when if the item has status failed

@Naveen.Ch

If my item has step 1 → step 2 → step 3, and it fails at step 2, I don’t want it to retry from step 1 again. Is that possible?

hi @rpa_4_lyf,

That is the case i am also not aware
@ovi is there any way to do @loginerror

Hi! Currently you can only retry the whole transaction. This is because, based on the Max. #of retries you set in the Queue, a Failed item will be retried. From what i understand @rpa_4_lyf you want to set some sort of status along the Transaction item’s steps and then have a condition like this_if Failed at step 2 → retry from here_

Will move it to Ideas category so product team can also give their input. Could you please give a use case? Like in what situation will you have a transaction with multiple steps?

Thanks!

Hi @rpa_4_lyf

Hope you got the answer

Best Regards,
Naveen Ch

Isn’t this what the “Progress” field is supposed to achieve?

I think what the OP said is that once the Status of the Transaction is Set on the Orchestrator, the Process will disappear from the Item, so In case you would like to to retry (meaning Retry with the Queue feature), you will not be access this “progress” then.

Unless you made a quick hit that I missed, I think the issue is still outstanding.

Cheers

Okay, so it looks like the is partially corrected (at least in 2019.1)
Did not find the relevant Release yet, but this may be somewhere.

Once an item is Set Transaction Status “Failed” and hasn’t reached the retry count, it will set the Status to Retried and add a New TransactionItem with the Status New, having the Process value available.

However, once this New Item will be picked and its Status Set (tested only with Failed, after maxRetry), there will be no trace of the Progress in both initial transactions (With Status retried) and the failed one.

This fine in terms of of accessing it from the Bot but still a bit fuzzy if we would like to look at understanding what happened to our case from the Orchestrator UI afterward.

Cheers

@qateam @rocsana does it happen to know when has the copying of progress between retried item has been fixed?

Hi All,

I have a similar issue. I am sending email to customer and then marking the email category as “Actioned”. If there is issue setting up the category then I need to retry this step alone and avoid sending duplicate email to the customer. Please let me know how to use the checkpoint after the send email is completed.

Thanks
Raji

Hi @RajiP

I believe something like that should work, no?

Example of use case here:

@loginerror - The example given is not clear. I wanted to know how to retry a transaction from a checkpoint using this set transaction progress activity.

For example, if my transaction process xaml file has 3 workflows, I have added try catch for each workflow and assigned a flag to it and also added set transaction progress as “failed” in the catch block. when it retries where should I give the progress input for the retry item to start? I am using RE Framework here. Please Suggest.

Thanks
Raji

I believe the idea would be to design the process that does checks if specific parts of the process should be skipped with a condition such as:
image
(based on the custom progress set for the queue item)

This should happen in the Process.xaml part, maybe with a simple flowchart logic and Flow Decision activities.

Hi there @loginerror,
That definitely works, however, once the maximum retries are exceeded, the item is marked as failed.

At this point, the progress is wiped (set to null).
In the event we then “manually” set the item to retry within Orchestrator, it will have to start from scratch.

It would be ideal if the progress be applied to the new “manually” retried item.
Unless I am missing something - This does not seem to be the case.

Thanks in advance for your support,
Josh

Hi @Mr_JDavey

Could you elaborate on your use case? I would imagine that the retry limit value would be a reasonably high value above which something went seriously wrong and should be investigated anyway.

What would be your suggestions of improvement that would solve this issue?

1 Like

Hi there @loginerror,
We have a situation where the business want to check all items before auto-retrying.

The process itself leverages financial data and thus, human intervention before retrying is necessary.
At the moment, we have a situation where we are tracking the progress and would like to report that back to the business on failure, so they can understand where it got to.

Once they are satisfied that retrying will not cause harm, they would go ahead and “manually” click retry transaction, but because the progress is lost, this effectively starts the transaction anew.

My suggestion would be to have the progress property persist in failure.
It would allow the business to understand how far the transaction got at a glance (without us needing to track it separately). It would also allow “manual” retries*** to leverage the progress value.

***To clarify, when I say manual retries, I mean clicking retry in Orchestrator.

Thanks once again for your support,
Josh

Thank you. It would seem that this could be properly managed by using an Orchestration Process, see here:

It was designed specifically to allow easy management of processes that require human intervention.

Would it be a good fit?

1 Like