How about a new release of Camunda BPM 7.8 to spice things up?
Among the long list of new features in Camunda BPM 7.8-alpha4, the highlights are:
- Deletion of Process Definitions in Cockpit (EE)
- History Cleanup in Cockpit (EE)
- Batch Process Instance Restart (EE)
- Interval Configuration for Failed Jobs
- 11 Bug Fixes
If you want to dig in deeper, you can find the source code on GitHub.
Deletion of Process Definitions in Cockpit (EE)
Until now, it has only been possible to erase process definitions in Cockpit by deleting a whole deployment. This behavior is not sensible for any case as, generally speaking, a deployment consists of several process definitions and resources – including those that are possibly still required and not supposed to be deleted.
This release brings a new feature to Cockpit that allows to delete process definitions, regardless of their respective
Apart from deleting individual versions, it is even possible to delete all versions of a process definition.
Please bear in mind that this feature is only available in the Enterprise Edition of Camunda BPM.
To try it out anyway, please request a Free Trial or a Quote.
History Cleanup in Cockpit (EE)
History cleanup is a functionality that makes the engine delete outdated data that mainly consists of finished process/decision/case instances and all their related data.
This version of Cockpit introduces a brand new page for this functionality. This page contains two main sections to manage the history cleanup functionality and to get useful reports that help configuring it more efficiently.
History Cleanup Management Section
The first section contains all the necessary information about the state of the history cleanup.
In fact, the cleanup can be in 4 different possible states:
- There is currently no cleanup running.
- There is a cleanup scheduled in x amount of time.
- The last running cleanup had incidents.
- There is neither a running nor a scheduled cleanup.
Moreover, this section of the cleanup page allows to perform operations on the history cleanup:
- Trigger a cleanup (only when there is no cleanup already running and when the last running history cleanup had no incidents).
- Retry the last run cleanup job (only if it had incidents).
Cleanable Instances Report
The second section of the cleanup page contains reports that help configuring the history cleanup functionality more efficiently.
This section displays information about the finished and cleanable process/decision/case instances and their respective history time to live configurations. Having this information in one view offers insights on whether any configuration changes need to be done.
Furthermore, it is possible to update the history time to live configuration for a certain process/decision/case definition directly from the table.
Notice: this feature is only available in the Enterprise Edition of Camunda BPM.
However, you can still try it out by requesting a Free Trial or a Quote.
Batch Process Instance Restart in Cockpit (EE)
Last month’s release introduced the batch process instance modification feature in Camunda Cockpit. Modification can be executed on process instances which are still running. But what about process instances which have already ended? Sometimes it is necessary to recreate or restart a process instance which has already ended. To achieve this, this release makes the Process Instance Restart API available in Camunda Cockpit.
The Process Instance Restart API allows to recreate one or multiple process instances from history. To specify which instances should be restarted, the list of finished process instances can be filtered by start- or end-date, variable values, business key and more. The following animation shows how to restart all process instances with certain variable values:
This operation is executed asynchronously using Camunda’s batch infrastructure. This ensures that the operation can also be executed on large sets of process instances.
Interval Configuration for the Failed Jobs
In its default behavior, the Camunda BPM engine takes care of retrying failed jobs automatically. After the initial failure, the job is only retried twice. However, the number of retries can be configured locally within the BPMN 2.0 XML for several BPMN notation elements (e.g., tasks).
The previous release introduced the possibility to configure the number of retrials globally with the property
failedJobRetryTimeCycle. However, this property could only accept a static number.
This release introduces a new notation to configure the
failedJobRetryTimeCycle property, allowing greater flexibility in the configuration of the number of retries of a failed job and the time of each retry:
... <process-engine name="default"> ... <properties> ... <property name="failedJobRetryTimeCycle">PT5M,PT20M,PT30M</property> </properties> </process-engine> ...
In this example, the engine is configured to retry failed jobs 3 times with a delay of 5 minutes before the first retry, 20 minutes before the second one, and 30 minutes before the last one.
For more details about this feature, please check out the
The next alpha version is scheduled for the end of October and our team is already working on it.
If you are curious about what the team is cooking for the next releases, here are few highlights:
- Support for Microsoft Edge
- Cockpit – Persistent Columns in Search
You can also find out more details if you check out our roadmap.
The minor release of Camunda BPM 7.8 is coming this fall (November 30, 2017).
Your Feedback Matters!
Your feedback is extremely important for us in order to improve Camunda BPM, so your thoughts are always highly appreciated and considered by our team.
Feel free to share your ideas and suggestions with us by writing a post in the forum.
Furthermore, if you have any feedback related to User Experience, things that keep bugging you, things that you think should work differently etc., please share your thoughts with us at https://camundabpm.userecho.com