Executing the Business Rule Set Execution Plan
The generation of the execution plan of a business rule set will involve:
1. Creation of a specific RuleValidation instance based on the selector defined in the business rule.
2. The RuleValidation instance will be used to determine if the configuration of the business rule is valid using the isConfigurationValid method. If the configuration is not valid, the RuleValidation will be skipped for the business rule set execution plan and error will be logged.
3. For each business rule the RuleValidation instance is called with the following items:
a. Collection of objects that rules are to evaluate
b. Context specific criteria (such as the container reference) that may be used by a RuleValidation to configure its execution.
4. The RuleValidation instance is added to the execution plan.
All the business rule validators will implement the RuleValidation interface. A typical business rule will fall under two primary categories:
• Simple validation: The rules check is done on the business object itself or on the seed objects as configured by the relationship. An example could be checking for attribute validation or checking a life cycle state of the object prior to release.
• Structured validation: The rules may or may not be performed on the business objects but will include some validation checks on its associated objects like the children of the part or document. In this type of validation, typically more complex set of algorithm might be required to calculate the business validation rules and populate the validation result with appropriate flag. An example of structured validation rule is a validation check that makes sure that all resulting objects and all first level dependents are in the correct state.
The following are supported RuleValidation implementations that are provided with the default Windchill installation:
|
Business Rule Selector
|
RuleValidation
|
Description
|
|---|---|---|
|
CHECKOUT_RULE
|
com.ptc.core.businessRules.validation.CheckoutRuleValidator
|
Validates that objects are not checked out or checked out to a project.
|
|
RELEASE_TARGET
|
com.ptc.core.businessRules.validation.ReleaseTargetValidator
|
Ensures that all “Resulting Objects” are at an appropriate state for release and have an appropriate change management transition specified that is consistent with the assigned lifecycle transition rules.
|
|
ATTRIBUTE_RULE
|
com.ptc.core.businessRules.validation.AttributeRuleValidator
|
Validates that the specified attribute rule configuration for an object type is valid.
|
|
BOM_RELEASE_RULE
|
com.ptc.core.businessRules.validation.BOMReleaseRuleValidator
|
Ensures that all resulting objects are at an appropriate state and all their first level children are at an appropriate state.
|
 |
As of the 11.0 release, the Promotion Request supports the Attribute Rule and the Check Out rule. The Change Notice supports any rule.
|
The instantiation of the RuleValidation will be based on the selector defined in the business rule. Application services will be used to lookup the implementing class for the defined selector. If no implementing class is defined, or the class fails to be instantiated an error will be logged.
Prior to executing any validation the engine will call the RuleValidation.isConfigurationValid which will determine if the business rule configuration is valid. This validation of the business rule configuration is also called when loading the business rule (see Creating Business Rules), but since it is possible to change the registered RuleValidation, validation of configuration is also called prior to executing the business rule validation.
TheRuleValidation initialization method called prepare is used to perform some initial preprocessing of the entire set of seed objects that will be validated against the set of business rules. This is to allow any pre-validation to occur within the Windchill server (example might be retrieving the lifecycle template which would be common to many of the items). It is best to call multi-object APIs from the RuleValidation.prepare method. It is advised not to use the RuleValidation.peformValidation method to perform multi-object calls.
If the method RuleValidation.isConfigurationValid returns true, the RuleValidation performValidation is called for each seed object. The seed object is passed inside the RuleValidationObject. The RuleValidationObject holds the target object (the seed object if it is not a link or the role A or role B if seed object is a link) and the link (if the seed object is a link). When the business rule is a structured type RuleValidation, the RuleValidationObject also contains the collected children and a map of the collected children to the links that they were collected with. The performValidation should always return a new RuleValidationResult that has a reference to the target object and not the link.
Business Rules Engine and Sequence Diagram
Business Rules Engine and Validation Interaction Diagram
RuleValidation implementations are registered in service.properties. To create or override a RuleValidation implementation, add the following to a custom service.properties xconf file:
<Service context="default" name="com.ptc.core.businessRules.validation.
RuleValidation">
<Option serviceClass="com.ptc.core.businessRules.validation.
CheckoutRuleValidator"
selector="CHECKOUT_RULE"
cardinality="singleton"
requestor="null"/>
</Service>
RuleValidation">
<Option serviceClass="com.ptc.core.businessRules.validation.
CheckoutRuleValidator"
selector="CHECKOUT_RULE"
cardinality="singleton"
requestor="null"/>
</Service>
When possible the cardinality of the RuleValidation should be set to “singleton” in order to reduce the number of instances of a particular RuleValidation implementation. The addToProcessingMap() of RuleValidationKey can be used for storing pre-validation data in order to support thread safe processing of RuleValidation implementations when the cardinality is set to “singleton”.