Copying custom properties from cost data objects to entity instances

After a line of business creates its cost data objects, the default rating engine creates new cost entities or updates existing cost entities.

The root CostData class knows how to copy all the built-in cost properties from the cost data object to the cost object. However, for a cost data subclass, the default rating engine needs help to copy any subclass-specific properties to the corresponding new or changed cost entity.

To coordinate this with the default rating engine, each cost data subclass must override (implement) the method setSpecificFieldsOnCost. Before doing anything else, this method must call the superclass implementation of this method: super.setSpecifiedFieldsOnCost.

The cost data base class for each policy line does not need to call the superclass. There is no implementation of this method on the CostData root class. For personal auto, for example, the root class is the class PACostData. However, any subclasses of the cost data base class for each line first must call the superclass implementation.

Next, the setSpecificFieldsOnCost method must copy any additional properties from the cost data object subclass to the cost entity.

For non-foreign-key properties, simply set properties directly on the cost entity instance. Get values from private variables of the cost data object and set properties in the cost entity instance.

For foreign key properties, this approach does not work. Remember that for cost entities, links to other objects are regular foreign key links directly to the destination entity instance. In contrast, cost data objects store the entity’s fixed ID encapsulated in a Key object. This difference simplifies rating code, particularly with external rating engines. You can easily send entity links as fixed IDs to an external system, and with results from the external system assemble cost data objects from that information. You do not have to worry about as many details of the revisioning system.

Because of this difference in links between cost entity objects and cost data objects, your setSpecificFieldsOnCost method cannot simply use code, such as the following code statement.

// This does NOT work because the cost data private variables like _line 
// contain a Key object (which contains a fixed ID), not a real link to a PolicyLine entity
costEntity.PolicyLine = _line

To resolve this difference between how costs and cost data objects handle links, you can use a method called setFieldValue on the Cost entity. The setFieldValue method takes two arguments.

  • The String property name on the Cost entity
  • A Key containing the fixed ID for the object to which you want to link. Alternatively, you can optionally pass a fixed ID String directly to this method instead of a Key if you have a plain fixed ID String for some reason. You might notice that some of the built-in rating code passes a fixed ID Key object to setFieldValue.

For example, the personal auto cost data subtype PersonalAutoCovCostData looks like the following code.

override function setSpecificFieldsOnCost(line : PersonalAutoLine, cost : PersonalAutoCovCost) : void {
  super.setSpecificFieldsOnCost(line, cost)
  cost.setFieldValue( "PersonalAutoCov", _covID )
  cost.setFieldValue( "PersonalVehicle", _vehicleID )
}