You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To make RPA a first class citizen of Camunda, RPA files should be deployed to Zeebe and linked from the process. Version resolution should be done by Zeebe. RPA files should be part of Process Applications.
For this, we will annotate the RPA files with metadata, such as version tags. The file structure can be a JSON file.
{
"id": "robot_123",
"name": "my robot",
"versionTag": "v123",
"RPARuntimeVersion": "1.0""CamundaVersion": "8.8",
"robotScript": "<content of original .robot file"
}
As the file ending .robot is already taken for "normal" robotframework scripts, we should consider using another file ending, like .rpa.
On a Service Task, a robotFile can be linked using a new extension element:
Zeebe will resolve the resource to a resource key. With the key, the RPA runtime can then fetch the resource directly from zeebe. This allows us to cache results for certain keys and save on bandwidth and Zeebe resources for resource lookup.
For this Approach, we need to following changes:
Zeebe
Deployment phase - Creating a RPA resource on Zeebe
(validation) - can be skipped for initial version
versioning
persistence
caching
Expanding the Model API - This allows us to reference additional resources from a Service Task, using an extension element
Process transformer
Link resource on task activation
evaluate expressions (resource id)
- raise incident if failed
determine resource key by id and version binding
provide resource key along with job
- custom headers
- or as new job field
Get API for retrieving the resource body, implemented as command:
To make RPA a first class citizen of Camunda, RPA files should be deployed to Zeebe and linked from the process. Version resolution should be done by Zeebe. RPA files should be part of Process Applications.
For this, we will annotate the RPA files with metadata, such as version tags. The file structure can be a JSON file.
As the file ending
.robot
is already taken for "normal" robotframework scripts, we should consider using another file ending, like.rpa
.On a Service Task, a robotFile can be linked using a new extension element:
Zeebe will resolve the resource to a resource key. With the key, the RPA runtime can then fetch the resource directly from zeebe. This allows us to cache results for certain keys and save on bandwidth and Zeebe resources for resource lookup.
For this Approach, we need to following changes:
Zeebe
- raise incident if failed
- custom headers
- or as new job field
Modeling
RPA Runtime
The text was updated successfully, but these errors were encountered: