What is the data model?

At its simplest, the Guidewire data model is a set of XML-formatted metadata definitions of entities and typelists.

Entities

An entity defines a set of fields for information. You can add the following kinds of fields to an entity:

  • Column
  • Type key
  • Array
  • Foreign key
  • Edge foreign key

Typelists

A typelist defines a set of code/value pairs, called typecodes, that you can specify as the allowable values for the type key fields of entities. Several levels of restriction control what you can modify in typelists:

  • Internal typelists – You cannot modify internal typelists because the application depends upon them for internal application logic.
  • Extendable typelists – You can modify this kind of typelist according to its schema definition.
  • Custom typelists – You can also create custom typelists for use on new fields on existing entities or for use with new entities.

Guidewire PolicyCenter loads the metadata of the data model on start-up. The loaded metadata instantiates the data model as a collection of tables in the application database. Also, the loaded metadata injects Java and Gosu classes in the application server to provide a programmatic interface to the entities and typelists in the database.

The data model in Guidewire application architecture

Guidewire applications employ a metadata approach to data objects. PolicyCenter uses metadata about application domain objects to drive both database persistence objects and the Gosu and Java interfaces to these objects.

This architecture provides enormous power to extend Guidewire application capabilities. Typically, you alter enterprise-level software applications through customization, wherein you change the behavior of the software by editing the code itself. In contrast, a Guidewire application uses XML files that provide default behavior, permissions, and objects in the base configuration. You change the behavior of the application by modifying the base XML files and by creating Gosu business rules, classes, enhancements, and other objects.

The base data model

The PolicyCenter data model specifies the entities, fields, and other definitions that comprise a default installation of PolicyCenter.

For example, the PolicyCenter data model defines a PolicyPeriod entity and several fields on it, such as AccountNumber, IssueDate, and Status.

PolicyCenter lets you change its data model to accommodate your business needs. You make your changes to the data model by modifying existing XML files and adding new ones. PolicyCenter stores your files that change the data model in the following application directory:

PolicyCenter/modules/configuration/config/extensions

However, you always access and edit the data model files indirectly through the configuration > config > Extensions folder in Studio. Do not edit the XML files directly from the file system yourself.

Changes that you make to the data model are called data model extensions. For example, you can extend the data model by adding new fields to the User entity, or you can declare entirely new entities. The complete data model of your PolicyCenter installation comprises the PolicyCenter model and any data model extensions that you make.

Warning: Do not attempt to modify any files other than those in the PolicyCenter/modules/configuration directory. Any attempt to modify files outside of this directory can prevent the PolicyCenter application from starting.

Working with dot notation

Many places within PolicyCenter require knowledge of fields within the application data model, especially while you configure PolicyCenter. For example, code in a business rule, class or enhancement may need to check the owner of an assignable object. As an alternative, code may need to check the date and time of object creation. PolicyCenter provides an easy and consistent method of referring to fields within the data model, using relative references based on a root object.

A root object is the starting point for any field reference. If you run Gosu submission rules on a policy for example, the policy is the root object and you can access anything that relates to this policy. On the other hand, if you run Gosu assignment code for an activity, the activity is the root object. In this case, you have access to fields that relate to the activity, including the User associated with the activity.

Guidewire applications use dot notation for relative references. For example, assume that your code has Account as the root object. For a simple reference to a field on the account such as AccountNumber, use: 
account.AccountNumber
However, suppose that you want to reference a field on an entity that relates to the account, such as a policy expiration date. You must first describe the path from the account to the policy, then describe the path from the policy to the policy expiration date: 
account.Policy.ExpirationDate