Data

Tools

Indexes

Applications

Experiments

Awesome

An open API service indexing awesome lists of open source software.

https://github.com/camunda/rpa-worker

Zeebe job worker for running RPA tasks
https://github.com/camunda/rpa-worker

automation camunda robotframework rpa zeebe-worker

Last synced: 7 days ago
JSON representation

Zeebe job worker for running RPA tasks

Awesome Lists containing this project

README 

          
= Camunda RPA Worker



The Camunda RPA Runtime is designed to bridge the gap between Robotic Process Automation (RPA) bots and the Camunda

workflow engine, enabling you to seamlessly integrate your task workers with Camunda.



== Getting Started



=== Obtaining the RPA Worker



Downloads and details for container images are available on the  https://github.com/camunda/rpa-worker/releases[Releases]

page.



=== Configuration



The RPA Worker can source its configuration either from a configuration file, or environment variables. The RPA Worker

will look for a file named `rpa-worker.properties` in the current directory.



==== Zeebe



Connecting to a Camunda cluster requires providing the configuration for the Zeebe client. The RPA Worker uses the

https://docs.camunda.io/docs/apis-tools/spring-zeebe-sdk/getting-started/#[Spring Zeebe] client, and so uses the same

https://docs.camunda.io/docs/apis-tools/spring-zeebe-sdk/getting-started/#configuring-the-camunda-8-connection[Configuration Properties].



.Example Camunda local dev configuration

----

camunda.client.mode=selfmanaged

camunda.client.zeebe.grpc-address=http://zeebe.camunda.local

camunda.client.zeebe.rest-address=http://zeebe.camunda.local

----



.Example Camunda SaaS configuration

----

camunda.client.mode=saas

camunda.client.auth.client-id=

camunda.client.auth.client-secret=

camunda.client.cloud.cluster-id=

camunda.client.cloud.region=



camunda.rpa.secrets.backend=camunda

----



.Example custom/dev SaaS configuration

----

camunda.client.mode=selfmanaged



camunda.client.cloud.cluster-id=

camunda.client.cloud.region=



camunda.client.auth.issuer=https://login.cloud.dev.ultrawombat.com/oauth/token

camunda.client.auth.client-id=

camunda.client.auth.client-secret=



camunda.client.zeebe.rest-address=https://${camunda.client.cloud.cluster-id}.${camunda.client.cloud.region}.zeebe.dev.ultrawombat.com

camunda.client.zeebe.grpc-address=https://${camunda.client.cloud.cluster-id}.${camunda.client.cloud.region}.zeebe.dev.ultrawombat.com

camunda.client.zeebe.base-url=https://${camunda.client.cloud.region}.zeebe.dev.ultrawombat.com/${camunda.client.cloud.cluster-id}

camunda.client.zeebe.audience=zeebe.dev.ultrawombat.com



camunda.rpa.zeebe.auth-endpoint=https://login.cloud.dev.ultrawombat.com/oauth



camunda.rpa.secrets.backend=camunda

camunda.rpa.secrets.camunda.token-audience=secrets.dev.ultrawombat.com

camunda.rpa.secrets.camunda.secrets-endpoint=https://cluster-api.cloud.dev.ultrawombat.com

----



TIP: When creating an API client in the Camunda Cloud Console, the autogenerated configuration file provided contains

most of the necessary configuration for connecting to production Camunda SaaS stacks.



==== Local-only Working



The Zeebe startup check and subscriptions can be disabled by setting

`camunda.client.zeebe.enabled` to *false*. 

Although the Zeebe Client itself cannot be disabled and it will still log,

the application will keep running allowing local working and these messages can be ignored.



==== Python



When the RPA Worker sets up its Python environment it will install a default set of dependencies. 



Additional dependencies can be installed by providing a supplementary `requirements.txt` file with the 

`camunda.rpa.python.extra-requirements` property.



.extra-requirements.txt

----

numpy==1.26.4

jmespath

----



.rpa-worker.properties

----

camunda.rpa.python.extra-requirements=extra-requirements.txt

----



If the extra requirements files changes, the RPA Worker will install the new dependencies at the next restart, although

no dependencies will be removed. If the Python environment is deleted then the RPA Worker will recreate it from scratch. 



== Robot Job Execution



=== Robot Runtimes



The RPA Worker supports two runtimes for executing Robotframework. 



==== The Python Runtime



The Python runtime creates a dedicated Virtual Environment using an available Python distribution. 

The Python distribution may already be present on the host, or it may be provisioned automatically by the RPA Worker on 

platforms where this is supported. 



The first time the environment is created the RPA Worker will install the necessary base dependencies into the 

environment. 

It will also install, if configured, any additional user-supplied extra requirements. 

If the base requirements change, such as a new version of the RPA Worker updating these dependencies, or the extra 

requirements are updated, then the RPA Worker will update the environment with the new dependencies automatically. 



As dependencies are fetched from the internet, the Python Runtime requires an internet connection.



==== The Static Runtime



The Static Runtime is a pre-built Python environment which is bundled with the RPA Worker. 

It contains a Python interpreter, as well as all the base dependencies, statically linked together in a single 

executable.

As such, when using the Static Runtime it is not possible to install any extra requirements. 



As the base dependencies are included in the Static Runtime, it does not require an internet connection.



==== Choosing a Runtime



The choice of runtime can be configured via the `camunda.rpa.python-runtime.type` configuration property. 

It supports three values: `auto` (the default), `static`, and `python`. 



When the runtime is set to `auto`, the RPA Worker will run the following checks to see if the Python Runtime is 

supported:



* If there is an existing Python environment created by the RPA Worker then this will be used

* If an internet connection is detected, **AND**:

** There is a local Python distribution at a supported version (>=3.10,<3.12) then this will be used to create a new

Virtual Environment, **OR**

** There is no local Python, but it can be provisioned automatically on the current platform (Windows), then Python 

will be provisioned in this way and used to create a new Virtual Environment



If these conditions are not satisfied then the RPA Worker will fall back to the Static Runtime.



NOTE: The Static Runtime is not supported in the JAR distribution of the RPA Worker



=== Built-in Variables



The RPA Worker makes the following environment variables available to the Robot execution:



|===

|Variable |Description



|`RPA_WORKSPACE_ID`

|The workspace ID of the current job



|`RPA_WORKSPACE`

|The full path to the workspace of the current job



|`RPA_SCRIPT`

|The name of the currently executing script



|`RPA_EXECUTION_KEY`

|The execution key of the currently executing script



|`RPA_ZEEBE_JOB_KEY`

|The Zeebe Job Key which triggered the Robot execution



|`RPA_ZEEBE_JOB_TYPE`

|The Zeebe Job type



|`RPA_ZEEBE_BPMN_PROCESS_ID`

|The current BPMN process ID



|`RPA_ZEEBE_PROCESS_INSTANCE_KEY`

|The current process instance key



|===



== Configuration Reference



[stripes=even]

|===

|Property |Description| Default Value



3+| *Python Properties*



|camunda.rpa.python.path

|The directory in which the Python environment will be created

|`${user.dir}/python/venv/`



|camunda.rpa.python.download-url

|The URL from which the portable Python will be downloaded if no system Python is available (Windows only)

|`https://github.com/winpython/winpython/releases/download/11.2.20241228final/Winpython64-3.13.1.0dot.zip`



|camunda.rpa.python.download-hash

|The expected SHA-256 hash of the file at `download-url`

|`47b9a4ce75efb29d78dda80716d6c35f9a13621efd3a89ef8242a114ef8001a3`



|camunda.rpa.python.extra-requirements

|The path to additional Python requirements that should be installed when setting up the Python environment

|_None_



|camunda.rpa.python.interpreter

|Path to a specific Python interpreter to use, rather than searching the path

|_None_



|camunda.rpa.python-runtime.type

|Which runtime to use for executing Robot. Can be `auto`, `python`, or `static`

|`auto`



3+| *Robot Properties*



|camunda.rpa.robot.default-timeout

|The default timeout to use when no other timeout is specified (ISO 8601 duration string)

|`PT5M` (5 minutes)



|camunda.rpa.robot.fail-fast

|Stops task execution if any task fails

|`true`



3+| *Sandbox Properties*



|camunda.rpa.sandbox.enabled

|Whether the script evaluation API should be available

|`true`



3+| *Zeebe Properties*

|camunda.client.zeebe.enabled

|Whether the Zeebe integration should be enabled

|`true`



|camunda.rpa.zeebe.rpa-task-prefix

|The prefix used to construct the task subscription key

|`camunda::RPA-Task::`



|camunda.rpa.zeebe.worker-tags

|The worker tag(s) this worker should subscribe to (comma-separated)

|`default`



|camunda.rpa.zeebe.max-concurrent-jobs

|How many Robot jobs from Zeebe to run concurrently

|`1`



|camunda.rpa.zeebe.auth-endpoint

|The authentication endpoint that should be used for authenticating before sending requests

|`https://login.cloud.camunda.io/oauth`



|camunda.client.zeebe.audience

|The token audience to use when authenticating for Zeebe

|`zeebe.camunda.io`



|camunda.client.cloud.region

|The region for Camunda SaaS

|_None_



|camunda.client.cloud.cluster-id

|The cluster ID for Camunda SaaS

|_None_



|camunda.client.zeebe.base-url

|The region for Camunda SaaS

|`https://${camunda.client.cloud.region}.zeebe.camunda.io/${camunda.client.cloud.cluster-id}`



|camunda.client.auth.client-id

|The client ID to use when authenticating with Zeebe

|_None_



|camunda.client.auth.client-secret

|The client secret to use when authenticating with Zeebe

|_None_



3+| _See the 

https://docs.camunda.io/docs/apis-tools/spring-zeebe-sdk/configuration/#additional-configuration-options[Spring Zeebe Configuration Reference]

for other supported properties_



3+| *Secrets Properties - General*

|camunda.rpa.secrets.backend

|The secrets provider backend

|`none` _(Secrets disabled)_



3+| *Secrets Properties - Camunda (`...backend=camunda`)*

|camunda.rpa.secrets.camunda.secrets-endpoint

|The endpoint providing the Camunda secrets service

|`https://cluster-api.cloud.camunda.io`



|camunda.rpa.secrets.camunda.secrets.token-audience

|The token audience to use when authenticating for secrets

|`secrets.camunda.io`



3+| *General Properties*

|server.address

|Network address to which the server should bind

|`localhost` for standalone, any for container



|logging.file.name

|Output file for log file (non-containerised)

|`rpa-worker.jsonl.log`

|===



== Supported Configuration



The RPA Worker will source its configuration from configuration files and/or environment variables.

The precedence order is documented in https://docs.spring.io/spring-boot/reference/features/external-config.html[Spring's Externalized Configuration] documentation.



.Configuration Files

A configuration file can be a Properties or a YAML document. 

It can have the name `application` or `rpa-worker`. 

It can be placed in the working directory of the Worker, or in a directory named `config` therein. 

The following are all valid paths to RPA Worker configuration files:



* `rpa-worker.properties`

* `application.properties`

* `rpa-worker.yaml`

* `application.yaml`

* `config/rpa-worker.properties`

* `config/application.properties`

* etc



.Environment Variables

Preferable for container-based deployments, the RPA Worker can source its configuration from environment variables. 

The name of the environment variables follow https://docs.spring.io/spring-boot/reference/features/external-config.html#features.external-config.typesafe-configuration-properties.relaxed-binding.environment-variables[Spring's Binding Rules],

which can be briefly summarised as:



. Convert the property name to upper-case

. Replace dots with underscores

. Remove hyphens



For example `camunda.rpa.zeebe.worker-tags` would become `CAMUNDA_RPA_ZEEBE_WORKERTAGS`.



Launching a dev container with Zeebe connection details, mapping the Worker's listener port to the host, might look like:

[source,shell]

----

$ docker run --rm -it \

    -p 36227:36227 \

    -e CAMUNDA_CLIENT_MODE=saas \

    -e CAMUNDA_CLIENT_AUTH_CLIENTID=abc123 \

    -e CAMUNDA_CLIENT_AUTH_CLIENTSECRET=def234 \

    -e CAMUNDA_CLIENT_CLOUD_CLUSTERID=ghi345 \

    -e CAMUNDA_CLIENT_CLOUD_REGION=lpp-1 \

    ghcr.io/camunda/rpa-worker:

----



== License



These source files are made available under the Camunda License Version 1.0.