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

[rpa_4_lyf]

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.

[Naveen.Ch (NaWin)]

Hi @rpa_4_lyf,

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

Best Regards,
Naveen

[rpa_4_lyf]

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

[Naveen.Ch (NaWin)]

it will retry when if the item has status failed

[rpa_4_lyf]

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

[Naveen.Ch (NaWin)]

hi @rpa_4_lyf,

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

[ovi (Viorela Preda)]

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!

[Naveen.Ch (NaWin)]

Hi @rpa_4_lyf

Hope you got the answer

Best Regards,
Naveen Ch

[badita (Mihai Badita)]

@rpa_4_lyf

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?

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

[Florent_Salendres]

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.

Progress in job queue is empty after completion

Hi, One thing to note is that the queue exports only contain the item status (so failed,in progress, success, etc) and then another column for the level of failure (so business or application) If you put any specific reason for the success or failure it is not exported. So if you want to view the reason in the queue, you can, but exporting as a report is not so useful. The other thing is that the data fields come down as one cell per transaction so you will need to parse this out to other cell…

Set Transaction Progress

Hi Team. Me again. It seems that the Transaction Progress is not persistent once the status of the queue item has been changed. E.g. if set back to New or postponed any update to the Transaction progress is lost. Could you check this please and amend for next version? RD

Set Transaction Progress

Hi there @richarddenton, You are absolutely correct. The feature is soooo close to being perfect, but has one minor oversight. Setting the progress and failing the item (granted queue retries are applicable), creates a new case, with the same information/history, which can be pulled and its progress retrieved! This means we can more accurately perform retries, directing the case to the relevant segments of the process. BUT, as you’ve noted, postponing the item does not achieve this …

Cheers

[Florent_Salendres]

@Florent_Salendres

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

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

[badita (Mihai Badita)]

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

[RajiP]

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

[loginerror (Maciej Kuźmicz)]

Hi @RajiP

I believe something like that should work, no?

Set Transaction Progress

Example of use case here:

Managing Queues in Studio

[RajiP]

@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

[loginerror (Maciej Kuźmicz)]

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:

(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.

[Mr_JDavey (Joshua Davey)]

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

[loginerror (Maciej Kuźmicz)]

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?

[Mr_JDavey (Joshua Davey)]

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

[loginerror (Maciej Kuźmicz)]

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

Orchestration Process

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

Would it be a good fit?