Parallel tasks with RPA Framework

RPA
1

Hello,

I have many questions, but I will try restrain myself as I understand you guys must be pretty busy preparing for the July release…

Here is one: Will it be possible to run parallel tasks with RPA Framework?

For example, very often when you press a submit button on a webpage, you may expect one of several things to happen. The ideal way to handle this is to have many tasks expecting one particular thing to happen, run in parallel. When some thing happens, the task that was expecting that particular thing gets executed, while the others are cancelled.

If you try to solve this scenario sequentially using if/else statements, you will find your robot wasting precious time…

How does the RPA Framework handle this scenario?

Thank you :slight_smile:

1 Like
2

I do not know if there is certain approach for rpa framework.

We use a job scheduler (like Jenkins) that triggers tasks depending on events. In this setup not tasks trigger succeeding tasks, but jobs trigger jobs. And jobs can easily run in parallel.

3

Having events triggering jobs, if I understand you correctly, is a great feature and I am happy to hear that it is supported, but it is not exactly what I am asking for here. My question is essentially about multi-threading and in the context of the Robot Framework (if I am not wrong, since I am new to this) running keywords in parallel (?)

I have done some research and I have come up with this that was asked in 2016:

Async Execution of Robot Keywords:
https://groups.google.com/forum/#!topic/robotframework-users/yNHawl804zo

To quote the Lead Developer of the Robot Framework in his answer here, running library keywords in parallel shouldn’t be too hard to implement, however

Being able to run user keywords in parallel would be
even better, but that would require quite big internal changes to
Robot Framework.

That’s the latest I could find on that matter. Has there been any progress on this? I do not know how important this feature is for test automation, but for RPA I think it is pretty important.

4

Ok. Do you have an example? Because running tasks or keywords in parallel are 2 different requirements.

5

Sure. This is an image from the user friendly/developer hostile visual UiPath editor:

Parallel
Parallel968×508 53.6 KB

I am not filling in any activities here, just comments so that you get the idea. The triggers in each path are activites waiting for some thing to happen. When the condition of one trigger is fulfilled, its Action gets executed and then you are immediately out of the block, meaning the other Actions are cancelled.

Is there a way I could do this with RPA Framework?

6

Hi Rovertos,

I see your point. So the idea is to wait for multiple conditions in parallel and then pick and execution path based on the condition that was fulfilled.

I’ll loop in our RPA Framework developers to discuss about this. It should be technically possible and there are multiple ways to achieve this.

Thanks!

2 Likes
7

Thank you Antti,

Please deliver me from the horizontal scrollbar I have to wrestle with when I add multiple branches :slight_smile:

8

You could solve this in a custom Python library; you’d create a method (which is then a custom keyword) that accepts a number of “tasks” (methods / functions) that it’ll execute in parallel, returning when the first supplied “task” completes. Python has the ThreadPoolExecutor for this:
https://docs.python.org/3/library/concurrent.futures.html#concurrent.futures.ThreadPoolExecutor
To continue when the first “task” finishes, you’d use the wait(fs, return_when=FIRST_COMPELTED) option:
https://docs.python.org/3/library/concurrent.futures.html#concurrent.futures.wait

1 Like
9

Hi Rovertos,

We had a short chat about this, and it’s an interesting feature. The usual Robot Framework way would be to either:

  1. Expect that A happens and do B if it didn’t (within a timeout)
  2. Wait for something to happen and then do A or B depending on the current state
  3. Allow waiting for multiple conditions on an individual library level

I can see the appeal of re-using existing user keywords for waiting things in parallel. Unfortunately, like you already found out, it’s not currently supported because of some technical limitations. However Pekka had the following to say over in RF slack:

Execution currently has too much global state that will be messed up if things happen in parallel. This was the reason parallel execution was removed back in the day. Global state has been removed over the years, but there’s still some left. Removing rest of it has been a long time hope/target for me, and I plan to look at that during RF 3.3/4.0 development when there are anyway needs for refactoring the execution side.

So there might be some possibilities for this in the near-ish future. In the meantime, I think a lot of the required use-cases can be implemented directly in our libraries. The given example for instance could be handled by allowing the windows/desktop libraries to wait on multiple conditions at once, and wouldn’t require changes in RF itself.

Would you mind elaborating a bit on where you’d usually need the pick activity?

10

I have been using this when I execute an operation that may take anything from a few seconds to several minutes to either succeed or display one of several notifications, which may be entirely different elements in some legacy applications where there is no consistency (for example, an alert box or an html popup).

If I don’t go parallel and my activity that keeps looking for the OK confirmation times out after 60 seconds, while the error popup has been displayed in just 2 seconds, that’s 58 seconds wasted. Of course I can loop, keep checking for everything and break when I find something, but then it gets ugly, especially in a visual editor where every single statement you add to the process brings so much real estate to the screen.

I have not yet encountered a situation where a feature such as the pick activity is essential, though. Maybe in attended automation, where you want the process to instantly respond to a user command while something else is happening? Probably, but not very likely.