Camunda 7 system configuration
Configuration for engines used to import data.
note
You have to have
at least one engine configured at all times. You can configure multiple engines
to import data from. Each engine configuration should have a unique alias associated
with it and represented by ${engineAlias}.
Note that each connected engine must have its respective history level set to FULL in order to see all available data
in Optimize. Using any other history level will result in less data and/or functionality within Optimize. Furthermore,
history in a connected engine should be configured for long enough for Optimize to import it. If data is removed from an
engine before Optimize has imported it, that data will not be available in Optimize.
| YAML path | Default value | Description |
|---|---|---|
| engines.${engineAlias}.name | default | The process engine's name on the platform, this is the unique engine identifier on the platforms REST API. |
| engines.${engineAlias}.defaultTenant.id | null | A default tenantID to associate all imported data with if there is no tenant configured in the engine itself. This property is only relevant in the context of a One Process Engine Per Tenant tenancy. For details consult the Multi-Tenancy documentation. |
| engines.${engineAlias}.defaultTenant.name | null | The name used for this default tenant when displayed in the UI. |
| engines.${engineAlias}.excludeTenant | [ ] | Comma-separated list of tenant IDs to be excluded when importing data from the specified engine. When left empty, data from all tenants will be imported. Please note that the defaultTenant cannot be excluded (and therefore also not the entities with null as tenant) |
| engines.${engineAlias}.rest | http://localhost:8080/engine-rest | A base URL that will be used for connections to the Camunda Engine REST API. |
| engines.${engineAlias}.importEnabled | true | Determines whether this instance of Optimize should import definition & historical data from this engine. |
| engines.${engineAlias}.eventImportEnabled | false | Determines whether this instance of Optimize should convert historical data to event data usable for event based processes. |
| engines.${engineAlias}.authentication.enabled | false | Toggles basic authentication on or off. When enabling basic authentication, please be aware that you also need to adjust the values of the user and password. |
| engines.${engineAlias}.authentication.user | When basic authentication is enabled, this user is used to authenticate against the engine. Note: when enabled, it is required that the user has
| |
| engines.${engineAlias}.authentication.password | When basic authentication is enabled, this password is used to authenticate against the engine. | |
| engines.${engineAlias}.webapps.endpoint | http://localhost:8080/camunda | Defines the endpoint where the Camunda webapps are found. This allows Optimize to directly link to the other Camunda Web Applications, e.g. to jump from Optimize directly to a dedicated process instance in Cockpit |
| engines.${engineAlias}.webapps.enabled | true | Enables/disables linking to other Camunda Web Applications |
Camunda 7 common import settings
Settings used by Optimize, which are common among all configured engines, such as REST API endpoint locations, timeouts, etc.
| YAML path | Default value | Description |
|---|---|---|
| engine-commons.connection.timeout | 0 | Maximum time in milliseconds without connection to the engine that Optimize should wait until a timeout is triggered. If set to zero, no timeout will be triggered. |
| engine-commons.read.timeout | 0 | Maximum time a request to the engine should last before a timeout triggers. A value of zero means to wait an infinite amount of time. |
| import.data.activity-instance.maxPageSize | 10000 | Determines the page size for historic activity instance fetching. |
| import.data.incident.maxPageSize | 10000 | Determines the page size for historic incident fetching. |
| import.data.process-definition-xml.maxPageSize | 2 | Determines the page size for process definition XML model fetching. Should be a low value, as large models will lead to memory or timeout problems. |
| import.data.process-definition.maxPageSize | 10000 | Determines the page size for process definition entities fetching. |
| import.data.process-instance.maxPageSize | 10000 | Determines the page size for historic decision instance fetching. |
| import.data.variable.maxPageSize | 10000 | Determines the page size for historic variable instance fetching. |
| import.data.variable.includeObjectVariableValue | true | Controls whether Optimize fetches the serialized value of object variables from the Camunda Runtime REST API. By default, this is active for backwards compatibility. If no variable plugin to handle object variables is installed, it can be turned off to reduce the overhead of the variable import. Note: Disabling the object variable value transmission is only effective with Camunda 7.15.0+. |
| import.data.user-task-instance.maxPageSize | 10000 | Determines the page size for historic User Task instance fetching. |
| import.data.identity-link-log.maxPageSize | 10000 | Determines the page size for historic identity link log fetching. |
| import.data.decision-definition-xml.maxPageSize | 2 | Determines the page size for decision definition xml model fetching. Should be a low value, as large models will lead to memory or timeout problems. |
| import.data.decision-definition.maxPageSize | 10000 | Determines the page size for decision definition entities fetching. |
| import.data.decision-instance.maxPageSize | 10000 | Overwrites the maximum page size for historic decision instance fetching. |
| import.data.tenant.maxPageSize | 10000 | Overwrites the maximum page size for tenant fetching. |
| import.data.group.maxPageSize | 10000 | Overwrites the maximum page size for groups fetching. |
| import.data.authorization.maxPageSize | 10000 | Overwrites the maximum page size for authorizations fetching. |
| import.data.dmn.enabled | true | Determines if the DMN/decision data, such as decision definitions and instances, should be imported. |
| import.data.user-task-worker.enabled | true | Determines if the User Task worker data, such as assignee or candidate group of a User Task, should be imported. |
| import.data.user-task-worker.metadata.includeUserMetaData | true | Determines whether Optimize imports and displays assignee user metadata, otherwise only the user id is shown. |
| import.data.user-task-worker.metadata.cronTrigger | 0 */3 * * * | Cron expression for when to fully refresh the internal metadata cache, it defaults to every third hour. Otherwise deleted assignees/candidateGroups or metadata changes are not reflected in Optimize. You can either use the default Cron (5 fields) or the Spring Cron (6 fields) expression format here. For details on the format please refer to: Cron Expression Description Spring Cron Expression Documentation |
| import.data.user-task-worker.metadata.maxPageSize | 10000 | The max page size when multiple users or groups are iterated during the metadata refresh. |
| import.data.user-task-worker.metadata.maxEntryLimit | 100000 | The entry limit of the cache that holds the metadata, if you need more entries you can increase that limit. When increasing the limit, keep in mind to account for that by increasing the JVM heap memory as well. Please refer to the "Adjust Optimize heap size" documentation. |
| import.skipDataAfterNestedDocLimitReached | false | Some data can no longer be imported to a given document if its number of nested documents has reached the configured limit. Enable this setting to skip this data during import if the nested document limit has been reached. |
| import.elasticsearchJobExecutorThreadCount | 1 | Number of threads being used to process the import jobs per data type that are writing data to elasticsearch. |
| import.elasticsearchJobExecutorQueueSize | 5 | Adjust the queue size of the import jobs per data type that store data to elasticsearch. If the value is too large it might cause memory problems. |
| import.handler.backoff.interval | 5000 | Interval in milliseconds which is used for the backoff time calculation. |
| import.handler.backoff.max | 15 | Once all pages are consumed, the import scheduler component will start scheduling fetching tasks in increasing periods of time, controlled by "backoff" counter. |
| import.handler.backoff.isEnabled | true | Tells if the backoff is enabled of not. |
| import.indexType | import-index | The name of the import index type. |
| import.importIndexStorageIntervalInSec | 10 | States how often the import index should be stored to Elasticsearch. |
| import.currentTimeBackoffMilliseconds | 300000 | This is the time interval the import backs off from the current tip of the time during the ongoing import cycle. This ensures that potentially missed concurrent writes in the engine are reread going back by the amount of this time interval. |
| import.identitySync.includeUserMetaData | true | Whether to include metaData (firstName, lastName, email) when synchronizing users. If disabled only user IDs will be shown on user search and in collection permissions. |
| import.identitySync.collectionRoleCleanupEnabled | false | Whether collection role cleanup should be performed. If enabled, users that no longer exist in the identity provider will be automatically removed from collection permissions. |
| import.identitySync.cronTrigger | 0 */2 * * * | Cron expression for when the identity sync should run, defaults to every second hour. You can either use the default Cron (5 fields) or the Spring Cron (6 fields) expression format here. For details on the format please refer to: |
| import.identitySync.maxPageSize | 10000 | The max page size when multiple users or groups are iterated during the import. |
| import.identitySync.maxEntryLimit | 100000 | The entry limit of the user/group search cache. When increasing the limit, keep in mind to account for this by increasing the JVM heap memory as well. Please refer to the "Adjust Optimize heap size" documentation on how to configure the heap size. |