I am currently working for a client that is fully invested in UiPath, and we have developed 82 RPA processes for them that run through out the day. There are some that fail due to not being able to connect to a Citrix connection and the solution is to re run the failed job to attempt to get a different Citrix Connection that will allow the process to log on and perform the task.
What I am wanting to find out is, is there a way to write a queue item to Orchestrator so that a clean up bot can pick up some tag/ information so that it will pick up the failed job assign it to a robot to re attempt so many times. Some times it could be up to 30 mins before the connection can be made.
I know we can use max number of reattempts in RE Framework, but we have about 40 RPA processes that are not built in the RE Framework structure. This is where I would like to have at the end of the Try Catch a Add Queue Item to a Failed Queue.
This is to mitigate a person having to babysit Orchestrator to make sure all the jobs ran successfully and have to manually restart any failed jobs.
Any ideas or solutions would be really appreciated!
Welcome to UiPath community buddy…Thats really a amazing question…
Great, so coming to the point
You idea sounds good and here are my kind suggestions that can be implemented if you would like to…
Add queue item every time as a first queue when u log on to a Citrix environment…may be with a status called connected. This term is called as dispatcher in uipath and this can be added even if you are not using REFramework…no problem…but thats the best practice…
Once added, now we are going to use a term called performer for this dispatcher…that is once the bot completes all the process in all the Citrix environment…we can make a schedule in orchestrator as u say it might take 30 min to connect and this performer can take the status from dispatcher with get transaction item activity in our studio, for checking the status whether it go connected or disconnected…if it’s connected no need to go for performer…if not continue with the performer…
You can do like this buddy
Or even i was thinking like why can’t we repeat the process again if it is getting failed with try catch block…but it wont because you are telling the connection would take 30 min…so lets better go by the above method buddy
I just want to make sure we understand your question…
What you are saying is that when a job runs, it can fail, and require some babysitting to rerun it. So, what you are looking for is a way to automate the rerun, right?
Technically, if you create another job that utilizes the Orchestrator activities, you might be able to have it get the jobs, then start the ones that failed.
However, I highly recommend you have some error handling to perform retry attempts in those processes, and you don’t need the ReFramework to do this. Obviously, it’s easier if this was in place when the projects were first deployed, but having this robust project design has saved us from many headaches (and very few use the default ReFramework). So, it might be worth going back and fix some things in those processes.
Additionally, there are a few things to consider while utilizing Queues… When you Add a Queue item to a queue, it can not be retried (automatically) once it finishes as successful or failed, assuming you have unique items set up. Therefore, to retry these items, you must use Postpone Queue item to change the status back to New. And, this is also assuming that you have some robust logic to pick up transaction items that were not fully complete the previous job run, such as checking if a file exists or something.
Palaniyappan that sounds like what I’m looking to do exactly. Sounds like I can create a workflow lets say dispatcher that invokes/ initiates at the beginning of the job/process that maybe defaults as failed in the queue and then after sign in to Citrix is successful then it can unmark or delete queue item from Orchestrator. The next step would be to create a performer job scheduled to run every 15 mins to check the queue to see if there is any jobs that failed that just need to re-run due to no open Citrix connections.
On high level would you say that’s feasible? I’m thinking my first approach might be to see if I can dissect out the Dispatch and Performer pieces of RE Framework to make this happen.
Any other suggestions/ tips/ advice is greatly appreciated!
ClaytonM, as always I appreciate your help! Yeah that is a correct understanding of what I’m hoping to achieve. I’ll have to get a better understanding of how to use queue items, but I’m hoping to be able to only add a queue item for the failed jobs/processes that need to be re ran. Then as I said above just have a job scheduled every 15 mins to check for items in the queue that need re ran.
Yeah, my first solution is to build in event handlers and utilize retry scopes, built in reattempts internally. There are a few jobs that have limited Citrix connections and the bot just can’t get through. These processes when they were done by people, they would just try again later. That is what I want these to be set up to handle. There are other times that a job that runs with out a peep for weeks at a time just not run successfully due to time out issues. About 90 percent of the jobs work through Citrix environments, and there are about 8 different interfaces. We are pulling records from several different locations through out the day. So, I’m needing to make it so that Orchestrator handles these occasional re runs of failed jobs.
What I have above in my other reply, would you have any suggestions on how to piece together this process or would dissecting it out of RE Framework be the only/best way?
Hey I was thinking that if I were to pass the process name to the queue then when I retrieve the "SpecificContent(“RPAProcessName”).ToString I could possibly plug in that value (having to match exact to the process name). Then using the key through web api to trigger the job that needs rerun??? I’m kind of excited if I can figure a few details I think this could work, right???
I am referencing another post that you were in on about starting a job from inside another job
That might work.
You can get the ProcessName when a job runs from the project.json that is part of the process package. To do so, use Read Text file (“project.json”), Deserialize Json, then pull like the name key, like jsonObject(“name”).ToString
So, maybe you can get the ProcessName stored in Queue as part of each job so when it runs, it shows up in Queue. But, you will need to change the status to Successful or Failed during each Job.
I am not sure how you would do this if adding the ProcessName was not part of each process and job run.
Then, using the ProcessName from the Queue, you can probably use the Start Job activity, so using API might not be needed for that approach.
Really appreciate the advice on how to approach my project. I’m working on learning how to use filter on Get Jobs so that I can pull jobs that are either in a “Stopped” state or “Successful” with an Exception Error (with the try catch I have around all the Jobs, the Job will show up as successful on Orchestrator, but still of failed. Probably bad design on my part, but part of it was like that when I got here and am still trying to dig through on issue at a time). I tried to use this filter below, but I am getting this error also.
I have one final question then I should be good for like at least 2 or 3 days (weekend is coming up).
In the Get Jobs Activity I figured out how to filter State “‘stopped’” Jobs but how do I filter EndTime to be last 30 mins?
I’m thinking about doing a date.now.addminutes(30) to get that value, but how do I apply the variable to the filter? var = howFarBackInTime < now? I know that was terrible, but you get the idea.