Async Execution of Robot Keywords

2,549 views
Skip to first unread message

Seth Rosetter

unread,
Apr 27, 2016, 9:04:14 PM4/27/16
to robotframework-users
Hi all,

I'm new to this group so let me know if this is duplicate etc. I would like to run a series of tasks in parallel and wait for them in a specific order. I just started looking at this today and got a mock up done.  

I tried using https://github.com/Chetic/robotframework-async/blob/master/AsyncLibrary/async.py originally but this API call (https://github.com/Chetic/robotframework-async/blob/master/AsyncLibrary/async.py#L34) seems to be gone. 

I feel like what I'm doing is pretty hacky (i.e. the reflection in to resolve the method in 'method_instance_for_keyword_name')

Is there a suggested way to do this or are there any suggestions?

Any help would be much appreciated!!

Thanks, 
- Seth



*** Test Cases ***
Test Async

    ${task1} =  Start Async  long task  one    ${10}
${task2} = Start Async long task two ${5}
${task3} = Start Async long task three ${3}

${text2} = Get Async ${task2}
Log To Console ${text2}
${text1} = Get Async ${task1}
Log To Console ${text1}
${text3} = Get Async ${task3}
Log To Console ${text3}


## Implementation


from uuid import uuid4
from robot.libraries.BuiltIn import BuiltIn
from concurrent.futures import ThreadPoolExecutor


def method_instance_for_keyword_name(keyword_name):

robot_libraries = BuiltIn().get_library_instance(all=True)

for lib in robot_libraries:
methods = [method for method in dir(robot_libraries[lib])]
if keyword_name in methods:
return getattr(robot_libraries[lib], method)

class Async:
def __init__(self):
self._futures = {}
self.executor = ThreadPoolExecutor(max_workers=10)

def start_async(self, keyword, *args, **kwargs):

handle = uuid4()
keyword_name_to_find = keyword.replace(" ", "_")
method = method_instance_for_keyword_name(keyword_name_to_find)

self._futures[handle] = self.executor.submit(method, *args, **kwargs)
return handle

def get_async(self, handle):
result = self._futures[handle].result()
return result


Tatu Aalto

unread,
May 3, 2016, 7:55:29 AM5/3/16
to seth.r...@gmail.com, robotframework-users

Ugh

I understand your need but many libraries are not build to support threads or multi processing. So blindly just wrapping keywords in thread may not be the best idea. Perhaps you could get the same result by starting the task as background process. In this way you could have many tasks running in the same time and wait for the task completion. If task can be started as process, the Process [1] library could be the easiest solution.

-Tatu

[1] http://robotframework.org/robotframework/latest/libraries/Process.html

--
You received this message because you are subscribed to the Google Groups "robotframework-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to robotframework-u...@googlegroups.com.
To post to this group, send email to robotframe...@googlegroups.com.
Visit this group at https://groups.google.com/group/robotframework-users.
For more options, visit https://groups.google.com/d/optout.

Pekka Klärck

unread,
May 4, 2016, 4:41:59 AM5/4/16
to seth.r...@gmail.com, robotframework-users
2016-04-28 4:01 GMT+03:00 Seth Rosetter <seth.r...@gmail.com>:
>
> I'm new to this group so let me know if this is duplicate etc. I would like
> to run a series of tasks in parallel and wait for them in a specific order.
> I just started looking at this today and got a mock up done.

Welcome aboard! Running keywords in parallel has been discussed few
times earlier and there are also issues related to it in the tracker.
There is no built-in support for that at the moment and libraries
needing such support need to implement it itself.

Running library keywords in parallel, something like your solution
seems to be doing, shouldn't be too hard to implement in some level.
There would, however, be hard problems like logging that should be
solved someway. Being able to run user keywords in parallel would be
even better, but that would require quite big internal changes to
Robot Framework. The main problem is that currently there is some
internal global date that would be messed up if updated in async
manner. Getting rid of such global data would be a big win in general,
but unfortunately the needed work would also be quite big and require
deep knowledge of Robot's internals.

Cheers,
.peke
--
Agile Tester/Developer/Consultant :: http://eliga.fi
Lead Developer of Robot Framework :: http://robotframework.org
Reply all
Reply to author
Forward
0 new messages