Process Engine Configuration

The auto starter uses the org.camunda.bpm.engine.impl.cfg.ProcessEnginePlugin mechanism to configure the engine.

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.CamundaDeploymentConfiguration
• 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

Default Configurations

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

DefaultProcessEngineConfiguration

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 configure more than one datasource and don’t want to use the @Primary one for the process engine, then name the one you want to use as camundaBpmDataSource.

@Bean
@Primary
@ConfigurationProperties(prefix="datasource.primary")
public DataSource primaryDataSource() {
  return DataSourceBuilder.create().build();
}

@Bean(name="camundaBpmDataSource")
@ConfigurationProperties(prefix="datasource.secondary")
public DataSource secondaryDataSource() {
  return DataSourceBuilder.create().build();
}

DefaultHistoryConfiguration

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

@Bean
public HistoryEventHandler customHistoryEventHandler() {
  return new CustomHistoryEventHanlder();
}

DefaultHistoryLevelAutoHandlingConfiguration

As camunda version >= 7.4 supports history-level auto, this configuration adds support for versions <= 7.3.

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.

DefaultJobConfiguration

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).

DefaultJpaConfiguration

If JPA is enabled and a entityManagerFactory bean is configured, the process engine is enabled to use JPA (see properties).

DefaultAuthorizationConfiguration

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

Overriding the Default Configuration

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

@Configuration
public class MyCamundaConfiguration {

	@Bean
	public static CamundaDatasourceConfiguration camundaDatasourceConfiguration() {
		return new MyCamundaDatasourceConfiguration();
	}

}

Adding Additional Configurations

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 (@Order 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 @Order(Ordering.DEFAULT_ORDER + 1) annotation to your class.

@Configuration
public class MyCamundaConfiguration {

	@Bean
	@Order(Ordering.DEFAULT_ORDER + 1)
	public static ProcessEnginePlugin myCustomConfiguration() {
		return new MyCustomConfiguration();
	}

}

Or, if you have component scan enabled:

@Component
@Order(Ordering.DEFAULT_ORDER + 1)
public class MyCustomConfiguration implements ProcessEnginePlugin {

	@Override
	public void preInit(ProcessEngineConfigurationImpl processEngineConfiguration) {
		//...
	}

	...

}

or

@Component
@Order(Ordering.DEFAULT_ORDER + 1)
public class MyCustomConfiguration extends AbstractCamundaConfiguration {

	@Override
	public void preInit(SpringProcessEngineConfiguration springProcessEngineConfiguration) {
		//...
	}

	...

}

Camunda Engine Properties

Prefix	Property name	Description	Default value
General
camunda.bpm	.enabled	Switch to disable the Camunda auto-configuration. Use to exclude Camunda in integration tests.	true
	.process-engine-name	Name of the process engine	Camunda default value
	.default-serialization-format	Default serialization format	Camunda default value
	.history-level	Camunda history level	FULL
	.history-level-default	Camunda history level to use when history-level is auto, but the level can not determined automatically	FULL
	.auto-deployment-enabled	If processes should be auto deployed. This is disabled when using the SpringBootProcessApplication	true
	.license-file	Provides an URL to your Camunda license file and is automatically inserted into the DB when the application starts (but only if no license key is found in the DB).	By default, the license key will be loaded: from the file with the name camunda-license.txt from classpath (if present) 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 deployment takes 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
camunda.bpm.database	.schema-update	If automatic schema update should be applied, use one of [true, false, create, create-drop, drop-create]	true
	.type	Type 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 camunda's bundled index.html. If this property is set to false, the default Spring Boot behaviour is taken into account.	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 displays all tasks. Useful for testing on h2 db.	-