-
Notifications
You must be signed in to change notification settings - Fork 197
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat: add RPA getting started guide (#5186)
* feat: add RPA getting started guide * chore: remove experimental RPA from sidebar * chore: adjust overview page * style(formatting): standard technical review * fix(RPA): change config options to correct values * chore(RPA): document RPA flag * add redirects and remove experimental mentions * backport * update htaccess * fix redirect * uppercase rpa folder * fix link * minor grammatical tweaks --------- Co-authored-by: Christina Ausley <christina.ausley@camunda.com>
- Loading branch information
1 parent
d4ff4e2
commit cb10f70
Showing
29 changed files
with
342 additions
and
414 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,78 @@ | ||
--- | ||
id: getting-started | ||
title: Getting started with RPA | ||
description: "Learn how to create your first script, test your script, and automate execution while getting started with RPA." | ||
--- | ||
|
||
:::note | ||
New to RPA? Visit the [overview page](/components/RPA/overview.md) to get familiar with Robotic Process Automation (RPA) capabilities. | ||
::: | ||
|
||
### Create your first script | ||
|
||
<!-- TODO(marstamm): The modeler flag is only required in the alpha releases. Remove this caution for 8.7 minor relase --> | ||
|
||
:::caution | ||
In Camunda Modeler 5.33.1, the RPA editor is enabled only if the `--no-disable-rpa` flag is set. Visit the [Modeler documentation](/components/modeler/desktop-modeler/flags/flags.md) to learn about setting flags. | ||
::: | ||
To get started with RPA, you first need to write an RPA script. [Camunda Modeler](/components/modeler/about-modeler.md) offers an interface for editing and testing your scripts: | ||
|
||
1. **Download Camunda Modeler**: Download the latest version of Camunda Modeler from the [Camunda website](https://camunda.com/download/modeler/). As RPA scripts are run locally on your machine, the RPA editor is only available in [Desktop Modeler](/components/modeler/desktop-modeler/index.md). | ||
2. **Open the RPA script editor**: Open Desktop Modeler and navigate to the RPA script editor under **Testing**. | ||
 | ||
3. **Start writing your RPA script using Robot Framework**: Use the interface provided to write your first RPA script. Scripts use the [Robot Framework](https://robotframework.org/) syntax. | ||
|
||
### Test your script | ||
|
||
Once you have written your script, you can test it on a local RPA worker. | ||
|
||
1. **Start the RPA worker**: | ||
|
||
1. Download the latest version of the [RPA worker](https://github.com/camunda/rpa-worker/releases). | ||
2. Create a new file named `rpa-worker.properties` in the same directory as the RPA worker. This is the configuration file for this worker. | ||
3. Add `camunda.client.zeebe.enabled=false` to `rpa-worker.properties`. This disables connection to Zeebe and allows you to test scripts locally. | ||
4. Start the worker by running the executable. | ||
|
||
2. **Check Desktop Modeler**: Ensure the RPA worker is now connected to Desktop Modeler. The worker should automatically connect. If not, ensure the connection URL is correct. | ||
|
||
3. **Test the script**: | ||
1. Click the test tube (🧪) icon in the footer of Desktop Modeler to open the run dialog. You can add any variables you expect from the process in JSON format. Once you start the execution, the execution tab will open. | ||
2. Review the execution log and the variables created during the script execution within Modeler. | ||
 | ||
|
||
### Automate execution | ||
|
||
Once you are happy with your script and have tested it locally, you can start automating it with Camunda. | ||
|
||
#### Link RPA task to BPMN | ||
|
||
1. **Deploy the RPA file**: | ||
|
||
1. If you haven't already, [set up client connection credentials](/guides/setup-client-connection-credentials.md) for your Modeler. | ||
2. Deploy your RPA script file by clicking on the rocket (🚀) icon in Modeler. | ||
3. Note the ID of your RPA script. You will need this in the next step. | ||
|
||
2. **Add RPA to your process**: | ||
|
||
1. In Camunda Modeler, create a new BPMN file or open an existing one. | ||
2. Add a new task and change it to an "RPA Connector". | ||
 | ||
3. Configure the task with the script ID from the previous step. Add any input mappings required for your script to work. | ||
 | ||
|
||
3. **Deploy and run the process**: | ||
|
||
1. Deploy the BPMN model with the configured RPA task. | ||
2. Start an instance of your process. | ||
|
||
#### Connect worker to Zeebe | ||
|
||
The last step is to configure the RPA worker to pick up the jobs from Camunda. | ||
|
||
1. **Create credentials for the worker**: | ||
|
||
1. Create the necessary worker credentials in Console. You can follow the same steps as for the Modeler credentials. Give your new client the scopes `Zeebe` and `Secrets`. | ||
2. Save the generated credentials in a file named `rpa-worker.properties` in the same directory as your RPA worker executable. | ||
3. Add `camunda.client.zeebe.enabled=true` to `rpa-worker.properties` to start fetching jobs from Zeebe. | ||
|
||
2. **Restart the worker**: If your worker is still running, restart it to apply the new credentials. The RPA worker should now be connected and ready to execute scripts from Zeebe. |
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,14 @@ | ||
--- | ||
id: overview | ||
title: Introduction | ||
description: "Integrate Legacy Applications into Camunda with Robotic Process Automation (RPA)." | ||
--- | ||
|
||
Robotic Process Automation (RPA) allows you to automate manual, repetitive tasks by interacting with applications directly. | ||
Camunda uses RPA to facilitate the integration of legacy applications without accessible APIs into your process orchestration. | ||
|
||
## Getting started | ||
|
||
Camunda's RPA functionality is built around a standalone RPA worker and [Robot Framework](https://robotframework.org/)-based RPA scripts. This setup allows users to develop and execute RPA scripts that integrate seamlessly with existing Camunda stacks. | ||
|
||
Check out the [getting started guide](./getting-started.md) or read up on setting up your workers for [production use cases](./production.md). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,50 @@ | ||
--- | ||
id: production | ||
title: Setting up RPA for production deployments | ||
description: "Understand the specific configuration of your RPA runner to set up your workers for production use cases." | ||
--- | ||
|
||
This article covers the specific configuration of your RPA runner. For the basics on getting started, visit the | ||
[getting started guide](./getting-started.md). | ||
|
||
## Using secrets | ||
|
||
When running an RPA worker with Camunda SaaS, you can add access to [Connector secrets](/components/connectors/use-connectors/index.md#using-secrets). | ||
|
||
To do this, [create client credentials](/guides/setup-client-connection-credentials.md) with both the `Zeebe` and `Secrets` scope and use them in the worker config. | ||
In your `rpa-worker.properties` file, add the secrets endpoint `camunda.rpa.zeebe.secrets.secrets-endpoint=https://cluster-api.cloud.camunda.io` to enable secret fetching. | ||
|
||
In the RPA script, your secrets are stored in the `${secrets}` variable. You can reference a secret like `MY_API_KEY` with `${secrets.MY_API_KEY}`. | ||
|
||
## Labels | ||
|
||
If you manage multiple RPA worker machines and scripts, you might need specialized environments to run certain tasks. | ||
To differentiate different capabilities of runners, you can use tags and labels. | ||
|
||
In the `rpa-worker.properties`, add `camunda.rpa.zeebe.worker-tags=accounting-system`. This worker will now only take up jobs | ||
which are labeled `accounting-system`. If you also want the worker to work on unlabeled tasks, use `camunda.rpa.zeebe.worker-tags=default,accounting-system` instead. | ||
Each worker can have multiple labels and will pick up waiting jobs from all scripts. | ||
|
||
You can add labels to your script when configuring the RPA task in your diagram. Note that a script can only have a single label. | ||
|
||
## Pre- and post-run scripts | ||
|
||
Some of your scripts might require a specific environment to be prepared before the main script starts, for example, downloading certain documents | ||
or setting up connections to internal systems. | ||
You can create and deploy separate RPA scripts and reference them from the properties panel. | ||
|
||
The same works for a post-run script, which can be used for environment cleanup or archiving results. Working directories of the worker's job will be removed once the job is completed. | ||
|
||
## Timeouts | ||
|
||
Runtime can vary greatly from script to script. It is important to set the right timeout for your job to ensure the jobs do not get canceled prematurely. There are two options to set timeouts: | ||
|
||
- **On the RPA task (recommended)**: When configuring the RPA task in your diagram, set the timeout for this script execution. This is recommended as it allows you a per-script configuration. | ||
|
||
- **Default timeout in a worker**: You can configure a default timeout in the `rpa-worker.properties` that is used for every task that does not have a timeout configured on the task. This should be used as a fallback. | ||
|
||
## Concurrent jobs | ||
|
||
By default, each worker only executes one job at the same time. This ensures scripts don't cause side effects while interacting with applications. | ||
|
||
Some use cases, like browser automation, can be side effect free and execution can be parallelized. The `camunda.rpa.zeebe.max-concurrent-jobs` defines how many jobs the RPA worker will pick up. |
101 changes: 0 additions & 101 deletions
101
docs/components/early-access/experimental/rpa/camunda-rpa-framework-library.md
This file was deleted.
Oops, something went wrong.
Binary file removed
BIN
-195 KB
docs/components/early-access/experimental/rpa/img/rpa-task-example.png
Binary file not shown.
Binary file not shown.
84 changes: 0 additions & 84 deletions
84
docs/components/early-access/experimental/rpa/rpa-integration-with-camunda.md
This file was deleted.
Oops, something went wrong.
Oops, something went wrong.