Can a robot start another robot?

Help
1

Hi,

I am experiencing a problem of concurrency: too many lengthy jobs need to run at the same time. Yes, I could up the number of robots but it’s not in scope right now.

So I was thinking that when “Job A” has finished it could trigger “Job B” which on its completion triggers “Job C”. This fits nicely into a 2-hour slot, so I would only have to trigger “Job A” every second hour (through a normal scheduled job).

Can a job trigger another job from inside the workflow? If yes, how?

Kind regard
/Klaus Ambrass

4 Likes
2

Hello,

You can achieve this using the StartJobs method from the Orchestrator API. At the end of one job, an API can be made to instruct to Orchestrator to start a new job either on the same robot or in another one.

If it runs on the same robott, i recommend you to use the API at the very end, if the initial job will not be terminated when the new one is triggered, that last one will fail.

This post refers to the use of StartJobs method if it can help you.

Cheers

6 Likes
3

Not a solution rather a question, without using API, what if you schedule to start Jobs A,B,C in 1 minute gap say 9:00 9:01 9:02 with Stop After(Stop not Kill) a specific time(2 hours). Won’t the jobs run in the same order? Unless you want to schedule only one job.

While A runs B and C will be pending and when B is running C will be pending and lastly C will kickoff.

1 Like
4

That’s what I was thinking @vvaidya, although it would create extra work to start each job and also could present problems if the first one fails, then starts the next job when you don’t want it to.

This is my opinion @KlausA, but if the jobs are part of the same process, then they should be in one published package. You can use a State Machine or Flow Chart with Invoke Workflow file (with shared workflows or part of the project) and design your entire process. So, if you use a part for multiple projects, you can share it and use Invoke. And In some projects, you might need to split it in 2 parts to allow manual validation before proceeding.

I think the Start Job via API could be useful in some way though. Like maybe if you are giving process owners an alternate way to trigger jobs.

Thanks.

2 Likes
5

Can you tell more about highlighted part as in why?

@ClaytonM nevermind understood. 1 job vs 3 jobs

If the jobs are interdependent, something like A sends confirmation email to B and only then B(checks for email) triggers or else it will stop and same with C.

6

Agreed you are both right. Queuing the jobs using schedule would work too.
I don’t think an email would be necessary, A good use of the queue mechanism would be more more auditable and traceable (if the job is not transactional, it is ok to consider the as transaction itself)

Example:

Process A: Load Queue (Create Queueitems For Queue1)
Process B: Work Queue1 (Work items Only New Items - Load Queue2 according to output of Queue1)
Process C: WorkQueue2

It is also possible to set the queue item with a short deadline to avoid confusions between runs.

Cheers

2 Likes
7

Haven’t worked on queues yet. So who takes care of this loading queues? A different robot or should be added at the end of each Robot (A and B I assume). Or Both will work?

8

Actually both, it depends on the design.

You have two available activity to initialize queue items

Add queue item & Add transaction Item

https://activities.uipath.com/v1.0/docs/queues-add-queue-item

https://activities.uipath.com/v1.0/docs/queues-add-transaction-item

The first one will add to your Orchestrator queue an item with the Status “new” and will have to be picked from the queue later using “Get Transaction Item” Activity, generally from another process. This Load work approach mainly allow your workload to be processed between several robots

Add transaction Item will directly start a queue item and put its Status as “in process”. It is quite handy and allows you to bypass the load phase if you do not intend to split the workload between several robots or see a need to process your transactions

Note that for both approaches, you have the possibility to attach data and output to each item which is quite helpful in term of understanding the case processed (For reporting or testing purpose).

At the end, you should set a status to your queue item (Failed or Completed) or even do more advanced thing such as postponing it using appropriate activities.

Queues also offer a very good retry management which help to keep the workflows lean and since the latest version allow you to avoid unwanted processing duplication with their unique reference options

In the case we were talking about I would see:

Start Initial job → Start Transaction Item → Set Status-> Add queue Item to second queue If Success → Job2 will Get Transaction Item → Set Status → Load 3rd queue - > Work (and so on…)

This is just a proposed design and other might also be good or even better

If one of the jobs (or its transactions, if you abstract rather the workload) is/are failed, simply the second process would run blank without incidence.

Queues and transaction may look unnecessary and tedious for some people at the first look, but I can guarantee you that with a bit of practice and learning, you can clearly see that both from development, support or business side, this makes everything simpler at the end.

Info here is surely incomplete! Recommend anyone:

Cheers

10 Likes
9

I guess this was my perspective, so never implemented the Queues concept. Will give a shot. Thanks for your time @Florent_Salendres

If think this post deserves to be as a separate thread. @Ovi 's call

1 Like
10

I think we’ll lose context if we move it to another thread. :slight_smile:

1 Like
11

Agreed, part of what i described i a sort of heretic way to use queues, seeing the jobs as a transaction

1 Like
12

I recommend you to use the API at the very end, if the initial job will not be terminated when the new one is triggered, that last one will fail.

I’m happy to say that after testingwith the Orchestrator 2018.0 and when using the StartJobs Method targeting a Robot already running, The new job will now be queued as “Pending” state and will start executing when the ressources will become available.

Thank you guys for fixing

Cheers

3 Likes
13

Hej Klaus

Have you found a solution yet? Elseway I can recommend using Orchestrators Queue functionality to keep track of which Jobs are left.

The trick is to build your queue priority into a robot which then runs job A,B or C based on what is found in the queues.

I hope this helps :slight_smile:

Best regards Mikkel

14

Hi Mikkel,

I’m currently looking at the WebService API to see if this is a valid road.
I’ll certainly have a look a Queues.

Best regards
/Klaus

16

Wow really great to read , do u have an example implementing both of these , please share xaml