Process Engine Configuration | docs.camunda.org

link管理
链接快照平台
输入网页链接，自动生成快照
标签化管理网页链接
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`

Configures the Camunda data source and enables transaction integration . By default, the primary DataSource and PlatformTransactionManager beans are wired with the process engine configuration.
If you want to configure more than one datasource and don’t want to use the @Primary one for the process engine, then you can create a separate data source with name camundaBpmDataSource that will be automatically wired with Camunda instead.
@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();
If you don’t want to use the @Primary transaction manager, it is possible to create a separate
transaction manager with the name camundaBpmTransactionManager that will be wired with the data
source used for Camunda (either @Primary or camundaBpmDataSource):
@Bean
@Primary
public PlatformTransactionManager primaryTransactionManager() {
  return new JpaTransactionManager();
@Bean(name="camundaBpmTransactionManager")
public PlatformTransactionManager camundaTransactionManager(@Qualifier("camundaBpmDataSource") DataSource dataSource) {
  return new DataSourceTransactionManager(dataSource);
  The wired data source and transaction manager beans must match, i.e. make sure that the transaction manager actually manages the Camunda data source. If that is not the case, the process engine will use auto-commit mode for the data source connection, potentially leading to inconsistencies in the database.
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).
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) {
		//...
@Component
@Order(Ordering.DEFAULT_ORDER + 1)
public class MyCustomConfiguration extends AbstractCamundaConfiguration {
	@Override
	public void preInit(SpringProcessEngineConfiguration springProcessEngineConfiguration) {
		//...
Camunda Engine Properties
In addition to the bean-based way of overriding process engine configuration properties, it is also possible
to set those properties via an application.yaml configuration file. Instructions on how to use it
can be found in the Spring Boot Starter Guide.
The available properties are as follows:
Prefix
 Property name
 Description
  Default value
General
camunda.bpm
.enabled
Switch to disable the Camunda auto-configuration. Use to exclude Camunda in integration tests.
.process-engine-name
Name of the process engine
Camunda default value
.generate-unique-process-engine-name
Generate a unique name for the process engine (format: 'processEngine' + 10 random alphanumeric characters)
false
.generate-unique-process-application-name
Generate a unique Process Application name for every Process Application deployment (format: 'processApplication' + 10 random alphanumeric characters)
false
.default-serialization-format
Default serialization format
Camunda default value
.history-level
Camunda history level
.history-level-default
Camunda history level to use when history-level is auto, but the level can not determined automatically
.auto-deployment-enabled
If processes should be auto deployed. This is disabled when using the SpringBootProcessApplication
.default-number-of-retries
Specifies how many times a job will be executed before an incident is raised
.job-executor-acquire-by-priority
If set to true, the job executor will acquire the jobs with the highest priorities
false
.license-file
Provides a URL to your Camunda license file and is automatically inserted into the DB when the application starts (but only if no valid license key is found in the DB).
Note: This property is only available when using the camunda-bpm-spring-boot-starter-webapp-ee
By default, the license key will be loaded:
  from the URL provided via the this property (if present)
  from the file with the name camunda-license.txt from the classpath (if present)
  from path ${user.home}/.camunda/license.txt (if present)
 The license must be exactly in the format as we sent it to you including the header and footer line. Bear in mind
 that for some licenses there is a minimum version requirement.
.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
Job Execution
camunda.bpm.job-execution
.enabled
If set to false, no JobExecutor bean is created at all. Maybe used for testing.
.deployment-aware
If job executor is deployment aware
false
.core-pool-size
Set to value > 1 to activate parallel job execution.
.keep-alive-seconds
Specifies the time, in milliseconds, for which threads are kept alive when there are no more tasks present. When the time expires, threads are terminated so that the core pool size is reached.
.lock-time-in-millis
Specifies the time in milliseconds an acquired job is locked for execution. During that time, no other job executor can acquire the job.
300000
.max-jobs-per-acquisition
Sets the maximal number of jobs to be acquired at once.
.max-pool-size
Maximum number of parallel threads executing jobs.
.queue-capacity
Sets the size of the queue which is used for holding tasks to be executed.
.wait-time-in-millis
Specifies the wait time of the job acquisition thread in milliseconds in case there are less jobs available for execution than requested during acquisition. If this is repeatedly the case, the wait time is increased exponentially by the factor waitIncreaseFactor. The wait time is capped by maxWait.
.max-wait
Specifies the maximum wait time of the job acquisition thread in milliseconds in case there are less jobs available for execution than requested during acquisition.
60000
.backoff-time-in-millis
Specifies the wait time of the job acquisition thread in milliseconds in case jobs were acquired but could not be locked. This condition indicates that there are other job acquisition threads acquiring jobs in parallel. If this is repeatedly the case, the backoff time is increased exponentially by the factor waitIncreaseFactor. The time is capped by maxBackoff. With every increase in backoff time, the number of jobs acquired increases by waitIncreaseFactor as well.
.max-backoff
Specifies the maximum wait time of the job acquisition thread in milliseconds in case jobs were acquired but could not be locked.
.backoff-decrease-threshold
Specifies the number of successful job acquisition cycles without a job locking failure before the backoff time is decreased again. In that case, the backoff time is reduced by waitIncreaseFactor.
.wait-increase-factor
Specifies the factor by which wait and backoff time are increased in case their activation conditions are repeatedly met.
Datasource
camunda.bpm.database
.schema-update
If automatic schema update should be applied, use one of [true, false, create, create-drop, drop-create]
.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
.jdbc-batch-processing
Controls if the engine executes the jdbc statements as Batch or not.
It has to be disabled for some databases.
See the user guide for further details.
Camunda default value: true
Eventing
camunda.bpm.eventing
.execution
Enables eventing of delegate execution events.
See the user guide for further details.
.history
Enables eventing of history events.
See the user guide for further details.
.task
Enables eventing of task events.
See the user guide for further details.
.skippable
Controls if listeners are registered as built-in (false) or are skippable (true).
See the user guide for further details.
Management
camunda.bpm.management
.health.camunda.enabled
Enables default camunda health indicators
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
.enabled
Switch to disable the Camunda Webapp auto-configuration.
.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.
.application-path
Changes the application path of the webapp.
When setting to /, the legacy behavior of Camunda Spring Boot Starter <= 3.4.x is restored.
/camunda
  camunda.bpm.webapp.csrf
.target-origin
Sets the application expected deployment domain. See the user guide for details.
Not set
.deny-status
Sets the HTTP response status code used for a denied request. See the user guide for details.
.random-class
Sets the name of the class used to generate tokens. See the user guide for details.
java.security.SecureRandom
.entry-points
Sets additional URLs that will not be tested for the presence of a valid token. See the user guide for details.
Not set
  .enable-secure-cookie
    If set to true, the cookie flag Secure is enabled.
  false
  .enable-same-site-cookie
    If set to false, the cookie flag SameSite is disabled. The default value of the SameSite cookie is LAX and it can be changed via same-site-cookie-option configuration property.
  .same-site-cookie-option
    Can be configured either to STRICT or LAX.


    Note:
      Is ignored when enable-same-site-cookie is set to false
      Cannot be set in conjunction with same-site-cookie-value
  Not set
  .same-site-cookie-value
    A custom value for the cookie property.


    Note:
      Is ignored when enable-same-site-cookie is set to false
      Cannot be set in conjunction with same-site-cookie-option
  Not set
  .cookie-name
      A custom value to change the cookie name.

      Note: Please make sure to additionally change the cookie name for each webapp
      (e. g. Cockpit
      ) separately.
  XSRF-TOKEN
  camunda.bpm.webapp.session-cookie
  .enable-secure-cookie
    If set to true, the cookie flag Secure is enabled for the
      Session Cookie.


    Note: If the Secure flag is set in the cookie by any other means already, this property will not remove it by setting it to false.
  false
  .enable-same-site-cookie
    If set to false, the cookie flag SameSite is disabled. The default value of the SameSite cookie is LAX and it can be changed via same-site-cookie-option configuration property.


    Note: If the SameSite flag is set in the cookie by any other means already, this property will not adjust or remove it.
  .same-site-cookie-option
    Can be configured either to STRICT or LAX.


    Note:
      Is ignored when enable-same-site-cookie is set to false
      Cannot be set in conjunction with same-site-cookie-value
      Will not change the value of the SameSite flag if it is set already by any other means
  Not set
  .same-site-cookie-value
    A custom value for the cookie property.


    Note:
      Is ignored when enable-same-site-cookie is set to false
      Cannot be set in conjunction with same-site-cookie-option
      Will not change the value of the SameSite flag if it is set already by any other means
  Not set
  .cookie-name
      A custom value to configure the name of the session cookie to adjust.
  JSESSIONID
  camunda.bpm.webapp.header-security
  .xss-protection-disabled
    The header can be entirely disabled if set to true. 

    Allowed set of values is true and false.
  false
  .xss-protection-option
    The allowed set of values:
      BLOCK: If the browser detects a cross-site scripting attack, the page is blocked completely
      SANITIZE: If the browser detects a cross-site scripting attack, the page is sanitized from suspicious parts (value 0)
    Note:
      Is ignored when .xss-protection-disabled is set to true
      Cannot be set in conjunction with .xss-protection-value
  BLOCK
  .xss-protection-value
    A custom value for the header can be specified.


    Note:
      Is ignored when .xss-protection-disabled is set to true
      Cannot be set in conjunction with .xss-protection-option
  1; mode=block
  .content-security-policy-disabled
    The header can be entirely disabled if set to true. 

    Allowed set of values is true and false.
  false
  .content-security-policy-value
    A custom value for the header can be specified.


    Note: Property is ignored when .content-security-policy-disabled is set to true
  base-uri 'self'
  .content-type-options-disabled
    The header can be entirely disabled if set to true. 

    Allowed set of values is true and false.
  false
  .content-type-options-value
    A custom value for the header can be specified.


    Note: Property is ignored when .content-security-policy-disabled is set to true
  nosniff
  .hsts-disabled
      Set to false to enable the header. The header is disabled by default.

      Allowed set of values is true and false.
  .hsts-max-age
      Amount of seconds, the browser should remember to access the webapp via HTTPS.


      Note:
        Corresponds by default to one year
        Is ignored when hstsDisabled is true
        Cannot be set in conjunction with hstsValue
        Allows a maximum value of 2³¹-1
  31536000
  .hsts-include-subdomains-disabled
      HSTS is additionally to the domain of the webapp enabled for all its subdomains.


      Note:
        Is ignored when hstsDisabled is true
        Cannot be set in conjunction with hstsValue
  .hsts-value
      A custom value for the header can be specified.


      Note:
        Is ignored when hstsDisabled is true
        Cannot be set in conjunction with hstsMaxAge or
        hstsIncludeSubdomainsDisabled
  max-age=31536000
  camunda.bpm.webapp.auth.cache
  .ttl-enabled
    The authentication cache time to live can be entirely disabled if set to false. I. e., authentication information is cached for the lifetime of the HTTP session.

    Allowed set of values is true and false.
  .time-to-live
    A number of milliseconds, while the web apps reuse the cache for an HTTP session before they recreate it and query for the authentication information again from the database.


    The allowed set of values:
      a time duration in milliseconds between 1 and 2⁶³-1
      0 which effectively leads to querying for the authentication information on each REST API request
    Note: Ignored when .enabled is set to false
  300,000
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.
Admin User
camunda.bpm.admin-user
The username (e.g., 'admin')
.password
The initial password
.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.
  .group-name-delimiter
    Configures the delimiter used in the OAuth2 Granted Authorities Mapper.
    It's only used if the configured group-name-attribute contains String value.
  , (comma)
  camunda.bpm.oauth2.sso-logout
  .enabled
  Activates the client initiated OIDC logout feature.
  false
  .post-logout-redirect-uri
  Configures the URI the user is redirected after SSO logout from the provider.
  {baseUrl}
Generic Properties
The method of configuration described above does not cover all process engine properties available. To override any process engine configuration
property that is not exposed (i.e. listed above) you can use generic-properties.
camunda:
    generic-properties:
      properties:
  Note:
  Overriding an already exposed property using the generic-properties
  keyword does not effect the process engine configuration. All exposed properties
  can only be overridden with their exposed identifier.
Examples
Override configuration using exposed properties:
camunda.bpm:
  admin-user:
    id: kermit
    password: superSecret
    firstName: Kermit
  filter:
    create: All tasks
Override configuration using generic properties:
camunda:
    generic-properties:
      properties:
        enable-password-policy: true
Session Cookie
You can configure the Session Cookie for the Spring Boot application via the application.yaml configuration file.
Camunda Spring Boot Starter versions <= 2.3 (Spring Boot version 1.x)
server:
  session:
    cookie:
      secure: true
      http-only: true # Not possible for versions before 1.5.14
Camunda Spring Boot Starter versions >= 3.0 (Spring Boot version 2.x)
server:
  servlet:
    session:
      cookie:
        secure: true
        http-only: true # Not possible for versions before 2.0.3
Further details of the session cookie like the SameSite flag can be configured via
camunda.bpm.webapp.session-cookie in the application.yaml.
Configuring Spin DataFormats
The Camunda Spring Boot Starter auto-configures the Spin Jackson Json DataFormat when the
camunda-spin-dataformat-json-jackson dependency is detected on the classpath. To include a
DataFormatConfigurator for the desired Jackson Java 8 module, the appropriate dependency needs
to be included on the classpath as well. Note that camunda-engine-plugin-spin
needs to be included as a dependency as well for the auto-configurators to work.
Auto-configuration is currently supported for the following Jackson Java 8 modules:
Parameter names (jackson-module-parameter-names)
Java 8 Date/time (jackson-datatype-jdk8)
Java 8 Datatypes (jackson-datatype-jsr310)
  Heads Up!
  The Spin Jackson Json DataFormat auto-configuration is disabled when using
camunda-spin-dataformat-all as a dependency. The camunda-spin-dataformat-all artifact shades the
Jackson libraries, which breaks compatibility with the regular Jackson modules. If usage of
camunda-spin-dataformat-all is necessary, please use the standard method for
Spin Custom DataFormat configuration.
For example, to provide support for Java 8 Date/time types in Spin, the following dependencies, with their
appropriate version tags, will need to be added in the Spring Boot Application’s
pom.xml file:
<dependencies>
    <dependency>
      <groupId>org.camunda.bpm</groupId>
      <artifactId>camunda-engine-plugin-spin</artifactId>
    </dependency>
    <dependency>
      <groupId>org.camunda.spin</groupId>
      <artifactId>camunda-spin-dataformat-json-jackson</artifactId>
    </dependency>
    <dependency>
      <groupId>com.fasterxml.jackson.datatype</groupId>
      <artifactId>jackson-datatype-jdk8</artifactId>
    </dependency>
</dependencies>
Spring Boot also provides some nice configuration properties, to further
configure the Jackson ObjectMapper. They can be found here.
To provide additional configurations, the following actions need to be performed:
Provide a custom implementation of org.camunda.spin.spi.DataFormatConfigurator;
Add the appropriate key-value pair of the fully qualified classnames of the interface and the
implementation to the META-INF/spring.factories file;
Ensure that the artifact containing the configurator is reachable from Spin’s classloader.
DefaultProcessEngineConfiguration
DefaultDatasourceConfiguration
DefaultHistoryConfiguration
DefaultHistoryLevelAutoHandlingConfiguration
DefaultJobConfiguration
DefaultDeploymentConfiguration
DefaultAuthorizationConfiguration
Overriding the Default Configuration
Adding Additional Configurations
Camunda Engine Properties
Generic Properties
Examples
Session Cookie
Configuring Spin DataFormats
            camunda.org and docs.camunda.org are part of Camunda 7
            Built by camunda and contributors — Privacy Statement — camunda Services GmbH © 2024
             The content on this site is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Default Configurations

`DefaultProcessEngineConfiguration`

`DefaultDatasourceConfiguration`

`DefaultHistoryConfiguration`

`DefaultHistoryLevelAutoHandlingConfiguration`

`DefaultJobConfiguration`

`DefaultDeploymentConfiguration`

`DefaultAuthorizationConfiguration`

Overriding the Default Configuration

Adding Additional Configurations

Camunda Engine Properties

Generic Properties

Note:

Examples

Configuring Spin DataFormats

Heads Up!
