Update notes (3.0 to 3.1)
To update Optimize to version 3.1.0, perform the following steps first: Migration & Update Instructions.
Here you will find information about:
- Limitations
- Known issues
- Changes in the supported environments
- Any unexpected behavior of Optimize (e.g due to a new feature)
Changes in the supported environments​
With this Optimize version, there are also changes in the supported versions of Camunda 7.
Camunda 7​
Optimize now requires at least Camunda 7 7.11.13.
See the Supported Environments sections for the full range of supported versions.
Breaking changes​
With Optimize 3.1.0, the History Cleanup configuration was restructured and needs to be adjusted accordingly.
Major changes are the removal of the global feature flag historyCleanup.enabled in favor of entity type specific feature flags as well as a relocation of process and decision specific configuration keys. Refer to the configuration documentation for details.
With this release, Optimize now imports deployment data from the engine when importing definitions. If Optimize is importing from an authenticated engine, the configured user must now have READ permission on the Deployment resource.
Known issues​
Event-based processes - event counts/suggestions​
As part of the update from Optimize 3.0 to 3.1, the event counts and the next suggested events used as part of the event based process feature are recalculated. Until the recalculation is complete, the event counts might be incorrect and the suggestions inaccurate.
Once the recalculation is complete, the event counts will return to being correct and you will see more accurate suggested next events.
Decision report filter incompatibilities - update and runtime errors possible​
Due to a restriction in the database schema for decision reports, the usage of filters is limited in Optimize 3.1.0 as well as 3.2.0 and will only be fully working again in Optimize 3.3.0. This results in the behavior that once a certain filter type was used, e.g. a fixed evaluation date filter, another filter type cannot be used anymore, e.g. a relative evaluation date filter. This issue can occur at runtime as well as during the update.
Usually, you will see a log similar to this one when you hit this issue:
{"error":{"root_cause":[{"type":"mapper_parsing_exception","reason":"object mapping for [data.filter.data.start] tried to parse field [start] as object, but found a concrete value"}],"type":"mapper_parsing_exception","reason":"object mapping for [data.filter.data.start] tried to parse field [start] as object, but found a concrete value"},"status":400}
We thus recommend removing all filters used on decision reports before updating to Optimize 3.1.0.
Limitations​
User permissions​
With Optimize 3.1, user and group related permissions are checked by Optimize to determine whether the current user is authorized to access other users/groups within Optimize, for example when adding new roles to a collection.
Due to this, it is now required to explicitly grant users the relevant authorizations, otherwise they will not be able to see other users and groups in Optimize. More information on authorizations can be found here.
User operations log import​
With Optimize 3.1, the user operations log is imported to detect changes to running instances' suspension status. The user operations log informs Optimize when instance suspension requests have been received by the engine, and Optimize then reimports the relevant instances to ensure their suspension state is set correctly in Optimize.
However, if instances are suspended using the engine API's executionDate parameter, with which suspension operations can be triggered with a delay, Optimize currently is not able to detect this delay, and will re-import the running process instances at the time the suspension operation is read from the user operations log, not at the time the suspension takes place. This can lead to inaccuracies in the suspension state of process instances in Optimize.