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 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 update your Elasticsearch cluster, please refer to the general Elasticsearch Update Guide on how to do that. Usually, the only thing you need to do is perform a rolling update.

Camunda Platform

Optimize now requires at least Camunda Platform 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. By doing this, 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: update 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 to also stop Optimize to prevent the same scenario reoccurring. In addition, you can also change the frequency at which this collection cleanup occurs by adjusting the import.identitySync.cronTrigger expression in your configuration file to 0 0 1 * * * which results in executing the sync once per day at 01:00 AM.

Misinterpreted cron expressions

The configuration of Optimize allows you to define when the history cleanup is triggered using Cron expression notation. However, the values are incorrectly interpreted in Optimize. For example, the historyCleanup.cronTrigger configuration has the default value 0 1 * * *, which should be 01:00 AM 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 * * *.