Writing delegate-based matcher classes

The delegate-based matchers implement methods that a delegate interface in the gw.api.logicalmatch package defines. The delegate interface depends on the type of the object to match.

  • For effective-dated subobjects in a PolicyPeriod graph, the matchers use the EffDatedLogicalMatcher interface. This interface extends the LogicalMatcher interface.
  • For all other entity types, the matchers use the LogicalMatcher interface.

The base comparison is in the PCBeanMatcher class. This class compares the Id property and, for effective-dated subobjects in a PolicyPeriod graph, the FixedID property,

To define a new matcher, extend the relevant abstract class that PolicyCenter provides as a base implementation of each matcher interface in the gw.api.logicalmatch package:
  • For effective-dated subobjects in a PolicyPeriod graph, extend the AbstractEffDatedPropertiesMatcher class.
  • For all other entity types, extend the AbstractPropertiesMatcher class.
In your new matcher class, override the abstract property definition for the IdentityColumns property. You use the set of fields that uniquely identify an entity to create the IdentityColumns property of the matcher.

To assist the matching task, the LogicalMatcher interface provides the genKey method to generate a unique key for an object. In the abstract implementations of the LogicalMatcher interface, the genKey method uses the IdentityColumns property to create the unique key. Two objects match if this unique key is the same for both objects. If the keys for two objects do not match, the objects definitely do not refer to the same item.

If the keys for two objects match, the objects might or might not refer to the same item. To confirm whether the two objects are the same, PolicyCenter calls the isLogicalMatchUntyped(KeyableBean bean) method, which optionally performs more checks. These additional comparisons could include whether a set of parent foreign keys also match. For example, two VehicleDriver entity instances match if the foreign keys to PersonalVehicle and PolicyDriver also match.

The implementation of the delegate-based matchers in the base configuration relies on properties on the entity, including parent foreign key links, to determine whether two objects match.

General guidelines for writing new matchers are described below.

  • You can match on whatever properties you want, but using properties backed by database columns is recommended over using virtual properties.

    Avoid matching on non-database-backed properties, such as dynamically generated Gosu properties. These types of properties are marked as (virtual property) in the Data Dictionary. For example, the CostNew property of a PersonalAuto instance is a virtual property. Contact Guidewire Customer Support for guidance before implementing matchers that use virtual properties.

  • Column values must be immutable values that never change over the life of the object. For example, an automobile VIN does not change over time. The only reason for editing a VIN is to correct a data entry error.