Authoring a Validation Rule Set involves the following steps:
If the Rule Set specified in the "Additional Validations" section does not exist, the Dynamic Evidence infrastructure will generate a "starter" Rule Set. The generated starter Rule Set will have a class called "ValidationResult" with the base Rule Class and an "evidence" Attribute as mentioned in the Validation Rule Sets Contract section, and will be associated with the Dynamic Evidence Validation category.
Sometimes, an existing Rule Set is specified as the Rule Set to be used for Validation. Typically, this happens when a new Dynamic Evidence Type Version is created and the previous Dynamic Evidence Type Version already had a Rule Set specified for Validation. If an existing Rule Set is used, it should adhere to the Validation Rule Sets contract. A point to note is that if an existing Validation Rule Set is modified, the changes would be visible to all Dynamic Evidence Type Versions which have been using this Rule Set.
As described in the section about DefaultEvidenceValidationResult Rule Class, this Rule Class has Attributes corresponding to different sets of Validations. All these Attributes have a value of null , which means by default there are no Validations defined in any of the Validation sets. For a particular Dynamic Evidence Type, all or only some of the Validation Sets might be required. For example. a Dynamic Evidence Type Version might require only "detailsValidations" and "standardValidations". As such, the Attributes corresponding to Validation sets should be redefined. Typically, a CER Fixed List is used to construct the list of Validations in a set.
Typically, a Validation will refer to data from the Case Evidence record or related Case Evidence records - this is why the contract for Validation Rule Sets specify that they should have an Attribute named "evidence". This Attribute is populated with data from the corresponding Case Evidence instance whenever the Rule Set is invoked.
A Validation can be defined by using the CER create expression. The create expression when called for the Validation Rule Class requires that a derivation be specified for the isFailure Attribute and failureMessage Attribute.
The derivation for the isFailure Attribute must produce a boolean value. For example, let us say there are two Attributes, "startDate" and "endDate" in a Dynamic Evidence Type, and the Validation required is that the "startDate" should not be the same as the "endDate". The derivation for the isFailure Attribute of this Validation can use a CER compare expression which compares the "startDate" and "endDate" Attributes. The compare expression will obtain the value of these two Attributes by using a reference expression on the "evidence" Attribute of the Validation Rule Class.
The derivation for the failureMessage Attribute should produce a value of type curam.creole.value.Message . For this, the derivation can use an XML Message or a Resource Message expression. Again, if the message is to be parameterized with data from the Case Evidence record, the required Attribute can be accessed through the "evidence" Attribute of the Validation Rule Class using the reference expression.
Optionally, a value can be specified for the "informationalType" of the Validation. If no value is specified, the informational type will be considered in error. However, the static operations ( error() , warning() and fatalError() ) in curam.dynamicevidence.validation.impl.InformationalType can be used to specify a different informational type.
Typically, the informational type is dependent on the Validation Mode. The Validation mode for a particular Validation session can be accessed through the "validationMode" Attribute of the Validation Result Rule Class. The validation mode can then be compared with one or more Validation Modes using the static operations ( applyChanges() , approve() , insert() , modify() , validateChanges() ) defined in curam.dynamicevidence.validation.impl.ValidationMode to determine the informational type to be used. For example, the Validation Mode for a Validation Session can be compared with "Apply Changes" and "Validate Changes" and the informational type can be specified as error for the former and warning for the latter case.