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)

Limitations

Migration Warning regarding incomplete UserTasks

The migration from Optimize 3.4 to 3.5 includes some improvements to the Optimize Process Instance data structure. Previously, Process Instance data in Optimize held two distinct lists: one for all FlowNode data and one for UserTask data. To avoid redundancy, these lists are merged into one during this migration. In order to correctly merge the UserTask data contained in the two lists, specific ID fields are used to correlate UserTasks correctly. However, due to the nature of the Optimize import, UserTask data can temporarily exist within Optimize without some of these fields. Normally, these fields are updated by the next scheduled UserTask import, but if Optimize was shut down before this next UserTask import can run, the fields remain null and cannot be used during migration.

Usually, this should only affect a small percentage of UserTasks and of this small percentage, the data that is lost during migration will only relate to the cancellation state or assignee/candidate group information. In practical terms, if you observe a warning regarding “x incomplete UserTasks that will be skipped during migration” in your update logs, this means that after the migration, x UserTasks in your system may be lacking assignee or candidate group information or may be marked as completed when in fact they were canceled.
Please note that any other UserTask data, old and new, will be complete.

If this inaccuracy in past data is not acceptable to you, you can remedy this data loss by performing a reimport after migration. You can either run a complete reimport using the reimport script, or alternatively use the below statements to only reset those imports responsible for the data that was skipped during migration.
Please ensure that Optimize is shut down before executing these import resets.

Reset the identityLinkLog import to reimport assignee and candidate group data:

curl --location --request DELETE 'http://<esHost>:<esPort>/<indexPrefix>-timestamp-based-import-index_v4/_doc/identityLinkLogImportIndex-<engineAlias>'

Reset the completedActivity import to reimport the correct cancellation state data:

curl --location --request DELETE 'http://<esHost>:<esPort>/<indexPrefix>-timestamp-based-import-index_v4/_doc/activityImportIndex-<engineAlias>'

For example, assuming Elasticsearch is at localhost:9200, the engine alias is camunda-bpm, and the index prefix is optimize, the request to reset the identityLinkLog import translates to:

curl --location --request DELETE 'http://localhost:9200/optimize-timestamp-based-import-index_v4/_doc/identityLinkLogImportIndex-camunda-bpm'

If you have more than one engine configured, both requests need to be executed once per engine alias.

Known Issues

Report Edit Mode fails for reports with Flow Node Filters

After updating to Optimize 3.5.0 you may encounter an issue that you cannot enter the edit mode on reports that use Flow Node Selection Filters.

In such a case, when entering edit mode, you are confronted with the following error in the Web UI:

  Cannot read property 'key' of undefined

This error can be resolved by running the following elasticearch update query on your Optimize report index:

curl --location --request POST 'http://{esHost}:{esPort}/{indexPrefix}-single-process-report/_update_by_query' \
--header 'Content-Type: application/json' \
--data-raw '{
  "script" : {
    "source": "if(ctx._source.data.filter.stream().anyMatch(filter -> \"executedFlowNodes\".equals(filter.type)) && ctx._source.data.definitions.length == 1){for (filter in ctx._source.data.filter){filter.appliedTo = [ctx._source.data.definitions[0].identifier];}}",
    "lang": "painless"
  }
}'

Applying this update query can be done anytime after the update to Optimize 3.5.0 was performed, even while Optimize 3.5.0 is already running.

Running 3.5 update on Optimize version 3.5 data results in NullPointerException

The Optimize 3.5 update will not succeed if it is run on data which has already been updated to 3.5. This is because the 3.5 update relies on the 3.4 schema to be present in order to perform certain operations, which will fail with a NullPointerException if attempted on the 3.5 schema. This will cause the update to abort. In this case however no further action is required as your data has already been updated to 3.5.

Unexpected Behavior

Flow Node selection in Report configuration moved to Flow Node Filter

The Flow Node selection previously found in the Report configuration menu has now been migrated to the Flow Node Filter dropdown as a “Flow Node Selection” Filter. Existing Flow Node selection configurations in old Reports will be migrated to an equivalent Filter with the Optimize 3.5.0 migration. Note that this Filter now also filters out instances which do not contain any Flow Nodes that match the Filter.

Changes in requirements

Java

With this release, support for Java 8 has been removed, meaning that Java 11 is now the only LTS version of Java that Optimize supports. Please see the Supported Environments sections for more information on supported versions.

Elasticsearch

With this release, Optimize no longer supports Elasticsearch versions 7.5.1, 7.6.0 or 7.7.0. See the Supported Environments sections for the full range of supported versions.