Here you will find information about:

• limitations,
• known issues,
• changes in the supported environments,
• any unexpected behvavior 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 Elasticsearch and Camunda BPM platform.

Elasticsearch

Optimize now requires at least Elasticsearch 6.4.0. See the Supported Environments sections for the full range of supported versions.

If you need to upgrade your Elasticsearch cluster, please refer to the general Elasticsearch Upgrade Guide on how to do that. Usually, the only thing you need to do is to perform a rolling upgrade.

Camunda BPM platform

Optimize now requires at least Camunda BPM 7.10.6. See the Supported Environments sections for the full range of supported versions.

Java

Optimize now only supports Java 8,11 & 13. Support for 12 was dropped as it reached end of support. See the Supported Environments sections for the full range of supported versions.

Known issues

Collection permissions get lost on failed Identity Sync

Optimize has an identity synchronization in place that fetches all users from the engine that have access to Optimize. This way, Optimize can easily check if the user is allowed to access the application and is able to quickly display metadata, such as the e-mail address and full name of the user. If you start Optimize 2.7 and the engine is down at the time of a user synchronisation, it is possible that you will lose all your collection permissions. This is due to Optimize not being able to receive the correct authorizations for the collections and as a result, all of the collection roles are removed.

The easiest way to recover your permissions and regain access to your collections would be to add a user id to the auth.superUserIds property of your configuration file, then readding the necessary permissions as this user.

After you have regained the roles of your collections, you should consider one of the two next follow-up steps:

• Preferred solution: upgrade to Optimize 3.2.0. There, the issue has been fixed.
• Interim solution: in case you anticipate the engine being taken down, it’s highly recommended also stopping Optimize to prevent the same scenario reoccurring. In addition, you can also change the frequency upon which this collection cleanup occurs, by adjusting the import.identitySync.cronTrigger expression in your configuration file to 0 0 1 * * *, which would correspond to executing the sync once per day at 1am during the night.

Misinterpreted cron expressions

The configuration of Optimize allows you to define when the history cleanup is triggered. For that, the Cron expression notation is used. However, the values are incorrectly interpreted in Optimize. For example, the historyCleanup.cronTrigger configuration has the default value 0 1 * * *, which should be 1am every day. Unfortunately, a bug causes this to be interpreted as every hour.

To fix this just use the spring cron expression notation. For instance, the default value for historyCleanup.cronTrigger would then be 0 0 1 * * *.