Overview of cost data objects

PolicyCenter defines cost entities that describe the costs of different objects in the policy graph. These are the entities that persist in the database. A cost specifies how much money in the premium applies to which items in the policy. Cost objects share common properties. However, Cost is not a single database table. There is not a single Cost entity that is the supertype of each cost entity. Instead, the Cost entity is a delegate, which is similar to an interface definition. The Cost delegate defines the various properties common to all costs. Each line of business implements its own root entity table for its cost objects, and all cost objects for that line of business are subtypes of that entity.

For example, personal auto line of business defines its own PACost entity, and all personal auto costs are subtypes of PACost. The Businessowners Policy defines the BOPCost entity. Each line defines further subtypes of the line-specific cost entity, for example the personal vehicle coverage cost object entity PersonalVehicleCovCost. The line-specific cost subtype entities include additional properties and links into the policy graph specific to that line of business.

If you create custom lines of business, you might want to look at how the built-in lines of business structure their cost objects within the policy graph.

Although the cost and transaction entities define what PolicyCenter persists to the database to describe the results of rating, it is difficult to write code that directly modifies cost entities. There are subtle aspects to manage, such as splitting and merging entities, and this interacts with how PolicyCenter tracks revisioned entities across effective time. For example, creating or removing additional slice dates or tracking which changes are window mode changes.

To make it easier for customers to write correct and complete rating engines, the default rating architecture manages a parallel hierarchy of objects that correspond to each Cost entity. These objects are called cost data objects, implemented by subclasses of the CostData class. The cost data objects are Gosu objects, which are simply instances of in-memory Gosu classes. The cost data classes mirror all of the cost entity subtypes and contain the same basic information. Each cost data subclass mirrors each subtype of the Cost entity. In general, for every cost entity in the database there is one cost data object that the rating engine generates. The name of each cost data entity subclass is the name of its cost data object that it mirrors, followed by the suffix Data. For example, there is PersonalVehicleCovCost cost entity and so there is also a PersonalVehicleCovCostData cost data class.

Cost data objects are regular Gosu objects (not entity instances) that mirror every cost in the policy graph. During the first phase of rating, your rating engine creates cost data objects. During the second phase of rating, some code converts these cost data objects to Cost entity instances. If you use the built-in rating framework, this is easy and automatic.

In contrast to actual Cost entities, it is easy and low risk to write Gosu code that splits and merges CostData objects. You can optionally split or merge cost data objects in your integration code on the way out of PolicyCenter. You can split or merge cost data objects on the way in to PolicyCenter after external rating is complete. Afterward, your rating integration code can rely on built-in Guidewire code that intelligently merges cost data objects as appropriate. The built-in code updates Cost entities based on CostData objects that your rating engine generates.

This approach helps rating engines separate the two major processes of rating.

• Determining the appropriate rates and costs, including calling out to an external system if necessary
• Persisting rating information changes in the database in the most efficient and correct way possible

Guidewire strongly recommends that you write your rating engine to populate CostData objects instead of actual Cost entities. It is easier and safer to integrate rating using the built-in CostData objects and the built-in code that generates and manipulates them.

The following are notable differences between Cost entities and CostData objects.

Behavior	Costs (entity instances)	Cost data objects (Gosu objects)
Are they persisted in the database?	Yes	No. Cost data objects never directly persist in the database. Guidewire code defined in AbtractRatingEngine converts the cost data objects to costs which PolicyCenter persists in the database with the policy.
Are links between objects handled as direct references to entities?	Yes. The application entity layer handles database persistence just like all other entity data.	No. CostData objects do not use actual links to other entities. Instead, cost data objects refer to entities using the fixed ID values of the entity this cost represents. A fixed ID is a unique identifier that identifies an object across effective time and also across multiple revisions. Cost data objects do not directly store the fixed IDs. Instead, they encapsulate fixed IDs into Key objects, which are a container for foreign keys. This difference in link handling simplifies rating code, particularly with external rating engines. Send entity links as fixed IDs to an external system. With results from an external system, you can assemble cost data objects from the fixed ID information. The built-in default rating engine merges cost data objects as appropriate and updates the actual Cost entities. This means that you do not have to worry about as many details of the revisioning system.
Do PCF pages use them to display costs?	Yes. PolicyCenter PCF pages display cost entities attached to the policy graph.	No. After the rating engine completes, PolicyCenter discards all cost data objects, which are just temporary Gosu objects.
How easy is it to write your own code to split or merge costs across effective time?	It is difficult to split or merge Cost entities correctly. How the revisioning system deals with splitting and merging entities across effective time is complex. Fortunately, you do not need to manage this if you use the built-in code to manipulate cost data objects.	It is easy and low risk to write your rating code to primarily use cost data objects. Split or merge cost data objects in your integration code after your core rating engine code returns its results. Afterward, built-in PolicyCenter code updates the raw Cost entities based on your CostData objects.

Guidewire strongly recommends that you write your rating code to use the cost data architecture and the built-in code to manipulate them. This simplifies your rating integration code. In theory, your rating plugin can manipulate raw cost entities. However, this approach is challenging and not recommended for the reasons stated earlier.

A cost data class includes the following important properties and methods.

• Cost-related properties – Cost-related properties defined by the corresponding cost entity.
• Revisioning properties – Cost data objects duplicate revisioning-specific fields from the Cost entity, such as the effective date and expiration date.
• Methods that you override – Each cost data object class helps the rating engine with tasks such as finding the related cost entity instance for this cost data object.
• API methods that you can call – Every cost data class inherits built-in APIs from the CostData class.