Best Practices Guide
Best Practices Guide
Contents
3
Guidewire PolicyCenter 9.0.6 Best Practices Guide
4
Guidewire PolicyCenter 9.0.6 Best Practices Guide
5
Guidewire PolicyCenter 9.0.6 Best Practices Guide
6
Guidewire PolicyCenter 9.0.6 Best Practices Guide
Document Purpose
InsuranceSuite Guide If you are new to Guidewire InsuranceSuite applications, read the InsuranceSuite Guide for informa‐
tion on the architecture of Guidewire InsuranceSuite and application integrations. The intended read‐
ers are everyone who works with Guidewire applications.
Application Guide If you are new to PolicyCenter or want to understand a feature, read the Application Guide. This guide
describes features from a business perspective and provides links to other books as needed. The in‐
tended readers are everyone who works with PolicyCenter.
Database Upgrade Guide Describes the overall PolicyCenter upgrade process, and describes how to upgrade your PolicyCenter
database from a previous major version. The intended readers are system administrators and imple‐
mentation engineers who must merge base application changes into existing PolicyCenter application
extensions and integrations.
Configuration Upgrade Guide Describes the overall PolicyCenter upgrade process, and describes how to upgrade your PolicyCenter
configuration from a previous major version. The intended readers are system administrators and im‐
plementation engineers who must merge base application changes into existing PolicyCenter applica‐
tion extensions and integrations. The Configuration Upgrade Guide is published with the Upgrade
Tools and is available from the Guidewire Community.
New and Changed Guide Describes new features and changes from prior PolicyCenter versions. Intended readers are business
users and system administrators who want an overview of new features and changes to features. Con‐
sult the “Release Notes Archive” part of this document for changes in prior maintenance releases.
Installation Guide Describes how to install PolicyCenter. The intended readers are everyone who installs the application
for development or for production.
System Administration Guide Describes how to manage a PolicyCenter system. The intended readers are system administrators re‐
sponsible for managing security, backups, logging, importing user data, or application monitoring.
Configuration Guide The primary reference for configuring initial implementation, data model extensions, and user inter‐
face (PCF) files for PolicyCenter. The intended readers are all IT staff and configuration engineers.
PCF Reference Guide Describes PolicyCenter PCF widgets and attributes. The intended readers are configuration engineers.
Data Dictionary Describes the PolicyCenter data model, including configuration extensions. The dictionary can be gen‐
erated at any time to reflect the current PolicyCenter configuration. The intended readers are configu‐
ration engineers.
Security Dictionary Describes all security permissions, roles, and the relationships among them. The dictionary can be
generated at any time to reflect the current PolicyCenter configuration. The intended readers are con‐
figuration engineers.
Globalization Guide Describes how to configure PolicyCenter for a global environment. Covers globalization topics such as
global regions, languages, date and number formats, names, currencies, addresses, and phone num‐
bers. The intended readers are configuration engineers who localize PolicyCenter.
Rules Guide Describes business rule methodology and the rule sets in Guidewire Studio for PolicyCenter. The in‐
tended readers are business analysts who define business processes, as well as programmers who
write business rules in Gosu.
Contact Management Guide Describes how to configure Guidewire InsuranceSuite applications to integrate with ContactManager
and how to manage client and vendor contacts in a single system of record. The intended readers are
PolicyCenter implementation engineers and ContactManager administrators.
Document Purpose
Best Practices Guide A reference of recommended design patterns for data model extensions, user interface, business
rules, and Gosu programming. The intended readers are configuration engineers.
Integration Guide Describes the integration architecture, concepts, and procedures for integrating PolicyCenter with ex‐
ternal systems and extending application behavior with custom programming code. The intended
readers are system architects and the integration programmers who write web services code or plu‐
gin code in Gosu or Java.
Java API Reference Javadoc‐style reference of PolicyCenter Java plugin interfaces, entity fields, and other utility classes.
The intended readers are system architects and integration programmers.
Gosu Reference Guide Describes the Gosu programming language. The intended readers are anyone who uses the Gosu lan‐
guage, including for rules and PCF configuration.
Gosu API Reference Javadoc‐style reference of PolicyCenter Gosu classes and properties. The reference can be generated
at any time to reflect the current PolicyCenter configuration. The intended readers are configuration
engineers, system architects, and integration programmers.
Glossary Defines industry terminology and technical terms in Guidewire documentation. The intended readers
are everyone who works with Guidewire applications.
Product Model Guide Describes the PolicyCenter product model. The intended readers are business analysts and implemen‐
tation engineers who use PolicyCenter or Product Designer. To customize the product model, see the
Product Designer Guide.
Product Designer Guide Describes how to use Product Designer to configure lines of business. The intended readers are busi‐
ness analysts and implementation engineers who customize the product model and design new lines
of business.
narrow bold The name of a user interface element, such Click Submit.
as a button name, a menu item name, or a
tab name.
monospace Code examples, computer output, class and The getName method of the IDoStuff API returns the name of the
method names, URLs, parameter names, object.
string literals, and other objects that might
appear in programming code.
monospace italic Variable placeholder text within code Run the startServer server_name command.
examples, command examples, file paths, Navigate to http://server_name/index.html.
and URLs.
Support
For assistance, visit the Guidewire Community.
8 About PolicyCenter documentation
Guidewire PolicyCenter 9.0.6 Best Practices Guide
Guidewire customers
https://community.guidewire.com
Guidewire partners
https://partner.guidewire.com
The PolicyCenter data model comprises metadata definitions of data entities that persist in the PolicyCenter
application database. Metadata definition files let you define the tables, columns, and indexes in the relational
database that supports your application. Typelist definitions let you define sets of allowed codes for specific typekey
fields on entities.
See also
• Configuration Guide
cases, use Contact Address and All Escalated Activities Claim Metric as respective displayName attribute
names. The graphical user interface uses the displayName attribute name when displaying the corresponding entity.
<extension entityName="Policy">
...
<column desc="Description of the column"
name="MyCustomColumn_Ext"
nullok="true"
default="abc"
type="varchar"
<columnParam
name="size"
value="60" />
</column>
<foreignkey
columnName="PolicyID"
...
name="Policy"/>
Adding the suffix ID to the column names of foreign keys helps database administrators identify columns in the
database that Guidewire uses as foreign keys.
12 chapter 1: Data Model Best Practices
Guidewire PolicyCenter 9.0.6 Best Practices Guide
If you add a foreign key as an extension to a base entity, follow the best practice of adding a prefix or suffix to the
name. For example:
<foreignkey
columnName="Policy_ExtID"
...
name="Policy_Ext"/>
See also
• Configuration Guide
Name Each word in a name begins with a capital letter. Spaces separate words. Approval Pending
PolicyCenter uses page configuration format (PCF) files to render the PolicyCenter application. PCF files contain
metadata definitions of the navigation, visual components, and data sources of the user interface. Display keys
provide the static text that visual components of the user interface display.
See also
• Configuration Guide
See also
• Configuration Guide
• Globalization Guide
ContactDetail
PolicyCenter represents display keys in a hierarchical name space. A period (.) separates display key names in the
paths of the display key hierarchy. For example:
Validation.Contact.ContactDetail
Generally, you specify text values for display key names that are leaves on the display keys resource tree. Generally,
you do not specify text values for display key names that are parts of the path to a leaf display key. In the preceding
example, the display keys Validation and Validation.Contact have no text values, because they are parts of a
display key path. The display key ContactDetail has a text value, “Contact Detail”, because it is a leaf display key
with no child display keys beyond it.
Validation.Contact.ContactDetail
Validation.Contact.NewContact
You want to add a display key for the text “Delete Contact”. Add a new display key named DeleteContact_Ext.
Validation.Contact.ContactDetail
Validation.Contact.DeleteContact_Ext
Validation.Contact.NewContact
You can change the text for base display keys to change the text that the base configuration of the application
displays. Guidewire recommends that you use the base configuration display keys for this purpose so the base
configuration PCF files can just make use of the new values. If you add display keys with the suffix _Ext with the
intention of using them in the base configuration, the base configuration PCF files must be altered to use them.
16 chapter 2: User Interface Best Practices
Guidewire PolicyCenter 9.0.6 Best Practices Guide
LV.Activity.Activities.DueDate
RangeInput
...
valueRange |policyPeriod.Policy.Product.AllowedPolicyTerms
If a page with this range input widget has any postOnChange fields, PolicyCenter potentially evaluates the
expression multiple times for each postOnChange edit that a user makes.
Input: myInput
...
value |someExpensiveMethod()
The following modified sample code improves performance. It assigns a performance intensive expression to a page
variable and assigns the variable to the widget value.
Variables
...
initialValue |someExpensiveMethod()
name |expensiveResult
--------------------------------
Input: myInput
...
value |expensiveResult
Input: myInput
...
id |myInput
...
visible |activity.someExpensiveMethod()
The following modified sample code improves performance. It assigns a performance intensive expression to a page
variable. PolicyCenter evaluates page variables only once before it displays a page, regardless how many contexts
under which it evaluates widget properties on the page.
Variables
...
initialValue |activity.someExpensiveMethod()
name |expensiveResult
--------------------------------
Input: myInput
...
id |myInput
...
visible |expensiveResult
perm.PolicyPeriod.renew(aPolicy)
Application permission keys evaluate the current user against general system permissions and the access control lists
of specific entity instances.
See also
• System Administration Guide
PolicyCenter rules comprise hierarchies of conditions and actions that implement complex business logic. As a best
practice, Guidewire recommends that you edit rules by using the Rules editor in Guidewire Studio.
See also
• Rules Guide
Identifier- Description
IMPORTANT PolicyCenter truncates Identifier values that exceed eight characters if you include
the actions.ShortRuleName property in rule actions to display rule names in messages that you
log or display. PolicyCenter also truncates Identifier values that exceed eight characters in
automatic log messages if you enable the RuleExecution logging category and set the server run
mode to Debug.
• Begin Identifier with up to four capital letters to identify the rule set or parent rule of which the rule is a
member.
• End Identifier with at least four numerals to identify the ordinal position of the rule within the hierarchy of
rules in the set.
• For Description values, keep them simple, short, and consistent in their conventions.
• Limit the total length of rule name to 60 characters.
For example:
The rule set contains four root rules, with identifiers CV001000, CV002000, CV003000, and CV004000. The numbers
at the end of the identifiers, 1000, 2000, 3000 and 4000, are units of one thousand. This spread of numbers lets you
add new root rules between existing ones without renumbering. You want identifier numbers for rules in a set to
remain in sequential order to mimic the order of rules within the fully expanded set.
For example, you want to add a rule between CV002000 and CV003000. Assign the new rule the identifier CV002500.
CV103900 - Default
CV004000 - Expected recovery exceeds 100
The spread of numbers for child rules of a root parent rule generally are units of one hundred. This spread of
numbers lets you add new child rules between existing ones without renumbering. Most importantly, the numbers of
child rules must fall between the numbers of their parent rule and the sibling rule that follows their parent. In this
example, the numbers for child rules satisfy both conventions.
The parent and child naming convention applies to another, third level of children. For example, you want to add
two new child rules to the rule CVI03100 - Workmens’s Compensation. Begin the child identifiers with CVIW, a
code to identify “Claim Validation Injury Workmen’s Compensation” rules. At the third level of a rule set hierarchy,
the spread of numbers for the child rules generally are units of ten.
modules/configuration/config/rules
• The depth of the hierarchy of rule categories, rule sets, rules, and parent/child rules
• The length of individual rule names
In addition, you must add four characters to the path for the name of each rule category, rule set, and parent rule.
Rules Best Practices 23
Guidewire PolicyCenter 9.0.6 Best Practices Guide
You must understand the file system implications of rule names. Windows file systems have a file path limit of 255
characters. To avoid exceeding the limit, Guidewire recommends that you do the following:
• Avoid a long path to your Guidewire installation directory.
• Avoid deep hierarchies of rule set categories.
• Avoid hierarchies of parent and child rules within a rule set deeper than three levels.
• Avoid long names for rule set categories, rule sets, and rules.
Rule Actions:
producerCode.rejectField("ProducerCodeRoles", null, null, "loadsave",
"A role is required for producer code" + producerCode.Code + "."
)
As written, the rejection message that the rule action displays makes it difficult to determine exactly which rule
caused an update to fail. To help identify the specific rule in the rejection message, use the
actions.getRule().DisplayName property to include the identifier portion of the rule name in the message.
Rule Actions:
producerCode.rejectField("ProducerCodeRoles", null, null, "loadsave",
"A role is required for producer code " + producerCode.Code +
". Rule: " + actions.getRule().DisplayName.substring(8)
)
By including the rule display name in the rule action, users see the following statement in the Validation window
when the rule action executes.
Note: In actual practice, Guidewire recommends that you make all String values into display keys.
Gosu is a general-purpose programming language built on top of the Java Virtual Machine. PolicyCenter uses Gosu
as its common programming language.
See also
• Gosu Reference Guide
var amount = 125.00 // use an initialization value to set the type for a variable
var string = new java.lang.String("") // initialize to the empty string instead of null
private var _firstName : String as FirstName // Delcare a public property as a private variable.
Avoid declaring public variables, as the following sample Gosu code does.
See also
• Gosu Reference Guide
class VinIdentifier {
static var myVector = new Vector() // All sessions share this static variable.
if policy.suspend() {
// Do something to suspend the policy.
}
Some entity and typelist APIs are case insensitive if they take String values for the name of an entity, a property, or
a typecode. However, it is best write your code as if they are case sensitive.
Gosu Language Best Practices 29
Guidewire PolicyCenter 9.0.6 Best Practices Guide
See also
• Gosu Reference Guide
Comment Placement
As a commenting best practice, always place block comments before every class and method that you write. Briefly
describe the class or method in the block comment. For comments that you place within methods, use any of the
commenting styles to help clarify the logic of your code.
Block Comments
Block comments provide descriptions of libraries and functions. A block comment begins with a slash followed by
an asterisk (/*). A block comment ends with an asterisk followed by a slash (*/). To improve readability, place an
asterisk (*) at the beginnings of new lines within a block comment.
/*
* This is a block comment.
* Use block comments at the beginnings of files and before
* classes and functions.
*/
Place block comments at the beginnings of files, classes, and functions. Optionally, place block comments within
methods. Indent block comments within functions to the same level as the code that they describe.
Javadoc Comments
Javadoc comments provide descriptions of classes and methods. A Javadoc comment begins with a slash followed
by two asterisks (/**). A Javadoc comment ends with a single asterisk followed by a slash (*/).
/**
* Describe method here--what it does and who calls it.
* How to Call: provide an example of how to call this method
* @param parameter description (for methods only)
* @return return description (for methods only)
* @see reference to any other methods,
* the convention is
* <class-name>#<method-name>
*/
Block comments that you format using Javadoc conventions allow automated Javadoc generation.
Single‐line Comments
Single-line comments provide descriptions of one or more statements within a function or method. A single-line
comment begins with double slashes (//) as the first two characters two non-whitepsace characters on a line.
...
}
If you cannot fit your comment on a single line, use a block comment, instead.
Trailing Comments
Trailing comments provide very brief descriptions about specific lines of code. A trailing comment begins with
double slashes (//) following the code that the comment describes. Separate the double slashes from the code with
at least two spaces.
if (a == 2) {
return true // Desired value of ’a’
}
else {
return false // Unwanted value of ’a’
}
If you place two or more trailing comments on lines in a block of code, indent them all to a common alignment.
/*
The dividing line starts a nested block comment and causes an unclosed comment compiler error.
//********************************************************************************************
*/
In the preceding example, compilation fails due to an unclosed comment. The following example avoids compilation
errors by inserting a space between the slash and the first asterisk.
/*
The dividing line does not start a nested block comment and causes no compiler error.
// **********************************************************************************
*/
( ( a + b ) / ( c - d ) ) // improper form
Example
In the following example, the two expressions produce the same results, but the first expression uses parentheses to
make the standard operator order clear:
value = rate + limit * 10.5 + deductible / autoGrade - 15 // same result, but poor form
Example
In the following example, using parentheses in the second Boolean expression ensures that it is read correctly:
32 chapter 4: Gosu Language Best Practices
Guidewire PolicyCenter 9.0.6 Best Practices Guide
if(premium <= 1000) { // Put opening curly brace on line that starts the block.
print("The premium is " + premium) // Surround even single-line blocks with curly braces.
} // Put closing curly brace on line after last statement.
Also, check variables for null before you call methods on variables:
Consider the following issues if you do not check variables for null:
• Accessing a property on a variable may use null-safe property access, which can cause null pointer exceptions in
later code that handles only non-null values.
• Calling a method on a variable risks a null pointer exception.
return aPerson.PrimaryAddress?.hashCode()
}
The following sample Gosu code uses the explicit null-safe operator ?[] to check for null to avoid a null pointer
exception while accessing an array. If strings[] is null, the entire expression strings?[index] evaluates to
null. However, the null-safe operator does not avoid out-of-bounds exceptions if strings[] is non-null and the
value of index exceeds the array length. For example, if the array is empty rather than null, an out-of-bounds
exception occurs.
See also
Gosu requires semicolons only if you place multiple statements on a single line. As a best practice, Guidewire
generally recommends against placing multiple statements on a single line. Exceptions include simple statement lists
declared in-line within Gosu blocks.
As a best practice, Guidewire recommends that you rewrite your Gosu code with comparison operators instead of
equals methods to make your code type safe and easier to read.
1 == "1"
Gosu implicitly coerces "1" to an integer value of 1, without explicit casting. Implicit coercion is convenient and
powerful, but it can cause unexpected results if used without caution.
Gosu Language Best Practices 35
Guidewire PolicyCenter 9.0.6 Best Practices Guide
Gosu produces compiler warnings for implicit coercions. As a best practice, Guidewire recommends that you take
these warnings seriously. If you want the coercion, explicitly cast the operand on the right by using an as Type
expression. If you do not want the coercion, rewrite your code to avoid the implicit coercion.
For example, the following expression compares a date value to a string representation of a date value.
(dateValue == "2011-11-15")
Because Gosu coerces of the string "2011-11-15" to a date, rewrite the code with an explicit type cast.
The following sample Gosu code follows the pattern and declares a variable as an Object. The if condition
downcasts the variable to its more specific subtype, String.
Because Gosu propagates the downcasting from the if condition into the if code block, the expression x.length is
valid. The length property is on String, not Object.
The following sample Gosu code is equivalent to the preceding example, but it redundantly casts the variable as a
String within the if code block.
See also
• Gosu Reference Guide
for (i in 1..10) {
if (i == 4) {
break // Break out of the loop on the fourth iteration.
}
The number is 1
The number is 2
The number is 3
Stopped printing numbers
Notice that the loop stops executing on the fourth iteration, when i equals 4.
Use a continue statement to Continue Immediately with the Next Loop Iteration
The continue statement stops execution of the current iteration, and the loop continues with its next iteration.
The following sample Gosu code interrupts the fourth iteration, when i equals 4, but the loop continues executing
through all remaining iterations.
for (i in 1..10) {
if (i == 4) {
continue // End the fourth iteration here.
}
The number is 1
The number is 2
The number is 3
The number is 5
The number is 6
The number is 7
The number is 8
The number is 9
The number is 10
Notice that the loop continues through all nine iterations, but it interrupts the fourth iteration, when i equals 4.
for (x in 5) {
if (x == 3) {
threeFound = threeFound + 1 // The loop keeps iterating after third one is found.
}
return threeFound >= 1 // The function returns long after third one is found.
}
The following modified sample code is more efficient. The function returns a result as soon as it detects the
affirmative condition.
return false
}
See also
• Gosu Reference Guide
IMPORTANT If you intend to do time-based testing, any dates affected by your implementation of the
ITestingClock plugin must use the DateUtil utility functions.
See also
• Integration Guide
Concatenation (+) on a variable with a literal Slower var aString : String = "Test"
aString = aString + " Test"
Concatenation (+) on a variable with a variable Slowest var aString : String = "Test"
var anotherString : String = " Test"
aString = aString + anotherString
and proceed from left to right until a condition fails. Runtime evaluation of compound expressions that use or
proceed from left to right until a condition succeeds. The order in which you place individual conditions can
improve or degrade evaluation performance of compound expressions.
For example, you have a condition that you expect to fail 99% of the time, with an estimated performance cost of
10,000 per evaluation. You have another condition that you expect to fail only 1% of the time, with an estimated
performance cost of 100 per evaluation. According to the formula, place the second condition earliest because it has
the lowest score.
You rarely have accurate figures for the failure percentages or performance costs of specific condition. Use the
formula to develop an educated guess about which condition to place earliest. In general, give preference to less
performance intensive condition. If the performance costs are roughly equal, give preference to condition with a
higher percentage of likely failures.
The following modified sample code improves performance. It calls a performance intensive method once and saves
the value in a local variable. It then uses the variable twice to test which value the method returns.
for (x in 5) {
if (x == 3 and period.Active) { // Evaulate a constant expression redunantly within a loop.
print("x == 3 on active period")
}
In the preceding example, Gosu evaluates the expression period.Active at least twice unnecessarily. The following
modified sample code improves performance.
}
}
}
duplicate value: 3
duplicate value: 3
The following sample Gosu code is a better solution. The code is more efficient because it loops through the array
once only. It produces appropriate results because it reports the duplicate value once only.
duplicate value: 3
computeA()
computeB()
computeC()
}
function computeA() {
var expensiveResult = expensiveCall() // Make the expensive call once.
//do A stuff on expensiveResult
}
function computeB() {
var expensiveResult = expensiveCall() // Make the same expensive call twice.
//do B stuff on expensiveResult
}
function computeC() {
var expensiveResult = expensiveCall() // Make the same expensive call three times.
//do C stuff on expensiveResult
}
The following modified sample code improves performance. It pulls the expensive method call up to the main
routine, which calls it once. Then, it passes the cached result down to the lower-level routines, as a context variable.
computeA(expensiveResult)
computeB(expensiveResult)
computeC(expensiveResult)
}
Most likely this was not what the developer intended. Determine the most efficient means of acquiring just the data
that you need. For example, rewrite the preceding example to use a query builder expression that fetches a more
focused set of addresses from the application database.
See also
• Gosu Reference Guide
Accessing the entity array does not incidentally query the relational database. The application database caches them
whenever it loads a parent entity from the relational database.
Calling a Finder method does incidentally query the relational database. However, the application database does not
cache finder arrays. Only your code keeps the array in memory.
To avoid repeated, redundant calls that incidentally query the database, Guidewire recommends as a best practice
that you cache the results once in a local array variable. Then, pass the local array variable to lower level routines to
operate on the same results. This design approach is an example of pulling up.
See also
• “Pull Up Multiple Performance Intensive Method Calls” on page 42
The following sample Gosu code suffers a performance problem. It inadvertently loads most of the claims, along
with their policies, from the relational database. Then, the code iterates the loaded claims and their policies and
process only those few that match a specific policy. In other words, the code loads an excessive amount of data
unnecessarily and takes an excessive amount of time to search for a few instances to process.
The following modified sample Gosu code improves performance. It finds only relevant policies to process with the
compare method:
The following sample Gosu code queries the database for addresses in the city of Chicago by using a compare
method on the query object. The select object returns only Chicago addresses from the database. The database
executes the query at the time the code calls the iterator method.
uses gw.api.database.Query
for (address in resultIterator) { // Iterate the the qualifying addresses in result object.
print (address.AddressLine1 + ", " + address.City + ", " + address.PostalCode)
The preceding sample code performs efficiently, because the database selects the Chicago addresses. The sample
code also uses the application cache efficiently, because it loads only the Chicago addresses into application
memory.
44 chapter 4: Gosu Language Best Practices
Guidewire PolicyCenter 9.0.6 Best Practices Guide
uses gw.api.database.Query
for (address in resultContainer ) { // Iterate the second container with the qualifying addresses.
print (address.AddressLine1 + ", " + address.City + ", " + address.PostalCode)
Returning all addresses to the application uses the cache inefficiently by loading it with unwanted addresses.
Converting the result to a collection uses the application heap inefficiently by loading the collection with unwanted
addressees. Calling the where method on the collection to select only addresses in Chicago performs the selection
much less efficiently than the database.
IMPORTANT Guidewire recommends the query builder APIs instead of find expressions to fetch items
from the application database whenever possible, especially for new code. For more information, see
the Gosu Reference Guide.
Use Empty Properties If You Want to Know Whether Anything Was Found
If you want to know only whether a result or query object fetched anything from the application database, use the
Empty property instead of the Count property. The value of the Empty property returns to your Gosu code faster,
because the evaluation stops as soon as it counts at least one fetched item. In contrast, the value of the Count
property returns to your Gosu only after counting all fetched items.
The following sample Gosu code uses the Count property on a query builder API result object.
uses gw.api.database.Query
The following sample Gosu code uses the Count property on a find expression query object.
uses gw.api.database.Query
The following sample Gosu code uses the Count property on a find expression query object.
The following sample Gosu code improves performance by comparing Activity.Pattern.Code with an activity
pattern code in the conditional expression.
Never localize activity pattern codes. These codes are intended for use in Gosu expressions, not for display in error
messages of the application user interface.
See also
• Globalization Guide
content. The original template could contain code that calls the other three templates. This design practice prevents
bumping up against the size limit. Additionally, this style produces more readable and more manageable code.
See also
• Gosu Reference Guide
An upgrade of your PolicyCenter installation comprises automated and manual procedures. The ways in which your
configure your PolicyCenter installation and the methods you use during an upgrade help determine the ease or
difficulty of the procedures for future upgrades.
See also
• Upgrade Guide
If the file changes in a future release, you will notice that the file was copied. You then can decide whether to
replicate the changes in the new file in your copy of the base version of the file. Especially if the change enhances
the base file or fixes a defect, you may want to apply the same changes to your copy of the file.
To confirm that you changed all existing code to use your copied function, temporarily rename the original function
and then compile your entire project to check for compilation errors. After you remove all calls to the original
function, consider commenting out the original function to prevent developers in the future from using it
accidentally.
If the function changes in a future release, you will notice that the function was copied. You then can decide whether
to replicate the changes in your copy of the base function. Especially if the change enhances the function or fixes a
defect, you may want to apply the same changes to your copy of the function.
Procedure
1. Rename the base file or function by including the customer identifier.
For example, make a copy of SomeBaseScreenDV.pcf and give it the name SomeBaseScreen_ExtDV.pcf.
2. Restore the original base file from base.zip or from your source code repository.
3. Add a comment to the top of the restored base file or function to state that the file or function was copied.
For example:
4. Make your additional major changes to the copy of the file or function.
Guidewire Rating Management provides a set of tools to manage and maintain rating in PolicyCenter. Guidewire
recommends a number of best practices for Rating Management.
See also
• Application Guide
• Configuration Guide
Package Name
Descriptive Name
Rate Books
For DescriptiveName:
• If you have multiple rate books per policy line, then add underwriting company, jurisdiction, or offering codes to
differentiate the books.
• It is not necessary to append the words book or rate book.
Rate Routine
Append _rr to easily identify rate routine codes as distinct from rate table codes.
For DescriptiveName:
• For a rate routine that calculates premium for a specific coverage, use the coverage code.
For example, a rate routine that calculates premium for Comprehensive coverage (PAComprehensiveCov is the
code) on a Personal Auto policy can be named: PAComprehensiveCov_rr.
• If a coverage has different rate routines that calculate premium for different types of risks, append the risk type to
the rate routine names. To use fewer characters, you can abbreviate the risk type.
For example, a rate routine that calculates premium for Collision coverage for occasional drivers (abbreviate to
OD) in a Personal Auto policy can be named: PACollisionOD_rr. The default rate routine for Collision coverage
can be named: PACollision_rr.
• If a rate routine applies to multiple coverages, then create a descriptive name. The name can be based on the
covered object. Add the word Coverages at the end.
For example, a rate routine that calculates premium for certain coverages with a covered object of
PersonalVehicle can be named: PAPersonalVehicleCoverages_rr.
Rate Table
In DescriptiveName, do not include the word table. When doing a rate table lookup in a rate routine, PolicyCenter
displays table: before the name.
Rate tables do not have a version field. However, you can copy a rate table and create the equivalent of a new
version by including a version number in the name and code.
If you plan on versioning, then use a versioning identifier as a suffix. This can be a version number or additional
information that helps you identify the version, such as _v2 or _ISO2015. You can choose to add a version number
beginning with the second version.
For example:
• A series of numbers starting at 1 to be consistent with other Rating Management numbering schemes, such as
rate routine versions.
• Date in YYYMMDD format such as 20130101.
• Filing identifier such as CA-2012-39A.