Business Rule Task

A Business Rule Task is used to synchronously execute one or more rules.

Using Camunda DMN Engine

You can use the Camunda DMN engine integration to evaluate a DMN decision. You have to specify the decision key to evaluate as the camunda:decisionRef attribute. Additionally, the camunda:decisionRefBinding specifies which version of the decision should be evaluated. Valid values are:

deployment, which evaluates the decision version which was deployed with the process version,
latest which will always evaluate the latest decision version,
version which allows you to specify a specific version to execute with the camunda:decisionRefVersion attribute, and
versionTag which allows you to specify a specific version tag to execute with the camunda:decisionRefVersionTag attribute.

<businessRuleTask id="businessRuleTask"
    camunda:decisionRef="myDecision"
    camunda:decisionRefBinding="version"
    camunda:decisionRefVersion="12" />

The camunda:decisionRefBinding attribute defaults to latest.

<businessRuleTask id="businessRuleTask"
    camunda:decisionRef="myDecision" />

The attributes camunda:decisionRef, camunda:decisionRefVersion, and camunda:decisionRefVersionTag can be specified as an expression which will be evaluated on execution of the task.

<businessRuleTask id="businessRuleTask"
    camunda:decisionRef="${decisionKey}"
    camunda:decisionRefBinding="version"
    camunda:decisionRefVersion="${decisionVersion}" />

The output of the decision, also called decision result, is not saved as process variable automatically. It has to pass into a process variable by using a predefined or a custom mapping of the decision result.

In case of a predefined mapping, the camunda:mapDecisionResult attribute references the mapper to use. The result of the mapping is saved in the variable which is specified by the camunda:resultVariable attribute. If no predefined mapper is set then the resultList mapper is used by default.

<businessRuleTask id="businessRuleTask"
    camunda:decisionRef="myDecision"
    camunda:mapDecisionResult="singleEntry"
    camunda:resultVariable="result" />

See the User Guide for details about the mapping.

Name of the Result Variable

The result variable should not have the name decisionResult, as the decision result itself is saved in a variable with this name. Otherwise, an exception is thrown while saving the result variable.

DecisionRef Tenant Id

When the Business Rule Task resolves the decision definition to be evaluated it must take multi tenancy into account.

Default Tenant Resolution

By default, the tenant id of the calling process definition is used to evaluate the decision definition. That is, if the calling process definition has no tenant id, then the Business Rule Task evaluates a decision definition using the provided key, binding and without a tenant id (tenant id = null). If the calling process definition has a tenant id, a decision definition with the provided key and the same tenant id is evaluated.

Note that the tenant id of the calling process instance is not taken into account in the default behavior.

Explicit Tenant Resolution

In some situations it may be useful to override this default behavior and specify the tenant id explicitly.

The camunda:decisionRefTenantId attribute allows to explicitly specify a tenant id:

<businessRuleTask id="businessRuleTask" decisionRef="myDecision"
  camunda:decisionRefTenantId="TENANT_1">
</businessRuleTask>

If the tenant id is not known at design time, an expression can be used as well:

<businessRuleTask id="businessRuleTask" decisionRef="myDecision"
  camunda:decisionRefTenantId="${ myBean.calculateTenantId(variable) }">
</businessRuleTask>

An expression also allows using the tenant id of the calling process instance instead of the calling process definition:

<businessRuleTask id="businessRuleTask" decisionRef="myDecision"
  camunda:decisionRefTenantId="${ execution.tenantId }">
</businessRuleTask>

Using a Custom Rule Engine

You can integrate with other rule engines. To do so, you have to plug in your implementation of the rule task the same way as in a Service Task.

<businessRuleTask id="businessRuleTask"
    camunda:delegateExpression="${MyRuleServiceDelegate}" />

Using Delegate Code

Alternatively, a Business Rule Task can be implemented using Java Delegation just as a Service Task. For more information on this please see the Service Tasks documentation.

Implementing as an External Task

In addition to the above, a Business Rule Task can be implemented via the External Task mechanism where an external system polls the process engine for work to do. See the section on [Service Tasks]((/manual/7.10/reference/bpmn20/tasks/service-task/#external-tasks) for more information about how to configure an external task.

Camunda Extensions

Attributes	camunda:asyncBefore, camunda:asyncAfter, camunda:class, camunda:decisionRef, camunda:decisionRefBinding, camunda:decisionRefTenantId, camunda:decisionRefVersion, camunda:decisionRefVersionTag, camunda:delegateExpression, camunda:exclusive, camunda:expression, camunda:jobPriority, camunda:mapDecisionResult, camunda:resultVariable, camunda:topic, camunda:type, camunda:taskPriority
Extension Elements	camunda:failedJobRetryTimeCycle, camunda:field, camunda:connector, camunda:inputOutput
Constraints	One of the attributes `camunda:class`, `camunda:delegateExpression`, `camunda:decisionRef`, `camunda:type` or `camunda:expression` is mandatory
	The attribute `camunda:resultVariable` can only be used in combination with the `camunda:decisionRef` or `camunda:expression` attribute
	The `camunda:exclusive` attribute is only evaluated if the attribute `camunda:asyncBefore` or `camunda:asyncAfter` is set to `true`
	The attribute `camunda:topic` can only be used when the `camunda:type` attribute is set to `external`.
	The attribute `camunda:taskPriority` can only be used when the `camunda:type` attribute is set to `external`.

Options