When you run a Ruletest in Studio, it might produce error messages. Error messages are distinct from Post messages you specified in Rulesheet Rule Statements to generate info, warning, and violation statements that are posted by normal operation of the rules.

Constraint violation

A constraint violation indicates that values in the test's attributes are not within numeric constraint ranges or not included in enumerated lists that were set in the Vocabulary's Custom Data Types. A constraint violation might look like this:
Figure 1. A Constraint violation in a Ruletest
In the example, the constraint is shown, and its violation is marked on the attribute and its entity in the Input column:

Running the test halts at the first constraint violation. The log lists the first constraint exception and its detailed trace. No response is generated.

You can revise the input to have valid values, or choose to relax the enforcement of such violations through a setting in the brms.properties file, com.corticon.vocabulary.cdt.relaxEnforcement=true.

When the option is enabled, a response is generated that includes each of constraint violation warnings. For example:

<CorticonResponse xmlns="urn:Corticon" 
                     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
                     decisionServiceName="Cargo.ers_null_ALL">
  <WorkDocuments>
    <Cargo  id="Cargo_id_1">
      <weight>0</weight>
      <volume>-1</volume>
      <container>standard</container>
    </Cargo>
  </WorkDocuments>
  <Messages version="0.0">
    <Message postOrder="cc00000001">
      <severity>Warning</severity>
      <text>constraint violation setting Cargo.weight to value [0]</text>
      <entityReference href="Cargo_id_1" />
    </Message>
  ...
  </Messages>
</CorticonResponse>

See How to relax enforcement of Custom Data Types for details about constraints and the option to relax enforcement.

Note: The output example shown reflects the execution properties in a Ruletest output file. If you extract the same response for a Ruletest from your Studio log when the RULETRACE logging filter is enabled, then you reveal several additional execution properties that can be helpful in support efforts, but they are otherwise not meaningful to users.

Severe errors

Some errors indicate problems with how the rules engine is handling the Decision Service: Null Pointer Exception, Reactor Exception, Fatal Exception. These error conditions are important to resolve as soon as possible.

Immediately capture and save any advanced information in the alert, and then copy and save the logs. You might want to try closing Corticon Studio and running the Ruletest again. If it reliably fails with a severe error, package the current project and logs, and then contact support. If you followed the best practice of retaining offline backups of the project as well as saving your work, you might be able to resume with most-recent backup in a different project workspace.

Note: Next step in troubleshooting—If you did not encounter constraint violations or severe errors, any other problems are within your rules. Proceed to Analyzing Test Results. To work around a problem in rules, you can identify the expression syntax that produces it, and then try to express the logic in a different way. The Corticon Rule Language is very flexible and usually allows the same logic to be expressed in many different ways.