skip to main content
Corticon Studio: Rule Modeling Guide : Building the Vocabulary : Custom Data Types : Relaxing enforcement of Custom Data Types
 

Try Corticon Now
Relaxing enforcement of Custom Data Types
Using Custom Data Types lets you define general limitations of an attribute's values that are enforced on all Rulesheets and Ruletests in the project and its Decision Services. While they are valuable in focusing on what is valid in rule designs, violations of the constraints or lists cause rule processing -- Ruletests in Studio; Decision Services on Servers -- to halt at the first violation. Such exceptions indicate that values in attributes are not within numeric constraint ranges or not included in enumerated lists that have been set in the Vocabulary's Custom Data Types.
Note: It is recommended that you use relaxed enforcement of CDTs only in test environments. In production, you should enforce data constraints and lists to ensure valid processing by rules.
For Ruleflows, a rule that throws an exception in earlier Rulesheets disables processing in subsequent Rulesheets. In the following example, the Advanced Tutorial testsheet outputs the following statements:
Note: The rule tracing feature reveals which Rulesheets fired which rules.
By defining a Custom Data Type that specifies the Item attribute price must be greater than zero, and then entering the input value -1.00 for an item on the testsheet, the first constraint error stops all the subsequent rules from firing:
Relaxing the enforcement of Custom Data Type constraints produces warnings instead of violations, so that development teams and pre-production testing teams can expedite their debugging of rules and error handling, as shown:
This example might indicate that the applications that format requests should handle the data constraint before forwarding a request into the rules engine.
Detailed Example
The following example uses the Cargo Vocabulary. It has two Custom Data Types, one numeric constraint (assigned to Cargo.weight and Cargo.volume) and an enumeration list (assigned to Cargo.container.)
A value that is outside the constraints (Cargo [1] volume = -1) is noted as violating the attribute's data type constraint on each input attribute and its entity, as well as noted on the Problems tab. But when the Ruletest runs, it halts on the first Violation, as shown:
The details of that first exception are entered in the log (when the loglevel is INFO or higher, and the logInfoFilter does not include VIOLATION -- thereby accepting that type of info into the log.) No further processing occurs.
Note: See the topic Changing logging configuration for more information.
By setting the CcServer property that relaxes enforcement of Custom Data Types, com.corticon.vocabulary.cdt.relaxEnforcement=true, and then restarting the Studio, the errors are still flagged in the data and the Problem information is unchanged. However, the Rule Messages section flags each of the constraint breaches as a Warning, lets them proceed, and then fires all the other rules.
Note: It is recommended that you create or update the standard last-loaded properties file brms.properties to list override properties such as this for Corticon Studios and Servers. See the introductory topics in "Configuring Corticon properties and settings" for information on where to locate this properties file.