The configuration is divided into sections. These sections are represented by the marker interfaces:

  • org.camunda.bpm.spring.boot.starter.configuration.CamundaProcessEngineConfiguration
  • org.camunda.bpm.spring.boot.starter.configuration.CamundaDatasourceConfiguration
  • org.camunda.bpm.spring.boot.starter.configuration.CamundaHistoryConfiguration
  • org.camunda.bpm.spring.boot.starter.configuration.CamundaHistoryLevelAutoHandlingConfiguration
  • org.camunda.bpm.spring.boot.starter.configuration.CamundaJobConfiguration
  • org.camunda.bpm.spring.boot.starter.configuration.CamundaJpaConfiguration
  • org.camunda.bpm.spring.boot.starter.configuration.CamundaAuthorizationConfiguration
  • org.camunda.bpm.spring.boot.starter.configuration.CamundaFailedJobConfiguration
  • org.camunda.bpm.spring.boot.starter.configuration.CamundaMetricsConfiguration

The following default and best practice configurations are provided by the starter and can be customized or overridden.

Sets the process engine name and automatically adds all ProcessEnginePlugin beans to the configuration.

DefaultDatasourceConfiguration

Applies the datasource and transaction management configurations to the process engine.If you want to and don’t want to use the@Primary one for the process engine, then name the one you want to use as camundaBpmDataSource.

Applies the history configuration to the process engine. If not configured, the history level is used.If you want to use a custom HistoryEventHandler, you just have to provide a bean implementing the interface.

  1. @Bean
  2. public HistoryEventHandler customHistoryEventHandler() {
  3.   return new CustomHistoryEventHanlder();
  4. }

DefaultHistoryLevelAutoHandlingConfiguration

To have more control over the handling, you can provide your own

  • org.camunda.bpm.spring.boot.starter.jdbc.HistoryLevelDeterminator with name historyLevelDeterminator
    IMPORTANT: The default configuration is applied after all other default configurations using the ordering mechanism.

Applies the job execution properties to the process engine.

To have more control over the execution itself, you can provide your own

  • org.camunda.bpm.engine.impl.jobexecutor.JobExecutor
  • org.springframework.core.task.TaskExecutor named camundaTaskExecutor
    beans.

IMPORTANT: The job executor is not enabled in the configuration.This is done after the spring context successfully loaded (see org.camunda.bpm.spring.boot.starter.runlistener).

DefaultDeploymentConfiguration

If auto deployment is enabled (this is the case by default), all processes found in the classpath are deployed.The resource pattern can be changed using properties (see properties).

DefaultAuthorizationConfiguration

Applies the authorization configuration to the process engine. If not configured, the camunda default values are used (see properties).

Provide a bean implementing one of the marker interfaces. For example to customize the datasource configuration:

You just have to provide one or more beans implementing the org.camunda.bpm.engine.impl.cfg.ProcessEnginePlugin interface(or extend from org.camunda.bpm.spring.boot.starter.configuration.impl.AbstractCamundaConfiguration).The configurations are applied ordered using the spring ordering mechanism ( annotation and Ordered interface).So if you want your configuration to be applied before the default configurations, add a @Order(Ordering.DEFAULT_ORDER - 1) annotation to your class.If you want your configuration to be applied after the default configurations, add a (Ordering.DEFAULT_ORDER + 1) annotation to your class.

  1. @Configuration
  2. public class MyCamundaConfiguration {
  4.     @Bean
  5.     @Order(Ordering.DEFAULT_ORDER + 1)
  6.         return new MyCustomConfiguration();
  7.     }
  9. }

Or, if you have component scan enabled:

or

  1. @Component
  2. @Order(Ordering.DEFAULT_ORDER + 1)
  3. public class MyCustomConfiguration extends AbstractCamundaConfiguration {
  5.     @Override
  6.     public void preInit(SpringProcessEngineConfiguration springProcessEngineConfiguration) {
  7.         //...
  8.     }
  10.     ...
  12. }
  • from path ${user.home}/.camunda/license.txt (if present)
    |.id-generator|Configure idGenerator. Allowed values: simple, strong, prefixed. prefixed id generator is like strong, but uses a Spring application name (${spring.application.name}) as the prefix for each id.|strong
    |.version|Version of the process engine|Read only value, e.g., 7.4.0
    |.formatted-version|Formatted version of the process engine|Read only value, e.g., (v7.4.0)
    |.deployment-resource-pattern|Location for auto deployment|classpath:**/.bpmn, classpath:**/.bpmn20.xml, classpath:**/.dmn, classpath:**/.dmn11.xml, classpath:**/.cmmn, classpath:**/.cmmn10.xml, classpath:**/.cmmn11.xml
    |Process application
    |camunda.bpm.application|.delete-upon-undeploy|Indicates whether the undeployment of the process archive should trigger deleting the process engine deployment. If the process engine deployment is deleted,all running and historic process instances are removed as well.|false
    |.scan-for-process-definitions|Indicates whether the classloader should be scanned for process definitions.|true
    |.deploy-changed-only|Indicates whether only changed resources should be part of the deployment. This is independent of the setting that if no resources change, no deploymenttakes place but the previous deployment is resumed.|false
    |.resume-previous-versions|Indicates whether old versions of the deployment should be resumed.|false
    |.resume-previous-by|Indicates which previous deployments should be resumed by this deployment.|process-definition-key
    |Job Execution
    |camunda.bpm.job-execution|.enabled|If set to false, no JobExecutor bean is created at all. Maybe used for testing.|true
    |.deployment-aware|If job executor is deployment aware|false
    |.core-pool-size|Set to value > 1 to activate parallel job execution.|3
    |.max-pool-size|Maximum number of parallel threads executing jobs|10
    |Datasource
    ||.schema-update|If automatic schema update should be applied, use one of [true, false, create, create-drop, drop-create]|true
    |.type|Yype of the underlying database. Possible values: h2, mysql, mariadb, oracle, postgres, mssql, db2.|Will be automatically determined from datasource
    |.table-prefix|Prefix of the camunda database tables. Attention: The table prefix will not be applied if you are using schema-update!|Camunda default value
    |.schema-name|The dataBase schema name|Camunda default value
    |JPA
    |camunda.bpm.jpa|.enabled|Enables jpa configuration|true. Depends on entityManagerFactory bean.
    |.persistence-unit-name|JPA persistence unit name|-
    |.close-entity-manager|Close JPA entity manager|true
    |.handle-transaction|JPA handle transaction|true
    |Management
    |camunda.bpm.management|.health.camunda.enabled|Enables default camunda health indicators|true
    |Metrics
    |camunda.bpm.metrics|.enabled|Enables metrics reporting|Camunda default value
    |.db-reporter-activate|Enables db metrics reporting|Camunda default value
    |Webapp
    |camunda.bpm.webapp|.index-redirect-enabled|Registers a redirect from / to camundas bundled index.html|true
    |Authorization
    |camunda.bpm.authorization|.enabled|Enables authorization|Camunda default value
    |.enabled-for-custom-code|Enables authorization for custom code|Camunda default value
    |.authorization-check-revokes|Configures authorization check revokes|Camunda default value
    |.tenant-check-enabled|Performs tenant checks to ensure that an authenticated user can only access data that belongs to one of his tenants.|true
    |Admin User
    |camunda.bpm.admin-user|.id|The username (e.g., 'admin')|-
    |.password|The initial password|=id
    |.firstName, .lastName, .email|Additional (optional) user attributes|Defaults to value of 'id'
    |Filter
    |camunda.bpm.filter|.create|Name of a "show all" filter. If set, a new filter is created on start that displayes all tasks. Useful for testing on h2 db.|-