We are excited to announce that Camunda Platform Runtime 7.15.0 is now available, including many new features.
Here are some of the highlights:
- RPA Orchestration: New Release, New Vendor
- Handling BPMN Errors in External Tasks
- New External Task Lock API
- Camunda Forms in Tasklist
- Custom Names for your Camunda Web Apps
- Know your Unique Task Worker Metrics
- Annotate your Incidents
- Maven Project Templates
- Expanded Task Query Filters
- New OpenAPI Endpoints
- SwaggerUI in Camunda Platform Run
- Newly Supported Environments
- Retired Environments
You can download Camunda 7.15.0 or run it with Docker.
Also included in the release:
- Assert 10.0.0 for convenient testing of processes in Java
- Java External Task Client 7.15.0, which can be embedded in Java applications
You can read all about these releases in the dedicated blog post.
For a complete list of the changes, please check out the release notes and the list of known issues. For patched security vulnerabilities, see our security notices.
If you want to dig deeper, you can find the source code on GitHub.
RPA Orchestration: New Release, New Vendor
This feature is only available in the Enterprise Edition of the Camunda Platform. Test it out with a Free Trial.
With the 7.15.0 release, we are bringing a new RPA vendor to the Camunda RPA Bridge. With Camunda Platform Runtime 7.14.0, we introduced the RPA bridge — a solution to easily connect to RPA systems, and speed up RPA bot orchestration.
Now, we are expanding the supported RPA vendor list with Automation Anywhere, integrating the Camunda RPA Bridge with their Automation 360 (formerly A2019) platform.
For more details check out the User and Installation guides.
Handling BPMN Errors in External Tasks
If you read the RPA Bot User guide, you will find out that RPA bots can be orchestrated as External Tasks in a BPMN process deployed to the Camunda process engine. With External Tasks, it is already possible to throw a BPMN Error to the Camunda process engine by using the POST /external-task/{id}/bpmnError Rest API endpoint. This business error may then be caught and handled somewhere else in your business logic.
However, an External Task Worker, like an RPA bot used through the Camunda RPA Bridge, might not be aware of the BPMN process that triggered it. In cases like these, it would be better to evaluate the results of the External Task execution inside the Camunda process engine.
For this reason, we added the camunda:errorEventDefinition extension attribute. The attribute extends the bpmn:errorEventDefinition element with an expression property, where users can define a JUEL expression to be evaluated against the result of the External Task execution.
The expression evaluation is triggered when POST /external-task/{id}/complete or POST /external-task/{id}/failure is called on the External Task, and has access to the ExternalTaskEntity object through the externalTask identifier. If the expression evaluates to true, the appropriate BPMN Error is thrown, otherwise the default (completed/failure) behavior is performed.
For even more details, check out the example in the External Task: Throw BPMN errors with expressions section of the 7.15.0-alpha3 release blog post.
New External Task Lock API
This release also comes with a new option to separate the actions of fetching and locking external tasks. External tasks can be queried with the ExternalTaskService in the Java API, or the GET /external-task or POST /external-task Rest API endpoints.
Once the required external tasks are selected, they can be locked through the new ExternalTaskService#lock(String externalTaskId) method, or through the new POST /external-task/{id}/lock Rest API endpoint.
Camunda Forms in Tasklist
We are excited to announce that the Camunda Modeler 4.7 release adds a new Camunda Forms feature. You can read more about this feature on the dedicated Camunda Modeler 4.7 release blog post.
What does this mean for the Camunda Platform? Well, Camunda Forms will allow you to easily design and configure forms in the Camunda Modeler, and then embed them in the 7.15.0 Camunda Tasklist Webapp.
Custom Names for your Camunda Web Apps
You have probably heard of Camunda Tasklist, Camunda Admin, Camunda Welcome and Camunda Cockpit. But maybe you don’t like these names? As of version 7.15.0, you can adjust the Vendor and App name of all of the Camunda Webapps. To do this, you will need to adjust the config.js located in app/{cockpit|admin|tasklist}/scripts and add the following configuration:
// …
app: {
name: 'Operations',
vendor: 'MyCompany'
},
// …After applying the modifications, the headers of your Camunda Webapps will look like this:
The feature is also documented for each of the webapps (Cockpit, Admin, Tasklist, Welcome).
Know your Unique Task Worker Metrics
The Camunda Platform Runtime 7.15.0 changes the tracking mechanism for Unique Task Worker Metrics. This metric follows the number of unique users that were assigned to user tasks in a given period of time.
Previously, the numbers were retrieved from history data, and for enterprise customers, this may have restricted history cleanup, as the license agreement could require them to report this metric and therefore also have implications on this data specifically.
From now on, this data is stored in a new, separate table. The data is still accessible from the Admin Webapp, but can also be retrieved from the GET /metrics/unique-task-workers/sum Rest API endpoint.
For users not interested in this metric, it can be disabled through the taskMetricsEnabled process engine configuration property. The data can be included for removal through history cleanup by setting the taskMetricsTimeToLive process engine configuration property, or manually through the DELETE /metrics/task-worker Rest API endpoint.
For even more details on this feature, you can checkout our 7.15.0-alpha3 release blog post (Revamped Unique Task Worker Metric).
Annotate your Incidents
Incidents can be annoying, especially when it is not clear what the reason is. You can now add notes to inform a coworker about insights, decisions, or solution ideas. This can be a valuable asset for increasing productivity and transparency. Head over to Cockpit to give them a try.
You can also annotate an incident by its ID through the PUT /incident/{id}/annotation Rest API endpoint.
Maven Project Templates
It can be annoying to set up a new project from scratch. You want to make sure that you added the correct dependencies, applied best practices and added all the bootstrap code. In our 7.15.0-alpha1 and 7.15.0-alpha2, we announced that if you decide to create a Camunda-related project, you can use one of our Maven Archetypes.
Have a look at the documentation to find out what kinds of project templates are available. You can also check out the source code on GitHub.
Expanded Task Query Filters
With this version, we added even more power to Task Querying. You can now filter tasks that have no due date with the withoutDueDate filter. You can also use the new process variable filter for Tasks processVariableValueNotLike to filter Tasks by variable value.
The filters can be applied to a TaskQuery created by the TaskService from the Java API, or through the GET /task and POST /task Rest API endpoints.
Camunda Platform Runtime OpenAPI Specification
New OpenAPI Endpoints
We continued working on expanding our OpenAPI specification. With version 7.15.0, the following endpoints were added:
- Batch
- Decision Definition
- Group
- Identity
- Tenant
- Execution
- Job
- Variable Instance
To learn more about our OpenAPI, visit our official documentation.
SwaggerUI in Camunda Platform Run
With version 7.15.0, we made it easier to test the Rest API endpoints. The Camunda Platform Run distribution now ships with its own Swagger UI. If you run it locally, you can access it via http://localhost:8080/swaggerui/ and try out the REST API.
Have a look at the installation guide for more details.
Newly Supported Environments
- WildFly Application Server 21.0 / 22.0
- Spring Boot 2.4 (with the Camunda Spring Boot Starter 7.15.0)
- MySQL 8.0
- Amazon Aurora PostgreSQL compatible with PostgreSQL 10.13 (also supported as of 7.12.16+, 7.13.10+, 7.14.4+)
- Amazon Aurora PostgreSQL compatible with PostgreSQL 12.4
- PostgreSQL 10.13 (also supported as of 7.12.18+, 7.13.11+, 7.14.5+)
- PostgreSQL 13
PostgreSQL Version Support
From this release, we made the PostgreSQL versions that we support consistent with the PostgreSQL versioning documentation. This means that we add support for major PostgreSQL versions (e.g. 9.6, 10, 11, 12, 13), and support all minor version numbers of these PostgreSQL releases (e.g. 10.4, 10.7, 13.2).
This has been reflected in the Supported Environments section of our documentation, as well as the Update guide for existing users.
Retired Environments
- WildFly Application Server 10.1 / 11
- Apache Tomcat 7.0 / 8.0
- PostgreSQL 9.4
- Oracle 11g
- MariaDB 10.0
You can always check out our currently supported environments in the official Camunda documentation.
Register for the Webinar
If you’re not already registered, be sure to secure a spot at the release webinar. You can register for free here.
Your Feedback Matters!
With every release, we strive to improve the Camunda Platform, and we rely on your feedback! Feel free to share your ideas and suggestions with us.
You can contact us via the Camunda user forum.
