Business Rules Configuration and Execution
The business rules engine executes the registered rules in a business rule set and return validation results. The business rules engine retrieves the set of business rules given the specified business rule set unique keys and the container references from the seed objects. With the set of business rules, the engine executes them against the seed objects.
The following phases describe the execution of business rule sets by the business rules engine:
1. Retrieves the specified seed objects to be validated
2. Retrieves the business rule sets
3. Generates and executes an execution plan for the business rule sets
4. Reports of the results of the plan executed.
Business Rules Execution Flow
Calling the Business Rules Engine
There are examples in the default Change Notice and Promotion Request workflows that show how to call the business rules engine from a workflow. The default Change Notice workflow comes with two different conditionals which call the business rules engine. If there are any failures, the Audit Change Notice Task will show a link called “View Conflicts” on the task. The Audit Change Notice Task allows you to proceed without fixing the failures. Similarly, the Resolve Release Conflicts Task shows the conflicts if there are any. You must fix the problems before proceeding on this task.
Here is another example of how you might want to set up a rework loop in the Promotion Request Approval Process. The Business rule is executed in the OR conditional. If it fails, then an email is sent and the Rework Promotion Request task appears.
There are two supported APIs to execute business rule sets.
• BusinessRulesHelper.engine.execute(primaryBusinessObject, BusinessRuleSetBean[]) : RuleValidationResultSet
The second option allows for overriding the container for all objects regardless of the container that the seed objects are in. This API requires that the seed objects be specified up front and only supports executing one business rule set at a time.
• BusinessRulesHelper.engine.execute(“Business rule set”, RuleValidationCriteria) : RuleValidationResultSet
See Javadoc for more details.
Retrieval of Seed Objects
The relationship delegate is used to get the seed objects for a primary business object that is to be evaluated for a particular business rule set. All relationship delegates implement the RuleValidation interface.
Relationship delegates are registered in service.properties. The following is an example of a delegate for getting the resulting objects for a primary object:
<Service context="default" name="com.ptc.core.businessRules.relationship.
BusinessRuleSetRelationshipDelegate">
<Option serviceClass="com.ptc.core.businessRules.relationship.
ResultingObjectsRelationshipDelegate"
selector="wt.change2.ChangeRecord2"
cardinality="singleton"
requestor="null"/>
The selector is the relationship key which is used to look up the relationship delegate instance. The relationship key naming convention is to use the link class name but is not a requirement. Note that if the relationship delegate returns the links for the relationship, then the role B objects of the links will be used as the seed objects. The target link role can be optionally specified in the BusinessRuleSetBean or RuleValidationCriteria. See the Javadoc for BusinessRuleSetBean for details on how to specify the relationship for a business rule set and current supported relationship delegates.
The following table shows the default delegates that are provided in a standard Windchill installation:
Relationship | Relationship Delegate | Description |
wt.change2.AffectedActivityData | com.ptc.core.businessRules.relationship.AffectedObjectsRelationshipDelegate | Gets the affected object links of the primary business object if it is a change notice or change task. |
wt.change2.ReportedAgainst | com.ptc.core.businessRules.relationship.AffectedObjectsRelationshipDelegate | Gets the affected object links of the primary business object if it is a problem report or variance. |
wt.change2.RelevantRequestData | com.ptc.core.businessRules.relationship.AffectedObjectsRelationshipDelegate | Gets the affected object links of the primary business object if it is a change request |
wt.change2.ChangeRecord2 | com.ptc.core.businessRules.relationship.ResultingObjectsRelationshipDelegate | Gets the resulting object links of the primary business object if it is a change notice or change task. |
wt.change2.IncludedIn2 | com.ptc.core.businessRules.relationship.IncludedInRelationshipDelegate | Gets the change tasks of the primary business object if it is a change notice or the change notice if the primary business object is a change task. |
wt.maturity.MaturityBaseline | com.ptc.core.businessRules.relationship.MaturityBaselineObjectsRelationshipDelegate | Gets the baseline items of the primary business object if it is a promotion notice. |
wt.maturity.PromotionSeed | com.ptc.core.businessRules.relationship.PromotionSeedObjectsRelationshipDelegate | Gets the promotion seeds of the primary business object if it is a promotion notice. |
wt.maturity.PromotionTarget | com.ptc.core.businessRules.relationship.PromotionTargetObjectsRelationshipDelegate | Gets the promotion targets of the primary business object if it is a promotion notice. |
Retrieval of the Business Rule Set Based on Container
The following information is required to obtain a business rule set from the system:
1. The unique key for a business rule set
2. The container reference of which the rules should be evaluated
The business rules engine will be responsible for acquiring the appropriate business rule set from the Windchill services. The business rule sets will be discovered using a hierarchical container lookup. Business rule sets that are not enabled will be ignored.
The following flow chart explains flow of the container look up for a rule set key and a container.
