Force Retry Process

[MateuszWojcik]

Hi,

Is there a way to force retry specific items in Blue Prism Process?

I do not see such action.

Do you know a way?


Kind regards

------------------------------
Mateusz Wojcik
RPA Programist
Rockwell Automation
Europe/Warsaw
------------------------------

[IsmoLehtiniemi]

I'm not sure if this is applicable for your needs, but it is possible to copy an existing item as a new item with the native work queue actions:



------------------------------
Ismo Lehtiniemi
RPA Architect & Solution Expert
Amcor
Europe/Warsaw
------------------------------

[MateuszWojcik]

Hi Ismo,

Thank you for your answer.

Unfortunately I cannot use your solution.

I need to force retry an existing item. Blue Prism has process item in 80% and faced an application error. Once the application Error is solved I need Blue Prism to continue work on this item. Our scheduler manually mark exceptions items to be force retry. 

I want to automate his work.

------------------------------
Mateusz Wojcik
RPA Programist
Rockwell Automation
Europe/Warsaw
------------------------------

[IsmoLehtiniemi]

In that case there is a simple way of doing it. First you mark the item as an exception which allows retries:

And then you add in the System -tab for the specific work queue Maximum Attempts to be something greater than 1:

That makes all of the exception items to be automatically retried as many times as needed / as many times as the limit permits.

------------------------------
Ismo Lehtiniemi
RPA Architect & Solution Expert
Amcor
Europe/Warsaw
------------------------------

[MateuszWojcik]

Hi Ismo,

We have already set up maximum attempts on 3.

When we have application issues BOT tries to  process items 3 times and 3 times fails.

I want to force retry those items using Blue prism Process after application problem is fixed.




------------------------------
Mateusz Wojcik
RPA Programist
Rockwell Automation
Europe/Warsaw
------------------------------

[IsmoLehtiniemi]

Ok, let's continue then mapping your options.

You could for example set the status to be something which would imply that a fix is needed in case of a failure. Then you would need to add a new logic for the process to check the item status if it should be handled or not. If not, the solution would release the item lock instead of marking it as an exception.

After you have fixed the issue, you would manually remove/change the status of the item(s), which would then allow the solution to work on the item.

------------------------------
Ismo Lehtiniemi
RPA Architect & Solution Expert
Amcor
Europe/Warsaw
------------------------------

[ritansh.jatwani]

Hi @MateuszWojcik,

The best way to deal with your scenario is:

1) Set Maximum attempts to 3 or more than that based on your requirement while creating the Work queues in the system manager.


2) While marking the item as Exception, make force retry as True so that the bot automatically retries the case.


3) The output of "Mark Item as Exception" would be "New Item ID". You can lock this new item ID and defer the case so that it won't get picked up instantly and will be worked at later stages.


4) The other option would be to tag the "New Item ID" with a new tag and just work on it at the extreme end of the process.​
5) The last option would be to set the priority of the "New Item ID". If you set the priority to be of low priority then this case would be looked up at the end hence you get enough time to fix the application issue.

Hope it helps

------------------------------
Ritansh Jatwani Senior Consultant
Consultant
EY
Gurgaon
*If you find this post helpful mark it as best answer
------------------------------

[MateuszWojcik]

Hi Ismo,

Flow of our processed works based on statuses. If I change status on temporary status that imply something needs to be repaired it will required to changes back this status manually. 

I look for solution which helps me limit manual work.

------------------------------
Mateusz Wojcik
RPA Programist
Rockwell Automation
Europe/Warsaw
------------------------------

[david.l.morris]

The only thing I'd adjust with your steps is to point out that the "New Item ID" will not be different from the Item ID. I think in an older version of Blue Prism, the New Item ID was different, but now all retries of a queue item have the same Item ID as the original. I cannot remember when that changed or if I dreamed that it used to be different, but I went ahead and checked v6.7, v6.10.1, and v7.0 just now to verify, and in all of them Mark Exception outputs the same Item ID into New Item ID.

I don't think any of that changes the logic of what you're doing though. I believe the exact same workflow you described would still work. The main time that it gets annoying is when you want to retrieve exception messages from old retries, which I believe is not possible without querying the database directly.

Screenshot:

------------------------------
Dave Morris
Cano Ai
Atlanta, GA
------------------------------

[MateuszWojcik]

HI Dave,

Thank you for your answer. 

Unfortunately this is not what I am looking for.

Your propositions are to leave item in the queue on pending for BOT to try again in later time. I do now what to do it, because  I do not know when the issue will be solved. In some cases there will be required intervention of developer and change of code. In such cases I should delay the item for several hours. After developer did its work I want to force retry exception item as soon as possible. This has to be done manually in control room by scheduler. Sometimes there could be a lot of exceptions. I want to find solution to avoid manual work of my scheduler. To mark all exception items from 1 specific queue to be forced retry.


------------------------------
Mateusz Wojcik
RPA Programist
Rockwell Automation
Europe/Warsaw
------------------------------