We’re pleased to announce the last alpha release of Camunda Platform Runtime 7.16. This release features the following improvements:
- New Components for Camunda Forms
- Cockpit: Navigate to Called Processes
- Cockpit: Correlate Message Batch Operation
- Exclusive Batch Jobs
- Job Executor Priority Ranges
- Support for Azure SQL
- Demo Data for Camunda Run
- 16 Bug Fixes
You can download Camunda for free or run it with Docker.
For a complete list of all the improvements, take a look at the release notes. Please also see the list of known issues.
If you want to dig deeper, you can find the source code on GitHub.
New Components for Camunda Forms
You can now use five new components in Camunda Forms within Tasklist. The following four components allow for data input:
- Number
- Checkbox
- Select
- Radio
As with the existing text field component, these fields can map to a process variable. Beyond that, Camunda Forms now also supports a static text component to include custom HTML or markdown in your form.
You can create these forms with the latest Camunda Modeler release. Learn more about the different forms that Tasklist supports and how to reference them in our Forms User Guide.
Cockpit: Navigate to Called Processes
If you use BPMN call activities for decomposing your processes, you’ll love Cockpit’s newest navigation feature. Click on a call activity to move directly to the called process. Or check the Called Process Definitions tab for an overview of all your call activities.
A new REST and Java API are backing this feature so you can use it in your applications with flexibility:
- REST API: Get Static Called Process Definitions
- Java API: RepositoryService#getStaticCalledProcessDefinitions
This feature is limited to call activities that do not use EL expressions to determine the called process.
Cockpit: Correlate Message Batch Operation
This feature is only available in the Enterprise Edition of Camunda Platform. Test it out with a free trial.
When an execution waits in a message-catching flow-node, you can use Message Correlation to continue the execution. Previously, it was already possible to correlate messages synchronously via a Java or REST API. With this release, we’re introducing a new cockpit batch operation to correlate messages asynchronously.
As shown above, you can directly open the batch operation page when you already know all the details for your asynchronous message correlation. Alternatively, you can also navigate to it from the process instance or definition view by clicking on the Correlate Message action button on the right side next to the BPMN diagram or by hovering over the message-catching flow-nodes. Either way, a modal dialog will open to confirm or adjust your selection. Next, you will progress to the batch operation page. Your batch operation will already be prefilled with the message name and a process instance or definition filter criterion, restricting the subset of affected process instances.
Sometimes the triggered execution will require data. You can use process variables to add it to your correlate message batch operation.
Read up on all the details in the User Guide and the Cockpit documentation.
Exclusive Batch Jobs
Batches help to offload workloads from the current execution to background processing. In Camunda Platform, a batch consists of multiple jobs. The job executor executes them asynchronously in the background. That job executor is also responsible for executing other jobs created by process instances, for example, timer and asynchronous continuation jobs.
The job executor can also run multiple jobs in parallel. Those jobs can potentially modify the same process instances, which you might not desire in your use case. Therefore, the job executor provides a concept of exclusive jobs. For one process instance, exclusive jobs are not run in parallel but in sequential order.
With this release, we have enabled the execution jobs of the following batch operations to run as exclusive jobs:
If the execution jobs of those batch operations relate to a single process instance, they are exclusive jobs. You can find further details in the documentation of the batch operations listed above.
Job Executor Priority Ranges
By default, the job executor executes all jobs regardless of their priorities. But some jobs might be more important to finish sooner than others. Job prioritization can help to mitigate such situations. But given a high enough load, we still might face starvation situations: a job executor is always busy working on high-priority jobs and never manages to execute those with the lower priority.
To prevent this, you can now specify a priority range for a job executor. The job executor will only acquire those jobs that are inside its priority range. This feature is handy if you want to separate multiple types of jobs from each other. For example, short-running, urgent jobs with high priority and long-running jobs that are not urgent but should finish eventually. Setting up a job executor priority range for both types will ensure that long-running jobs can not block urgent ones. Make sure to dig into all the details of this new feature over at our documentation.
Support for Azure SQL
Camunda now runs on the Azure SQL family of databases as well. We now support:
- SQL Server on Azure Virtual Machines
- Azure SQL Managed Instance
- Azure SQL Database
From version 7.16.0-alpha5, you can spin up an Azure SQL flavor and use it to run the Camunda Platform. Note, however, that Camunda supports the Azure Database Compatibility Level values of the Camunda-supported Microsoft SQL Server versions. Have a look at the Camunda support for Azure SQL documentation for more details on configuring your Azure SQL instance.
Demo Data for Camunda Run
Getting started with Camunda by using Camunda Platform Run is a great way to go, however, this pre-packaged distribution lacked demo data that could be included as the other pre-packaged Camunda Platform distributions have. Such demo data helps to explore the features of Camunda Platform with actual data that you do not have to provide yourself.
Starting with Camunda Platform 7.16.0-alpha5, you now have the option to include the same demo application in Camunda Run that we have provided in all other distributions. Starting Camunda Run with any of the start scripts launches the demo application as well. You can influence that behavior by specifying which modules to include with Camunda Run by using our command-line parameters, including the new option --example. Furthermore, the example application can be disabled in the application properties YAML. You can find more details in our Camunda Run documentation.
Share your thoughts with us!
Your feedback is vital to us, so please download Camunda Platform Runtime 7.16.0-alpha5, 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.
