Scheduling multiple jobs all from the same processes, but with different parameters

I have a UiPath Process that I designed to be very generic and reusable by passing arguments. This process extracts data from our BI system and creates a csv file. This process works great and has for many months. The problem I’m now running into now is it’s used very widely by different business areas that I’m having issues scheduling it.

If I had 10 different processes the system will queue them all up and while the first job is running the other 9 will be pending and the robot will work through the list perfectly.

However if I try to stack up 10 of the same process each with different arguments for totally different purposes, The first one runs, great, the second one goes to pending, perfect, but the third one gives the error “The robots already have pending jobs for this Process (#1670)”
If you were running these jobs manually you get this error and you know you need to wait. However if you schedule them in Orchestrator, and the jobs back up then the third one just doesn’t run, no error, no log, no nothing Just a mysteriously intermittent problem :confounded:

We have only 1 robot, so I can’t distribute them to different robots.
I have tried to space out the jobs to avoid this, but sometimes jobs take much longer to run than normal which is what makes this intermittent. As we use this job more and more to extract different files for different business areas the problem get’s worse.
there are not enough hours in the evening to safely space these jobs out using worst case for every job.
It always seems to be the critical job that doesn’t run (Murphy’s Law)

I strongly believe building a single argument driven reusable process is the best practice vs building many different branches for each extraction. Any way to get around this issue?

Thanks!

Buy more licenses so your licensing is appropriate for your usage.

1 Like

Hello,

from what I’ve understood the problem is that when you schedule more jobs in pending state, you receive error about the job that it can’t be scheduled. Have you tried to manipulate the Trigger (parameter for maximum pending/running jobs)?

Best regards

Artur

Hi Arthur,

The issue is not the number of jobs. I can have many jobs waiting in pending if they are all different processes, but in this case they are the same process with different Arguments for different purposes.

So for your case postwick has right. You have to buy more licenses

Buy more licenses, Really! Perhaps I’m not explaining my issue correctly. If each job were a different process hard coded there would be no issues. All jobs will run and be complete As soon as possible. Since all of the jobs happen to be the same process parameter driven then the scheduler if a job runs long then some jobs just don’t execute, with no log entry or any indication as to why. This is a bug or a poor product.

hmmm … so all your jobs trying launch on the same VM ? Maybe you should add more VMs to your environment which your process work or in the trigger settings mark dynamic allocation.


Please share your settings that will be easier for us to understand your issue.

I believe these guys are wrong. You don’t need more licences. Licences don’t limit how many processes you can have in pending. I do alot with persistence activities and having jobs often in suspended and pending states.
I literally just tested kicking off the same process a bunch of times and I do not get your issue. This is on a tenant with 1 production licence and 1 VM.

So everyone claiming to just get more VM’s and licences. I suggest you stop, there is a bug here. There is nothing in the licencing or documentation to explain why jobs should or would get stuck. It also makes no sense as a fix because the jobs are not allocated to a bot or VM when they are in pending.

@rogerfries So in my opinion, certainly a bug, but I’d like to know abit about how you are starting these jobs.
I’d also suggest you change your bot to use queue items and become transactional rather than requiring input arguments. This is the intended way to run a process like this.

Actually what he’s doing is exactly the intent of parameters. It’s why there is an hierarchy to the parameters (Trigger > Process > Package). Parameters are exactly to control inputs to the job, such as the location of the files the job should load.

Well I disagree entirely paul.
Parameters are cumbersome to change and means a process can only do a single unit of work.

Lets take for example downloading a report from SAP. If you design your process so you can add the Customer Code, and Date as input arguments you can run a job that does that one task and nothing else. It cannot handle more than a single unit of work making the process less re-useable.

If you instead make the process without any parameters but have it read from a queue you can add the Customer Code and Date to each queue item.
In this manner the process can consume x units of work. You can make 10 queue items and have a single process do all those units of work, this results in a faster bot and processing time since the process only needs to log in and out once unlike the first example where having 10 jobs causes the bot to log in 10 times.

You use parameters to control settings and things to tell the automation how to run, not to tell it what to run. You use queues to tell it what to run. Queue items are the single units of work. Parameters are settings for the automation, like who to email a confirmation to, where the source files are located, where to write logs, etc. That way when you have to change those things, you just update the parameter. And then you can have the same automation run with different settings, using different triggers and setting the parameters in the triggers.

You are being far too general here. Parameters absolutely can tell the automation what to run, it depends on what kind of process it is. If its a linear process then the inputs do not function as you claim.
Besides, some of the scenarios you describe for ‘Settings’ are not appropriate at all for parameters. Where to write logs is definitely a setting and should be stored as an asset, arguably so is the location of the source files and email confirmation. None of those should be arguments.

Currently the OP has a linear process, I propose it is changed to a transactional one. Its really that simple and the process is transactional from what he has described, he is queuing up 10 units of work.

I’m sorry but what you are saying just confuses the situation as its not accurate, getting more licences won’t help him and isn’t a cost effective solution (what if now he can queue 6 jobs instead of 3, does he need another licence to queue up 9, plus you don’t even have a clue if that could work, which I seriously doubt it would) and leveraging arguments in the way you suggest won’t.
Converting from a linear process to a transactional one will help him based on what OP described and given the symptoms described would avoid the issue he is facing as he wouldn’t need to queue up the same process multiple times at all.

I’m sorry, this is utterly wrong. We stopped using Assets and config files, and started using parameters. They work MUCH better and there is less maintenance overhead.

If you don’t think this is what parameters are for, then what do you think they’re for?

He did not describe a transactional process.

This is a perfect use of parameters. You have one Process with input parameters for the location of these files, for example. Then you schedule a trigger to run with the parameter set to “\shareserver\dept1folder” and a second trigger to run with the parameter set to “\shareserver\dept2folder” - these are not work items. These are settings telling the automation what the source folder is for each run.

I’m sorry, this is utterly wrong. We stopped using Assets and config files, and started using parameters. They work MUCH better and there is less maintenance overhead.

If you don’t think this is what parameters are for, then what do you think they’re for?

This is contrary to everything that UiPath does and teach and what everybody else does.
Its far far more likely that you are wrong and doing it incorrectly because you misunderstand how these things work rather than everybody else who uses UiPath is wrong and so are UiPath in what they teach and set up. You’d fail exam questions for UiPath certification if you decide settings are useless and instead everything should be done with input parameters. Thats just not how its done because its a bad idea.

If you were struggling to manage your bots before then I’d wager, based on what you say, its because of a lack of knowledge or experience as to how to design bots well. The REFramework UiPath provide is clunky but its a good base to understand how to think about setting these things up, in doing so you’ll see the appropriate use of these various terms.

As for him not describing a transactional process. Well, you are wrong. He did, the fact he is queuing jobs like this demonstrates it to me. If it were a linear process, lets say like an attended bot that was logging into a system or setting and out of office (simple examples) then yeah, an input argument would make alot more sense over an asset or a queue item.
Its all contextual and you are prone to make some rather incorrect, broad statements such as claiming more licences could fix the bug described above. I urge you to take a step back and appreciate that there is common wisdom in how things are done for a reason.

Two points that I’ve seen for this.

  1. If you set the parameters at the process level then you can only have one version of a process at a time, however if you use triggers to set the parameters then multiple configurations should be able to run in parallel.

  2. License issues aren’t relevant here, if you have the jobs running on specific bots then only one job can be pending at a time, try allocating dynamically. Though this depends on your orchestrator configuration for how many jobs can be pending at the same time.

I’m setting my parameters at the trigger level and each process has a unique name specified at the trigger level, however only one instance of the same process can exist in the pending state. Many different processes can exist in the pending state, so it’s not the setting for number of pending processes. The scheduler just ignores the jobs if one is already pending. I believe as stated earlier in this thread that I could convert the process to the queueing style and it would solve my problem, but I don’t have time to rework this large important process right now. I believe I’ve come up with a schedule where everything should run without bumping into each other, but I’m wasting robot time by leaving large margins between jobs.

While the queueing might be the better way, I’m I still strongly feel the way parameter driven way I built mine is quite good and this is a bug in the product. Hopefully this will get on a bug fix list for a future release.