Lecture #1 : Data Model

DATA MODEL :
●​ A set of XML- Formatted metadata definitions of entities and type lists. (simply set
of entities & type lists)
●​ It is the core for all guidewire applications. Understanding the structure of data
model is critical to make successful modifications to guidewire applications

●​ Data model is loaded on start up of all GW Applications

●​ As part of application start up, the loaded metadata instantiates the data model as
a collection of tables in the application database.

●​ Entities defined in the data model map to Tables and Fields map to database
columns, except for arrays and virtual properties

●​ GW generates Java and Gosu classes in the application server for programmatic interface to
Entities and Typelists.
ENTITIES :
●​ Entities represent real business objects such as Invoice, Claim, Person, Policy, Account.
●​ Entities serve as root objects for any UI, Gosu rules and other data related items.

●​ An Entity defines a set of fields that store Information.

●​ There are two types of columns used in GW model configuration,

○​ Data columns and Relationship columns

●​ 1)Data column types → data type defines the type of data stored in that column . examples-
varchar, integer, datetime, bit
●​ 2)Relationship columns are used to define relationships between entities.

○​ a) Foreign key links a single instance of one entity to another, such as primary address
to contact

○​ b) Array links multiple instances of one entity to another. All addresses related to a
contact

○​ c) Type key associates one value from a typelist with a column in another entity.
Sub Type:
●​ Provide a way of dividing a general entity type into several related entity types. It helps you
create entity hierarchies for adding different information at each entity level
●​ Info common to all types is stored at supertype level and information specific to subtype is
stored at Subtype level.

●​ Subtype will only have only one supertype. To create a subtype entity the supertype should not
be final.

Here the abstract is true for [Link], so subtypes can be created.

Here the ExposureRule abstract is false. So subtype cannot be created for ExposureRule
●​ All fields in the parent entity are inherited by the child entity. Methods also are inherited from
subtype

●​ Top level entity (abstract). Abstract entities cannot be instantiated but can be subtyped.

i.e., You cannot create instances of top level entities, but can create instances of its Subtypes if
abstract is false

●​ Lets say person and company store info about person and company. Common fields can be
supertyped to a supertype entity contact.
 ●​ Now we can move TaxID and Email to Contact and make Person and Company as subtypes of
Contact.

Super type entity table contains subtype columns in denormalized form

Subtypes will also generate java classes. You cannot subtype from multiple supertypes

Lecture #2 : Linking Entities

●​ There are multiple types of relationships in the Guidewire data model.

○​ a) foreign key b) Array c) one-one d) many many e) circular

a) Foreign key: A foreign key is a field or collection of fields in one table that refers to the
primary key in the other table.
 ●​ Here ClaimantDenorm in Claim is the Foreign key and ID is the primary key of
contact.

●​ Foreign keys are non-nullable.

b) Arrays: Keep in mind that Arrays are maintained in code, and are not stored. The code
assembles the array when needed by executing queries against the database.

●​ Each member should have a foreign key to the parent.

●​ The name of the Foreign key must match the name of the parent entity. Here it is
the claim.

​
c) ONE-ONE Relationship: One-One splits a logical entity across multiple physical entities​
c)Many-Many Relationship: To add many many relationships between entities create a
separate versionable entity that represents the many-many relationship.

●​ versionable entities have a version and ID field and can be deleted as opposed to
retirable entities which can never be deleted.

●​ Create foreign keys to each entity in the many-many relationship

●​ Next, add the unique indexes, consisting of foreign keys, so that duplicate rows can
not be added. to the table.

●​ To access the many-many relationship, add an array to one or both entities

 ●​ Roles array specifies that there are O or more user roles for a given user.

●​ Users array in Role specifies that there are 0 or more Users for a given role.

●​ Both related entities do not necessarily have an array.

d) Circular Relationship: In some cases an entity needs to refer to itself

●​ GW data model does not let an entity refer to itself, or two or more entities
reference one another in a circular manner using only foreign keys. To solve this GW
recommends to use edge foreign keys.

●​ EDGE FOREIGN KEY : An edge foreign key from A to B introduces a new hidden
entity that has foreign key to A and a foreign key to B. However it does not create
any direct foreign key from A to B

●​ GW can safely commit the A objects first then B objects and then finally the hidden
A/B edge foreign key entity objects.

●​ The same principal is true for two or more entities that reference one another in a
circular fashion

●​ Edge Foreign Key ensures safe ordering of data insertion and deletion. Usually
needed if we want to commit some data in the entity first and then the remaining
data. i.e., all data is not expected to be committed at the same time.

Self reference
Edge foreign key to other entity
One entity having both self reference edge foreign key and other entity edge foreign key
Lecture #3 : Data Model File Structure
a)BASE APPLICATION ENTITIES:
●​ Base application entities are defined in .eti files
○​ Example : [Link]
○​ Available in modules/configuration/config/metadata/entity.
○​ All the files in metadata/entity are read only.
○​ Many platform entities have platform = "true" attribute
●​ Many application entities can be subtyped and also entity extensions can be
created.
●​ Entity with final="true" attribute cannot be subtyped and Entity with extendable=
"false" cannot be extended.
●​ Platform entities are common to all GW applications([Link],[Link]) and
Applications entities are specific to application([Link],[Link]).
b)CUSTOM ENTITIES :
●​ They are found in modules/configuration/config/extensions/entity folder.
●​ They will have a .eti file type like GW base entities. To ensure upgrade safety, always
name the entities with the suffix "_Ext” .
○​ Example : Testing_Ext.eti
●​ A custom entity is the entity created by customers. And fields are not required to
have “_Ext” suffix.
●​ Custom entities cannot be extended.

c)ENTITY EXTENSIONS:
●​ Adding new fields to the base application entities can be done by entity extension.
●​ They are found in modules/configuration/config/extensions/entity folder.
●​ Entity extension will have the same name as base application entity but will have
.etx file
●​ It is recommended to add suffix “_Ext” to the new fields in the entity extension
 ●​ A base application entity can have at most one ETX File.

●​ Entity extensions allow customers also to override certain attributes of base

application entity fields.

d)INTERNAL ENTITY EXTENSION :

●​ EIX files contain extensions to the platform level entities. that are required for the
base application and cannot be modified.
●​ EIX File is read only and present in modules/configuration/config/metadata/entity.
●​ They are basically created by GW for base application purposes.
●​ Here [Link] is platform level internal extension and [Link] is base
application entity. Both are read only

● TYPELIST :
●​ Typelists are mainly used for drop down values from a set of values. Each value
from the set of values is called typecode.
●​ Base application typelists are read only and are defined in .tti files.
●​ Typelist extension allows customers to safely add new Typecedes to base
application typelists.
●​ Typelist extension is defined in .TTX files and newly added typecodes should end
with "_Ext".

○​ Internal typelist extension -> .tix(configuration/config/extensions/typelist)

○​ Base Typelists - .tti (configuration/config/metadata/typelist)
○​ Custom typelists -> .tti (configuration/config/extensions/typelist)
○​ Typelist extensions -> .ttx (configuration/config/extensions/typelist)

●​ Typecodes are stored as foreign key columns in the entity table

●​ Typecode after code generation become static final variables in the class
●​ Typelist does not allow display key properties, we use the localization button during
typelist creation.

●​ Database table name for customtype_ext.tti will be cctl_CustomType_Ext

●​ Type Filters : It makes the typelist to display only a subset of typecodes

A typekey field can reference utmost one typefilter from associated typelist
Lecture #4 : Data Model Configuration
●​ The physical database table includes fields from base entity and extended entity.

●​ All these are also available in the generated Java class and present in the
Application server.
●​ When a GW application requires access to an entity in the database, an instance of
java class is created. The generated java class reads data from database in to the
instance and changes made to data in turn saved to database
Extra Notes :
●​ Columnparam is used for column special parameters.
○​ name: size, validates, encryption, trimwhitespaces, precision etc
○​ Value = ….

●​ Use the base product data types shorttest, mediumtext and longtext instead of
varchar.
●​ Use the type varchar(xx) for string data when a fixed width is required by an
external system.
●​ Each new entity (custom) created in the studio has a corresponding physical table
that is generated in the database on server startup.
●​ The name of physical table a is similar to the entity and includes a prefix matching
the two character application code and ends with ‘X’ for custom entity .
○​ Ex - trainer_ext.eti -> ccx_trainer_ext
○​ [Link], [Link] -> cc_claim
●​ Subtype entities are child entities of super type entities and all fields in the super
type are inherited by the child entity and fields from all the subtype and super type
are stored in a single table.
 ●​ Entity type :
○​ Versionable -> Keeps history
○​ Retirable -> Entity can be both logically and physically deleted.
●​ If the entity is final, you can subtype the entity

Entity Extension Entity Subtype

Used to add fields to an existing entity Create a version of entity that can have its
without changing its fundamental purpose own attributes and business logic

Can have only one extension to an entity Can have multiple subtypes to an entity

[Link] -> [Link] [Link] -> [Link],

[Link],[Link]