I have published recently my work on the robotframework-camunda library. The library provides keywords for processing workloads orchestrated from Camunda.
Obviously, such visualizations, must support Camunda Cockpit. The repository now includes build for a such bundle (and change from Webpack to Rollup, because I was unable to figure out, how to build Cockpit-compatible bundle with Webpack).
Camunda Cockpit really got easy to extend in Camunda 7.14.0. For example, if robotframework-camunda would upload Robot Framework report files as process variables (files) into process (or possibly as task local variables, if those are available through Camunda history API), it could be possible to render those in the Cockpit.
FYI also that I’ve been working on some small Cockpit plugins on 7.14.0 to make at least some history visible with just the Community edition (currently only for running processes, but I’m working on something minimal for completed processes).
When I’m working with external tasks next time, I’ll check if “local variables” (in external task completion API) are available… if so, I open an issue into robotframework-camunda for more discussion. Being able to raise failed Robot tasks as incident into Cockpit, show the robot log and allow to use Cockpit UI for retry the task should be useful.
I confirmed that in calling POST /external-task/{id}/complete it is possible to pass files as localVariables. They will be scoped for the specific external task, what would make it possible to use generic variable names when passing e.g. log.html when completing an external task.
Of course, the open source version of Camunda does not include user interface for browsing local variables for completed tasks. The information is available by REST API though, so it is possible make a cockpit extension for that.
Saving log files for failing tasks requires a bit different approach. POST /external-task/{id}/failure does not support updating variables and therefore local variables must be updated by calling POST /execution/{id}/localVariables with the execution id from external task instance data. Now, when calling failure to raise incident, the log.html saved as a task local variable, would be readable at Camunda Cockpit and possibly help fixing the issue causing failure before retrying the task. The default behavior of Camunda Cockpit is to show download link for file variables.
That all said, I am not sure how this would fit with the current robotframework-camunda -approach, where we are calling Camunda from Robot Framework and don’t have the log files yet Well, food for though anyway.
I supervise a student project in February where we implement a service fetching workloads from camunda and running robot tasks. That would be different approach than robotframework-camumda. It would be similar to the POC @datakurre made with camunda + Robocorp, only independent from Robocorp (I still see a valid use case in this scenario for Robocorp afterwards, but different topic).
Nice! That sounds like “RPA bridge” for Robot Framework. Please, ping me when it is progressing. Maybe we could amend it with an accompanying Cockpit plugin to better show robot tasks and their reports.
icons will help visualizing the integration!
Well, food for though anyway.