We are pleased to announce the next alpha release of Camunda Automation Runtime 7.19. This release features the following improvements:
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.
Add a Job due date when setting the retries for Jobs
In the process engine, jobs are used to trigger process execution. A job is created when a token reaches a timer event or an activity that is marked for asynchronous execution. Job execution can fail, so the job executor will retry them as long as they have retries left. When a job runs out of retries, the execution of this job is paused until the retries are increased again (by user or API). Also, all jobs have due dates. As soon as a job’s due date is reached, the job is ready to be picked up by the job executor (if the job has retries left). There are multiple ways to configure job due dates. Even when a job runs out of retries, a new due date is calculated based on the configuration. More information on how jobs are executed can be found in the docs.
Let’s consider a case where a job that is configured to run every day just failed and used its last retry. An operations engineer resolves the incident right away and increments the retries. The due date was calculated based on the job configuration and the job is now scheduled to be executed in one day. The operations engineer now needs to set the jobs due date to now to make the job executor pick up the job right away.
Users can now perform these two operations in one go. The Java and REST APIs have been extended to allow an optional due date parameter. All jobs that the API call modifies will receive the new due date, saving one interaction and making the behavior more transparent to the user.
Here is an example on how to use the new parameter in the Java API:
// synchronous call
managementService().setJobRetries(5).jobIds(myIds).dueDate(myDate).execute();
// asynchronous call using a job query
managementService().setJobRetriesByJobsAsync(5).jobQuery(myJobQuery).dueDate(myDate).executeAsync();
// asynchronous call using a list of process instance ids
managementService().setJobRetriesByProcessAsync(5).processInstanceIds(myProcessInstances).dueDate(myDate).executeAsync();All this is available in Cockpit as well. Using either the retry feature on a single job or creating a batch to retry multiple jobs will open a dialog where users can choose to keep the previous due date or set a specific due date.
You can read up on how to use this new feature in Cockpit in the docs.
Fire Historic Task update events when Task is updated
Emitting events might be helpful in scenarios like having a Spring boot starter application and listening to events to take an action. This new feature is about task events, their history and the reported use case is for custom implementation of a task list.
Previously a historic task update event was fired only when saving a task. To close the gap between runtime and history, now the historic task update event is fired on each task update, such as assigning a task, changing the priority, adding a comment, etc.
An example of how to listen for such events is the Spring Eventing Bridge with the focus of the HistoryEvents, the implementation class of historic task events is HistoricTaskInstanceEventEntity.
Support for Quarkus 2.16.4
This alpha features support for the latest version of Quarkus. You can use Quarkus 2.16.4 together with the Camunda Automation Platform Quarkus Extension.
Make sure to check out the Quarkus migration guides between 2.8 and 2.16 for further details on what’s new.
On the road to Jakarta EE 10 support
With Camunda 7.19, we plan to add support for a set of Jakarta EE 10 APIs. This enables you to run Camunda 7 in new environments like the latest WildFly 27 application server. This support will come additionally to all currently supported APIs and environments.
This undertaking brings along a set of new classes and artifacts in the Camunda 7 ecosystem. There will be dedicated Jakarta-based artifacts for CDI and EJB support as well as the REST API and the web applications. The core engine artifact will see new classes that allow Jakarta API-based transaction handling and process application development. Our minor release announcements will feature more details on how to use the new artifacts in action. You can find them in our Maven Central repository.
With Camunda 7.19.0, we also plan to directly add support for WildFly 27 out of the box via our pre-packaged distribution as usual. We are currently working on the last bits of finishing this up, so watch out for the minor release announcements and artifacts to give this a try. With WildFly 27 moving to Jakarta EE 10 without backward compatibility to EE 8 and 9, you can start to fully leverage the latest APIs and capabilities, Camunda 7 process applications included. We are excited to support you on that journey starting with Camunda 7.19. Stay tuned!
Share Your Thoughts with Us!
Your feedback is really important to us, so please download Camunda Automation Platform 7.19.0-alpha4, 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 issue tracker.
