Product model immutable field verification

After you move your product model definition to the test or production server, changes to definition, if uploaded to the server, can have adverse effects, such as corrupting existing policies. For example, consider the effects of removing a coverage pattern while there is a bound policy that uses that coverage pattern. PolicyCenter guards against many such changes. For example, it will not let you remove a coverage pattern from a test or production server. But PolicyCenter cannot guard against all possible changes that could have unintended consequences, so you need to think carefully about any changes to existing product model patterns.

You can change certain fields on product model patterns without adverse effects. For example, you can change fields such as Name, Description, or Priority. However, you must guard against changes to fields that define the fundamental identity of the product model patterns. Guidewire refers to these types of field as being immutable, meaning that after you set them you must never change them. Guidewire also uses the term locked field interchangeably with the term immutable field. Additionally, PolicyCenter will not let you make changes on a test or production server that change the fundamental scaffolding of the overall product model. For example, once a coverage term is added to a coverage, that coverage term cannot be deleted.

To prevent changes to these fields, PolicyCenter verifies the set of immutable fields and product model scaffolding when you start the server. It checks both for missing items—a missing coverage pattern, for example—and for immutable fields that have been changed. If verification fails, PolicyCenter adds a message to the server log and fails to start.

Locked entity fields

PolicyCenter stores information about immutable fields in the test or production database. During server startup, it reads this information and compares it with the product model definition files stored, or newly loaded, in its local file system. The locking table contains one row for every product model entity. For example, it contains a row for each coverage, a row for each policy line, and so forth. A separate table stores the locked field name and the locked value. These name-value pairs represent a Name and an EntityPublicID for a field on the referenced entity.

For example:

ProductModelEntityType
    FieldName 1: FieldValue 1
    FieldName 2: FieldValue 2
    ...
    FieldName n: FieldValue n

To illustrate with a more concrete example, some of the locked fields on this Personal Auto Collision Coverage are:

CoveragePattern
    CodeIdentifier: PersonalAutoCollisionCoverage
    CoverageCategory: PAPPhysDamGrp
    CoverageSubtype: PersonalVehicleCov
    OwningEntityType: PersonalVehicle
    PublicID: 32342123342
    ...

In this coverage, the locked fields are CoverageCategory, CoverageSubtype, and OwningEnityType, which specifies that this is a vehicle-level coverage. The CodeIdentifier and PublicID are locked by the deleted pattern check. See Deleted pattern checks.

Locked array elements

PolicyCenter also stores any required array elements in the locking table. The table contains a row for each array element. Therefore, if the array has multiple elements, the table has a row for each element. To illustrate, suppose a particular CoverageSymbolGroup entity named CovSymbGrp has an array of coverage symbol entities named CovSymbs associated with it. In this example, CovSymbs has a field with the name covsymbgrp that points back to CovSymbGrp. In the production locking table, PolicyCenter stores locking table entries as 

CovSymbs, covsymbgrp : CovSymbGrp, ...

This group of locking table entries indicates that there must be an entity of type CovSymbs and that the field covsymbgrp must have the value of its parent, CovSymbGrp. If CovSymbs is deleted, PolicyCenter immediately identifies the deletion.

Verifying locked fields and arrays

After PolicyCenter populates the locking table, you can verify whether you have made any illegal edits. During server startup, after loading the product model, PolicyCenter iterates over all the rows in the locking table and tries to find a match for each individual row.

There are two possible scenarios.

  • The entity has a Public ID – If the entity has a PublicID, that PublicID is always locked. If PolicyCenter does not allow deletions for this entity, PolicyCenter searches the locking table for a product model entity of the same type and with the same PublicID. The possible outcomes are:
    • PolicyCenter cannot find a match in the locking table and assumes that the entity was deleted. PolicyCenter adds a message to the server log and fails to start.
    • PolicyCenter finds a match in the locking table and compares all the locked fields against the product model entity. If this comparison fails, PolicyCenter adds a message to the server log and fails to start. In the error case, PolicyCenter issues specific error messages such as: You changed field A on entity B to value C. Please set it back to A.
  • The entity does not have a Public ID – The entity has no PublicID. A subset of the product model entities do not have a PublicID. If deletions for this entity are not allowed, PolicyCenter attempts to find a complete match for the product model entity in the locking table. If it does not find a complete match, PolicyCenter adds an Entity Deleted or Modified error to the server log and fails to start.

Adding new entities

You can add new product model patterns to the product model at any time. However, after you add new product model patterns on the test or production server, PolicyCenter locks those entities and does not allow further changes to immutable fields on those entities. Additionally, in most cases, the entity cannot be deleted. During server startup, if PolicyCenter finds an entity for which there are no corresponding rows in the locking table, it assumes that the entity is new. If so, it iterates across the entity definition and inserts rows into the locking table as appropriate. During the subsequent server startups, PolicyCenter verifies its locally stored product model against the product model it is loading.