Validation chaining

In the base configuration, the gw.policy.PolicyPeriodValidation class is an example of policy-graph validation in which one validation class successively calls (chains to) other validation classes to perform additional validation. For example, while running its validation checks for the policy period, PolicyPeriodValidation chains to:

  • gw.policy.PolicyContactRoleValidation to validate the contact roles on the policy.
  • gw.policy.PolicyContactRoleForSameContactValidation to validate multiple roles on the same contact.
  • gw.policy.PolicyLocationValidation to validate each policy location.
  • gw.policy.PolicyLineValidation to validate each of its lines of business.
  • gw.policy.ModifierValidation to validate that all specified modifiers are valid modifier type codes.

Validation chaining is the process of one validation class calling another validation class to perform additional validation checks. Thus, to chain validation:

  1. A validate method in one validation class first calls the validation methods defined in its class.
  2. This validate method then invokes the validate method on another validation class (often by looping through a set of objects).
  3. In turn, these classes chain to validations of entities they hold. For example, to validate all vehicles on a policy for a Personal Auto policy period, PolicyPeriodValidation chains to PALineValidation which then chains to PALineVehiclesValidator. To validate each individual vehicle, PALineVehiclesValidator chains to PersonalVehicleValidation. Other examples of chaining include PALineValidation calling PALineCoveragesValidator, PALineDriversValidator, and PALineAssignmentValidator.
  4. After executing the validate methods in each of the related classes, control returns to the calling class. The calling class can then perform additional validation checks.

It is important to understand that validation chaining is not automatic. For a class to perform validation chaining, you must specifically construct it to do so. Guidewire specifically designed the PolicyPeriodValidation class to perform validation chaining.

Validation Chaining Example

The following graphic illustrates the concept of validation chaining. This is a simplified diagram—it does not show every validation method call in the actual implementation. The actual implementation provides an easy way to perform a full validation of the policy period.


Validation chaining for the PolicyPeriod entity

Any change to a PolicyPeriod object triggers validation of that object (1 and 2 in the graphic). Initially, the validateImpl method defined in PolicyPeriodValidation (3 in the graphic) executes a number of validation methods defined in PolicyPeriodValidation, each of which tests for a certain condition. These methods (labeled 4 through 12) are:

  • checkPeriodDates
  • checkQuoteNeededDate
  • checkProductIsValid
  • checkMinimumDataForQuote
  • checkBillingInformation
  • checkReportingPolicyIsCreatedWithFinalAudit
  • checkOfficialIDs
  • checkUnderwritingCompany
  • checkAnswers

After these checks complete—still in the validateImpl method—the code executes a loop through all of the Location objects in PolicyLocations (labeled 13). For each Location, it calls the PolicyLocationValidation validate method on that object (labeled 14). The validation methods within PolicyLocationValidation (labeled 15 through 17) are:

  • allAccountLocationsAreActive
  • territoryCodeAgreesWithLocation
  • checkAnswers

The PolicyPeriodValidation validateImpl method continues by invoking the validate method for each policy line to perform line-specific validation:

Period.Lines.each(\ line -> validateLine(line, \ validator -> validator.validate() )

For example, if validating a Personal Auto line policy period, the code calls the validate method in PALineValidation.gs (labeled 19). This validation override first calls the local method policyPeriodOneYearMax. It then chains to validate methods in a series of other validation classes:

  • CoveragesValidator.doValidate
  • AssignmentValidator.doValidate
  • VehiclesValidator.doValidate
  • DriversValidator.doValidate

Each of these validation classes contains its own override of doValidate. Among these, only a few of the methods in DriversValidator are shown in diagram (labeled 21 through n). These methods perform specific checks for driver qualifications, including:

  • qualifiedGoodDriver
  • appliedGoodDriverDiscount
  • licenseInfoRequired

Each of the validators loops as needed to validate all of the coverages, assignments, vehicles, and drivers that apply within the policy period being validated.

Finally, control returns to the original validateImpl method in PolicyPeriodValidation and calls additional local validation methods (labeled 24 through 29), including:

  • checkUniqueKeyBeansHaveNoDuplicates
  • checkNamedInsuredIndustryCode
  • checkPolicyLocationIndustryCode

The following topics discuss parts of this example in more detail:

For an explanation of Gosu block definition and syntax, refer to Basic block definition and invocation.