Package: rpadriver
The goal of RPADriver is to make Robot Framework a true RPA tool. This is a RPA helper library built on
the TOS model usingtask-object-storagepackage.RequirementsMongoDBPython >3.7robotframework >3 (>=3.2 for RPAListener)task-object-storageOverviewRPADriver relies on the concept of stages: Every RPA process can usually be divided to at least two stages:ProducerConsumerThere is always one producer, but there might be many consumers (1…n). The naming convention is as follows:TypeNameProducerstage_0Consumer 1stage_1Consumer 2stage_2Consumernstage_nProducer creates task objects, and consumers fetch them from the database for processing.
Splitting the work into stages gives more control over the process execution enables stages to be run (and retried) in isolation.RPADriver consists of two packages:RPALibraryUsed to implement RPA processes largely as Python code, in stage definitions that inherit fromProducerandConsumersuperclasses. Robot Framework acts only as a thin wrapper.RPAListenerEnables RPA process stages to be defined in Robot Framework test data, while still leveragingTOSLibrary.RPALibraryRPALibraryis the classic library originally included as a helper withTOSLibrary.
With this you create robot stage definition in Python code, but still have support for
Robot Framework keywords.Conventional project structureConventional project structure looks like this.
├── keywords
├── libraries
├── pipelines
│   ├── Jenkinsfile
│   ├── consumer.groovy
│   └── producer.groovy
├── resources
│   └── settings.py
├── stages
├── tasks
│   └── main.robot
└── run.pywherekeywords: Robot Framework keyword files.libraries: module for all the Python library code.pipelines: Jenkins pipelines.resources: place to store all miscellaneous files: settings, configs, templates.stages: module for the stage definitions (in Python code).tasks: Robot Framework suites.run.py: startup script for the robot.The robot control flow isrun.py->tasks/main.robot->stages.StageN.ProducerTo build a Producer stage, you need to create a new filestages/Stage0.pywith a class
calledStage0inside. This class should inherit fromProducer.
The class needs at least one method:process_data(self).
This method is the main action to do for every data item that will become task object payload.
Optionally, if you need to first prefetch the data into memory (e.g., into a list), you will need
to define a method calledpreloop_action. This will then feedprocess_datawith data items
one at a time. When prelooping, you will need to defineprocess_datalike this:process_data(self, item),
whereitemis one of the pre-prepared data items.CallStage0.Main Loopfrom Robot Framework to start the loop action (your defined Python methods will be
called automatically inside the library).By inheriting fromProduceryou get:Automatic task object creation.Automatic looping of the data.Automatic error handling.Every software robot you and your team builds will follow the same conventions.ConsumerTo build a Consumer stage, you need to create a new filestages/Stage1.pywith a class
calledStage1inside (the number depending on your stage number).
This class should inherit fromConsumer.
The class needs at least one method:main_action(self, to), wheretois a task object
fetched by the library from your MongoDB database. All you need to do is to define what to do
for every task object.CallStage1.Main Loopfrom Robot Framework to start the loop action (your defined Python methods will be
called automatically inside the library).By inheriting fromConsumeryou get:Automatic task object fetching.Automatic error handling.Every software robot you and your team builds will follow the same conventions.Example usageNote that the examples here are overly simplified.Startup script (run.py):defmain():returnrobot.run("tasks")if__name__=='__main__':sys.exit(main())Main Robot file definition (tasks/main.robot):*** Settings ***LibraryTOSLibrary${db_server}:${db_port}  ${db_name}Library../stages/Stage0.pyLibrary../stages/Stage1.py*** Tasks ***Create task objects from raw data[Tags]stage_0Stage0.Main Loopno_screenshots=TrueDo action on the task objects[Tags]stage_1Stage1.Main LoopProducer stage definition (stages/Stage0.py):fromRPALibraryimportProducerclassStage0(Producer):defpreloop_action(self):"""Read and preprocess an Excel worksheet."""data=self.read_excel()data=self.filter_rows(data)returndatadefprocess_data(self,item):"""
        Do some some operations for every data item (e.g.
        Excel row). This should return a dictionary.
        The return value will be used as the payload for the task object.
        The task objects are created automatically in ``Producer`` object.

        Having ``item`` parameter in the method signature is important.
        """item=self.reader.clean_item(item)returnitemConsumer stage definition  (stages/Stage1.py)fromRPALibraryimportConsumerfrom.errorsimportSYSTEM_OFFLINEclassStage1(Consumer):defmain_action(self,to):"""The library will pass created task objects to this method."""self.do_some_complex_action_on_the_task_object(to)defaction_on_fail(self,to):ifto["last_error"]==SYSTEM_OFFLINE:self.handle_system_offline()self.return_to_main_screen()You can also call your stage methods as Robot Framework keywords withrun_keyword:fromrobot.libraries.BuiltInimportBuiltInrun=BuiltIn().run_keywordclassStage1(Consumer):defmain_action(self,to):run("Do Some Complex Action On The Task Object",to)defaction_on_fail(self,to):ifto["last_error"]==SYSTEM_OFFLINE:run("Handle System Offline")run("Return To Main Screen")RPAListenerRPAListener is a tool that adds transaction management for RPA automations, where the top-level workflow
has been defined natively in Robot Framework script. The library has been implemented as alistener library.In the backend, the RPAListener uses Task Object Storage (TOS), meaning that it relies on MongoDB
for work item persistence.For more information about TOS, seehttps://skaler.gitlab-siili.io/skaler-core/task-object-storageFor more information about Robot Framework, seehttp://robotframework.org.BackgroundRPA processes usually consist of sequential stages. Some stages are to be executed only once (batch).
Others are transactional, where identical steps are performed to a number of work items in a
repetitive manner. RPAListener automates the management of task iterations and work items during
transactional stages.UsageAfter installation, RPAListener can be imported in the Settings-table.*** Settings ***
Library    RPAListener    ${db_server}:${db_port}    ${db_name}Database connection details (address, credentials) are passed to the library using
theTOS convention.Task TagsRPAListener requires special tags to be set on the robot tasks in order to use them as RPA process stages.
Each task should be assigned a tag prefixed withstage_depending on its sequence in the process,Transactional stages, whose steps are to be repeated for each applicable work item,
are marked withrepeattag.Example process consisting of one batch stage followed by one transactional stage:*** Tasks ***
Initial Stage
    [Tags]    stage_0
    Log    This is performed only once

Process transactions A
    [Tags]    stage_1    repeat
    Log    Processing item '${ITEM_ID}'Working with itemsIn transactional stages, RPAListener sets the workable items to the robot scope for each task iteration.
The work item’s payload contents can be accessed in a dictionary named${ITEM}.
The MongoDB ObjectId of the work item can be accessed as{ITEM_ID}(str).
The name of the dictionary variable can be overriden using theitem_variable_nameupon library import.
For example, if you want to refer to the work item as&{PERSON}in your script:Library     RPAListener    db_server=localhost    db_name=newtos    item_variable_name=PERSONRPAListener exposesUpdate Current Itemkeyword, that can be used in a transactional stage
to update the payload contents of the currently worked item, e.g. adding a key-value pair.
The keyword is used similarly toSet To Dictionaryfrom the standard libraryCollections,
except that the targeted dictionary is omitted:| Update Current Item | my_new_key=my_new_value | another_key=another_value |
| Update Current Item | my_new_key | my_new_value | another_key | another_value |Setups and TeardownsDefault test setups and teardowns, (i.e. those set in*** Settings ***) are run for each stage.
Any setups/teardowns set on the robot task with[Setup]and[Teardown]override their
default counterparts.Suite Setup/Teardownset in*** Settings ***are run as per normal,
i.e. only at the beginning and end of the robot execution.Task NamingTask iterations are named according to the worked item. The name determines appears
in the robot log file. By default, RPAListener uses the MongoDB Object-id as task name,
but any field from the payload can be used by specifyingitem_identifier_fieldupon library import. For example, in order to use the values from fieldpayload.myField,
RPAListener should be imported as follows:Library     RPAListener    db_server=localhost    db_name=newtos    item_identifier_field=myFieldSkipping TasksBesides passing or failing, processing of a work item can result in the item being skipped.
This is done when the item violates a predefined business rule, and hence should not be processed further.
When skipped, keyword and task execution ends for that work item, and its status is changed toskip.Skipping is perfomed with the keywordRun Keyword And Skip On Failure, used in conjunction with a
keyword whose failure indicates an invalid work item. For example:| Run Keyword And Skip On Failure | Should Be True | ${invoice_amount} > 0 |
| ...    msg=Invoice is for a zero amount, no action required |Error Handling (experimental)When processing of a work item fails, robot behaviour depends on the type of error raised.
RPAListener exposes keywordsraise_business_exceptionandraise_application_exception.
The first argument for both keywords is the error message. By default, execution continues
despite of a failing work item. If an application exception is raised with argumentfatalset toTrue, robot execution is stopped, for example:| Raise Application Exception | Something went terribly wrong | fatal=${TRUE} |It is possible to assign a stage-specific error handling keyword, to be run upon failure.
This is done by tagging the robot task witherror_handler=[KeywordName], for example:*** Tasks ***
My RPA Stage
    [Tags]    stage_1    repeat    error_handler=Handle My Error
        # ...Task timeouts can be used as per normal robot convention. The timeout specified on a stage
is the maximum time allowed for working one item in said stage. If the timeout is exceeded,
the item is failed and error handler is called.Available keywords/methodsSee the fullAPI documentation.For developersRelease a new version by running:scripts/build.shreleaseYou can also install thewhlpackage found in thedistdirectory withpipinstall<package-name>.whl