Python Automation

How to manage the execution of your automation, your guide to know BotCity Runner

The process of delivering an RPA automation has a few phases. We can start by mapping existing processes, how they work, and how to improve them. After this, we need to analyze what is worth automating, and then the demand is sent to your development team. During this stage, you can define how you will develop your bots according to the needs of each process. And more: how will you run them? We have a tool called BotCity Runner to run your bots, which you’ll learn more about in this article.

Why must I worry about where and how my automation will run?

Depending on the process to attend, automation may need to be developed directly on the user’s machine, for example. Or on a computer that could be a server. Or it may be more worthwhile to make this robot available on a virtual machine or in a cloud, be it AWS, Google Cloud, Azure, or others. These definitions can directly influence certain items:

  • How to develop this robot: headless mode and configuration.
  • What should be in the environment to execute the automation: what needs to be installed in this environment to run the bots.

Let’s explore more of the topics explained above.

How to develop the robot considering where it will need to run

During the development of your automation, you may have to decide whether or not to run it headless. What does that mean?

  • Headless mode activated: when your automation can be run in the background without necessarily interacting with a graphical interface. Examples: crawlers, data processing, generating reports, making integration between different systems using APIs, or others. In this case, we would use the runner background.
  • Headless mode deactivated: when your automation cannot run in the background because it needs interaction with graphical interfaces and cannot have the mouse and keyboard compromised during its execution. Examples: filling forms, interacting with systems such as SAP, TOTVS, or others. In this case, we would use the desktop runner.

You can check our article to learn more about the differences between Runner Desktop and Runner Background.

In your code, using BotCity’s Open Source Web framework, you can configure headless as follows:

# Creating the bot object using the Web framework
bot = WebBot()

# Setting headless to true to run automation in the background
bot.headless = True

Note: If you don’t want to run the automation in headless mode, change the value to False according to the following code.

#Creating the bot object using the Web framework
bot = WebBot()

# Setting headless to false so as not to run automation in the background
bot.headless = False

For more details, see our documentation.

What should the environment be like, considering where the robot will run?

Suppose you develop your automation with our frameworks, for example. In that case, you may need to install some packages where you will run the automation, such as Python, some frameworks, libraries used in the code, or others. This may change according to the technology you used during development. A correctly configured environment can avoid many problems at runtime.

What is it, and how do you manage the execution with BotCity Runner?

BotCity Runner is the tool that will run your automation, searching for the tasks that need to be executed and configuring the environment on the machine where the execution will occur.

runner screenshot

It must be installed and configured following the guidelines in our documentation at the location where your automation is to run:

  • can be on the client’s computer;
  • can be on a virtual machine;
  • can be in the cloud (AWS, Google Cloud, Azure, or others).

How does the BotCity Runner know how to prepare the environment and what it needs to run?

While deploying your automation in our Orchestrator, you define the runner(s), choosing one you already have or creating a new one if necessary.

screenshot of the orchestrator in the easy deploys menu

By making this configuration, you are allowing the BotCity Orchestrator to communicate perfectly with the BotCity Runner, and the connection between the automation and the runner(s) defined for it will happen.

the image shows a flow in which on the left-hand side there is an area called BotCity Orchestrator and inside it is a rectangle representing automation. Also in this space, there are two rectangles representing two different tasks connected to the automation. On the right-hand side is another area called Computer that will run the automation. Inside this area are two rectangles representing different runners. There is an arrow pointing from the automation towards the runner.

The runner will then know what it needs to configure and install in the execution environment and which tasks it must execute according to the same automation you configured in the Orchestrator.

How does BotCity Runner work?

When the runner is online (active), it asks BotCity Orchestrator if any new tasks from the automation are defined for it to run. As long as tasks are ready for execution for that specific runner, it will search for that task, prepare the environment, execute it, and ask again if there are any new tasks to complete.

The flow is in the following order: It starts with the item Start. The next step is to check whether the runner is online. If not, it goes to the action of trying to reconnect and then checking again if it is online. If the runner is online, the next step is to check if it has any new tasks. If it doesn't, it checks the runner's status and then checks for tasks again. It stays in this flow until it has a new task to run. If it has a task, the runner goes to the step of preparing the environment and then to the step of executing the task. It then checks again to see if it has a new task to run.

* If the runner goes offline for some reason, the Orchestrator waits five minutes while the runner tries to become active again. If it doesn’t become online again, the BotCity Orchestrator will send an e-mail to let you know.
A runner can go offline for many reasons: a problem on the computer where it is set to run, the computer shut down, the connection to the network has been lost, the runner has been closed abruptly, and so on.

Number of automation per runner and parallelism

Remember when you had to choose the runner the automation should use when deployed? It’s important to remember that the automation can be connected to multiple runners if necessary.

screenshot of easy deploy with two runners selected for automation

Doing this can be very useful because if all the selected runners are available when you create several tasks for that particular automation, they can be run in parallel, speeding up the process.

It’s also important to note that you can connect more than one automation to the same runner. The runner will execute tasks according to the order in which they were created or the prioritization you set up. You can see more details about this priority functionality in the documentation.

screenshot of the new task screen with an arrow pointing to the field for filling in the task execution priority

Okay, so what’s the summary of all this?

BotCity Runner is the tool that must be configured on the site where the automation is to run or on a machine in the cloud, and then connect to BotCity Orchestrator to pull up the tasks that are ready to be executed at a given time in the queue, according to order and prioritization, as well as being the tool that will help prepare the environment for this execution to take place correctly.

How do I test these features?

Create your free account and use the community license to test BotCity’s tools. And if you have any questions, we’re at the Slack community or our forum to help each other. 

She/her. I am a Tech Writer and Developer Relations at BotCity. I am also a tech content creator who loves tech communities and people.

Leave a Reply

%d