Camunda BPM Runtime 7.14.0-alpha3 Released

By
  • Blog
  • >
  • Camunda BPM Runtime 7.14.0-alpha3 Released
TOPICS

30 Day Free Trial

Bring together legacy systems, RPA bots, microservices and more with Camunda

Sign Up for Camunda Content

Get the latest on Camunda features, events, top trends, and more.

TRENDING CONTENT

We are happy to share the third alpha release of Camunda BPM Runtime 7.14 with you!

This release features the following improvements:

  • Improved External Task Fetch and Lock
  • Cleanup of History Cleanup Logs
  • REST API: Fetch Telemetry Configuration
  • Cockpit: Asynchronously Set Variables to Process Instances
  • Cockpit: Plugin Point for Batch Operations
  • Support for WildFly 20
  • 11 Bug Fixes

You can Download Camunda for free or Run it with Docker.

For a complete list of all improvements, take a look at the release notes. Please also see the list of known issues.

If you want to dig in deeper, you can find the source code on GitHub.

Improved External Task Fetch and Lock

In situations where’re you’re using highly concurrent requests to fetch external tasks (e.g. when you run many external task clients for the same topic), it was possible that requests could fail with a NullPointerException due to a concurrent modification. Example: A request fetches a task that is completed and thus deleted in parallel. This alpha release improves the handling of this situation so that the fetch and lock request no longer fails. Instead, such tasks are removed from the result set. The implementation was contributed by community member Harish Malavade.

Cleanup of History Cleanup Logs

Data produced by the engine, like finished Tasks, finished process instances and executed jobs can be stored in history tables. Depending on the usage of the BPM platform, the collection of history data can grow rapidly. To counter this we can schedule periodic cleanup of history data. Each time the history cleanup job is executed, it will search for expired history data and delete it, including entries from the historic job log. Since the history cleanup job is a job in itself, it will also produce historic job log entries potentially resulting in a long history job log containing only history cleanup job logs (because the rest was cleaned up).

To give admins more control over their history, we created a process engine configuration property to enable cleanup of historic job log entries produced by the history cleanup job. The historyCleanupJobLogTimeToLive property takes an ISO-8601 formatted duration String specifying only a number of days (PT30D and PT1D is allowed while PT1H or PT5D10H is not).

Please note, that this feature only works in conjunction with removal-time based history cleanup. More information about the new property and process engine configuration in general can be found in the docs.

REST API: Fetch Telemetry Configuration

The upcoming Camunda BPM Runtime 7.14.0 minor release will provide an option to collect and send environment and usage data that will help us to improve our products for you. The option is not applied by default, and in this alpha we added a new REST API endpoint where the telemetry configuration can be checked. Here is an example of what the request/response looks like:

GET /telemetry/configuration<br>{<br> enableTelemetry: true<br>}

For more information, please have a look at REST API documentation here. The Java API is already available via the ManagementService.
Read more about telemetry in the docs. With this alpha the telemetry cannot be activated in bpm-platform.xml or standalone.xml.

Cockpit: Asynchronously Set Variables to Process Instances

Sometimes it is necessary to add or update data of an already running process instance. For example, when a user entered incorrect data at the beginning of a process, the data needs to be corrected on-the-fly. In Cockpit, this is already possible by setting or updating a variable during process runtime. While this feature is helpful, it becomes a repetitive task when the same variable needs to be set to many process instances at once.

With this release, we introduce a new feature in Cockpit to set variables to the root scope of process instances asynchronously. The new batch operation allows you to set one or more variables to a group of process instances that can be filtered according to several criteria.

Please also see the documentation about the Java API and REST API.

Cockpit: Changes to the Plugin API

With the last alpha release, we introduced the new Frontend Plugin API. We changed a few details in the API since then to clarify what is needed for the plugin to work.

Every plugin point now supports the same top-level attributes: id, pluginPoint, priority, render and unmount. A detailed explanation for these can be found in our docs. These can be used for every documented plugin point. Certain plugin points require additional configuration, which will be capsuled in a properties object, which is specific for every plugin point. The most common property is the label attribute, like in the process definition runtime tab. The new batch operations plugin shows what a more complex plugin point can look like.

To make it easier to create requests to the Camunda REST API, the argument of the render function now has the api property. It contains the API endpoints for the engine and webapps, as well as the current engine and the CSRF tokens. This makes creating requests much easier. You can access it from you plugin like this: render: (node, {api}) => {console.log(api)}. Check out our examples to see how it is used.

Cockpit: Plugin Point for Batch Operations

Operations affecting many process instances can be grouped into a batch operation and executed in the background without blocking the normal execution. With Camunda BPM, you can create any kind of operations using the Java API. To make your custom batch operations more accessible, we added a new Plugin point to cockpit to make it easier to trigger them.

The interface allows you to render a custom form to define your own payload for the operation. Camunda offers filter options for process instances, decision instances and batches. Check out the details and an example in the Plugin Point Documentation.

Support for WildFly 20

With Camunda BPM Runtime 7.14.0-alpha3 we added support for WildFly Application Server 20. You can find an overview of all supported environments in the documentation.

Share Your Thoughts with Us!

Your feedback is really important to us, so please download Camunda BPM Runtime 7.14.0-alpha3, try it out, and let us know what you think about it.

You can contact us in the forum, send a tweet to @Camunda, or file a bug in our ticket system.

Try All Features of Camunda

Related Content

We're streamlining Camunda product APIs, working towards a single REST API for many components, simplifying the learning curve and making installation easier.
Learn about our approach to migration from Camunda 7 to Camunda 8, and how we can help you achieve it as quickly and effectively as possible.
We've been working hard to reduce the job activation latency in Zeebe. Read on to take a peek under the hood at how we went about it and then verified success.