Identify the breakpoint
- Last Updated: June 9, 2021
- 2 minute read
- Corticon
- Version 7.2
- Documentation
To understand why your rules are producing incorrect results, it is important to know where in the Rulesheet or Ruleflow the rules stop behaving as expected. At some point, the rules stop acting normally and start acting abnormally; they break. After you identify where the rule breaks, the next step is to determine why it breaks.
An important tool to help identify the breakpoint is the Ruletest’s message box.
By choosing values for Post and Alias columns in the Rule Messages window, you can
generate a trace or log of the rules that fire during execution. The message box in a
Ruletest displays those messages in the order that they were generated by Corticon Server. In other words, the order of the
messages in the box (top to bottom) corresponds to the order in which the rules were fired
by Corticon Server. While messages in the message
box can also be sorted by severity or entity by clicking the header of those columns,
clicking the Message column header will always sequence according to the order in which
the rules fired. Inserting attribute values into rule statements can also provide good
insight into rule operation. But beware; a non-existent entity inserted into a rule
statement prevents the rule from firing, becoming the cause of another failure!
Disable/Enable
- Rulesheet elements - Right-click active
Condition or Action row headers, column headers, or Filter row headers to display a
pop-up menu containing enable/disable options. Disabled rows and columns will be
shaded in gray on the Rulesheet.
Figure 1. Rulesheet with Rule Column 2 disabled.
- Ruleflow objects - Select objects on a Ruleflow
canvas, and then click the Disable/Enable toolbar button
to toggle the disabled
objects to dark gray. Redo the action to re-enable the object.Figure 2. Ruleflow with coupons object disabled
Disable and re-enable Rulesheet elements and Ruleflow objects until the strange or unexpected behavior stops.