Unless the application that formed the request ensured that a value was provided before submission, one (or both) of the attributes used in a comparison test might have a null value. You might need to define rules to handle such cases. An example that describes the workaround for these cases uses the following Vocabulary:



Here are two scenarios:

  1. Two dates are passed from the application and one of them is null. When given the rule ‘[ If FilingUnit.theDate is null ] or [ [ FilingUnit.theDate = Null ] and [FilingUnit.theDate >= Person.theDate ] ]’, then the appropriate action triggers.
  2. In Actions, one date value is set to another date's value that happens to be null. If the date is null, then it is used in the subsequent Rulesheets in their Conditions section. However, because the value is null, a warning is generated in the Corticon logs.

For the first scenario, the logic in subsequent Rulesheets needs to determine whether a value is null, so it can apply appropriate actions. The following Rulesheet shows that you can avoid the error message by only setting the preferred date when you have a non-null filing date or person date.



Note: If null values would prevent subsequent rules from continuing reasonable further processing, then perhaps validation sheets should be used before rule processing to check the data, and then terminate execution of the decision if the data is bad. That could be accomplished by setting an attribute that can be tested in the filter section of subsequent Rulesheets. Then, every subsequent Rulesheet is assured of dealing only with clean data.

For the scenario where both values being compared are null, you could set the resulting value to a default value or to null, as shown:



As highlighted, Rule 3 explicitly sets the preferred date to null when both incoming dates are null.