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 haveto 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 processversion,
- 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 asan 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 yourimplementation 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 moreinformation 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 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 . |
Additional Resources
- Decisions
- Service Tasks
- Tasks in the BPMN 2.0 Modeling Reference
- Demo using Drools on the Business Rule Task
原文: https://docs.camunda.org/manual/7.9/reference/bpmn20/tasks/business-rule-task/