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 BPM platform.

Camunda BPM platform

Optimize now requires at least Camunda BPM 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. Please 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 upgrade 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 - Upgrade 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 upgrade.

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 highly recommend to remove all filters used on Decision Reports before upgrading 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.