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 were set in the Vocabulary's Custom Data Types.

Note: Progress recommends 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 preproduction 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 to 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 stops 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 information into the log.) No further processing occurs.

Note: See the topic How to change logging configuration .

You can set the property in brms.properties that relaxes enforcement of Custom Data Types, com.corticon.vocabulary.cdt.relaxEnforcement=true, and then restart 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: Progress recommends 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 Server Properties and settings for more for information about where to locate this properties file.