Execution Environment Options

Unattended robots have the freedom to run "where no humans are needed", which opens up many options. As Robocorp tooling supports Windows, macOS and Linux, the options widen. We also add the support of Cloud Containers, which means you get the environment when you need it.

The downside is all the options can make your head spin when coming in from the "Only on dedicated Windows machines" world. When you do not need to worry about each executor costing a hefty fixed price, you can re-think your infrastructure and we have seen some big saving numbers around this topic.

Use cases

So let's clarify things by listing out the options by looking at some use cases.

Notes for all cases:

  • Robocorp Control Room handles the orchestration of executions when executors are available, prioritization, up-to-date robot code, monitoring, collection, security, and data retention of artifacts, logs, and work items.
  • The self-hosted machine can be an actual machine or a Virtual Machine.

I am automating a website, reading excel and sending emails and do not know what kind of infra I need.

Robocorp Hosted Cloud Containers are probably the thing for you. The Control Room automatically spins into these Linux containers to action when needed. Do not be scared by the mention of Linux here as containers can do a LOT, and you do not need to set up anything.

Browser automation, Email handling, anything dealing with just APIs and data layer access, and the initial data input parsers can run in the containers.

Container executions are also the place to be if you need multiple executors running in parallel to get a task as fast as possible in actual wall-time.

--> Read more

I have a specific Windows application that I need to automate.

Workforce Agent running with full desktop access on a self-hosted Windows machine is your option.

Having full desktop access that uses user accounts you can specify, enables just about any automation and gives the needed control.

The real kicker here is that you can run multiples on a single machine, reducing infra-costs by a lot!

If the target application can run with multiple Windows users on the same machine, this is the way to get the most out of your hardware.

With Environment Groups you can even get your self-hosted workforce running in parallel.

--> Read more

I have a specific machine that has access to the service I need to automate.

Workforce Agent running as a background service on a self-hosted machine is probably a good fit for this case.

If the automation does not require interaction with the desktop, you can set up the Workforce Agent to run as a background service on all platforms (Windows/Linux/macOS).

This is also a good choice if the automation handles sensitive data that you don't feel comfortable sending anywhere, as you can disable all log sending and decide what artifacts are sent to Control Room.

--> Read more

I am one with things like Docker and Kubernetes.

Docker containers and setting up a Kubernetes Cluster of your own give you the complete control and power of an on-demand executor.

--> Read more

I'm just getting started and would like to test Workforce Agent on my machine.

Running Workforce Agent with the UI is meant for this purpose.

In this case, the Agent is only running when you are logged in to the machine and you can test out things "just like the real deal".

We do NOT recommend this for any production bots as you would need to keep the machine on and logged in constantly.

--> Read more

Details

In the heart of all the use cases above, the Robocorp Workforce Agent handles the communications between whatever machine, VM or docker is running it and the Robocorp Control Room. Note that the Workforce Agent does not need the UI application for most cases to be installed. In general, for unattended robot runs, the human users should stay out of the way to not disturb the bot in action.

You should be able to find the use cases above from the overview picture below:

Robocorp Hosted Cloud Containers

  • No infra setups, the container start when execution is needed
  • Headless Linux can do a lot, except run Windows applications 😉.
  • More details

One or more desktop automation on a single machine

  • You control the target machine and what applications are installed there.
  • Full access to a user desktop, where you control the user accounts and what they can do.
  • Setting up multiple user accounts on the same machine enables you to run multiple robots in parallel
  • Setup details

Workforce Agent as background service

  • Just like the above but without access to the user interface.
  • You control the target machine and what applications are installed there.
  • For cases where the machine serves as access to specific resources.
  • Setup details

Docker and Kubernetes setups

  • A way to set up your own docker executors
  • With Kubernetes, you can set up your executor cluster that only spins up the executor when needed.
  • For bigger cases where the setup of individual VMs slows you down in scaling.
  • Docker guide
  • Kubernetes guide

Running Workforce Agent UI for testing

  • For your first tests, set up Workforce Agent on your machine to test the connections and see the automation in action.
  • This is meant for testing only; if you use this in earnest, you need to be hands-off with your machine when the automation is triggered from Control Room.
  • Setup details
April 14, 2022