Implemented a global locking mechanism to have better support for using the async executor in a setup with multiple Flowable Engines. Together with this the async executor default configuration was changed to be able to handle more jobs per second by default. A 4-part article series describe all the fine details and a performance benchmark of this, Part 1, Part 2, Part 3, Part 4.
Added support for multi instance variable aggregation, https://www.flowable.com/blog/multi-instance-variable-aggregation/.
Added support for case reactivation to support reactivating historic and completed case instances to a running case instance. Case definitions can have a case reactivation listener. that can be triggered to reactivate a historic case instance and the variable context etc will be re-created.
A variable listener has been added to allow for BPMN and CMMN models to listen to changes for a specific variable and handle this trigger in the model.
Add support for repetition signal and generic event listener in the CMMN engine to be triggered in parallel.
Added an optimization flag for asynchronous multi-instance usage when the multi-instance is an automatic step or a sequence of automatic steps. If set, the engine will drastically lower resource consumption, and remove the optimistic locking exceptions and typically be more performant.
Added support of synchronous handling of event registry events.
Added support for DMN 1.3 version models.
Added support for method overloading in JUEL / backend expressions.
Added localization support for case definitions and runtime and history case instances and plan item instances.
Added basic CMMN model validation to the CMMN engine.
Added basic CDI support to the CMMN engine.
Exceptions thrown from Task listeners are no longer wrapped in FlowableException.
Exceptions thrown from Task, case lifecycle and plan item lifecycle listeners are no longer wrapped in FlowableException.
Improved paging of runtime and historic process and case instance queries including variables. In earlier versions queries with include variables did paging in memory with a lot of limitations.
In this release an upgrade to Spring Boot 2.5.4 and Spring 5.3.9 was done.
There has been a change in the way a process / case instance is started from an event from the event registry. Instead of starting the process / case asynchronously, it is started synchronously. Using this default value allows correct processing of in-order event coming on the same topic. In case in order processing is not important you can configure that as part of your model by marking the Event Registry Start event as async or marking the Case Model as async. If you want to go back to the previous default you can set the following properties: