Guidewire PolicyCenter™

Configuration Guide
Release 9.0.9
©2020 Guidewire Software, Inc.
For information about Guidewire trademarks, visit [Link]
Guidewire Proprietary & Confidential — DO NOT DISTRIBUTE

Product Name: Guidewire PolicyCenter

Product Release: 9.0.9
Document Name: Configuration Guide
Document Revision: 30-May-2020
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Contents

About PolicyCenter documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29

Conventions in this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31

Part 1
PolicyCenter configuration basics
1 Overview of PolicyCenter configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
What you can configure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
Guidewire internal methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
How you configure PolicyCenter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
Types of application environments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
The development environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
The production environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
Deploying configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
Deploying changes in a development environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
Deploying changes to the production server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
Regenerating the data and security dictionaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
Generating the data and security dictionaries in HTML format. . . . . . . . . . . . . . . . . . . . . . . . . . .39
Generating the data and security dictionaries in XML format . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
Generating the security dictionary from PolicyCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40
Generating the dictionaries as you generate a .war or .ear file. . . . . . . . . . . . . . . . . . . . . . . . . . . .40
Aspects of regenerating the Security Dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40
Managing configuration changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40

2 Application configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41

Working with configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
Adding custom parameters to PolicyCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
Configuration parameter behaviors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
View configuration parameters on a running server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
Access configuration parameters in Gosu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
Adding custom MIME types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
Account parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
AccountsWithdrawnAfterMonths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
Archive parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
ArchiveDaysRetrievedBeforeArchive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
ArchiveDefaultRecheckDays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
ArchiveEnabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
ArchivePolicyTermDays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
ArchiveRecentJobCompletionDays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
DomainGraphKnownUnreachableTables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
Assignment parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
AssignmentQueuesEnabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
Batch process parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
BatchProcessHistoryPurgeDaysOld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
CleanupETLPurgeRoot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
Business calendar parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
BusinessDayDemarcation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
3
Guidewire PolicyCenter 9.0.9 Configuration Guide

BusinessDayEnd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
BusinessDayStart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
BusinessWeekEnd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
HolidayList (obsolete). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
IsFridayBusinessDay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
IsMondayBusinessDay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
IsSaturdayBusinessDay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
IsSundayBusinessDay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
IsThursdayBusinessDay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
IsTuesdayBusinessDay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
IsWednesdayBusinessDay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
MaxAllowedDate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
MinAllowedDate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
Business rules parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
BizRulesCacheStaleTimeMinutes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
BizRulesDeploymentEnabled. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
BizRulesDeploymentId . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
BizRulesImportBootstrapRules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49
BizRulesLeafSearchNumOfHops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49
BulkLoadRuleHeadByIdCacheEnabled. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49
PreloadBizRulesBeansCacheEnabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50
Cache parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50
ExchangeRatesCacheRefreshIntervalSecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50
GlobalCacheActiveTimeMinutes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50
GlobalCacheDetailedStats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
GlobalCacheReapingTimeMinutes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
GlobalCacheSizeMegabytes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
GlobalCacheSizePercent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
GlobalCacheStaleTimeMinutes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
GlobalCacheStatsRetentionPeriodDays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
GlobalCacheStatsWindowMinutes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
GroupCacheRefreshIntervalSecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
ScriptParametersRefreshIntervalSecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
TreeViewRefresh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
ZoneCacheRefreshIntervalSecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
Clustering parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
ClusteringEnabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
ClusterMemberPurgeDaysOld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
ClusteringProductModelUpdateMaxRetries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
ClusteringProductModelUpdateRetryTimeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
ClusteringProductModelUpdateSleepTimeCeiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
ConfigVerificationEnabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
PDFMergeHandlerLicenseKey. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
SerializationWhitelistEnabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
Database parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
DisableHashJoinPolicySearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
DisableIndexFastFullScanForPolicySearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
DisableSequenceUtil. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
DisableSortMergeJoinPolicySearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
DiscardQueryPlansDuringStatsUpdateBatch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
IdentifyQueryBuilderViaComments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
IdentifyORMLayerViaComments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
MigrateToLargeIDsAndDatetime2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
UseOracleHintsOnMessageQueries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
Data destruction parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57

4
 Guidewire PolicyCenter 9.0.9 Configuration Guide

ArchiveReferenceTrackingEnabled. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
ContactDestructionRequestAgeForPurgingResults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58
PersonalDataDestructionEnabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58
Desktop and team parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58
ActivityStatisticsWindowSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58
OtherWorkOrdersStatisticsWindowSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58
RenewalsStatisticsWindowSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58
SearchActivityThresholdDays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
SubmissionsStatisticsWindowSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
TeamScreenTabVisibilityRowCountCutoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
Document creation and document management parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
DisplayDocumentEditUploadButtons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
DocumentContentDispositionMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
DocumentTemplateDescriptorXSDLocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
FinalDocumentsNotEditable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
MaximumFileUploadCount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
MaximumFileUploadSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
MaximumTotalUploadSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
Environment parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
AddressVerificationFailureAsError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
AlwaysShowPhoneWidgetRegionCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
CurrentEncryptionPlugin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
DeprecatedEventGeneration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
EnableAddressVerification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62
EnableInternalDebugTools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62
KeyGeneratorRangeSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62
MemoryUsageMonitorIntervalMins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62
PublicIDPrefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62
ResourcesMutable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
RetainDebugInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
StrictDataTypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64
TwoDigitYearThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64
UnreachableCodeDetection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64
UnrestrictedUserName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64
UseOldStylePreUpdate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
WarnOnImplicitCoercion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
WebResourcesDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
Financial parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
Geocoding parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
UseGeocodingInPrimaryApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
ProximitySearchOrdinalMaxDistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
ProximityRadiusSearchDefaultMaxResultCount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
UseMetricDistancesByDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
Globalization parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
DefaultApplicationLanguage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
DefaultApplicationLocale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
DefaultApplicationCurrency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
DefaultRoundingMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67
MulticurrencyDisplayMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67
DefaultCountryCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68
DefaultPhoneCountryCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68
DefaultNANPACountryCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68
AlwaysShowPhoneWidgetRegionCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68
Integration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68
BillingSystemArchiveEnabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68

5
Guidewire PolicyCenter 9.0.9 Configuration Guide

BillingSystemArchivePolicyPeriodDays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68
BillingSystemURL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69
ClaimSystemURL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69
DefaultXmlExportIEncryptionId . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69
KeepCompletedMessagesForDays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69
LockDuringDistributedMessageRequestHandling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69
LockPrimaryEntityDuringMessageHandling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69
PaymentSystemURL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70
PluginStartupTimeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70
Job expiration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71
JobExpirationCheckAudit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71
JobExpirationCheckCancellation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72
JobExpirationCreateDateThreshold. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72
JobExpirationEffDateThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72
JobExpireCheckIssuance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72
JobExpireCheckPolicyChange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72
JobExpireCheckReinstatement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72
JobExpireCheckRenewal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72
JobExpireCheckRewrite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
JobExpireCheckSubmission. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
JobExpireCheckTestJob . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
Lookup table parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
AvailabilityContextCacheEntryExpirationTime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
AvailabilityContextCacheSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
UsePolicyPeriodReferenceDateForOfferingAvailability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
Miscellaneous job-related parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
AllowedDaysBeforeOrAfterPolicyStartDate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
MaximumPolicyCreationYearDelta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74
MaxRecentAccounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74
MaxRecentPoliciesAndJobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74
MaxSubmissionsToCreate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74
MinimumPolicyCreationYear. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74
PatternCacheMaxDuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74
PolicyChangeMaxQuotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74
PurgeTemporaryPolicyPeriodsAfterDays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74
PurgeTemporaryPolicyPeriodsEnabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74
RenewalMaxQuotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
RenewalProcessLeadTime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
SubmissionMaxQuotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
Miscellaneous parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
ConsistencyCheckerThreads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
DefaultDiffDateFormat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
DisableDomainGraphSupport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
IgnoreLeapDayForEffDatedCalc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
InitialSampleDataSet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
PreloadSystemTableToCacheForFasterSynchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
ProfilerDataPurgeDaysOld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
TransactionIdPurgeDaysOld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
Policy exception parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
BoundPolicyThresholdDays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
ClosedPolicyThresholdDays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
OpenPolicyThresholdDays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
PDF print settings parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
DefaultContentDispositionMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
PrintFontFamilyName. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78

6
 Guidewire PolicyCenter 9.0.9 Configuration Guide

PrintFontSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78
PrintFOPUserConfigFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78
PrintHeaderFontSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78
PrintLineHeight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78
PrintListViewBlockSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78
PrintListViewFontSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78
PrintMarginBottom. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78
PrintMarginLeft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
PrintMarginRight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
PrintMarginTop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
PrintMaxPDFInputFileSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
PrintPageHeight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
PrintPageWidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
PrintPdfDefaultBaseFileExtension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
PrintPdfMimeType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
Print settings parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
PrintCsvDefaultBaseFileExtension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
PrintCsvMimeType. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
PrintDefaultBaseFileName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
Product model parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
ExternalProductModelDirectory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
ProductModelClassCacheConcurrencyLevel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81
Quote purging configuration parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81
PruneAndPurgeJobsEnabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81
PruneVersionsDefaultRecheckDays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81
PruneVersionsPolicyTermDays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81
PruneVersionsPolicyTermDaysCheckDisabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81
PruneVersionsRecentJobCompletionDays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81
PurgeJobsDefaultRecheckDays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82
PurgeJobsPolicyTermDays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82
PurgeJobsPolicyTermDaysCheckDisabled. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82
PurgeJobsRecentJobCompletionDays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82
PurgeOrphanedPolicyPeriodsEnabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82
Rating management parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82
EnableRateRoutinesJar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82
OverriddenTableArgsLabelSimple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
PurgeRateBookExportResultEnabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
PurgeWorksheetsEnabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
RateBookExportResultAgeForPurging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
RateBookPreloadEnabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
RateRoutineIndexingThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
RateRoutinesJarFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84
RateRoutinesUpdateJarFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84
RateTableManagementNormalizationRowLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
RateTableManagementNormalizationRowThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
RatingWorksheetContainerAgeForPurging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
SmallRateTableRowLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
RateBookCacheEntryLifetimeSecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
RateBookCacheUpdateIntervalSecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
RateTableCacheConcurrency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86
RateTableCacheEntryLifetimeSecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86
RateTableCacheMaxSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86
RateTableCacheUpdateIntervalSecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86
RateTableDefinitionCacheUpdateIntervalSecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86
Risk assessment parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86

7
Guidewire PolicyCenter 9.0.9 Configuration Guide

MultipleLocationRiskAssessmentEnabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
PurgeRiskAssessmentTempStoreDays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
RiskAssessmentIntegrationEnabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
RiskAssessmentThumbnailMapEnabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
SingleLocationRiskAssessmentEnabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
SpotlightInteractiveServiceURL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
SpotlightLoginURL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
SpotlightRiskAssessmentServiceURL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
SpotlightThumbnailMapURL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
Scheduler and workflow parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88
SchedulerEnabled. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88
WorkflowLogDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88
WorkflowLogPurgeDaysOld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88
WorkflowPurgeDaysOld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88
WorkflowStatsIntervalMins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88
Search parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88
FreeTextSearchEnabled. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
MaxContactSearchResults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
PolicySearchMaxResult . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
Security parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
EnableDownlinePermissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
ExternalUserAccess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
FailedAttemptsBeforeLockout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
LockoutPeriod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
LoginRetryDelay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
MaxPasswordLength. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
MinPasswordLength . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
RestrictContactPotentialMatchToPermittedItems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91
RestrictSearchesToPermittedItems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91
SessionTimeoutSecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91
Side-by-side quoting parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91
RenewalMaxSideBySideQuotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91
SideBySide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91
SubmissionMaxSideBySideQuotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91
PolicyChangeMaxSideBySideQuotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
User interface parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
ActionsShortcut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
AutoCompleteLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
InputMaskPlaceholderCharacter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
ListViewPageSizeDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
MaxBrowserHistoryItems (obsolete). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
QuickJumpShortcut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
UISkin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
WebUIAJAXTimeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
Work queue parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
InstrumentedWorkerInfoPurgeDaysOld. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
WorkItemCreationBatchSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
WorkItemPriorityMultiplierSecs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
WorkItemRetryLimit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
WorkQueueHistoryMaxDownload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94
WorkQueueThreadPoolMaxSize. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94
WorkQueueThreadPoolMinSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94
WorkQueueThreadsKeepAliveTime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94

8
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Part 2
The Guidewire development environment
3 Getting started. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97
What Is Guidewire Studio? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97
The Studio development environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97
Working with the QuickStart development server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98
Connecting the development server to a database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99
Deploying your configuration changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
PolicyCenter configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Key directories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Studio and IntelliJ IDEA configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Using Studio with IntelliJ IDEA Ultimate Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Setting IntelliJ IDEA properties in Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Studio and the DCEVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Start Guidewire Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Stop Guidewire Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Updating Guidewire Studio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Enable or disable automatic update checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Manually check for Studio updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Setting the Studio update site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Updating Studio manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

4 Working in Guidewire Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Entering valid code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Using dot completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Accessing reference information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Accessing the Gosu API Reference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Accessing the PCF Reference Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Accessing the Gosu Reference Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Using Studio keyboard shortcuts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Saving your work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Verifying configuration resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Inspecting configuration resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Compiling configuration resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Enabling or disabling Gosu compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Setting options for Gosu command prompt compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Suppressing compiler warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Editing the XML definition of Studio resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

5 Working with Guidewire Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Improving Studio performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Set the maximum amount of memory available to Guidewire Studio. . . . . . . . . . . . . . . . . . . . . . 115
Set the amount of memory for project builds in Guidewire Studio . . . . . . . . . . . . . . . . . . . . . . . 116
Resetting Guidewire Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Rebuild the Studio project files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Rebuild the Studio file index cache. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Setting font display options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

6 Guidewire Studio and Gosu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Gosu building blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Gosu case sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Working with Gosu in PolicyCenter Studio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Gosu packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Create a new package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Gosu classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
9
Guidewire PolicyCenter 9.0.9 Configuration Guide

Create a new Gosu class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

PolicyCenter base configuration classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Class visibility in Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Preloading Gosu classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Gosu enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Create a new enhancement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
XML and GX models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Define a GX model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Script parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Script parameters overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Script parameters as global variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Script parameter examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Working with script parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Referencing a script parameter in Gosu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
PolicyCenter script parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Part 3
Guidewire Studio editors
7 Using the Studio editors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Editing in Guidewire Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Working in the Gosu editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Using Product Designer to edit the product model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

8 Using the plugins registry editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

What are plugins? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Plugin implementation classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
What is the plugins registry? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Startable plugins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Working with plugins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Create a Plugins Registry item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Add an implementation to a Plugins Registry item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Configuring a plugin environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Customizing plugin functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Working with plugin versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

9 Working with web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Using the web service editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Defining a web service collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

10 Implementing QuickJump commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

What Is QuickJump? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Adding a QuickJump navigation command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Implementing QuickJumpCommandRef commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Implementing StaticNavigationCommandRef commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Implementing ContextualNavigationCommandRef commands. . . . . . . . . . . . . . . . . . . . . . . . . . 144
Checking permissions on QuickJump navigation commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

11 Using the entity names editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Entity names editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Variable table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
The Entity Path column . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
The Use Entity Name? column. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
The Sort columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Gosu text editor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

10
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Including data from subentities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

Entity name types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

12 Using the messaging editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Messaging editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Open the messaging editor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Add or remove a messaging configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Add a message destination. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Associating event names with a message destination. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

13 Using the display keys editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Overview of display keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Display key requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Creating display keys in a Gosu editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Retrieving the value of a display key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Part 4
Data model configuration
14 Working with the Data Dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
What is the Data Dictionary? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
What can you view in the Data Dictionary? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Using the Data Dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Property colors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Object attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Property attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Property tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Entity subtypes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Data field types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Virtual properties on data entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

15 The PolicyCenter data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

What is the data model? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
The data model in Guidewire application architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
The base data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Working with dot notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Overview of data entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Data entity metadata files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
The extensions properties file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Working with entity definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Search for an existing entity definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Create a new entity definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Extend an existing entity definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
PolicyCenter data entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Data entities and the application database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
PolicyCenter database tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Data objects and scriptability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
XML root elements and related base PolicyCenter data object types . . . . . . . . . . . . . . . . . . . . . . . 179
<delegate> elements and related data object types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
<entity> elements and related data object types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
<extension> elements and related data object types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
<nonPersistentEntity> elements and related data object types . . . . . . . . . . . . . . . . . . . . . . . . . . 191
<subtype> elements and related data object types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
<viewEntity> elements and related data object types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
<viewEntityExtension> elements and related data object types . . . . . . . . . . . . . . . . . . . . . . . . . 197

11
Guidewire PolicyCenter 9.0.9 Configuration Guide

Data entity subelements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

<array> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
<column> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
<edgeForeignKey> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
<events> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
<foreignkey> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
<fulldescription> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
<implementsEntity> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
<implementsInterface> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
<index>. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
<onetoone> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
<remove-index> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
<tag> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
<typekey> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Interactions of ignoreForEvents attribute with data entity relationships . . . . . . . . . . . . . . . . . . . . 221

16 Working with associative arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Overview of associative arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Associative array mapping types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Scriptability and associative arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Setting array member values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Subtype mapping associative arrays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Working with array values by using subtype mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Typelist mapping associative arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Working with array values by using typelist mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Example: Mapping an entity to entities of a different type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Constant mapping associative arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Working with array values by using constant mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

17 Modifying the base data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Planning changes to the base data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Overview of data model extensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Strategies for extending the base data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
What happens if you change the data model? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Naming restrictions for extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Defining a new data entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Create a new entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Default properties on a new entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Extending a base configuration entity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Create a new extension file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Working with attribute and element overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Overriding data type attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Overriding nested subelements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Extending the base data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Creating a new delegate object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Extending a delegate object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Defining a subtype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Defining a reference entity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Define an entity array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Implementing a many-to-many relationship between entity types . . . . . . . . . . . . . . . . . . . . . . . . 255
Extending an existing view entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Removing objects from the base configuration data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Remove a base extension entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Remove an extension to a base object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Implications of modifying the data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Deploying data model changes to the application server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
12
 Guidewire PolicyCenter 9.0.9 Configuration Guide

18 Example: Creating assignable entities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

Creating an assignable extension entity type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Step 1: Create extension entity type UserAssignableEntity_Ext . . . . . . . . . . . . . . . . . . . . . . . . . 263
Step 2: Create assignment class NewAssignableMethodsImpl . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Step 3: Test assignment of your extension entity instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Making your extension entity type eligible for round-robin assignment . . . . . . . . . . . . . . . . . . . . . 267
Step 1: Extend the AssignmentState entity types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Step 2: Subclass class AssignmentType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Step 3: Create class UserAssignableEntityExtEnhancement. . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Step 4: Test round-robin assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Creating an assignable extension entity type that uses foreign keys . . . . . . . . . . . . . . . . . . . . . . . . 273
Step 1: Create extension entity type TestClaimAssignable_Ext. . . . . . . . . . . . . . . . . . . . . . . . . . 273
Step 2: Add foreign keys to assignable entity types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Step 3: Create new assignment type for extension entity type TestClaimAssignable_Ext . . . . . . . . 275
Step 4: Create enhancement class TestClaimAssignableExtEnhancement . . . . . . . . . . . . . . . . . . 277
Step 5: Create delegate class TestClaimAssignableMethodsImpl . . . . . . . . . . . . . . . . . . . . . . . . 278
Step 6: Add the necessary permission for the extension entity type . . . . . . . . . . . . . . . . . . . . . . . 279
Step 7: Test assignment of the assignable entity type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

19 Data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

Overview of data types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Working with data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Using data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Defining a data type for a property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
The data types configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
<...DataType> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Deploying modifications to the data types configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Customizing base configuration data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
The Length attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
The Precision and Scale attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
The Validator attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
List of customizable data types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Working with the medium text data type (Oracle) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Working with the VARCHAR data type (SQL Server) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
The data type API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Retrieving the data type for a property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Retrieving a particular data type in Gosu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Retrieving a data type reflectively. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Using the IDataType methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Define a new data type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Defining a new tax identification number data type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Step 1: Register the data type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Step 2: Implement the IDataTypeDef Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Step 3: Implement the data type aspect handlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294

20 Field validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

Field validator definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
<FieldValidators> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
<ValidatorDef> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Modifying field validators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Using <column-override> to modify field validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301

21 Working with typelists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303

What is a typelist? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Terms related to typelists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Typelists and typecodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
13
Guidewire PolicyCenter 9.0.9 Configuration Guide

Typelist definition files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

Different kinds of typelists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Internal typelists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Extendable typelists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Custom typelists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Working with typelists in Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
The typelist editor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Entering typecodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Typekey fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Example: Typekey field. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Removing or retiring a typekey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Remove a typekey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
Retire a typekey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
Typelist filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
Static filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Create a static filter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Creating a static filter using categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Creating a static filter using includes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Creating a static filter using excludes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Dynamic filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Creating a dynamic filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Typecode references in Gosu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Mapping typecodes to external system codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

22 The PolicyCenter archive domain graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325

Understanding archiving in Guidewire PolicyCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Overview of the archive domain graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
The archive domain graph is a directed acyclic graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
The archive domain graph and entity instance graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
The archive domain graph and reference data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Understanding PolicyCenter entity ownership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Foreign key ownership in the archive domain graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Inverse foreign key ownership in the archive domain graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Ownership through the effective dated branch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Ownership relationships in the PolicyCenter archive domain graph . . . . . . . . . . . . . . . . . . . . . . . . 330
Entities in the archive domain graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Archive entities and the RootInfo delegate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Archive entities and the Extractable delegate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Archive entities and the EffDated delegate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Archive entities and the OverlapTable delegate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Data model changes that impact archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Working with shared entity data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
About cycles in the archive domain graph. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Circular foreign key references. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Ownership cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Validation of the archive domain graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Graph validation errors that prevent the server from starting . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Graph validation warnings that do not prevent the server from starting . . . . . . . . . . . . . . . . . . . . 337
About archive domain graph errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
Resolve archive graph errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
Resolve archive graph warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Resolving issues with custom archive entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Defining a cross-domain tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Defining a revisioned entity from a purge-only domain graph tag . . . . . . . . . . . . . . . . . . . . . . . . 341
About archive graph error messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342

14
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Graph validation errors generated during server startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342

Graph validation errors generated at run time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
About archiving and event messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Viewing the archive domain graph. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Generate the archive domain graph in PDF format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Generate the archive domain graph in PNG format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Using archive logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344

Part 5
User interface configuration
23 Using the PCF editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Page configuration (PCF) editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Page canvas overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Creating a new PCF file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Create a new PCF folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Create a new PCF file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
PCF file type icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Working with shared or included files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Understanding PCF modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Setting a PCF mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Create new modal PCF files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Page Config menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Toolbox tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
Structure tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Properties tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Child lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
PCF elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
PCF elements and the Properties tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Working with elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Adding an element to the canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Moving an element on the canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Changing the type of an element. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Adding a comment to an element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Find a PCF element on the canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
View the source of a PCF element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Duplicate a PCF element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Delete a PCF element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Copy a PCF element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Cut a PCF element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Paste a PCF element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Linking widgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361

24 Introduction to page configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363

Page configuration files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Page configuration elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
What is a PCF element? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Types of PCF elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
Identifying PCF elements in the user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Getting started configuring pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
Finding an existing element to edit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
Creating a new standalone PCF element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
Modifying style and theme elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Changing or adding images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Overriding CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
15
Guidewire PolicyCenter 9.0.9 Configuration Guide

Changing theme colors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370

Advanced theming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

25 Data panels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373

Panel overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Detail view panel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Define a detail view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
Add columns to a detail view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Format a detail view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
List view panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
Define a list view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
Iterate a list view over a data set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
Choose the data source for a list view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381

26 Location groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383

Location group overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
Define a location group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
Location groups as navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Location groups as tab menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Location groups as menu links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Location groups as sidebar navigation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386

27 Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Navigation overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Tab bars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Configure the default tab bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Specify which tab bar to display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Define a tab bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Define a tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Define a drop-down menu on a tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391

28 Configuring search functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393

Overview of search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Database search configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
PolicyCenter database search functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Configuring PolicyCenter database search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Configuring database search criteria in XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Configuring database search criteria in Gosu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Deploying customized database search files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Search criteria validation on server start-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Free-text search configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Overview of free-text search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Free-text search system architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Enabling free-text search in PolicyCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Enable free-text search in PolicyCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
Enabling the free-text search user interface in PolicyCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
Configuring the Guidewire Solr Extension. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Configuring free-text search for indexing and searching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Configuring the free-text batch load command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
Configuring the basic search screen for free-text search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
Modifying free-text search for additional fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
Localizing free-text search. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430

29 Configuring special page functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431

Adding print capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431

16
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Overview of print functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431

Types of printing configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
Linking to a specific page using an EntryPoint PCF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
Entry points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Create a Forwarding EntryPoint PCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Linking to a specific page using an ExitPoint PCF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Creating an ExitPoint PCF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435

Part 6
Workflow, activity patterns, and email configuration
30 Using the workflow editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
Workflow in Guidewire PolicyCenter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
Workflow in Guidewire Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
Access the workflow editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
Workflow editor window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Workflow editor elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Understanding workflow steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Using the workflow right-click menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
Using search with workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444

31 Guidewire workflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445

Understanding workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Workflow instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Work items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
Workflow process format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Workflow step summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Workflow Gosu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
Workflow versioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
Workflow localization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
Workflow structural elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
<Context> workflow element. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
<Start> workflow element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
<Finish> workflow element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
Common step elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
Enter and exit scripts in workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
Asserts in workflows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
Events in workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
Notifications in workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
Branch IDs in workflows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
Basic workflow steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
AutoStep workflow step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
MessageStep workflow step. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
ActivityStep workflow step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
ManualStep workflow step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
Outcome workflow step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
Step branches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
Working with branch IDs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
GO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
TRIGGER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
TIMEOUT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Creating new workflows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Clone an existing workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Extend an existing workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Extending a workflow: a simple example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
17
Guidewire PolicyCenter 9.0.9 Configuration Guide

Instantiating a workflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466

A simple example of instantiation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
The workflow engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Distributed execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Synchronicity, transactions, and errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Workflow subflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Workflow administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
Workflow debugging, logging, and testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
Process logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474
Workflow testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
Enable the ITestingClock plugin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475

32 Defining activity patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477

What is an activity pattern?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
Pattern types and categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Activity pattern types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Categorizing activity patterns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Using activity patterns in Gosu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Calculating activity due dates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
Target due dates (deadlines) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
Escalation dates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
Base configuration activity patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
Activity pattern objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Use activity patterns with documents and emails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
Specifying document and email templates in CSV files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
Localizing activity patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482

33 Guidewire PolicyCenter and Email. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483

Configure the email plugin class and parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
The email object model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
Email utility methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
Email transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
About email templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
Create an email template file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
Create an email template descriptor file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
Localize an email template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
Sending emails from Gosu code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
Saving an email message as a document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Creating an HTML email within code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489

Part 7
Testing Gosu code
34 Testing and debugging your configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
Testing PolicyCenter with Guidewire Studio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
Running PolicyCenter without debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
Debugging PolicyCenter within Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
Debugging a PolicyCenter server that is running outside of Studio . . . . . . . . . . . . . . . . . . . . . . . 500
The Studio debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
Setting breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
Set a breakpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
View a breakpoint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
Remove a breakpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
Stepping through code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
Viewing current values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504

18
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Viewing variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504

Defining a watch list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
Resuming execution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
Using the Gosu scratchpad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
Run the Gosu scratchpad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
Executing code in the Gosu scratchpad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
Accessing application data in the Gosu scratchpad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
Run scratchpad code in the application server debug process . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
Understanding internally generated code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
Manually generate code for configuration resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
Enable or disable code generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
Change code generation for XML classes to generate source code . . . . . . . . . . . . . . . . . . . . . . . 506
Change PCF code generation error behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
Suggestions for testing rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
Compiling and building the application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508

35 Using GUnit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509

The TestBase class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
Overriding TestBase methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
Configuring the server environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510
Server runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
Configuring the test environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512
Set default configuration parameters for all tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512
Add a named set of configuration parameters for tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512
View test configuration settings before launching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512
Configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
Creating a GUnit test class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
Server tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
Using entity builders to create test data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
Creating an entity builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Entity builder examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
Creating new builders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521

Part 8
Guidewire PolicyCenter configuration
36 PolicyCenter configuration guidelines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529
Guidelines for modularizing line-of-business code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529

37 Validation in PolicyCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531

Validation overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
Choosing between validation and underwriting authority. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
Field-level validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
Class-based data object validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
Rules-based data object validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533

38 Class-based validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535

Class-based validation overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535
Validation classes in the base configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
Configuring class-based validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536
Policy object validation levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
Adding new validation levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
Validation package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 538
Validation chaining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
PolicyPeriodValidation:validateImpl method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545

19
Guidewire PolicyCenter 9.0.9 Configuration Guide

PolicyPeriodValidation validation checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545

Invariant validation checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546
Static validation checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546
Invoking class-based validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547
Example: Invoking validation in a job wizard step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547

39 Configuring quote purging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551

Quote purging configuration overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551
Quote purging object model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551
Objects that get purged or pruned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552
Quote purging batch processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554
Enable quote purging batch processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555
Batch processes to run prior to running the purge batch process . . . . . . . . . . . . . . . . . . . . . . . . . 555
Purge batch process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555
Purge Orphaned Policy Periods batch process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558
Using events to notify external system of purged of pruned entities . . . . . . . . . . . . . . . . . . . . . . . . 559
Purging test tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559
Flushing other work queues with the purging test tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559
Purge or prune a job with the purging test tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559
Prune policy periods with the purging test tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560
Run the Purge batch process from the purging test tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561

40 Configuring quote cloning for business intelligence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563

Quote cloning configuration overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
Quote cloning object model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564
Enable quote cloning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564
Quote clone plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564
Determining whether to clone a quote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565
Cleaning up after cloning policy period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565
Processing the cloned policy period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565
Adding to the Purge Quote Clones query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565
Purge quote clones batch processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566

41 Configuring contingencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567

Contingency configuration overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567
Contingency object model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567
Contingency Gosu class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569
Contingency batch processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569

42 Configuring the Spotlight integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571

Spotlight integration overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
Spotlight Integration Requires HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
Accessing risk assessment interactively. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
Accessing risk assessment non-interactively . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
Risk assessment object model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575
Location risk assessment object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576
Risk assessment temporary objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576
Configuring risk assessment in the Location Information Screen . . . . . . . . . . . . . . . . . . . . . . . . . . 577
Risk assessment information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577
Risk assessment thumbnail map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578
Deleting temporary risk assessment objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578
Risk assessment configurable classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578
Spotlight service authentication for risk assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
Risk assessment error handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
Request and location level errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580
Enabling Spotlight services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580

20
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Risk assessment configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 580

Spotlight session time-out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581

43 Configuring underwriting authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583

Overview of configuring underwriting authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
Underwriting Authority Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
Configuring authority grants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
Underwriting authority profile object model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
Displaying authority grants in the user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
Configuring underwriting rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
Configuring underwriting rules through business rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
Underwriting rules object model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585
Adding a new checking set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587
Adding a new value comparator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
Adding a new value formatter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591
Checking sets and evaluators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
Orphaned underwriting issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
Blocking points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
Configuring underwriting referral reasons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594
Job interactions with underwriting issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594
Issue keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597
Configuring underwriting issue history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
Comparing issue values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
Configuring default values for assignment type and value offset amount . . . . . . . . . . . . . . . . . . . 599
Underwriter issue type verifier class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
Localizing underwriting issue details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 599
Configuring approvals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
Approval expiration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
Special approval permission. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
Passing approval requests to underwriters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 600
Handling underwriting issues in policy revisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
Handling underwriting issues in out-of-sequence policy changes . . . . . . . . . . . . . . . . . . . . . . . . 602
Handling underwriting issues in preempted jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
Creating externally managed underwriting rules in Gosu code . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
Gosu implementation overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
UWIssueType fields in underwriting rule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604
Creating underwriting issues with policy evaluation plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604
Raise underwriting issues in Gosu code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605

44 Configuring business rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607

The business rules plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607
What can you modify in the business rules plugin class? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607
Working with the business rules plugin class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608
Configuring methods and properties for business rule conditions . . . . . . . . . . . . . . . . . . . . . . . . 608
Business rule actions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
Triggering point mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
Rule permission provider. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
Custom rule utility functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 609
Rule contexts and rule context definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 610
Configuring applicability criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611
Add a new PolicyCenter applicability criterion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612

45 Configuring the Account Holder Info screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613

Ways to configure the Account Holder Info screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
Consolidate account information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614
Cross-application alerts in a single location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
21
Guidewire PolicyCenter 9.0.9 Configuration Guide

Links to referenced objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615

Controlled access to the Account Holder Info screen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
Customizing Account Holder Info screen data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
Account Holder Info screen performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
Configuration files for the Account Holder Info screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
Entities and the Account Holder Info screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
Permissions for the Account Holder Info screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
Display keys for the Account Holder Info screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
PCF files for the Account Holder Info screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
Gosu files for the Account Holder Info screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617

46 Configuring policy data spreadsheet import/export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619

Changing the spreadsheet protection password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619
Change the worksheet protection password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619
Configuring spreadsheet import/export in commercial property. . . . . . . . . . . . . . . . . . . . . . . . . . . 620
Adding spreadsheet import/export to other entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
Create an XML file describing columns to import and export. . . . . . . . . . . . . . . . . . . . . . . . . . . 620
Defining column data resolvers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622
Create an import strategy for each new data column resolver . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
Modify the ImportStrategyRegistry class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623

47 Configuring earned premium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625

How PolicyCenter calculates earned premium. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
Methods that calculate earned premium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
PCF files that display earned premium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626

48 Configuring the Team tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627

Configuring the Team Screens batch process for team statistics. . . . . . . . . . . . . . . . . . . . . . . . . . . 627
Scheduling the Team Screens batch process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627
Setting the window size for team statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628
How PolicyCenter calculates reporting categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628
Setting the maximum number of rows on the Team screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630

49 Configuring Rating Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631

Rating Management data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631
Rate table data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631
Rate routine data model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632
Rating Management performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633
Improving startup and first access to Rating Management components . . . . . . . . . . . . . . . . . . . . 633
Improving rate table performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639
Parameters and properties for Rating Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640
Minimum rating level parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 640
Rate table normalization configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641
Logging properties for Rating Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641
Third party libraries for Rating Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641
POI library. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641
User authority and permissions for Rating Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
Rating Management permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
Rating Management roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
Assignment of permission to roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
Custom physical tables for Rating Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643
Configuring a new custom physical table. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643
Configuring value providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643
Typelist value provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643
PolicyCenter product model value providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644
Reference factor value provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645

22
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Creating a new value provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645

Configuring matching rule operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645
Configure a new match operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645
Extending the match operation factory class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646
Match operation implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646
Match operation validator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647
Configuring rate book matching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
Configuring rate routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
Configuring the rating engine to execute the rate routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
Adding a new rate routine function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650
Configuring rounding operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650
Configure prefixes that identify types in rate routine steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 651
Configuring variant identifiers for a rate routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 652
Configuring the rate routine plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654
Using Gosu to get the rate factor from the rate table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654
Configuring new parameters in parameter sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657
Creating a new parameter for inclusion in parameter sets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657
Adding a new parameter to the rating engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658
Configuring new wrappers for parameter sets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659
Configuring rating worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660
Configuring extract and purge rating worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660
Logging rate routine functions in a rating worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662
Configuring impact testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663
Impact testing warnings and recommendations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663
Enabling impact testing for a line of business. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663
Rate renewals as renewal jobs in impact testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663
Modifying the functionality of impact testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664
Work queues for impact testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664
Configuring the impact testing plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664
Configuring rate book export to spreadsheet and XML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665
Rating Management plugins and interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665
Rate routine plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665
Impact testing plugin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669
Rate query lookup plugin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671
Adding line-specific cost methods using cost adapters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672

50 Configuring Reinsurance Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675

Reinsurance Management object model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675
Reinsurance program object model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675
Reinsurance agreement object model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675
Reinsurance coverage group object model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678
Policy period reinsurance object model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
Reinsurance Management permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680
Configuring reinsurance coverage groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680
Configure reinsurance coverage group on individual coverages . . . . . . . . . . . . . . . . . . . . . . . . . 681
Disable Reinsurance Management for a line of business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681
Reinsurance net retention underwriting issue type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681
Implementing Gosu methods for Reinsurance Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681
Gosu methods for calculating the total insured value. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681

51 Handling high volume quote requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683

High volume quotes overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683
Generating the quote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683
Viewing the quote. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684
Moving the quote into the system of record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684
Other considerations for handling high volume quotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685
23
Guidewire PolicyCenter 9.0.9 Configuration Guide

High volume quotes implementation overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685

Quoting processor plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
Quoting data plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687

52 Configuring multicurrency. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689

Configuring PolicyCenter for a single currency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689
Creating multicurrency policy lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689
Adding coverage currencies to a policy line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690
Changing the settlement currency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 691
PolicyCenter and product model configured for multicurrency . . . . . . . . . . . . . . . . . . . . . . . . . . 692
Configuring the coverage currency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
Coverage currency in accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
Coverage currency in policy periods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
Coverage currency in coverages and clauses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
Coverage currency in coverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
Configuring the settlement currency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
Settlement currency in contacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
Settlement currency in accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694
Settlement currency in policy periods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694
Configuring multicurrency and reinsurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694
Reinsurance objects and multicurrency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695
Configuring multicurrency and rating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695
Costs and multicurrency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696
Transactions and multicurrency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697
Configuring underwriting authority and multicurrency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697
Configuring underwriting issues and multicurrency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697
Configuring authority profiles and multicurrency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698
Implementing an exchange rate service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698
The Exchange Rate Service Plugin interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699
Enabling multicurrency integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699
Set up currency-specific plans and authority limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699

53 Policy Term archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703

Archiving in Guidewire PolicyCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703
How PolicyCenter determines the date for archive eligibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704
Batch processing and archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704
Monitoring archiving activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704
Understanding errors in the archiving process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
Logging archiving activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
Archive configuration options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
Archive data model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
Archive configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707
Archiving and the SQL Server database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707
Gosu code and archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707
Understanding the archiving plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708

54 Configuring personal data destruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709

Data destruction configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709
Data model configuration for data destruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710
DestructionRootPinnable delegate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710
Do Not Process flag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
Display keys for data destruction messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
Obfuscatable delegate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711
Obfuscator interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
Marking entity fields for obfuscation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
Entity domain graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713
24
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Identifying archived objects that affect destruction of data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714

Data Protection Officer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714
Data Protection Officer permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714
Notifying the Data Protection Officer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
Data destruction purge configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
Pinnable hierarchy in PolicyCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
PersonalDataPurgeTree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716
Traversing the pinnable hierarchy for personal data purge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717
Defining the destroyer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719
PersonalDataPurge event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719
Specifying which objects in the graph can be destroyed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720
Data obfuscation in PolicyCenter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 721
Implementing the Obfuscatable delegate in an entity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
Implementing the Obfuscator interface in an entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
Personal data obfuscator classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723
Data destruction test tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726

Part 9
Guidewire PolicyCenter job configuration
55 Configuring jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729
Common ways to configure jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729
Wizards for jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729
Gosu classes for jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 730
Job rule sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 730
Job workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731
System configuration parameters for jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731
Changing jobs to expired status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731
Configuring the job expire batch process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 731
Configuring job history events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732
History events in the default configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733
Configuring history search criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734
Multiple revision jobs and the job selected branch property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734
Selecting the underwriting company through segmentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734
Segmentation classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735
PolicyPeriodBaseEnhancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735

56 Configuring submissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737

Configuring submissions overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737
Submission process Gosu class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737
Submission enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738
Submission integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739
Submission web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739
Submission plugins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739
Expiring submissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740
Submission configuration examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740
Configuring the copy submission feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740

57 Configuring issuance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741

Configuring issuance overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741
Modifying the issuance process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741
Issuance integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741
Issuance web services and plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 742

25
Guidewire PolicyCenter 9.0.9 Configuration Guide

58 Configuring renewals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743

Configuring renewals overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743
Renewal process Gosu class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743
Renewal enhancement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744
Renewal workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744
Renewal rule sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745
Renewal integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745
Renewal web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745
Renewal plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746
Renewal events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747
Configuring batch process renewals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747
Renewal plugin calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748
Renewal lead time in notification config system table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749
Example lead time by line of business. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749
Example lead time by time of year . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749
Delay for a conflicting job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 750
Configuring explanations in pre-renewal directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 750

59 Configuring cancellations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751

Configuring cancellations overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751
Cancellation Gosu classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 752
Complete cancellation workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753
Cancellation integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753
Cancellation web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753
Cancellation plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753
Cancellation events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754
Calculating the cancellation effective date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754
Calculating the cancellation effective date if the source is insured . . . . . . . . . . . . . . . . . . . . . . . 754
Calculating the cancellation effective date if the source is insurer . . . . . . . . . . . . . . . . . . . . . . . . 754
Configuring the premium calculation method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755

60 Configuring policy change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757

Configuring policy change overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757
Policy change process class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757
Modifying the policy change process class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758
Policy change integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759
Policy change web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759
Policy change plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759
Policy change events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759

61 Configuring reinstatement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761

Configuring reinstatement overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761
Reinstatement process Gosu class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761
Reinstatement integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762
Reinstatement web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762
Reinstatement plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 762
Reinstatement events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763

62 Configuring rewrite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765

Configuring rewrite overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765
Rewrite process Gosu class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765
Rewrite integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766
Rewrite events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766

63 Configuring rewrite new account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767

Configuring the rewrite new account job overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767

26
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Rewrite new account job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767

Rewrite new account object model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768
Rewrite new account history events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768

64 Configuring premium audit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769

Configuring premium audit overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769
Audit Gosu classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 770
Premium audit integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771
Integration with BillingCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771
Audit web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771
Audit plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771
Audit events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771
Defining audit schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 771
Final audit schedules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772
Premium report schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772
Create audit schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773
Configuring audit types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 773
Add new audit type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774
Extend audit schedule type typelist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 774
Audit schedule properties file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775
Audit schedule pattern. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777

65 Configuring side-by-side quoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779

Changing the maximum number of versions in side-by-side quoting . . . . . . . . . . . . . . . . . . . . . . . 779
Marking a job as side-by-side . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779
Side-by-side quoting object model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780
Configuring the side-by-side quoting screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780
Posting Changes to the server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780
Disable post on enter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 781
Configuring initial behavior of the side-by-side quoting screen . . . . . . . . . . . . . . . . . . . . . . . . . 781
Copying base data for side-by-side quoting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 781
High-level view of base data copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 782
Gosu methods for base data copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 782
Excluding side-by-side data from base data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784
Side-by-side data that base data copy must exclude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785
Side-by-side data that base data copy can exclude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785
Side-by-side data in personal auto excluded from base data copy . . . . . . . . . . . . . . . . . . . . . . . . 787
Exclude entities reachable through two paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 788
Configuring data excluded from base data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 790
Configuring quote all to ignore validation warnings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 790

27
Guidewire PolicyCenter 9.0.9 Configuration Guide

28
 Guidewire PolicyCenter 9.0.9 Configuration Guide

About PolicyCenter documentation

The following table lists the documents in PolicyCenter documentation:

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.
Upgrade Guide Describes the overall upgrade process, and describes how to upgrade your configuration and data‐
base from a previous major version. The intended readers are system administrators and implementa‐
tion engineers who must merge base application changes into existing application extensions and in‐
tegrations.
The Upgrade Guide is available separately from the main documentation set.
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.

About PolicyCenter documentation 29

Guidewire PolicyCenter 9.0.9 Configuration Guide

Document Purpose
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.
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.

Conventions in this document

Text style Meaning Examples
italic Indicates a term that is being defined, A destination sends messages to an external system.
added emphasis, and book titles. In Navigate to the PolicyCenter installation directory by running the
monospace text, italics indicate a variable to following command:
be replaced.
cd installDir

bold Highlights important sections of code in for (i=0, i<[Link](), i++) {

examples. newArray[i] = someArray[i].getName()
}

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 [Link]
and URLs.

30 About PolicyCenter documentation

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Support
For assistance, visit the Guidewire Community.
Guidewire customers
[Link]
Guidewire partners
[Link]

About PolicyCenter documentation 31

Guidewire PolicyCenter 9.0.9 Configuration Guide

32 About PolicyCenter documentation

Part 1

PolicyCenter configuration basics

Guidewire PolicyCenter 9.0.9 Configuration Guide
chapter 1

Overview of PolicyCenter
configuration

This topic provides some basic information, particularly about the Guidewire PolicyCenter data model and system
environment. Guidewire recommends that before you undertake any configuration changes, that you thoroughly
understand this information.

What you can configure

Application configuration files determine virtually every aspect of the PolicyCenter application. For example, you
can make the following changes by using XML configuration files and simple Gosu:

Extend the data model

You can add fields to existing entities handled by the application, or create wholly new entities to support a wide
array of different business requirements. You can:
• Add a field such as a column, typekey, array or foreign key to an extendable entity. For example, you can add an
IM Handle field to contact information.
• Create a subtype of an existing non-final entity. For example, you can create an Inspector object as a subtype of
Person.
• Create a new entity to model an object not supported in the base configuration product. For example, you can
create an entity to archive digital recordings of customer phone calls.

Change or augment the PolicyCenter application

You can extend the functionality of the application:
• Build new views of policies and other associated objects.
• Create or edit validators on fields in the application.
• Configure a new line of business.

Modify the PolicyCenter interface

You can configure the text labels, colors, fonts, and images that comprise the visual appearance of the PolicyCenter
interface. You can also add new screens and modify the fields and behavior of existing screens.
Overview of PolicyCenter configuration 35
Guidewire PolicyCenter 9.0.9 Configuration Guide

Implement security policies

You can customize permissions and security in XML and then apply these permissions at application runtime.

Create business rules and processes

You can create customized business-specific application rules and Gosu code. For example, you can create business
rules that perform specialized tasks for validation and work assignment.

Designate activity patterns

You can group work activities and assign to agents and underwriters.

Integrate with external systems

You can integrate PolicyCenter data with external applications.

Define application parameters

You can configure basic application settings such as database connections, clustering, and other application settings
that do not change during server runtime.

Define workflows
You can create new workflows, create new workflow types, and attach entities to workflows as context entities. You
can also set new instances of a workflow to start within Gosu business rules.

Guidewire internal methods

Some code packages contain Guidewire internal classes that are reserved for Guidewire use only. Gosu code written
to configure PolicyCenter must never use an internal class nor call any method of an internal class for any reason.
Future releases of PolicyCenter can change or remove an internal class without notification.
The following packages contain Guidewire internal classes.
• All packages in [Link].*
• Any package whose name or location includes the word internal
Gosu configuration code can safely use classes defined in any gw.* package, except for those packages whose name
or location includes the word internal.
Some Gosu classes are visible in Studio, but are not intended for use. You can distinguish these Gosu classes
because they have no visibility annotations (neither @Export nor @ReadOnly) and they are not in a gw package. Do
not use these methods in configuration. The methods are unsupported and may change or be withdrawn without
notice.

How you configure PolicyCenter

Guidewire provides a configuration tool, Guidewire Studio, that you use to edit files stored in the development
environment. (Guidewire also calls the development environment the configuration environment.) You then deploy
the configuration files by building a .war or .ear file and moving it to the application (production) server.
Guidewire Studio provides graphical editors for most of the configuration files. A few configuration files you must
manually edit (again, through Studio).

See also
• “Using the Studio editors” on page 131
36 chapter 1: Overview of PolicyCenter configuration
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Types of application environments

Configuring the application requires an installed development instance of the application (often called a
configuration environment). You use Guidewire Studio to edit the configuration files. Then, you create a .war
or .ear file and copy it to the production server. This section describes some of the particular requirements of these
two environments:
• “The development environment” on page 37
• “The production environment” on page 37

The development environment

The development environment for PolicyCenter has the following characteristics:
• It includes an embedded development QuickStart server and database for rapid development and deployment.
• It includes a repository for the source code of your customized application files. Guidewire expects you to check
your source code into a supported SCM (Source Control Management) SCM system.
• It includes directories for the base configuration application files and your modifications of them.
• It provides command line tools for creating the deployment packages. (These are new, customized, versions of
the server application files that you use in a production environment.)
Guidewire provides a development environment (Guidewire Studio) that is separate from the production
environment. Guidewire Studio is a stand-alone development application that runs independently of Guidewire
PolicyCenter. You use Studio to build and test application customization in a development or test mode before
deploying your changes to a production server. (You can for example, modify a PCF file or add a new workflow.)
It is important to understand that any changes that you make to application files through Studio do not automatically
propagate into your production environment. You must specifically build a .war or .ear file and deploy it to a
production server for the changes to take effect. Studio and the production application server—by design—do not
share the same configuration file system.

The production environment

The deployed production application server for PolicyCenter has the following characteristics:
• It runs as an application within an application server.
• It handles web clients, or SOAP message requests, for policy information or services.
• It generates the web pages for browser-based client access to PolicyCenter.

Deploying configuration files

There is a vast difference in how you deploy modified configuration files in a development environment as opposed
to a production environment. The following sections describes these differences:
• “Deploying changes in a development environment” on page 38
• “Deploying changes to the production server” on page 38

Overview of PolicyCenter configuration 37

Guidewire PolicyCenter 9.0.9 Configuration Guide

Deploying changes in a development environment

In the base configuration, Guidewire provides an embedded application server in the development environment.
This, by design, shares its file structure with the Studio application configuration files. Thus:
• If you modify a file, in many cases, you do not need to deploy the changed configuration file. The development
server reflects the changes automatically. For example, if you add a new typelist, Studio recognizes this change.
• If you modify certain resource files, you must stop and restart Studio for the change to become effective. For
example, if you add a new workflow type, then you must stop and restart Studio before a Gosu class that you
create recognizes the workflow.
• If you modify the base configuration data model files, you must stop and restart the development server to force a
database upgrade.
It is possible to use a different development environment and database other than that provided by Guidewire in the
base configuration. If you do so, then deployment of modified configuration files can require additional work. For
details on implementing a different development environment, see the Installation Guide.

Deploying changes to the production server

About this task
To deploy configuration changes to the PolicyCenter production application server, you must do the following:
• Create an application .war (or .ear) file with your configuration changes in the development environment.
• Shut down the production server.
• Remove the old PolicyCenter instance on the production application server.
• Deploy the .war (or .ear) file to the production application server.
• Restart the production application server.
In the following procedure, notice whether you need to do a task on the development or production server.

Procedure
1. After making configuration changes in your development environment, run one of the build commands from
your development PolicyCenter directory.
For example:
gwb warTomcatDbcp

2. Shut down the production application server.

3. Delete the existing web application folder in the production server installation.
For example (for Tomcat), delete the following folder:
PolicyCenter/webapps/pc

Also, delete the existing .war (or .ear) file on the production server. In any case, moving a new copy to the
production server overwrites the existing file.
4. Navigate to your development installation dist directory (for example, PolicyCenter/dist). The build
script places the new [Link] or [Link] file in this directory.
5. Copy the newly created [Link] file to the production webapps folder (for Tomcat). If using WebSphere or
WebLogic, use the administrative console to deploy the [Link] file.
6. Restart the production application server.
7. During a server start, if the application recognizes changes to the data model, then it mandates that a database
upgrade be run. The server runs the database upgrade automatically.

See also
• If working in a clustered server environment, see the System Administration Guide.
38 chapter 1: Overview of PolicyCenter configuration
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Regenerating the data and security dictionaries

If you change the metadata, for example by extending base entities, it is important that you regenerate the Data
Dictionary and Security Dictionary to reflect those changes. In this way, other people who use the dictionaries can
see these changes.
To generate the Data Dictionary or the Security Dictionary, use one of the following methods:

Method Use to generate More information

PolicyCenter Administration→Utilit- Security Dictionary “Generating the security dictionary from PolicyCenter” on
ies→Export Data page 40
Command prompt gwb Security Dictionary “Generating the data and security dictionaries in HTML format”
genDataDictionary Data Dictionary on page 39
“Generating the data and security dictionaries in XML format” on
page 39

See also
• To understand the Data Dictionary and the information it includes, see “Working with the Data Dictionary” on
page 163.
• To understand the Security Dictionary and the information it includes, see the Application Guide

Generating the data and security dictionaries in HTML format

About this task
To generate the PolicyCenter Data Dictionary and PolicyCenter Security Dictionary in HTML format, run the
following command from the PolicyCenter directory:
gwb genDataDictionary

This command generates HTML files for the dictionaries in the following locations:
PolicyCenter/build/dictionary/data
PolicyCenter/build/dictionary/security

To view a dictionary, open its [Link] file from the listed locations.

Generating the data and security dictionaries in XML format

About this task
You can generate the Data Dictionary and Security Dictionary in XML format, with associated XSD files. Use the
generated XML and XSD files to import the Data Dictionary and Security Dictionary into third-party database
design tools.
To generate the Data Dictionary and Security Dictionary in XML format, run the following command from the
PolicyCenter directory:
gwb genDataDictionary -DoutputFormat=xml

This command generates the following XML and XSD files for the dictionaries:
PolicyCenter/build/dictionary/data/[Link]
PolicyCenter/build/dictionary/data/[Link]

PolicyCenter/build/dictionary/security/[Link]
PolicyCenter/build/dictionary/security/[Link]

The parameter that specifies the output format has two allowed values.
-DoutputFormat={html|xml}

Overview of PolicyCenter configuration 39

Guidewire PolicyCenter 9.0.9 Configuration Guide

If you specify -DoutputFormat=html or you omit the -DoutputFormat parameter, the genDataDictionary
command generates HTML versions of the Data Dictionary and the Security Dictionary.

Generating the security dictionary from PolicyCenter

If you add or modify a user role or role permission, you need to regenerate the Security Dictionary to ensure that it
reflects the changes that you made. You can regenerate the Security Dictionary either through a command prompt
tool or from within PolicyCenter itself.
To generate the Security Dictionary from PolicyCenter, you must have administrative privileges and be able to
access the PolicyCenter Administration tab. On the Administration tab, navigate to the Utilities Export Data screen. From
here, you can download the current security information in HTML and XML format.

Generating the dictionaries as you generate a .war or .ear file

About this task
You can generate the Data Dictionary and the Security Dictionary in HTML format as you generate the Guidewire
application .war (.ear) file. To do so, use one of the build commands. For example:
gwb warTomcatDbcp -DincludeDictionary=true

See also
• Installation Guide

Aspects of regenerating the Security Dictionary

Guidewire PolicyCenter stores the role information used by the Security Dictionary in the base configuration in the
following file:
PolicyCenter/modules/configuration/config/import/gen/[Link]

PolicyCenter does not write this file information to the database.

If you make changes to roles using the PolicyCenter interface, PolicyCenter does write these role changes to the
database.
PolicyCenter does not base the Security Dictionary on the actual roles that you have in your database. Instead,
PolicyCenter bases the Security Dictionary on the [Link] file.

IMPORTANT It is possible for the Security Dictionary to become out of synchronization with the
actual roles in your database. Guidewire PolicyCenter bases the Security Dictionary on the file
[Link] only.

Managing configuration changes

To track, troubleshoot and replicate the configuration changes that you make, Guidewire strongly recommends that
you use a Source Control Management (SCM) to manage the application source code.

40 chapter 1: Overview of PolicyCenter configuration

chapter 2

Application configuration parameters

This topic covers the PolicyCenter configuration parameters, which are static values that you use to control various
aspects of system operation. For example, you can control business calendar settings, cache management, and user
interface behavior through the use of configuration parameters, along with much more.

Working with configuration parameters

You set application configuration parameters in the file [Link]. You can find this file in the Guidewire Studio
Project tool window, under configuration→config.
This file generally contains entries in the following format:
<param name="param_name" value="param_value" />

Each entry sets the parameter named param_name to the value specified by param_value.
The [Link] file in the base configuration contains all available parameters. To set a parameter, edit the file,
locate the parameter, and change its value. PolicyCenter configuration parameters are case-insensitive. If a
parameter does not appear in the file, Guidewire PolicyCenter uses the default value, if the parameter has one.

Adding custom parameters to PolicyCenter

You cannot add new or additional configuration parameters to [Link]. If you want to add custom parameters to
your configuration of PolicyCenter, consider defining script parameters. You can access the values of script
parameters in Gosu code at runtime. For more information, see “Script parameters” on page 125.

Configuration parameter behaviors

The configuration parameters in [Link] may implement the following behaviors:

Behavior Summary More information

Required You must supply a value. “Required” on page 42
Set for environment You can set a different value for different servers in the same “Set for environment” on page 42
environment.
Development envi‐ The parameter is valid only on a development environment “Development environment only”
ronment only server. on page 42
Dynamic You can change the parameter value on a running server. “Dynamic” on page 42

Application configuration parameters 41

Guidewire PolicyCenter 9.0.9 Configuration Guide

Behavior Summary More information

Permanent Once you start the server, you cannot change the parameter val‐ “Permanent” on page 42
ue.
Semi‐permanent Once you start the server, you can change the parameter value “Semi‐permanent” on page 43
only in limited ways.
Nullable The parameter value is allowed to be null. “Nullable” on page 43

Required
Guidewire designates certain configuration parameters as required, which means that you must supply a value for
that parameter.
Configuration parameters that are required have Required: Yes in their parameter descriptions.

Set for environment

Guidewire designates certain configuration parameters as possible for the parameter value to vary on different
servers in the same environment.
Configuration parameters that can be set per environment have Set for Environment: Yes in their parameter
descriptions.
Do not add a configuration parameter that is not designated as Set for Environment: Yes to a local configuration file.
If you do so, PolicyCenter prints a warning message in the configuration log file when the application server starts.
For example:
WARN Illegal parameter specified in a local config file (will be ignored): XXXXXXX

Note: For information on server environments in Guidewire PolicyCenter, see the System
Administration Guide.

Development environment only

Guidewire designates certain configuration parameters as permitted to be active only in a development environment.
A production server ignores any configuration parameters that are designated as such. A configuration parameter
with this behavior has Development Environment Only: Yes in its parameter description.

Dynamic
Guidewire designates certain configuration parameters as dynamic. This indicates that Guidewire permits you to
change this value on a running application server through management integration. The discussion of configuration
parameters indicates this by adding Dynamic: Yes to the parameter description.
See the Integration Guide.

Permanent
Guidewire specifies several configuration parameter values as permanent. After you set the value of a permanent
parameter and start the production application server, you cannot change the parameter’s value. An example is the
DefaultApplicationLocale configuration parameter. If you set the value of this parameter on a production server and
then start the server, you are unable to change the value thereafter.
Guidewire stores these values in the database and checks the value at server start up. If an application server value
does not match a database value, PolicyCenter throws an error.

42 chapter 2: Application configuration parameters

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Semi‐permanent
Guidewire specifies a limited number of configuration parameter values as semi-permanent. After you set the value
of a semi-permanent parameter and start the production application server, you can change the value of the
parameter only once to a specified value.

Nullable
The parameter value is allowed to be null.

View configuration parameters on a running server

About this task
You can view the configuration parameters and their values that are in effect on a running PolicyCenter server. To
change the values dynamically, you can create a management integration plugin.

Procedure
1. Open the Server Tools page of the PolicyCenter server.
2. In the sidebar, click Info Pages→Configuration.

Result
See the Integration Guide.

Access configuration parameters in Gosu

Procedure
To access a configuration parameter in Gosu code, use the following syntax:
[Link]
[Link]

Example
For example:
var businessDayEnd = [Link]
var forceUpgrade = [Link]

Adding custom MIME types

About this task
Perform the following steps to add PolicyCenter support for a new MIME type (Multipurpose Internet Mail
Extension).

Procedure
1. If necessary, add the MIME type to the configuration of the application server. This step is dependent on the
configuration requirements of the application server.
For example, Tomcat stores MIME type information in the [Link] configuration file in a series of <mime-
mapping> tags. Verify that the needed MIME type exists in the appropriate file. If necessary, add it.
Application configuration parameters 43
Guidewire PolicyCenter 9.0.9 Configuration Guide

2. Add the new MIME type to the PolicyCenter [Link] file in the <mimetypemapping> section.
• For the name attribute, specify the name of the MIME type, such as text/plain.
• For the extensions attribute, specify the file extensions used by the MIME type. If the MIME type is used
by more than one file extension, separate each extension with a “|” character. PolicyCenter uses this
information to associate MIME types and file extensions. If retrieving a file extension from a MIME type,
PolicyCenter uses the first extension in the list. If retrieving a MIME type from a file extension,
PolicyCenter uses the first <mimetype> entry associated with the extension.
• For the icon attribute, specify the image to use for documents of the MIME type. For example, Tomcat
assumes the images are stored in the tomcat/webapps/pc/resources/images directory.
3. Create a description for the MIME type. The description is stored in the displaykey files. The definition has a
prefix of Mimetype. (notice the prefix-terminating period) followed by the MIME type name attribute
specified in the type’s definition in the [Link] <mimetypemapping> section. Any non-alphanumeric
character in the name must be replaced with an underscore character. For example, the text/plain MIME
type would have a displaykey description of Mimetype.text_plain.

Account parameters
Guidewire provides the following configuration parameters in the [Link] file related to approval activities.
For information on editing [Link] and setting configuration parameters, see “Working with configuration
parameters” on page 41.

AccountsWithdrawnAfterMonths
This parameter is one of the factors that Account Withdraw Evaluation batch processing uses to evaluate whether to
change an account's status to withdrawn. If the creation time or origination date of the account is greater than this
value in months, then the account can be withdrawn.
Default: 37 months

Archive parameters
Guidewire provides the following configuration parameters in the [Link] file that relate to archiving.

See also
• “Working with configuration parameters” on page 41
• “Policy Term archiving” on page 703
• Application Guide

ArchiveDaysRetrievedBeforeArchive
Minimum number of days that must pass after PolicyCenter restores a policy term before it is possible to archive the
term again.
Default: 90

ArchiveDefaultRecheckDays
Minimum number of days that must pass before PolicyCenter reconsiders a policy term for archiving after a
previous check did not identify the policy term as an archiving candidate.
Default: 30
44 chapter 2: Application configuration parameters
 Guidewire PolicyCenter 9.0.9 Configuration Guide

ArchiveEnabled
A Boolean string that specifies whether archiving is enabled or disabled. If set to true, an archive storage area must
be implemented. An archive storage area can be implemented as a database, a regular file on a storage system, or
some other desired method of storage. The PolicyCenter base configuration does not provide an archive storage
area.
This parameter also controls the creation of indexes on the ArchivePartition column. If you set the value of this
parameter to true, PolicyCenter creates a non-unique index on the ArchivePartition column for Extractable
entities.
In PolicyCenter, ArchiveEnabled controls whether or not the domain graph is started. If this parameter and
DisableDomainGraphSupport are both true, the server will not start.
The value of ArchiveEnabled is semi-permanent, meaning that after you start the production server, you can change
the value of this parameter from false to true, but not the converse.

WARNING After you set ArchiveEnabled to true and start the server, you cannot change the
value again. If you reset the value to false, the server will not start.

Default: false
Required: Yes
Permanent: Semi-permanent

ArchivePolicyTermDays
Minimum number of days that must pass before the policy periods associated with a given policy term can be
archived.
Default: 366

ArchiveRecentJobCompletionDays
Minimum number of days that must pass after a job is closed before archiving the associated policy term. Jobs are
associated with policy periods.
Default: 90

DomainGraphKnownUnreachableTables
Use to define a comma-separated list of relative names of entity types that are linked to the graph through a nullable
foreign key. This can be problematic because the entity can become unreachable from the graph if the foreign key is
null. Naming the type in this configuration parameter suppresses the warning that would otherwise be generated for
the type by the domain graph validator
Default: None

Assignment parameters
Guidewire provides the following configuration parameters in the [Link] file that relate to assignment.
For information on editing [Link] and setting configuration parameters, see “Working with configuration
parameters” on page 41.

AssignmentQueuesEnabled
Whether to display the PolicyCenter interface portions of the assignment queue mechanism. If you turn this on, you
cannot turn it off again while working with the same database.
Default: false
Application configuration parameters 45
Guidewire PolicyCenter 9.0.9 Configuration Guide

Batch process parameters

Guidewire provides the following configuration parameters in the [Link] file that relate to batch processing.
For information on editing [Link] and setting configuration parameters, see “Working with configuration
parameters” on page 41.

BatchProcessHistoryPurgeDaysOld
Number of days to retain batch process history before PolicyCenter deletes it.
Default: 45

CleanupETLPurgeRoot
Minimum number of days that must pass after a purge event has occurred for the request to be eligible for delete by
the Cleanup ETLPurgeRoot process.
Default: 180

Business calendar parameters

Guidewire provides the following configuration parameters in the [Link] file that relate to defining a business
calendar.
For information on editing [Link] and setting configuration parameters, see “Working with configuration
parameters” on page 41.

BusinessDayDemarcation
The time at which a business day begins.
Default: 12:00 AM
Set For Environment: Yes

BusinessDayEnd
Indicates the time at which the business day ends.
Default: 5:00 PM
Set For Environment: Yes

BusinessDayStart
Indicates the time at which the business day starts.
Default: 8:00 AM
Set For Environment: Yes

BusinessWeekEnd
The day of the week considered to be the end of the business week.
Default: Friday
Set For Environment: Yes

HolidayList (obsolete)
This parameter is obsolete. Do not use it. Previously, you would use this to generate a comma-delimited list of
dates to consider as holidays. Instead, use the Administration screen within Guidewire PolicyCenter to manage the
46 chapter 2: Application configuration parameters
 Guidewire PolicyCenter 9.0.9 Configuration Guide

official designation of holidays. Guidewire retains this configuration parameter to facilitate upgrade from older
versions of PolicyCenter.

IsFridayBusinessDay
Indicates whether Friday is a business day.
Default: true
Set for Environment: Yes

IsMondayBusinessDay
Indicates whether Monday is a business day.
Default: true
Set for Environment: Yes

IsSaturdayBusinessDay
Indicates whether Saturday is a business day.
Default: false
Set for Environment: Yes

IsSundayBusinessDay
Indicates whether Sunday is a business day.
Default: false
Set for Environment: Yes

IsThursdayBusinessDay
Indicates whether Thursday is a business day.
Default: true
Set for Environment: Yes

IsTuesdayBusinessDay
Indicates whether Tuesday is a business day.
Default: true
Set for Environment: Yes

IsWednesdayBusinessDay
Indicates whether Wednesday is a business day.
Default: true
Set for Environment: Yes

MaxAllowedDate
The latest date allowed to be used.
Default: 2200-12-31
Set For Environment: Yes
Application configuration parameters 47
Guidewire PolicyCenter 9.0.9 Configuration Guide

MinAllowedDate
The earliest date allowed to be used.
Default: 1800-01-01
Set For Environment: Yes

Business rules parameters

Guidewire provides the following configuration parameters in the [Link] file that relate to the business rules.
Business rules, which you manage through the PolicyCenterAdministration tab, are distinct from Gosu rules, which
you manage through Guidewire Studio.
For information on editing [Link] and setting configuration parameters, see “Working with configuration
parameters” on page 41.

See also
• Application Guide

BizRulesCacheStaleTimeMinutes
Time (in minutes) that PolicyCenter retains rule data in the RuleVersion cache before it considers cached items to
be stale and thus eligible for reaping.
PolicyCenter initializes the RuleVersion cache once, at server start up. It then rebuilds the cache every time the
following entities change:
• RuleHead
• RuleVersion
• Rule
Default: 60
Minimum: 1
Maximum: 120
Set for Environment: Yes

BizRulesDeploymentEnabled
Determines whether it is necessary to explicitly deploy a business rule before PolicyCenter can evaluate the rule. If
you set the value of this parameter to true, you must also provide a value for configuration parameter
BizRulesDeploymentId.

IMPORTANT Always set this parameter to true in a production environment.

It is possible to disable the requirement for rule deployment in a test or development environment, by setting
BizrulesDeploymentEnabled to false. In a non-production environment, if you do not enable business rule
deployment, PolicyCenter evaluates all enabled and valid rules at runtime, including rules in the draft state.
Default: false

BizRulesDeploymentId
Unique string identifier of the server to which you intend to deploy the business rules. There is no default value for
this parameter. If the value of BizRulesDeploymentEnabled is true, then you must supply a value for this
parameter. Otherwise, the server generates an error during server start and refuses to start. PolicyCenter ignores this
configuration parameter if the value of BizRulesDeploymentEnabled is false.
It is possible to change the value of this parameter through a server restart. However, if you change the value of
BizRulesDeploymentId, PolicyCenter does not update already deployed rule versions.
48 chapter 2: Application configuration parameters
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Guidewire recommends, in a production environment, that you have a single BizRulesDeploymentId value for the
entire production cluster. This action guarantees that all nodes in the cluster use the same BizRulesDeploymentId
parameter value. Using the same value on all cluster nodes ensures that rule deployment works consistently across
all nodes in the cluster. You can choose any name for this value if you use only a single PolicyCenter production
cluster. For example, if all nodes in a cluster point to a single database, you can use the database ID as the
BizRulesDeploymentId value.
However, if you use multiple production clusters, each separate cluster must have its own unique value for this
configuration parameter. PolicyCenter expressly does not permit you to import business rules from another cluster
instance that has the same BizRulesDeploymentId value as the cluster instance into which you are importing the
rules.
PolicyCenter associates the BizRulesDeploymentId value (name) with a rule during its deployment. Thus, if you
deploy the rule in one production cluster, the name appears along with the rule version number in other production
clusters to identify that the rule was deployed in a particular production cluster. For example, if the value of
BizRulesDeploymentId is GW100-A, the rule version appears as 1.GW100-A in all other production clusters.
Default: None

See also
• System Administration Guide

BizRulesImportBootstrapRules
Whether PolicyCenter imports the business rules located in folder config/import/bizrules on starting the
application server with an empty database. Set the value of this parameter to true to import the files located in the
bizrules folder.

IMPORTANT Guidewire recommends that you set the value of this configuration parameter to true in
a non-production test environment only.

Default: false

See also
• System Administration Guide

BizRulesLeafSearchNumOfHops
Maximum number of hops for a leaf search to search through in suggesting matching results. This parameter refers
to the autocomplete feature of the Rule Condition editor on the Business Rules detail screens.
In the following expression, A is the root, B is a single hop, and c is a leaf.
A.B.c

The following example illustrates a two hop expression, with the root being office and PhoneNumber the leaf.
[Link][0].[Link]

Default: 3

BulkLoadRuleHeadByIdCacheEnabled
The Rule Head cache stores the RuleHead IDs for all business rules used in the application. If not configured to do
otherwise, PolicyCenter populates this cache using multiple database queries. The use of multiple queries can
greatly impact the performance of the business rules. However, if you set this configuration parameter to true,
PolicyCenter uses a single database query to bulk load the cache, thereby significantly improving the performance of
the business rules.
Application configuration parameters 49
Guidewire PolicyCenter 9.0.9 Configuration Guide

This parameter can take the following values:

• true - PolicyCenter uses a single query to populate the Rule Head cache.
• false - PolicyCenter uses multiple queries to populate the Rule Head cache.
Note: For information on how to bulk load the Rule Head cache at server start, see the System
Administration Guide.
Default: true

PreloadBizRulesBeansCacheEnabled
The Rule Entities cache stores the entities that comprise the entire rule graph for all rule versions that can possibly
execute in the application. If not configured to do otherwise, PolicyCenter populates this cache using multiple
database queries. The use of multiple queries can greatly impact the performance of the business rules. However, if
you set this configuration parameter to true, PolicyCenter uses a single database query to bulk load the cache,
thereby significantly improving the performance of the business rules.
This parameter can take the following values:
• true - PolicyCenter uses a single query to preload the Rule Entities cache with business rule entities from the
database.
• false - PolicyCenter uses multiple queries during rule execution to fetch the necessary business rule entities.
Note: For information on how to bulk load the Rule Entities cache at server start, see the System
Administration Guide.
Default: true

Cache parameters
Guidewire provides the following configuration parameters in the [Link] file that relate to the application
cache.
For information on editing [Link] and setting configuration parameters, see “Working with configuration
parameters” on page 41.

See also
• System Administration Guide

ExchangeRatesCacheRefreshIntervalSecs
The time between refreshes of the ExchangeRateSet cache, in seconds. This integer value must be 0 or greater. See
the System Administration Guide for more information.
Default: 600

GlobalCacheActiveTimeMinutes
Time period (in minutes) in which PolicyCenter considers cached items as active, meaning that Guidewire
recommends that the cache give higher priority to preserve these items. You can think of this as the period during
which PolicyCenter is using one or more items very heavily. For example, this can be the length of time that a user
stays on a page. The maximum value for this parameter is the smaller of 15 and the value of
GlobalCacheStaleTimeMinutes.
See the System Administration Guide for more information.
Default: 5
Minimum: 1
Maximum: 15
Set for Environment: Yes
50 chapter 2: Application configuration parameters
 Guidewire PolicyCenter 9.0.9 Configuration Guide

GlobalCacheDetailedStats
Configuration parameter GlobalCacheDetailedStats determines whether to collect detailed statistics for the global
cache. Detailed statistics are data that PolicyCenter collects to explain why items are evicted from the cache.
PolicyCenter collects basic statistics, such as the miss ratio, regardless of the value of this parameter.
In the base configuration, Guidewire sets the value of the GlobalCacheDetailedStats parameter to false. Set the
parameter to true to help tune your cache.
At runtime, use the PolicyCenter Management Beans page to enable the collection of detailed statistics for the global
cache. If you disable the GlobalCacheDetailedStats parameter, PolicyCenter does not display the Evict Information
and Type of Cache Misses graphs.
Default: false
Dynamic: Yes
Required: Yes

GlobalCacheReapingTimeMinutes
Time (in minutes) since the last use before PolicyCenter considers cached items to be eligible for reaping. You can
think of this as the period during which PolicyCenter is most likely to reuse and entity. See the System
Administration Guide for more information.
Default: 15
Minimum: 1
Maximum: 15
Set for Environment: Yes

GlobalCacheSizeMegabytes
The amount of space to allocate to the global cache. If you specify this value, it takes precedence over
GlobalCacheSizePercent. See the System Administration Guide for more information.
Nullable: Yes
Set for Environment: Yes

GlobalCacheSizePercent
The percentage of the heap to allocate to the global cache. See the System Administration Guide for more
information.
Default: 15
Set for Environment: Yes

GlobalCacheStaleTimeMinutes
Time (in minutes) since the last write before PolicyCenter considers cached items to be stale and thus eligible for
reaping. See the System Administration Guide for more information.
Default: 60
Minimum: 1
Maximum: 120
Set for Environment: Yes
Dynamic: Yes
Application configuration parameters 51
Guidewire PolicyCenter 9.0.9 Configuration Guide

GlobalCacheStatsRetentionPeriodDays
Time period (in days), in addition to today, for how long PolicyCenter preserves statistics for historical comparison.
See the System Administration Guide for more information.
Default: 7
Minimum: 2
Maximum: 365
Set for Environment: Yes

GlobalCacheStatsWindowMinutes
Time period (in minutes). PolicyCenter uses this parameter for the following purposes:
• To define the period of time to preserve the reason for which PolicyCenter evicts an item from the cache, after
the event occurred. If a cache miss occurs, PolicyCenter looks up the reason and reports the reason in the Cache
Info page.
• To define the period of time to display statistics on the chart on the Cache Info page.
See the System Administration Guide for more information.
Default: 30
Minimum: 2
Maximum: 120
Set for Environment: Yes

GroupCacheRefreshIntervalSecs
The time in seconds between refreshes of the group cache. This integer value must be 0 or greater. See the System
Administration Guide for more information.
Default: 600

ScriptParametersRefreshIntervalSecs
The time between refreshes of the script parameter cache, in seconds. This integer value must be 0 or greater. See
the System Administration Guide for more information.
Default: 600

TreeViewRefresh
The time in seconds that Guidewire PolicyCenter caches a tree view state.
Default: 120

ZoneCacheRefreshIntervalSecs
The time between refreshes of the zone cache, in seconds. See the System Administration Guide for more
information.
Default: 86400

Clustering parameters
Guidewire provides the following configuration parameters in the [Link] file that relate to the application
clusters.
52 chapter 2: Application configuration parameters
 Guidewire PolicyCenter 9.0.9 Configuration Guide

To improve performance and reliability, you can install multiple PolicyCenter servers in a configuration known as a
cluster. A cluster distributes client connections among multiple PolicyCenter servers, reducing the load on any one
server. If one server fails, the other servers transparently handle its traffic.
For information on editing [Link] and setting configuration parameters, see “Working with configuration
parameters” on page 41.

See also
• System Administration Guide

ClusteringEnabled
Whether to enable clustering on this application server.

Studio Read‐only Mode

If you set the value of ClusteringEnabled to true in file [Link] on a particular application server and then
restart the associated Studio, Studio becomes effectively read-only. In this context, read-only means:
• It is not possible to modify a Studio-managed resource. This applies, for example, to files that you open in the
Gosu or Rules editor.
• If it is possible to modify a Studio-managed resource, it is not possible to save any modification you make to that
resource. This applies, for example, to files that you open in the PCF editor.
To indicate the read-only status:
• Studio displays a padlock icon on the status bar that is visible only if Studio is in read-only mode. If you click the
icon, Studio displays a modal message box indicating the reason why it is in read-only mode.
• Studio disables the Save button any time that Studio is in read-only mode.
• Studio changes the Save button tooltip in read-only mode to display the reason that save is not active in this
mode. This is the same message that Studio shows if you click the padlock icon on the status bar.
Setting the value of configuration parameter “ResourcesMutable” on page 63 to false provides the same Studio
read-only behavior.
Default: false
Set for Environment: Yes

See also
• “ResourcesMutable” on page 63

ClusterMemberPurgeDaysOld
The number of days to keep cluster member records before they can be deleted.
Default: 30
Minimum value: 1
Required: true

ClusteringProductModelUpdateMaxRetries
Note: This configuration parameter has no meaning unless configuration parameter
ClusteringEnabled is set to true.
Sets the maximum number of retries for each cluster node to perform synchronized product model update
operations. In a multi-node PolicyCenter cluster, you install product model changes on one server, then start that
server to force the upgrade changes. After the first server completes the upgrade process, you can then start the other
nodes in the server cluster simultaneously. Due to the number of concurrent server starts, it is possible for there to be
contention for the shared update lock while updating the PolicyCenter product model on each node. This
Application configuration parameters 53
Guidewire PolicyCenter 9.0.9 Configuration Guide

configuration parameter sets the maximum number of times that a server node attempts to acquire the update lock
before failing.
This parameter works in conjunction with ClusteringProductModelUpdateRetryTimeout and
ClusteringProductModelUpdateSleepTimeCeiling. See ClusteringProductModelUpdateSleepTimeCeiling
for an explanation of how these parameters interact.
Default: 25 (retries)

ClusteringProductModelUpdateRetryTimeout
Note: This configuration parameter has no meaning unless configuration parameter
ClusteringEnabled is set to true.
Sets the time between successive attempts (retries) by a server node to perform synchronized product model update
operations. In a multi-node PolicyCenter cluster, you install product model changes on one server, then start that
server to force the upgrade changes. After the first server completes the upgrade process, you can then start the other
nodes in the server cluster simultaneously. Due to the number of concurrent server starts, it is possible for there to be
contention for the shared update lock while updating the PolicyCenter product model on each node. This
configuration parameter sets the time to wait between successive attempts to acquire the update lock.
Each node in the server cluster uses the following algorithm to calculate the timeout before the next retry attempt. In
this equation, TIMEOUT is the value of ClusteringProductModelUpdateRetryTimeout and n is the value of
ClusteringProductModelUpdateMaxRetries.
(TIMEOUT) + (2 * TIMEOUT) + ... + ((n-1) * TIMEOUT) + (n * TIMEOUT)
This parameter works in conjunction with ClusteringProductModelUpdateMaxRetries and
ClusteringProductModelUpdateSleepTimeCeiling. See ClusteringProductModelUpdateSleepTimeCeiling
for an explanation of how these parameters interact.
Default: 5000 (milliseconds)

ClusteringProductModelUpdateSleepTimeCeiling
Note: This configuration parameter has no meaning unless configuration parameter
ClusteringEnabled is set to true.
Sets the maximum time between successive attempts (retries) by a server node to perform synchronized product
model update operations. In a multi-node PolicyCenter cluster, you install product model changes on one server,
then start that server to force the upgrade changes. After the first server completes the upgrade process, you can then
start the other nodes in the server cluster simultaneously. Due to the number of concurrent server starts, it is possible
for there to be contention for the shared update lock while updating the PolicyCenter product model on each node.
Each cluster server uses a retry/back-off approach in which each retry causes an increasing sleep time delay on that
node. This configuration parameter sets the maximum allowable sleep time between successive attempts to acquire
the update lock. PolicyCenter uses the minimum of the calculated sleep time and this parameter value to calculate
the sleep time for each cluster node for each retry.
This parameter works in conjunction with ClusteringProductModelUpdateMaxRetries and
ClusteringProductModelUpdateRetryTimeout. The following table illustrates the connections between these
three configuration parameters.

Parameter Default Effect

Value
ClusteringProductModelUpdateMaxRetries 25 retries The server attempts to acquire the database lock and
fails. It then tries another n‐1 times to acquire the lock
until it is either successful or reaches the maximum
number of permitted retries (n), at which point the
lock acquisition fails.
ClusteringProductModelUpdateRetryTimeout 5 seconds The first retry attempt to acquire the lock occurs 5000
ms or 5 seconds after the first attempt. The second
retry occurs 10 seconds (2 * 5) after the second
54 chapter 2: Application configuration parameters
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Parameter Default Effect

Value
attempt. The third retry occurs after 15 seconds (3 * 5).
This pattern repeats until the 9th retry, after which the
time between successive retries increases to 50
seconds (10 * 5).
ClusteringProductModelUpdateSleepTimeCeiling 50 seconds After the calculated time between retries equals the
value of the sleep time ceiling, PolicyCenter waits this
amount of time between all succeeding retry attempts
until the lock process either succeeds or fails.

Default: 50000 (milliseconds)

ConfigVerificationEnabled
Whether to check the configuration of this server against the other servers in the cluster. You must also set
configuration parameter ClusteringEnabled to true for ConfigVerificationEnabled to be meaningful.

WARNING Guidewire does not support disabling the ConfigVerificationEnabled parameter in

a production environment. Do not set this parameter to false unless specifically instructed to do
so by Guidewire Support.

Default: true
Set for Environment: Yes

PDFMergeHandlerLicenseKey
Provides the BFO (Big Faceless Organization) license key needed for server-side PDF generation. If you do not
provide a license key for a server, each generated PDF from that server contains a a large DEMO watermark on its
face. The lack of a license key does not, however, prevent document creation entirely.
It is possible to set this value differently for each server node in the cluster.
Default: None

SerializationWhitelistEnabled
Whether PolicyCenter permits only those Java classes placed on a serialization whitelist to be deserialized. In some
situations, it is possible for deserialized Java objects from untrusted sources to be used to perform remote code
invocation attacks against a Guidewire application server.
For this configuration parameter:
• If disabled, PolicyCenter permits any Java class sent over a cluster channel to be deserialized, except for those
classes specifically placed on a black (forbidden) list.
• If enabled, PolicyCenter permits only those Java classes placed on a white list to be deserialized if sent over a
cluster channel. If enabled, it is not possible to place any class on the black list on the white list as well.
You define the permitted (whitelist) and forbidden (blacklist) Java classes in the following configuration files:
• [Link]
• [Link]
The Server Tools Serialization Info screen (under Info Pages) provides a means of monitoring the deserialization of Java
classes.
Default: false
Application configuration parameters 55
Guidewire PolicyCenter 9.0.9 Configuration Guide

See also
• System Administration Guide

Database parameters
Guidewire provides the following configuration parameters in the [Link] file that relate to the application
database.
For information on editing [Link] and setting configuration parameters, see “Working with configuration
parameters” on page 41.

DisableHashJoinPolicySearch
On an Oracle database, you can improve the performance of a policy search—if the search criteria include a first
name, last name or a company name—by disabling a Hash Join.
Default: true

DisableIndexFastFullScanForPolicySearch
On Oracle, you can improve the performance of a policy search—if the search criteria include a first name, last
name or a company name—by disabling an Index Fast Full Scan. This parameter has no effect on databases other
than Oracle.
Default: true

DisableSequenceUtil
Disables the sequence utility class [Link]. Use this to ensure that any sequences
in your code use some alternative mechanism for sequenced identifiers.
Default: false

DisableSortMergeJoinPolicySearch
On Oracle, you can improve the performance of a policy search—if the search criteria include a first name, last
name or a company name—by disabling a Sort Merge Join. This parameter has no effect on databases other than
Oracle.
Default: true

DiscardQueryPlansDuringStatsUpdateBatch
Whether to instruct the database to discard existing query plans during a database statistics batch process.
Default: false

IdentifyQueryBuilderViaComments
(SQL Server only.) Whether to provide comments with contextual information in certain SQL Select statements
sent to the relational database. The comments are generated by instrumentation in higher level database objects
created by using the query builder APIs.
The SQL comments are in the following format:
/* applicationName:ProfilerEntryPoint */

The applicationName component of the comment is PolicyCenter.

The ProfilerEntryPoint component of the comment is the name of an entry point known to the Guidewire
profiler for that application. For example, ProfilerEntryPoint might have the value WebReq:ClaimSearch.
56 chapter 2: Application configuration parameters
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Default: true

See also
• Gosu Reference Guide

IdentifyORMLayerViaComments
(SQL Server only.) Whether to provide comments with contextual information in certain SQL Select statements
sent to the relational database. The comments are generated by instrumentation in lower level objects, such as beans,
typelists, and other database building blocks.
The SQL comments are in the following format:
/* applicationName:ProfilerEntryPoint */

The applicationName component of the comment is PolicyCenter.

The ProfilerEntryPoint component of the comment is the name of an entry point known to the Guidewire
profiler for that application. For example, ProfilerEntryPoint might have the value WebReq:ClaimSearch.
Default: false

See also
• Gosu Reference Guide

MigrateToLargeIDsAndDatetime2
(SQL Server only.) Use to control whether to migrate to large 64-bit IDs in the database while upgrading. Migrating
to 64-bit IDs is an expensive operation. Also updates timestamps to use the data type Datetime2.
Default: true

UseOracleHintsOnMessageQueries
An Oracle database can experience improved performance if Oracle hints are used on queries for Message objects.
This parameter affects Oracle databases only.
Default: true

Data destruction parameters

Guidewire provides configuration parameters in the [Link] file that relate to destruction of data. In the base
configuration of PolicyCenter, data destruction is not enabled. You must set configuration parameters to enable data
destruction.

See also
• “Data destruction configuration parameters” on page 709
• “Working with configuration parameters” on page 41.

ArchiveReferenceTrackingEnabled
A Boolean string that controls whether Guidewire PolicyCenter uses reference tracking during an archive operation.
During an archive operation, if this value is true, PolicyCenter stores references to objects outside an archive graph
in a specific table. The purpose of this table is to allow for the purging of non- archive graphs.
Set this value to true. If you have already archived policies before setting this parameter to true, then you must run
the ArchiveReferenceTrackingSync batch process in order to add reference tracking for previously archived
Application configuration parameters 57
Guidewire PolicyCenter 9.0.9 Configuration Guide

documents. The ArchiveReferenceTrackingSync batch process must first complete for each previously archived
document before you can use personal data purge.

ContactDestructionRequestAgeForPurgingResults
Used by the RemoveOldContactDestructionRequest work queue to determine the age of
PersonalDataDestructionRequest objects that have a status of Finished. In the base configuration, this parameter
is set to 10 days.

See also

PersonalDataDestructionEnabled
Set this parameter to true to enable destruction of personal data. In the base configuration, this parameter is false.
The server will not start if both PersonalDataDestructionEnabled and DisableDomainGraphSupport parameters
are true.

Desktop and team parameters

Guidewire provides the following configuration parameters in [Link] that relate to the Desktop and Team tabs.
For information on editing [Link] and setting configuration parameters, see “Working with configuration
parameters” on page 41.

ActivityStatisticsWindowSize
Time window to capture activity statistics.
Default: 0

OtherWorkOrdersStatisticsWindowSize
Time window that the Team tab uses to calculate statistics for work orders other than renewals and submissions.
Possible values are:

0 Use this week as the window, defined as the start of the current business week until now.
‐1 Use this month as the window, defined as the start of the current month until now.
Any positive integer N The window is the last N days of activity, including the current day.

Default: 0

See also
• “Setting the window size for team statistics” on page 628
• Application Guide

RenewalsStatisticsWindowSize
Time window that the Team tab uses to calculate renewal statistics. Possible values are:

0 Use this week as the window, defined as the start of the current business week until now.
‐1 Use this month as the window, defined as the start of the current month until now.
Any positive integer N The window is the last N days of activity, including the current day.

58 chapter 2: Application configuration parameters

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Default: 0

See also
• “Setting the window size for team statistics” on page 628
• Application Guide

SearchActivityThresholdDays
This parameter controls the threshold within which an activity must have been modified to qualify a job as being
assigned to a user. The UpdateTime field on an activity contains a timestamp of when the activity was last modified.
The activity must have been modified within SearchActivityThresholdDays days before the current date.
Default: 366

See also
• “Configuring the Team tab” on page 627
• Application Guide

SubmissionsStatisticsWindowSize
Time window that the Team tab uses to calculate submission statistics. Possible values are:

0 Use this week as the window, defined as the start of the current business week until now.
‐1 Use this month as the window, defined as the start of the current month until now.
Any positive integer N The window is the last N days of activity, including the current day.

Default: 0

See also
• “Setting the window size for team statistics” on page 628
• Application Guide

TeamScreenTabVisibilityRowCountCutoff
This parameter sets the maximum number of rows on the Team tab screens. Increasing this parameter potentially
increases the amount of time that PolicyCenter takes to render the Team screens. If the results exceed the value of
this parameter, then PolicyCenter displays a message on that screen and does not display the results.
If you select an individual user, PolicyCenter always displays the filtered results even if the number of results
exceeds the cutoff parameter.
Default: 200
• “Setting the maximum number of rows on the Team screens” on page 630
• Application Guide

Document creation and document management parameters

Guidewire provides configuration parameters in the [Link] file that relate to document creation and
management.
Application configuration parameters 59
Guidewire PolicyCenter 9.0.9 Configuration Guide

See also

• “Working with configuration parameters” on page 41

• Application Guide

DisplayDocumentEditUploadButtons
Whether the Documents list displays Edit and Upload buttons. Set this parameter to false if the
IDocumentContentSource integration mechanism does not support it.
Default: true

DocumentContentDispositionMode
The Content-Disposition header setting to use when PolicyCenter returns document content directly to the
browser. Supported settings are inline and attachment.
Default: inline

DocumentTemplateDescriptorXSDLocation
The path to the XSD file that PolicyCenter uses to validate document template descriptor XML files. Specify this
location relative to the following directory:
modules/configuration/config/resources/doctemplates

FinalDocumentsNotEditable
Indicates whether documents with Final status can be transferred by using the Asynchronous implementation of the
IDocumentContentSource plugin. A value of false indicates that documents with Final status can be transferred. A
value of true indicates that documents with Final status cannot be transferred.
Default: false

MaximumFileUploadCount
The maximum number of document content files that can be listed and uploaded at once. The number of files listed
for upload can affect the performance of the upload screen.
Default: 200

MaximumFileUploadSize
The maximum allowable size in megabytes for a document file that you can upload to the server. Attempting to
upload a file larger than this size results in failure. Because the uploaded document must be handled on the server,
this parameter protects the server from possible memory consumption problems.
Default: 150 MB

MaximumTotalUploadSize
The maximum allowable total size in megabytes per session for documents uploads that are pending commitment to
the document management system. Because multiple documents can be uploaded at once, this value also provides
control of the overall size of an upload and protects the server from possible memory consumption problems.
Default: 150 MB
60 chapter 2: Application configuration parameters
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Environment parameters
Guidewire provides the following configuration parameters in the [Link] file that relate to the application
environment.
For information on editing [Link] and setting configuration parameters, see “Working with configuration
parameters” on page 41.

AddressVerificationFailureAsError
Set to true to have address verification failures shown as errors instead of warnings. This parameter has no effect if
EnableAddressVerification is set to false.
Default: false

See also
• “EnableAddressVerification” on page 62

AlwaysShowPhoneWidgetRegionCode
Whether the phone number widget in the application user interface always displays a selector for phone region
codes.
Default: false
Set for Environment: Yes

CurrentEncryptionPlugin
Set this value to the name of the plugin that you intend to use to manage encryption. Typically, a Guidewire
installation has only a single implementation of an encryption plugin interface. However, you can, for example,
decide to implement a different encryption algorithm using a different implementation of the encryption interface as
part of an upgrade process. In this case, you must retain your old encryption plugin implementation in order to
support the upgrade.
To support multiple implementations of encryption plugins, PolicyCenter provides the CurrentEncryptionPlugin
configuration parameter. Set this configuration parameter to the EncryptionID of the encryption plugin currently in
use—if you have implemented multiple versions IEncryption plugin interface.
• If you do not provide a value for this configuration parameter, then data is unencrypted.
• If you create multiple implementations of a plugin interface, then you must name each plugin implementation
individually and uniquely.

IMPORTANT PolicyCenter does not provide an encryption algorithm. You must determine the best
method to encrypt your data and implement it.

Default: None

See also
• For information on using the Plugins Registry editor, see “Using the plugins registry editor” on page 133.
• Integration Guide

DeprecatedEventGeneration
Whether to use the now-deprecated event logic that had previously been available.
Default: false
Application configuration parameters 61
Guidewire PolicyCenter 9.0.9 Configuration Guide

EnableAddressVerification
Set this value to true to enable address verification warnings. Address verification checks that all the fields match
each other based on the zone data.
This parameter works in concert with the AddressVerificationFailureAsError parameter to show either a
warning or an error, as follows:
• If EnableAddressVerification is true and AddressVerificationFailureAsError is false, PolicyCenter
shows a warning message if verification against zone data fails.
• If EnableAddressVerification is true and AddressVerificationFailureAsError is true, PolicyCenter
shows an error message if verification against zone data fails.
• If EnableAddressVerification is false, PolicyCenter does not verify the address based on zone data.
Default: false

See also
• “AddressVerificationFailureAsError” on page 61

EnableInternalDebugTools
Make internal debug tools available to developers.
Default: false
Set for Environment: Yes

KeyGeneratorRangeSize
The number of key identifiers (as a block) that the server obtains from the database with each request. This integer
value must be 0 or greater.
As you create a new PolicyCenter object such as a Policy, PolicyCenter assigns it a key, or unique public identifier.
To ensure that keys are unique, the server requests an available key from the PolicyCenter database. If every server
in a cluster queried the database each time it needed a single key, performance would degrade.
Instead, use this configuration parameter to obtain a block of keys with a single request. For example, a server can
reserve a block of 100 keys, and then assign each key without needing to query the database again. The server
continues to assign the keys from a block until it uses all keys in that block.
The default value of 100 is large enough to prevent frequent database queries for more keys. It is also small enough
to not waste too many keys that the server reserves but never uses. The server discards allocated but unused keys as
it shuts down. Keys are 64-bit integers, so wasting a few keys is not an issue. The default value of 100 is reasonable
in most situations.
Default: 100

MemoryUsageMonitorIntervalMins
How often the PolicyCenter server logs memory usage information, in minutes. This is often useful for identifying
memory problems.
To disable the memory monitor, do one of the following:
• Set this parameter to 0.
• Remove this parameter from [Link].
Default: 0

PublicIDPrefix
The prefix to use for public IDs generated by the application. Generated public IDs are of the form prefix:id. This
id is the actual entity ID. Guidewire strongly recommends that you set this parameter to different values in
production and test environments to allow for the clean import and export of data between applications.
62 chapter 2: Application configuration parameters
 Guidewire PolicyCenter 9.0.9 Configuration Guide

This PublicIDPrefix must not exceed 9 characters in length. Use only letters and numbers. Do not use space
characters, colon characters, or any other characters that other applications might process or escape specially. Do not
specify a two-character value. Guidewire reserves for itself all public IDs that start with a two-character ID and then
a colon

IMPORTANT Guidewire reserves two-character public ID prefixes for its own current or future use.

Required: Yes
Default: None

ResourcesMutable
Indicates whether resource are mutable (modifiable) on this server. If you connect Studio to a remote server (on
which this parameter set to true), then Studio pushes resource changes to the remote server as you save local
changes. Guidewire strongly recommends that you set this value to false on a production server to prevent changes
to the configuration resources directory.
See also “RetainDebugInfo” on page 63.

Studio Read‐only Mode

If you set the value of ResourcesMutable to false in [Link] on a particular application server and then restart
the associated Studio, that Studio becomes effectively read-only. In this context, read-only means:
• It is not possible to modify a Studio-managed resource. This applies, for example, to files that you open in the
Gosu or Rules editor.
• If it is possible to modify a Studio-managed resource, it is not possible to save any modification you make to that
resource. This applies, for example, to files that you open in the PCF editor.
To indicate the read-only status:
• Studio displays a padlock icon on the status bar that is visible only if Studio is in read-only mode. If you click the
icon, Studio displays a modal message box indicating the reason why it is in read-only mode.
• Studio disables the Save button any time that Studio is in read-only mode.
• Studio changes the Save button tooltip in read-only mode to display the reason that save is not active in this
mode. This is the same message that Studio shows if you click the padlock icon on the status bar.
Setting the value of configuration parameter ClusteringEnabled to true provides the same Studio read-only
behavior.
Default: true

WARNING Guidewire recommends that you always set this configuration parameter to false in a
production environment. Setting this parameter to true has the potential to modify resources on a
production server in unexpected and possibly damaging ways.

See also
• “ClusteringEnabled” on page 53

RetainDebugInfo
Whether the production server retains debugging information. This parameter facilitates debugging from Studio
without a type system refresh.
• If set to true, PolicyCenter does not clear debug information after compilation.
• If set to false, the server does not retain sufficient debugging information to enable debugging. As a production
server does not recompile types, it is not possible to regenerate any debugging information.
Default: false
Application configuration parameters 63
Guidewire PolicyCenter 9.0.9 Configuration Guide

See also
• “ResourcesMutable” on page 63

StrictDataTypes
Controls whether PolicyCenter uses the pre-PolicyCenter 4.0 behavior for configuring data types, through the use of
the [Link] file.
• Set this value to false to preserve the existing behavior. This is useful for existing installations that are
upgrading but want to preserve the existing functionality.
• Set this value to true to implement the new behavior. This is use for new PolicyCenter installations that want to
implement the new behavior.

StrictDataTypes = true
If you set the StrictDataTypes value to true, then PolicyCenter:
• Does not permit decimal values to exceed the scale required by the data type. The setter throws a
[Link] if the scale is greater than that allowed by the data type. You are responsible
for rounding the value, if necessary.
• Validates field validator formats in both the PolicyCenter user interface and in the field setter.
• Validates numeric range constraints in both the PolicyCenter user interface and in the field setter.

StrictDataTypes = false
If you set the StrictDataTypes value to false, then PolicyCenter:
• Auto-rounds decimal values to the appropriate scale, using the RoundHalfUp method. For example, setting the
value 5.045 on a field with a scale of 2 sets the value to 5.05.
• Validates field validator formats in the interface but not at the setter level. For example, PolicyCenter does not
permit a field with a validator format of [0-9]{3}-[0-9]{2}-[0-9]{4} to have the value 123-45-A123 in the
interface. It is possible, however, to set a field to that value in Gosu code, for example. This enables you to
bypass the validation set in the interface.
• Validates numeric range constraints in the interface, but not at the setter level. For example, Guidewire does not
allow a field with a maximum value of 100 to have the value 200 in the interface. However, you can set the field
to this value in Gosu rules, for example. This enables you to bypass the validation set in the interface.
Default: true

TwoDigitYearThreshold
The threshold year value for determining whether to resolve a two-digit year to the earlier or later century.
Default: 50

UnreachableCodeDetection
Determines whether the Gosu compiler generates errors if it detects unreachable code or missing return statements.
Default: true

UnrestrictedUserName
By default, PolicyCenter uses the su user as the user with unrestricted permissions to do anything in PolicyCenter.
To set the unrestricted user to a different user, set the value of the UnrestrictedUserName parameter to that user’s
login name.
Default: su
64 chapter 2: Application configuration parameters
 Guidewire PolicyCenter 9.0.9 Configuration Guide

UseOldStylePreUpdate
Deprecated. This parameter has no effect in PolicyCenter.
Default: false

WarnOnImplicitCoercion
A value of true indicates that the Gosu compiler generates warnings if it determines that an implicit coercion is
occurring in a program.
Default: true

WebResourcesDir
Specifies the location of the Web resources directory under the root of the Tomcat configuration directory.
Default: resources

Financial parameters
Guidewire provides the following parameters in the [Link] file to help configure how PolicyCenter works with
monetary amounts.
For information on editing [Link] and setting configuration parameters, see “Working with configuration
parameters” on page 41.

See also
• Globalization Guide

Geocoding parameters
Guidewire provides the following configuration parameters in the [Link] file that relate to geocoding.
For information on editing [Link] and setting configuration parameters, see “Working with configuration
parameters” on page 41.

UseGeocodingInPrimaryApp
If true, PolicyCenter enables searching for nearby locations in the Reinsurance Management user interface.
ContactManager does not respond to this parameter.
Default: false

ProximitySearchOrdinalMaxDistance
A distance that provides an approximate bound to improve performance of an ordinal (nearest n items) proximity
search. This distance is in miles, unless you set UseMetricDistancesByDefault to true. This parameter has no
effect on radius (within n miles or kilometers) proximity searches or walking-the-group-tree-based proximity
assignment.
Default: 300

ProximityRadiusSearchDefaultMaxResultCount
The maximum number of results to return if performing a radius (within n miles or kilometers) proximity search.
This parameter has no effect on ordinal (nearest n items) proximity searches.
Default: 1000
Application configuration parameters 65
Guidewire PolicyCenter 9.0.9 Configuration Guide

UseMetricDistancesByDefault
If true, PolicyCenter uses kilometers and metric distances instead of miles and United States distances for location
searches. Set this parameter identically in both PolicyCenter and ContactManager.
Default:
false

Globalization parameters
Guidewire provides the following configuration parameters in the [Link] file that relate to globalization.
For information on editing [Link] and setting configuration parameters, see “Working with configuration
parameters” on page 41.

IMPORTANT If you integrate the core applications in Guidewire InsuranceSuite, you must set the
values of DefaultApplicationCurrency and MulticurrencyDisplayMode to be the same in each
application.

DefaultApplicationLanguage
Default display language for the application as a whole.

IMPORTANT This parameter setting is permanent. Once you set the parameter and then start the
server, you cannot change the value.

Default: en_US
Permanent: Yes

See also
• Globalization Guide

DefaultApplicationLocale
Default locale for regional formats in the application. You must set configuration parameter
DefaultApplicationLocale to a typecode contained in the LocaleType typelist.

IMPORTANT This parameter setting is permanent. Once you set the parameter and then start the
server, you cannot change the value.

Default: en_US
Permanent: Yes

See also
• Globalization Guide

DefaultApplicationCurrency
Default currency for the application. You must set configuration parameter DefaultApplicationCurrency to a
typecode contained in the Currency typelist, even if you configure PolicyCenter with a single currency. Guidewire
applications which share currency values must have the same DefaultApplicationCurrency setting in their
respective [Link] files. The default currency is sometimes known as the preferred currency.
66 chapter 2: Application configuration parameters
 Guidewire PolicyCenter 9.0.9 Configuration Guide

IMPORTANT This parameter setting is permanent. Once you set the parameter and then start the
server, you cannot change the value.

Default: usd
Permanent: Yes

See also
• Globalization Guide

DefaultRoundingMode
Sets the default rounding mode for monetary amount calculations.
The available choices are a subset of those supported by [Link], namely:
• UP
• DOWN
• CEILING
• FLOOR
• HALF_UP
• HALF_DOWN
• HALF_EVEN
Guidewire strongly recommends that you use one of the following:
• HALF_UP
• HALF_EVEN
You can access this value in Gosu code by using the following method:
[Link]()

IMPORTANT This parameter setting is permanent. Once you set the parameter and then start the
server, you cannot change the value.

Default: HALF_UP
Permanent: Yes
• Globalization Guide

MulticurrencyDisplayMode
Determines whether PolicyCenter displays currency selectors for monetary values. The following are the allowed
values for MulticurrencyDisplayMode:
• SINGLE
• MULTIPLE
In the base configuration of PolicyCenter, the value is set to SINGLE. You can change the value to MULTIPLE once
only. After you change the value to MULTIPLE, you cannot later change it back to SINGLE. If you change the value
back to SINGLE, subsequent attempts to start the server fail.
Default: SINGLE
Permanent: Semi-permanent

See also
• Globalization Guide
Application configuration parameters 67
Guidewire PolicyCenter 9.0.9 Configuration Guide

DefaultCountryCode
The default ISO country code that PolicyCenter uses if the country for an address is not set explicitly. PolicyCenter
also uses the value of this parameter as the default country code for new addresses that it creates. The country code
must be a valid ISO country code that exists as a typecode in the Country typelist.
See the following page to search a list of ISO country codes:
[Link]

DefaultPhoneCountryCode
The default ISO country code used for phone data.
Default: None

DefaultNANPACountryCode
The default country code for region 1 phone numbers. If the area code is not in the [Link] map file,
then it defaults to the value configured with this parameter.
Default: US

AlwaysShowPhoneWidgetRegionCode
Whether the phone number widget in the application user interface always displays a selector for phone region
codes.
Default: false

Integration parameters
Guidewire provides the following configuration parameters in the [Link] file that relate to how multiple
Guidewire applications integrate with each other.
For information on editing [Link] and setting configuration parameters, see “Working with configuration
parameters” on page 41.

BillingSystemArchiveEnabled
Whether or not the archiving is enabled in the billing system. This parameter needs to match billing system settings
for archiving.
Default: false

BillingSystemArchivePolicyPeriodDays
The minimum number of days after the term end date before the billing policy period is archived. This value must be
less than the setting in the billing system. This value must be less than or equal to the setting in the billing system.
Guidewire recommends setting the value to be equal and keeping the value of
BillingSystemArchivePolicyPeriodDays synchronized with the value of ArchivePolicyPeriodDays in
BillingCenter.
This parameter is used to decide whether to check the billing system for the archiving flag. A negative value
disables this check, and PolicyCenter ignores the archiving flag when determining whether to call the billing system
API. This parameter is applicable only if the BillingSystemArchiveEnabled parameter is true.
Default: -1
68 chapter 2: Application configuration parameters
 Guidewire PolicyCenter 9.0.9 Configuration Guide

BillingSystemURL
URL to use in ExitPoint PCF pages that view items in the billing system.
• If integrating Guidewire PolicyCenter with Guidewire BillingCenter, then set this parameter to the BillingCenter
base URL (for example, [Link] In this case, the exit points add the appropriate BillingCenter entry
point.
• If integrating with a non-Guidewire billing system, then you need to modify the ExitPoint PCF to set up the
parameters required by that system.
• If you omit this parameter or if you set it to an empty string, then PolicyCenter hides the buttons in the interface
that take you to the exit points.
Default: Empty string

See also
• Integration Guide

ClaimSystemURL
URL to use in ExitPoint PCF pages that view items in the claims system.
• If integrating Guidewire PolicyCenter with Guidewire ClaimCenter, then set this parameter to the ClaimCenter
base URL (for example, [Link] In this case, the exit points add the appropriate ClaimCenter entry
point.
• If integrating with a non-Guidewire claim system, then you need to modify the ExitPoint PCF to set up the
parameters required by that system.
• If you omit this parameter or if you set it to an empty string, then PolicyCenter hides the buttons in the interface
that take you to the exit points.
Default: Empty string

See also
• Integration Guide

DefaultXmlExportIEncryptionId
The unique encryption ID of an encryption plugin. If archiving is enabled, PolicyCenter uses the encryption plugin
to encrypt any encrypted fields during XML serialization.
Default: null (no encryption)

KeepCompletedMessagesForDays
Number of days after which PolicyCenter purges old messages in the message history table.
Default: 90

LockDuringDistributedMessageRequestHandling
When processing a distributed message transaction, the parameter determines whether to lock the transaction's
message object. The parameter has no effect on non-distributed message transactions.
Default: false

LockPrimaryEntityDuringMessageHandling
When processing a message transaction, the parameter determines whether to lock the primary entity instance
associated with the message. If the message has no primary entity associated with it, the parameter has no effect.
Application configuration parameters 69
Guidewire PolicyCenter 9.0.9 Configuration Guide

Regardless of the parameter's setting, the primary entity instance is locked only if the transaction's message object is
also locked. For example, a distributed message transaction that does not lock its message object will not lock the
primary entity either, even if locking of the entity is enabled by this parameter. Whether a distributed message
transaction locks its message object is determined by the LockDuringDistributedMessageRequestHandling
configuration parameter.

Considerations for production installations

In the base configuration, PolicyCenter (and ContactManager) do not update the primary entity while
acknowledging a message. Therefore, it is possible to set configuration parameter
LockPrimaryEntityDuringMessageHandling to false under the following conditions:
• You are not updating any entity on the acknowledgment of a message.
• You are only updating a very few fields on non-primary entities that do not cause a lock on a primary entity. The
non-primary entities must be mutually exclusive for destinations on the acknowledgment of a message.
Guidewire recommends that you review your integration code for these conditions before you set this configuration
parameter to false.
If you do set LockPrimaryEntityDuringMessageHandling to false, be aware that PolicyCenter does not lock the
primary entity during the following processes:
• Sending a message
• Handling all parts of a message
• Marking a message as skipped
However, PolicyCenter does lock the primary entity message creation.
Default: true

PaymentSystemURL
URL to use in ExitPoint PCF pages that view items in a payment system.
• If integrating Guidewire PolicyCenter with Guidewire BillingCenter, then set this parameter to the BillingCenter
base URL (for example, [Link] In this case, the exit points add the appropriate BillingCenter entry
point.
• If integrating with a non-Guidewire billing system, then you need to modify the ExitPoint PCF to set up the
parameters required by that system.
• If you omit this parameter or if you set it to an empty string, then PolicyCenter hides the buttons in the interface
that take you to the exit points.
Note: Guidewire configures this parameter in the base configuration to work with a demonstration
payment system. For more details, see the Integration Guide.
Default: pc

See also

• Integration Guide

PluginStartupTimeout
OSGi plugins startup timeout (in seconds). The PluginConfig component waits for at most this time for all required
OSGi plugins to start. The PluginConfig component reports an error for each OSGi plugin that does not start after
this timeout has expired.
Default: 60

70 chapter 2: Application configuration parameters

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Job expiration parameters

Guidewire provides the following configuration parameters in [Link] that relate to how PolicyCenter handles
jobs.
PolicyCenter provides a Job Expire (jobexpire) batch process that moves jobs from the New, Draft, or Quote status to
the Expired status. This process first examines all jobs that have a New, Draft, or Quote status. From this set of jobs, the
batch process expires the jobs that meet all of the following criteria:
• The job meets the expiration threshold.
• The job meets the creation threshold.
• The [Link] method returns true for that job type.
In the base configuration, this process moves Submission jobs to the Expired status if all of the following are true:
• The job status is either New, Draft, or Quote.
• The job is at least seven days past the effective date of the policy.
Setting the expiration and creation thresholds – Modify the following parameters to configure the expiration and
creation thresholds. If you enable both parameters, the job must meet both thresholds.
• “JobExpirationEffDateThreshold” on page 72 – The number of days past the policy effective date before the
batch process JobExpire expires a job.
• “JobExpirationCreateDateThreshold” on page 72 – The number of days past the job creation date before batch
process JobExpire expires a job.
Expiring different job types – You can also enable expiration for job types other than Submission. To facilitate this
process, PolicyCenter provides a number of Boolean configuration parameters of the following pattern:
JobExpirationCheck<JobType>

Job types – For this configuration parameter, <JobType> can be any of the following:
• Audit
• Cancellation
• Issuance
• PolicyChange
• Reinstatement
• Renewal
• Rewrite
• Submission
• TestJob
To enable the expiration of a particular job type, set JobExpirationCheck<JobType> to true for that particular job
type.

See also

• “Changing jobs to expired status” on page 731

• System Administration Guide

JobExpirationCheckAudit
Set to true to enable PolicyCenter to expire this job type. For audit jobs, you must override the canExpireJob
method in the [Link] class and modify it to return true. You can find this class in the Classes folder
in Studio.
Default: false
Application configuration parameters 71
Guidewire PolicyCenter 9.0.9 Configuration Guide

JobExpirationCheckCancellation
Set to true to enable PolicyCenter to expire this job type.
Default: false

JobExpirationCreateDateThreshold
Number of days past the job creation date before batch process JobExpire expires a job. Batch process JobExpire
first examines all jobs meeting the date criteria set by this parameter. In addition to this threshold, the job must also
meet the JobExpirationEffDateThreshold threshold. The batch process then expires those jobs for which
[Link] is true.
The job creation date is specified in [Link].
A value of -1 disables this parameter.

IMPORTANT Setting the create date threshold to a negative number effectively disables create date
checking, as it is not possible to create a job with a future create date. Disabling
JobExpirationCreateDateThreshold does not disable JobExpirationEffDateThreshold.

Default: -1

JobExpirationEffDateThreshold
Number of days past the job effective date before batch process JobExpire expires a job. Batch process JobExpire
first examines all jobs meeting the date criteria set by this parameter. In addition to this threshold, the job must also
meet the JobExpirationCreateDateThreshold threshold. The batch process then expires those jobs for which
[Link] is true.
The job effective date is the EditEffectiveDate of a PolicyPeriod on the Job. If the job has more than one policy
period, then each active policy period on the job must meet the threshold. You access the active policy periods on
the job through the [Link] array.
A negative value means that the batch process expires unbound jobs by that number of days before their effective
date is reached. For example, a value of -5 for this parameter indicates that jobs expire five days before their
effective date.
Default: 7

JobExpireCheckIssuance
Set to true to enable PolicyCenter to expire this job type.
Default: false

JobExpireCheckPolicyChange
Set to true to enable PolicyCenter to expire this job type.
Default: false

JobExpireCheckReinstatement
Set to true to enable PolicyCenter to expire this job type.
Default: false

JobExpireCheckRenewal
Set to true to enable PolicyCenter to expire this job type.
Default: false
72 chapter 2: Application configuration parameters
 Guidewire PolicyCenter 9.0.9 Configuration Guide

JobExpireCheckRewrite
Set to true to enable PolicyCenter to expire this job type.
Default: false

JobExpireCheckSubmission
Set to true to enable PolicyCenter to expire this job type.
Default: true

JobExpireCheckTestJob
Set to true to enable PolicyCenter to expire this job type.
Default: false

Lookup table parameters

For information on editing [Link] and setting configuration parameters, see “Working with configuration
parameters” on page 41.

AvailabilityContextCacheEntryExpirationTime
Lookup Table Manager uses a cache to improve performance of Product Model availability lookups. Cache entries
expire after a period of inactivity defined by this configuration parameter. Specify the expiration time in minutes.
Consider the performance impact before reducing the expiration time. Cache misses may result if entries have been
flushed.
Default: 1440 minutes (1 hour)
Required: No

AvailabilityContextCacheSize
The maximum size of the cache holding AvailabilityContexts after a lookup.
Default: 1000
Required: Yes

UsePolicyPeriodReferenceDateForOfferingAvailability
Whether to use written date or effective date for offerings availability. If true, use effective date. If false, use
written date.
Default: false
Required: No

Miscellaneous job‐related parameters

Guidewire provides the following configuration parameters in [Link] that relate to PolicyCenter jobs.
For information on editing [Link] and setting configuration parameters, see “Working with configuration
parameters” on page 41.

AllowedDaysBeforeOrAfterPolicyStartDate
Number of days, before or after a given policy period StartDate, to search for a non-cancelled bound
PolicyPeriod on which to base the renewal.
Application configuration parameters 73
Guidewire PolicyCenter 9.0.9 Configuration Guide

For example, if you need to rewrite a cancelled policy with an earlier start date, the most recent bound period is the
cancelled period. To renew such a policy, it must be possible to identify the rewrite. This parameter establishes the
windows in which to search for a rewritten policy.
• If the policy term is 6 months or longer, then the default of 90 days is acceptable.
• If the policy term is shorter, then use a smaller number for this parameter.
Default: 90

MaximumPolicyCreationYearDelta
Value, which added to the current year, represents the maximum year to use during policy creation. This integer
value must be 0 or greater.
Default: 1

MaxRecentAccounts
Maximum number of recent accounts that PolicyCenter shows in the Account tab.
Default: 5

MaxRecentPoliciesAndJobs
Maximum number of recent policies and jobs that PolicyCenter shows in the Policy tab.
Default: 8

MaxSubmissionsToCreate
Maximum number of submissions that PolicyCenter can create at one time in the New Submission page.
Default: 20

MinimumPolicyCreationYear
Minimum (earliest) year to use during policy creation. This integer value must be 1000 or greater.
Default: 1000

PatternCacheMaxDuration
Upper bound on how long PolicyCenter allows caches of pattern entities to exist without refresh, measured in
seconds.
Default: 86400

PolicyChangeMaxQuotes
Maximum number of allowable quotes for a policy change.
Default: 3

PurgeTemporaryPolicyPeriodsAfterDays
Minimum number of days that must pass before a temporary policy period can be purged.
Default: 14

PurgeTemporaryPolicyPeriodsEnabled
Enables Purge Temporary Policy Periods batch processing. If false, the work queue will not remove any temporary
policy periods.
74 chapter 2: Application configuration parameters
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Default: false

RenewalMaxQuotes
Maximum number of allowable quotes for a renewal.
Default: 3

RenewalProcessLeadTime
Lead time (in number of days) before the state non-renewal notification deadline to start renewals.
Default: 165

SubmissionMaxQuotes
Maximum number of allowable quotes for a submission.
Default: 3

Miscellaneous parameters
Guidewire provides the following configuration parameters in the [Link] file that relate to various
miscellaneous application features.
For information on editing [Link] and setting configuration parameters, see “Working with configuration
parameters” on page 41.

ConsistencyCheckerThreads
Number of threads to use when running the consistency checker.
Default: 1

DefaultDiffDateFormat
Sets the default format for dates in the difference tree user interface. Valid formats mirror the Java default date
formats:
• short
• medium
• long
• full
Default: short

DisableDomainGraphSupport
All PolicyCenter environments are expected to have valid data models. However, in rare situations, you might want
to upgrade a PolicyCenter environment that does not yet have a valid data model. If there are compelling business
reasons not to correct the data model during the upgrade, you can disable domain graph support by setting the
DisableDomainGraphSupport parameter to true.
Guidewire strongly recommends that you resolve domain graph issues at the earliest opportunity to minimize the
upgrade cost of the changes required to achieve a valid data model.
You cannot disable domain graph support if you are using archiving, quote purging, quote cloning, and personal data
destruction. These features require domain graph support. Therefore, PolicyCenter will not start if
DisableDomainGraphSupport is true and ArchiveEnabled or PersonalDataDestructionEnabled is true.
Default: false
Application configuration parameters 75
Guidewire PolicyCenter 9.0.9 Configuration Guide

IgnoreLeapDayForEffDatedCalc
In the default configuration, the IgnoreLeapDayForEffDatedCalc parameter determines whether PolicyCenter
ignores a leap day in the following calculations:
• Calculating scalable properties
• Prorating premiums for policies that are less than a full term
The following table describes the values for the IgnoreLeapDayForEffDatedCalc parameter:

Value Description
true PolicyCenter does not include the leap day while calculating the values for scalable properties or prorated premiums.
false PolicyCenter includes the leap day while calculating the scalable property amount or prorated premium.

In the default configuration, some scalable properties are OverrideAmount on the Cost entity and
ScalableBasisAmount on the GLExposure entity.
Default: true

Leap Days and Prorated Premiums Example

Assume that PolicyCenter needs to rate a policy change that affects the entire month of February in a year that
includes a leap day. If IgnoreLeapDayforEffDatedCalc is true, PolicyCenter ignores the leap day and prorates the
premium for 28 days. If false, PolicyCenter includes the leap day and prorates the premium for 29 days.
PolicyCenter prorates the premium in the proration plugin. It is possible to override the
IgnoreLeapDayForEffDatedCalc parameter by a parameter on the plugin. For more information, see the
Integration Guide.

InitialSampleDataSet
Optional set of sample data to load at server start up. This value must be a typecode from the SampleDataSet
typelist, or null. In the base application configuration, valid typecodes are:

Typecode Description
Tiny Just a few users like aapplegate, good for test purposes.
Small A small community model and a few sample Accounts and Policies, useful for local development.
Large A large, full data set useful for application demonstrations and manual Quality Assurance.

Set value to Tiny, Small, or Large, corresponding to the data set that you want to load:
• If there is no sample data loaded as the server starts, PolicyCenter loads the sample data set that you specify.
• If there is sample data, PolicyCenter does nothing.
Default: None
Set for Environment: Yes

PreloadSystemTableToCacheForFasterSynchronization
Enables or disables the pre-load of system tables at server start. To enable pre-loading, set this parameter to true.
Pre-loading the system tables at server start allows for faster synchronization and faster server startup times.
However, be aware that the use of system table pre-loading can require PolicyCenter to allocate additional heap
space.
Default: true
Required: Yes
76 chapter 2: Application configuration parameters
 Guidewire PolicyCenter 9.0.9 Configuration Guide

ProfilerDataPurgeDaysOld
Number of days to keep profiler data before PolicyCenter deletes it.
Default: 30

TransactionIdPurgeDaysOld
Number of days to keep external transaction ID records before they can be deleted.
Default: 30

Policy exception parameters

Guidewire provides the following configuration parameters in [Link] that limit how many days must pass
before the Policy Exception Rules run a second time on any given PolicyPeriod entity.

See also
• Rules Guide

BoundPolicyThresholdDays
The minimum number of days that must pass before the Policy Exception Rules run again on a bound
PolicyPeriod entity. This integer value must be 0 or greater.
Default: 14
Dynamic: Yes

ClosedPolicyThresholdDays
The minimum number of days that must pass before the Policy Exception Rules run again on a closed
PolicyPeriod entity. This integer value must be 0 or greater.
Default: 14
Dynamic: Yes

OpenPolicyThresholdDays
The minimum number of days that must pass before the Policy Exception Rules run again on an open
PolicyPeriod entity. This integer value must be 0 or greater.
Default: 1
Dynamic: Yes

PDF print settings parameters

Guidewire provides the following configuration parameters in the [Link] file that relate to the generation of
PDF files from PolicyCenter.
For information on editing [Link] and setting configuration parameters, see “Working with configuration
parameters” on page 41.

DefaultContentDispositionMode
The Content-Disposition header setting to use when PolicyCenter returns file content directly to the browser.
This parameter applies to printed and exported content. It does not apply to documents. For documents, use the
DocumentContentDispositionMode parameter. Supported settings are inline and attachment.
Application configuration parameters 77
Guidewire PolicyCenter 9.0.9 Configuration Guide

Default: attachment

PrintFontFamilyName
Use to configure FOP settings for printing non-U.S. character sets. (FOP refers to the Apache Formatting Objects
Processor.) Set this value to the name of the font family for custom fonts as defined in your FOP user configuration
file. For more information, refer to the following:
[Link]

Default: san-serif

PrintFontSize
Font size of standard print text.
Default: 10pt

PrintFOPUserConfigFile
Path to FOP user configuration file, which contains settings for printing non-U.S. character sets. (FOP refers to the
Apache Formatting Objects Processor.) Enter a fully qualified path to a valid FOP user configuration file. There is
no default. However, a typical value for this parameter is the following:
C:\fopconfig\[Link]

For more information, refer to the following:

[Link]

Default: None

PrintHeaderFontSize
Font size of headers in print text.
Default: 16pt

PrintLineHeight
Total size of a line of print text.
Default: 14pt

PrintListViewBlockSize
Use to set the number of elements in a list view to print as a block. This parameter splits the list into blocks of this
size, with a title page introducing each block of elements. A large block size consumes more memory during
printing, which can cause performance issues. For example, attempting to print a block of several thousand elements
can potentially cause an out-of-memory error.
Default: 20

PrintListViewFontSize
Font size of text within a list view.
Default: 10pt

PrintMarginBottom
Bottom margin size of print page.
78 chapter 2: Application configuration parameters
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Default: 0.5in

PrintMarginLeft
Left margin size of print page.
Default: 1in

PrintMarginRight
Right margin size of print page.
Default: 1in

PrintMarginTop
Top margin size of print page.
Default: 0.5in

PrintMaxPDFInputFileSize
During PDF printing, PolicyCenter first creates an intermediate XML file as input to a PDF generator. If the input is
very large, the PDF generator can run out of memory.

Value Purpose
Negative A negative value indicates that there is no limit on the size of the XML input file to the PDF generator.
Non‐ A non‐negative value limits the size of the XML input file to the set value (in megabytes). If a user attempts to
negative print a PDF file that is larger in size than this value, PolicyCenter generates an error.

Default: -1

PrintPageHeight
Total print height of page.
Default: 8.5in

PrintPageWidth
Total print width of page.
Default: 11in

PrintPdfDefaultBaseFileExtension
Default base output file extension for PDF documents.
Default: 11in

PrintPdfMimeType
MIME type used for generated PDF output files.
Default: application/pdf
Application configuration parameters 79
Guidewire PolicyCenter 9.0.9 Configuration Guide

Print settings parameters

Guidewire provides the following configuration parameters in the [Link] file that relate to printing from
PolicyCenter.
For information on editing [Link] and setting configuration parameters, see “Working with configuration
parameters” on page 41.

PrintCsvDefaultBaseFileExtension
Default base output file extension for CSV documents.
Default: csv

PrintCsvMimeType
MIME type used for generated CSV output files.
Default: application/excel

PrintDefaultBaseFileName
Default base output filename for output generation.
Default: Print

Product model parameters

Guidewire provides the following configuration parameters in [Link] that relate to the PolicyCenter product
model.
For information on editing [Link] and setting configuration parameters, see “Working with configuration
parameters” on page 41.

ExternalProductModelDirectory
Specifies the directory from which to load product model availability data. PolicyCenter loads the information in
this directory at server startup time or if requested through the Server Tools Product Model Info screen. For the load to
succeed, all of the following must true:
• The parameter specifies a directory accessible to the application server.
• The directory is not in the deployment directory.
• The directory contains a complete product model definition that only defines existing patterns.
• The directory contains at least one lookup XML file ending in -[Link].
• The XML files in the directory are all valid.
If this parameter is blank, PolicyCenter loads availability data from the standard configuration module at server
startup time. Any attempt to reload the data through the Server Tools Product Model Info screen then fails with an error
message.
Default: None
Dynamic: No

See also
• Product Model Guide
• System Administration Guide
80 chapter 2: Application configuration parameters
 Guidewire PolicyCenter 9.0.9 Configuration Guide

ProductModelClassCacheConcurrencyLevel
To fine tune performance, use this parameter to adjust the concurrency level of the product model class cache. This
cache is lazy-loaded when product model pattern objects, such as coverage patterns, are instantiated. See
[Link]#concurrencyLevel for more information about caches and
concurrency levels. The minimum value is 1. The maximum value is 100.
Default: 10
Dynamic: No

Quote purging configuration parameters

This topic describes quote purging configuration parameters related to purging jobs and pruning policy periods.
Purging removes jobs after a specified length of time has passed. The jobs must meet the purging criteria.
Pruning removes unselected policy periods attached to a job. The selected policy period is specified by the
SelectedVersion property on the Job entity. Unselected policy periods are any policy periods attached to the job
that are not the SelectedVersion.

See also
• “Configuring quote purging” on page 551
• Application Guide

PruneAndPurgeJobsEnabled
Specifies whether the Purge batch process is enabled.
Default: false

See also
• “Enable quote purging batch processes” on page 555

PruneVersionsDefaultRecheckDays
The minimum number of days that must pass after failing a purging check before reconsidering the unselected
policy periods on the job for pruning.
Default: 30

PruneVersionsPolicyTermDays
The minimum number of days that must pass after a job’s selected policy period has ended before the unselected
policy periods on the job are eligible for pruning. This parameter is ignored if
PruneVersionsPolicyTermDaysCheckDisabled is true.
Default: 30

PruneVersionsPolicyTermDaysCheckDisabled
If true, then disable the PruneVersionsPolicyTermDays parameter. Setting this parameter to true does not disable
pruning closed jobs.
Default: false

PruneVersionsRecentJobCompletionDays
The minimum number of days that must pass after a job is closed before the unselected policy periods on the job are
eligible for pruning.
Application configuration parameters 81
Guidewire PolicyCenter 9.0.9 Configuration Guide

Default: 210

PurgeJobsDefaultRecheckDays
The minimum number of days that must pass after failing a purging check before a job is reconsidered for purging.
Default: 30

PurgeJobsPolicyTermDays
The minimum number of days that must pass after the end of a job’s selected policy period before the job is eligible
for purging. This parameter is ignored if PurgeJobsPolicyTermDaysCheckDisabled is true.
Default: 30

PurgeJobsPolicyTermDaysCheckDisabled
If true, then disable the PurgeJobsPolicyTermDays parameter. Setting this parameter to true does not disable
purging closed jobs.
Default: false

PurgeJobsRecentJobCompletionDays
The minimum number of days that must pass after a job is closed before the job is eligible for purging.
Default: 210

PurgeOrphanedPolicyPeriodsEnabled
Specifies whether the Purge Orphaned Policy Periods batch process is enabled.
Default: false

See also
• “Enable quote purging batch processes” on page 555

Rating management parameters

Guidewire provides the following configuration parameters in the [Link] file that relate to Guidewire Rating
Management.

IMPORTANT To determine whether your Guidewire PolicyCenter license agreement includes

Guidewire Rating Management, contact your Guidewire sales representative. Rating Management
requires an additional license key. For instructions on obtaining and installing this key, contact your
Guidewire support representative.

EnableRateRoutinesJar
Set this Boolean parameter to true if you want rate routines to be preloaded from the rate routines JAR file at
system startup. This parameter also enables the Generate JAR File and Download JAR File buttons on the Rate Books
screen.
If you enable this parameter, then you must also specify the location in the RateRoutinesJarFile parameter.
Note:
Precompiling rate routine JAR file is not supported on JBoss application servers.
Default: false
82 chapter 2: Application configuration parameters
 Guidewire PolicyCenter 9.0.9 Configuration Guide

See also
• “Precompiling rate routines JAR file” on page 634

OverriddenTableArgsLabelSimple
You can speed up rate table preloading by setting the parameter OverriddenTableArgsLabelSimple to true. (The
RateBookPreloadEnabled parameter must also be true.)
When true, when viewing a rate routine on the Rate Routine screen, parameters in rate routine steps may appear as
ellipses (...).

PurgeRateBookExportResultEnabled
If true, enable Purge Rate Book Export Result batch processing.
Default: true

See also
• System Administration Guide

PurgeWorksheetsEnabled
Enable the Purge Rating Worksheets batch process.
Default: false

See also
• “Extract Rating Worksheets batch process” on page 660

RateBookExportResultAgeForPurging
Purge Rate Book Export Result batch processing removes from the PolicyCenter database RateBookExportResult
Excel and XML files that have been around for more days than this parameter.
Default: 60

See also
• System Administration Guide

RateBookPreloadEnabled
This parameter determines whether to load Rating Management components on system startup. If true,
PolicyCenter loads all rate books and their associated rate routines and rate tables on system startup.
Note: Unrelated to whether this parameter is true or false, PolicyCenter always preloads some parts
of rate books that load quickly. After this, PolicyCenter writes this message to the log file:
INFO [Link] Preloading all ratebooks

Therefore, this message is not an indication of the RateBookPreloadEnabled parameter setting.

Default: true

See also
• “Preloading Rating Management components” on page 633

RateRoutineIndexingThreshold
When editing a long rate routine, you can edit the rate routine by section. A long rate routine has more steps than the
value of the indexing threshold, the RateRoutineIndexingThreshold parameter.
Application configuration parameters 83
Guidewire PolicyCenter 9.0.9 Configuration Guide

Default: 150

See also
• Application Guide

RateRoutinesJarFile
Specify the file system location of the rate routines JAR file. May be an absolute path or path relative to the web
application root. For allowed locations, see Integration Guide. Guidewire recommends that you deploy the JAR file
in the following location:
modules/configuration/plugins/Gosu/lib/[Link]

For example, if you are running PolicyCenter under Apache Tomcat and the WAR file expands into
<TOMCAT_HOME>/webapps/pc, where <TOMCAT_HOME> is the Tomcat root directory, then set RateRoutinesJarFile
to webapps/pc/modules/configuration/plugins/Gosu/lib/[Link].
If the directory does not exist, PolicyCenter will attempt to create it. If the file exists, it must be a valid JAR file. If
the file does not exist, PolicyCenter will create it if EnableRateRoutinesJar is true. If the JAR does not exist at
startup, PolicyCenter compiles all rate routines in the rate books returned by the RateBookPreloadPlugin to the
JAR. To avoid this delay during startup, deploy the JAR file to the production system when you build PolicyCenter.
Note:
Precompiling rate routine JAR file is not supported on JBoss application servers.

See also
• “Precompiling rate routines JAR file” on page 634

RateRoutinesUpdateJarFile
Specify the location of the rate routines JAR file that is updated dynamically while PolicyCenter is running. If you
specify this parameter, PolicyCenter modifies the file referred to by it whenever an update event happens. If you do
not specify this parameter, PolicyCenter updates the file pointed to by RateRoutinesJarFile.
Note:
You must use this parameter if you are running PolicyCenter on Windows Server.
For allowed locations, see Integration Guide. Guidewire recommends that you deploy the JAR file in the following
location:
modules/configuration/plugins/Gosu/lib/rateroutines_update.jar

If the directory does not exist, PolicyCenter attempts to create it.

Modify the startup process

If you specify RateRoutinesUpdateJarFile, the JAR file must not exist at system startup. If it exists, PolicyCenter
throws an exception and fails to start. Therefore, perform these steps before starting the server:
1. If the file specified by RateRoutinesUpdateJarFile exists, then copy it to the file specified by
RateRoutinesJarFile.
2. Delete the file specified by RateRoutinesUpdateJarFile.
3. Start the server.
For example, the following Windows shell script starts the server on Tomcat:
SET ROUTINES_JAR = %TOMCAT_HOME%\webapps\pc\modules\configuration\plugins\gosu\lib\[Link]
SET UPDATE_JAR=%TOMCAT_HOME%\webapps\pc\modules\configuration\plugins\gosu\lib\rateroutines_update.jar
IF EXIST %UPDATE_JAR% {
del %ROUTINES_JAR%
ren %UPDATE_JAR% %ROUTINES_JAR%

84 chapter 2: Application configuration parameters

 Guidewire PolicyCenter 9.0.9 Configuration Guide

}
%TOMCAT_HOME%\bin\[Link]

RateTableManagementNormalizationRowLimit
PolicyCenter determines whether to normalize a rate table if the table contains this many rows or more.
If the number of rows in the normalized table would exceed this limit, the table is automatically marked as non-
normalizable. PolicyCenter stores the non-normalized version of the table.
Default: 10000

See also
• “Rate table normalization configuration parameters” on page 641

RateTableManagementNormalizationRowThreshold
If the number of rows in the normalized table would exceed this threshold, the user is given the option to store a
non-normalized version of the table.
Default: 1000

See also
• “Rate table normalization configuration parameters” on page 641

RatingWorksheetContainerAgeForPurging
The Purge Rating Worksheets batch process uses this parameter as one factor in determining if a worksheet
container can be purged. To be considered for purging, the worksheet container’s job must have been completed at
least RatingWorksheetContainerAgeForPurging days.
Default: 90

See also
• “Purge Rating Worksheet batch process” on page 661

SmallRateTableRowLimit
Before importing rate tables, PolicyCenter scans the import file. The scan does not examine rate tables with more
rows than specified in SmallRateTableRowLimit.
Default: 10000

RateBookCacheEntryLifetimeSecs
The maximum time in seconds that a non-active rate book can stay in the rate book cache without being refreshed.
Default: 53

See also
• “Improving performance of rate tables loaded in memory” on page 640

RateBookCacheUpdateIntervalSecs
The time in seconds after which the rate book cache is rebuilt: all non-active rate books are refreshed and any rate
books added after the last update are added to the cache.
Default: 307
Application configuration parameters 85
Guidewire PolicyCenter 9.0.9 Configuration Guide

See also
• “Improving performance of rate tables loaded in memory” on page 640

RateTableCacheConcurrency
Provides guidance on the maximum number of concurrent operations on the rate table cache.
Default: 16

See also
• “Improving performance of rate tables loaded in memory” on page 640

RateTableCacheEntryLifetimeSecs
The maximum time in seconds for which a rate table in a non-active rate book can stay in the rate table cache
without being refreshed.
Default: 53

See also
• “Improving performance of rate tables loaded in memory” on page 640

RateTableCacheMaxSize
The maximum number of rate tables that can be in the rate table cache. For no limit, set to -1. To disable rate table
caching, set to 0.
Default: -1

See also
• “Improving performance of rate tables loaded in memory” on page 640

RateTableCacheUpdateIntervalSecs
The time in seconds after which the rate table cache is cleared.
Default: 307

See also
• “Improving performance of rate tables loaded in memory” on page 640

RateTableDefinitionCacheUpdateIntervalSecs
The time in seconds after which the rate table definition cache is cleared.
Default: 601

See also
• “Improving performance of rate tables loaded in memory” on page 640

Risk assessment parameters

Risk assessment parameters enable you to set the URL for log in to Guidewire Spotlight and to access risk
assessment services.
You must change the default URL, [Link], to enable testing or using Spotlight services.
86 chapter 2: Application configuration parameters
 Guidewire PolicyCenter 9.0.9 Configuration Guide

See also
• “Enabling Spotlight services” on page 580
• Application Guide

MultipleLocationRiskAssessmentEnabled
Specify whether multiple location risk assessment calls may be made to Spotlight.
Default: false

PurgeRiskAssessmentTempStoreDays
Minimum number of days that must pass after temporary risk assessment objects has been created before the objects
can be eligible for purging.
Default: 30

See also
• System Administration Guide

RiskAssessmentIntegrationEnabled
Enable or disable access to all Spotlight services from PolicyCenter.
Default: false

RiskAssessmentThumbnailMapEnabled
Enable or disable access to Spotlight thumbnail map service.
Default: false

SingleLocationRiskAssessmentEnabled
Specify whether single location risk assessment calls may be made to Spotlight.
Default: false

SpotlightInteractiveServiceURL
Specifies the URL to the Spotlight interactive service. This service provides interactive access to Spotlight.
Default: [Link]

SpotlightLoginURL
Specifies the URL to the Spotlight login screen.
Default: [Link]

SpotlightRiskAssessmentServiceURL
Specifies the URL to the Spotlight risk assessment service.
Default: [Link]

SpotlightThumbnailMapURL
Specifies the URL to the Spotlight thumbnail map service.
Application configuration parameters 87
Guidewire PolicyCenter 9.0.9 Configuration Guide

Default: [Link]

Scheduler and workflow parameters

Guidewire provides the following configuration parameters in the [Link] file that relate to batch process
scheduler and workflow.
For information on editing [Link] and setting configuration parameters, see “Working with configuration
parameters” on page 41.

SchedulerEnabled
Whether to enable the internal batch process application scheduler. See the System Administration Guide for more
information on batch processes and the scheduler.
Default: true
Dynamic: Yes

WorkflowLogDebug
Configuration parameter WorkflowLogDebug takes a Boolean value:
• If set to true, PolicyCenter outputs the ordinary verbose system workflow log messages from the Guidewire
server to the workflow log.
• If set to false, PolicyCenter does not output any of the ordinary system messages.
The setting of this parameter does not have any effect on calls to log workflow messages made by customers.
Therefore, all customer log messages are output. If customers experience too many workflow messages being
written to the xx_workflowlog table, Guidewire recommends that you set this parameter to false.
Default: true

WorkflowLogPurgeDaysOld
Number of days to retain workflow log information before PurgeWorkflowLogs batch processing deletes it.
See the System Administration Guide for details.
Default: 30

WorkflowPurgeDaysOld
Number of days to retain workflow information before PurgeWorkflows batch processing deletes it.
See the System Administration Guide for details.
Default: 60

WorkflowStatsIntervalMins
Aggregation interval in minutes for workflow timing statistics. Statistics such as the mean, standard deviation, and
similar statistics used in reporting on the execution of workflow steps all use this time interval. A value of 0 disables
statistics reporting.
Default: 60

Search parameters
Guidewire provides the following configuration parameters in the [Link] file that relate to searching.
88 chapter 2: Application configuration parameters
 Guidewire PolicyCenter 9.0.9 Configuration Guide

For information on editing [Link] and setting configuration parameters, see “Working with configuration
parameters” on page 41.

FreeTextSearchEnabled
Whether to enable the free-text search feature. Setting the FreeTextSearchEnabled parameter to true enables the
free-text plugins for indexing and search. Setting the parameter to true also enables the display of the
Search Polices→Basic screen, which uses free-text search. The FreeTextSearchEnabled parameter has no effect on
the user interface unless you also set the EnableDisplayBasicSearchTab script parameter to true. Script
parameters are defined initially through Studio but administered on the Script Parameters page of the Administration tab.
Default: false

See also

• “Script parameters” on page 125

• “Free-text search configuration parameters and files” on page 409

MaxContactSearchResults
Maximum number of contacts that PolicyCenter returns in a search. If the number to return is greater than this value,
then PolicyCenter prompts the user to narrow the search parameters. This integer value must be 1 or greater.
Default: 100

PolicySearchMaxResult
Number of maximum results to return from a database policy search. This parameter has no effect on free-text
policy search.
Default: 300

See also

• “Overview of search” on page 393

Security parameters
Guidewire provides the following configuration parameters in the [Link] file that relate to application security.
For information on editing [Link] and setting configuration parameters, see “Working with configuration
parameters” on page 41.

EnableDownlinePermissions
If UseACLPermissions is true, then setting this parameter to true means that supervisors inherit permissions on an
object that has been added for a supervised user or group.
Default: true

Application configuration parameters 89

Guidewire PolicyCenter 9.0.9 Configuration Guide

ExternalUserAccess
Indicate which groups and producer codes are available to external users. In order of increasing access, values are:
• FULLYRESTRICTED – External users can be assigned to groups only within their organization. Users inherit
producer codes from their groups. In addition, external users can be assigned producer codes from their
organization.
• PROTECTINTERNAL – External users can be assigned to any external groups. Users inherit producer codes from
their groups. In addition, external users can be assigned producer codes from any external organization.
• ALLOWINTERNAL – External users can be assigned to any groups, internal or external. Users inherit producer codes
from their groups. In addition, external users can be assigned producer codes from internal or external
organizations.
Default: FULLYRESTRICTED

See also
• Application Guide

FailedAttemptsBeforeLockout
Number of failed attempts that PolicyCenter permits before locking out a user. For example, setting this value to 3
means that the third unsuccessful try locks the account from further repeated attempts. This integer value must be 1
or greater. A value of -1 disables this feature.
Default: 3
Minimum: -1

LockoutPeriod
Time in seconds that PolicyCenter locks a user account. A value of -1 indicates that a system administrator must
manually unlock a locked account.
Default: -1

LoginRetryDelay
Time in milliseconds before a user can retry after an unsuccessful login attempt. This integer value must be 0 or
greater.
Default: 0
Minimum: 0

MaxPasswordLength
New passwords must be no more than this many characters long. This integer value must be 0 or greater.
Default: 16

MinPasswordLength
New passwords must be at least this many characters long. For security purposes, Guidewire recommends that you
set this value to 8 or greater. This integer value must be 0 or greater. If 0, then Guidewire PolicyCenter does not
require a password. (Guidewire does not recommend this.)
Default: 8
Minimum: 0
90 chapter 2: Application configuration parameters
 Guidewire PolicyCenter 9.0.9 Configuration Guide

RestrictContactPotentialMatchToPermittedItems
Whether PolicyCenter restricts the match results from a contact search screen to those that the user has permission to
view.
Default: true

RestrictSearchesToPermittedItems
Whether PolicyCenter restricts the results of a search to those that the user has permission to view.
Default: true

SessionTimeoutSecs
Use to set the browser session expiration timeout, in seconds. By default, a session expires after three hours (60 * 60
* 3 = 10800 seconds).
• The minimum value to which you can set this parameter is five minutes (60 * 5 = 300 seconds).
• The maximum value to which you can set this parameter is one week (3600 * 24 * 7 = 604800 seconds)
This value sets the session expiration timeout globally for all PolicyCenter browser sessions. See the System
Administration Guide for information on how to set the session timeout at a more granular level.
Default: 10800
Minimum: 300
Maximum: 604800

Side‐by‐side quoting parameters

Guidewire provides the following configuration parameters in [Link] that relate to side-by-side quoting.
PolicyCenter provides a number of configuration parameters related to the display of side-by-side quotes in the
PolicyCenter interface. For a discussion of side-by-side quoting, see the Application Guide.

RenewalMaxSideBySideQuotes
Sets an upper limit on the number of versions to show on a side-by-side quote page for a policy renewal.
Default: 4

SideBySide
Determines whether validation warnings block Quote All in side-by-side quoting.
In the default configuration, Quote All in the Side by Side Quoting screen does not produce quotes when there are
validation warnings. This is to prevent PolicyCenter from generating invalid quotes. Guidewire expects that the
default implementation is suitable for most implementations.
Default: true

See also
• For more information about setting this parameter, see “Configuring quote all to ignore validation warnings” on
page 790.

SubmissionMaxSideBySideQuotes
Sets an upper limit on the number of versions to show on a side-by-side quote page for a policy submission.
Default: 4
Application configuration parameters 91
Guidewire PolicyCenter 9.0.9 Configuration Guide

PolicyChangeMaxSideBySideQuotes
Sets an upper limit on the number of versions to show on a side-by-side quote page for a policy change.
Default: 4

User interface parameters

Guidewire provides the following configuration parameters in t he [Link] file that relate to the PolicyCenter
interface.
For information on editing [Link] and setting configuration parameters, see “Working with configuration
parameters” on page 41.

ActionsShortcut
The keyboard shortcut to use for the Actions button.
Default: A

AutoCompleteLimit
The maximum number of autocomplete suggestions to show.
Default: 10

InputMaskPlaceholderCharacter
The character to use as a placeholder in masked input fields.
Default: . (period)

ListViewPageSizeDefault
The default number of entries that PolicyCenter displays in each page in a list view, if the page does not explicitly
specify this value. This integer value must be at least 1.
Default: 15
Minimum: 1

MaxBrowserHistoryItems (obsolete)
This parameter is obsolete. Do not use it.

QuickJumpShortcut
The keyboard shortcut to use to activate the QuickJump box.
Default: / (forward slash)

UISkin
Name of the PolicyCenter interface skin to use.
Default: theme-9

WebUIAJAXTimeout
Number of seconds that the PolicyCenter web client waits after issuing a call to the PolicyCenter server. If the server
does not respond within this time, the web client assumes that the server is offline, terminates all connections, and
92 chapter 2: Application configuration parameters
 Guidewire PolicyCenter 9.0.9 Configuration Guide

displays an error. You may want to increase this value if you are performing data-intense operations that take a long
time to process.
Default: 600

Work queue parameters

Guidewire provides the following configuration parameters in the [Link] file that relate to the work queue.
For information on editing [Link] and setting configuration parameters, see “Working with configuration
parameters” on page 41.
For information on work queues in general, see the System Administration Guide.

InstrumentedWorkerInfoPurgeDaysOld
Number of business days to retain instrumentation information for a worker instance before PolicyCenter deletes it.
Default: 45

WorkItemCreationBatchSize
The maximum number of work items for a work queue writer to create for each transaction.
Default: 100

WorkItemPriorityMultiplierSecs
Used to calculate the AvailableSince field for new work items. For new work items without a priority,
PolicyCenter sets AvailableSince to the current time. Later, PolicyCenter checks out work items from the work
queue in ascending order by AvailableSince, so work items without a priority are checked out in the order they
were created.
You can assign a priority to new work items by implementing the Work Item Priority plugin
(IWorkItemPriorityPlugin). For new work items with a priority, PolicyCenter sets AvailableSince according to
the following formula:
[Link] = CurrentTime – ([Link] * WorkItemPriorityMultiplierSecs)

Work items with higher priorities have earlier AvailableSince values than work items with lower priorities.
Therefore, work items with higher priorities are checked out before ones with lower priorities because their
AvailableSince values are earlier.
Priority influences the calculation of AvailableSince only at the time work items are created. If a worker throws an
exception while processing a work item, PolicyCenter reverts the status of the work item from checkedout to
available. At the same time, PolicyCenter resets AvailableSince according to the following formula:
[Link] = CurrentTime + RetryInterval

Work items are retried in the order they encounter exceptions, irrespective of priority.

IMPORTANT Prioritization affects only work items of type WorkflowWorkItem or its derivatives.

Default: 600

WorkItemRetryLimit
The maximum number of times that PolicyCenter retries an orphaned or failed work item.
Guidewire logs a ConcurrentDataChangeException generated by workers at different levels depending on context.
If the ConcurrentDataChangeException occurs on processing the work items, PolicyCenter logs the error only if
the number of attempts exceeds the configured value of the WorkItemRetryLimit. Otherwise, PolicyCenter logs the
debug message instead.
Application configuration parameters 93
Guidewire PolicyCenter 9.0.9 Configuration Guide

The value for WorkItemRetryLimit applies to all work queues unless overridden in [Link] by
retryLimit for specific work queues. For more information on tuning work queue performance by adjusting the
number of retries, see the System Administration Guide.
Default: 3

WorkQueueHistoryMaxDownload
The maximum number of ProcessHistory entries to consider when producing the Work Queue History download.
The valid range is from 1 to 525600. (The maximum of 525,600 is 60*24*365, which is one writer running every
minute for a year.)
Default: 10000

WorkQueueThreadPoolMaxSize
Maximum number of threads in the work queue thread pool. This must be greater than or equal to
“WorkQueueThreadPoolMinSize” on page 94. All threads that are not core threads are additional on-demand
threads. PolicyCenter terminates any idle on-demand threads after the period of time defined by configuration
parameter WorkQueueThreadsKeepAliveTime.
Default: 50
Set For Environment: Yes

WorkQueueThreadPoolMinSize
Minimum number of core threads in the work queue thread pool.
Default: 0
Set For Environment: Yes

WorkQueueThreadsKeepAliveTime
Keep alive timeout (in seconds) for additional on-demand threads in the work queue thread pool. An additional on-
demand thread is terminated if it is idle for more than the time specified by this parameter.
Default: 60
Set For Environment: Yes

94 chapter 2: Application configuration parameters

Part 2

The Guidewire development

environment
Guidewire PolicyCenter 9.0.9 Configuration Guide
chapter 3

Getting started

This topic describes Guidewire Studio, which is the PolicyCenter administration tool for creating and managing
PolicyCenter resources. (Studio resources include Gosu rules, classes, enhancements, the product model, script
parameters, and the PolicyCenter data model files.) Using Guidewire Studio, you can do the following:
• Create and edit individual rules, and manage these rules and their order of consideration within a rule set
• Create and manage PCF pages, workflows, entity names, and display keys
• Create and manage Gosu classes
• Access rule sets, Gosu classes, and other resources stored in a SCM (Source Control Management) system

What Is Guidewire Studio?

Guidewire Studio is the IDE (integrated development environment) for creating and managing PolicyCenter
application resources. These resources include Gosu rules, classes, enhancements and plugins, and all configuration
files used by PolicyCenter to build and render the application.
Guidewire Studio is based upon IntelliJ IDEA Community Edition, a powerful and popular IDE.
Using Guidewire Studio, you can:
• Create and edit individual rules, and manage these rules and their order of consideration within a rule set
• Create and manage PCF pages, workflows, entity names, and display keys
• Create and manage Gosu classes and entity enhancements
• Create and manage the PolicyCenter data entities, business objects, and data types
• Manage plugins and message destinations
• Configure database connections
• Manage the PolicyCenter product model

IMPORTANT Do not create installation directories that have spaces in the name. This can prevent
Guidewire Studio from functioning properly.

The Studio development environment

Guidewire Studio is a stand-alone development application that runs independently of Guidewire PolicyCenter. You
use Studio to build and test application customization in a development or test mode before deploying your changes
to a production server. Any changes that you make to application files through Studio do not automatically
Getting started 97
Guidewire PolicyCenter 9.0.9 Configuration Guide

propagate into production. You must specifically build a .war file and deploy it to a server for the changes to take
effect. (Studio and the production application server—by design—do not share the same configuration file system.)
Guidewire recommends that you not run Studio on a machine with an encrypted hard drive. If you run Guidewire
Studio on a machine with hard drive encryption, Studio can take 15 or more seconds to refresh. This slow refresh
can happen when you switch focus from the Studio window to something else, such as the browser, and back again.
To assist with this development and testing process, Guidewire bundles the following with the PolicyCenter
application:
• A QuickStart development server
• A QuickStart database
• A QuickStart server used for testing that you cannot control
• A QuickStart database used for testing that is separate from the QuickStart development database
The following diagram illustrates the connections between Guidewire Studio, the bundled QuickStart applications,
the local file system, and the PolicyCenter application server. You use the QuickStart test server and test database for
testing only as PolicyCenter controls them internally. You can use either the bundled QuickStart development server
bundled with Guidewire PolicyCenter or use an external server such as Tomcat. In general, dotted lines indicate
actions on your part that you perform manually. For example, you must manually create a .war file and manually
move it to the production server. The system does not do this for you.

Local (Development) Environment Production

Application Server

Guidewire
Studio
Debug
Development Debug
QuickStart
Server
Test
Server
PolicyCenter
QuickStart Database Application
and
Check Out/Submit

Configuration
Files
Database
Local
Configuration WAR / EAR
Files

SCM
System

PolicyCenter Database

Working with the QuickStart development server

It is possible to use any of the supported application servers in a development environment, rather than the
embedded QuickStart server. To do so, you need to point PolicyCenter to the configuration resources edited by
Guidewire Studio. This requires additional configuration, described for each application server type in the
Installation Guide.

98 chapter 3: Getting started

 Guidewire PolicyCenter 9.0.9 Configuration Guide

For information on starting and testing the QuickStart server from within Studio, see “Testing PolicyCenter with
Guidewire Studio” on page 499.

Connecting the development server to a database

PolicyCenter running on the QuickStart development server can connect to the same kinds of databases as any of the
other Guidewire-supported application servers. However, for performance reasons, Guidewire recommends that you
use the bundled QuickStart database. Guidewire optimizes this database for fast development use. It can run in either
of the following modes:

Mode Description
file mode The database persists data to the hard drive (the local file system), which means that the data can live from one
server start to another. This is the Guidewire‐recommended default configuration.
memory The database does not persist data to the hard drive and it effectively drops the database each time you restart
mode the server. Guidewire does not recommend this configuration.

You set configuration parameters for the QuickStart database associated with the development server in database-
[Link]. For example:
<!-- H2 (meant for development/quickstart use only!) -->
<database
name="PolicyCenterDatabase"
dbtype="h2">
<dbcp-connection-pool
jdbc-url="jdbc:h2:file:/tmp/guidewire/pc"/>
<upgrade
defer-create-nonessential-indexes="false"/>
</database>

Set the database mode

About this task

In the base configuration, the QuickStart database runs in file mode. You set the database mode using the jdbc-url
attribute. In file mode, the jdbc-url attribute value specifies an actual file location. For example:
jdbc-url="jdbc:h2:file:/tmp/guidewire/pc"

The default file location in the base configuration is /tmp/guidewire/pc.

Drop the QuickStart database

About this task

Occasionally, you may want (or need) to drop the QuickStart database. For example, Guidewire recommends that
you drop the QuickStart database if you make changes to the PolicyCenter data model.
Drop the database from the command line
• At the command prompt, run gwb dropDb.
Drop the database manually
• Delete the files from the directory specified by the jdbcURL parameter (by default, <root>/tmp/guidewire/pc).
The server must be stopped when you delete the directory.

Getting started 99
Guidewire PolicyCenter 9.0.9 Configuration Guide

Deploying your configuration changes

About this task
To deploy your configuration changes to an actual production server, you must build a .war or .ear file and deploy
it on the application server. By design, you cannot directly deploy configuration files from Studio to the application
server.
As the bundled QuickStart development server and Studio share the same configuration directory, you do not need
to deploy your configuration changes to the QuickStart development server.
Hot-deploy PCF files
Editing and saving PCF files in the Page Configuration (PCF) editor does not automatically reload them in the
QuickStart server, even if there is a connection between it and Studio. You do not actually need to be connected to
the server from Studio to reload PCF files.
You can also reload display keys this way, as well.

Procedure
1. Navigate to the PolicyCenter web interface on the deployment server, and log in.
2. Reload the PCF configuration using either the Internal Tools page or the Alt+Shift+L shortcut.

Result
Hot-deploy Gosu files
Editing and saving Gosu files in Studio does not automatically reload them in the QuickStart server, even if there is
a connection between it and Studio. To reload the Gosu files, do one of the following:
• To recompile all files, click Build→Compile.
• To compile only files that were changed since the last compile, click Build→Make Project.

PolicyCenter configuration files

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 cause damage
to the PolicyCenter application and prevent it from starting thereafter.

Installing Guidewire PolicyCenter creates the following directory structure:

Directory Description
.gradle Configuration and settings for Gradle, the project build tool.
.idea Configuration and settings for IntelliJ IDEA, the foundation for Guidewire Studio.
admin Administrative tools. See the System Administration Guide for descriptions.
bin Deprecated. The gwpc batch file and shell script used to launch commands for building and deploying.
These commands are deprecated, and are provided only for backwards compatibility with previous releas‐
es. For the updated commands, see the Installation Guide.
build The output of build commands such as exploded .war files and the data and security dictionaries. This
directory is not present when you first install PolicyCenter. The directory is created when you run one of
the build commands.
dist Guidewire application .war, and .jar files are built in this directory. The directory is created when you run
one of the build commands to generate .war files.
doc HTML and PDFs of PolicyCenter documentation.
gradle Support files for Gradle, the project build tool.

100 chapter 3: Getting started

 Guidewire PolicyCenter 9.0.9 Configuration Guide

java-api The Java API libraries created by running the gwb genJavaApi command. See the Integration Guide.
javadoc Reference documentation for the Java API libraries.
licenses License information for third‐party tools used by PolicyCenter.
logs Application log files.
modules Subdirectories including configuration resources for each application component.
productdesigner Application files for Product Designer.

repository Necessary PolicyCenter files.

solr Installation and support files for the Solr free text search platform. See “Free‐text search configuration” on
page 406.
studio Application files for Guidewire Studio.
ThemeApp Files defining the user interface styling for PolicyCenter.
webapps Necessary files for use by the application server.

Edited Resource Files Reside in the Configuration Module Only

The configuration module is the only place for configured resources. As PolicyCenter starts, a checksum process
verifies that no files have been changed in any directory except for those in the configuration directory. If this
process detects an invalid checksum, PolicyCenter does not start. In this case, overwrite any changes to all modules
except for the configuration directory and try again.
Guidewire recommends that you use Studio to edit configuration files to minimize the risk of accidentally editing a
file outside the configuration module.

Key directories
The installation process creates a configuration environment for PolicyCenter. In this environment, you can find all
of the files needed to configure PolicyCenter in two directories:
• The main directory of the configuration environment. In the default PolicyCenter installation, the location of this
directory is PolicyCenter/modules/configuration.
• PolicyCenter/modules/configuration/config contains the application server configuration files.
The installation process also installs a set of system administration tools in PolicyCenter/admin/bin.
PolicyCenter runs within a J2EE server container. To deploy PolicyCenter, you build an application file suitable for
your server and place the file in the server’s deployment directory. The type of application file and the deployment
directory location is specific to the application server type. For example, for PolicyCenter (deployed as the [Link]
application) running on a Tomcat J2EE server on Windows, the deployment directory might be C:\Tomcat\webapps
\pc.

Studio and IntelliJ IDEA configuration

Guidewire Studio is based upon IntelliJ IDEA Community Edition. You can configure many aspects of Studio using
the same configuration that you would use for the standalone IntelliJ IDEA application. Some configuration changes
require special procedures. This topic describes the following:
• “Using Studio with IntelliJ IDEA Ultimate Edition” on page 101
• “Setting IntelliJ IDEA properties in Studio” on page 102

Using Studio with IntelliJ IDEA Ultimate Edition

About this task
Guidewire Studio is bundled with the Community Edition of IntelliJ IDEA, a free version of this popular IDE. If
desired, you can configure Studio to work with the Ultimate Edition of IntelliJ IDEA instead. To use the Ultimate
Getting started 101
Guidewire PolicyCenter 9.0.9 Configuration Guide

Edition, you must obtain your own license for it from IntelliJ. For information about the supported versions of
IntelliJ IDEA Ultimate, visit the Guidewire Community and search for knowledge article 1005, “Supported
Software Components”.

Procedure
1. In your PolicyCenter installation directory, create a text file named [Link] that contains the full
path of your IntelliJ IDEA Ultimate Edition installation directory. For example:
C:\Program Files (x86)\JetBrains\IntelliJ IDEA 15.0.6
2. Run Guidewire Studio.
3. When prompted for your IntelliJ IDEA Ultimate Edition license, provide it.

Setting IntelliJ IDEA properties in Studio

About this task
In the standalone IntelliJ IDEA application, you can set various properties by editing the [Link] file. In
Guidewire Studio, you cannot edit [Link] directly. Instead, do the following:

Procedure
1. Edit the file PolicyCenter/modules/script/[Link].
2. Locate the studio section:
studio {
...
}

3. Within this section, set any properties that are valid in the [Link] file by adding a statement in the
following format:
ideaProperties["property_name"] = "property_value"

For example, to disable the IntelliJ IDEA cycle buffer, set the following:
ideaProperties["[Link]"] = "disabled"

Note: Do not modify other sections of the [Link] file.

4. Restart Studio.

Studio and the DCEVM

The PolicyCenter application server and Guidewire Studio require a JVM (Java Virtual Machine). The version of the
JVM depends on the servlet container and operating system on which the application server runs.
Guidewire strongly recommends the use of the DCEVM for development in the QuickStart environment. Guidewire
does not support the DCEVM for other application servers or in a production environment.
The Dynamic Code Evolution Virtual Machine (DCEVM) is a modified version of the Java HotSpot Virtual
Machine (VM). The DCEVM supports any redefinition of loaded classes at runtime. You can add and remove fields
and methods and make changes to the super types of a class using the DCEVM. The DCEVM is an improvement to
the HotSpot VM, which only supports updates to method bodies.

DCEVM Limitations
If you reload Gosu classes using hotswap on the DCEVM, it is possible to add new static fields (again, only on the
DCEVM). However, Gosu does not execute any initializers for those static variables. For example, if you add the
following static field to a class:
public static final var NAME = "test"

102 chapter 3: Getting started

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Gosu adds the NAME field to the class dynamically. However, the value of the field is null until you restart the server
(or Studio, if you are running the code from the Studio Gosu Scratchpad). If you need to initialize a newly added
static field, you must write a static method that sets the variable and then executes that code.
For example, suppose that you added the following static method to class MyClass:
public static var x : int = 10

To initialize this field, write code to set the static variable to the value that you expect and then execute that code:
MyClass.x = 10

This does not work if the field is final.

Note: Adding an instance variable rather than a static variable with an initializer also results in null
values on existing instances of the object. However, any newly-constructed instances of the object will
have the field initialized.

See also

• For details on how to select the proper JVM for your installation, see the Installation Guide.

Start Guidewire Studio

Procedure

1. Open a command window.

2. Navigate to the application directory.
3. At the command prompt, type:

gwb studio

Result

The first time that you start Guidewire Studio, it may take some extra time to load and index configuration data.
Subsequent starts, however, generally load much more quickly.

Stop Guidewire Studio

Procedure

Click File→Exit. You can also stop Studio by closing its window (by clicking the x in the upper right-hand corner of
the window).

Updating Guidewire Studio

Guidewire Studio can be updated to a newer release independently of your application, and without requiring a full
reinstallation. Studio can detect when Guidewire posts a Studio update, and then download and apply the update. If
desired, you can manually download and apply updates instead.

Getting started 103

Guidewire PolicyCenter 9.0.9 Configuration Guide

Enable or disable automatic update checks

About this task
Studio can automatically check an update site to determine if an update is available. If enabled, the automatic check
occurs at the following times:
• each time Studio is run
• if Studio is left running, every 24 hours after it was first run
If an update is available, Studio notifies you and prompts you to download and apply it.

Procedure
1. Click File→Settings.
2. In the Settings dialog, in the navigation list, click Guidewire Studio.
3. In the Update section, select or clear the Check Automatically check box.

Manually check for Studio updates

About this task
If an update is available, Studio notifies you and prompts you to download and apply it.
• Click Help→Check for Studio Update.

Setting the Studio update site

To determine whether an update is available, Studio contacts an update site. If an update is available, Studio
downloads the update.
The update site can be one of the following:
• a secure site managed by Guidewire
• an internal site managed by you

Use the Guidewire update site for Studio updates

About this task
Guidewire provides a secure site that Studio can contact to download updates.
Note: The Guidewire update site is a secure server that only Studio can access. You cannot access this
server yourself, such as by using a web browser.

Procedure
1. Click File→Settings.
2. In the Settings dialog, in the navigation list, click Guidewire Studio.
3. In the Update section, set the Update Site URL text box to the following:
[Link]

Use an internal site for Studio updates

About this task
Instead of having Guidewire Studio download updates from the update server managed by Guidewire, you can set
up your own internal update site. You may want to use an internal update site if you have multiple Studio
installations that do not have Internet access to the Guidewire update server. You can also use an internal update site
to closely manage when your Studio installations are updated.
104 chapter 3: Getting started
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Your update site can be a web server, FTP server, network file share, or any location accessible using standard URL
protocols such as http, ftp, file, and so on.

Procedure
1. Download the Studio update files. See “Download update files from the Guidewire Community” on page 105.
2. Place the Studio update files in the shared location in your update site.
3. Create a file that identifies the latest Studio update. Studio checks this file to determine when an update is
available.
a. In the shared location on your update site, create a text file named [Link].
b. Edit [Link] and add a line that specifies a Studio major release and the latest minor release
number for that major release.
For example, the following specifies that for any Studio "3.0.x" major release, Studio updates to the
"3.0.4" minor release:
3.0.x = 3.0.4

4. In Studio, click File→Settings.

5. In the Settings dialog, in the navigation list, click Guidewire Studio.
6. In the Update section, set the Update Site URL text box to the URL of your update site.
7. Repeat from step 4 for each instance of Studio that updates from your update site.

Next steps
When you place a new Studio release in your update site, edit [Link] and change the minor release number
to match the latest release.

Updating Studio manually

Instead of having Guidewire Studio download updates from an update server, you can manually update Studio when
desired. You may want to manually update Studio if you have multiple Studio installations that do not have access to
an update server. You can also manually update Studio to closely manage when your Studio installations are
updated.
You can obtain the Studio update files from either the Guidewire Community or a Studio installation that has already
been updated. Once you have the files, you can install them in the Studio instance that you want to update.

See also
• “Download update files from the Guidewire Community” on page 105
• “Copy update files from an updated Studio installation” on page 106
• “Manually install the Studio update files” on page 106

Download update files from the Guidewire Community

You can download the Studio update files from the Guidewire Community.
1. Browse to the Guidewire Community.
2. Click the Resources menu, and then click Product Releases.
3. In the Product Group drop-down list, click InsuranceSuite.
4. In the Product drop-down list, click Guidewire Studio.
5. Next to the Guidewire Studio release that you want, in the Software column, click the download icon to
download the studio-*.zip file.
Getting started 105
Guidewire PolicyCenter 9.0.9 Configuration Guide

See also
• “Manually install the Studio update files” on page 106.

Copy update files from an updated Studio installation

About this task
You can copy the Guidewire Studio update files from a Studio installation that has already been updated.

Procedure
1. In the updated Studio installation, go to the directory PolicyCenter/studio.
2. Copy the studio-*.zip file with the highest release number.

See also
• “Manually install the Studio update files” on page 106.

Manually install the Studio update files

About this task
Once you have obtained the Guidewire Studio update files, you can install them manually into a Studio instance that
you want to update.

Procedure
1. In the Studio installation to update, go to the directory PolicyCenter/studio/plugins.
2. Delete the following directories:
• gosucheckstyle
• ij-gosu
• ij-studio
• inspections
3. Extract the studio-*.zip Studio update file into the PolicyCenter/studio/plugins directory.

See also
• “Updating Studio manually” on page 105.

106 chapter 3: Getting started

chapter 4

Working in Guidewire Studio

You can perform a number of common tasks in Guidewire Studio™.

Entering valid code

Guidewire Studio provides several different ways of obtaining information about PolicyCenter objects and APIs to
assist you in writing valid rules and Gosu code. These include:

Dot comple‐ Opens a context‐sensitive pop‐up window that contains all the subobjects and methods that are valid for this
tion object, in this context. Dot completion works with both Gosu or Java packages.
SmartHelp Displays a list of valid fields and subobjects for the current object.

Keyboard commands provide code completion, code navigation, and code editing shortcuts. See “Using Studio
keyboard shortcuts” on page 108 for information on keyboard shortcuts.

Using dot completion

You can use Studio to complete your code by placing the cursor (or caret) at the end of a valid PolicyCenter object
or subobject and typing a dot (.). This action causes Studio to open a pop-up window that contains all the
subobjects, methods, and properties that are valid for this object, in this context.
As you type, Studio filters this list to include only those choices that match what you have typed thus far. Use the
down arrow to highlight the item you want and press Enter, the space bar, or Tab to select it. After you select an
item, Studio inserts it in the correct location in the code.

Gosu and Java package name completion

Dot completion also works with Gosu or Java packages. You can enter a package name and press dot to get a list of
packages and types within the package name before the dot. Studio can complete all packages and namespaces
within the Studio type system including product model and PCF types. Studio filters the list as you type to include
only those choices that match what you have typed thus far.

Accessing reference information

PolicyCenter provides reference information that you can review. This includes:
Working in Guidewire Studio 107
Guidewire PolicyCenter 9.0.9 Configuration Guide

Gosu API Reference Provides a searchable reference on the Gosu APIs, methods and properties. See the Gosu Reference
Guide.
PCF Reference Guide Provides a description of the PCF widgets and their attributes that you can use within the PCF editor.
This documentation is also known as the PCF Format Reference.
Gosu Reference Guide Provides information on the Gosu language.

Accessing the Gosu API Reference

Guidewire provides API reference information that you can use to obtain additional information about the Gosu
APIs and their methods and parameters. There are two ways to access this information:
• Access the Gosu API reference as described in the Gosu Reference Guide. Use the Search functionality to find
information on an API, or expand the API list and select a field, parameter or method to view.
• Click a method name in a line of code and press CTRL+Q. A pop-up window opens and displays information about
that method, including information about its parameters.
The Gosu API reference window contains a search pane, a contents tree, and a display area.
• The contents tree displays a tree view of the type system, organized by package.
• The search pane contains a text field for search terms, a button to clear the text field, a search button, and a re-
index button. It also includes an indication of the time of the last indexing operation.
If the reference has never been indexed, then index it before proceeding.

Accessing the PCF Reference Guide

Guidewire provides the Guidewire PolicyCenter PCF Format Reference that you can use to obtain information
about PCF widgets and their attributes. To access the reference guide, in your file system, open the file
PolicyCenter/modules/[Link].

Accessing the Gosu Reference Guide

You can view the Gosu Reference Guide in the Guidewire PolicyCenter documentation set.

Using Studio keyboard shortcuts

Guidewire Studio provides a number of keyboard commands that provide important code completion, navigation,
and editing capabilities. For a full list of keyboard shortcuts, see the IntelliJ IDEA documentation at the following
link:
[Link]

The following are some of the more useful keyboard shortcuts:

Keystroke Name Description

Ctrl+Space Code completion Helps you complete the names of classes, methods, fields, and keywords.
Ctrl+/ Comment/uncomment Comment or uncomment a line or block of code.
Ctrl+Shift+/

Alt+Enter Intention actions Offers suggestions to correct the error nearest the caret.
Ctrl+N Find class or file by name Finds and opens the class or file in its editor.
Ctrl+Shift+N

Ctrl+Q Context help Shows documentation for the symbol at the caret.
Ctrl+Shift+G Show type information Shows the type of the symbol at the caret.

108 chapter 4: Working in Guidewire Studio

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Saving your work

PolicyCenter automatically saves any modifications made in Studio under the following conditions:
• If you move between different tabs (views) within Studio
• If the Studio main window loses focus (for example, by moving to another application)
However, you also have the option of performing manual “saves” by using the File menu.

Command Description

File→Save All Writes any unsaved changes to your local fie or SCM (Source Control Management) system. You can also
use the standard keyboard shortcut Ctrl+S save your changes.

Toolbar Save icon Works the same way that Save All and Ctrl+S do.

If you have no unsaved changes pending, these commands are unavailable.

Verifying configuration resources

Guidewire Studio automatically verifies each configuration resource as you edit it. All errors are highlighted in the
editor.
To explicitly verify a resource, right-click it, and then click Verify.
In addition, you can verify configuration resources using the command line tool verifyResources. For example:
gwb verifyResources

Any resource errors are reported on the command line.

Inspecting configuration resources

Guidewire has implemented several scripts that enable Gosu developers to inspect Gosu code and to identify style-
related issues. The Gosu code to be inspected can include configuration resources. With the inspection scripts,
developers can examine Gosu code and obtain reports on it in the Guidewire Studio development environment.
The inspection scripts that Guidewire has implemented report on issues regarding code style as well as declaration
redundancy. The code style reports include the following:
• Anonymous classes that block expressions can replace
• Getter and setter method prototypes that class property definitions can replace
• Calls to property getter and setter methods that class property syntax can replace
• Block expressions with code block bodies that block expressions with expression-style bodies can replace
• Calls to the [Link] method that the equality operator, ==, can replace
The declaration redundancy reports include the following:
• Local variable declarations that Gosu code can omit due to the Gosu type inference capability. For example, this
report would include the variable declaration, var a : String = "Hello". The report would do so because the
developer can simplify this declaration by using the declaration, var a = "Hello".

Working in Guidewire Studio 109

Guidewire PolicyCenter 9.0.9 Configuration Guide

Compiling configuration resources

There are several ways to compile configuration resources during development:
• Make – On the Build menu, click Make Project. Compiles all resources that have been modified since the last
compilation. All dependent resources are also compiled. When you run or debug the server within Studio, Studio
first runs a make to ensure that all resources are compiled.
• Rebuild – On the Build menu, click Rebuild Project. Recompiles all resources, including resources that have
already been compiled. This is required after first installing Studio, and may be necessary when the classpath
entries have changed. For example, when SDKs or libraries are added, removed, or altered.
• Compile – On the Build menu, click Compile ‘resource_name’. Recompiles only the selected resource and its
dependencies.
• gwb compile – At a command prompt, run this command. To run the QuickStart development server from the
command line, you must first run this command to compile it from the command line.

Enabling or disabling Gosu compilation

If you know that your Gosu code will generate many compilation errors, then you may want to disable compilation
while you fix them. For example, if a PolicyCenter upgrade involves API changes, then you can disable compilation
while you make the required changes to your code.
There are several ways to compile Gosu source code files, such as by building the project. When compilation is
disabled, explicitly compiling Gosu source files within Studio does not produce .class files. Instead, only the .gs
files are copied to the output directory. In addition, when compilation is disabled, Studio always reports an explicit
compilation as completing successfully, even when the code contains errors. To detect errors in your code when
compilation is disabled, explicitly verify that resource.
When you deploy your application, the .gs files are copied to the server, and the server compiles them as needed.
Therefore, when Gosu compilation is disabled, you may see server compilation errors that were not reported when
compiling in Studio.
Gosu compilation in Guidewire Studio is enabled by default.
1. In Guidewire Studio, click File→Settings.
2. In the Settings dialog, in the navigation list, expand Build, Execution, Deployment, then expand Compiler, and then
click Gosu Compiler.
3. Do the following:
• To disable Gosu compilation for tests, set Exclude Tests.
• To disable Gosu compilation for other files, set Disable Local Gosu Compilation. Then set the option to disable it
for All Gosu code, or Only Gosu code in PCF files.

See also
• “Compiling configuration resources” on page 110
• “Verifying configuration resources” on page 109
• “Setting options for Gosu command prompt compilation” on page 110

Setting options for Gosu command prompt compilation

The gwb compile command provides multiple options that modify the behavior of the Gosu compiler. These
configuration options apply only to the gwb compile command. The compilation tools that Guidewire Studio
provides do not use these options. For example, if you make changes to your Gosu code that might cause many
compilation errors or warnings, you can set options to terminate the compilation after reaching a threshold.
To set Gosu command-prompt compilation options, you edit the [Link] file in the PolicyCenter
configuration folder. You add the configuration options and values at the top of the file, similar to the following
lines:
110 chapter 4: Working in Guidewire Studio
 Guidewire PolicyCenter 9.0.9 Configuration Guide

// Add custom project specific configuration here if needed

[Link] = false

The following table lists and describes the available configuration options for Gosu compilation.

Configuration option Default value Description

[Link] false Supports enabling checked arithmetic, which
generates Gosu exceptions for [Link] overflow
errors
[Link] true Supports terminating a compilation task if the
number of errors exceeds the value that maxErrs
specifies.
[Link] 100 Specifies the permitted number of compilation
errors after which the compilation task fails if
failOnError is set to true. The compilation task
checks this value after compiling each file and
terminates if the number of errors is greater than
this value. If a file generates multiple compilation
errors, the reported number of errors can be
more than one greater than this option value.
[Link] [Link] Specifies the permitted number of compilation
warnings after which the compilation task fails if
warnings is set to true. The compilation task
checks this value after compiling each file and
terminates if the number of warnings is greater
than this value. If a file generates multiple compi‐
lation warnings, the reported number of warn‐
ings can be more than one greater than this op‐
tion value.
[Link] false Specifies whether to print a message to the log
for every file that the task compiles.
[Link] false Supports terminating a compilation task if the
number of warnings exceeds the value that
maxWarns specifies.

Examples
Each example stands alone. Remove the line or lines that you added for one example before you try the next
example.
• Add the following line to the top of the [Link] file.
[Link] = true

At the command prompt run the gwb compile command. When you run a compiled class that causes a numeric
overflow, the class throws an arithmetic exception and terminates.
• Add the following line to the top of the [Link] file.
[Link] = false

At the command prompt run the gwb compile command. Even if there are multiple compilation errors, the task
ignores the maxErrs option and compiles all available Gosu classes. Output similar to the following lines
appears.
Error threshold of 10 exceeded; aborting compilation.
gosuc completed with 12 errors. Warnings were disabled.

Working in Guidewire Studio 111

Guidewire PolicyCenter 9.0.9 Configuration Guide

:modules:configuration:compileGosu completed with errors, but ignoring as 'gosuO

[Link] = false' was specified.

• Add the following lines to the top of the [Link] file.

[Link] = true
[Link] = 10

At the command prompt run the gwb compile command. If the number of compilation errors after completing
compilation of any Gosu file is greater than maxErrs, the compilation task terminates. Output similar to the
following lines appears.
Error threshold of 10 exceeded; aborting compilation.
gosuc completed with 12 errors. Warnings were disabled.

:modules:configuration:compileGosu FAILED

FAILURE: Build failed with an exception.

* What went wrong:

Execution failed for task ':modules:configuration:compileGosu'.
> Compilation failed with exit code 1; see the compiler error output for details.

• Add the following line to the top of the [Link] file.

[Link] = true
[Link] = 100

At the command prompt run the gwb compile command. If the number of compilation warnings after
completing compilation of any Gosu file is greater than maxWarns, the compilation task terminates. Output
similar to the following lines appears.
Warning threshold of 100 exceeded; aborting compilation.
gosuc completed with 129 warnings and 0 errors.

:modules:configuration:compileGosu FAILED

FAILURE: Build failed with an exception.

* What went wrong:

Execution failed for task ':modules:configuration:compileGosu'.
> Compilation failed with exit code 1; see the compiler error output for details.

• Add the following line to the top of the [Link] file.

[Link] = true

At the command prompt run the gwb compile command. Output similar to the following lines appears.
gosuc: about to compile file: C:\Guidewire\PolicyCenter\modules\configuration\gsrc\gw\policy
\[Link]
gosuc: about to compile file: C:\Guidewire\PolicyCenter\modules\configuration\gsrc\gw\policy
\[Link]

See also
• Gosu Reference Guide

Suppressing compiler warnings

Gosu provides limited support for the Java annotation, @SuppressWarnings. As its namesake indicates, the
@SuppressWarnings annotation informs a compiler to suppress warnings.

112 chapter 4: Working in Guidewire Studio

 Guidewire PolicyCenter 9.0.9 Configuration Guide

You can use the @SuppressWarnings annotation in several kinds of declarations. Such declarations exclude
declarations of local variables. Instead, the @SuppressWarnings annotation can apply to declarations of the
following categories:
• Type
• Function
• Property
• Constructor
• Field
• Parameter
The @SuppressWarnings annotation requires one parameter. This parameter is a String value that indicates the
warnings you wish to suppress.
For example, suppose you pass in the argument "all" into the @SuppressWarnings annotation. The annotation
invocation in this case would be @SuppressWarnings("all"). The effect of the annotation would be to suppress all
warnings.
For another example, suppose instead that you pass in the argument "deprecation" into the @SuppressWarnings
annotation. Suppose further that you invoke the annotation on the line prior to a Gosu class declaration. The
invocation in this case would be @SuppressWarnings("deprecation"). The effect of this annotation is to suppress
all deprecation warnings for the Gosu class you have declared.

Editing the XML definition of Studio resources

About this task
The editors in Guidewire Studio provide a visual editing environment for many resources. In addition to using the
visual editors, you can also edit the underlying XML code that defines the resource. Guidewire recommends that
you edit the XML code only within Studio, and that you do not edit it in an external editor.

Procedure
1. Open the resource in the Studio editor.
2. At the bottom of the editor pane, click the Text tab. The XML definition is shown in the editor pane.
3. Modify the XML as desired.
4. To switch back to the visual editor, click the tab next to the Text tab that shows the type of the resource that
you are editing.

Next steps
Make sure that the XML remains valid, and that you do not introduce any syntax errors. If the XML contains errors,
the representation of the resource in the visual editor may not be accurate.

Working in Guidewire Studio 113

Guidewire PolicyCenter 9.0.9 Configuration Guide

114 chapter 4: Working in Guidewire Studio

chapter 5

Working with Guidewire Studio

This topic describes Guidewire Studio and the Studio development environment.

Improving Studio performance

• “Set the maximum amount of memory available to Guidewire Studio” on page 115
• “Set the amount of memory for project builds in Guidewire Studio” on page 116

Set the maximum amount of memory available to Guidewire Studio

About this task
If Guidewire Studio is running slowly, you can increase the amount of memory available to it. Additional memory
allocated might improve Studio performance.

Procedure
1. Edit the file PolicyCenter/modules/script/[Link].
2. Locate the studio section:

studio {
...
}

3. Within this section, set the following properties:

ideaProperties["[Link]"] = "memory_value"

Set memory_value to the number of megabytes desired, followed by the letter m. For example, to assign Studio
6GB, set this property to 6000m. The default value is 4000m.
Note: To set the memory for IntelliJ IDEA with OSGi Editor, set the property
[Link].
4. Restart Studio.

See also
• “Setting IntelliJ IDEA properties in Studio” on page 102
•
Working with Guidewire Studio 115
Guidewire PolicyCenter 9.0.9 Configuration Guide

Set the amount of memory for project builds in Guidewire Studio

About this task
You can set the amount of memory available to Guidewire Studio during project builds and compilation. This may
reduce the time required for these actions.

Procedure
1. In Studio, click File→Settings.
2. In the Settings dialog, navigate to Build, Execution, Deployment→Compiler.
3. In the Build process heap size text box, type the number of megabytes.
For example, to assign Studio 12GB for project builds, set this property to 12000.

Resetting Guidewire Studio

Some changes that you make to Guidewire Studio or configuration files may result in Studio having obsolete file
references. For example, if you relocate the Guidewire Studio installation directory, or reinstall a source control
system, then Studio may produce compilation errors due to incorrect file references.
To correct obsolete file references, you can do the following:
• “Rebuild the Studio project files” on page 116
• “Rebuild the Studio file index cache” on page 116

Rebuild the Studio project files

Procedure
1. At a command prompt, change to the PolicyCenter directory.
2. Run the following command:
gwb cleanIdea

Rebuild the Studio file index cache

Procedure
1. Run Guidewire Studio.
2. On the File menu, click Invalidate Caches / Restart.
3. In the Invalidate Caches confirmation dialog, click Invalidate and Restart.

Setting font display options

About this task
You can set values for:
• Text font and size
• Character format properties
• Foreground and background colors of various language elements
116 chapter 5: Working with Guidewire Studio
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Note: You can set anti-aliasing of fonts in the editor Appearance settings page at
File→Settings→Editor→Appearance. Additionally, you can set font size zooming with the Ctrl+Mouse
wheel in the main Editor settings page at File→Settings→Editor.

Procedure
1. Navigate to File→Settings→Editor→Colors & Fonts.
2. Use the Colors & Fonts menu selections to set Studio display of text in the editors.
For example, if you click Gosu, you can set the font type and size of Gosu code in the editor.
3. You can also set how Studio displays specific Gosu code items, such as keywords or operators.
Studio displays a code sample at the bottom of the dialog that reflects your settings.

Working with Guidewire Studio 117

Guidewire PolicyCenter 9.0.9 Configuration Guide

118 chapter 5: Working with Guidewire Studio

chapter 6

Guidewire Studio and Gosu

This topic discusses how to work with Gosu code in Guidewire Studio.

Gosu building blocks

Guidewire provides a number of building blocks to assist you in implementing, configuring, and testing your
business logic in PolicyCenter. These include the following:
• Gosu classes and enhancements
• Gosu base library methods
• Gosu rules
• Gosu tests
• Gosu script parameters
For information on each of these, see the following:
• For general information on Gosu classes, see the Gosu Reference Guide.
• For information on the PolicyCenter base configuration classes see, “PolicyCenter base configuration classes” on
page 121.
• For information on the @export annotation and how it affects a class in Studio, see “Class visibility in Studio” on
page 122.
• For general information on Gosu enhancements, see the Gosu Reference Guide.
• For information on using Gosu business rules within Guidewire PolicyCenter, see the Rules Guide.
• For information on script parameters and how to use them in Gosu code, see “Script parameters” on page 125.

Gosu case sensitivity

Guidewire code is case sensitive. Access existing types exactly as they are declared, including correct capitalization.
For example, if a type is declared as MyClass, you cannot refer to it as myClass or myclass. Use the Gosu editor’s
code completion feature to enter the names of types and properties correctly.
To assist you, Studio highlights issues with case sensitivity.
The following table lists conventions for capitalization of various Gosu language elements:

Guidewire Studio and Gosu 119

Guidewire PolicyCenter 9.0.9 Configuration Guide

Language element Standard capitalization Example

Gosu keywords Always specify Gosu keywords correctly, typically lowercase. if
Type names, including class names Uppercase first character DateUtil
Claim

Local variable names Lowercase first character myClaim

Property names Uppercase first character CarColor

Method names Lowercase first character printReport

Package names Lowercase all letters in packages and subpackages [Link].*

Working with Gosu in PolicyCenter Studio

It is possible to create the following by selecting New from the Classes right-click menu:

Classes→New More information

Class • “Gosu classes” on page 120

• Gosu Reference Guide
Interface • Gosu Reference Guide
Enhancement • “Gosu enhancements” on page 124
• Gosu Reference Guide
Template • Gosu Reference Guide
Package • “Gosu packages” on page 120
GX Model • Gosu Reference Guide

Gosu packages
Guidewire PolicyCenter stores Gosu classes, enhancements, and templates in hierarchical structure known as
packages. To access a package, expand the Classes node in the Studio Resources tree.
Note: You can delete only an empty package.

Create a new package

About this task
It is possible to nest package names to create a dot-separated package name by selecting a package and repeating
these steps.

Procedure
1. Select Classes in the Resources tree.
2. Right-click, select New, then Package from the menu.
3. Enter the name for this package.
4. Click OK to save your work and exit this dialog.

Gosu classes
Gosu classes correspond to Java classes. Gosu classes reside in a file-based package structure. You can extend
classes in the base configuration of PolicyCenter to add properties and methods, and you can write your own Gosu
120 chapter 6: Guidewire Studio and Gosu
 Guidewire PolicyCenter 9.0.9 Configuration Guide

classes. You define classes in Gosu, and you access the properties and call the methods of Gosu classes from Gosu
code within methods.
You create and reference Gosu classes by name, just as in Java. For example, you define a class named MyClass in a
package named MyPackage. You define a method on your class named getName. After you define your class, you
can instantiate an instance of the class and call the method on that instance, as the following Gosu sample code
demonstrates.
var myClassInstance = new [Link]()
var name = [Link]()

Studio stores enhancement files in the gsrc folder in the resources tree. Gosu class files end in .gs.

See also
• “PolicyCenter base configuration classes” on page 121
• “Class visibility in Studio” on page 122
• “Preloading Gosu classes” on page 123
• Gosu Reference Guide

Create a new Gosu class

1. First create a package for your new class, if you have not already done so.
2. Select the package in the configuration tree.
3. Right-click, select New, then Gosu Class from the menu.
4. Enter the name for this class. (You can also set the resource context for this class at this time.)
5. Click OK to save your work and exit this dialog.

PolicyCenter base configuration classes

The gsrc resource folder contains Guidewire classes and enhancements—divided into packages—that provide
additional business functionality. In the base configuration, Studio contains the following packages in the gsrc
folder:
• com
• gw
• wsi
If you create new classes and enhancements, Guidewire recommends that you create your own subpackages in the
gsrc folder, rather than adding to the existing Guidewire folders.

The com package

In the base configuration, the com package contains a single Gosu class:
[Link]

For a discussion of the QuickJump functionality, see “Implementing QuickJump commands” on page 141.

The gw package
In the base PolicyCenter configuration, the gw.* Gosu class libraries contain a number of Gosu classes, divided into
subpackages by functional area. To access these libraries, you merely need to type gw. (gw dot) in a Studio editor.
The following subpackages under the gw package play an important role in Studio:
• [Link].*
• [Link]
Guidewire Studio and Gosu 121
Guidewire PolicyCenter 9.0.9 Configuration Guide

[Link].*
There are actually two [Link] packages that you can access:
• One consists of a set of built-in library functions that you can access and use, but not modify.
• The other set of library functions is visible in the Studio gsrc folder in the configuration tree. You cannot only
access these classes but also modify them to suit your business needs.
You access both the same way, by entering [Link] in the Gosu editor. You can then choose a package or class that
falls into one category or the other. For example, if you enter [Link]. in the Gosu editor, the Studio Complete Code
feature provides you with the following list:
• activity
• address
• admin
• ...
In this case, the activity and admin packages contain read-only classes. The address package is visible in Studio,
in the gsrc folder.

[Link]
If you create a new Gosu plugin, place your plugin class in the [Link] package.

See also
• For information on how to use Studio to work with plugins, see “Using the plugins registry editor” on page 133.
• For information on various types of plugins and how to implement plugins, see the Integration Guide.

The wsi package

PolicyCenter provides a fully WS-I standard-compliant web services layer for both server (publishing) and client
(consuming) web service APIs. The wsi package provides means of working with WS-I compliant web services.

See also
• “Using the web service editor” on page 139
• Integration Guide

Class visibility in Studio

For a Guidewire-provided Gosu class to be directly visible in Guidewire Studio™, Guidewire must mark that class
with the @export annotation. If a class is not marked @export, you might be able to access it in the file structure but
not see it in Studio.
If you need to access the class, simply create a new class and have it extend or subclass the class that you need.
For example, suppose that in PolicyCenter, the application source code defines a CCPCSearchCriteria class. This
class is visible in the application file structure as a read-only file in the following location:
PolicyCenter/modules/configuration/gsrc/gw/webservice/pc/pc900/ccintegration/ccentities

To access the class functionality, first create a new class in the following Studio Classes package:
[Link]

You then have this class extend CCPCSearchCriteria, for example:

package [Link]

uses [Link]
uses [Link]
uses [Link]

class MyClass extends CCPCSearchCriteria {

var _accountNumber : String as AccountNumber

122 chapter 6: Guidewire Studio and Gosu

 Guidewire PolicyCenter 9.0.9 Configuration Guide

var _asOfDate : Date as AsOfDate

var _nonRenewalCode : String as NonRenewalCode
var _policyNumber : String as PolicyNumber
var _policyStatus : String as PolicyStatus
var _producerCodeString : String as ProducerCodeString
var _producerString : String as ProducerString
var _product : String as Product
var _productCode : String as ProductCode
var _state : String as State
var _firstName : String as FirstName
var _lastName : String as LastName
var _companyName : String as CompanyName
var _taxID : String as TaxID

construct() { }

override function extractInternalCriteria() : PolicySearchCriteria {

var criteria = new PolicySearchCriteria()
[Link] = SearchObjectType.TC_POLICY
...
}
}

Preloading Gosu classes

PolicyCenter provides a preload mechanism to support preloading of Gosu classes, as well as other primary classes.
The intent is to make the system more responsive the first time requests are made for that class. This is meant to
improve application performance by preloading some of the necessary application types.
To support this, Guidewire provides a [Link] file in Other Resources to which you can add the following:

Static meth‐ Static method invocations dictate some kind of action and have the following syntax:
od invoca‐ type#method
tions The referenced method must be a static, no‐argument method. However, the method can be on either a Java
or Gosu type.
In the base configuration, Guidewire includes some actions on the [Link] class. For
example, to cause all Gosu types to be loaded from disk, use the following:
[Link]#headerCompileAllGosuClasses
You can add additional lines that call static methods.
Type names Type names can be either Gosu or Java types. You must use the fully‐qualified name of the type. For any Java or
Gosu type that you list in this file:
• Java – PolicyCenter loads the associated Java class file.
• Gosu – PolicyCenter parses and compiles the type to Java byte code, as well as any Gosu blocks and inner
classes within that type.

Guidewire provides the logging category [Link], which provides DEBUG level logging of all actions and
preloaded types.

Populate the list of types

Before you begin
Guidewire recommends that you first perform whatever actions you need to within PolicyCenter interface.

Procedure
1. Navigate to the Loaded Gosu Classes page (Server Tools→Info Pages).
2. Copy and paste the list that you see there into the [Link] file.

Result
The next time that you start the application server, PolicyCenter compiles those types on startup.
Guidewire Studio and Gosu 123
Guidewire PolicyCenter 9.0.9 Configuration Guide

Gosu enhancements
Gosu enhancements provide additional methods (functionality) on a Guidewire entity. For example, suppose that
you create an enhancement to the Activity entity. Within this enhancement, you add methods that support new
functionality. Then, if you type Activity. (Activity dot) within any Gosu code, Studio automatically uses code
completion on the Activity entity. It also automatically displays any methods that you have defined in your
Activity enhancement, along with the native Activity entity methods.
Studio stores enhancement files in the gsrc folder in the resources tree.
• Gosu class files end in .gs.
• Gosu enhancement files end in .gsx.
The Gosu language defines the following terms:
• Classes – Gosu classes encapsulate data and code for a specific purpose. You can subclass and extend existing
classes. You can store and access data and methods on an instance of the class or on the class itself. Gosu classes
can also implement Gosu interfaces.
• Enhancements – Gosu enhancements are a Gosu language feature that allows you to augment classes and other
types with additional concrete methods and properties. For example, use enhancements to define additional
utility methods on a Java class or interface that you cannot directly modify. Also, you can use an enhancement to
extend Gosu classes, Guidewire entities, or Java classes with additional behaviors.

Create a new enhancement

Before you begin
If you have not already done so, first create a package for your new class.

Procedure
1. In Guidewire Studio, in the Project tool window, navigate to configuration→gsrc, and then to the package for
your new class.
2. Right-click the package, and then click New→Gosu Enhancement.
3. Type the name for the enhancement.
Guidewire strongly recommends that you end each enhancement name with the word Enhancement.
For example, if you create an enhancement for an Activity entity, name your enhancement
ActivityEnhancement.
4. Enter the entity type to enhance.
For example, if enhancing an Activity entity, enter Activity.

See also
• Gosu Reference Guide

XML and GX models

Business data entities, Gosu class data, and other types can be exported as XML by using a GX model. The model is
built by selecting the desired properties from the data type. While selecting the properties to map, PolicyCenter
automatically creates an XSD schema to describe the model’s XML structure. At run time, an object’s data can be
converted to XML by creating an instance of the GX model.

Define a GX model
1. Navigate to the Classes package in which you want to create the GX model.
2. Right-click the package name, and then click New→GX Model.
124 chapter 6: Guidewire Studio and Gosu
 Guidewire PolicyCenter 9.0.9 Configuration Guide

See also
• Gosu Reference Guide

Script parameters
Script parameters are resources defined in Guidewire Studio™ that you can use as global variables in Gosu code.
System administrators change the values of script parameters on the Administration tab. Changes to values take effect
immediately in Gosu code.

Script parameters overview

PolicyCenter uses the [Link] configuration file as the system of record for script parameter
definitions and their initial values. You can create script parameters only in Studio, by navigating to
configuration→config→resources→[Link]. At the time of creation, Studio adds new script parameters to
the [Link] configuration file. After creation, you manage the values of script parameters through
the PolicyCenter user interface, not through Studio.
On server startup, PolicyCenter compares the list of script parameters that currently reside in the database to those in
the ScriptParameters file. During the comparison, PolicyCenter does one of the following:
• New script parameters – PolicyCenter adds to the database new script parameters in the XML file that are not
in the database. PolicyCenter propagates the initial values as set in the XML file to the database.
• Existing script parameters – PolicyCenter ignores existing script parameters in the XML file that already are in
the database. PolicyCenter does not propagate changed values for existing parameters from the XML file to the
database.
After a script parameter resides in the database, you manage it solely from the Script Parameters administration screen
in the PolicyCenter administrative interface. You access the Script Parameters screen by first logging on with an
administrative account, then navigating to Administration→Utilities→Script Parameters.

IMPORTANT After you create a script parameter in Studio, PolicyCenter ignores subsequent changes
that you make to the parameter value. You must make all subsequent changes to parameter values in
the Script Parameters administration screen of the PolicyCenter user interface.

Script parameters as global variables

There are several reasons to create global variables:
• You want a variable that is global in scope across the application that you can change or reset through the
application interface.
• You want a variable to hold a value that you can use in any Gosu expression, and you want to change that value
without editing the expression.
These two reasons for use of script parameters, while seemingly related, are entirely independent of each other.
• Use script parameters to create variables that you can change or reset through the PolicyCenter interface.
• Use Gosu class variables to create variables for use in Gosu expressions.
For information on Gosu class variables, see the Gosu Reference Guide.

Script parameter examples

Suppose, for example, that you have exception rules that trigger when an activity is overdue for more than five (5)
days. If you included the value “5” in all of the rules, you would have to modify the rules if you decided to change
the value to ten (10). Instead, define a script parameter, set its value to five (5), and then use this parameter in the
rules. To change the activity exception behavior, you need change only the parameter, and the rules automatically
uses the new value.
Guidewire Studio and Gosu 125
Guidewire PolicyCenter 9.0.9 Configuration Guide

More complex examples include:

• Setting the number of days before the policy end date to start the renewal process – It is possible that this
varies by policy type and Line of Business.
• Setting the maximum number of years for automatic policy renewal without an underwriting review –
After the set number of threshold years passes, the Rule engine generates an activity to manually review the
policy.
• Setting the date in which new policy terms come into effect – This effectively requires all policies created
after a given date to contain certain forms and amendment, for example.
Note: Script parameters are read-only within Gosu. You cannot set the value of a script parameter in a
Gosu statement or expression.

Working with script parameters

In working with script parameters:
• You create script parameters, set their initial values, and create property getter methods in Guidewire Studio.
• You administer script parameters and modify their values in the PolicyCenter interface, on the Administration tab.
The application server references only the initial values for script parameters that you set in Guidewire Studio.
Thereafter, the application server references the values that you set through the PolicyCenter interface and ignores
subsequent changes to values that you set as set in Studio.
A script parameter definition is provided in a <ScriptParameterPack> element within the <script-parameters>
element in the [Link] configuration file. The following lines show the basic attributes and
subelements for a script parameter definition:
<script-parameters>
<ScriptParameterPack ParamName="ParameterName" ParamType="datatype">
<ParamValue>value</ParamValue>
</ScriptParameterPack>
</script-parameters>

To see the data types available for script parameters, examine the ScriptParameter entity definition. This entity
contains properties for each valid type. For example, ScriptParameter uses BitValue for bit, DatetimeValue for
datetime, IntegerValue for decimal, and VarcharValue for varchar script parameter values.
To make a new script parameter value available in Gosu, you must provide a getter method in the script parameters
enhancement file.

IMPORTANT After you create a script parameter in Studio, PolicyCenter ignores subsequent changes
that you make to the parameter value. You must make all subsequent changes to parameter values in
the Script Parameters administration screen of the PolicyCenter user interface.

Create a script parameter

Procedure
1. In Guidewire Studio, in the Project tool window, navigate to configuration→config→resources, and then open the
file [Link].
2. Edit the XML and define your new parameter using the existing format as a guide.
3. Navigate to configuration→gsrc→gw→scriptparameter, and then double-click ScriptParametersEnhancement.
4. Add a static property getter method that returns a value of the correct data type for the new parameter.
For example, for a script parameter of type varchar, use code similar to the following:
public static property get MyNewScriptParameter(): String {
return [Link]("MyNewScriptParameter") as String;
}

126 chapter 6: Guidewire Studio and Gosu

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Delete a script parameter

About this task
You can delete a script parameter if you no longer reference it in any Gosu expression.

Procedure
1. In Guidewire Studio, in the Project tool window, navigate to configuration→config→resources, and then open the
file [Link].
2. Edit the XML and remove the element defining the parameter to delete.

Referencing a script parameter in Gosu

You can access a script parameter in Gosu through the globally accessible ScriptParameters object. Within Gosu,
you access a parameter by using [Link].
For example, the following Gosu code determines if it is more than five days past an activities due date:
[Link]( [Link] ) > 5

You can, instead, create a script parameter named escalationTime, set its value to 5, and rewrite the line as
follows:
[Link]( [Link] ) > [Link]

Note: Guidewire recommends that you use Gosu class variables instead of script parameters to
reference values in Gosu expressions. The exception would be if you needed the ability to reset the
value from the PolicyCenter interface.

PolicyCenter script parameters

The base configuration of PolicyCenter includes the script parameter EnableDisplayBasicSearchTab. You
administer script parameters and modify their values on the Script Parameters page of the Administration tab.

See also
• “Configuration parameters and files for free-text search in PolicyCenter” on page 409
• “Enabling free-text search in PolicyCenter” on page 411
• “Enabling the free-text search user interface in PolicyCenter” on page 412

Guidewire Studio and Gosu 127

Guidewire PolicyCenter 9.0.9 Configuration Guide

128 chapter 6: Guidewire Studio and Gosu

Part 3

Guidewire Studio editors

Guidewire PolicyCenter 9.0.9 Configuration Guide
chapter 7

Using the Studio editors

This topic discusses the various editors available to you in Guidewire Studio.

Editing in Guidewire Studio

Guidewire Studio displays PolicyCenter resources in the left-most Studio pane. After you select a resource, Studio
automatically loads the editor associated with that resource into the Studio work space. Studio contains the
following editors:

Editor Use to... More information

Display Keys Graphically create and define display keys. “Using the display keys editor” on page 157
Entity Names Represent an entity name as a text string suitable for view‐ “Using the entity names editor” on page 147
ing in the PolicyCenter interface.
Gosu Create and manage Gosu code used in classes, tests, en‐ “Working in the Gosu editor” on page 132
hancements, and interfaces.
Messaging Work with messaging plugins. “Using the messaging editor” on page 153
Page Configura‐ Graphically define and edit page configuration (PCF) files, “Using the PCF editor” on page 349
tion (PCF) used to render the PolicyCenter Web interface.
Plugins Graphically define, edit and manage Java and Gosu plugins. “Using the plugins registry editor” on
page 133
Product Model Define and configure the PolicyCenter product model. “Using Product Designer to edit the product
model” on page 132
System Tables Define PolicyCenter system tables. Product Model Guide
Typelist Define typelists for use in the application. “Working with typelists” on page 303
Workflows Graphically define and edit application workflows. “Using the workflow editor” on page 441

Using the Studio editors 131

Guidewire PolicyCenter 9.0.9 Configuration Guide

Working in the Gosu editor

You use the Gosu editor to manage all code written in Gosu. If you open any of the following from the Resources
pane, Studio automatically opens the file in the Gosu editor:
• Classes
• Enhancements
• Interfaces
• GUnit tests

See also
• Gosu Reference Guide

Using Product Designer to edit the product model

Guidewire Product Designer provides a means of viewing, manipulating, and managing the PolicyCenter product
model using a graphical interface (rather than through configuration files). By using Product Designer, you can
define and configure the following:
• Products
• Policy Lines
• Question Sets
• Audit Schedules
• System Tables
In Product Designer, you can view, edit, and create new instances of each product model component through a web
interface, in either a single-user or mutli-user environment.

See also
• Product Model Guide
• Application Guide

132 chapter 7: Using the Studio editors

chapter 8

Using the plugins registry editor

A PolicyCenter plugin is a mini-program that you can invoke to perform some task or calculate a result.

What are plugins?

PolicyCenter plugins are mini-programs (Gosu or Java classes) that PolicyCenter invokes to perform an action or
calculate a result.
• An example of a plugin that calculates a result is a policy number generation plugin, which PolicyCenter invokes
to generate a new policy number as necessary.
• An example of a plugin that performs an action would be a message transport plugin, the purpose of which is to
send a message to an external system.

Plugin implementation classes

A Guidewire plugin class implements a specific plugin interface. Guidewire provides a set of plugin interfaces in the
base configuration. You can create a new class that implements the plugin interface for your business needs. You can
choose to implement a plugin as either a Gosu class, Java class, or OSGi bundle. Alternatively, if the PolicyCenter
base configuration already provides a implementation of the plugin interface, then you can register it.

See also
• Integration Guide

What is the plugins registry?

Within Studio, expand the configuration→config →Plugins→registry node to view the contents of the Plugins Registry.
Each item in the Plugins Registry is a .gwp file that represents a plugin implementation in the base configuration. To
configure a particular plugin, double-click its name in the registry to enter the Plugins Registry editor.
Each Plugins Registry item (each .gwp file) includes fields for the following information:
• Plugin name – A unique name for this plugin implementation. Plugin names can include alphanumeric
characters only. Space or blank characters are not allowed. If the plugin interface supports only a single
implementation, make this the name of the interface without the package.
• Implementation class – The plugin implementation class as a fully-qualified class name.
• Plugin interface – The interface that the class implements. If the plugin interface field is left blank, PolicyCenter
uses the plugin name as the interface name.
Using the plugins registry editor 133
Guidewire PolicyCenter 9.0.9 Configuration Guide

The Plugins Registry fields work slightly differently depending on whether the interface supports multiple
implementations. Most plugin interfaces supports only a single plugin implementation. Other plugin interfaces, such
as messaging plugins and startable plugins, support multiple plugin implementations.

See also
• For the maximum number of supported implementations for each plugin interface, see the table the Integration
Guide.

Startable plugins
To register code that runs at server start up, you register startable plugin implementations. Startable plugins
implement the IStartablePlugin interface. Typically, startable plugins are implemented as daemons, such as
listeners to JMS queues. Unlike standard Guidewire plugins, you can stop and start startable plugins from the
administrative interface. Alternatively, you can use PolicyCenter multi-threaded inbound integration APIs, which
use startable plugins.

See also
• Integration Guide

Working with plugins

Create a Plugins Registry item
Procedure
1. In the Project tool window, navigate to configuration→config →Plugins→registry.
2. Right-click registry, and then click New→Plugin.
3. In the Name text box, type the plugin name. If the interface supports only a single implementation, use the
same name as the plugin interface. For the maximum number of supported implementations for each interface,
see the table the Integration Guide.
4. In the Interface box, type the name of the plugin interface, or click Browse to search for valid interfaces.
For all startable plugins, enter IStartablePlugin.

Add an implementation to a Plugins Registry item

Procedure
1. In the Project tool window, navigate to configuration→config →Plugins→registry. In the list of plugin items in the
Plugins Registry, double-click the plugin name to open it in the Plugins Registry editor.
2. Click Add Plugin , and then click the type of plugin to add: Gosu, Java, or OSGi.
Note: Do not change the value of the Name field in this editor.
• Gosu implementations
If you select Add Gosu Plugin, you see the following:

Gosu Type the name of the Gosu class that implements this plugin interface. In the base configuration, Guidewire
Class places all Gosu plugin implementation classes in the following package under configuration→gsrc:
[Link]

You must enter the fully qualified path to the Gosu implementation class. For example, use
[Link] for the Gosu emailMessageTransport plugin.
134 chapter 8: Using the plugins registry editor
 Guidewire PolicyCenter 9.0.9 Configuration Guide

See the Integration Guide for more information.

• Java implementations
If you select Add Java Plugin, you see the following:

Java Class For the Java class that implements this plugin, type the fully qualified path, which includes the dot‐
separated package path to the class. Place all Java plugin classes that are not provided in the base config‐
uration in the following directory:
PolicyCenter/modules/configuration/plugins/

Plugin Di- (Optional) Type the name of the base plugin directory for the Java class. This is a folder (directory) in the
rectory modules/configuration/plugins directory. If you do not specify a value, Studio assumes that the class
exists in the modules/configuration/plugins/shared directory.
See the Integration Guide.

• OSGi Implementations
If you select Add OSGi Plugin, you see the following:

Service PID Type the fully qualified Java class name for your OSGi implementation class.
See the Integration Guide.

• All Implementations
Optionally, you can set the following:

Environment Type a comma‐separated list of the environments in which the plugin operates.
See “Configuring a plugin environment” on page 135.
Server Type the name of the server on which the plugin operates.
See “Configuring a plugin environment” on page 135.

3. After creating the plugin, you can add parameters to it. To do so, click Add Parameter , and enter the
parameter name and value.

Next steps
For more information on setting environment or server properties, see “Configuring a plugin environment” on
page 135.

Enable and disable a plugin implementation

You can choose to make a plugin implementation inactive using the Disabled checkbox. You can, for example, enable
the plugin implementation for testing and disable it for production. It is important to understand, however, that you
can still access a disabled plugin implementation and call it from code. Enabling or disabling a plugin
implementation is only meaningful for plugins that care about the distinction. For example, you must enable a plugin
for use in messaging in order for the plugin to work and for messages to reach their destination. If it is a concern,
then the plugin user must determine whether a plugin implementation is enabled.
If you change the status of the plugin (from enabled to disabled, or the reverse), then you must restart the application
server for it to pick up this change.

Configuring a plugin environment

A plugin operates in the context of one or more environments. For example, an installation might define separate
environments for production and test. In a clustered environment, a plugin operates on one or more servers.

Specifying plugin operation for environments and servers

Specify the environments in which a plugin operates by using the Plugins Registry editor to set the Environment
property. Multiple environments can be specified in the Environment property by separating each environment with a
comma. For example, if environments have been defined for production and test, a plugin operates in either
Using the plugins registry editor 135
Guidewire PolicyCenter 9.0.9 Configuration Guide

environment or both of them depending on the value you set for the environment property. If you specify any value
in the environment property, the plugin only operates in an environment that matches the value of that property.
By default, a plugin can operate on any server. If PolicyCenter is running in a clustered environment, to restrict the
plugin so that it operates only on a specific server, specify the server ID in the Server property.
If you do not specify a value for the environment property, the plugin operates in all environments. If you do not
specify a value for the server property, the plugin operates on all servers.

Configuring parameter values for environments and servers

To configure a plugin's operation for a particular environment, you can specify parameter values that apply to that
environment. During its execution, the plugin uses a parameter's value to determine the actions to perform.
Environment values are specified for particular parameter Name and Value property pairs.
If the plugin operates in an environment that is not specified for a particular parameter, you can provide a default
value for the parameter by adding a line containing a value for the parameter but leaving the environment property
for the parameter empty. Alternatively, the plugin code can provide a default value for the parameter.
For example, consider a plugin that operates in an environment called production. The plugin provides a parameter
called loglevel. For the production environment, the parameter's value is error. If the plugin is running in the
production environment, retrieving the value of the loglevel parameter instructs the plugin to log events of type
error.

Name Value Environment

loglevel error production

To extend the example, assume the plugin also operates in an environment called test. If both environments are
specified in a single, comma-separated Environment value, the value of error is used for the loglevel parameter if
the plugin operates in either environment.

Name Value Environment

loglevel error production,test

To assign a different loglevel value for each environment, specify the environments on separate lines in the list of
plugin parameters. The loglevel parameter can then provide different values specific to each environment. The
plugin retrieves a different loglevel value based on the environment in which it is operating.

Name Value Environment

loglevel error production

loglevel debug test
loglevel warning

A parameter that does not specify the environment property uses the same value for all environments. In the
following context, the incomingFileDir parameter uses the value /tmp/inbound/incoming for both the
production and test environments.

Name Value Environment

loglevel error production

loglevel debug test
incomingFileDir /tmp/inbound/incoming

136 chapter 8: Using the plugins registry editor

 Guidewire PolicyCenter 9.0.9 Configuration Guide

By default, a plugin uses the same value for a parameter on any server. If PolicyCenter is running in a clustered
environment, you can assign different values for a plugin parameter for specific servers by specifying the server ID
in the Server property. You can provide a default value for a plugin parameter by adding a line containing a value for
the parameter but leaving the server property for the parameter empty. Alternatively, the plugin code can provide a
default value for the parameter.

Name Value Environment Server

transferTimeoutSec 15 messaging
transferTimeoutSec 10 shorttimeout
transferTimeoutSec 120

A parameter that does not specify the server property uses the same value on all servers.

See also
• Integration Guide
• System Administration Guide

Customizing plugin functionality

To modify the behavior of a plugin, do one of the following:
• Modify the underlying class that implements the plugin functionality.
• Change the plugin definition to point to an entirely different Java or Gosu plugin class.
For information on plugins in general, see the Integration Guide.
For information on creating and deploying a specific plugin type, see the following topics:

Plugin type Description More information

Gosu A Gosu class Integration Guide
Java A Java class that does not use the OSGi standard. Integration Guide
Integration Guide
OSGi A Java class inside an OSGi bundle. Integration Guide

Working with plugin versions

If your installation includes more than one Guidewire application, be aware that some plugins exist primarily to
connect to other Guidewire applications. If you want to use the base configuration plugin implementation to connect
to other Guidewire applications, you must ensure that you use the correct version of the plugin implementation. The
name of the classes are equivalent but vary in their package, which includes the application version number.
For the package name, Guidewire includes the application two-character abbreviation followed by the application
version number with no periods. For example, in PolicyCenter 9.0, the package includes pc900.
For example, in the Guidewire PolicyCenter application, the plugin implementation that connects PolicyCenter 9.0
to BillingCenter 9.0 is at the fully qualified path:
[Link]

For integrations with other Guidewire InsuranceSuite applications, choose the plugin implementation class that
matches the version of your applications. Choose the implementation with the proper version number of the other
application (not the current application) in its package name.
Guidewire uses the following abbreviation conventions for naming its applications:
Using the plugins registry editor 137
Guidewire PolicyCenter 9.0.9 Configuration Guide

Application Abbreviation
ClaimCenter cc

PolicyCenter pc

ContactManager ab
BillingCenter bc

138 chapter 8: Using the plugins registry editor

chapter 9

Working with web services

PolicyCenter supports WS-I web services. WS-I web services use the SOAP protocol. This topic discusses how to
define and configure web services with Guidewire Studio.

Using the web service editor

PolicyCenter provides a fully WS-I compliant web services layer for both server publishing and client consuming
web service APIs.
Guidewire Studio™ stores WS-I web service resources in a web service collection. A web service collection
encapsulates the set of resources necessary to connect to a web service on an external server. Typical resources
include one or more web service endpoints and the WSDL and XSD files that they reference. Web service
collections are created and managed in the Studio Web Service editor.
Collection files have a .wsc file extension. The location of the web service collection in the package hierarchy
defines the package for the types that Gosu creates from the associated WSDL.
The Web Service editor consists of several areas.

Editor Description
area
Toolbar The toolbar is located directly above the Resources pane. The toolbar icons provide the following actions.
• Add New Resource – Create new URL resource to the web service WSDL file.
• Edit Resource ‐ Edit the URL resource to the web service WSDL file.
• Remove Resource – Remove the URL from the list of web service resources.
• Move Up ‐ Move the selected URL resource up one level in the list of resources.
• Move Down ‐ Move the selected URL resource down one level in the list of resources.
• Fetch – Retrieve WSDL and XSD files for a web service resource. The retrieved files are shown in the editor's
Fetched Resources tab.
• Setup Environment ‐ Show the Studio Settings window. In the window's Sidebar, select Guidewire Studio to show
the Web Services Environment setting.
Resources Contains the list of defined URL resources for the web service. Each URL points to a web service WSDL file. The
pane WSDL file can exist in any of the following locations.
• The local file system
• A local server
• A remote server

Working with web services 139

Guidewire PolicyCenter 9.0.9 Configuration Guide

Editor Description
area
Settings tab Create and manage configuration entries for the web service. The following types of configuration entries are
supported.
• Configuration Provider – Specifies a class that implements the IWsiWebserviceConfigurationProvider
interface.
• Override URL – Specifies an override proxy URL for the web service.
See the Integration Guide.
Fetched Re- Shows the WSDL and XSD files for the web services.
sources tab

See also
• Integration Guide

Defining a web service collection

To consume an external web service, the associated WSDL and schema files for the web service must be loaded into
the local namespace. This operation is performed by defining a web service collection in PolicyCenter Studio. In the
base configuration, Guidewire provides a number of default web service collections in the following hierarchy.
configuration→gsrc→wsi.
Guidewire recommends that new web service collections be created within this directory structure.

Create a web service collection

Procedure
1. In Studio, navigate in the configuration→gsrc→wsi hierarchy to a package in which to store the collection file.
2. Right-click and choose New→Webservice Collection. Studio prompts for a name for the web service collection.
Enter a name for the web service collection and click OK to show the Web Service editor.
3. On the editor toolbar, click the Add New Resource icon.
4. In the Add Resource window, enter the URL of the WSDL for the external web service. This is also called the
web service endpoint URL. After a valid URL is entered, click OK.
5. Studio recognizes that the list of resource URLs has been modified and offers to fetch updated resources.
Click Yes. Studio retrieves the WSDL and XSD files for the web service. The file contents can be viewed in
the Fetched Resources tab. Updated resources can be fetched at any time by clicking the toolbar's Fetch icon.
6. The created collection URL is shown in the editor’s Resources pane.

140 chapter 9: Working with web services

chapter 10

Implementing QuickJump commands

This topic discusses how you can configure, or create new, QuickJump commands.

What Is QuickJump?
The QuickJump box is a text-entry box for entering navigation commands using keyboard shortcuts. Guidewire places
the box at the upper-right corner of each PolicyCenter screen. You set which commands are valid through the
QuickJump configuration editor. At least one command must exist (be defined) in order for the QuickJump box to appear
in PolicyCenter. (Therefore, to remove the QuickJump box from the PolicyCenter interface, remove all commands
from the QuickJump configuration editor.)
You set the keyboard shortcut that activates the QuickJump box in [Link]. The default key is “/” (a forward
slash). Therefore, the default action to access the box is Alt+/.
There are three basic types of navigation commands:

Type Use for

QuickJumpCom‐ Commands that navigate to a page that accepts one or more static (with respect to the command being
mandRef defined) user‐entered parameters. See “Implementing QuickJumpCommandRef commands” on
page 142 for details.
StaticNavigation‐ Commands that navigate to a page without accepting user‐entered parameters. See “Implementing Stat‐
CommandRef icNavigationCommandRef commands” on page 143.
ContextualNaviga‐ Commands that navigate to a page that takes a single parameter, with the parameter determined based
tionCommandRef on the user's current location. See “Implementing ContextualNavigationCommandRef commands” on
page 144.

Adding a QuickJump navigation command

If you add a command, first set the command type, then define the command by setting certain parameters. The
editor contains a table with each row defining a single command and each column representing a specific command
parameter. You use certain columns with specific command types only. PolicyCenter enables only those row cells
that are appropriate for the command, meaning that you can only enter text in those specific fields.

Implementing QuickJump commands 141

Guidewire PolicyCenter 9.0.9 Configuration Guide

Column Only use with Description

Command Name • QuickJumpCommandRef Display key specifying the command string the user types to
• StaticNavigationCommandRef invoke the command. Note that the command string must not
• ContextualNavigationCommandRef contain a space.
Command Class • QuickJumpCommandRef Class that specifies how to implement the command. This
class must be a subclass of QuickJumpCommand. Guidewire in‐
tentionally makes the base QuickJumpCommand class package
local. To implement, override one of the subclasses described
in “Implementing QuickJumpCommandRef commands” on
page 142.
You only need to subclass QuickJumpCommand if you plan to
implement the QuickJumpCommandRef command type. For the
other two command types, you use the existing base class ap‐
propriate for the command—either
StaticNavigationCommand or
ContextualNavigationCommand—and enter the other re‐
quired information in the appropriate columns.
Command Target • StaticNavigationCommandRef Target page ID.
• ContextualNavigationCommandRef
Command Argu‐ • StaticNavigationCommandRef Comma‐separated list of parameters used in the case in which
ments the target page accepts one or more string parameters. (This is
not common.)
Context Symbol • ContextualNavigationCommandRef Name of a variable on the user's current page.
Context Type • ContextualNavigationCommandRef Type of context symbol (variable).

Implementing QuickJumpCommandRef commands

To implement the QuickJumpCommandRef navigation command type, subclass QuickJumpCommand or one of its
existing subclasses. See the following sections for details:

Subclass Section
StaticNavigationCommand “Implementing QuickJumpCommandRef commands” on page 142
ParameterizedNavigationCommand “Implementing QuickJumpCommandRef commands” on page 142

ContextualNavigationCommand “Implementing QuickJumpCommandRef commands” on page 142

EntityViewCommand “Implementing QuickJumpCommandRef commands” on page 142

All QuickJumpCommand subclasses must define a constructor that takes a single parameter—the command name—as
a String.

Navigation commands with one or more static parameters

To perform simple navigation to a page that accepts one or more parameters (which are always the same for a given
command), subclass StaticNavigationCommand. The class constructor must call the super constructor, which takes
the following arguments:
• The command name (which you pass into your subclass's constructor)
• The target location's ID
Your subclass implementation must override the getLocationArgumentTypes and getLocationArguments
methods to provide the required parameters for the target location.
It is possible to create a no-parameter implementation by subclassing StaticNavigationCommand. However,
Guidewire recommends that you use the StaticNavigationCommandRef command type instead as it reduces the
142 chapter 10: Implementing QuickJump commands
 Guidewire PolicyCenter 9.0.9 Configuration Guide

number of extraneous classes needed. See “Implementing StaticNavigationCommandRef commands” on page 143
for details.

Navigation commands with an explicit parameter (including search)

To create a command that performs simple navigation to a page that accepts a single user parameter, subclass
ParameterizedNavigationCommand. The constructor takes the same two arguments as
StaticNavigationCommand. Your subclass must override the getParameterSuggestions method, which provides
the list of auto-complete suggestions for the parameter. It must also override the getParameter method, which
creates or fetches the actual parameter object given the user's final input.
Subclasses of ParameterizedNavigationCommand must also implement getCommandDisplaySuffix.
PolicyCenter displays the command in the QuickJump box as part of the auto-complete list (before the user has
entered the entire command). Therefore, PolicyCenter displays the command name followed by the command
display suffix. This is typically some indication of what the parameter is, for example bean name or policy number.

Navigation commands with an inferred parameter

To implement a command that navigates to a page that accepts a single parameter, with the parameter based on the
user's current location, subclass ContextualNavigationCommand. The constructor takes the same two arguments as
StaticNavigationCommand, plus two additional arguments:
• The name of a PCF variable. If this variable exists on the user's current location, Guidewire Studio™ makes the
command available and uses the value of the variable as the parameter to the target location.
• The type of the variable.
Guidewire recommends that you use the ContextualNavigationCommandRef command type instead of subclassing
ContextualNavigationCommand. See “Implementing ContextualNavigationCommandRef commands” on page 144
for details.

Navigation to an entity‐viewing page

For commands that navigate to a page that simply displays information about some entity, subclass
EntityViewCommand. The constructor takes the following arguments:
• The name of the command (which you pass into your subclass's constructor)
• The type of the entity
• A property on the entity to use in matching the user's input (and providing auto-complete suggestions)
• The permission key that determines whether the user has permission to know the entity exists (This is typically a
“view” permission.)
• The target location's ID
Subclasses must override handleEntityNotFound to specify behavior on incomplete or incorrect user input. A
typical implementation simply throws a UserDisplayableException. Subclasses must also implement
getCommandDisplaySuffix, which behaves in the fashion described previously in “Implementing
QuickJumpCommandRef commands” on page 142.
By default, parameter suggestions and parameter matching use a query that finds all entities of the appropriate type
in which the specified property starts with the user's input. If this query is too inefficient, the subclass can override
getQueryProcessor (for auto-complete) and findEntity (for parameter matching). If you do not want some users
to see the command, then the subclass must also override the isPermitted method.
By default, the auto-complete list displays each suggested parameter completion as the name of the command
followed by the value of the matched parameter. Subclasses can override getFullDisplay to change this behavior.
However, the suggested name must not stray too far from the default, as it does not change what appears in the
QuickJump box after a user selects the suggestion. Entity view commands automatically chain to any appropriate
contextual navigation command (for example, “Claim <claim #> Financials”).

Implementing StaticNavigationCommandRef commands

StaticNavigationCommandRef specifies a command that navigates to a page without accepting user-entered
parameters. It is the simplest to implement. You specify the Command Name and Command Target in exactly the
Implementing QuickJump commands 143
Guidewire PolicyCenter 9.0.9 Configuration Guide

same manner as for a static navigation command. You must also specify the Command Target, and any necessary
Command Arguments. These parameters have the following meanings:
• Command Target specifies the ID of the target page.
• Command Arguments specify one or more parameters to use in the case in which the target page accepts one or
more string parameters. If there is more than one parameter, enter a comma-separated list.

Implementing ContextualNavigationCommandRef commands

ContextualNavigationCommandRef specifies a command that navigates to a page that takes a single parameter.
(The user's current location determines the parameter.) You specify the Command Name and Command Target in
exactly the same manner as for a static navigation command. You must also specify the Context Symbol and the
Context Type. These parameters have the following meanings:
• Context Symbol specifies that name of a variable on the user’s current page.
• Context Type specifies that variable’s type.
PolicyCenter passes the value of this variable to the target location as the only parameter. If no such variable exists
on the current page, then the command is not available to the user and the command does not appear in the
QuickJump box’s auto-complete suggestions.
If the Context Type is an entity, then any EntityViewCommands matching the entity type can automatically be
“chained” by the user into the ContextualNavigationCommand. For instance, suppose that there is an
EntityViewCommand called Policy that takes a policy number and navigates to a Policy. Also, suppose that there is
a ContextualNavigationCommand called Contacts whose context type is Policy. In this case, the user can type
Policy 35-402398 Contacts to invoke the Contacts command on the specified Policy.

See also
• “Implementing QuickJumpCommandRef commands” on page 142

Checking permissions on QuickJump navigation commands

Keep the following security issues in mind as you create navigation commands for the QuickJump box.

Subclassing StaticNavigationCommand
Commands that implement this subclass check the canVisit permission by default to determine whether a user has
the necessary permission to see that QuickJump option in the QuickJump box. The permission hole in this case arises
if permissions were in place for all approaches to the destination but not on the destination itself.
For example, suppose that you create a new QuickJump navigation for NewNotePopup. Then suppose that previously
you had placed a permission check on all New Note buttons. In that case PolicyCenter would have checked the
[Link] permissions. However, enabling QuickJump navigation to NewNotePopup bypasses those previous
permissions checks. The best practice is to check permissions on the canVisit tag of the actual destination page, in
this case, on NewNotePopup.

Subclassing ContextualNavigationCommand
As with StaticNavigationCommand subclasses, add permission checks to the destination page's canVisit tag.

Subclassing ParameterizedNavigationCommand
Classes subclassing ParameterizedNavigationCommand have the (previously described) method called
isPermitted, which is possible for you to override. This method—isPermitted—controls whether the user can
see the navigation command in the QuickJump box. After a user invokes a command, PolicyCenter performs standard
permission checks (for example, checking the canVisit expression on the target page), and presents an error
message to unauthorized users.
It is possible for the canVisit expression on the destination page to return a different value depending on the actual
parameters passed into it. As a consequence, PolicyCenter cannot determine automatically whether to display the
144 chapter 10: Implementing QuickJump commands
 Guidewire PolicyCenter 9.0.9 Configuration Guide

command to the user in the QuickJump box before the user enters a value for the parameter. If it is possible to
manually determine whether to display the command to the user, check for permission using the overridden
isPermitted method. (This might be, for example, from the destination's canVisit attribute.)

Implementing QuickJump commands 145

Guidewire PolicyCenter 9.0.9 Configuration Guide

146 chapter 10: Implementing QuickJump commands

chapter 11

Using the entity names editor

This topic describes entity names and entity name types and how to work with the entity names in the Entity Names
editor in Guidewire Studio™.

Entity names editor

It is possible to define an entity name as a text string, which you can then use in the PolicyCenter interface to
represent that entity. Thus, you often see the term display name associated with this feature as well, especially in
code and in Gosu documentation.
PolicyCenter uses the DisplayName property on an entity to represent the entity name as a text string. You can
define this entity name string as a simple text string, or you can use a complicated Gosu expression to generate the
name. PolicyCenter uses these entity name definitions in generating database queries that return the limited
information needed to construct the display name string. This ensures that PolicyCenter does not load the entire
entity and its subentities into memory simply to retrieve the few field values necessary to generate the display name.
The use of the Entity Name feature helps to avoid loading entities into memory unless you are actually going to view
or edit its details. The use of display names improves overall application performance.
The Entity Names editor consists of two parts:
• A table in which you manage variables for use in the Gosu code that defines the entity name
• A Gosu editor that contains the Gosu code that defines the entity name

WARNING Do not reference in an entity name definition either a virtual property or an otherwise
non-queryable column, including an amount virtual property. Failing to follow this guidance will
compromise performance and lead to exceptions.

Variable table
You must declare any field that you reference in the entity definition (in the code definition pane) as a variable in the
variable table at the top of the page. This tells the Entity Name feature which fields to load from the database, and
puts each value in a variable for you to use.
For example, the Contact entity name defines the following variables:

Using the entity names editor 147

Guidewire PolicyCenter 9.0.9 Configuration Guide

Notice that this defines LastName as [Link] and Name as [Link], for example.
Use the variable table to manage variables that you can embed in the Gosu entity name definitions. You can add and
remove variables using the function buttons next to the table. The columns in the table have the following meanings:

Column name Description

Name The name of the variable.
Entity Path [Link] that the variable represents.

Sort Path The values that PolicyCenter uses in a sort.

Sort Order The order in which PolicyCenter sorts the Sort Path values.
Use Entity Name? Whether to use this value as the entity display name.

The Entity Path column

Use only actual columns in the database as members of the Entity Path value. You must declare an actual database
column in metadata, in an actual definition file. If you do not define a column in metadata, then PolicyCenter labels
that entity column (field) as virtual in the PolicyCenter Data Dictionary.
Thus:
• You cannot use ClaimContactRole fields in the Entity Path, such as [Link]. This is
because the Injured contact role on Incident does not have a denormalized column.
• You can, however, use special denormalized fields for certain claim contacts, such as
[Link] or [Link]. The description of the column indicate which
ClaimContactRole value it denormalizes.

The Use Entity Name? column

The last column in the variable table is Use Entity Name? If the column check box is set, then it has a value of true. If
the check box is not set, then it has a value of false.
• A value of true is meaningful only if the value of Entity Path is an entity type. A value of true instructs the Entity
Name utility to calculate the Entity Name for that entity, instead of loading the entity into memory. The variable
for that subentity is of type String and you can use the variable in the Gosu code that constructs the current
Entity Name.
Note: If the value of Entity Path is an entity, then you must set the value of Use Entity Type? to true.
Otherwise, a variable entry that ends in an entity value uploads that entire entity, which defeats the
purpose of using Entity Names.
• A value of false indicates that PolicyCenter does not use the Entity Path value as an entity display name.
• An empty column is the same as a value of false. This is the default.
Set the Use Entity Name? value to true if you want to include the entire Entity Name for a particular subentity. For
example, suppose that you are editing the Exposure entity name and that you create a variable called claimant with
an Entity Path of [Link]. Suppose also that you set the value of Use Entity Name to true. In this
case, the entity name for the Claimant, as defined by the Contact entity name definition, would be included in a
148 chapter 11: Using the entity names editor
 Guidewire PolicyCenter 9.0.9 Configuration Guide

String variable called claimant. PolicyCenter would then use this value in constructing the entity name for the
Exposure entity.
Note: If you set the Use Entity Name? field to true and then attempt to use a virtual field as an Entity
Path value, Studio resource verification generates an error.

Evaluating null values

If the value of Use Entity Name? is true, then PolicyCenter always evaluates the entity name definition, even if the
foreign key is null. By convention, in this case, the entity name definition usually returns the empty string "". In
other words, the entity name string can never be null even if the foreign key is null. You can use the HasContent
enhancement property on String to test whether the display name string is empty.
Thus, as you write entity name definitions, Guidewire recommends that you return the empty string if all the
variables in your entity name definition are null or empty. Guidewire uses the empty string (instead of returning
null) to prevent Null Pointer Exceptions. For example, suppose that you construct an entity name such as "X-Y-Z",
in which you add a hyphen between variables X, Y, and Z from the database. In this case, be sure you return the
empty string "" if X, Y, and Z are all null or empty and not " - - ".

The Sort columns

The two columns Sort Path and Sort Order do not, strictly speaking, involve variable replacement in the entity name
Gosu code. Rather, you use them to define how to sort beans of the same entity.

Sort Path Defines the values that PolicyCenter uses in a sort

Sort Order Defines the order in which PolicyCenter sorts the Sort Path values

Therefore, if PolicyCenter is in the process of determining how to order two contacts, it first compares the values in
the (Sort Path) LastNameDenorm fields (Sort Order = 1). If these values are equal, Studio then compares the values in
the FirstNameDenorm fields (Sort Order = 2), repeating this process for as long as there are fields to compare.
These columns specify the default sort order. Other aspects of Guidewire PolicyCenter can override this sort order,
for example, the sort order property of a list view cell widget.

Gosu text editor

You enter the actual Gosu code used to construct the entity name in the code definition pane underneath the variable
table. Studio then replaces the variable with mapped property.
The following Gosu definition code for the Contact entity name shows these mappings.
if (SubType != null && [Link]([Link]("entity." + SubType))) {
var person = new PersonNameFieldsImpl(){
:LastName = LastName,
:FirstName = FirstName,
:Suffix = Suffix,
:Prefix = Prefix,
:MiddleName = MiddleName,
:Name = Name
}
return new NameFormatter().format(person, " ", NameOwnerFieldId.DISPLAY_NAME_FIELDS)
} else {
var contact = new ContactNameFieldsImpl(){
:Name = Name
}
return new NameFormatter().format(contact, " ")
}

To use the Contact entity name definition, you can embed the following in a PCF page, for example.
<Cell id="Name" value="[Link]" ... />

Using the entity names editor 149

Guidewire PolicyCenter 9.0.9 Configuration Guide

Do not use virtual entity methods to define display names. Doing so may result in slow performance. Also, if the
entity for which the display name is being generated is retired, calls to virtual methods may behave unpredictably.

Including data from subentities

Many times, you want to include information from subentities of the current entity in its Entity Name. For example,
this happens often with Contacts related to the current entity. Guidewire recommends that you do one of the
following to include data from a subentity. (The two options are mutually exclusive. You must do one or the other.)

Option 1: Use the DisplayName for a subentity

To use the DisplayName value for a subentity, you must set the value of Use Entity Name to true on the variable
definition. For example, for Contacts, you must set the value to true through an explicit Denorm column, such as
[Link].
To illustrate:

Name Entity Path Use Entity Name?

claimantDisplayName [Link] true

incidentDisplayName [Link] true

Option 2: Reference fields on the subentity

It is possible that you do not want to use the Entity Name as defined for the subentity's type. If so, then you need to
set up variables in the table to obtain the fields from the subentity that you need. To illustrate:

Name Entity Path Use Entity Name?

claimantFirstName [Link] false

claimantLastName [Link] false

severity [Link] false

incidentDesc [Link] false

You can then use these variables in Gosu code (in the text editor) to include the Claimant and Incident information
in the entity name for Exposure.

Guidewire recommendations
Do not end an Entity Path value with an entity foreign key, without setting the Use Entity Name value to true.
Otherwise, PolicyCenter loads the entire entity being referenced into memory. In actuality, you probably only need a
couple fields from the entity to construct your entity name. Instead, you one of the approaches described in one of
the previous steps.

Denormalized columns
Within the PolicyCenter data model, it is possible for a column to end in Denorm for (at least) two different reasons:
• The column contains a direct foreign key to a particular Contact (for example, as in [Link].)
• The original column is of type String and the column attribute supportsLinguisticSearch is set to true. In
this case, the denormalized column contains a normalized version of the string for searching, sorting, and
indexing. Thus, the Contact entity definition uses LastNameDenorm and FirstNameDenorm as the sort columns
in the definition for the Contact entity name. It then uses LastName and FirstName in the variables' entity paths
for eventual inclusion in the entity name string.
150 chapter 11: Using the entity names editor
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Entity name types

An entity name definition is called the entity name type. Thus, most—but not all—entity names have a single type.
However, it is possible for certain entities in the base application to have multiple, alternate names (types) and thus,
multiple entity name definitions. Again, these can be either simple text strings, or more complicated Gosu
expressions.
Studio displays each entity name type as a separate tab or code definition area at the bottom of the screen. You
cannot add or delete an entity name type to the base application. You can, however, change the Gosu definition of an
entity name type. Guidewire recommends, however, that you not modify an entity name type definition without a
great deal of thought.
Most entity names have only the single type named Default. You can access the Default entity name from Gosu code
by using the following code:
[Link]

Only internal application code (internal code that Guidewire uses to build the application) can access any of non-
default entity name types. For example, some of the entity names contain an additional type or definition of
ContactRoleMessage. PolicyCenter uses the ContactRoleMessage type to define the format of the entity name to
use in role validation error messages. In some cases, this definition is merely the same as the default definition.
Note: It is not possible for you to either add or delete an entity name type from the base application
configuration. You can, however, modify the definition—the Gosu code—for all defined types. You
can directly access only the default type from Gosu code.

Using the entity names editor 151

Guidewire PolicyCenter 9.0.9 Configuration Guide

152 chapter 11: Using the entity names editor

chapter 12

Using the messaging editor

This topic covers how you use the messaging editor in Guidewire Studio.

Messaging editor
You use the Messaging editor to set up and define one or more message environments, each of which includes one or
more message destinations. A message destination is an abstraction that represents an external system. Typically, a
destination represents a distinct remote system. However, you can also use destinations to represent different remote
APIs or different types of messages that must be sent from PolicyCenter business rules.
You use the Messaging editor to set up and define message destinations, including the destination ID, name, and the
transport plugin to use with this destination. In a similar fashion to the Plugins editor, you can also set the
deployment environment in which this message destination is active.
Each destination can specify a list of events that are of interest to it, along with some basic configuration
information.

See also
• Integration Guide

Open the messaging editor

Procedure
1. In the Studio Project pane, go to configuration→config→Messaging.
2. Open the [Link] file.

Add or remove a messaging configuration

You can define multiple messaging configurations to suit different purposes. For example, you can set up different
messaging configurations for the following:
• A development environment
• A test environment
• A production environment
Guidewire provides a single default messaging configuration in the PolicyCenter base configuration. You see it
listed as Default in the Messaging Config drop-down list.
Using the messaging editor 153
Guidewire PolicyCenter 9.0.9 Configuration Guide

Create a new messaging configuration

Procedure
1. Next to the Messaging Config drop-down list, click Add Messaging .
2. In the New Messaging dialog box, type the name for the new message configuration.
3. Add message destinations as required.

Remove a messaging configuration

About this task
If there is more than one messaging configuration, than you can remove one. There must be at least one messaging
configuration.
Note: Be careful not to inadvertently click the Remove Messaging button, as PolicyCenter deletes the
message configuration without any additional warning. You cannot undo this action.

Procedure
1. In the Messaging Config drop-down list, click the messaging configuration to remove.
2. Click Remove Messaging .
PolicyCenter deletes the messaging environment without asking for confirmation.

Add a message destination

Procedure
1. Open the Messaging editor.
2. Select a message environment
3. Click Add Destination .
4. Fill in the required fields. Notice that Studio requires that you enter a plugin name in the Transport Plugin field.

IMPORTANT If you register a messaging plugin, you must register it in two places. First,
register it in the plugin registry in the plugin editor; see “Using the plugins registry editor” on
page 133. Remember the plugin name that you use. You need it to configure the messaging
destination in the Messaging editor in Studio for each destination. Use those plugin names in the
messaging editor.

5. After you click Add Destination in the Messaging editor, fill in the following fields.

ID The destination ID (as an integer value). The valid range for custom destination IDs is 0 through 63, inclusive.
Guidewire reserves all other destination IDs for built‐in destinations such as the email transport destination.
Studio marks these internal values with a gray background, indicating that they are not editable. Studio also
marks valid entries with a white background and invalid entries with a red background.
Name Required. The name to use for this messaging destination.
Trans- Required. The name of the MessageTransport plugin implementation that knows how to send messages for
port Plu- this messaging destination. A destination must define a message transport plugin that sends a Message object
gin over a physical or abstract transport. For example, the plugin might do one of the following.
• Submit the message to a message queue.
• Call a remote web service API and get an immediate response that the system handled the message.
• Implement a proprietary protocol that is specific to a remote system.
Each messaging destination must specify its own unique implementation of a MessageTransport plugin. A
particular MessageTransport plugin cannot be assigned to multiple destinations.

154 chapter 12: Using the messaging editor

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Next steps
If the Disabled check box is selected, the messaging destination is disabled.

See also
• Integration Guide

Associating event names with a message destination

To define one or more specific events for which you want this message destination to listen, click Add Event under
Events. Each event triggers the Event Fired rule set for that destination. Use the special event name wildcard string
"(\w)*" to listen for all events.
To get notifications using Event Fired rules when specific types of data changes occur, you must specify one or more
messaging destinations to listen for that event. If no messaging destination listens for an event, PolicyCenter does
not call the Event Fired rules for that combination of event and destination.
If more than one destination listens for that event, the Event Fired rules run multiple times, varying only in the
destination ID. To get the destination ID in your Event Fired rules, check the property [Link].

Using the messaging editor 155

Guidewire PolicyCenter 9.0.9 Configuration Guide

156 chapter 12: Using the messaging editor

chapter 13

Using the display keys editor

This topic discusses how to work with the display key editor that is available to you in Guidewire Studio.

Overview of display keys

A display key represents a single user-viewable text string. Guidewire strongly recommends that any string literal
that can potentially be seen by a user be defined as a display key rather than as a hard-coded String literal.
PolicyCenter stores display keys in a display key properties file. In Guidewire Studio, this file is located under
configuration→config→Localizations. The file is named display_languageCode.properties, where languageCode is
the language code for the strings defined in the file. For example, the display key properties file for United States
English is display_en_US.properties.
If you do localize one or more display keys, then PolicyCenter uses additional
display_languageCode.properties files, one for each language that you install. For more information, see the
Globalization Guide.
PolicyCenter represents display keys within a hierarchical name space. Within the display key properties file, this
translates into a dot (.) separating the levels of the hierarchy.
By opening the display key properties file in Studio, you can do the following:

Task Actions
View a display key Navigate to the display key that you want to view by scrolling through the display key proper‐
ties file. To search for a particular key or value, press Ctrl+F and then type your search term
in the search bar.
Modify the text of an existing Navigate to the display key that you want to modify, and then modify the string in the editor
display key as you want.
Create a new display key In the display key editor, type the desired name and value for your new display key.
Delete an existing display key Highlight the display key that you want to delete, and then press Delete.

Display key requirements

A display key name cannot contain spaces, and it must be defined on a single line.
A display key value can contain any string that the [Link] method accepts. Escape the
characters { (curly brace) and \ (backslash) with a backslash (for example, \{ and \\). You can also use codes such
as \n for a newline, or \u for Unicode characters (for example, \u00A0 for a non-breaking space).
Using the display keys editor 157
Guidewire PolicyCenter 9.0.9 Configuration Guide

Creating display keys in a Gosu editor

About this task
You can create a display key directly from within a Gosu editor by first typing a string literal and then converting it
to a display key.

Procedure
1. Place the cursor within the string, and then press Alt+Enter.
2. Click Convert string literal to display key. Studio opens the Create Display Key dialog.
3. In the Name text box, type the name of the display key. Studio fills in this text box with the string value, but
you can change it.
4. In the Values box, under the desired locale name, verify or change the string value.
5. Click OK. Studio creates the new display key in the display key properties file. Studio also inserts a reference
to that display key in place of the string literal in the Gosu code.

Example
For example, suppose that you enter the following in the Rules editor:
var errorString = "Failed to send"

If you place the cursor within that string, then press Alt+Enter, and then click Convert string literal to display key,
Studio opens the Create Display Key dialog.
If you name the new display key SendFailed, then Studio creates the following new display key in the display key
properties file:
SendFailed=Failed to send

Studio also replaces the string literal in your Gosu code, and changes it to the following:
var errorString = [Link]("SendFailed")

Retrieving the value of a display key

Some display keys contain a placeholder argument or parameter, designated by {}. PolicyCenter replaces each of
these parameters with actual values at run time. For example, in the display key properties file, you see the
following:
[Link] = You do not have permission to perform actions on the
following activities\: {0}.

Thus, at run time, PolicyCenter replaces {0} with the appropriate value, in this case, the name of an activity.
Occasionally, there are display keys that contain multiple arguments. For example:
[Link] = The group {0} cannot be added for the user {1}
as they do not belong to the same organization.

Method [Link]
Use the [Link] method to return the value of the display key. Use the following syntax:
[Link](display_key_name)

For example:
[Link]("[Link]")

returns:
158 chapter 13: Using the display keys editor
 Guidewire PolicyCenter 9.0.9 Configuration Guide

User has duplicate roles

This also works with display keys that require a parameter or parameters. To retrieve the parameter value, use the
following syntax.
[Link](display_key_name, arg1)

For example, the display key properties file defines the following display key with placeholder {0}:
[Link] = Cannot delete user because they are supervisor of the
following groups\: {0}.

Suppose that you have the following display key Gosu code:
[Link]("[Link]", GroupName)

If the variable GroupName is defined as WesternRegion, this display key returns the following:
Cannot delete user because they are supervisor of the following groups: WesternRegion

The same syntax works with multiple arguments, as well:

[Link](display_key_name, arg1, arg2, ...)

Note: Make sure to include the following line in any Gosu code that calls the [Link]
method:
uses [Link]

Using the display keys editor 159

Guidewire PolicyCenter 9.0.9 Configuration Guide

160 chapter 13: Using the display keys editor

Part 4

Data model configuration

Guidewire PolicyCenter 9.0.9 Configuration Guide
chapter 14

Working with the Data Dictionary

Guidewire provides the Data Dictionary to help you understand the PolicyCenter data model. The Data Dictionary
is a detailed set of linked documentation in HTML format. These linked HTML pages contain information on all the
data entities and typelists that make up the current data model.

Related concepts

“What is the Data Dictionary?” on page 163

“What can you view in the Data Dictionary?” on page 164
“Using the Data Dictionary” on page 165

What is the Data Dictionary?

The PolicyCenter Data Dictionary documents all the entities and typelists in your PolicyCenter installation.
Provided that you regenerate it following any customizations to the data model, the dictionary documents both the
base PolicyCenter data model and your extensions to it. Using the Data Dictionary, you can view information about
each entity, such as fields and attributes on it.
You must manually generate the Data Dictionary after you install Guidewire PolicyCenter. Guidewire strongly
recommends that you perform this task as part of the installation process. Also, as you extend the data model, it is
important that you regenerate the Data Dictionary as needed in order to view your extensions to the data model.
To generate the PolicyCenter Data Dictionary, run the following command from the PolicyCenter directory:
gwb genDataDictionary

PolicyCenter stores the current version of the Data Dictionary in the following directory:
PolicyCenter/build/dictionary/data/

To view the Data Dictionary, open the following file:

PolicyCenter/build/dictionary/data/[Link]

As an option, you can generate the Data Dictionary in XML format with associated XSD files. Use the generated
XML and XSD files to import the Data Dictionary into third-party database design tools.

Related concepts

“Regenerating the data and security dictionaries” on page 39

Working with the Data Dictionary 163
Guidewire PolicyCenter 9.0.9 Configuration Guide

What can you view in the Data Dictionary?

Note: If you use a third-party tool to edit PolicyCenter configuration files, Guidewire recommends
that you work with one that fully supports UTF-8 file encoding. If the editing tool does not handle
UTF-8 characters correctly, it can create errors that you then see in the Guidewire Data Dictionary.
This is not an issue with the Data Dictionary. It occurs only if the third-party tool cannot handle
UTF-8 values correctly.
After you open the Data Dictionary (at PolicyCenter/build/dictionary/data/[Link]), Guidewire presents
you with multiple choices. You can choose to view either Data Entities, Data Entities (Database View), Data Entities
(Migration View), or Typelists.
The standard, database, and migration views of data entities are similar but not identical. You use each for a different
purpose. In general:
• Use the standard view to view a full set of entities associated with the PolicyCenter application and the columns,
typekeys, arrays, and foreign keys associated with each entity. See “Using the Data Dictionary” on page 165.
• Use the database view to view all persistent, non-virtual entities associated with the PolicyCenter application and
the persistent columns, typekeys, arrays, and foreign keys associated with each persistent entity. See “Using the
Data Dictionary” on page 165.
• Use the migration view to assist you in converting data from a legacy application. This view provides a subset of
the information in the standard view of the application entities that is more useful for those working on the
conversion of legacy data.
• Use the typelists view to view all typelists associated with the PolicyCenter application and the typecodes
associated with each typelist. See “Using the Data Dictionary” on page 165.

The migration view of the Data Dictionary

The standard Data Dictionary view separates out entity subtypes from the main entity supertype. In brief, a
supertype relates to a subtype in a parent-child relationship. For example, if a Contact data entity is the supertype,
then Person and Company are examples of its subtypes. Thus, an entity subtype inherits the characteristics of its
supertype and adds individual variations particular to it.
This separation into supertype and subtype is not particularly useful for data conversion (the process of importing
data into PolicyCenter from an external legacy application). Therefore, the migration view of the Data Dictionary
differs from the standard view in the following respects:
• The migration view displays subtype fields interspersed with supertype fields. For example:
◦ fieldA
◦ fieldB (only for subtype XYX)
◦ fieldC (only for subtype DFG)
◦ fieldD
• The migration view does not show virtual fields or virtual arrays.
• The migration view does not show non-loadable columns. For example, it does not show createUserID or
createTime.
• The migration view omits any non-persistent entities.
• The migration view omits entities that are persistent but non-loadable. For example, Group is not loadable.
Therefore, the migration view does not display it.

Related concepts
“Using the Data Dictionary” on page 165

164 chapter 14: Working with the Data Dictionary

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Using the Data Dictionary

You use the Data Dictionary to do the following:
• To determine what a field means that you see in a data view definition.
• To see what fields are available to add to a view, or to use in rules, or to export in an integration template, and
more.
• To view the list of options for an associated typekey field.
You navigate the dictionary like a web site, with links leading you to associated pages. You can use the Back and
Forward controls of your browser to take you to previously visited pages. Within the Data Dictionary, you have the
option to navigate to three Data Entities views or the Typelists view.
If you click on one of the Data Entities views, PolicyCenter displays a left-side pane listing entities in PolicyCenter.
Then, on the right-side, PolicyCenter displays a pane that shows the details of the selected item in the left-side pane.
If you click on the Typelists view, PolicyCenter displays a left-side pane listing all of the typelists in PolicyCenter.
Then, on the right-side, PolicyCenter displays a pane that shows the typecodes for the selected typelist in the left-
side pane.
Within the details of an object, you can follow links to related objects or view the allowed values for a typelist.

Related concepts

“Property colors” on page 165

“Object attributes” on page 166
“Entity subtypes” on page 167
“Data field types” on page 167
“Virtual properties on data entities” on page 168
“What is a typelist?” on page 303
“What can you view in the Data Dictionary?” on page 164

Property colors
An examination of the Data Dictionary shows properties in green, blue, and red. These colors have the following
meanings:

Color Meaning
Green The object property is part of the Guidewire base configuration. The object definition file exists in Studio in the follow‐
ing locations:
• config→configuration→Metadata
• config→configuration→Extensions
Blue The object property is defined in an extension file, either by Guidewire or as a user customization. The object defini‐
tion file exists in Studio in the following location:
• config→configuration→Extensions
It is possible for Guidewire to define a base object in the Metadata folder and then to extend the object using an exten‐
sion entity in the Extensions folder.
Red Occasionally, it is possible to see a message in red in the Data Dictionary that states:
This entity is overwritten by the application during staging.
This message indicates that Guidewire PolicyCenter auto‐populates a table or column's staging table equivalent. Do
not attempt to populate the table yourself as the loader import process overwrites the staging table during import.
See also the description of the overwrittenInStagingTable attribute in “<entity> elements and related data object
types” on page 183.

Working with the Data Dictionary 165

Guidewire PolicyCenter 9.0.9 Configuration Guide

Object attributes
An object in the PolicyCenter data model can have a number of special attributes assigned to it. These attributes
describe the object (or entity) further. You use the Data Dictionary to see what these are. For example, the Policy
entity has the attributes Editable, Exportable, Extendable, Final, Keyed, Loadable, Sourceable, and Versionable.
The following list describes the possible attributes:

Attribute Description
Abstract The entity is a supertype. However, all instances of it must be one of its subtypes. That is, you cannot instantiate
the supertype entity itself. An abstract entity is appropriate if the supertype serves only to collect logic or common
fields. The abstract entity is appropriate because, in this case, it is not expedient for the supertype to exist on its
own.
Editable The related database table contains rows that you can edit. An Editable table manages additional fields that track
the immediate status of an entity in the table. For example, the table tracks who created the entity, the creation
time, who last modified the entity, and the modification time.
Exportable Unused.
Extendable It is possible to extend the entity with additional custom fields added to it.

Final It is not possible to subtype this entity. However, you can extend the entity by adding fields to it.
Keyed The entity has a related database table that has a primary key. Each row in a Keyed table has an integer primary
key named ID. PolicyCenter manages these IDs internally, and the application ensures that no two rows in a keyed
table have the same ID. You can also associate an external unique identifier with each row in a table.
Loadable It is possible to load the entity through the use of staging tables.
Sourceable The entity links to an external source. Each row in a table for a Sourceable entity has additional fields to identify
the external application and to store the ID of the Sourceable entity in the external application.
Supertype The entity has a single table that represents multiple types of entities called subtypes. Each subtype shares appli‐
cation logic and a majority of its fields. Each subtype can also define fields that are particular to it.
Temporary The entity is a temporary entity created as part of an upgrade or staging table loading. PolicyCenter deletes the
entity after the operation is complete.
Versionable The entity has a version number that increases every time the entity changes. The PolicyCenter cache uses the
version number to determine if updates have been made to an entity.

To view the definition of a particular attribute, click the small question mark (?) by the attribute name in the attribute
list in the Guidewire Data Dictionary.

Property attributes
A property in the PolicyCenter data model can have a number of special attributes assigned to it. These attributes
describe the property further. You use the Data Dictionary to see what these are. For example, the Policy entity has
a property named Account. The attributes of this property are exportable, non-null, and writable.
The following list describes the possible attributes:

Attribute Description
database column: [name] The corresponding database column for the property has a name of [name]. This attribute is
present if [name] is a name other than the name of the property.
default: [value] This attribute is often present for a property that is associated with a column or a typekey. When
the attribute is present, [value] represents the default value for the property.
exportable Unused.
export as id Unused.

166 chapter 14: Working with the Data Dictionary

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Attribute Description
loadable The property is loadable by way of the staging tables.
localized The property contains a <localization> subelement. This subelement causes a localization
table to be created during the next database upgrade. A localization table stores localized values
for a column for every language other than the default application language. See Globalization
Guide.
non-null The property cannot contain null values.
overwritten on load The property contains an overwrittenInStagingTable attribute with a value of true.
PolicyCenter uses the property and a corresponding staging table during the load of staging table
data to operational tables. When the overwrittenInStagingTable attribute has a value of true,
the loader import process overwrites the staging table corresponding the property. See “Staging
tables” on page 178 for more information.
triggers validation The property contains a triggersValidation attribute with a value of true. When this scenario
exists and an array, a foreign key, or a one‐to‐one entity on the property changes, PolicyCenter
initiates validation on the property. See “<array>” on page 199, “<foreignkey>” on page 211,
and “<onetoone>” on page 217 for more information about the effects of the
triggersValidation attribute when arrays, foreign keys, and one‐to‐one entities change.

unique index The property participates in one or more unique indexes.

virtual property PolicyCenter creates no physical database column for the property.
writable The user can write the property with Gosu or the IDataObjectAPI interface.

To view the definition of a particular attribute, click the small question mark (?) by the attribute name in the attribute
list in the Guidewire Data Dictionary.

Property tags
A property in the PolicyCenter data model can have a number of tags assigned to it. These tags further describe the
property.
You use the Data Dictionary to see what these tags are. For example, the Data Dictionary indicates whether the
PersonalData obfuscation tag is set on the various fields that use the tag as well as the tag value. One such value
for the PersonalData tag is ObfuscateDefault.

Entity subtypes
If you look at Contact in the Guidewire Data Dictionary, for example, you see that data dictionary lists a number of
subtypes. For certain PolicyCenter objects, you can think of the object in several different ways:
• As a generic object. That is, all contacts are similar in many ways.
• As a specific version or subtype of that object. For example, you would want to capture and display different
information about companies than about people.
PolicyCenter creates Contact object subtypes by having a base set of shared fields common to all contacts and then
extra fields that exist only for the subtype.
PolicyCenter also looks at the subtype as it decides which fields to show in the PolicyCenter interface. You can
check which subtype a contact is by looking at its subtype field (for example, in a Gosu rule or class).

Data field types

You can use the Data Dictionary to view the type of each object field. The following list describes some of the
possible field types on an object:
Working with the Data Dictionary 167
Guidewire PolicyCenter 9.0.9 Configuration Guide

Type Description
array Represents a one‐to‐many relationship. For example, consider the relationship between a contact and a set of
addresses. There is no actual column in the database table that maps to the array. PolicyCenter stores this infor‐
mation in the metadata.
column As the name specifies, it indicates a column in the database. Inside a column field, you can add tag subtypes to
point out additional information about the field. The Data Dictionary displays such tags and their values.
foreign key References a keyable entity. For example, Policy has a foreign key (AccountID) to the related account on the
policy, found in the Account entity.
typekey Represents a discrete value picked from a particular list, called a typelist.
virtual prop- Indicates a derived property. PolicyCenter does not store virtual properties in the PolicyCenter physical database.
erty

Note: Inside any field of the data model aside from virtual properties, you can add tags and optional
corresponding values to point out additional information about the field. The Data Dictionary displays
such tags and values.

Virtual properties on data entities

The Data Dictionary lists certain entity properties as virtual. PolicyCenter does not store virtual properties in the
PolicyCenter physical database. Instead, it derives a virtual property through a method, a concatenation of other
fields, or from a pointer (foreign key) to a field that resides elsewhere.
For example, if you view the Account entity in the Data Dictionary (for PolicyCenter), you see the following next
to the AccountContactRoleSubtypes field:
Derived property returning [Link] (virtual property)

Examples
The following examples illustrate some of the various ways that Guidewire applications determine a virtual
property. The following examples use Guidewire ClaimCenter for illustration.
Virtual property based on a foreign key
[Link] is a virtual property that pulls its value from the cc_claimtext table, which
stores [Link] = BenefitsDecisionReason. It returns a mediumtext value. The other
fields in cc_claimtext and cc_exposuretext work in a similar fashion.
Virtual property based on an associated role
[Link] is a virtual property that retrieves the Contact associated with the Claim having the
ClaimContactRole of claimant. The virtual property returns a Person value.
Virtual property based on a typelist
[Link] is a virtual property that calculates its return value based on the value from
[Link]. It retrieves the telephone number stored in the field represented by that typekey. The
telephone number can be one of the following:
• [Link]
• [Link]
• [Link]
The virtual property returns a phone value.

168 chapter 14: Working with the Data Dictionary

chapter 15

The PolicyCenter data model

The in PolicyCenter data model comprises the persistent data objects, called entities, that PolicyCenter manages in
the application database.

Related concepts

“What is the data model?” on page 169

“Overview of data entities” on page 171
“XML root elements and related base PolicyCenter data object types” on page 179

Related references

“Data entity subelements” on page 198

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 PolicyCenter data model 169
Guidewire PolicyCenter 9.0.9 Configuration Guide

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.
You can change the PolicyCenter data model to accommodate your business needs. 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
Always access and edit the data model files 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:
[Link]

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:
[Link]

170 chapter 15: The PolicyCenter data model

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Overview of data entities

Data entities are the high-level business objects used by PolicyCenter, such as a Policy, PolicyLine, or Coverage.
An entity serves as the root object for data views, rules, Gosu classes, and most other data-related areas of
PolicyCenter. Guidewire defines a set of data objects in the base PolicyCenter configuration from which it derives
all other objects and entities. For many of the Guidewire base entities, you can also create entity extensions that
enhance the base entities and provide additions required to support your particular business needs. In some cases,
you can even define entirely new entities.
If you plan to archive data entities in your PolicyCenter installation, you must define your data entities in such a way
as to facilitate the archiving process. An incorrect data entity definition can cause the archive operation to fail.

Related concepts
“The PolicyCenter archive domain graph” on page 325

Data entity metadata files

You define data entities through XML elements in the entity metadata definition files. The root element of an entity
definition specifies the kind of entity and any attributes that apply. Subelements of the entity element define entity
components, such as columns (or fields) and foreign keys.

WARNING Do not modify any of the base data entity definition files (those in the PolicyCenter/
modules/configuration/config/metadata directory) by editing them directly. You can view
these files in read-only mode in Guidewire Studio™ in the configuration →config→Metadata folder.

To better understand the syntax of entity metadata, it is sometimes helpful to look at the PolicyCenter data model
and its metadata definition files. PolicyCenter uses separate metadata definition files for entity declarations and
extensions to them.
The base metadata files are available in Studio in the following location: configuration→config→Metadata
The extension metadata files are available in Studio in the following location: configuration→config→Extensions
The file extensions of metadata definition files distinguish their type, purpose, and contents.

File type Pur‐ Contains More information

pose

.dti Data Type Info A single data type definition. “Data types” on page 283
.eti Entity Type In‐ A single Guidewire or custom entity declaration. The “XML root elements and related
formation name of the file corresponds to the name of the enti‐ base PolicyCenter data object
ty being declared. types” on page 179
.eix Entity Internal A single Guidewire entity extension. The name of the Internal defintion; see .etx
eXtension file corresponds to the name of the Guidewire entity
being extended.
.etx Entity Type eX‐ A single Guidewire or custom entity extension. The “<extension> elements and relat‐
tension name of the file corresponds to the name of the enti‐ ed data object types” on page 189
ty being extended. “<viewEntityExtension> elements
and related data object types” on
page 197
.tti Typelist Type In‐ A single Guidewire or custom typelist declaration. “Working with typelists” on
fo The name of the file corresponds to the name of the page 303
typelist being declared.
.tix Typelist Internal A single Guidewire typelist extension. The name of “Working with typelists” on
eXtension the file corresponds to the name of the Guidewire page 303
typelist being extended.

The PolicyCenter data model 171

Guidewire PolicyCenter 9.0.9 Configuration Guide

File type Pur‐ Contains More information

pose

.ttx Typelist Type eX‐ A single Guidewire or custom typelist extension. The “Working with typelists” on
tension name of the file corresponds to the name of the page 303
typelist being extended.

The type of a metadata definition file determines what you can store and whether you can modify its contents.

File type Location Files are modifia‐

ble
.dti configuration→config→datatypes No
.eti configuration→config→Extensions→Entity Yes
configuration→config→Metadata→Entity No
.eix configuration→config→Metadata→Entity No
.etx configuration→config→Extensions→Entity Yes
.tti configuration→config→Extensions→Typelist Yes
configuration→config→Metadata→Typelist No
.tix configuration→config→Metadata→Typelist No
.ttx configuration→config→Extensions→Typelist Yes

The Metadata folder

The Studio Metadata folder contains the metadata definition files for entities that comprise the PolicyCenter data
model.
A Metadata folder contains the following metadata definition file types:
• Declaration files – Versions of metadata definition files with extensions *.eti and *.tti.
• Internal extension files – Versions of metadata definition files with extensions *.eix or *.tix.
For an example, the PolicyCenter data model includes the following metadata definition files that collectively define
the Address entity type.

File version Metadata location File purpose

[Link] configuration→config→Metadata→Entity Entity definition

[Link] configuration→config→Metadata→Entity Extension to the entity definition

At runtime, PolicyCenter merges the .eti and .eix versions of the Address definition file to create a complete
Address entity type.

The Extensions folder

The configuration→config→Extensions folder contains your data model definitions that extend the PolicyCenter data
model. PolicyCenter considers the base definitions in configuration→config→Metadata first, and then applies the
definitions in the Extensions folder to them. This lets you create an entity extension that overrides any Guidewire
entity extensions.

172 chapter 15: The PolicyCenter data model

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Example of Activity metadata and extension files

The PolicyCenter data model includes the following metadata definition files that collectively define the
PolicyCenter Activity entity.

File Location Purpose

[Link] configuration→config→Metadata→Entity Entity definition, not modifiable.

[Link] configuration→config→Metadata→Entity Entity extension, not modifiable.

To extend the PolicyCenter Activity entity, create the following extension file through Guidewire Studio.

File Location Purpose

[Link] configuration→config→Extensions→Entity Custom entity extension.

WARNING Use only Guidewire Studio to create data model definition files. Use of Studio assures
that the files reside in the correct location.

The extensions properties file

In general, if you change the data model, PolicyCenter automatically upgrades the database the next time that you
start the application server. It detects changes to files in that directory by recording a checksum each time the
application server starts. If the recorded checksum and the current checksum differ, PolicyCenter upgrades the
database.
Sometimes you want to force PolicyCenter to upgrade the database without making changes to your custom data
model extensions. The configuration→config→Extensions folder in Guidewire Studio™ contains an
[Link] file that contains the numeric property version. The value of the version property
represents the current version of the data model definition for your instance of PolicyCenter. It controls whether
PolicyCenter performs a database upgrade on server startup.
Whenever PolicyCenter upgrades the database, PolicyCenter stores the value of the version property in the
database. The next time the application server starts up, PolicyCenter compares the value of the property in the
database to the value in the [Link] file. If the value in the database is lower than the value in the
file, PolicyCenter performs a database upgrade. If the value in the database is higher, the upgrade fails.

WARNING If the server is operating in either production or test mode, Guidewire strictly requires
that you increment the version number whenever you make changes to the data model before you
restart the application server. Otherwise, unpredictable results can occur. Use of the
[Link] file in a development environment is optional. However, as a general
best practice, Guidewire recommends that you always increment the version number in
[Link] after you make changes to the product model.

Working with entity definitions

In working with entity definitions, you typically want to perform the following operations:
• Search for an existing entity definition
• Create a new entity definition
• Extend an existing entity definition
This section describes procedures for each operation.

The PolicyCenter data model 173

Guidewire PolicyCenter 9.0.9 Configuration Guide

Note: Guidewire strongly recommends that you verify your entity definitions at the time that you
create them. To do so, right-click the entity in the Project window, and then click Validate. The
verification process highlights any issues with a data model definition, enabling you to correct any
issues.

Search for an existing entity definition

Procedure
1. In Guidewire Studio, press Ctrl+N.
2. In the Enter class name dialog, start typing the name of the entity that you want to find.
Studio displays a list of matching entries that begin with the character string that you type.
3. In the list, click the name of the entity definition that you want to view.
Pay attention to the class type. For example, if you type Activity, Studio displays a list that includes all
components whose name contains that text. Look for the one that ends with .eti.

Result
Studio opens the file in the appropriate editor.

Create a new entity definition

Procedure
1. In Guidewire Studio, in the Project tool window, navigate to configuration→config→Extensions→Entity.
2. Right-click Entity, and then click New→Entity.
3. In the Entity text box, type the name of the new entity definition that you want to create. Set the other
properties for the entity.
4. Click OK.

Result
Studio displays the name of your new file in the Extensions→entity folder in Studio, and it stores the new file in the
file system at the following location.
configuration/config/extensions/entity

Then Studio opens your new file in the appropriate editor.

Extend an existing entity definition

About this task
You can extend only entity definition files that have the .eti extension.

Procedure
1. In Guidewire Studio, in the Project tool window, navigate to configuration→config→Metadata, and then expand
Entity.
2. Right-click the entity that you want to extend, and then click New→Entity Extension.
The file that you want to extend must have the .eti extension.
3. In the Entity Extension dialog, Studio displays the name and location of the extension file it will create. Click
OK.
174 chapter 15: The PolicyCenter data model
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Result

Studio displays the name of your new file in the Extensions→Entity folder and stores the new file at the following
location:
configuration/config/extensions/entity

Studio then opens your new file in the appropriate editor.

PolicyCenter data entities

PolicyCenter uses XML metadata files to define all data entities in the data model. The [Link] file defines
the elements and attributes that you can include in the XML metadata files. You can view a read-only version of this
file in the configuration→xsd→metadata folder in Studio.

WARNING Do not attempt to modify [Link]. You can invalidate your PolicyCenter
installation and prevent it from starting thereafter.

File [Link] defines the following:

• The set of allowable or valid data entities
• The attributes associated with each data entity
• The allowable subelements on each data entity
All PolicyCenter entity definition files must correspond to the definitions in [Link].
Using XML files, Guidewire defines a data entity as a root element in an XML file that bears the name of the entity.
For example, Guidewire declares the Activity entity type with the following [Link] file:
<?xml version="1.0"?>
<entity xmlns="[Link]
desc="An activity is a instance of work assigned to a user and belonging to a claim."
entity="Activity"
exportable="true"
extendable="true"
platform="true"
table="activity"
type="retireable">
...
</entity>

At application server start up, PolicyCenter loads the XML definitions of the data entities into the application
database.

Data entities and the application database

PolicyCenter defines each data entity as a root XML element in the file that bears its name. For example,
PolicyCenter defines the Activity data entity in [Link]:
<entity xmlns="[Link]
entity="Activity"
...
type="retireable">
...
</entity>

Notice that for the base configuration Activity object, PolicyCenter sets the type attribute to retireable. The
type attribute that determines how PolicyCenter manages the data entity in the PolicyCenter database. For example:
• If a data entity has a type value of versionable, PolicyCenter stores instances of the entity in the database with
a specific ID and version number.
• If a data entity has a type value of retireable, PolicyCenter stores instances of the entity in the database
forever. However, you can retire, or hide, specific instances so that PolicyCenter does not display them in the
interface.
The PolicyCenter data model 175
Guidewire PolicyCenter 9.0.9 Configuration Guide

IMPORTANT For each data entity in the PolicyCenter data model and for each entity type that you
declare, PolicyCenter automatically generates a field named ID that is of data type key. An ID field is
the internally managed primary key for the object. Do not attempt to create entity fields of type key.
The key type is for Guidewire internal use only. Guidewire also reserves the exclusive use of the
following additional data types: foreignkey, typekey, and typelistkey.

The following table lists the possible values for the entity type attribute. Use only those type attributes marked for
general use to create or extend an data entity. Do not attempt to create or extend an entity with a type attribute
marked for internal-use.

Type attribute Usage Description

editable General An editable entity is a versionable entity. PolicyCenter automatically stores the version
use number of an editable entity. In addition to the standard versionable attributes of ver‐
sion and ID, an editable entity has the following additional attributes:
• CreateUser and CreateTime
• UpdateUser and UpdateTime
effdated General An effdated entity is an editable entity. effdated entities have effective date fields,
use meaning start and end dates, used within Guidewire PolicyCenter. An effdated entity is a
member of an effective dated graph, rooted at an effdatedbranch entity. PolicyCenter
auto‐splits the date fields during editing in some modes.
effdatedbranch Internal An effdated branch entity is a retireable entity. effdatedbranch entities define the enti‐
use ty type of the root of a tree that contains effdated entities.
Guidewire recommends not to attempt to create an entity with a type attribute of
effdatedbranch.

effdatedcontainer Internal An effdatedcontainer entity is a retireable entity. effdatedcontainer entities define

use only the entity type that has branch children. Guidewire recommends not to attempt to create an
entity with a type attribute of effdatedcontainer.
joinarray Internal A joinarray entity works in a similar manner as a versionable entity. Guidewire recom‐
use only mends not to use this entity type. Use versionable instead.
keyable Internal All entities are keyable entities, except for those entities with an explicit nonkeyable type.
use only Moreover, all entity types other than the nonkeyable entity type have the keyable entity
type as an ancestor.
A keyable entity has an ID. You can delete keyable entities from the database.
nonkeyable Internal Do not use.
use only
retireable General A retireable entity is an editable entity. retireable entities are the most common type
use of entity. Most, but not all, base entities are of this type.
After PolicyCenter adds an instance of a retireable data entity to the database,
PolicyCenter never deletes the instance. Instead, PolicyCenter retires the instance. For ex‐
ample, if you select a retireable instance in a list view and then click Delete, PolicyCenter
preserves the instance in the database. However, PolicyCenter inserts an integer in the
Retired column for the row that represents the instance. Any non‐zero value in the Retired
column indicates that PolicyCenter considers the instance retired.
PolicyCenter automatically creates the following fields for retireable entities:
• ID and PublicID
• CreateUser and CreateTime
• UpdateUser and UpdateTime
• Retired
• BeanVersion
These are the same fields as those PolicyCenter creates for editable entities, with the addi‐
tion of the Retired property.

176 chapter 15: The PolicyCenter data model

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Type attribute Usage Description

IMPORTANT Although it is extremely common for a base entity to be retireable, it is not
required. You cannot assume this to be the case. Always check the Data Dictionary to deter‐
mine whether an entity can be retired.
versionable General A versionable entity is a keyable entity. versionable entities have a version and an ID.
use Entities of this type can detect concurrent updates. It is possible to delete entities of this
type from the database.

PolicyCenter database tables

For every entity type in the data model, PolicyCenter creates a table in the application database. For example,
PolicyCenter creates a Policy table to store information about the Policy object.
In the application database, you can you identify an entity or extension table by the following prefix:

pc_ Entity table – one for each entity in the base configuration
pcx_ Extension table – one for each custom extension added to the extensions folder in Studio

Note: It is possible to create non-persistent entities. These are entities or objects that you cannot save
to the database. Guidewire discourages the use of non-persistent entities in favor of Plain Old Gosu
Objects (POGOs), instead. See “<nonPersistentEntity> elements and related data object types” on
page 191 for more information.
Besides entity tables, PolicyCenter creates the following types of tables in the database:

Table type More information

shadow tables “Shadow tables” on page 177
staging tables “Staging tables” on page 178
temporary tables “Temporary (temp) tables” on page 178

Shadow tables
A shadow table stores a copy of data from a main table for testing purposes. Every entity table potentially has a
corresponding shadow table. Shadow tables in the database have one of the following prefixes:

pct_ Entity shadow table

pctt_ Typelist shadow table

Shadow tables provide a way to quickly save and restore test data. All GUnit tests, including those that you write
yourself, use shadow tables automatically. You cannot prevent GUnit tests from using shadow tables. GUnit tests use
shadow tables according to the following process:
1. GUnit copies data from the main application tables to the shadow tables to create a backup of your test data.
2. GUnit runs your tests.
3. GUnit copies data backed up data in shadow tables to the main tables to restore a fresh copy of your test data
for subsequent tests.
To start a test server, set its [Link] system property to true either explicitly or programmatically.
In addition, set the server environment to one that uses your test database. Upon server startup, if shadow tables do
not already exist, PolicyCenter drops the database, recreates it, and then creates the shadow tables. PolicyCenter
creates shadow tables only in an empty database.

The PolicyCenter data model 177

Guidewire PolicyCenter 9.0.9 Configuration Guide

Staging tables
PolicyCenter generates a staging table for any entity that is marked with an attribute of loadable="true". The
loadable attribute is true by default in the base configuration. A staging table largely parallels the main entity table
except that:
• PolicyCenter replaces foreign keys by PublicID objects of type String.
• PolicyCenter replaces typecode fields by typekey objects of type String.
After you load data into these staging tables, you run the command line tool table_import to bulk load the staging
table data into the main application database tables. See the System Administration Guide for information on how to
use this command.

IMPORTANT Some data types, for example, Entity, contain an overwrittenInStagingTable

attribute. If this attribute is set to true, then do not attempt to populate the associated staging table
yourself because the loader import process overwrites this table.

In the application database, you can you identify a staging table by the following prefix pcst_.

Temporary (temp) tables

PolicyCenter generates a temporary table for any entity that is marked with an attribute of temporary="true". Do
not confuse a temporary table with a shadow table, they are not synonymous. PolicyCenter uses temporary tables as
work tables during installation or upgrade only. PolicyCenter does not use them if the server is running in standard
operation.
Unfortunately, it is easy to forget to clear up these tables if they are no longer needed. Therefore, it is quite possible
for an application to have several of these temporary tables remaining even though the upgrade triggers that used
them are long gone.
In the application database, temporary tables look like any other entity table except that temporary tables are almost
always empty.

Data objects and scriptability

Scriptability is the ability of code to set (write) or get (read) a scriptable item such as a property (column) on an
entity. To do so, you set the following attributes:
• getterScriptability
• setterScriptabiliy
The following table lists the different types of scriptability:

Type Description
all Exposed in Gosu, wherever Gosu is valid, for example, in rules and PCF files
doesNotExist Not exposed in Gosu

hidden Not exposed in Gosu

If you do not specify a scriptability annotation, then PolicyCenter defaults to a scriptability of all.

IMPORTANT There are subtle differences in how PolicyCenter treats entities and fields marked as
doesNotExist and hidden. However, these differences relate to internal PolicyCenter code. For your
purpose, these two annotations behave in an identical manner, meaning any entity or field that uses
one of these annotations does not show in Gosu code. In general, there is no need for you to use either
one of these annotations.

Scriptability behavior on entities

If you set setterScriptability at the entity level but you also set the value to hidden or doesNotExist, then
PolicyCenter does not generate constructors for the entity. In essence, you cannot create a new instance of the entity
178 chapter 15: The PolicyCenter data model
 Guidewire PolicyCenter 9.0.9 Configuration Guide

in Gosu. Within the PolicyCenter data model, you can set the following scriptability annotation on <entity>
objects:

Object Set (write) Get (read)

<entity> Yes No*
* <entity> does not contain a getterScriptability attribute.

Scriptability behavior on fields (columns)

If you set setterScriptability at the field level, then the value that you set controls the writability of the
associated property in Gosu. Within the PolicyCenter data model, you can set the following scriptability annotation
on fields on <entity> objects:

Field Set (write) Get (read)

<array> Yes Yes
<column> Yes Yes
<edgeForeignKey> Yes Yes
<foreignkey> Yes Yes
<onetoone> Yes Yes
<typekey> Yes Yes

XML root elements and related base PolicyCenter data object

types
The base PolicyCenter configuration recognizes a set of XML root elements. These elements match by name a set of
base data object types. All PolicyCenter objects exist as instances of one of the base data object types or as instances
of a subtype of a base object type. The following table lists the XML root elements for the base PolicyCenter data
object types:

XML root element Exten‐ Folder More information

sion
<delegate> .eti metadata, “<delegate> elements and related data object types” on page 180
extensions

<entity> .eti metadata, “<entity> elements and related data object types” on page 183
extensions

<extension> .etx extensions “<extension> elements and related data object types” on page 189
<nonPersistentEntity> .eti metadata, “<nonPersistentEntity> elements and related data object types” on
extensions page 191
<subtype> .eti metadata, “<subtype> elements and related data object types” on page 192
extensions

<viewEntity> .eti metadata “<viewEntity> elements and related data object types” on page 195
<viewEntityExtension> .etx extensions “<viewEntityExtension> elements and related data object types” on
page 197

The PolicyCenter data model 179

Guidewire PolicyCenter 9.0.9 Configuration Guide

IMPORTANT There are additional data objects that Guidewire uses for internal purposes. Do not
attempt to create or extend a data entity that is not listed in the previous table.

Related concepts
“<delegate> elements and related data object types” on page 180

Related references
“<entity> elements and related data object types” on page 183
“<extension> elements and related data object types” on page 189
“<nonPersistentEntity> elements and related data object types” on page 191
“<subtype> elements and related data object types” on page 192
“<viewEntity> elements and related data object types” on page 195
“<viewEntityExtension> elements and related data object types” on page 197

<delegate> elements and related data object types

The <delegate> XML root element defines delegate data object types. A delegate data object type is a collection of
properties and behaviors. Moreover, a delegate contains an interface and a default implementation of that interface.
A delegate can also add its own columns to the tables of data object types that implement the delegate. This type of
delegation enables a data object type to implement an interface while delegating the implementation to the delegate.
You often use a delegate so that objects can share code. The delegate implements the shared code rather than each
class implementing copies of common code. Thus, a delegate is an entity associated with an implemented interface
that multiple parent entities can reuse.
Guidewire defines delegates in data model metadata files. You can extend existing delegates that are marked as
extendible. You can also create your own custom delegates.
PolicyCenter stores all database columns on the delegate entity in the implementing entity.

Attributes of <delegate>
The <delegate> element contains the following attributes.

<delegate> attribute Description Default

extendable Internal. false

name Required. None

platform Internal. Do not use. The only real effect is to change the location in which the table false
appears in a data distribution report.
requiresType Specifies that the delegate must be implemented by an entity of a general type, such nonkeyable
as retireable or versionable.
Possible values for the requiresType attribute are the values of the type attribute on
the <entity> element. Some of the general types extend others. For example,
editable extends versionable, and versionable extends keyable. An entity can im‐
plement the delegate if the implementor is the specified type or one that extends it.
For example, if the requiresType attribute is keyable, then an implementing entity
could have type keyable, versionable, or editable.
setterScriptability See “Data objects and scriptability” on page 178 for information. None

Subelements of <delegate>
The <delegate> element contains the following subelements.
180 chapter 15: The PolicyCenter data model
 Guidewire PolicyCenter 9.0.9 Configuration Guide

<delegate> subelement Description

column See “<column>” on page 202.

datetimeordering Internal.
dbcheckbuilder Internal.
foreignkey See “<foreignkey>” on page 211.
fulldescription See “<fulldescription>” on page 214.
implementsEntity See “<implementsEntity>” on page 214.
implementsInterface See “<implementsInterface>” on page 215.
index See “<index>” on page 216.
monetaryamount Handles monetary amounts. The <monetaryamount> subelement is a compound data type that
stores its values in two separate database columns: a <money> column type and a typekey to the
Currency typelist.

typekey See “<typekey>” on page 220.

Implementing delegate data object types

To implement most delegate data object types, you add the following to an entity definition or extension.
<implementsEntity name="SomeDelegate"/>

For example, in the base configuration, the Group entity implements the Validatable delegate by using the
following:
<entity entity="Group" ... >
<implementsEntity name="Validatable"/>
...
</entity>

It is possible for an entity to implement multiple delegates, just as a Gosu or Java class can implement multiple
interfaces.

See also
• “<implementsEntity>” on page 214
• “Creating a new delegate object” on page 247.
• For a discussion of working with delegates in Gosu classes, see the Gosu Reference Guide.

Delegate object types that you cannot implement directly

There are some delegates that you cannot implement directly through the use of the <implementsEntity> element.
They are:
• Versionable
• KeyableBean
• Editable
• Retireable
• EffDated
• EffDatedBranch
• EffDatedContainer
These are special delegates that PolicyCenter implicitly adds to an entity if you set the type attribute on the entity to
one of these values. Therefore, do not use the <implementsEntity> element to specify one of these delegates.
Instead, use the type attribute on the entity declaration. The basic syntax looks similar to the following:
The PolicyCenter data model 181
Guidewire PolicyCenter 9.0.9 Configuration Guide

<entity name="SomeEntity" ... type="SomeDelegate">

For example, in the base configuration, the Group entity also implements the Retireable delegate by setting the
entity type attribute to retireable.
<entity entity="Group" ... type="retireable">
<implementsEntity name="Validatable"/>
...
</entity>

Also, it is not possible to explicitly implement the EventAware delegate. PolicyCenter automatically adds this
delegate to any entity that contains an <events> element.

Archiving delegates in the base configuration must not be changed

To support the archive process, certain Guidewire entities in the base configuration implement one or more of the
following delegates:
• RootInfo
• Extractable
• OverlapTable

WARNING Do not change or remove the archiving delegates on Guidewire entities in the base
configuration. Otherwise, the server may not start due to errors in the archiving domain graph.

Recommendations for using delegates

Guidewire recommends that you use delegates in three scenarios.

Implementing a common interface

Guidewire recommends that you use a delegate if you want both of the following:
• If you want to have multiple entities implement the same interface
• If you want most of the implementations of the interface to be common
PolicyCenter defines a number of delegates in the base configuration. For example:
• Assignable
• Editable
• Validatable
• ...
To determine the list of base configuration delegate entities, search the configuration→config→Metadata→Entity folder
for files that contain the following text:
<delegate

Subtyping without single‐table inheritance

Guidewire recommends that you create a delegate entity rather than define a supertype entity if you do not want to
store subtype data in a single table. PolicyCenter stores information on all subtypes of a supertype entity in a single
table. This can create a table that is extremely large and extremely wide. This is true especially if you have an entity
hierarchy with a number of different subtypes that each have their own columns. Using a delegate avoids this single-
table inheritance while preserving the ability to define the fields and behavior common to all the subtypes in one
place.
Guidewire recommends that you consider carefully before making a decision on how to model your entity hierarchy.

Using entity polymorphism

Guidewire recommends that you create a delegate entity if you want to use polymorphism on class methods. For
core PolicyCenter classes defined in Java, you cannot override these class methods on its Gosu subtypes. You can,
182 chapter 15: The PolicyCenter data model
 Guidewire PolicyCenter 9.0.9 Configuration Guide

however, push all methods and behaviors that can possibly be polymorphic into an interface, rather than the Java
superclass. You can then require that all implementers of the delegate implement that interface (the
<implementsEntity>) through the use of the delegate requires attribute. This delegate usage permits the use of
polymorphism and enables delegate implementations to share common implementations on a common superclass.

<entity> elements and related data object types

The <entity> XML root element defines many—if not most—of the PolicyCenter entities.

Attributes of <entity>
The <entity> element contains the following attributes.

<entity> attribute Description Default

abstract If true, you cannot an create instance of the entity type at run false
time. Instead, you must declare a subtype entity with
abstract=false, which you can instantiate. Any of the gener‐
ated code is abstract.
admin Determines whether you can reference the entity from staging false
tables:
• Entity X has admin="true". Suppose that you have
another, loadable table Y that has a foreign key to X. Then
at the time you load the staging table for Y, you can load
public IDs that specify entities of type X that are already in
the main tables.
• Entity X has admin="false". Any Y that you load into a
staging table must specify an X that is being loaded into
the staging table for X at the same time.
This is important because it allows the staging table loader to
do less checking at load time. For example:
• If admin="false", then the staging table loader merely
has to check that all public IDs in ccst_y specify valid
entries in ccst_x.
• If admin="true", then the staging table loader has to
check that all public IDs in ccst_y specify a valid entry in
ccst_x. It must also check that all public IDs in ccst_y
specify a valid entry in cc_x, the main table.
autoSplit Use with effDated entities, whether PolicyCenter auto‐splits true
the entity on a slice edit.
cacheable Internal. If set to false, then Guidewire prohibits entities of true
this type and all its subtypes from existing in the global cache.
consistentChildren Internal. If set to true, then PolicyCenter generates a consis‐ false
tency check and a loader validation that tries to ensure that
links between child entities of this entity are consistent.
Guidewire enforces the constraint only while loading data
from staging tables. You can detect violations of the constraint
on data committed to entity tables after the fact by running a
consistency check.
IMPORTANT Guidewire does not enforce
consistentChildren constraints at bundle commit.

desc A description of the purpose and use of the entity. None

displayName Optional. Creates a more human‐readable form of the entity None
name. You can access this name using the following:
[Link]

The PolicyCenter data model 183

Guidewire PolicyCenter 9.0.9 Configuration Guide

<entity> attribute Description Default

If you do not specify a value for the DisplayName attribute,
then the [Link] method returns the value of
the entity attribute, instead. If you subtype an entity that has
a specified display name, then the [Link]
method returns the name of the subtype key.
edgeTable For the purposes of archiving, whether the entity has the se‐ false
mantics of an edge table.
effDatedBranchType Relevant only for entities of type effDated. This value defines None
the type of the root of the tree in which the effDated entity
exists. The only allowed value is PolicyPeriod.
effDatedBranchesField Internal. Relevant only for Policy entities. This value defines None
the field that refers to the branches of this container.
effDatedContainerField Internal. Relevant only for PolicyPeriod entities. This value None
defines the field that refers to the container of this branch.
effDatedRegistryTableName Internal. Relevant only for Policy entities. This value defines None
the name of the table that stores the effdated table registry
for this container entity.
entity Required. The name of the entity. You use this name to access None
the entity in data views, rules, and other areas within
PolicyCenter.
exportable Unused.
extendable Internal. If true, it is possible to extend this entity. true

final If true, you cannot subtype the entity. If false, you can de‐ true
fine subtypes using this entity as the supertype.
IMPORTANT If you define this incorrectly, PolicyCenter gener‐
ates an error message upon resource verification and the ap‐
plication server refuses to start. PolicyCenter generates this
verification error:
• If you attempt to subtype an entity that is marked as
final that exists in the metadata folder in Guidewire
Studio™.
• If you attempt to subtype an entity that is marked as
final that exists in the extensions folder in Studio.

generateInternallyIfAbsent Internal. Do not use. false

ignoreForEvents The ignoreForEvents attribute indicates whether other enti‐ false

ties pass over the instant entity when determining the origin
of an event. If the value of ignoreForEvents is true,
PolicyCenter ignores the entity in this context.
If the <events> element is not present in an entity, that entity
does not generate events. Moreover, that entity does not gen‐
erate events when you create, modify, or delete it. Thus, it
makes no sense for PolicyCenter to examine either that entity
or entities that reference it when the product searches for the
source of an event.

184 chapter 15: The PolicyCenter data model

 Guidewire PolicyCenter 9.0.9 Configuration Guide

<entity> attribute Description Default

Nonetheless, even if an entity generates no events, whenever
you modify it, PolicyCenter still examines that entity and all
entity instances that reference it. The scope of this examina‐
tion encompasses the non‐event‐generating entity as well as
arrays, foreign keys, and edge foreign keys that reference it. If
PolicyCenter finds an entity instance that both generates
events and references the modified, non‐event‐generating en‐
tity, the product generates a Changed event for that entity in‐
stance. This examination and event generation process results
in unnecessary and long chain queries.
Guidewire offers two solutions to the resultant performance
challenge. You can avoid the examination and event genera‐
tion altogether if you set the ignoreForEvents attribute to
true on the non‐event‐generating entity. In this case,
PolicyCenter ignores the non‐event‐generating entity as well
as references to it when an event occurs.
As an alternative, you can avoid the examination and event
generation in some cases while allowing the process in others.
To effect this selective avoidance, set the ignoreForEvents
attribute to true not on the non‐event‐generating entity.
Rather, set it to true only on event‐generating entity instan‐
ces both that reference the entity and that you want
PolicyCenter to ignore. Such referencing entity instances
might be arrays, foreign keys, or edge foreign keys.
In this case, when you modify the non‐event‐generating enti‐
ty, PolicyCenter does not ignore the entity altogether. When
you modify the entity, event‐generating entity instances that
reference the entity and on which the ignoreForEvents at‐
tribute is false still generate events. Instead, PolicyCenter ig‐
nores only the referencing entity instance on which you set
the ignoreForEvents attribute to true.
Thus, if you want no events triggered at all when you modify a
non‐event‐generating entity, set the ignoreForEvents attrib‐
ute on that entity to true. If you want some events avoided
and some triggered, take this step only on event‐generating
entities that reference the non‐event‐generating entity and
that you want to ignore. Set the ignoreForEvents attribute to
true as appropriate to ensure optimal performance.

instrumentationTable Internal. false

loadable If true, you can load the entity through staging tables. true

lockable Internal. If set to true, PolicyCenter adds a lock column false

(lockingcolumn) to the table for this entity. PolicyCenter uses
this to acquire an update lock on a row. The most common
use is on objects in which it is important to implement safe or‐
dering of messages. In that case, the entity that imposes the
safe ordering needs to be lockable.
IMPORTANT Guidewire strongly recommends that you do not
use this locking mechanism.
overwrittenInStagingTable Internal. If true and the entity is loadable, the loader process false
auto‐populates the staging table during import.
IMPORTANT If set to true, do not attempt to populate the ta‐
ble yourself, because the loader import process overwrites
this table.
platform Internal. Do not use. The only real effect is to change the loca‐ false
tion in which the table appears in a data distribution report.

The PolicyCenter data model 185

Guidewire PolicyCenter 9.0.9 Configuration Guide

<entity> attribute Description Default

priority The priority of the corresponding subtype key. This value is ‐1
meaningful only for entities participating in a subtype hierar‐
chy, which can be either the <subtype> entities or the root
<entity>.

readOnly Optional. The typical use of read‐only entities is for tables of None
reference data that you import as administrative data and
then never touch again.
You can add a read‐only entity only to a bundle that has the
allowReadOnlyBeanChanges() flag set on its commit options.
That means that inserting, modifying or deleting a read‐only
entity requires one of these special bundles.
You cannot set bundle commit options from Gosu. Therefore,
you cannot modify these entities from Gosu, unless some
Gosu‐accessible interface gives you a special bundle. The ad‐
ministrative XML import tools use such a special bundle. How‐
ever, Guidewire uses these tools internally only in the
PolicyCenter product model.
setterScriptability See “Data objects and scriptability” on page 178. None
subpackage Subpackage to which the class corresponding to this entity be‐ None
longs.
table Required. The name of the database table in which None
PolicyCenter stores the data for this entity. PolicyCenter auto‐
matically prefixes table names with pc_ for base entities and
pcx_ for extension entities.
Guidewire recommends the following table naming conven‐
tions:
• Do not begin the table name with any product‐specific
extension.
• Use only unaccented, lowercase Roman letters and the
underscore character.
• Prefix the table name with test_ if you use the table
solely for testing.
• Because PolicyCenter automatically prefixes extension
table names with pcx_, if you run into limits on the length
of the table name, you can consider removing the _Ext
suffix from the table name.
Guidewire enforces the following restrictions on the maxi‐
mum allowable length of the table name:
• loadable="true" — maximum of 25 characters
• loadable="false" — maximum of 26 characters
temporary Internal. If true, then this table is a temporary table that false
PolicyCenter uses only during installation or upgrade.
PolicyCenter deletes all temporary tables after it completes
the installation or the upgrade.
type Required. See “Overview of data entities” on page 171 for a None
discussion of data entity types.
typelistTableName The typelist that PolicyCenter generates when you create a None
non‐final entity has an associated database table. If you do
not specify a value for the typelistTableName attribute, then
PolicyCenter uses the name of the entity as the table name for
the subtype typelist.

186 chapter 15: The PolicyCenter data model

 Guidewire PolicyCenter 9.0.9 Configuration Guide

<entity> attribute Description Default

However, PolicyCenter places a restriction of 25 characters on
the length of the database table name. You use the
typelistTableName attribute to specify the database table
name for the typelist if an entity name is too long to become a
valid typelist table name.
It is not valid to use this attribute with entity types marked as
final.
validateOnCommit Internal. Do not use. If true, PolicyCenter validates this entity true
during a commit of a bundle that contains this entity.

IMPORTANT Do not modify internal entity attributes. This instruction applies even in the case of
custom entities.

IMPORTANT
If you create a non-final <entity> element, then PolicyCenter automatically creates a typelist with the
same name as the resulting entity. The typelist allows you to keep track of the subtypes of that entity.
PolicyCenter creates this typelist whether or not a <subtype> element exists that refers to the non-
final <entity> element.
Suppose that you change a final <entity> element to a non-final <entity> element. Suppose further
that you already have a typelist with the same name as the resulting entity. In this case, you must
change the name of the preexisting typelist beforehand. Otherwise, the automatic typelist generation
cannot proceed, and you will receive an error.

Subelements of <entity>
The <entity> element contains the following subelements.

<entity> subelement Description

array See “<array>” on page 199.
checkconstraint Internal.
column See “<column>” on page 202.
customconsistencycheck Internal.
datetimeordering Internal.
dbcheckbuilder Internal.
edgeForeignKey See “<edgeForeignKey>” on page 207.
events Indicates that the entity raises events and that the entity is aware of events. See “<events>” on
page 210.
foreignkey See “<foreignkey>” on page 211.
fulldescription See “<fulldescription>” on page 214.
implementsEntity See “<implementsEntity>” on page 214.
implementsInterface See “<implementsInterface>” on page 215.
index See “<index>” on page 216.
jointableconsistencycheck Internal.

The PolicyCenter data model 187

Guidewire PolicyCenter 9.0.9 Configuration Guide

<entity> subelement Description

monetaryamount Handles monetary amounts. The <monetaryamount> subelement is a compound data type that
stores its values in two separate database columns: a <money> column type, and a typekey to
the Currency typelist.
onetoone See “<onetoone>” on page 217.
remove-index See “<remove‐index>” on page 218.
searchColumn See “<entity> elements and related data object types” on page 183
searchTypekey Defines a search denormalization typekey in the database. The denormalization copies the val‐
ue of a column on another table into a typekey field on the denormalizing table. You must link
the tables through a foreign key. The purpose of this denormalization is to avoid costly joins in
performance critical searches.
tableAugmenter Internal.
typekey See “<typekey>” on page 220.
validatetypekeyinset Internal.
validatetypekeynotinset Internal.

IMPORTANT Do not modify internal entity subelements even in the case of custom entities.

The <searchColumn> subelement

The <searchColumn> subelement on <entity> defines a search denormalization column in the database. The
denormalization copies the value of a column on another table into a column on the denormalizing table. You must
link the tables through a foreign key. The purpose of this denormalization is to avoid costly joins in performance-
critical searches.
The use of search denormalization columns adds overhead to updates, as does any denormalization. Guidewire
recommends that you only use these columns if there is an identifiable performance problem with a search that is
directly related to the join between the two tables
Note: It is possible to have a <searchColumn> sublement on the <extension> and <subtype>
elements as well.
The <searchColumn> element contains the following attributes.

<searchColumn> attribute Description Default

columnName Name to use for the database column corresponding to this property. If None
you do not specify a value, then PolicyCenter uses the name value in‐
stead.
The columnName attribute must be no more than 30 characters in
length. It allows only unaccented Roman letters, numbers, and the un‐
derscore character. The first character of the columnName attribute
must be a letter. Although the underscore character is allowable here,
Guidewire discourages its use.
deprecated If true, then PolicyCenter marks the item as deprecated in the Data false
Dictionary and places a Deprecated annotation on it in the Guidewire
Studio API Reference.
If you deprecate an item, use the description to explain why.
For more information, see “Data entity subelements” on page 198.
desc Description of the intended purpose of this column. None

188 chapter 15: The PolicyCenter data model

 Guidewire PolicyCenter 9.0.9 Configuration Guide

<searchColumn> attribute Description Default

name Required. Name of the column on the table and the field on the entity. None
The name value maps to the accessor and mutator methods of a field on
the entity, not the actual private member field. For example, name
maps to setName and getName, not the private _name member field.
Column names must contain letters only. A column name cannot con‐
tain an underscore.
sourceColumn Required. Name of the column on the source entity, whose value this None
column copies. The sourceColumn must not name a localized column.
sourceForeignKey Required. Name of a foreign key field on this entity, which refers to the None
source entity for this search denormalization column. The
sourceForeignKey must not be importable against existing objects.

sourceSubtype Optional name of the particular subtype on which the source column is None
defined. If not specified, then PolicyCenter assumes that the source
column to exist on the entity referred to by the source object. However,
you must specify this value if the sourceColumn is on a subtype of the
entity referred to by sourceForeignKey.

For example, suppose that you set the following attribute definitions:
• searchColumn – MyDenormColumn
• sourceForeignKey – Source
• sourceColumn – SourceField
This declaration says:
Copy the value of SourceField on the object pointed to by the foreign key named Source into the field named
MyDenormColumn. PolicyCenter automatically populates the column as part of bundle commit, staging table load,
and database upgrade.
If you need to denormalize a field on a subtype of the entity referred to by the foreign key, then you can specify the
optional sourceSubtype attribute.
As with linguistic denormalization columns, you cannot access the value of these search denormalization columns in
memory. The value is only available in the database. Thus, you can only access the value through a database query.
It is possible to make a query against a search denormalization column that is a denormalization of a linguistic
denormalization column. In that case, the query generator knows not to wrap the column values in the linguistic
denormalization function. This preserves the optimization that linguistic denormalization columns provide.
It is important to understand that search denormalization columns specify one column only — the column that you
specify with the sourceColumn attribute. So, if you want to denormalize both a column and its linguistic
denormalization, then you need two separate search denormalization columns. However, in this case, you typically
would just want to denormalize the linguistic denormalization column. You would only want to denormalize the
source column if you wanted to support case-sensitive searches on it.
Search denormalization columns can only specify <column> or <typekey> fields.

<extension> elements and related data object types

The <extension> XML root element defines extension data object types. An extension data object type extends an
already existing data object type or entity. Guidewire defines extensions in data model metadata files.

See also
• For information on how to extend the base data objects, see “Modifying the base data model” on page 237.

Attributes of <extension>
The <extension> element contains the following attributes.
The PolicyCenter data model 189
Guidewire PolicyCenter 9.0.9 Configuration Guide

<extension> attrib‐ Description Default

ute
entityName Required. This value must match the file name of the entity that it extends. None
PolicyCenter generates an error at resource verification if the value that you set for the
entityName attribute in an extension does not match the file name.

Subelements of <extension>
The <extension> element contains the following subelements.

<extension> subelement Description

array See “<array>” on page 199.
array-override Use to override, or flip, the value of the triggersValidation attribute of an <array> element
definition on a base data object. See “Working with attribute and element overrides” on
page 243 for details.
column See “<column>” on page 202.
column-override Use to override certain very specific attributes of a base data object. See “Working with attribute
and element overrides” on page 243 for details.
description A description of the purpose and use of the entity.
edgeForeignKey See “<edgeForeignKey>” on page 207.
edgeForeignKey- Use to override certain very specific attributes of a base data object.
override

events See “<events>” on page 210.

foreignkey See “<foreignkey>” on page 211.
foreignkey-override Use to override, or flip, the value of the triggersValidation attribute of a <foreignkey> ele‐
ment definition on a base data object. See “Working with attribute and element overrides” on
page 243 for details.
implementsEntity See “<implementsEntity>” on page 214.
implementsInterface See “<implementsInterface>” on page 215.
index See “<index>” on page 216.
internalonlyfields Internal.
monetaryamount Handles monetary amounts. The <monetaryamount> subelement is a compound data type that
stores its values in two separate database columns: a <money> column type and a typekey to the
Currency typelist.

onetoone See “<onetoone>” on page 217.

onetoone-override Use to override, or flip, the value of the triggersValidation attribute of a <onetoone> element
definition on a base data object. See “Working with attribute and element overrides” on
page 243 for details.
remove-index See “<remove‐index>” on page 218.
searchColumn See “<entity> elements and related data object types” on page 183
searchTypekey Defines a search denormalization typekey in the database. The denormalization copies the value
of a column on another table into a typekey field on the denormalizing table. You must link the
tables through a foreign key. The purpose of this denormalization is to avoid costly joins in per‐
formance critical searches.
typekey See “<typekey>” on page 220.

190 chapter 15: The PolicyCenter data model

 Guidewire PolicyCenter 9.0.9 Configuration Guide

<extension> subelement Description

typekey-override Use to override certain specific attributes, or fields, of a <typekey> element definition on a base
data object. See “Working with attribute and element overrides” on page 243 for details.

<nonPersistentEntity> elements and related data object types

The <nonPersistentEntity> XML root element defines non-persistent entity data object types. A non-persistent
entity data object type defines a temporary entity instance or object. PolicyCenter creates and uses this object only
during the time that the PolicyCenter server is running. When the server shuts down, PolicyCenter discards the
object data. It is not possible to commit a non-persistent entity object to the database.
Guidewire defines non-persistent entities in data model metadata files.
Note: You cannot subtype a persistent entity with a non-persistent entity.

Guidewire recommendations for non‐persistent entities

As a general rule, Guidewire recommends that you do not create new non-persistent entities. In addition, do not
extend existing non-persistent entities unless instructed to do so. For example, the base configuration contains non-
persistent entities that you can extend to specify new search criteria.
A major issue with non-persistent entities is that they do not interact well with data bundles. For example, passing a
non-persistent entity instance to a PCF page is generally a bad idea because it generally does not work in the manner
that you expect.
A non-persistent entity instance has to live in a bundle and can only live in one bundle. Therefore, passing it to one
context removes it from the other context. Even worse, it is possible that in passing the non-persistent entity instance
from one context to another, the object loses any nested arrays or links associated with it. Thus, it is possible to lose
parts of the entity graph as the non-persistent entity instance moves around.
In situations where you want the behavior of a non-persistent entity, use a Gosu class instead. For example:
• If you want the behavior of a non-persistent entity in web services, create a Gosu class. Then, expose the class as
a web service. Do not rely on non-persistent entities and entity serialization.
• If you want a field that behaves as a column, specify a data type through the use of annotations. For example, you
could use this technique for nonnegativeinteger column behavior. After specifying the data type, add the
wanted data type behavior to properties on Gosu classes. For information on how to associate data types with
object properties using the annotation syntax, see “Defining a data type for a property” on page 285.

Attributes of <nonPersistentEntity>
The <nonPersistentEntity> element contains the following attributes.

<nonPersistentEntity> at‐ Description De‐

tribute fault
abstract If true, you cannot create an instance of the entity type at runtime. Instead, you false
must declare a subtype entity with abstract=false, which you can instantiate. Any
of the generated code is abstract.
desc A description of the purpose and use of the entity. None
displayName Optional. Creates a more human‐readable form of the entity name. You can access None
this name using the following:
[Link]
If you do not specify a value for the DisplayName attribute, then the
[Link] method returns the value of the entity attribute, instead. If you
subtype an entity that has a specified display name, then the [Link]
method returns the name of the subtype key.
entity Required. The name of the entity. You use this name to access the entity in data None
views, rules, and other areas within PolicyCenter.

The PolicyCenter data model 191

Guidewire PolicyCenter 9.0.9 Configuration Guide

<nonPersistentEntity> at‐ Description De‐

tribute fault
exportable Unused.
extendable If true, it is possible to extend this entity. true

final If true, you cannot subtype the entity. If false, you can define subtypes using this true
entity as the supertype.
platform Internal. Do not use. The only real effect is to change the location in which the table false
appears in a data distribution report.
priority The priority of the corresponding subtype key. This value is meaningful only for enti‐ -1
ties participating in a subtype hierarchy, which can be either the <subtype> entities
or the root <entity>.
typelistTableName If you create a non‐final entity, then PolicyCenter automatically creates a typelist to None
keep track of the subtypes of that entity. That typelist has an associated database ta‐
ble. If you do not specify a value for this attribute, then PolicyCenter uses the name
of the entity as the table name for the subtype typelist.
However, PolicyCenter places a restriction of 25 characters on the length of the data‐
base table name. You use this attribute to specify the database table name for the
typelist if an entity name is too long to become a valid typelist table name.
It is not valid to use this attribute with entity types marked as final.

Subelements of <nonPersistentEntity>
The <nonPersistentEntity> element contains the following subelements.

<nonPersistentEntity> subele‐ Description

ment
array See “<array>” on page 199.
column See “<column>” on page 202.
edgeForeignKey See “<edgeForeignKey>” on page 207.
foreignkey See “<foreignkey>” on page 211.
fulldescription See “<fulldescription>” on page 214.
implementsEntity See “<implementsEntity>” on page 214.
implementsInterface See “<implementsInterface>” on page 215.
monetaryamount Handles monetary amounts. The <monetaryamount> subelement is a compound data
type that stores its values in two separate database columns: a <money> column type
and a typekey to the Currency typelist.
onetoone See “<onetoone>” on page 217.
typekey See “<typekey>” on page 220.

<subtype> elements and related data object types

The <subtype> XML root element defines an entity type that is a subtype of another entity. The subtype entity has
all of the fields and elements of its supertype. The subtype entity can also have additional fields and elements.
Guidewire defines subtype entities in the data model metadata files.
PolicyCenter does not associate a separate database table with a subtype. Instead, PolicyCenter stores all subtypes of
a supertype in the table of the supertype and resolves the entity to the correct subtype based on the value of the
Subtype field. To accommodate this, PolicyCenter stores all fields of a subtype in the database as nullable columns

192 chapter 15: The PolicyCenter data model

 Guidewire PolicyCenter 9.0.9 Configuration Guide

—even the ones defined as non-nullable. However, if you define a field as non-nullable, then the PolicyCenter
metadata service enforces this for all data operations.
You can only define a subtype for any entity that has its final attribute set to false. PolicyCenter automatically
creates a Subtype field for non-final entities.

Attributes of <subtype>

The <subtype> element contains the following attributes:

<subtype> attrib‐ Description De‐

ute fault
abstract If true, you cannot create an instance of the entity type at runtime. Instead, you must de‐ false
clare a subtype entity with abstract=false, which you can instantiate. Any of the generat‐
ed code is abstract.
desc A description of the purpose and use of the subtype. None
displayName Optional. Occasionally in the PolicyCenter interface, you want to display the subtype name None
of subtyped entity instances. Use the displayName attribute to specify a String to display
as the subtype name. You can access this name using the following:
[Link]
If you do not specify a value for the displayName attribute, then PolicyCenter displays the
name of the entity. The entity name is often not user‐friendly. For a description of the
displayName attribute, see “<entity> elements and related data object types” on page 183.

entity Required.
final If true, you cannot subtype the entity. If false, you can define subtypes using this entity as false
the supertype.
platform Internal. Do not use. The only real effect is to change the location in which the table ap‐ false
pears in a data distribution report.
priority The priority of the corresponding subtype key. This value is meaningful only for entities -1
participating in a subtype hierarchy, which can be either the <subtype> entities or the root
<entity>.

readOnly Optional. The typical use of read‐only entities is for tables of reference data that you import None
as administrative data and then never touch again.
You can add a read‐only entity only to a bundle that has the allowReadOnlyBeanChanges()
flag set on its commit options. That means that inserting, modifying or deleting a read‐only
entity requires one of these special bundles.
You cannot set bundle commit options from Gosu. Therefore, you cannot modify these en‐
tities from Gosu, unless some Gosu‐accessible interface gives you a special bundle. The ad‐
ministrative XML import tools use such a special bundle. However, Guidewire uses these
tools internally only in the PolicyCenter product model.
setterScriptability See “Data objects and scriptability” on page 178 for information. None
supertype Required.

Subelements of <subtype>

The <subtype> element contains the following subelements.

<subtype> subelement Description

array See “<array>” on page 199.
checkconstraint Internal.
column See “<column>” on page 202.

The PolicyCenter data model 193

Guidewire PolicyCenter 9.0.9 Configuration Guide

<subtype> subelement Description

customconsistencycheck Internal.
datetimeordering Internal.
dbcheckbuilder Internal.
edgeForeignKey See “<edgeForeignKey>” on page 207.
events See “<events>” on page 210.
foreignkey See “<foreignkey>” on page 211.
fulldescription See “<fulldescription>” on page 214.
implementsEntity See “<implementsEntity>” on page 214.
implementsInterface See “<implementsInterface>” on page 215.
index See “<index>” on page 216.
jointableconsistencycheck Internal.

monetaryamount Handles monetary amounts. The <monetaryamount> subelement is a compound data type that
stores its values in two separate database columns: a <money> column type, and a typekey to
the Currency typelist.
onetoone See “<onetoone>” on page 217.
searchColumn See “<entity> elements and related data object types” on page 183.
searchTypekey Defines a search denormalization typekey in the database. The denormalization copies the val‐
ue of a column on another table into a typekey field on the denormalizing table. You must link
the tables through a foreign key. The purpose of this denormalization is to avoid costly joins in
performance critical searches.
tableAugmenter Internal.
typekey See “<typekey>” on page 220.
validatetypekeyinset Internal.
validatetypekeynotinset Internal.

Subtypes and typelists

After you define a new subtype, PolicyCenter automatically adds that entity type to the associated entity typelist.
This is true, even if PolicyCenter marks that typelist as final.
For example, suppose that you define an Inspector entity as a subtype of Person.
<?xml version="1.0"?>
<subtype xmlns="[Link] desc="Professional inspector" displayName="Inspector"
entity="InspectorExt"
supertype="Person">
<column name="InspectorLicenseExt" type="varchar" desc="Inspector's business license number">
<columnParam name="size" value="30"/>
</column>
</subtype>

Notice that while InspectorExt is subtype of Person, Person, itself, is a subtype of Contact. PolicyCenter
automatically adds the new InspectorExt type to the Contact typelist. This is true, even though PolicyCenter
marks the Contact typelist as final.
To see this change:
• In the PolicyCenter Data Dictionary, you must restart the application server.
• In the Contact typelist in Studio, you must restart Studio.

194 chapter 15: The PolicyCenter data model

 Guidewire PolicyCenter 9.0.9 Configuration Guide

See also

• “Defining a subtype” on page 252

<viewEntity> elements and related data object types

The <viewEntity> XML root element defines view entity data object types. A view entity data object type is a
logical view of entity data. You can use a view entity to enhance performance during the viewing of tabular data. A
view entity provides a logical view of data for an entity of interest to a list view. A view entity can include paths
from the root or primary entity to other related entities.
For example, from the DesktopActivityView, you can specify a column with a [Link] value. The
Activity entity is the primary entity of the DesktopActivityView. The Activity entity has a corresponding view
entity called ActivityView.
Unlike a standard entity, a view entity does not have an underlying database table. PolicyCenter does not persist
view entities to the database. Instead of storing data, a view entity restricts the amount of data that a database query
returns. A view entity does not represent or create a materialized view, which is a database table that caches the
results of a database query.
Queries against a view entity type are actually run against the normal entity table in the database, as specified by the
primaryEntity attribute of the view entity definition. The query against a view entity automatically adds any joins
necessary to retrieve view entity columns if they include a bean path. However, access to view entity columns is not
possible when constructing the query.
A view entity improves the performance of PolicyCenter on frequently used pages that list entities. Like other
entities, you can subtype a view entity.
For example, the My Activities page uses a view entity, the ActivityDesktopView, which is a subtype of the
ActivityView.
Because PolicyCenter can export view entity types, it generates SOAP interfaces for them.
Note: If you create or extend a view entity that references a column that is of
type="currencyamount", then you must handle the view entity extension in a particular manner.
Guidewire defines this object in the data model metadata files as the <viewEntity> XML root element.

Attributes of <viewEntity>

The <viewEntity> element contains the following attributes:

<viewEntity> attrib‐ Description Default

ute
abstract If true, you cannot an create instance of the entity type at runtime. Instead, you must de‐ false
clare a subtype entity with abstract=false, which you can instantiate. Any of the generated
code is abstract.
desc A description of the purpose and use of the entity. None
displayName Optional. Creates a more human‐readable form of the entity name. You can access this name None
using the following:
[Link]
If you do not specify a value for the DisplayName attribute, then the [Link]
method returns the value of the entity attribute, instead. If you subtype an entity that has a
specified display name, then the [Link] method returns the name of the sub‐
type key.
entity Required. Name of this viewEntity object. None
exportable Unused.
extendable If true, it is possible to extend this entity. true

The PolicyCenter data model 195

Guidewire PolicyCenter 9.0.9 Configuration Guide

<viewEntity> attrib‐ Description Default

ute
final If true, the entity definition is final and you cannot define any subtypes for it. If false, then true
you can define a subtype using this entity as the supertype.
platform Internal. Do not use. The only real effect is to change the location in which the table appears false
in a data distribution report.
primaryEntity Required. The primary entity type for this viewEntity object. The primary entity must be None
keyable. See “Data entities and the application database” on page 175 for information on
keyable entities.

priority For supertypes and subtypes, the priority of the corresponding subtype key. -1

showRetiredBeans Whether to show retired beans in the view. None

supertypeEntity Optional. The name of supertype of this entity. None
typelistTableName If you create a non‐final entity, then PolicyCenter automatically creates a typelist to keep None
track of the subtypes of that entity. That typelist has an associated database table. If you do
not specify a value for this attribute, then PolicyCenter uses the name of the entity as the
table name for the subtype typelist.
However, PolicyCenter places a restriction of 25 characters on the length of the database ta‐
ble name. You use this attribute to specify an alternate database table name for the typelist if
an entity name is too long to become a valid typelist table name.
It is not valid to use this attribute with entity types marked as final.

Subelements of <viewEntity>
The <viewEntity> elements contain the following subelements:

<viewEntity> subele‐ Description

ment
computedcolumn Specifies a column with row values that Guidewire computes while querying the database. For
example, the values of a computed column might be the sum of the values from two database
columns (col1 + col2).
computedtypekey Specifies a typekey that has some type of transformation applied to it during querying from the
database.
fulldescription See the discussion following the table.
implementsInterface See “<implementsInterface>” on page 215.
viewEntityColumn Represents a column in a viewEntity table
viewEntityLink Uses to access another entity through a foreign key. Typically, you use this value within the
PolicyCenter interface to create a link to that entity.
viewEntityName Represents an entity name column in a viewEntity table. An entity name is a string column that
contains the name of an entity that is suitable for viewing in the PolicyCenter interface.

viewEntityTypekey Represents a typekey column in a viewEntity table.

The Data Dictionary uses the fulldescription subelement. The following example illustrates how to use this
element:
<fulldescription>
<![CDATA[<p>Aggregates the information needed to display one activity row (base entity for all other
activity views).</p>]]>
</fulldescription>

The other subelements all require both a name and path attribute. The following code illustrates this:

196 chapter 15: The PolicyCenter data model

 Guidewire PolicyCenter 9.0.9 Configuration Guide

<viewEntityName name="RelActAssignedUserName" path="[Link]"/>

Specify the path value relative to the primaryEntity on which you base the view.
The computedcolumn takes a required expression attribute and an additional, optional function attribute. The
following is an example of a computedcolumn:
<computedcolumn name="Amount" expression="${1}" paths="[Link]" function="SUM"/>

The expression for this column can take multiple column values ${column_num} passed from the PolicyCenter
interface. For example, a valid expression is ${1} - ${2}, where ${1} represents the first column and ${2}
represents the second column. The function value must be an SQL function that you can apply to this expression.
The following are legal values:
• SUM
• AVG
• COUNT
• MIN
• MAX
Note: If the SQL function aggregates data, PolicyCenter applies an SQL group automatically.

<viewEntityExtension> elements and related data object types

The <viewEntityExtension> XML root element defines view entity extension data object types. You use the view
entity extension entity to extend the definition of a viewEntity entity. See “<viewEntity> elements and related data
object types” on page 195 for more information on view entities. Guidewire defines view entity extension data
object types in the data model metadata files.

Attributes of <viewEntityExtension>

The <viewEntityExtension> element contains the following attributes:

<viewEntityExtension> attrib‐ Description Default

ute
entityName Required. This value must match the file name of the viewEntityExtension that it None
extends.
PolicyCenter generates an error at resource verification if the value set that you set
for the entityName attribute for a viewEntityExtension does not match the file
name.

Subelements of <viewEntityExtension>

The <viewEntityExtension> element contains the following subelements:

<viewEntityExtension> sub‐ Description

element
computedcolumn Specifies a column with row values that Guidewire computes while querying the database.
For example, the values of a computed column might be the sum of the values from two
database columns (col1 + col2).
computedtypekey Specifies a typekey that has some type of transformation applied to it during querying from
the database.
description A description of the purpose and use of the entity.

The PolicyCenter data model 197

Guidewire PolicyCenter 9.0.9 Configuration Guide

<viewEntityExtension> sub‐ Description

element
viewEntityColumn Represents a column in a viewEntity table. The viewEntityColumn element contains a
path attribute that you use to define the entity path for the column:
• The path attribute definition cannot traverse arrays.
• The path attribute is always relative to the primary entity on which you base the view.
Note: If you reference a column of type currencyamount, you must also define the
currencyProperty specified in the original column definition on the viewEntity entity. See
“Extending an existing view entity” on page 255 for an example of this.
viewEntityLink Uses to access another entity through a foreign key. Typically, you use this value within the
PolicyCenter interface to create a link to that entity.
viewEntityName Represents an entity name column in a viewEntity table. An entity name is a string column
that contains the name of an entity that is suitable for viewing in the PolicyCenter interface.
viewEntityTypekey Represents a typekey column in a viewEntity table.

Important caution
Guidewire strongly recommends that you not create a view entity extension—viewEntityExtension—that causes
traversals into revisioned (effdated) data. Doing so has the possibility of returning duplicate rows if any
revisioning in the traversal path splits an entity.
Instead, try one of the following:
• Denormalize the desired data onto a non-effdated entity.
• Add domain methods to the implementation of the View entity.

Data entity subelements

This topic describes the subelements that you can use in metadata definition files. These subelements are:
• <array>
• <column>
• <edgeForeignKey>
• <events>
• <foreignkey>
• <fulldescription>
• <implementsEntity>
• <implementsInterface>
• <index>
• <onetoone>
• <remove-index>
• <tag>
• <typekey>

Subelements for internal use only

Do not use the following entity subelements. Guidewire uses these subelements for internal purposes only.
• <aspect>
• <checkconstraint>
• <customconsistencycheck>
• <datetimeordering>
198 chapter 15: The PolicyCenter data model
 Guidewire PolicyCenter 9.0.9 Configuration Guide

• <dbcheckbuilder>
• <jointableconsistencycheck>
• <tableAugmenter>
• <validatetypekeyinset>
• <validatetypekeynotinset>

The deprecated attribute

The deprecated attribute applies to the following subelements:
• <array>
• <column>
• <componentref>
• <edgeForeignKey>
• <foreignkey>
• <onetoone>
• <searchColumn>
• <typekey>
The deprecated="true" attribute does not alter the database in any way. Instead, the deprecated attribute marks a
data field as deprecated in the Data Dictionary and places a Deprecated annotation on the field in the Guidewire
Studio API Reference. The deprecated attribute supports organizations that want to remove a field in a two-phase
process.
In the first phase, you add the deprecated attribute to the field subelement. Studio indicates the field is deprecated
whenever Gosu code references the field. During this first phase, developers work to remove the deprecated field
from their code. The second phase occurs after developers remove all occurrences of the deprecated field.
In the second phase, you drop the field from the entity definition. In some cases, Guidewire will drop the column
from the database automatically to synchronize the physical database with your revised data model. In most cases
however, the DBA must alter the database with SQL statements run against the database to synchronize the database
with your revised data model.
Guidewire generally recommends against using the deprecated attribute and the two-phase removal process. If you
deprecate a field, Studio signals to the development team that the field is no longer used. The DBA does not receive
this information. Over time, with a number of deprecated fields, the DBA manages an ever larger amount of unused
information in the physical database. To avoid managing unused data, Guidewire strongly recommends that you
keep your physical database and the data model of your application synchronized by dropping unused fields instead
of deprecating them.

<array>
An array defines a set of additional entities of the same type to associate with the main entity. For example, a
Policy entity includes an array of Document entities.

Attributes of <array>
The <array> element contains the following attributes:

<array> attribute Description De‐

fault
arrayentity Required. The name of the entity that makes up the array. None
arrayfield Optional. Name of the field in the array table that is the foreign key back to this table. How‐ None
ever, you do not need to define a value if the array entity has exactly one foreign key back to
this entity.

The PolicyCenter data model 199

Guidewire PolicyCenter 9.0.9 Configuration Guide

<array> attribute Description De‐

fault
Note that even if you define only one foreign key explicitly, additional foreign keys may be
created implicitly. For example, CreateUserID is automatically added to an editable entity.
In that case, arrayfield would be required because there is more than one foreign key.
cascadeDelete If the cascadeDelete attribute is true, the array container is retireable, and you delete the false
array container; then PolicyCenter deletes (or retires) the array elements also. If this scenar‐
io applies but the array container is not retireable, then PolicyCenter deletes the array ele‐
ments.

IMPORTANT Whether the cascadeDelete attribute is true or false, if the entity

containing the array is not retireable, deleting an instance of that entity also deletes the
objects inside the array. This behavior occurs even if the array objects themselves are
retireable in order to preserve the array objects' referential integrity. For this reason,
Guidewire recommends that you avoid placing an array of retireable objects inside an
entity that is not retireable.

deprecated If true, then PolicyCenter marks the item as deprecated in the Data Dictionary and places a false
Deprecated annotation on it in the Guidewire Studio API Reference.
If you deprecate an item, use the description to explain why.
See The deprecated attribute for more information.
desc A description of the purpose and use of the array. None
exportable Unused.
getterScriptability See “Data objects and scriptability” on page 178 for information. all

ignoreForEvents This attribute has complex, non‐intuitive interactions with data entity relationships. See false
“Interactions of ignoreForEvents attribute with data entity relationships” on page 221 for
information on how to use and configure it.
name Required. The name of the property corresponding to this array. None
owner If true, then the entity containing the array owns the objects in the array. The owner attrib‐ false
ute has the following behavior:
• If true (an owned array), then the method isFieldChanged returns true if a child
element of the array has changed. If false (a non-owned array), then the method
isFieldChanged returns false if a child element of the array has changed. In either
case, isFieldChanged returns true if any child elements are added to or removed from
the array, regardless of the value of the owner attribute.
• If true and you delete the owning object, PolicyCenter deletes (or retires) the array
items as well. In this case, PolicyCenter deletes the array items notwithstanding a value
of false for the cascadeDelete attribute. However, see the important note following
this description.
• If true, then if you update the contents of the array, then PolicyCenter considers the
owner as updated as well. This behavior can result in side effects. For example,
notwithstanding a value of false for the triggersValidation attribute, the behavior
can trigger validation.
• If true, then child array elements are copied along with the parent when the parent
copied, such as with the copy method.
• If true, the effects of the owner attribute override the effects of false values for the
cascadeDelete and triggersValidation attributes.

200 chapter 15: The PolicyCenter data model

 Guidewire PolicyCenter 9.0.9 Configuration Guide

<array> attribute Description De‐

fault

IMPORTANT Whether the owner attribute is true or false, if the entity containing the
array is not retireable, deleting an instance of that entity also deletes the objects inside
the array. This behavior occurs even if the array objects themselves are retireable in order
to preserve the array objects' referential integrity. For this reason, Guidewire recommends
that you avoid placing an array of retireable objects inside an entity that is not retireable.

Note: The owner attribute must have a value of true if the corresponding array permits
concurrent changes to its values. PolicyCenter applies an optimistic locking approach for
concurrent changes to array values. A true value for the owner attribute results in
PolicyCenter notifying the array of concurrent changes or additions to the array children.
The notification is in the form of a concurrent data change exception (CDCE) in the user
interface.
requiredmatch One of the following values None
• all – There must be at least one matching row in the array for every row from this table.
For example, there must be at least one check payee for every check.
• none – There is no requirement for matching rows.
• nonretired – There must be at least one matching row for every non‐retired row from
this table.
setterScriptability See “Data objects and scriptability” on page 178 for information. all

triggersValidation Whether changes to the entity pointed to by this array trigger validation. Changes to the false
array that trigger validation include:
• The addition of an object to the array
• The removal of an object from the array
• The modification of an object in the array
See the discussion on this attribute that follows this table.

If set to true, the triggersValidation attribute can trigger additional PolicyCenter processing. Exactly what
happens depends on several different factors:
• If the parent entity for the array is validatable, then any modification to the array triggers the execution of the
Preupdate and Validation rules on the parent entity. Validation occurs whenever PolicyCenter attempts to commit
a bundle that contains the parent entity. For an entity to be validatable, it must implement the Validatable
delegate.
• If the parent entity has preupdate rules, but no validation rules, then PolicyCenter executes the preupdate rules on
the commit bundle. This is the case only if configuration parameter UseOldStylePreUpdate is set to true,
which is the default. If UseOldStylePreUpdate is set to false, PolicyCenter invokes the IPreUpdateHandler
plugin on the commit bundle instead. Then, PolicyCenter executes the logic defined in the plugin on the commit
bundle.
• If the parent entity has validation rules, but no preupdate rules, then PolicyCenter executes the validation rules on
the commit bundle.
• If the parent entity has neither preupdate nor validation rules then the following occurs:
1. In the case of UseOldStylePreUpdate=true, PolicyCenter does nothing.
2. In the case of UseOldStylePreUpdate=false, PolicyCenter calls the IPreUpdateHandler plugin on the
commit bundle.

Subelements of <array>
The <array> element contains the following subelements:

The PolicyCenter data model 201

Guidewire PolicyCenter 9.0.9 Configuration Guide

<array> subelement Description

array-association This subelement contains the following attributes:
• hasContains (default = false)
• hasGetter (default = true)
• hasSetter (default = false)
• valueField (default = ID)
It also contains the following subelements of its own, each of which can exist, at most, one time:
• constant-map
• subtype-map
• typelist-map
See “Typelist mapping associative arrays” on page 230 for more information.
fulldescription See “<fulldescription>” on page 214.
link-association This subelement contains the following attributes:
• hasGetter (default = true)
• hasSetter (default = false)
• valueField (default = ID)
It also contains the following subelements of its own, each of which can exist, at most, one time:
• constant-map
• subtype-map
• typelist-map
See “Subtype mapping associative arrays” on page 227 for more information.
tag See “<tag>” on page 219.

<column>
The <column> element defines a single-value field in the entity.
Note: For a discussion of <column-override>, see “Working with attribute and element overrides” on
page 243 for details.

Attributes of <column>
The <column> element contains the following attributes:

<column> attribute Description Default

allowInitialValueForUpgrade Internal use. false

autoincrement The name of a database sequence used as the source of values for the None
column. This attribute is applicable only for integer columns, and only
for implementations where PolicyCenter relies on the database for the
sequence. Do not use the same sequence in more than one
autoincrement column. There can be at most one autoincrement col‐
umn per table.
columnName Optional. If specified, PolicyCenter uses this value as the column name None
of the corresponding database column. If you do not specify a
columnName value, then PolicyCenter uses the value of the name attrib‐
ute for the database column name.
The columnName attribute must be no more than 30 characters in
length. It allows only unaccented Roman letters, numbers, and the un‐
derscore character. The first character of the columnName attribute
must be a letter. Although the underscore character is allowable here,
Guidewire discourages its use.

202 chapter 15: The PolicyCenter data model

 Guidewire PolicyCenter 9.0.9 Configuration Guide

<column> attribute Description Default

IMPORTANT All column names on a table must be unique within that
table. Otherwise, Guidewire Studio™ displays an error if you verify the
resource and the application server fails to start.
createhistogram Whether to create a histogram on the column during an update to the false
database statistics.
Note: It is possible to override this attribute on an existing column in an
extension (*.etx) file using the <column-override> element. You can
use the override to turn off an existing histogram or to create one that
did not previously exist.
This change does not take effect during an upgrade. The change occurs
only if you regenerate statistics for the affected table by using the
Guidewire maintenance_tools command.
See also
• “Working with attribute and element overrides” on page 243
• System Administration Guide
default Default value given to the field during new entity creation. None
Note: For columns with the datetime data type, see Integration
Guide for the syntax to use for the value of the default attribute.
deprecated If true, then PolicyCenter marks the item as deprecated in the Data false
Dictionary and places a Deprecated annotation on it in the Guidewire
Studio API Reference.
If you deprecate an item, use the description to explain why.
For more information, see “Data entity subelements” on page 198.
desc A description of the purpose and use of the field. None
exportable Unused.
getterScriptability See “Data objects and scriptability” on page 178 for information. all

ignoreforevents If you change (or add, or remove) an entity X that does not generate false
events, then PolicyCenter searches for all event‐generating entity in‐
stances that specify X. If PolicyCenter finds any of these event‐
generating entity instances, it generates Changed events for those enti‐
ty instances.
To determine what entities reference a non‐event‐generating entity,
PolicyCenter examines the foreign keys and arrays that point to the en‐
tity. However, if you set ignoreForEvents to true on an entity that ref‐
erences the non‐event‐generating entity, then PolicyCenter ignores
that link as it determines what entities specify another entity.
• At the entity level, the ignoreForEvents attribute means changes
to (or addition or removal of) this entity do not cause Changed
events to fire for any other entity.
• At the column level, the ignoreForEvents attribute means changes
to this column do not cause the application to generate events.
loadable If true, you can load the field through staging tables. A staging table true
can contain a column mapping to the field.
loadedByCallback Internal. If true, then the loading code does not use a default value or false
report a warning if the column is nullable without a default.
name Required. The name of the column on the table and the field, or prop‐ None
erty, on the entity. PolicyCenter uses this value as the column name
unless you specify a columnName attribute. Use this name to access the
column in data views, rules, and other areas within PolicyCenter.

The PolicyCenter data model 203

Guidewire PolicyCenter 9.0.9 Configuration Guide

<column> attribute Description Default

IMPORTANT All column names on a table must be unique within that
table. Otherwise, Studio displays an error if you verify the resource and
the application server fails to start.
nullok Whether the column can contain null values. true
In general, this attribute is always true, as many tables include columns
that do not require a value at different points in the process.
overwrittenInStagingTable Internal. If true and the entity is loadable, the loader process auto‐ false
populates the staging table during import.
IMPORTANT If set to true, do not attempt to populate the table your‐
self as the loader import process overwrites this table.
required Whether the column is required to be non‐null upon initial construc‐ false
tion of instances of the entity. See the Gosu Reference Guide.
scalable Whether this value scales as the effective and expired dates change. false
This attribute applies only to number‐type values. For example, you
cannot scale a varchar. Also, it only applies to effective dated types.
setterScriptability See “Data objects and scriptability” on page 178 for information. all

soapnullok Unused.
supportsLinguisticSearch Applies only to columns of varchar‐based data types. false
• If true, case insensitive searches can be performed on the
denormalized version of the column.
• If false, searches are binary and cannot be performed on a
denormalized version of the column.
You cannot use this attribute with an encrypted column.
The setting of this attribute does not affect locale or language used in
searches.
See also
• “Including data from subentities” on page 150
• Globalization Guide
type Required. Data type of the column, or field. In the base configuration, None
Guidewire defines a number of data types and stores their metadata
definition files (*.dti) in under configuration→config→datatypes.
Each metadata definition file name is the name of a specific data type.
You use one of these data types as the type attribute on the <column>
element. Thus, the list of valid values for the type attribute is the same
as the set of .dti files in the application datatypes folders.
Each metadata definition also defines the value type for that data type.
The value type determines how PolicyCenter treats that value in mem‐
ory.
The name of the data type is not necessarily the same as the name of
its value type. For example, for the bit data type, the name of the data
type is bit and the corresponding value type is [Link].
Similarly, the data type varchar has a value type of [Link].
The datetime data type is a special case. PolicyCenter persists this data
type in the application database using the database data type
TIMESTAMP. This corresponds to the value type [Link]. In
other words:
• PolicyCenter represents a column whose type is datetime in
memory as instances of [Link].
• PolicyCenter stores this type of value in the database as TIMESTAMP.

204 chapter 15: The PolicyCenter data model

 Guidewire PolicyCenter 9.0.9 Configuration Guide

<column> attribute Description Default

Note: Guidewire does not support the unlimiteddecimal data type
in a persistent data model configuration.
See also
• “Data types” on page 283
• “Customizing base configuration data types” on page 287
• “Define a new data type” on page 291

Subelements of <column>
The <column> element contains the following subelements:

<column> subelement Description Default

columnParam See “<columnParam> subelement” on page 205. None
fulldescription See “<fulldescription>” on page 214. None
localization See “<localization> subelement” on page 206. None
tag See “<tag>” on page 219. None

<columnParam> subelement
You use the <columnParam> element to set parameters that a column type requires. The type attribute of a column
determines which parameters you can set or modify by using the <columnParam> subelement. You can determine the
list of parameters that a column type supports by looking up the type definition in its .dti file.
For example, if you have a mediumtext column, you can determine the valid parameters for that column by
examining file [Link]. This file indicates that you can modify the following attributes of a mediumtext
column:
• encryption
• logicalSize
• trimwhitespace
• validator
Because you cannot modify the base configuration data type declaration files, you cannot see these files in
Guidewire Studio. To view these files, navigate to the directory modules/configuration/config/datatypes.
The following example, from [Link] in PolicyCenter, illustrates how to use this subelement to define certain
column parameters.
<?xml version="1.0"?>
<entity xmlns="[Link]
desc="An account is ..."
entity="Account"
...
table="account"
type="retireable">
...
<column desc="Business and Operations Description."
name="BusOpsDesc"
type="varchar">
<columnParam name="size" value="240"/>
</column>
...
</extension>

Parameters that you can define by using <columnParam>

The following list describes the parameters that you can define by using <columnParam>, depending on which
parameters are listed as valid in the .dti file of the data type.
The PolicyCenter data model 205
Guidewire PolicyCenter 9.0.9 Configuration Guide

Parameter Description
countryProperty Name of a property on the owning entity that returns the country to use for localizing the data
format for this column.
createSpatialIndex Applies to columns with a spatial point data field. If the createSpatialIndex parameter has
the default value of true in a column of an extension or custom entity, PolicyCenter creates an
index for spatial point data. If the parameter has a value of false, PolicyCenter does not create
such an index. In this case, PolicyCenter avoids creating an index regardless of whether the pa‐
rameter is in a <columnParam> subelement of a <column> element or a <column-override>
element.
currencyProperty Name of a property on the owning entity that returns the currency for this column.
encryption Whether PolicyCenter stores this column in encrypted format. This only applies to text‐based
columns.
Guidewire allows indexes on encrypted columns, or fields. However, because Guidewire stores
encrypted fields as encrypted in the database, you must encrypt the input string and search for
an exact match to it.
exchangeRateProperty Name of a property on the owning entity that returns the exchange rate to use during currency
conversions.
extensionProperty The name of a property on the owning entity whose value contains the phone extension.
logicalSize The size of this field in the PolicyCenter interface. You can use this value for String columns
that do not have a maximum size in the database, such as CLOB objects. If you specify a value
for the size parameter, then the logicalSize value must be less than or equal to the value of
that parameter.
phonecountrycodeProperty The name of a property on the owning entity whose value contains the country with which to
validate and format values.
precision The precision of the field. Precision is the total number of digits in the number. The precision
parameter applies only if the data type of the field allows a precision attribute.
scale The scale of the field. Scale is the number of digits to the right of the decimal point. The scale
parameter applies only if the data type of the field allows a scale attribute.
secondaryAmountProperty Name of a property on the owning entity that returns the secondary amount related to this cur‐
rency amount column.
size Integer size value for columns of type TEXT and VARCHAR. This parameter specifies the maxi‐
mum number of characters, not bytes, that the column can hold.
WARNING The database upgrade utility automatically detects definitions that lengthen or short‐
en a column. For shortened columns, the utility assumes that you wrote a version check or oth‐
erwise verified that the change does not truncate existing column data. For both Oracle and
SQL Server, if shortening a column causes the truncation of data, the ALTER TABLE statement in
the database fails and the upgrade utility fails.
trimwhitespace Applies to text‐based data types. If true, then PolicyCenter automatically removes leading and
trailing white space from the data value.
validator The name of a ValidatorDef in [Link]. See “<ValidatorDef>” on page 298.

See also

• See “Overriding data type attributes” on page 244 for an example of using a nested <columnParam> subelement
within a <column-override> element to set the encryption attribute on a column.

<localization> subelement
For a discussion of the column <localization> element with examples on how to use it, see the Globalization
Guide.

206 chapter 15: The PolicyCenter data model

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Attributes of <localization>

The <localization> element contains the following attributes:

<localization> attrib‐ Description Default

ute
extractable Whether the localized data entity is marked as Extractable for archiving. false

nullok Required. Whether null values are allowed. None

overlapTable Whether the localized data entity implements the OverlapTable delegate and is marked false
as OverlapTable for archiving.
tableName The table name of the localized data table. None
unique Required. Whether values must be unique. false

<edgeForeignKey>
You use the <edgeForeignKey> element to define a reference to another entity, in a manner similar to the
“<foreignkey>” on page 211 element. However, you use an edge foreign key in place of a standard foreign key to
break a cycle of foreign keys in the data model. Guidewire defines this element in the data model metadata files as
the <edgeForeignKey> XML subelement.

The data model and circular references

A chain of foreign keys can form a cycle, also known as a circular reference, in the data model. As an example of a
circular reference, entity type A has a foreign key to entity type B, and B has a foreign key to A. Circular references
can occur with more extensive chains of foreign keys, such as A refers to B, which refers to C, which refers to A.
The PolicyCenter data model does not permit circular foreign keys reference, because PolicyCenter cannot
determine a safe order for committing the entity instances in a circular reference to the database.
For example, entity types A and B have foreign key references to each other. The foreign keys create a circular
reference. Suppose that a bundle contains a new instance of A and a new instance of B. The circular reference would
cause a foreign key constraint to fail upon committing the bundle. If PolicyCenter commits A before B is committed
and in the database, a constraint failure occurs on the foreign key from A to B. The converse order of committing B
before A causes a similar failure.
An edge foreign key in place of a standard foreign key resolves circular references so PolicyCenter can determine a
safe order for committing the entity instances within a cycle. An edge foreign key from A to B introduces a new,
hidden associative entity with a foreign key to A and a foreign key to B. The edge foreign key associates A and B
without establishing foreign keys in the database directly between them. With an edge foreign key, PolicyCenter can
safely first commit new object A, then new object B, and finally the edge foreign key instance.

Edge foreign keys in entity database tables

Unlike a standard foreign key, an edge foreign key does not correspond to an actual column in the database table of
an entity type. Nor does an edge foreign key implement a database foreign key constraint. However, the
PolicyCenter Data Dictionary labels edge foreign keys as standard foreign keys. In Gosu code, you access edge
foreign keys in the same manner that you access standard foreign keys.

Edge foreign keys and associative database tables

An edge foreign key creates an associative table in the database. An associative table is essentially a table of foreign
keys relationships. An associative table associates other database tables with each other but holds no other essential
business data itself.

The PolicyCenter data model 207

Guidewire PolicyCenter 9.0.9 Configuration Guide

In PolicyCenter, the associative table that implements an edge foreign key has two columns:
• OwnerID
• ForeignEntityID
If entity instance A has an edge foreign key to entity type B, PolicyCenter creates a row in the edge foreign key
table. The value in the row for OwnerID points to A and the value for ForeignEntityID points to B.
Every time you traverse, or dereference, the edge foreign key, PolicyCenter loads the join array.
• If the array is of size 0, then the value of the edgeForeignKey is null.
• If the array is of size 1, the PolicyCenter follows the ForeignEntityID on the row.

IMPORTANT When you change a foreign key to an edge foreign key, you must write an upgrade
trigger to populate the edge table for existing data. Otherwise, the associative edge table will remain
empty even upon a database upgrade. Moreover, when you reference the edge foreign key, you will
receive a null value.

Edge foreign keys in Gosu

In Gosu code, edge foreign keys work in a manner similar to standard foreign keys. Just like a standard foreign key,
you can query an edge foreign key and get and set its attributes.

Edge foreign keys and performance

An edge foreign key has more performance issues than a standard foreign key, because PolicyCenter must manage a
separate table for the relationship. Queries must join an extra table. Nullability constraints in the database do not
work with edge foreign keys, so you must enforce nullability constraints with extra Gosu code the you develop.

Edge foreign keys and archiving

If you add an edge foreign key to an entity that is part of the archive domain graph, set the extractable attribute on
the edge foreign key to true. The value true causes PolicyCenter to add the Extractable delegate to the
associative table generated for the edge foreign key. If the extractable attribute of an edge foreign key on an entity
that is part of the archive domain graph is not set to true, the server will not start. In addition, the entity type that
the edge foreign key relates to must implement the Extractable delegate.

See also
• “The PolicyCenter archive domain graph” on page 325

When to use edge foreign keys

Use an edge foreign key only to avoid circular foreign key references in the data model. Circular foreign key
references can prevent PolicyCenter from determining a safe order for committing the entity instances in a circular
reference to the database.
Use an edge foreign key instead of a standard foreign key in the following situations:
• An entity type has self-referencing foreign keys, including foreign keys between subtypes.
• A Group entity must specify its parent group.
• Entity type A has a foreign key to B, and entity type B has a foreign key to A.
• Cycles that involve more that two entity types.
• The primary member of an array requires a foreign key to its owner.
Note: <edgeForeignKey> is a valid subelement for all entity types, including entity extension types.

Attributes of <edgeForeignKey>
The <edgeForeignKey> element contains the following attributes.
208 chapter 15: The PolicyCenter data model
 Guidewire PolicyCenter 9.0.9 Configuration Guide

<edgeForeignKey> attribute Description Default

createhistogram Whether to create a histogram on the column during an update to the data‐ false
base statistics.
Note: It is possible to override this attribute on an existing column in an ex‐
tension (*.etx) file using the <column-override> element. You can use the
override to turn off an existing histogram or to create one that did not previ‐
ously exist.
This change does not take effect during an upgrade. The change occurs only if
you regenerate statistics for the affected table by using the Guidewire
maintenance_tools command.
See also
• “Working with attribute and element overrides” on page 243
• System Administration Guide
deprecated If true, then PolicyCenter marks the item as deprecated in the Data Diction‐ false
ary and places a Deprecated annotation on it in the Guidewire Studio API Ref‐
erence.
If you deprecate an item, use the description to explain why.
For more information, see “Data entity subelements” on page 198.
desc A description of the purpose and use of the edge foreign key. None
edgeTableEntityName The name of the edge table entity. If you do not specify a name, then None
PolicyCenter creates one automatically by taking the edgeTableName attribute
and capitalizing the first letter. If the edgeTableName contains an underscore,
then all text up to and including the first underscore is discarded, and the first
letter after the underscore is capitalized.
edgeTableName Required. The name of the edge, or join array, table to create. As with other None
entity table names, the edgeTableName does not require a prefix such as pc_.
exportable Unused.
exportasid Unused.
extractable Whether the edge entity is marked Extractable for archiving. false

fkentity Required. The entity to which this foreign key points. None
getterScriptability See “Data objects and scriptability” on page 178 for information. all

ignoreforevents This attribute has complex, non‐intuitive interactions with data entity rela‐ false
tionships. See “Interactions of ignoreForEvents attribute with data entity rela‐
tionships” on page 221 for information on how to use and configure it.
importableagainstexistingobject If true and the entity is importable, or loadable, then the value in the staging true
table can be a reference to an existing object. This reference is the publicID
of a row in the source table for the referenced object.
loadable If true, then PolicyCenter creates a staging table for the edge table. false

loadedByCallback Internal. If true, then the loading code does not use a default value or report a false
warning if the column is nullable without a default.
name Required. Specifies the name of the property on the entity. None
nullok Whether the column can contain null values. This value is meaningless for true
edgeForeignKey objects.

overlapTable Whether the edge entity implements the OverlapTable delegate and is false
marked OverlapTable for archiving.
overwrittenInStagingTable Internal. If true and the edge table is loadable, the loader process auto‐ false
populates the staging table during import.

The PolicyCenter data model 209

Guidewire PolicyCenter 9.0.9 Configuration Guide

<edgeForeignKey> attribute Description Default

IMPORTANT If set to true, do not attempt to populate the table yourself, as
the loader import process overwrites this table.
setterScriptability See “Data objects and scriptability” on page 178 for information. all

soapnullok Unused.

Subelements of <edgeForeignKey>
<edgeForeignKey> subelement Attributes Description
fulldescription None See “<fulldescription>” on page 214.
tag None See “<tag>” on page 219.

<events>
If the <events> element appears within an entity, that entity and its descendant entities raise events. The names of
the standard events are XXAdded, XXChanged, and XXRemoved, where XX is the name of the entity declaring the
<events> element. A subtype or descendant of an event-aware entity can override the names of the standard events
by declaring its own <events> element. The descendant can also add additional events.
If the <events> element does not appear in an entity or any of its ancestors, that entity does not raise any events.
Note: This element is not valid for a nonPersistentEntity.
Guidewire defines this element in the data model metadata files as the <events> XML subelement. There can be at
most one <events> element in an entity. However, you can specify additional events through the use of <event>
subelements. For example:
<events>
<event>
...
</events>

Note: PolicyCenter automatically adds the EventAware delegate to any entity that contains the
<events> element. This addition makes such an entity aware of events that it raises and that other
entities raise.

Attributes of <events>

There are no attributes on the <events> element.

Subelements of <events>

The <events> element contains the following subelements.

<events> sub‐ Description

element
event Defines an additional event to fire for the entity. Use multiple <event> elements to specify multiple events.
This subelement contains the following attributes:
• description (required = true)
• name (required = true)
The <event> element requires each of these attributes.
Note that the event name is exposed as a public static constant field. For example, you might have an event
named PersonalDataPurge on the ABContact data entity. Such an event is exposed publicly as a constant
field on the ABContact class. The public class‐level String constant is
ABContact.PERSONALDATAPURGE_EVENT.

210 chapter 15: The PolicyCenter data model

 Guidewire PolicyCenter 9.0.9 Configuration Guide

<foreignkey>
The <foreignkey> element defines a foreign key reference to another entity.

Attributes of <foreignkey>

The <foreignkey> element contains the following attributes.

<foreignkey> attribute Description Default

archivingOwner By default, a foreign key implies a relationship that the link target owns the target
source of the foreign key. Use the archivingOwner attribute to change the
direction of this ownership relationship.
This attribute can be set to one of the following:
• none – There is no ownership relationship between the source and the
target of the link.
• source – The source of the foreign key owns the link.
• target – The target of the foreign key owns the link.
columnName Optional. If specified, PolicyCenter uses this value as the column name of the None
corresponding database column. If you do not specify a columnName value,
then PolicyCenter uses the value of the name attribute for the database col‐
umn name.
The columnName attribute must be no more than 30 characters in length. It al‐
lows only unaccented Roman letters, numbers, and the underscore character.
The first character of the columnName attribute must be a letter. Although the
underscore character is allowable here, Guidewire discourages its use.
Note: As a common and recommended practice, use the suffix ID for the col‐
umn name. For example, for a foreign key with the name Policy, set the
columnName to PolicyID.
Guidewire does not require that you use an ID suffix on names of foreign key
columns. However, Guidewire strongly recommends that you adopt this prac‐
tice to help you analyze the database and identify foreign keys.
IMPORTANT All column names on a table must be unique in that table. Other‐
wise, Guidewire Studio™ displays an error if you verify the resource, and the
application server fails to start.
createConstraint If true, the database creates a foreign key constraint for this foreign key. true

createbackingindex If true, the database automatically creates a backing index on the foreign key. true
If set to false, the database does not create a backing index.
createhistogram Whether to create a histogram on the column during an update to the data‐ false
base statistics.
Note: It is possible to override this attribute on an existing column in an ex‐
tension (*.etx) file using the <column-override> element. You can use the
override to turn off an existing histogram or to create one that did not previ‐
ously exist.
This change does not take effect during an upgrade. The change occurs only if
you regenerate statistics for the affected table by using the Guidewire
maintenance_tools command.
See also
• “Working with attribute and element overrides” on page 243
• System Administration Guide
deprecated If true, then PolicyCenter marks the item as deprecated in the Data Diction‐ false
ary and places a Deprecated annotation on it in the Guidewire Studio API Ref-
erence.
If you deprecate an item, use the description to explain why.
For more information, see “Data entity subelements” on page 198.

The PolicyCenter data model 211

Guidewire PolicyCenter 9.0.9 Configuration Guide

<foreignkey> attribute Description Default

desc A description of the purpose and use of the field. None
existingreferencesallowed If the following attributes are set to false, which is not the default: true
• loadable
• importableagainstexistingobject
then, the value in the staging table can only be a reference to an existing ob‐
ject.
exportable Unused.
exportasid Unused.
fkentity Required. The entity to which this foreign key refers. None
getterScriptability See “Data objects and scriptability” on page 178 for information. all

ignoreforevents This attribute has complex, non‐intuitive interactions with data entity rela‐ false
tionships. See “Interactions of ignoreForEvents attribute with data entity rela‐
tionships” on page 221 for information on how to use and configure it.
importableagainstexistingobject If true and the entity is importable (loadable), then the value in the staging true
table can be a reference to an existing object. (This is the publicID of a row in
the source table for the referenced object.)
includeIdInIndex If true, then include the ID as the last column in the backing index for the for‐ false
eign key.
This is useful if the access pattern in one or more important queries is to join
to this table through the foreign key. You can then use the ID to probe into a
referencing table. The only columns that you need to access from the table
are this foreign key, and the retired and ID columns.
In that case, adding the ID column to the index creates a covering index and
eliminates the need to access the table.
loadable If true, you can load the field through staging tables. A staging table can con‐ true
tain a column for the public ID of the referenced entity.
loadedByCallback Internal. If true, then the loading code does not use a default value or report a false
warning if the column is nullable without a default.
name Required. Specifies the name of the property on the entity. None
nonEffDated Internal. This applies only to a foreign key that points to an effdated entity. If false
a foreign key points to an effdated entity and this attribute is true, then
PolicyCenter creates a real foreign key between the source and target entities.
nullok Whether the field can contain null values. true

overwrittenInStagingTable Internal. If true (and the table is loadable), it indicates that the loader process false
auto‐populates the staging table during import.
IMPORTANT If set to true, do not attempt to populate the table yourself be‐
cause the loader import process overwrites this table.
required Whether the foreign key is required to be non‐null upon initial construction of false
instances of the entity. See the Gosu Reference Guide.
setterScriptability See “Data objects and scriptability” on page 178 for information. all

soapnullok Unused.
triggersValidation Whether changes to the entity referred to by this foreign key trigger valida‐ false
tion.

Subelements of <foreignkey>

The <foreignkey> element contains the following subelements.

212 chapter 15: The PolicyCenter data model
 Guidewire PolicyCenter 9.0.9 Configuration Guide

<foreignkey> subelement Attributes Description

fulldescription None See “<fulldescription>” on page 214.
tag None See “<tag>” on page 219.

Entity properties for foreign keys between effdated entities

The foreign key of an entity having the effdated type matches a different property on the entity to which the
foreign key refers than most foreign keys. Most foreign keys refer to and match on the value of another object's ID
property. By contrast, PolicyCenter compares the foreign key, the BranchValue property, and the SliceDate
property of an effdated entity with four properties of a referenced entity. These four comparisons result in the
source entity instance of the foreign key matching at most one target entity instance.
The target entity properties in the four comparisons are FixedID, BranchValue, EffectiveDate, and
ExpirationDate. The comparisons for the FixedID and BranchValue properties on the source and target entities
require exact matches. The comparison for the EffectiveDate property on the target entity requires the value of the
SliceDate property on the source entity to be greater than or equal to the value of the EffectiveDate property on
the target entity. The comparison for the ExpirationDate property requires the value of the SliceDate property to
be less than the value of the ExpirationDate property.
PolicyCenter restricts effdated entity instances with the same FixedID and BranchValue property values from
having overlapping effective date ranges or EffectiveDate and ExpirationDate pairs. As a result, through the
sequence of property comparisons, the source entity instance of the foreign key will match no more than one target
entity instance.
The following table provides information about these target entity properties as well as the SliceDate property for
the source entity:

Property Type Meaning

FixedID Integer Identifies a single object across effective date periods, both:
• Within the same period but with different effective dates
• Across multiple periods but in one contractual policy period
This value must be non‐null.
BranchValue Integer Note: At the database layer, BranchValue is the BranchID column.
Foreign key to the entity instance that contains this entity instance. Within the same branch, all
entities must share the same BranchValue value. This value must be non‐null. This is a read‐only
property.
From Gosu, the foreign key property appears as the BranchValue property, although the data‐
base column name for that property is actually BranchID.
EffectiveDate Date Date the entity instance becomes effective. A null value means that the entity instance is effec‐
tive at the start of the period.
ExpirationDate Date Date the entity instance expires or is no longer effective. A null value means that the entity in‐
stance expires at the end of the period.
SliceDate Date The slice date is the current view, or slice, of the branch (and its entities) in effective time. If the
slice date is null, the branch is being viewed/edited in window mode. Any edits made with the
slice date set are made in that effective time, splitting the entity instance if necessary. This is a
read‐only property. To get this PolicyPeriod at a different slice date, use the getAsOf method.
Note: PolicyCenter never persists the slice date value itself in the database. The slice date
property exists as a special property on the in‐memory entity instance that Gosu can access.

See also
• Application Guide

The PolicyCenter data model 213

Guidewire PolicyCenter 9.0.9 Configuration Guide

<fulldescription>
PolicyCenter uses the fulldescription subelement to populate the Data Dictionary. For example:
<fulldescription>
<![CDATA[<p>Aggregates the information needed to display one activity row
(base entity for all other activity views).</p>]]>
</fulldescription>

<implementsEntity>
The <implementsEntity> subelement specifies that an entity implements the specified delegate. Guidewire calls an
entity an implementor of a delegate if the entity specifies the delegate in a <implementsEntity> subelement.

IMPORTANT Do not change the delegate that a Guidewire base entity implements by creating an
extension entity that includes an “<implementsEntity>” on page 214 subelement. PolicyCenter
generates an error if you do.

If a delegate definition includes the optional requires attribute, then the implementor must provide an adapter
attribute on its <implementsEntity> subelement. The adapter attribute specifies the name of a Java or Gosu type
that implements the interface that the delegate definition specifies in its own requires attribute.
For example, the PolicyCenter base configuration defines a Cost delegate as follows:
<?xml version="1.0"?>
<delegate ... name="Cost" requires="[Link]">
...
</delegate>

The base configuration defines a BACost entity that includes an <implementsEntity> subelement, which specifies
delegate with name="Cost". Therefore, the BACost entity is an implementor of the Cost delegate.
<?xml version="1.0"?>
<entity ... entity="BACost" ... >
...
<implementsEntity name="Cost" adapter="[Link]" />
...
</entity>

The Cost delegate requires an implementation of the CostAdapter interface. So in its adapter attribute, the BACost
entity specifies a BACostAdapter class, which implements the CostAdapter interface that the Cost adapter specifies
in its requires attribute. The following diagram illustrates the relationship between the Cost delegate and the
BACostAdapter adapter class:

Delegate / Adapter Relationship Example

Cost CostAdapter
Delegate Interface

BACost BACostAdapter
Delegate Entity Interface
Implementor / Implementor
Indirect Interface
Implementor

214 chapter 15: The PolicyCenter data model

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Follow these rules for defining entities that implement delegates:

• If you specify a value for the requires attribute in a delegate, then implementers of the delegate must specify an
adapter attribute in their definitions. The adapter attribute must specify the name of a Java or Gosu type that
implements the interface specified by the requires attribute in delegate definition.
• If you do not specify a value for the requires attribute in a delegate, then implementers of the delegate must not
specify an adapter attribute their definitions.

The Extractable Delegate

Entities that are part of the archive domain graph must implement the Extractable delegate. For example, if you
create a custom subtype of Contact, then the custom subtype must implement the Extractable delegate.
If you add an edge foreign key to an entity that is part of the archive domain graph, set the extractable attribute on
the edge foreign key to true. The value true causes PolicyCenter to add the Extractable delegate to the
associative table generated for the edge foreign key.

Attributes of <implementsEntity>
The <implementsEntity> element contains the following attributes.

<implementsEntity> subelement Description

name Required. The name of the delegate that this entity must implement.

Subelements of <implementsEntity>
There are no subelements on the <implementsEntity> subelement.

<implementsInterface>
The <implementsInterface> subelement specifies that an entity implements the specified interface. This element
defines two attributes: an interface (iface) attribute and an implementation (impl) attribute.
For example, the PolicyCenter base configuration defines the BACost entity with the following
<implementsInterface> subelement:
<entity ... entity="BACost" ...>
...
<implementsInterface
iface="[Link]"
impl="[Link]"/>
</entity>

The BACostMethods interface has getter methods that any class that implements this interface must provide. The
getter methods are coverage, state, and vehicle. By including the <implementsInterface> subelement, the BACost
entity lets you use getter methods on instances of the BACost entity in Gosu code.
var cost : BACost
var cov = [Link]
var state = [Link]
var vehicle = [Link]

Attributes of <implementsInterface>
The <implementsInterface> element contains the following attributes.

<implementsInterface> attribute Description

iface Required. The name of the interface that this data object must implement.
impl The name of the class or subclass that implements the specified interface, if any. Valid
only when declared on abstract entities or delegates.

The PolicyCenter data model 215

Guidewire PolicyCenter 9.0.9 Configuration Guide

Subelements on <implementsInterface>
There are no subelements on the <implementsInterface> subelement.

<index>
The <index> element defines an index on the database table used to store the data for an entity. Guidewire defines
this element in the data model metadata files as the <index> XML subelement. This element contains a required
subelement, which is <indexcol>.
The <index> element instructs PolicyCenter to create an index on the physical database table. This index is in
addition to those indexes that PolicyCenter creates automatically.
An index improves the performance of a query search within the database. It consists of one or more fields that you
can use together in a single search. You can define multiple <index> elements within an entity, with each one
defining a separate index. If a field is already part of one index, you do not need to define a separate index
containing only that field.
For example, PolicyCenter frequently searches non-retired accounts for one with a particular account number.
Therefore, the Account entity defines an index containing both the Retired and AccountNumber fields. However,
another common search uses just AccountNumber. Since that field is already part of another index, a separate index
containing only AccountNumber is unnecessary.
A column used in an index cannot have a length of more than 1000 characters.

IMPORTANT In general, the use of a database index has the possibility of reducing update
performance. Guidewire recommends that you add a database index with caution. In particular, do not
attempt to add an index on a column of type CLOB or BLOB. If you do so, PolicyCenter generates an
error message upon resource verification.

Attributes of <index>
The <index> element contains the following attributes.

<index> attribute Description Default

desc A description of the purpose and use of the index. None
expectedtobecovering If true, it indicates that the index covers all the necessary columns for a table that is to be false
used for at least one operation. For example, search by name is one such operation.
Thus, if true, it indicates that there is to be no table lookup. In this case, use the desc
attribute to indicate which operation that is.
name Required. The name of the index. The first character of the name must be a letter. The None
maximum length for an index name is 18 characters.
IMPORTANT For <subtype> definitions, all index names must be unique between the sub‐
type and supertype. In other words, do not duplicate an index name between the subtype
definition in the extensions folder and its supertype in the metadata folder. Otherwise,
PolicyCenter generates an error on resource verification.
trackUsage If true, track the usage of this index. true

unique Whether the values of the index are unique for each row. false
Note:
When you set the unique attribute to true for an index on a subtype entity, PolicyCenter
generally sets the attribute to false upon index generation. In this case, the database
does not define the index as unique. Rather, PolicyCenter uses an integrity check to en‐
sure that you do not add duplicates through the staging tables and a consistency check to
highlight past duplicates.
Exceptional cases arise if the unique attribute is true and either the index consists of on‐
ly a single column or the index has an ID column. In these cases, the database defines the
index as unique.

216 chapter 15: The PolicyCenter data model

 Guidewire PolicyCenter 9.0.9 Configuration Guide

<index> attribute Description Default

verifyInLoader If true, then PolicyCenter runs an integrity check for unique indexes before loading data true
from the staging tables.

Subelements of <index>
The <index> element contains the following subelements.

<index> sub‐ Description De‐

element fault
forceindex Use to force PolicyCenter to create an index if running against a particular database. None
This subelement is useful because the index generation algorithm can throw away some declared in‐
dexes as being redundant. In some cases, PolicyCenter can require one or more of those indexes to
work around an optimization problem.
This subelement contains the following attributes:
• oracle – If true, force the creation of an index if running against an Oracle database.
• sqlserver – If true, force the creation of an index if running against a Microsoft SQL Server
database.
indexcol Required. Defines a field that is part of the index. You can specify multiple <indexcol> elements to None
define composite indexes. This subelement contains the following attributes:
• keyposition – Required. The position of the field within the index. The first position is 1.
• name – Required. The column name of the field. This name can be a column, foreignkey, or
typekey defined in the entity.
• sortascending – If true, the default, then the sort direction is ascending. If false, then the sort
direction is descending.
The column cannot have a length of more than 1000 characters.

<onetoone>
The <onetoone> element defines a single-valued association to another entity that has a one-to-one cardinality.
Guidewire defines this element in the data model metadata files as the <onetoone> XML subelement. A one-to-one
element functions in a similar manner to a foreign key in that it makes a reference to another entity. However, its
purpose is to provide a reverse pointer to an entity or object that is pointing at the <onetoone> entity, through the
use of a foreign key.
For example, entity A has a foreign key to entity B. You can associate an instance of B with at most one instance of
A. Perhaps, there is a unique index on the foreign key column. This then defines a one-to-one relationship between
A and B. You can then declare the <onetoone> element on B, to provide simple access to the associated A. In
essence, using a one-to-one element creates an array-of-one, with, at most, one element. Zero elements are also
possible.
Note: PolicyCenter labels one-to-one elements in the Guidewire Data Dictionary as foreign keys. You
access these elements in Gosu code in the same manner as you access foreign keys.

Attributes of <onetoone>
The <onetoone> element contains the following attributes.

<onetoone> attribute Description Default

cascadeDelete If true, then PolicyCenter deletes the entity to which the <onetoone> element points if false
you delete this entity.
deprecated If true, then PolicyCenter marks the item as deprecated in the Data Dictionary and places false
a Deprecated annotation on it in the Guidewire Studio API Reference.
If you deprecate an item, use the description to explain why.

The PolicyCenter data model 217

Guidewire PolicyCenter 9.0.9 Configuration Guide

<onetoone> attribute Description Default

For more information, see “Data entity subelements” on page 198.
desc A description of the purpose and use of the field. None
exportable Unused.
fkentity Required. The entity to which this foreign key points. None
getterScriptability See “Data objects and scriptability” on page 178 for information. all

ignoreForEvents This attribute has complex, non‐intuitive interactions with data entity relationships. See false
“Interactions of ignoreForEvents attribute with data entity relationships” on page 221 for
information on how to use and configure it.

IMPORTANT Do not confuse the definition of the ignoreForEvents attribute for the
<onetoone> element with the definition of the attribute of the same namesake in
<entity> and <array> elements. Although they share the same name, the two
ignoreForEvents attributes are near opposites in effect.

linkField Optional. Specifies the foreign key field that points back to this object. None
name Required. Specifies the name property on the entity. None
nullok Whether the field can contain null values. true

owner If true, this entity owns the linked object (the object to which the <onetoone> element false
points):
• If you delete the owning object, then PolicyCenter deletes the linked object as well.
• If you update the object pointed to by the <onetoone> element, then PolicyCenter
considers the owning object updated as well.
setterScriptability See “Data objects and scriptability” on page 178 for information. all

triggersValidation Whether changes to the entity pointed to by this entity trigger validation. false

Subelements of <onetoone>
The <onetoone> element contains the following subelements.

<onetoone> subelement Description Default

fulldescription See “<fulldescription>” on page 214. None
tag See “<tag>” on page 219. None

<remove‐index>
The <remove-index> element defines the name of a database index that you want to remove from the data model. It
is valid for use with the following data model elements:
• <entity>
• <extension>
You can use this element to safely remove a non-primary key index if it is one of the following:
• non-unique
• unique and contains an ID column
Guidewire performs metadata validation to ensure that the <remove-index> element removes only those indexes
that fall into one of these categories.

218 chapter 15: The PolicyCenter data model

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Note: Adding, removing, or changing indexes results in changes to server performance. Before
making modifications to indexes, consult with your database administrator or Guidewire
representative. Include performance testing in your modification plan.
Note: The <remove-index> element does not remove spatial point indexes. To remove a spatial point
index for an extension entity, override a spatial point <column> element with a createSpatialIndex
parameter having a value of false.
See “Overriding data type attributes” on page 244 for an example of using a nested <columnParam>
subelement within a <column-override> element to set an attribute on a column. Use the same
pattern to set the createSpatialIndex parameter to false and to remove a spatial point index for an
extension entity. See also “<columnParam> subelement” on page 205 for a description of the
createSpatialIndex parameter.

The index is non‐unique

You can safely remove a non-primary key index with the unique attribute set to false. In general, these are indexes
that Guidewire provides for performance enhancement. It is safe to remove these kinds of indexes.

The index is unique and contains an ID column

You can safely remove a non-primary key index with the unique attribute set to true if that index also includes ID
as a key column. An ID column is already unique by itself, and so a multicolumn index that includes the ID column
does not enforce a uniqueness condition. Thus, it is safe to remove these kinds of indexes.
For example, the WorkItem entity contains the following index definition:
<index desc="Covering index to speed up checking-out of work items and they involve search on status"
name="WorkItemIndex2" unique="true">
<indexcol keyposition="1" name="status"/>
<indexcol keyposition="2" name="Priority" sortascending="false"/>
<indexcol keyposition="3" name="CreationTime"/>
<indexcol keyposition="4" name="ID"/>
</index>

Although the unique attribute is set to true, you can safely remove this index because the index definition contains
an ID column; in this example, keyposition="4".

Attributes of <remove‐index>
The <remove-index> element contains the following attributes.

<remove-index> attribute Description Default

name Name of the index to remove. The index name is defined by the <index> element. None

Modifying an index
In many cases, you want to modify an existing database index. In that case, use the <remove-index> element to
remove the index, and then add a new index with the same name that contains the desired characteristics.

<tag>
The <tag> element defines a data model annotation. You can use predefined tags to add your own metadata to the
data model.
The file PolicyCenter/modules/configuration/config/metadata/[Link] specifies the list of valid tags that
you can use. You cannot add a new tag to this file.
At most one of each tag can exist on a field at one time. Extensions can add, but not override, tags on existing fields.

Attributes of <tag>
The <tag> element contains the following attributes.
The PolicyCenter data model 219
Guidewire PolicyCenter 9.0.9 Configuration Guide

<tag> attribute Description Default

name Required. The name of the tag. None
value The value of the tag. None

Use of the <tag> Subelement in Archiving

One of the common uses for the <tag> subelement is adding the element to a foreign key to assist in resolving
certain archive domain graph issues. See System Administration Guide for details.

<typekey>
The <typekey> element defines a field for which a typelist defines the values. Guidewire defines this element in the
data model metadata files as the <typekey> XML subelement.
Note: For information on typelists, typekeys, and keyfilters, see “Working with typelists” on
page 303.

Attributes of <typekey>

The <typekey> element contains the following attributes.

<typekey> attribute Description Default

columnName Optional. If specified, PolicyCenter uses this value as the column name of the corre‐ None
sponding database column. If you do not specify a columnName value, then
PolicyCenter uses the value of the name attribute for the database column name.
The columnName attribute must be no more than 30 characters in length. It allows on‐
ly unaccented Roman letters, numbers, and the underscore character. The first char‐
acter of the columnName attribute must be a letter. Although the underscore charac‐
ter is allowable here, Guidewire discourages its use.
IMPORTANT All column names on a table must be unique within that table. Other‐
wise, Guidewire Studio™ displays an error if you verify the resource and the applica‐
tion server fails to start.
createhistogram Whether to create a histogram on the column during an update to the database sta‐ false
tistics.
Note: It is possible to override this attribute on an existing column in an extension
(*.etx) file using the <column-override> element. You can use the override to turn
off an existing histogram or to create one that did not previously exist.
This change does not take effect during an upgrade. The change occurs only if you
regenerate statistics for the affected table by using the Guidewire
maintenance_tools command.
See also
• “Working with attribute and element overrides” on page 243
• System Administration Guide
default The default value given to the field during new entity creation. None
deprecated If true, then PolicyCenter marks the typekey as deprecated in the Data Dictionary false
and places a Deprecated annotation on it in the Guidewire Studio API Reference.
If you deprecate a typekey, use the description attribute (desc) to explain why.
For more information, see “Data entity subelements” on page 198.
desc A description of the purpose and use of the field. None
exportable Unused.
getterScriptability See “Data objects and scriptability” on page 178 for information. None

220 chapter 15: The PolicyCenter data model

 Guidewire PolicyCenter 9.0.9 Configuration Guide

<typekey> attribute Description Default

loadable If true, then you can load the field through staging tables. A staging table can contain true
a column, as a String, for the code of the typekey.
loadedByCallback Internal. If true, then the loading code does not use a default value or report a warn‐ false
ing if the column is nullable without a default.
name Required. Specifies the name of the property on the entity None
nullok Whether the field can contain null values. true

overwrittenInStagingTable Internal. If true and the typekey is loadable, the loader process auto‐populates the false
typekey in the staging table during import.
IMPORTANT If set to true, do not attempt to populate the typekey yourself because
the loader import process overwrites this typekey.
required Whether the typekey is required to be non‐null upon initial construction of instances false
of the entity. See the Gosu Reference Guide.
setterScriptability See “Data objects and scriptability” on page 178 for information. None
soapnullok Unused.
typefilter The name of a filter associated with the typelist. See “Static filters” on page 315 for None
additional information.
typelist Required. The name of the typelist from which this field gets its value. None
See also
• “Working with typelists” on page 303.

Subelements of <typekey>
The <typekey> element contains the following subelements.

<typekey> subele‐ Description Default

ment
keyfilters Defines one or more <keyfilter> elements. There can be at most one <keyfilters> None
element in an entity. See “Dynamic filters” on page 320 for additional information.
fulldescription See “<fulldescription>” on page 214. None
tag See “<tag>” on page 219. None

Subelements of <keyfilters>
The <keyfilters> element contains the following subelements.

<keyfilters> subele‐ Description Default

ment
<keyfilter> Specifies a keyfilter to use to filter the typelist. This element requires the <name> attribute. None
This attribute defines a relative path, navigable through Gosu dot notation, to a physical data
field. Each element in the path must be a data model field.
Note: You can include multiple <keyfilter> elements to specify multiple keyfilters.

Interactions of ignoreForEvents attribute with data entity relationships

The interactions of the ignoreForEvents attribute with relationships between data entities produce what might
appear to be unpredictable results. At the very least, the results are not intuitive.

The PolicyCenter data model 221

Guidewire PolicyCenter 9.0.9 Configuration Guide

However, an understanding of event generation and behavior, the definitions of the ignoreForEvents attribute, the
direction of data entity relationships, and the behavior of the relationships in light of the attribute helps to predict
such outcomes. Such an understanding will also help you to design predictable data entity relationships.
To this end, Guidewire recommends that you configure both sides of a data entity relationship with the same
ignoreForEvents attribute value. For example, in an <array>-<foreignkey> pair and a <onetoone>-
<foreignkey> pair, use the same ignoreForEvents attribute value for both pair members when possible. This topic
assumes that you have followed this recommendation.
Note: As a shorthand, this topic sometimes refers to entities declaring foreign key relationships and
one-to-one relationships as foreign key entities and one-to-one entities respectively. Similarly, as a
shorthand, the topic sometimes refers to the <foreignkey> and <one-to-one> elements themselves as
foreign keys and one-to-ones. The topic refers to the entity to which a foreign key or one-to-one points
as the target entity or target.

Event generation and behavior

PolicyCenter automatically generates standard events for most top-level objects. Generally, this event generation
occurs upon any addition, modification, removal, or retirement of a top-level entity instance. The occurrence of an
event results in the EventFired rule set executing. When this rule set is executed, PolicyCenter generates messages
using the context of the event.

ignoreForEvents attribute definitions

The ignoreForEvents attribute has three definitions, a first for entities, a second for most relationships between
entities, and a third for <onetoone> entity relationships. With respect to an entity, the value of the ignoreForEvents
attribute determines whether to ignore the entity when generating events. With respect to an entity relationship, the
ignoreForEvents attribute generally helps to rule out the relationship entity or an activity for event generation.
With respect to a <onetoone> entity relationship, the ignoreForEvents attribute, when true, reverses the direction
of the parent for a backing <foreignkey> element. This topic concerns only the interactions of the
ignoreForEvents attribute with data entity relationships.
Note: PolicyCenter implements <onetoone> entity relationships as arrays, not as a pair of singleton
entities. Thus, if an entity B has a <onetoone> entity relationship with an entity A, a parent-child
direction exists for that relationship. Moreover, B is the parent of A.

Direction of data entity relationships

With respect to events, every relationship between two entities—foreign key, edge foreign key, one-to-one, and array
— has a direction. This direction determines which entity in the relationship is the parent and which is the child.
For any given entity relationship, suppose that the parent entity generates events and the child entity does not
generate events. In this scenario, when an instance of the child entity changes, PolicyCenter raises a ParentChanged
event. The key in such a scenario is that the relationship between the two entities must flow in the direction of an
EventAware entity, a parent entity, to generate an Event. EventAware entities cannot be event children.
For a given entity relationship, first determine whether the preceding scenario is present. If so, the relationship is
relevant. If not, the relationship is not relevant. Moreover, if the rules lead to a parent not being a EventAware entity
and to the Child being an EventAware entity, no event relationship exists between the two entities. EventAware
entities cannot have event parents because updates are not propagated through EventAware entities.
Second, determine which entity is the parent and which entity is the child in accordance with the following logic:
• An array entity is always the event parent. The entity with the array is the event parent, and the entity with the
foreign key is the child.
• With a one-to-one relationship, the entity declaring the <onetoone> element is the event parent unless the value
of the ignoreForEvents attribute on the one-to-one entity is true. PolicyCenter implements one-to-one entities
as arrays. In this implementation, the ignoreForEvents attribute only reverses the direction of the relationship
between the array and a backing foreign key when the attribute has a value of true. When the ignoreForEvents
attribute has a value of false, the one-to-one entity behaves exactly as an array with no reversal of ownership
direction. Moreover, the one-to-one entity is the parent, and the foreign key entity is the child. If the
222 chapter 15: The PolicyCenter data model
 Guidewire PolicyCenter 9.0.9 Configuration Guide

ignoreForEvents attribute has a value of true, the foreign key entity is the parent, and the one-to-one entity is
the child.
• With a foreign key relationship, the entity declaring a foreign key is the event parent, and the target entity of the
foreign key is the event child. An exception to this scenario occurs if the foreign key backs an array. If the
foreign key backs an array, the foreign key entity is the event child.
• With an edge foreign key relationship, the entity declaring an edge foreign key is the event parent, and the target
entity of the edge foreign key is the event child.

Behavior of data entity relationships in light of the ignoreForEvents attribute value

Determine the effects of the value of the ignoreForEvents attribute on data entity relationships in accordance with
the following logic:
• If the value of the ignoreForEvents attribute on a relationship is true, ignore the relationship for event
generation unless the relationship involves a one-to-one entity.
For a relationship involving a one-to-one entity, consider the relationship for event generation as you would an
array with a reversed direction of events. In this case, events propagate from the one-to-one entity to the foreign
key entity if the latter is EventAware and the former is not.
For a relationship involving a foreign key or edge foreign key, update events generally will propagate from the
target object of the foreign key or edge foreign key. That is, the events generally will propagate by virtue of the
target object alone being changed.
However, consider an important exception to this generalization. Suppose that the only fields changed on the
target object of the foreign key or edge foreign key have a value of true for the ignoreForEvents attribute. In
this case, the PolicyCenter database reflects the changes. However, PolicyCenter does not consider the target
object updated for the purpose of event generation. Whether the foreign key backs an array is irrelevant for this
behavior. This behavior allows you to update internal bookkeeping fields without raising events.
Suppose that you update only an entity that is not EventAware. Although that entity alone will not result in event
generation, an EventAware parent or grandparent having an ignoreForEvents attribute with a value of false
will. The EventAware parent or grandparent in this case will generate events on the basis of the changed child or
grandchild that is not EventAware.
• If the value of the ignoreForEvents attribute is false, then evaluate the relationship for event generation in
accordance with the following logic:
◦ Events propagate from any changed entity that is not EventAware and that has an ignoreForEvents attribute
with a value of false. The propagation proceeds along a chain of entities from child to parent so long as the
last entity in the chain is EventAware.
◦ For a relationship involving a one-to-one entity, consider the relationship for event generation as you would an
array without a reversed direction of event propagation. In this case, events propagate from the from the
foreign key entity to the one-to-one entity if the latter is EventAware and the former is not.

Examples
1. Array and foreign key
Suppose that an entity A has a foreign key to entity B and that the foreign key backs an array. Moreover,
suppose that B has an array of A. In this case, B is the parent, and A is the child. The ignoreForEvents used
is set on the array entity. In this case, the ignoreForEvents used is set on the array, but Guidewire
recommends applying the same setting both to the array and to the backing foreign key.
If the foreign key does not back an array, then A is the parent, and B is the child.
2. Array and multiple foreign keys
Suppose the following:
• Claim has an array of ABC_NonEAEntity with an ignoreForEvents value of false.
• ABC_NonEAEntity has a foreign key, ClaimID, to Claim with an ignoreForEvents value of true.
• ABC_NonEAEntity has a foreign key, ABC_AnotherNonEAEntityID, to ABC_AnotherNonEAEntity with an
ignoreForEvents value of true.
The PolicyCenter data model 223
Guidewire PolicyCenter 9.0.9 Configuration Guide

Given this premise, the following is true:

• Claim is an event parent of ABC_NonEAEntity, because of the array.
That the foreign key of ABC_NonEAEntity to Claim has an ignoreForEvents attribute with a value of true
does not matter. This irrelevance is because the foreign key backs an array.
In addition, under ordinary circumstances, ABC_NonEAEntity would be an event parent of
ABC_AnotherNonEAEntity. However, PolicyCenter does not treat ABC_NonEAEntity as an event parent
because the foreign key has an ignoreForEvents attribute with a value of true.
• Given this configuration, the following actions will raise ClaimChanged events:
◦ Changing a field on Claim
◦ Adding a new ABC_NonEAEntity to Claim
◦ Removing an existing ABC_NonEAEntity from Claim
◦ Updating any combination of fields on an existing ABC_NonEAEntity, except any combination that
includes only ClaimID or ABC_AnotherNonEAEntityID. The exclusion is due to the latter fields having an
ignoreForEvents attribute with a value of true.
• The following independent actions will not raise ClaimChanged events:
◦ Updating an existing ABC_AnotherNonEAEntity
◦ Changing an existing ABC_NonEAEntity to point to a different ABC_AnotherNonEAEntity
The reason for no raising of ClaimChanged events is because the only field that changed,
ABC_AnotherNonEAEntityID, has an ignoreForEvents attribute with a value of true.
3. Foreign key and array
Suppose the following:
• Entity E has a foreign key F with an ignoreForEvents value of true.
• An instance of E undergoes a change only to the field for F.
• No other change would cause PolicyCenter to raise EChanged or XYZChanged events.
Given this premise, the following is true:
• PolicyCenter will not consider the instance of E to have changed for event generation purposes.
• If E is an EventAware entity, PolicyCenter will not raise an EChanged event.
• If E is not an EventAware entity, PolicyCenter will not raise an XYZChanged event for any event parents of E.
Suppose further that foreign key F backs an array. Given this elaboration, the following is true:
• Only the array is used to determine the event propagation relationship between the foreign key and the array.
• If the array has an ignoreForEvents attribute with a value of true, PolicyCenter will not propagate events
between the two entities.
• Suppose that the foreign key has an ignoreForEvents attribute with a value of true. In this case,
PolicyCenter ignores changes to any instance of the foreign key for deciding whether a bean has changed for
the purpose of event generation.

224 chapter 15: The PolicyCenter data model

chapter 16

Working with associative arrays

This topic describes the different types of associative arrays that Guidewire provides as part of the base data model
configuration.

Related concepts
“Overview of associative arrays” on page 225
“Subtype mapping associative arrays” on page 227
“Typelist mapping associative arrays” on page 230

Overview of associative arrays

An associative array provides a mapping between a set of keys and values that the keys represent. A common
example of such a mapping is a telephone book. A telephone book maps names of people in a jurisdiction to
telephone numbers. Another common example is a dictionary. A dictionary maps terms to their definitions.
To expand on this concept, a telephone book contains a set of names. Each name in the set is a key, and each
associated telephone number is a value. Using array-like notation, you can write:
telephonebook[peter] = 555-123-1234
telephonebook[shelly] = 555-234-2345
...

Note: When you modify an array such that it is an associative array, the array continues to exhibit its
original properties as an indexed array. You can use an associative array just as you would an indexed
array. For example, you can use an associative array in for loops.
PolicyCenter uses associate arrays to expose array values as a type-safe map within Gosu code. The following
example uses a typekey from a State typelist as a mapping index for an associative array of state capitals:

State typekey index Maps to...

Capital[State.TC_AL] Montgomery

Capital[State.TC_AK] Juneau

Capital[State.TC_AZ] Phoenix

Capital[State.TC_AR] Little Rock

Working with associative arrays 225

Guidewire PolicyCenter 9.0.9 Configuration Guide

Two tasks are required to work with an associative array in Gosu:

• Exposing the key set to the type system
• Calculating the value from the key

Associative array mapping types

An associative array must have a key that maps to a value. The mapping type describes what PolicyCenter uses as
the key and what value that key returns.

Mapping type Key Value More information

Subtype mapping Entity subtype Implicit subtype field on an entity “Subtype mapping associative arrays” on page 227
Typelist mapping Typelist Typekey field on the entity “Typelist mapping associative arrays” on page 230

To implement an associative array, add one of the following elements to an <array> element in the data type
definition file. The number of results that each returns—the cardinality of the result set—depends on the element
type.

<link-association> Returns at most one element. The return type is an object of the type of the array.
<array-association> Returns an array of results that match the value. The number of results can be zero, one, or more.

Each <array> element in a data type definition file can have zero or one of each of these elements.
As an example, in the ClaimCenter Claim definition file (configuration→config→Metadata→Entity→[Link]), you see
the following XML (simplified for clarity):
<entity xmlns="[Link]
entity="Claim"
table="claim"
type="retireable">
...
<array arrayentity="ClaimMetric"
desc="Metrics related to this claim."
exportable="false"
ignoreforevents="true"
name="ClaimMetrics"
triggersValidation="false">
<link-association>
<subtype-map/>
</link-association>
<array-association>
<typelist-map field="ClaimMetricCategory"/>
</array-association>
</array>
...
</entity>

See also
• “Subtype mapping associative arrays” on page 227.
• “Typelist mapping associative arrays” on page 230.

Scriptability and associative arrays

It is possible to set the following attributes on each <link-association> and <array-association> element:
• hasGetter
• hasSetter
For example:
226 chapter 16: Working with associative arrays
 Guidewire PolicyCenter 9.0.9 Configuration Guide

<link-association hasGetter="true" hasSetter="true">

<typelist-map field="TAccountType"/>
</link-association>

For these attributes:

• If hasGetter is true, you can read the property.
• If hasSetter is true, you can update the property.
Note: If you do not specify either of these attributes, PolicyCenter defaults to hasGetter="true".

See also
• “Data objects and scriptability” on page 178.

Setting array member values

There are several restrictions on setting associative array member values, including:
• You can use a query builder expression to retrieve a specific entity instance. However, the result of the query is
read-only. You must add the retrieved entity to a bundle to be able to manipulate its fields. To work with bundles,
use one of the following:
var bundle = [Link]()
[Link](\ bundle -> ) //Use this version in the Gosu tester

• You can set array values only on fields that are database-backed fields, not on fields that are derived properties.
To determine which fields are derived, consult the PolicyCenter Data Dictionary.

See also
• Gosu Reference Guide

Subtype mapping associative arrays

Use subtype mapping to access array elements based on their subtype. This type of associative array divides the
elements of the array into multiple partitions. Each of these partitions contains array elements of only a particular
object subtype.
For example, in PolicyCenter, you can define an associative array called JobTypes on the Policy object. In the
Policy definition file (configuration→config→Metadata→Entity→[Link]), you can add the <array> element from the
following example XML:
<entity xmlns="[Link]
entity="Policy"
table="policy"
type="retireable">
...
<array arrayentity="Job"
desc="Types of jobs pertaining to a policy."
exportable="false"
ignoreforevents="true"
name="JobTypes">
<link-association>
<subtype-map/>
</link-association>
</array>
...
</entity>

The JobTypes array contains a number of objects. Each of these objects is a subtype of a Job object. The data model
defines the associative array using the <link-association> element. A link association returns at most one
element. The return type is an object of the type of the array. In this case, the return type is an object of type Job or,
more specifically, one of its subtypes.
Working with associative arrays 227
Guidewire PolicyCenter 9.0.9 Configuration Guide

The PolicyCenter data model defines a number of subtypes of the Job object, including:
• Audit
• Cancellation
• Issuance
• PolicyChange
• Reinstatement
• Renewal
• Rewrite
• RewriteNewAccount
• Submission
To determine the complete list of subtypes on an object, consult the PolicyCenter Data Dictionary. The dictionary
organizes the subtypes into a table at the top of the dictionary page with active links to sections that describe each
subtype in greater detail.

Working with array values by using subtype mapping

To retrieve an array value through subtype mapping, use the following syntax:
[Link]

Each field has the following meanings:

Field Description
base-entity The base object on which the associative array exists. For example, consider the Claim entity for the
ClaimMetrics array.

subtype-map The array entity subtype, for example, AllEscalatedActivitiesClaimMetric (a subtype of ClaimMetric).

property A field or property on the array object. For example, the AllEscalatedActivitiesClaimMetric object con‐
tains the following properties (among others):
• ClaimMetricCategory
• DispalyTargetValue
• DisplayValue

Note: To see a list of subtypes for any given object, consult the PolicyCenter Data Dictionary. To
determine the list of fields (properties) on an object, again consult the Data Dictionary.
The following table lists the attributes associated with the <subtype-map> element.

<subtype-map> attrib‐ Description Default

utes
customAccessor Internal. Do not use. None
propertyPrefix Optional attribute that specifies a prefix for every property that an array association None
generates. This attribute is useful when you have two or more array associations with
overlapping keys. For example, suppose that you have two array associations that both have
a subtype map on the same field. In this case, you need to use the propertyPrefix attribute
on at least one of the subtype maps. Providing a value for the attribute avoids the two array
associations having the same set of property names.

Example 1
The following example code uses the sample data in the Guidewire ClaimCenter base configuration. It first retrieves
a specific claim object using a query builder and then uses that object as the base entity from which to retrieve array
member properties.
228 chapter 16: Working with associative arrays
 Guidewire PolicyCenter 9.0.9 Configuration Guide

uses [Link]
uses [Link]

var clm = [Link](Claim).compare("Claim#ClaimNumber", Equals,

"235-53-365870").select().getAtMostOneRow()

print("AllEscalatedActivitiesClaimMetric\tClaim Metric Category = "

+ [Link])
print("AllEscalatedActivitiesClaimMetric\tDisplay Value = "
+ [Link])
print("AllEscalatedActivitiesClaimMetric\tReach Yellow Time = "
+ [Link])

The output of running this code in the Gosu Scratchpad looks similar to the following:
AllEscalatedActivitiesClaimMetric Claim Metric Category = Claim Activity
AllEscalatedActivitiesClaimMetric Display Value = 0
AllEscalatedActivitiesClaimMetric Reach Yellow Time = null

Example 2
The following sample code:
• Retrieves a read-only claim object.
• Adds the claim object to transaction bundle to make it writable.
• Sets a specific property on the AllEscalatedActivitiesClaimMetric object (a subtype of the ClaimMetric
object) associated with the claim.
In the definition of the claim object, ClaimCenter associates an array of ClaimMetric objects—the ClaimMetrics
array—with the Claim object. The metadata definition file also defines the ClaimMetrics array as being of type
<link-association> using subtypes. Thus, you can access array member properties by first accessing the array
member of the proper subtype.
uses [Link]
uses [Link]

var todaysDate = [Link]

var clm = [Link](Claim).compare(Claim#ClaimNumber, Equals,
"235-53-365870").select().AtMostOneRow

//Query result is read-only, need to get current bundle and add object to bundle
[Link](\bundle -> {
if (clm != null) {
clm = [Link](clm)

print("AllEscalatedActivitiesClaimMetric\tReach Yellow Time = "

+ [Link])
[Link] = todaysDate

print("\nAfter modifying the ReachYellowTime value...\n")

print("AllEscalatedActivitiesClaimMetric\tReach Yellow Time = "
+ [Link])
}
}, "su")

The output of running this code in the Gosu Scratchpad looks similar to the following:
AllEscalatedActivitiesClaimMetric Reach Yellow Time = null

After modifying the ReachYellowTime value...

AllEscalatedActivitiesClaimMetric Reach Yellow Time = 2018-03-08

See also
• Gosu Reference Guide

Working with associative arrays 229

Guidewire PolicyCenter 9.0.9 Configuration Guide

Typelist mapping associative arrays

You use a typelist map to partition array objects based on a typelist field (typecode) in the <array> element. In the
ClaimCenter base configuration, the ClaimMetrics array on Claim contains an example of a typelist mapping.
<entity xmlns="[Link]
entity="Claim"
table="claim"
type="retireable">
...
<array arrayentity="ClaimMetric"
desc="Metrics related to this claim."
exportable="false"
ignoreforevents="true"
name="ClaimMetrics">
...
<array-association>
<typelist-map field="ClaimMetricCategory"/>
</array-association>
</array>
...
</entity>

The <typelist-map> element requires that you set a value for the field attribute. This attribute specifies the
typelist to use to partition the array.

IMPORTANT It is an error to specify a typelist mapping on a field that is not a typekey.

Associative arrays of type <array-associaton> are different from those created using <link-association> in that
they can return more than a single element. In this case, the code creates an array of ClaimMetric objects named
ClaimMetrics. Each ClaimMetric object as well as all subtype objects of the ClaimMetric object contain a
property called ClaimMetricCategory. The array definition code utilizes that fact and uses the
ClaimMetricCategory typelist as a partitioning agent.
The ClaimMetricCategory typelist contains three typecodes, which are:
• ClaimActivityMetrics
• ClaimFinancialMetrics
• OverallClaimMetrics
Each typecode specifies a category. This category contains multiple ClaimMetric object subtypes. For example, the
OverallClaimMetrics category contains two ClaimMetric subtypes:
• DaysInitialContactWithInsuredClaimMetric
• DaysOpenClaimMetric
In another example from the ClaimCenter base configuration, you see the following defined for ReserveLine.
<entity entity="ReserveLine"
xmlns="[Link]
...
table="reserveline"
type="retireable">
...
<array arrayentity="TAccount"
arrayfield="ReserveLine"
name="TAccounts"
...
setterScriptability="hidden">
<link-association hasGetter="true" hasSetter="true">
<typelist-map field="TAccountType"/>
</link-association>
</array>
...
</entity>

In this case, the array definition code creates a <link-association> array of TAcccount objects and partitions the
array by the TAccountType typelist typecodes.

230 chapter 16: Working with associative arrays

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Working with array values by using typelist mapping

To retrieve an array value through typelist mapping, use the following syntax:
[Link]

Each field has the following meaning:

Field Description
entity The object on which the associative array exists. For example, consider the ReserveLine entity on which the
Taccounts array exists.

typecode The typelist typecode that delimits this array partition, for example, OverallClaimMetrics (a typecode from the
ClaimMetricCategory typelist).

property A field or property on the array object. For example, the ClaimMetric object contains the following properties
(among others):
• ReachRedTime
• ReachYellowTime
• Skipped

The following table lists the attributes associated with the <typelist-map> element.

<typelist-map> at‐ Description Default

tributes
customAccessor Internal. Do not use. None
field Required. Name of the property to which the array associates. None
propertyPrefix Optional attribute that specifies a prefix for every property that an array association None
generates. This attribute is useful when you have two or more array associations with
overlapping keys. For example, suppose that you have two array associations that both have
a typelist map on the same field. In this case, you need to use the propertyPrefix attribute
on at least one of the typelist maps. Providing a value for the attribute avoids the two array
associations having the same set of property names.

Example 1
The following example code uses sample data in the Guidewire ClaimCenter base configuration. It iterates over the
members of the ClaimMetrics array that fall into the OverallClaimMetrics category.
uses [Link]
uses [Link]

var clm = [Link](Claim).compare(Claim#ClaimNumber, Equals, "235-53-365870").select().AtMostOneRow

for (time in [Link]) {
print([Link] + ": ReachYellowTime = " + [Link])
}

The output of running this code in the Gosu Scratchpad looks similar to the following:
Days Open: ReachYellowTime = 2018-08-24
Initial Contact with Insured (Days): ReachYellowTime = 2018-02-12

Example 2
The following example code also uses the sample data in the Guidewire ClaimCenter base configuration. It first
retrieves a specific Claim object and then retrieves a specific ReserveLine object associated with that claim.
uses [Link]
uses [Link]

var clm = [Link](Claim).compare(Claim#ClaimNumber, Equals,

Working with associative arrays 231

Guidewire PolicyCenter 9.0.9 Configuration Guide

"235-53-365870").select().AtMostOneRow
var thisReserveLine = [Link]()

print(thisReserveLine)
print([Link])

The output of running this code in the Gosu Scratchpad looks similar to the following:
(1) 1st Party Vehicle - Ray Newton; Claim Cost/Auto body
Thu Feb 22 15:35:02 PST 2018

Setting array member values

The following example code also uses the sample data in the Guidewire ClaimCenter base configuration. It uses a
query builder expression to retrieve a specific claim entity. Because the result of the query is read-only, you must
first retrieve the current bundle, then add the claim to the bundle to make its fields writable. The retrieved claim is
the base entity on which the ClaimMetrics array exists.
The following sample code:
• retrieves a read-only claim object
• adds the claim object to transaction bundle to make it writable
• sets specific properties on the ClaimMetric object associated with the claims that are in the
OverallClaimMetrics category
In the definition of the claim object, ClaimCenter associates an array of ClaimMetric objects—the ClaimMetrics
array—with the Claim object. The metadata definition file also defines the ClaimMetrics array as being of type
<array-association> using the ClaimMetricCategory typelist. Thus, you can access array member properties by
first accessing the array member of the proper category.
uses [Link]
uses [Link]

var todaysDate = [Link]

var thisClaim = [Link](Claim).compare(Claim#ClaimNumber, Equals, "235-53-365871").select().AtMostOneRow
//Query result is read-only, need to get current bundle and add entity to bundle

[Link](\bundle -> {
if (thisClaim != null) {
thisClaim = [Link](thisClaim)

//Print out the current values for the [Link] field on each subtype
for (color in [Link]) {
print("Subtype - " + [Link] + ": ReachYellowColor = " + [Link])
}

print("\nAfter modifying the values...\n")

//Modify the [Link] value and print out the new values
for (color in [Link]) {
[Link] = todaysDate
print("Subtype - " + [Link] + ": ReachYellowColor = " + [Link])
}
}
}, "su")

The output of running this code in the Gosu Scratchpad looks similar to the following:
Subtype - Days Open: ReachYellowColor = 2017-11-08
Subtype - Initial Contact with Insured (Days): ReachYellowColor = 2017-10-30

After modifying the values...

Subtype - Initial Contact with Insured (Days): ReachYellowColor = 2018-03-08

Subtype - Days Open: ReachYellowColor = 2018-03-08

See also

• Gosu Reference Guide

232 chapter 16: Working with associative arrays
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Example: Mapping an entity to entities of a different type

When creating a database entity that refers to multiple entities of a different type, a best practice is to use an
associative array with typelist mapping.

About this task

A database entity often requires references to multiple entities of a different type.

One way to implement such references is to use <onetoone> links. In this case, you must have a separate
<foreignkey> element that corresponds to each such link. These separate <foreignkey> elements must be on each
entity to which the original database entity refers. The separate elements must also point back to the original
database entity. In addition, on each <onetoone> link, you must specify its linkField attribute to associate the link
with its corresponding <foreignkey> element.
However, this method has a downfall. A <onetoone> link generally requires a unique relationship to the
<foreignkey> element that backs the link. The relationship must have a unique index on the <foreignkey>
element. Such a relationship and its unique index cannot be present if the <foreignkey> element is nullable. In this
case, nothing enforces the constraint that the <onetoone> link implies.
A preferable option or best practice would be to use an <array> element and a <link-association> subelement. This
configuration produces virtual properties for the original database entity. You can use these virtual properties to
access the entity instances to which the original database entity refers.
To illustrate how to do so, consider an example of an automation that checks three kinds of results related to an
insurance claim—coverability, handleability, and payability. Take the following steps to map a database entity,
Ext_Automation, to three entities of type Ext_AutomationCheckResult—CoverabilityResult,
HandleabilityResult, and PayabilityResult:

Procedure

1. Create an entity, Ext_Automation.

2. Create another entity, Ext_AutomationCheckResult.
3. Add to Ext_Automation an array of the Ext_AutomationCheckResult entity.
4. Create one <foreignkey> element for the Ext_AutomationCheckResult entity that points back to the
Ext_Automation entity.
5. Create a typelist named Ext_AutomationResultType.
6. Add three type codes to the Ext_AutomationResultType typelist: CoverabilityResult,
HandleabilityResult, PayabilityResult.
7. Add a <typekey> element to the Ext_AutomationCheckResult entity.
8. With this <typekey> element, refer to the Ext_AutomationResultType typelist.
9. Under the array of Ext_AutomationCheckResult in the Ext_Automation entity definition, declare a <link-
association> subelement.
10. Under the <link-association> subelement, declare a <typelist-map> that refers to your <typekey> field
from step 7.
11. Add an <index> subelement to the Ext_AutomationCheckResult entity.
12. To ensure unique index entries, set the unique attribute on the <index> subelement to true.
13. Add as index columns the Ext_Automation foreign key and the typekey corresponding to the
Ext_AutomationResultType typelist.

Result

You now have three new virtual properties on the Ext_Automation database entity with which to access the three
Ext_AutomationCheckResult types—CoverabilityResult, HandleabilityResult, and PayabilityResult.
Working with associative arrays 233
Guidewire PolicyCenter 9.0.9 Configuration Guide

Constant mapping associative arrays

You use a constant map to allow the data model itself to specify key-value pairs. To indicate this mapping type, add
the <constant-map> subelement to an <array-association> element or a <link-association> element. Then,
enter key-value pairs in the definition file.
For example, the following extension code extends the Account entity type and does the following:
• It defines an array of AccountLocation objects, with each contact associated with a specific role.
• It adds this array to the Account entity.
• It defines individual address types directly as properties on a <constant-map> subelement of the <link-
association> and <array-association> elements.
<?xml version="1.0"?>
<extension xmlns="[Link] entityName="Account">
<array name="AccLocs" arrayentity="AccountLocation">
<link-association>
<constant-map field="AddressType">
<property name="BillingLoc" nullOk="true" value="billing"/>
</constant-map>
</link-association>

<array-association>
<constant-map field="AddressType">
<property name="HomeLocs" value="home"/>
<property name="BusinessLocs" value="business"/>
<property name="OtherLocs" value="other"/>
</constant-map>
</array-association>
</array>
</extension>

The structure of the constant-map association allows you to specify multiple properties under a constant. Notice that
you specify array-association constants and link-association constants in two separate groups.

See also

• “Subtype mapping associative arrays” on page 227

• “Typelist mapping associative arrays” on page 230

Working with array values by using constant mapping

To retrieve a member of the Role array, use the following syntax:
[Link]-property

Each field has the following meanings:

Field Description
base-entity The base object on which the associative array exists. For example, consider the Account entity for the
Contacts array.

defined-property The property that you defined for the constant map array.

The following tables list the attributes and subelements associated with the <constant-map> element.

<constant-map> at‐ Description Default

tributes
customAccessor Internal. Do not use. None
field Required. Name of the property to which the array associates. None

234 chapter 16: Working with associative arrays

 Guidewire PolicyCenter 9.0.9 Configuration Guide

<constant-map> at‐ Description Default

tributes
propertyPrefix Optional attribute that specifies a prefix for every property that an array association None
generates. This attribute is useful when you have two or more array associations with
overlapping keys. For example, suppose that you have two array associations that both have a
constant map on the same field. In this case, you need to use the propertyPrefix attribute
on at least one of the constant maps. Providing a value for the attribute avoids the two array
associations having the same set of property names.
Note: Constant maps generally do not require a propertyPrefix attribute because the
property subelement allows full control over property names.

<constant-map> subelements Description

property Key‐value pair in the map.

Working with associative arrays 235

Guidewire PolicyCenter 9.0.9 Configuration Guide

236 chapter 16: Working with associative arrays

chapter 17

Modifying the base data model

This topic discusses how to extend the base data model as well as how to create new data objects.

Related concepts
“Planning changes to the base data model” on page 237
“Defining a new data entity” on page 240
“Extending a base configuration entity” on page 242
“Working with attribute and element overrides” on page 243
“Extending the base data model” on page 246
“Removing objects from the base configuration data model” on page 256
“Deploying data model changes to the application server” on page 260

Planning changes to the base data model

Before proceeding to modify the base data model, Guidewire strongly recommends that you first review the Data
Dictionary. Verify that the existing data model does not provide the functionality that you need first before
modifying the base application functionary.

Overview of data model extensions

Entity extensions are additions to the entities in the base data model. Although you cannot modify the base data type
declaration files directly, you can define an extension to one in a separate .etx file. You can also define new data
model objects that extend the data model in an .eti file. This allows new PolicyCenter releases to modify the base
definitions without affecting your extensions, thus preserving an upgrade path.
By extending the base data model, you can:
• Add fields (columns) to an existing base entity through the use of the <column>, <typekey>, <foreignkey>,
<array>, and similar elements. See “Data entity subelements” on page 198.
• Create a new entity with custom fields using any of the entity types listed in “XML root elements and related
base PolicyCenter data object types” on page 179.
• Modify a small subset of the attributes of an existing base entity using overrides.
• Remove (or hide) an extension to a base entity that exists in the extensions folder as an .etx declaration file.
• Remove (or hide) a base entity that exists in the extensions folder as an .eti declaration file.
Modifying the base data model 237
Guidewire PolicyCenter 9.0.9 Configuration Guide

However, using extensions, you cannot:

• Delete a base entity or any of its fields. If you do not use a particular base entity or one of its fields, then simply
ignore it.
• Change most of the attributes of a base entity or any of its fields.

Strategies for extending the base data model

Extending the data model means one of the following:
• You want to add new fields to an existing entity.
• You want to create a new entity.
During planning for data model extensions, you need to consider performance implications. For example, if you add
hundreds of extensions to a major object, this can conceivably exceed a reasonable row size in the database.

Adding fields to an entity

If an entity has almost all the functionality you need to support your business case, you can add one or more fields to
it. In this sense, Guidewire uses the term field to denote one of the following:
• Column
• Typekey
• Array
• Foreign key
See “Data field types” on page 167 for a description of these fields.

Subtyping a non‐final entity

If you want to find a new use for an existing entity, you can subtype and rename it. For instance, suppose that you
want to track individuals who have already had the role of IssueOwner. In this case, it can be useful to create
PastIssueOwner.

Creating a new entity

Occasionally, careful review of the base application data model makes it clear that you need to create a new entity.
There are several types of base entities within Guidewire applications. However, Guidewire recommends in general
practice that you always use one of the following types if you create a new entity:

retireable This type of entity is an extension of the editable entity. It is not possible to delete this entity. It is possible to
retire it, however.
versionable This type of entity has a version and an ID. It is possible to delete entities of this type from the database.

Guidewire recommends the following:

• If another entity contains a foreign key reference to the new entity, then make the new entity retireable. For
example, any entity that contains an array must be retireable.
• If there is no foreign key reference, and you desire the entity to contain the fields CreateTime, UpdateTime,
CreateUser, and UpdateUser, then make the new entity editable.
• Otherwise, make the entity versionable.
Note: To later change an existing entity from retireable to versionable, you must drop the
database.
See “Data entities and the application database” on page 175 for more information on these data types.
238 chapter 17: Modifying the base data model
 Guidewire PolicyCenter 9.0.9 Configuration Guide

In general, you typically want to create a new entity under the following circumstances:
• If your business model requires an object that does not logically exist in the application. Or, if you have added
too many fields to an existing entity, and want to abstract away some of it into a new, logical entity.
• If you need to manage arrays of objects, as opposed to multiple objects, you can create an entity array.

Reference entities
To store some unchanging reference data, such as a lookup table that seldom changes, you can create a reference
entity. An example of a business case for a reference entity is a list of typical reserve amounts for a given exposure.
To avoid the overhead of maintaining foreign keys, make reference entities keyable. Unless you want to build in the
ability to edit this information from within the application, set setterscriptability = hidden. This prevents
Gosu code from accidentally overwriting the data.
Guidewire recommends that you determine that this is not really a case for creating a typelist before you create a
reference entity.

See also
• “Defining a reference entity” on page 253
• “The archive domain graph and reference data” on page 327

What happens if you change the data model?

During server start up, PolicyCenter analyzes the metadata for changes since the last build. If you have made
extensions, the application merges this into the working PolicyCenter data model, which is the composite of the base
entities and your extensions.
After merging the base data model with any extensions, PolicyCenter compares the startup layout to the physical
schema in the current database. (Each PolicyCenter database stores schema version numbers and metadata
checksums to optimize the analysis and comparison.)
If the application detects changes between the startup layout and the physical database schema, it initiates a database
upgrade automatically. This keeps the physical schema synchronized with the schema defined by the XML
metadata. By default, PolicyCenter refuses to start until the two are synchronized.
The PolicyCenter application server conducts a number of additional tests on the product model data model as it
starts. See the following for more information:
• Product Model Guide

WARNING Do not directly modify the physical database that PolicyCenter uses. Only make
changes to the PolicyCenter data model through Guidewire Studio.

Database upgrade triggers

The upgrade utility initiates a database upgrade automatically at application server startup if there are additions,
modifications, or extensions to any of the following:
• Data model version
• Extensions version
• Platform version
• PolicyCenter data model
• Field encryption
• Typelists
In addition to these generic changes, the following specific localization changes trigger a database upgrade:
• In file [Link], any change to the <LinguisticSearchCollation> subelement on the <GWLocale>
element of the default application locale forces a database upgrade at application server startup.
• In file [Link], any change to the source definition of the DBJavaClass definition forces a database
upgrade at application server startup.
Modifying the base data model 239
Guidewire PolicyCenter 9.0.9 Configuration Guide

Decimal database column upgrade triggers

A decimal database column will upgrade automatically at application server startup in the following Guidewire
Studio scenario. For the scenario, note the following concepts:
• The characteristic of a database column is the set of digits to the left of the decimal point.
• The mantissa of a database column is the set of digits to the right of the decimal point.
• The precision of a database column is the total number of digits.
• The scale of a database column is the number of digits in the mantissa.
• The number of digits in the characteristic is the difference between the precision and the scale (precision - scale).
In the scenario, suppose that a user increases the number of digits in the characteristic (precision - scale) and/or the
mantissa (scale) of a database column. Suppose also that the user maintains the number of digits in the other part of
the database column, if any. The modified database column part or parts will automatically convert to the
appropriate number of digits in this case.

WARNING Do not decrease the number of digits in either the characteristic (precision - scale) or
the mantissa (scale) of a database column. If you do, the application server will throw an
exception during startup.

Naming restrictions for extensions

PolicyCenter uses the names of extensions as the basis for several other internally-generated structures, such as
database elements and Java classes. Because of this, it is important that you adhere to the naming requirements and
guidelines described in this section.

IMPORTANT Deviations from these guidelines can result in product errors or unexpected behavior.

An extension name cannot start with a number; it must start with a letter. Other than that, an extension name can
contain letters, numbers, or underscores (_). Guidewire does not permit any other characters in extension names.

Defining a new data entity

You define all new data entity objects in declaration files that end with the .eti extension. You do this through
Guidewire Studio. Studio automatically manages the process and stores the .eti file in the correct location in the
application (in the configuration→config→extensions→entity folder).

Create a new entity

Procedure
1. In Guidewire Studio, in the Project tool window, navigate to configuration→config→Extensions→Entity.
2. Right-click Entity, and then click New→Entity.
3. In the Entity dialog, specify the entity definition values.

Data entity More information

<delegate> “<delegate> elements and related data object types” on page 180
<entity> “<entity> elements and related data object types” on page 183
<extension> “<extension> elements and related data object types” on page 189
<nonPersistentEntity> “<nonPersistentEntity> elements and related data object types” on page 191

<subtype> “<subtype> elements and related data object types” on page 192
<viewEntity> “<viewEntity> elements and related data object types” on page 195

240 chapter 17: Modifying the base data model

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Data entity More information

<viewEntityExtension> “<viewEntityExtension> elements and related data object types” on page 197

4. Add fields to your new data entity. In the Field drop-down list, select the field type to add, and then click Add
. For example:

XML tag Use to add

<array> An array of entities
<column> A field with a simple data type
<foreignkey> A field referencing another entity

<typekey> A field with a typelist

For information on the possible XML elements that you can add to your new entity definition, see “Data entity
subelements” on page 198.
5. Deploy your changes to the application server. You must redeploy the application after you make any change
to the Guidewire PolicyCenter data model. See “Deploying data model changes to the application server” on
page 260 for details.

Default properties on a new entity

The following table contains the entity properties that PolicyCenter generates automatically when you create a new
entity:

Property Description
ID Internally managed primary key
CreateTime Timestamp indicating when the object was created. This property is only applicable for editable, effdated,
effdatedbranch, effdatedcontainer, and retireable entity types.
CreateUser User who created the object. This property is only applicable for editable, effdated, effdatedbranch,
effdatedcontainer, and retireable entity types.
LoadCommandID This property is included for entities where the loadable attribute has a value of true. However,
PolicyCenter does not use this property.
New Indicator of whether this object is a new object that has not been committed to the database.
NewlyImported Obsolete.
PublicID ID or primary key of the row in the external system to which this row is mapped
Retired Derived property returning a Boolean value. The Boolean value is true if the RetiredValue property has a
non‐zero value. The Boolean value is false if the RetiredValue property has a zero value. The Retired
property is only applicable for effdatedbranch, effdatedcontainer, and retireable entity types.
RetiredValue Value indicating whether the object is still in active use. A zero value for the property means that the object
is not retired. A non‐zero value equal to the entity ID means that the object is retired from active use. Note
that even if an object is retired, it can still be referred to by another object. The RetiredValue property is
only applicable for effdatedbranch, effdatedcontainer, and retireable entity types.
UpdateTime Timestamp when the object was last updated. This property is only applicable for editable, effdated,
effdatedbranch, effdatedcontainer, and retireable entity types.
UpdateUser User who last updated the object. This property is only applicable for editable, effdated, effdatedbranch,
effdatedcontainer, and retireable entity types.

Modifying the base data model 241

Guidewire PolicyCenter 9.0.9 Configuration Guide

Note: New entities have constant properties that the PolicyCenter data dictionary lists. The table in
this topic does not list these properties. Instead of using these constant properties, use feature literals
to refer to the static properties of entities in queries.

See also
• For more information on using feature literals to refer to entity properties, see Gosu Reference Guide.

Extending a base configuration entity

You can define all your entity extensions in files that end with the .etx extension by using Guidewire Studio™.
Studio automatically manages the process and stores the .etx file in the correct location in the application.

IMPORTANT Guidewire provides certain entity extensions as part of the base application
configuration. Many of the extension index definitions address performance issues. Other extensions
provide the ability to configure the data model in ways that would not be possible if the extension was
part of the base data model. Do not overwrite a Guidewire extension with your own extension without
understanding the full implications of the change.

PolicyCenter extensions enable you to add new fields to the base data entities. You can add custom fields to
extendable entities only. Not all entities are extendible, but most of the important business entities such as Policy,
User, Contact, and others are extendible. (You can determine if an entity is extendible by looking in the Data
Dictionary to see if it supports the Extendable attribute. The Data Dictionary displays the list of attributes for that
entity type directly underneath the entity name.)
Use the <extension> XML root element to create an extension entity. Before creating a new extension file, first
determine if one already exists.
• If an extension file for the entity does exist, edit that file to extend the entity.
• If an extension file for the entity does not exist, create the new extension file and populate it accordingly.
You can define multiple extensions for base configuration entities and typelist entities. Each extension file must
have a unique name.
You can add a qualifier to a base entity or typelist file name to adhere to the uniqueness constraint. The following
list contains valid entity extension file names with the first name being the base file name and the subsequent file
names having qualifiers:
• [Link]
• [Link]
• [Link]
The following list contains valid typelist extension file names with the first name being the base file name and the
subsequent file names having qualifiers:
• [Link]
• [Link]
• [Link]

Create a new extension file

About this task
The simplest (and safest) way to create a new extension file is to let Studio manage the process.

Procedure
1. In the Studio Project tool window, navigate to configuration→config→Metadata→Entity, and then locate the entity
that you want to extend.
242 chapter 17: Modifying the base data model
 Guidewire PolicyCenter 9.0.9 Configuration Guide

2. Right-click the entity, and then click New→Entity Extension. Studio creates a basically empty extension file
named <entity>.etx, places it in the configuration→config→Extensions→Entity folder, and opens it in a view
tab for editing.
Note: If an extension file for the selected entity file already exists, Studio does not permit you to
create another one. If the file name in the Entity Extension dialog box is grayed out, that means
that an extension already exists. In that case, search in the
configuration→config→Extensions→Entity folder for an existing extension file.
3. Populate the extension with the required attributes.
4. Deploy your changes to the application server.

Next steps
You must redeploy the application after you make any change to the Guidewire PolicyCenter data model. See
“Deploying data model changes to the application server” on page 260 for details.

Working with attribute and element overrides

It is possible to override certain attribute values (fields) and elements on entities that Guidewire defines in files to
which you do not have direct access. For example, you do not have write access to any entity definition files in the
configuration→config→Metadata→Entity subfolders. Guidewire provides a limited number of override elements for use
in .etx extension files in the configuration→config→Extensions folder.
To use an override element:
• If an entity extension file (.etx) already exists in the Extensions folder, then add one of the specified override
elements to the existing file.
• If an entity extension file (.etx) does not already exist in the Extensions folder, then you need to create one and
add an override element to that file.
• If an entity definition file (.eti) exists in the Extensions folder, then you can modify the original field definition.
You do not need to use an override element.
Add override elements only to .etx files in the configuration→config→Extensions folder. Do not attempt to add an
override element to a file in any other folder or to any other file type.
The following list describes the attributes that you can override by using an override element in an .etx file in the
Extensions folder:

Override element Attributes or elements that you can override

<array-override> desc
name
triggersValidation

<column-override> createhistogram
default
desc
name
nullok
supportsLinguisticSearch

Modifying the base data model 243

Guidewire PolicyCenter 9.0.9 Configuration Guide

Override element Attributes or elements that you can override

type
Note: You can override the previous attributes directly with a <column-override> element.
However, to modify data type attributes such as size, logicalSize, and encryption, nest a
<columnParam> subelement under a <column-override> element. Then, set the data type at‐
tributes on the <columnParam> subelement. See “Overriding data type attributes” on page 244
and “Using <column‐override> to modify field validation” on page 301 for examples of this con‐
figuration.
Note: You can override the type attribute of a <column-override> element. However, you can
do so only with a data type that has the same value type as the previous data type of the type
attribute. For example, suppose that the data type of the type attribute is shorttext. Because
the shorttext data type has a value type of [Link], the data type in the attribute
override value must also have the [Link] value type. While longtext would be an
acceptable data type, BigDecimal would not.
<edgeForeignKey- desc
override> extractable
name
overlapTable

<foreignkey-override> desc
importableagainstexistingobject
name
nullok
triggersValidation

<onetoone-override> desc
name
triggersValidation

<typekey-override> default
desc
name
nullok
typefilter
<keyfilters-override>

<keyfilters-override> <keyfilter>

See also

• “Changing the length of a text field” on page 302 for overriding the size data type attribute or the logicalSize
data type attribute.
• “<columnParam> subelement” on page 205 for more information on size, logicalSize, and other data type
attributes.
• “The data types configuration file” on page 285 for the global configuration of data type attributes.
• “The Length attribute” on page 287 for the global configuration of the character length of a column.

Overriding data type attributes

Besides the attributes that you can specifically override using the <column-override> element, you can also modify
data type attributes on a column. You do this through the use of nested <columnParam> subelements within the
<column-override> element.
For example, the base configuration Contact entity defines a TaxID column (in [Link]):
<column createhistogram="true"
desc="Tax ID for the contact (SSN or EIN)."

244 chapter 17: Modifying the base data model

 Guidewire PolicyCenter 9.0.9 Configuration Guide

name="TaxID"
type="ssn"/>

To encrypt the contents of this column (a reasonable course of action), create a Contact extension ([Link])
and use the <column-override> element to set the encryption attribute on the column:
<column-override name="TaxID">
<columnParam name="encryption" value="true"/>
</column-override>

See also
• See “<columnParam> subelement” on page 205 for a description of the <columParam> element and the column
attributes that you can modify using this element.

A desc attribute example

About this task
You can change the description of the Name column for a Document entity as follows:

Procedure
1. Open Guidewire Studio.
2. Navigate to configuration→config→Extensions.
3. Right-click Entity, and then click New Entity Extension.
4. Click Document, and then click OK.
5. In the Primary Value column, right-click Name, and then click override.
6. For the desc attribute, in the Value column, type the new value.

A triggersValidation example
You use the triggersValidation attribute to instruct PolicyCenter whether changes to an array, a foreign key, or a
one-to-one entity initiates validation on that entity. To illustrate, in the base configuration, Guidewire defines the
Account entity in file [Link].
<entity ... entity="Account" ...>
...
<array arrayentity="UserRoleAssignment"
desc="Role Assignments for this account."
exportable="false"
name="RoleAssignments"
triggersValidation="true"/>
...
</entity>

The definition of the RoleAssignments array specifies that if any element of the array changes, the change triggers
a validation of the object graph that includes the array. Suppose, for some reason, that you want to turn off validation
even if changes occur to the RoleAssignments array. To do so, you need to create an extension file with an <array-
override> element that modifies the triggersValidition attribute set on the base data object.
The following steps illustrate this concept.

To override a triggersValidation attribute

1. Create an [Link] file.
a. Find the [Link] file in the Studio configuration tree. You can use Ctrl+N to find the file.
b. Select the file, right-click it, and then click New→Entity Extension.
Studio creates an [Link] file and places it in the configuration→config→Extensions→Entity folder.
2. Populate [Link] with the following:
<?xml version="1.0"?>
<extension xmlns="[Link] entityName="Account">

Modifying the base data model 245

Guidewire PolicyCenter 9.0.9 Configuration Guide

<array-override name="RoleAssignments" triggersValidation="false">

</extension>

3. Stop and restart the application server. The application server recognizes that there are changes to the data
model and automatically runs the upgrade utility on start up.
This effectively switches off the validation that usually occurs on changes to elements of the RoleAssignments
array.

Overriding nested subelements

You can override a nested subelement of an override element. At this time, the only such possibility is with nested
<keyfilter> subelements. These subelements exist inside the body of a <keyfilters> subelement, which is
further contained in the body of a <typekey> element. To effect an override of the nested <keyfilter>
subelements, specify a <keyfilters-override> subelement in the body of a <typekey-override> element. Then,
specify any number of <keyfilter> subelements in the body of the <keyfilters-override> sublement.
In this context, the <keyfilter> elements that you define override or take precedence over all of the <keyfilter>
elements in the bodies of the original <keyfilters> subelement and <typekey> element. For example, suppose the
original <keyfilters> subelement of a <typekey> element contains <keyfilter> subelements A, B, and C.
Further suppose that a <keyfilters-override> subelement of a <typekey-override> element contains
<keyfilter> subelements B, C, and D. In this case, the code ignores the former subelements A, B, and C and gives
effect instead to the latter subelements B, C, and D.
In the following code example are <typekey> and <typekey-override> elements that enable filtered lists of
languages from the United States and Canada respectively:
<typekey
desc="Associates an entity with appropriate lists of languages."
name="Languages"
nullok="false">
<keyfilters>
<keyfilter name="United States Languages"/>
</keyfilters>
</typekey>

<typekey-override
name="Languages">
<keyfilters-override>
<keyfilter name="Canada Languages"/>
</keyfilters-override>
</typekey-override>

Extending the base data model

As described in “Defining a new data entity” on page 240, you can define entirely new custom entities that become
part of the PolicyCenter entity model. You can then use these entities in your data views, rules, and Gosu classes in
exactly the same way as you use the base entities. PolicyCenter makes no distinction between the usage of base
entities and custom entities.

Testing Your Work

After you make any change to the data model, Guidewire recommends that you do the following to test your work.
• First, stop and restart Guidewire Studio. Verify that there are no errors or warnings. If there are, do not proceed
until you have corrected the issues. Guidewire does not strictly require that you always stop and restart Studio
after a data model change. However, it is one way to test that you have not inadvertently made a typing error, for
example.
• After starting Studio, start Guidewire PolicyCenter. As the application server starts, it recognizes that you have
made changes to the database and runs the upgrade utility automatically. Verify that the application server starts
cleanly, without errors or warnings.
246 chapter 17: Modifying the base data model
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Related concepts

“Creating a new delegate object” on page 247

“Extending a delegate object” on page 249
“Defining a subtype” on page 252
“Defining a reference entity” on page 253
“Implementing a many-to-many relationship between entity types” on page 255
“Extending an existing view entity” on page 255

Related tasks

“Define an entity array” on page 253

Creating a new delegate object

Creating a delegate object and associating it to an entity is a relatively straightforward process. It does involve
multiple steps, as do many changes to the data model. To create a new delegate, you need to do the following:

Task Description More information

Step 1: Create the Dele‐ Define the delegate entity using the <delegate> element. “Step 1: Create the delegate ob‐
gate Object ject” on page 247
Step 2: Define the Dele‐ Create a Gosu enhancement to provide any functionality that “Step 2: Define the delegate func‐
gate Functionality you want to expose on your delegate. tionality” on page 248
Step 3: Add the Delegate Use the <implementsEntity> element to associate the dele‐ “Step 3: Add the delegate to the
to the Parent Entity gate with the parent entity. parent entity” on page 248
Step 4: Deploy your Data Deploy your data model changes. You may need to regener‐ “Step 4: Deploy your data model
Model Changes ate any Java API file or web service WSDL files after data changes” on page 249
model changes.

Step 1: Create the delegate object

About this task

The first step in defining a new delegate is to create the delegate file and populate it with the necessary code.

Procedure

1. In Guidewire Studio, in the Project tool window, navigate to configuration→config→Extensions→Entity.

2. Right-click Entity, and then click New→Entity.
3. In the Entity text box, type the name of the delegate.
4. In the Entity Type drop-down list, click delegate.
5. Click OK.
6. Add fields to your new delegate. In the Field drop-down list, select the field type to add, and then click Add .
For information on the possible XML elements that you can add to your new entity definition, see “Data entity
subelements” on page 198.

Next steps

After completing this task, complete “Step 2: Define the delegate functionality” on page 248.
Modifying the base data model 247
Guidewire PolicyCenter 9.0.9 Configuration Guide

Step 2: Define the delegate functionality

Before you begin
Before beginning this task, complete “Step 1: Create the delegate object” on page 247.

About this task

Next, you need to provide functionality for the delegate. While there are several ways to do this, you must use a
Gosu enhancement implementation.

Java class imple‐ In the base configuration, Guidewire provides a Java class implementation for each delegate to provide the
mentation necessary functionality. The Delegate object designates the Java class through the javaClass attribute. It is
not possible for you to create and use a Java class for this purpose.
Gosu enhance‐ You must implement the delegate functionality through a Gosu enhancement that defines any functionality
ment imple‐ associated with the fields on the delegate. By providing the name of the delegate entity to the enhancement
mentation as you create it, you inform Studio that you are adding functionality for that particular delegate. Studio auto‐
matically recognizes that you are enhancing the delegate.

Procedure
1. In Guidewire Studio, in the Project tool window, navigate to configuration→config→gsrc→gw.
This is an example package. In actual practice, you can place the enhancement in a location that makes
business sense.
2. Right-click gw, and then click New→Gosu Enhancement.
3. In the Name text box, type the name of the enhancement.
As a best practice, Guidewire recommends that you use the name of the delegate followed by Enhancement.
For example, if the delegate is named MyDelegate, then name the enhancement MyDelegateEnhancement.
4. In the Enhanced type list, click the name of the delegate entity that you created.
5. Click OK.
6. In the enhancement code window, enter code to provide the necessary functionality. The delegate
automatically has access to all fields and members that you define in the Gosu enhancement.

Next steps
After completing this task, complete “Step 3: Add the delegate to the parent entity” on page 248.

Step 3: Add the delegate to the parent entity

Before you begin
Before beginning this task, complete “Step 2: Define the delegate functionality” on page 248.

About this task

The next step is to associate a delegate with an entity using the <implementsEntity> element in the entity
definition.
• If you are creating a new entity, then you need to add the <implementsEntity> element to the entity definition.
• If you are working with an existing entity, then you need to add the <implementsEntity> element to the entity
extension.

Procedure
1. In Guidewire Studio, in the Project tool window, navigate to the entity to modify, or create a new entity.
2. In the Field drop-down list, click implementsEntity, and then click Add .
248 chapter 17: Modifying the base data model
 Guidewire PolicyCenter 9.0.9 Configuration Guide

3. Next to the name attribute, click the Value drop-down list, and click the name of the delegate.

Next steps
After completing this task, complete “Step 4: Deploy your data model changes” on page 249.

Step 4: Deploy your data model changes

Before you begin
Before beginning this task, complete “Step 3: Add the delegate to the parent entity” on page 248.

About this task

After completing the previous steps, you need to deploy your data model changes. If necessary, see “Deploying data
model changes to the application server” on page 260 for details. Depending on whether you are working in a
development or production environment, you need to perform different tasks. You may need to regenerate any Java
API file or web service WSDL files after data model changes.

Extending a delegate object

Note: A Delegate data object is a reusable entity that contains an interface and a default
implementation of that interface. See “<delegate> elements and related data object types” on page 180
for more information.
Typically, you extend existing delegate objects to provide additional fields and behaviors on the delegate. Through
extension, you can add the following to a delegate object in Guidewire PolicyCenter:
• <column>
• <foreignkey>
• <description>
• <implementsEntity>
• <implementsInterface>
• <index>
• <typekey>
You cannot remove base delegate fields. However, you can modify them to a certain extent—for example, by
making an optional field non-nullable (but not the reverse). You cannot replace the requires attribute on the base
delegate (which specifies the required adapter), but you can implement other delegates.
In Guidewire PolicyCenter, you can extend the following base configuration delegates:
• Auditable
• Cost
• Coverable
• Coverage
• Exclusion
• Modifiable
• Modifier
• PCAssignable
• PolicyCondition
• RateFactor
• Transaction
• UWIssueDelegate
Modifying the base data model 249
Guidewire PolicyCenter 9.0.9 Configuration Guide

Note: In addition to these application-specific delegates, you can extend the following system
delegate: AddressAutofillable.
You can extend a delegate only if the base configuration definition file for that delegate contains the following:
extendable="true"

The default for the extendable attribute on <delegate> is false. Therefore, if it is not set explicitly to true in the
delegate definition file, you cannot extend that delegate.
Do not attempt to change the graph to which a Guidewire base entity belongs through extension. In other words, do
not attempt to change the delegate that a Guidewire base entity implements through an extension entity using
<implementsEntity>. PolicyCenter generates an error if you attempt to do so.

Extend a delegate object

1. Navigate to configuration→config→Extensions→Entity.
2. Right-click and select New→Entity Extension.
3. Enter the name of the delegate that you want to extend and add the .etx extension. Studio opens an empty
file.
4. Enter the delegate definition in the delegate extension file. If necessary, find an existing delegate file and use it
as a model for the syntax. For details, see “Creating a new delegate object” on page 247.

Modifier delegate example

To illustrate, in the base PolicyCenter configuration, PolicyCenter provides a Modifier delegate. PolicyCenter
stores the delegate definition in file [Link], in configuration→config→Metadata→Entity. The following is a
simplified version of this definition file.
<?xml version="1.0"?>
<delegate xmlns="[Link]
effdatedOnly="true"
extendable="true"
javaClass="[Link]"
name="Modifier"
requires="[Link]">
<fulldescription><![CDATA[A list of states and their rating factors (e.g. experience modification
for workers' compensation).]]></fulldescription>
<column desc="Boolean modifier"
name="BooleanModifier"
type="bit"/>
...
</delegate>

This delegate defines the following fields:

• BooleanModifier
• DateModifier
• Eligible
• Justification
• PatternCode
• RateModifier
• ReferenceDateInternal
• TypeKeyModifier
• ValueFinal
• State (type list)
Any entity that wants to use the Modifier delegate functionality must implement this delegate.

250 chapter 17: Modifying the base data model

 Guidewire PolicyCenter 9.0.9 Configuration Guide

The modifier delegate extension

Suppose that you want to extend the definition of the Modifer entity in file [Link] to add additional
columns to the delegate entity. For example:
• OverriddenRateModifier
• SuggestedRateModifier
The delegate extension code looks similar to the following.
<extension
xmlns="[Link]
entityName="Modifier">
<column
desc="The rate modifier that has been overridden."
name="OverriddenRateModifier"
type="rate">
</column>
<column
desc="The rate modifier that the external system has suggested."
name="SuggestedRateModifier"
type="rate">
</column>
</extension>

These fields are then accessible to any entity that implements this delegate. You use these fields to support user
overrides of the modifier rates originally suggested by an external process. All modifiers for all lines of business use
this override process. Thus, by placing this functionality in the Modifier delegate, each entity that implements the
Modifier delegate inherits this functionality, instead of each entity implementing this functionality separately.
Each line of business (LOB) uses one or two LOB-specific modifier entities that implement the Modifier delegate.
For example:
• BAModifier
• BOPModifier
• CPModifier
• GLModifier
• PAModifier
• PAVehicleModifier
• ProductModifier
• WCModifier
Because each of these LOB-specific modifier entities already implements the Modifier entity, each automatically
inherits the Modifier column extensions.
If an entity does not already implement the Modifier delegate, then you need to do one of the following:
• If an extension for that entity already exists in the Extensions folder, then you need to modify that extension file so
that it implements the required delegate. In this case, modify the extension entity and add the following, using the
appropriate adapter name:
<implementsEntity adapter="xxx" name="Modifier"/>

• If an extension for that entity does not exist in the Extensions folder, then you need to create an extension and
have that entity extension implement the required delegate. In this case, right-click the extensions folder and
select New→Other file. Enter the entity name and add the .etx extension. Populate the extension file with
something similar to the following, using the appropriate adapter and entity name (entityName):
<?xml version="1.0"?>
<extension xmlns="[Link] entityName="xxx">
<implementsEntity adapter="xxx" name="Modifier"/>
</extension>

Modifier delegates and arrays

Delegate entities do not support arrays. Thus, the Modifier delegate does not include an array of RateFactor
entities. Instead each concrete modifier type must define its own array of rate factors. Therefore, for each entity that
Modifying the base data model 251
Guidewire PolicyCenter 9.0.9 Configuration Guide

implements the Modifier delegate (for example, BAModifier), there must also be a corresponding entity that
implements the RateFactor delegate (for example, BARateFactor)

Modifier delegates and adapters

Each entity that implements the Modifier delegate must specify an adapter class. Each adapter class must
implement the [Link] interface. This interface implements generic modifier operations
such as returning the owning Modifiable entity and working with the array of rate factors.
Similarly, entities that implement the RateFactor delegate must separately specify an adapter class that implements
the [Link] interface. This adapter needs to define one method only, one that returns
the owning Modifier.
To support out-of-sequence and preemption handling, each modifier type must implement its own matcher class.
Each modifier and rate factor entity must separately implement the [Link]
interface. Guidewire provides the following classes as starting points for configuration:
• [Link]
• [Link]

See also
• “The PolicyCenter data model” on page 169
• “<delegate> elements and related data object types” on page 180
• “<implementsEntity>” on page 214
• “Creating a new delegate object” on page 247
• Product Model Guide

Defining a subtype
A subtype is an entity that you base on another entity (its supertype). The subtype has all of the fields and elements
of its supertype, and it can also have additional ones. You can also create subtypes of subtypes, with no limit to the
depth of the hierarchy.
PolicyCenter does not associate a unique database table with a subtype. Instead, the application stores all subtypes in
the table of its supertype. The supertype table includes a subtype column. The subtype column stores the type
values for each subtype. PolicyCenter uses this column to resolve a subtype.
You define a subtype using the <subtype> element. You must specify certain attributes of the subtype, such as its
name and its supertype (the entity on which PolicyCenter bases the subtype entity). For a description of required and
optional attributes, see “<subtype> elements and related data object types” on page 192.
Within the <subtype> definition, you must define its fields and other elements. For a description of the elements
you can include, see “Data entity subelements” on page 198.

Example
This example defines an Inspector_Ext entity as a subtype of Person. The Inspector_Ext entity includes a field
for the inspector’s business license. To create the Inspector_Ext.eti file
1. In Studio, navigate to configuration→config→Extensions→Entity.
2. Right-click Entity, and then click New→Entity.
3. In the Entity text box, type Inspector_Ext.
4. In the Entity Type drop-down list, click subtype.
5. In the Supertype box, type Person.
6. Click OK.
7. In the Field drop-down list, click column.
252 chapter 17: Modifying the base data model
 Guidewire PolicyCenter 9.0.9 Configuration Guide

8. Set the following properties for the new column:

• name: InspectorLicense_Ext
• type: varchar
• desc: Inspector's business license number
9. In the Field drop-down list, click columnParam.
10. Set the following properties for the new column parameter:
• name: size
• value: 30
Note that while Inspector_Ext is subtype of Person, Person, itself, is a subtype of Contact. PolicyCenter
automatically adds the new Inspector_Ext type to the Contact typelist. This is true, even though PolicyCenter
marks the Contact typelist as final.
To see this change:
• To see this change in the PolicyCenter Data Dictionary, you must restart the application server.
• To see this change in the Contact typelist in Studio, you must restart Studio.

Defining a reference entity

You use a reference entity to store reference data for later access from within PolicyCenter without having to call out
to an external application. For example, you can use reference entities to store:
• Medical payment procedure codes, descriptions, and allowed amounts
• Average reserve amounts, based on coverage and loss type
• PIP aggregate limits, based on state and coverage type
You can populate a reference entity by importing its data, and then you can query it using Gosu expressions. If you
do not want PolicyCenter to update the reference data, set setterScriptability = hidden during entity
definition.

IMPORTANT You can use any entity type as a reference entity. However, if you use the entity solely
for storing and querying reference data, then Guidewire recommends that you use a keyable entity.

Example
This example defines a read-only reference table named ExampleReferenceEntityExt.
<entity entity="ExampleReferenceEntityExt" table="exampleref" type="keyable"
setterScriptability="hidden">
<column name="StringColumn" type="shorttext"/>
<column name="IntegerColumn" type="integer"/>
<column name="BooleanColumn" type="bit"/>
<column name="TextColumn" type="longtext"/>
<index name="internal1">
<indexcol name="StringColumn" keyposition="1"/>
<indexcol name="IntegerColumn" keyposition="2"/>
</index>
</entity>

See also
• “The archive domain graph and reference data” on page 327

Define an entity array

About this task
It is often useful to have a field that contains an array of other entities. For example, to represent that a contact can
contain multiple address, the Contact entity contains the [Link] field, which is an array of
ContactAddresses entities for each Contact data object.
Modifying the base data model 253
Guidewire PolicyCenter 9.0.9 Configuration Guide

As you define the entity for the array, consider the type of entity to use. The general rule, is that if another entity
does not refer to the new entity through a foreign key, then make the entity versionable. Otherwise, make the
entity retireable.

Procedure
1. Define the entity to use as a member of the array. Although you can use one of the PolicyCenter base entities
for an array, it is often likely that you need to define a new entity for this purpose.
2. Define an array field in the entity that contains the array. You can give the field any name you want. It does
not need to be the same name as the array entity.
3. Define a foreign key in the array entity that references the containing entity. PolicyCenter uses this field to
connect an array to a particular data object.

For more information about See

entity types “Overview of data entities” on page 171
defining a new entity “Defining a new data entity” on page 240
defining an array field “<array>” on page 199
defining a foreign key field “<foreignkey>” on page 211

Example
The following example, defines a new retireable entity named ExampleRetireableArrayEntityExt and adds it as
an array to the Policy entity.
The first step is to define the array entity:
<?xml version="1.0"?>
<entity entity="ExampleRetireableArrayEntityExt" table="exampleretarray" type="retireable"
exportable="true">
<column name="StringColumn" type="shorttext"/>
<typekey name="TypekeyColumn" typelist="SystemPermissionType" desc="A test typekey column"/>
<foreignkey name="RetireableFKID" fkentity="ExampleRetireableEntityExt"
desc="FK back to ExampleRetireableEntity" exportable="false"/>
<foreignkey name="KeyableFKID" fkentity="ExampleKeyableEntityExt"
desc="FK through to ExampleKeyableEntity" exportable="false"/>
<foreignkey name="ClaimID" fkentity="Claim" desc="FK back to Claim" exportable="false"/>
<implementsEntity name="Extractable"/>
<index name="internal1" unique="true">
<indexcol name="RetireableFKID" keyposition="1"/>
<indexcol name="TypekeyColumn" keyposition="2"/>
</index>
</entity>

To make this example useful, suppose that you now add this array field to the Policy entity. It is possible that a
Policy entity already exists in the base configuration. Verify that the data type declaration file does not exist before
adding another one. To determine if a Policy extension file already exists, use CTRL-N to search for [Link].
• If the file does exist, then you can modify it.
• If the file does not exist, then you need to create one.
Add the following to [Link].
<extension entityName="Policy" ...>
...
<array arrayentity="ExampleRetireableArrayEntityExt"
desc="An array of ExampleRetireableArrayEntityExt objects."
name="RetireableArrayExt" />
...
</extension>

Next, modify the array entity definition so it includes a foreign key that refers to Policy:
<entity entity="ExampleRetireableArrayEntityExt" table="exampleretarray" ... >
...
<foreignkey name="PolicyID" fkentity="Policy" desc="FK back to Policy" exportable="false"/>
</entity>

254 chapter 17: Modifying the base data model

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Finally, create the two referenced entities, ExampleRetireableEntityExt and ExampleKeyableEntityExt.

Implementing a many‐to‐many relationship between entity types

To add a many-to-many relationship between entity types to the data model, you need to do the following:
• First, create a separate entity with a type attribute of versionable or a child of versionable.
• Add non-nullable foreign keys to each end of the many-to-many relationship.
• Add a unique index on each of the foreign keys.
These steps create a classic join entity.
The following example illustrates how to create a many-to-many relationship between Account and Contact entity
types.
• It first creates a versionable entity, AccountContact, by setting the type attribute to retireable.
• It then defines foreign keys to Account and Contact.
• Finally, it adds indexes to these foreign keys.
The code looks similar to the following:
<entity xmlns="[Link]
entity="AccountContact"
table="accountcontact"
type="retireable"
desc="Join entity modeling many-to-many relationship between Account and Contact entities">
<foreignkey columnName="AccountID"
fkentity="Account"
name="Account"
nullok="false"/>
<foreignkey columnName="ContactID"
fkentity="Contact"
name="Contact"
nullok="false"/>
<index name="accountcontacts" unique="true">
<indexcol keyposition="1" name="AccountID"/>
<indexcol keyposition="2" name="ContactID"/>
</index>
</entity>

To access the relationship, you need to add an array of the new join entities to either end or to both ends of the
relationship. For example:
<extension xmlns="[Link] entityName="Account">
<array arrayentity="AccountContact"
desc="All the AccountContact entities related to Account."
name="AccountContacts"/>
</extension>

This provides an array of AccountContact entities on Account.

Extending an existing view entity

Guidewire uses viewEntity entities to improve performance for list view pages in rendering the PolicyCenter
interface. (See “<viewEntity> elements and related data object types” on page 195 for details.) Some default PCF
pages make use of list view entities and some do not. If you add a new field to an entity, then you need to decide if
you want to extend a viewEntity to include this new field. This can potentially avoid performance degradation.
The following example illustrates a case in which you add an extension both to a primary entity and its
corresponding viewEntity. First search for [Link] to determine if one exists. (Use Ctrl+N to open the
search dialog.)
Add the following to [Link]:
<extension entityName="Activity">
...
<column type="bit"
name="validExt"
default="true"
nullok="true"

Modifying the base data model 255

Guidewire PolicyCenter 9.0.9 Configuration Guide

desc="Sample bit extension, with a default value."/>

...
</extension>

Next, search for [Link]. Suppose that you do not find this file, but you see that
[Link] exists. As this is part of the base configuration, you cannot modify this declaration file.
However, find the highlighted file in Guidewire Studio™ and select New→Entity Extension from the right-click
submenu. This opens a mostly blank file.
Enter the following in [Link]:
<viewEntityExtension entityName="ActivityDesktopView">
<viewEntityColumn name="validExt" path="validExt"/>
</viewEntityExtension>

Note: The path attribute is always relative to the primary entity on which you base the view.
These data model changes add a validExt column (field) to the Activity object, which is also accessible from the
ActivityDesktopView entity.

Extending an existing view entity with a compound data type

If you create or extend a view entity with a column that references a compound data type, you must handle the view
entity extension in a particular manner. If the view entity extension column references a compound data type, then
you need to append the appropriate suffix on the path for the column. This suffix represents the relevant data for the
compound data type.
For example, suppose that in PolicyCenter, you extend the PolicyPeriodSummary view entity. In doing so, you
wish to add a field from the PolicyPeriod entity, TotalPremiumRPT. Looking at the definition of PolicyPeriod,
you see the following:
<monetaryamount
amountColumnName="TotalPremiumRPT" desc="Total amount of all premium (but not taxes or any other costs)
for the entire policy period. The total is denormalized for higher performance UI display and
reporting support."
name="TotalPremiumRPT"
nullok="true"/>

Notice that [Link] is a monetaryamount element. As a consequence, if you extend

PolicyPeriodSummary with this field, you need to define a column for the field with a particular suffix on the path
attribute. Add the following to [Link]:
<viewEntityColumn name="TotalPremiumRPT" path="TotalPremiumRPT_amt"/>

By defining a TotalPremiumRPT column on the view entity, the view entity loads the total reported premium.
The complete extension of the PolicyPeriodSummary view entity will also have a currency type for the
TotalPremiumRPT column. Adding this currency type requires a type key. The name and path for the type key must
have the respective suffixes Cur and _cur. The complete extension of the PolicyPeriodSummary view entity is as
follows:
<viewEntityExtension xmlns="[Link] entityName="PolicyPeriodSummary">
<viewEntityColumn name="TotalPremiumRPT" path="TotalPremiumRPT_amt"/>
<viewEntityTypekey name="TotalPremiumRPTCur" path="TotalPremiumRPT_cur"/>
</viewEntityExtension>

Removing objects from the base configuration data model

It is possible to safely remove certain objects from the base configuration data model. You can do this only if the
object definition is either an .eti file or an .etx file in the configuration→config→Extensions→Entity folder.
The following table lists the objects that you can remove (or hide) in the base configuration:

256 chapter 17: Modifying the base data model

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Object to remove Location File More information

Base configuration entity extensions .eti “Remove a base extension entity” on page 257

Base configuration extension extensions .etx “Remove an extension to a base object” on page 258

Guidewire recommends that you review the material in “Implications of modifying the data model” on page 258
before you remove an object from the data model.

IMPORTANT PolicyCenter provides certain entity extensions as part of the base application
configuration. Many of the extension index definitions address performance issues. Other extensions
provide the ability to configure the data model in ways that would not be possible if the extension was
part of the base data model. Do not modify a PolicyCenter extension without understanding the full
implications of the change.

WARNING Do not attempt to remove a base configuration data object (meaning one defined in the
configuration→config→Metadata folder). Also, do not attempt to remove any extension marked as
internal. Any attempt to do so can invalidate your Guidewire installation, causing the application
server to refuse to start.

Related concepts
“Implications of modifying the data model” on page 258

Related tasks
“Remove a base extension entity” on page 257
“Remove an extension to a base object” on page 258

Remove a base extension entity

About this task
It is possible to remove an extension entity that is part of the base data model. You can only remove an extension
entity that the base configuration defines in the configuration→config→Extensions→Entity folder as an .eti file.
For example, in PolicyCenter, the base configuration includes a number of entity extension files in the Extensions
folder, including:
• RateGLClassCodeExt
• RateWCClassCodeExt
• ...
There are two ways to remove an extension entity from the Extensions folder:
• For entities that Guidewire added as part of the base configuration, you need to edit the entity, remove the current
content, and insert a <deleteEntity> element in its place.
• For entities that you added as part of your customization process, you need merely delete the entity.
In actual practice, you are not removing or deleting either the physical file or the extension itself. You are merely
hiding—or negating—the effects of the extension entity in the data model.

Procedure
1. Open the entity extension .eti file. This file must be located in the extensions folder.
• If the .eti file is one that you created (meaning it is not part of the Guidewire-provided base configuration),
then you merely need to delete the file. You can then omit the next step and continue to step 3.
• If the .eti file is part of the Guidewire-provided base configuration, then continue to the next step.
Modifying the base data model 257
Guidewire PolicyCenter 9.0.9 Configuration Guide

2. Use the <deleteEntity> object to define the extension entity to remove from the data model.
For example, if you want to remove an extension entity named RateGLClassCodeExt, then enter the
following:
<?xml version="1.0"?>
<deleteEntity xmlns="[Link] name="RateGLClassCodeExt" />

3. Stop and restart the application server.

At start up, the application server recognizes a data model change and automatically upgrades the database.

Next steps
If you encounter error messages, or the application server refuses to start, examine your code and correct any issues
before you attempt to continue.

Remove an extension to a base object

About this task
It is also possible to remove an extension to a base data model object. You can only remove an entity extension that
the base configuration defines in the configuration→config→Extensions→Entity folder as an .etx file.
As with the case with extension entities in the Extensions folder, there are two ways to handle the removal of entity
extensions:
• For .etx files that Guidewire added as part of the base configuration, you need to edit the file, remove the
current content, and insert a <deleteEntity> element in its place.
• For .etx files that you added as part of your customization process, you need merely delete the file.

IMPORTANT You cannot delete an extension marked as internal. Any attempt to do so can invalidate
your Guidewire installation, causing the application server to refuse to start.

Procedure
1. Navigate to the extensions folder and open the declaration file for the entity extension that you want to remove.
• If the .etx file is one that you created (meaning it is not part of the Guidewire-provided base configuration),
then you merely need to delete the file. You can then omit the next step and continue to step 3.
• If the .etx file is part of the Guidewire-provided base configuration, then continue to the next step. For
example, suppose that you want to remove (hide) the extension defined in the base configuration for the
Contact entity. In that case, you open [Link] in the Extensions folder.
2. Delete the contents of the declaration file and insert a blank skeleton definition.
For example, for the Contact extension, use the following:
<?xml version="1.0"?>
<extension xmlns="[Link] entityName="Contact"/>

3. Stop and restart the application server.

At start up, the application server recognizes a data model change and automatically upgrades the database.

Next steps
If you encounter error messages, or the application server refuses to start, examine your code and correct any
problems before you attempt to continue.

Implications of modifying the data model

Any change to a data object modifies the underlying PolicyCenter database. Typically, each data entity has a
corresponding table in the database and each object attribute maps to a table column. If you remove or alter a data
object, the possibility exists that your object contains data such as rows in an entity table or data in a column.
258 chapter 17: Modifying the base data model
 Guidewire PolicyCenter 9.0.9 Configuration Guide

This topic covers the following:

• “Does removing an extension make sense?” on page 259
• “Writing SQL for extension removal” on page 259
• “Strategies for handling extension removal” on page 260
• “Troubleshooting modifications to the data model” on page 260

Does removing an extension make sense?

Typically, removing a data object only makes sense in your development environment. If you build a new
configuration, it can sometimes be necessary to remove an object rather than to drop it and to recreate the database.
Dropping the database destroys any data that currently exists. This might not be an option if you share a database
instance with multiple developers. In this case, removing the object is less painful for the development team.
During server start up, PolicyCenter checks for configuration changes, such as modified extensions, that require a
database upgrade. Until the database reflects the underlying configuration, PolicyCenter refuses to start.
However, there are situations in which you modify a data object and the application upgrade process cannot make
the corresponding database modification for you. Currently, the database upgrade tool is unable to implement
extension modifications that require it to do any of the following:
• Change a column from nullable to non-nullable if null values exist in the database column or if there is not a
default value. PolicyCenter refuses to start if there are null values in a non-nullable column.
• Change the underlying data type of a column. For example, changing a varchar column to clob or varchar
column to int.
• Shorten the length of a varchar/text-based column (for example, mediumtext to shorttext) if this truncates
data in the column. If shortening the length does not require truncating existing data, the upgrader can handle
both shortening the length of a varchar column and increasing the length of a varchar column. (It can increase
the length up to 8000 characters for SQL Server.)

Writing SQL for extension removal

Some modifications to the data model can require that you to write an SQL statement to synchronize the database
with the data model. How complex this SQL is depends on what you want to remove. For example, to remove a
field on an object, you need to alter the table and drop the column. However, if your extension includes foreign keys
or indexes, then you need to take into account the referential integrity rules for the database—and your SQL
becomes correspondingly more complex.
In a development environment, you can use the trial-and-error approach to writing your SQL.
In a production environment, in which—typically—there is data to preserve in each extension, the SQL can require
an additional layer of complexity. For example, if you write an SQL statement in which a column type changes, your
SQL can do something similar to the following:
• The SQL creates a temporary column.
• It copies data from the existing extension column to the temporary column.
• It drops the existing extension column.
• It recreates the extension column with its new properties as appropriate.
• It copies the data from the temporary column to the newly recreated column.
• It removes the temporary column.
However, in most cases, this is not necessary as Guidewire provides version triggers that modify the database
automatically if the application detects data model changes. You only need to do manual SQL modification of the
database if you want to modify your own extensions. Even in that case, Guidewire strongly recommends that a
database administrator (DBA) always develop the SQL to use in removing an extension.

Modifying the base data model 259

Guidewire PolicyCenter 9.0.9 Configuration Guide

WARNING Be very careful of making changes to the data model on a live production database.
You can invalidate your installation.

Strategies for handling extension removal

In many development environments, multiple developers all use the same database instance. Before modifying the
data model, first you need to communicate with your team to make them aware of your planned changes. A good
way to communicate your intentions is to provide the team with a list of files that refer to the affected data model
extensions. After communicating with your team, follow a process similar to the following to remove a data model
extension:
1. Remove the extension entity or entity extension using the methods outlined in the following sections:
• “Remove a base extension entity” on page 257
• “Remove an extension to a base object” on page 258
2. Remove any references to the object in other parts of your configuration. If you do not remove these
references, PolicyCenter displays error messages when attempting server start up and the server does not start.
3. Check in your changes.
4. Write code that supports the changes to the database. Implement the IDatamodelUpgrade plugin and write
IDatamodelChange upgrade triggers.
The code in the upgrade trigger runs when you start the PolicyCenter server.
5. Run the gwb compile command to update the resources that the PolicyCenter server uses.
6. Start the PolicyCenter server.
In a production environment, Guidewire recommends that you include formal testing and quality assurance before
removing or modifying an extension. Also, involve your company database administrator (DBA) and any impacted
departments. Guidewire recommends also that you document your change and the reasons for it.

Troubleshooting modifications to the data model

It is possible to change an integer column to a typekey column (and the reverse). However, integer values in the
database do not necessarily map to a valid ID within the referenced typelist table after you make this type of change.
Related to this, removing typecodes from a typelist (instead of retiring them) can cause data inconsistencies as well.
If you have data that references a non-existent typecode, the upgrade does not complete and the server refuses to
start. Instead of removing typecodes, retire them instead.
You can remove an extension field or the entire entity from the data model. If you do this, the server logs an
informational message to the console such as:
pcx_ex_ProviderServicedStates: mismatch in number of columns - 5 in data model, 6 in physical database

Deploying data model changes to the application server

How your deploy changes to the data model depends on if you are working in a development or production
environment.

Development environment
If you are working in a development environment, then do the following:
1. Use the following command to regenerate the Data Dictionary so that it reflects your data model changes:
gwb genDataDictionary

2. Stop and restart both the application server and Studio. As the application server and Studio share the same
file structure in the development environment, you need only restart the development application server to
pick up these changes.
260 chapter 17: Modifying the base data model
 Guidewire PolicyCenter 9.0.9 Configuration Guide

If necessary (and it is almost always necessary if you change the data model), PolicyCenter runs the database
upgrade tool during application start up.

Production environment
If you are working in a production environment, then do the following:
1. Use the following command to regenerate the Data Dictionary so that it reflects your data model changes:
gwb genDataDict

2. Create a .war or .ear file using one of the build commands.

For information on how to use these commands, see the Installation Guide.
3. Copy this file to the application server. The target location of the file is dependent on the application server.
If necessary (and it is almost always necessary if you change the data model), PolicyCenter runs the database
upgrade tool during application start up.

Modifying the base data model 261

Guidewire PolicyCenter 9.0.9 Configuration Guide

262 chapter 17: Modifying the base data model

chapter 18

Example: Creating assignable entities

This topic describes how to modify the Guidewire data model. It illustrates how to construct a data entity and make
it assignable.

Creating an assignable extension entity type

To create an assignable extension entity type, perform the following steps:
• “Step 1: Create extension entity type UserAssignableEntity_Ext” on page 263
• “Step 2: Create assignment class NewAssignableMethodsImpl” on page 265
• “Step 3: Test assignment of your extension entity instance” on page 266

IMPORTANT The code and objects in this example refer to Guidewire ClaimCenter. However, the
principles involved in extending the data model apply to all Guidewire applications.

Step 1: Create extension entity type UserAssignableEntity_Ext

The first step in creating an assignable entity type is to create the entity or extend the entity if it already exists.

About this task

The assignable entity type implements the following:
• CCAssignable delegate class
• CCAssignableMethods interface
The entity type must link to a Gosu class that defines the necessary assignment methods and properties. The
following procedure creates a new extension entity that implements NewAssignableMethodsImpl, a delegate class.

Procedure
1. Create the new extension entity file.
a. In Studio, navigate to configuration→config→extensions→Entity.
b. Right-click Entity and select New→Entity.
2. Provide the required information for the new entity definition.
a. Enter the name of the extension entity in the text field.
To follow the rest of this procedure, use the name UserAssignableEntity_Ext.
Example: Creating assignable entities 263
Guidewire PolicyCenter 9.0.9 Configuration Guide

b. In Entity Type, select entity.

c. In Desc, type:
Assignable extension entity, for testing
d. In Type, select retireable.
e. Select the check boxes Extendable and Final.
f. Click OK.
3. In the entity editor, add the following items to UserAssignableEntity_Ext.

Element type Attribute Value

fulldescription Simple entity that you can assign. This entity does not have a foreign
key.

implementsEntity name CCAssignable

implementsInterface iface [Link]

impl [Link]

column name InstanceUpdateTime

type datetime

nullok true

column name VarcharColumn

type varchar

nullok true

columnparam name size

value 60

typekey name Country

typelist Country

nullok true

typekey name PhoneType

typelist PhoneType

nullok true

index name internal1

indexcol name VarcharColumn

keyposition 1

Result

Notice the following:

• Entity UserAssignableEntity_Ext implements the CCAssignable delegate.
• Entity UserAssignableEntity_Ext uses class NewAssignableMethodsImpl, which implements the
CCAssignableMethods interface, to define the necessary assignment methods and properties.

Next steps

• “Step 2: Create assignment class NewAssignableMethodsImpl” on page 265

• “Step 3: Test assignment of your extension entity instance” on page 266
264 chapter 18: Example: Creating assignable entities
 Guidewire PolicyCenter 9.0.9 Configuration Guide

See also
• For information on how to extend the data model, see “Modifying the base data model” on page 237.
• For information on the data model in general, see “The PolicyCenter data model” on page 169.

Step 2: Create assignment class NewAssignableMethodsImpl

Any new assignable entity must implement the CCAssignableMethods interface.

Before you begin

• “Step 1: Create extension entity type UserAssignableEntity_Ext” on page 263

About this task

The following procedure defines a delegate class that provides an implementation of the methods in the
CCAssignableMethods interface. In the example, the NewAssignableMethodsImpl class extends the abstract
superclass CCAssignableMethodsBaseImpl. The CCAssignableMethodsBaseImpl abstract superclass provides
standard implementations of some of the functionality for which the CCAssignableMethods interface provides
method signatures.

Procedure
1. Create a new class file in the package [Link] and name it NewAssignableMethodsImpl.
a. In Studio, navigate to configuration→gsrc→gw→assignment.
b. Right-click assignment and select New→Gosu Class.
c. Enter the name of the class in the text box.
For this example, enter the following class name.
NewAssignableMethodsImpl

d. Click OK.
Studio creates a skeleton class file in the assignment folder and opens the file in an editor tab.
2. Have your class do one of the following.
• Implement the interface [Link].
• Extend the abstract superclass [Link].
Which of these options you implement depends on your business needs. In either case, you must provide
method bodies for all unimplemented methods. To determine what methods you need to implement, you need
merely to have your class implement the interface or extend the abstract superclass.
In this example, you extend the abstract superclass. Make the class declaration look like the following line.
class NewAssignableMethodsImpl extends CCAssignableMethodsBaseImpl {

The editor shows an error at CCAssignableMethodsBaseImpl.

3. Press Alt-Enter and click Import class.
4. Press Alt-Enter and click Implement methods. Then, click OK.
Studio provides skeleton method overrides for all the abstract methods in the
[Link] class. In later steps, you also override other methods
that the abstract class implements.
5. Add a constructor to the class by entering the following code before the first overridden method.
construct(testEntity : UserAssignableEntity_Ext) {
super(testEntity)
}

6. Add the following methods that override methods in CCAssignableMethodsBaseImpl.

override property get Owner() : UserAssignableEntity_Ext {
return [Link] as UserAssignableEntity_Ext

Example: Creating assignable entities 265

Guidewire PolicyCenter 9.0.9 Configuration Guide

override function shouldCascadeAssignment(parent : Assignable, defaultOwnerUserId : Key,

defaultGroupId : Key) : boolean {
return false
}

7. To resolve the error indication, press Alt-Enter and click Import class. Import the class
[Link].

Result
Your new class looks like the following code.
package [Link]

uses [Link]
uses [Link]
uses [Link]
uses [Link]

class NewAssignableMethodsImpl extends CCAssignableMethodsBaseImpl {

construct(testEntity : UserAssignableEntity_Ext) {
super(testEntity)
}

override property get AssignmentReviewActivitySubject() : String {

return null
}

override property get AssignmentReviewActivityLinkProperty() : ILinkPropertyInfo {

return null
}

override property get OwningClaim() : Claim {

return null
}

override function pushAssignmentPopup(list : List<CCAssignableMethods>) {

override property get ChildrenForCascadeAssignment() : List<CCAssignableMethods> {

return null
}

override property get Owner() : UserAssignableEntity_Ext {

return [Link] as UserAssignableEntity_Ext
}

override function shouldCascadeAssignment(parent : Assignable, defaultOwnerUserId : Key,

defaultGroupId : Key) : boolean {
return false
}
}

Next steps
• “Step 3: Test assignment of your extension entity instance” on page 266

Step 3: Test assignment of your extension entity instance

Before you begin
• “Step 1: Create extension entity type UserAssignableEntity_Ext” on page 263
• “Step 2: Subclass class AssignmentType” on page 270

About this task

After you create an assignable entity type, test your work to verify that your entity definition and associated Gosu
code are correct. Because you have changed the data model, you first restart the server to force a database upgrade.
266 chapter 18: Example: Creating assignable entities
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Procedure
1. Stop the server, if it is running.
2. Start the server from within Studio.
3. Correct any problems that occur and repeat the previous steps until the server starts without errors.
4. If you have not already done so, load the demonstration data into the database.
The next step requires this data.
5. Click Tools→Gosu Scratchpad to open the Studio Gosu Scratchpad.
6. Enter the following code in the Gosu Scratchpad tab.

uses [Link]
uses [Link]
uses [Link]

var _users = [Link](User).join(User#Credential).compare(Credential#UserName, Equals, "aapplegate")

var _usr = _users.select().AtMostOneRow
var _group = _usr.GroupUsers[0].Group
[Link](\bundle -> {
var newExtEntity = new UserAssignableEntity_Ext()
// Assign the entity to the specified user and group
print([Link](_group, _usr) + "\t\t\tThe assign method succeeded. Thus, it returns true.")
print([Link] + "\tThe user that is assigned the newExtEntity (UserAssignableEntity_Ext)
object.")
print([Link] + "\tThe group that is assigned the newExtEntity (UserAssignableEntity_Ext)
object.")
}, "su")

7. Click Run.
Output similar to the following lines appears in the Console tab.
true The assign method succeeded. Thus, it returns true.
Andy Applegate The user that is assigned the newExtEntity (UserAssignableEntity_Ext) object.
Auto1 - TeamA The group that is assigned the newExtEntity (UserAssignableEntity_Ext) object.

Making your extension entity type eligible for round‐robin

assignment
To assign an entity instance through round-robin assignment, you invoke the assignUserByRoundRobin method on
the entity instance. To implement round-robin assignment on the assignable entity type, you need to add extra
tracking properties for the round-robin state to the following entity types:
• DynamicAssignmentState
• GroupAssignmentState
• GroupUserAssignmentState
For an entity type in the base configuration, you add these properties as an extension. For a custom entity type, you
create an extension entity with the necessary properties.
Finally, you create a new Gosu class that extends (subclasses) the AssignmentType class. You add methods to this
subclass so that the round-robin infrastructure can find the newly added properties.
The following procedures assume the existence of an assignable entity type named UserAssignableEntity_Ext.
The steps in “Creating an assignable extension entity type” on page 263 describe how to create this entity.
This example requires the following steps:
• “Step 1: Extend the AssignmentState entity types” on page 268
• “Step 2: Subclass class AssignmentType” on page 270
• “Step 3: Create class UserAssignableEntityExtEnhancement” on page 271
• “Step 4: Test round-robin assignment” on page 272
Example: Creating assignable entities 267
Guidewire PolicyCenter 9.0.9 Configuration Guide

IMPORTANT The code and objects in this example refer to Guidewire ClaimCenter. However, the
principles involved in extending the data model apply to all Guidewire applications.

Step 1: Extend the AssignmentState entity types

You extend AssignmentState entity types to add fields on the object that ClaimCenter uses to track information for
the round robin state.

Before you begin

• “Creating an assignable extension entity type” on page 263

About this task

The first step in creating an entity type that you can use with round-robin assignment is to extend the following base
configuration entity types:
• DynamicAssignmentState
• GroupAssignmentState
• GroupUserAssignmentState

Procedure
1. In Guidewire Studio, open [Link] for editing or create a new entity extension.
a. Press Ctrl-N and start entering the entity type name.
Studio displays a number of matches because files with the name DynamicAssignmentState already
exist.
b. If [Link] appears in the list, double-click that file.
c. If [Link] is not in the list, create a new extension by navigating to
configuration→config→extensions→Entity. Right-click Entity and select New→Entity Extension. Enter
DynamicAssignmentState and click OK.
2. In the entity editor, add the following items to the DynamicAssignmentState extension.

Element type Attribute Value

foreignkey name LastTEAEUser

fkentity User

nullok true

columnName LastTEAEUserId

foreignkey name LastTEAEGrp

fkentity Group

nullok true

columnName LastTEAEGrpId

foreignkey name LastTCAUser

fkentity User

nullok true

columnName LastTCAUserId

foreignkey name LastTCAGrp

fkentity Group

268 chapter 18: Example: Creating assignable entities

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Element type Attribute Value

nullok true

columnName LastTCAGrpId

3. Add fields to the file [Link]. If this file does not exist, you need to create it. Follow the
instructions in In Guidewire Studio, open [Link] for editing or create a new entity
extension. to search for [Link].
4. In the entity editor, add the following items to the GroupAssignmentState extension.

Element type Attribute Value

foreignkey name LastTEAEUser

fkentity User

nullok true

columnName LastTEAEUserId

foreignkey name LastTEAEGrp

fkentity Group

nullok true

columnName LastTEAEGrpId

foreignkey name LastTCAUser

fkentity User

nullok true

columnName LastTCAUserId

foreignkey name LastTCAGrp

fkentity Group

nullok true

columnName LastTCAGrpId

column name TEAELoad

type integer

nullok true

column name TCALoad

type integer

nullok true

5. Add fields to the file [Link]. If this file does not exist, you need to create it.
Follow the instructions in In Guidewire Studio, open [Link] for editing or create a
new entity extension. to search for [Link].
6. In the entity editor, add the following items to the GroupUserAssignmentState extension.

Element type Attribute Value

column name TEAELoad

type integer

nullok true

Example: Creating assignable entities 269

Guidewire PolicyCenter 9.0.9 Configuration Guide

Element type Attribute Value

column name TCALoad

type integer

nullok true

Next steps
• “Step 2: Subclass class AssignmentType” on page 270
• “Step 3: Create class UserAssignableEntityExtEnhancement” on page 271
• “Step 4: Test round-robin assignment” on page 272

Step 2: Subclass class AssignmentType

The AssignmentType class contains getter and setter methods that inform the round-robin mechanism of the
location of fields in the AssignmentState entity types.

Before you begin

• “Step 1: Extend the AssignmentState entity types” on page 268

About this task

Now, you need to create a subclass of the AssignmentType class to access the entity fields that you created in the
previous step.

Procedure
1. Create a new class file in the package [Link] and name it
UserAssignableEntityExtAssignmentType.
a. In Studio, navigate to configuration→gsrc→gw→assignment.
b. Right-click assignment and select New→Gosu Class.
c. Enter the name of the class in the text box.
For this example, enter the following class name.
UserAssignableEntityExtAssignmentType

Studio creates a skeleton class file in the assignment folder and opens the file in an editor tab.
2. Enter the following code in your class file.
package [Link]

uses [Link]
uses [Link]
uses [Link]

class UserAssignableEntityExtAssignmentType extends AssignmentType {

construct() {}

override function getLastAssignedUser(groupState : GroupAssignmentState) : Key {

return [Link]
}

override function getLastAssignedUser(dynamicState : DynamicAssignmentState) : Key {

return [Link]
}

override function setLastAssignedUser(groupState : GroupAssignmentState, user : Key) {

[Link] = [Link](user) as User
}

override function setLastAssignedUser(dynamicState : DynamicAssignmentState, user : Key) {

270 chapter 18: Example: Creating assignable entities

 Guidewire PolicyCenter 9.0.9 Configuration Guide

[Link] = [Link](user) as User

}

override function getUserLoad(groupUserState : GroupUserAssignmentState) : int {

return [Link]
}

override function setUserLoad(groupUserState : GroupUserAssignmentState, load : int) {

[Link] = load
}

override function getLastAssignedGroup(groupState : GroupAssignmentState) : Key {

return [Link]
}

override function getLastAssignedGroup(dynamicState : DynamicAssignmentState) : Key {

return [Link]
}

override function setLastAssignedGroup(groupState : GroupAssignmentState, group : Key) {

[Link] = [Link](group) as Group
}

override function setLastAssignedGroup(dynamicState : DynamicAssignmentState, group : Key) {

[Link] = [Link](group) as Group
}

override function getGroupLoad(groupState : GroupAssignmentState) : int {

return [Link]
}

override function setGroupLoad(groupState : GroupAssignmentState, load : int) {

[Link] = load
}

protected override property get AssignableClass() : IEntityType {

return UserAssignableEntity_Ext
}
}

Studio indicates that the code is invalid in the get AssignableClass method definition because you have not
yet created the necessary UserAssignableEntity_Ext Gosu enhancement. You create this entity
enhancement in the next step.

Next steps
• “Step 3: Create class UserAssignableEntityExtEnhancement” on page 271
• “Step 4: Test round-robin assignment” on page 272

Step 3: Create class UserAssignableEntityExtEnhancement

You create an enhancement to the UserAssignableEntity_Ext entity type for use in creating instances of that type.

Before you begin

• “Step 1: Extend the AssignmentState entity types” on page 268
• “Step 2: Subclass class AssignmentType” on page 270

Procedure
1. Create a new enhancement file and name it UserAssignableEntityExtEnhancement.
a. In Studio, navigate to configuration→gsrc→gw→assignment.
b. Right-click assignment and select New→Gosu Enhancement.
c. Enter the UserAssignableEntity_Ext in the Enhanced type text box.
The text that you enter filters the available entity types. If multiple selections are shown, ensure that you
select UserAssignableEntity_Ext. This entity type is the one that you need to enhance.
d. Enter the name of the class in the Type to enhance text box.
Example: Creating assignable entities 271
Guidewire PolicyCenter 9.0.9 Configuration Guide

For this example, enter the following class name.

UserAssignableEntityExtEnhancement

Studio creates a skeleton class file in the assignment folder and opens the file in an editor tab.
e. Click OK.
2. Enter the following code in the enhancement file.
package [Link]

uses [Link]

enhancement UserAssignableEntityExtEnhancement : UserAssignableEntity_Ext {

static property get ASSIGNMENT_TYPE() : AssignmentType {
return new UserAssignableEntityExtAssignmentType()
}
}

Next steps
• “Step 4: Test round-robin assignment” on page 272

Step 4: Test round‐robin assignment

After you create an assignable entity type that is suitable for use with round-robin assignment, you must test your
work to verify that you have performed the previous steps correctly.

Before you begin

• “Step 1: Extend the AssignmentState entity types” on page 268
• “Step 2: Subclass class AssignmentType” on page 270
• “Step 3: Create class UserAssignableEntityExtEnhancement” on page 271

About this task

Because you have changed the data model, you first restart the server to force a database upgrade.

Procedure
1. Stop the server, if it is running.
2. Start the server from within Studio.
3. Correct any problems that occur and repeat the previous steps until the server starts without errors.
4. If you have not already done so, load the demonstration data into the database.
The next step requires this data.
5. Click Tools→Gosu Scratchpad to open the Studio Gosu Scratchpad.
6. Enter the following code in the Gosu Scratchpad tab.
uses [Link]
uses [Link]
uses [Link]

var _users = [Link](User).join(User#Credential).compare(Credential#UserName, Equals, "aapplegate")

var _usr = _users.select().AtMostOneRow
var _group = _usr.GroupUsers[0].Group
[Link](\bundle -> {
for (i in 1..3) {
print("Pass " + i + ":")
var newExtEntity = new UserAssignableEntity_Ext()
// Assign the entity to the specified user and group
print([Link](_group, _usr) + "\t\t\tThe assign method succeeded. Thus, it returns true.")
print([Link] + "\tThe user that is assigned the newExtEntity (UserAssignableEntity_Ext)
object.")
print([Link] + "\tThe group that is assigned the newExtEntity
(UserAssignableEntity_Ext) object.")

272 chapter 18: Example: Creating assignable entities

 Guidewire PolicyCenter 9.0.9 Configuration Guide

var assignedToUser = [Link](false, _group)

print("\t" + assignedToUser + "\t\t\tThe assignUserByRoundRobin method succeeded. Thus, it returns true.")
print("\t" + [Link] + "\tThe assignUserByRoundRobin method assigns the object to the
next person in the group.")
}
}, "su")

7. Click Run.
Output similar to the following lines appears in the Console tab.
Pass 1:
true The assign method succeeded. Thus, it returns true.
Andy Applegate The user that is assigned the newExtEntity (UserAssignableEntity_Ext) object.
Auto1 - TeamA The group that is assigned the newExtEntity (UserAssignableEntity_Ext) object.
true The assignUserByRoundRobin method succeeded. Thus, it returns true.
Andy Applegate The assignUserByRoundRobin method assigns the object to the next person in the group.
Pass 2:
true The assign method succeeded. Thus, it returns true.
Andy Applegate The user that is assigned the newExtEntity (UserAssignableEntity_Ext) object.
Auto1 - TeamA The group that is assigned the newExtEntity (UserAssignableEntity_Ext) object.
true The assignUserByRoundRobin method succeeded. Thus, it returns true.
Sue Smith The assignUserByRoundRobin method assigns the object to the next person in the group.
Pass 3:
true The assign method succeeded. Thus, it returns true.
Andy Applegate The user that is assigned the newExtEntity (UserAssignableEntity_Ext) object.
Auto1 - TeamA The group that is assigned the newExtEntity (UserAssignableEntity_Ext) object.
true The assignUserByRoundRobin method succeeded. Thus, it returns true.
Betty Baker The assignUserByRoundRobin method assigns the object to the next person in the group.

Creating an assignable extension entity type that uses foreign

keys
To create an assignable extension entity type with foreign key links to Claim and Activty, perform the following
steps:
• “Step 1: Create extension entity type TestClaimAssignable_Ext” on page 273
• “Step 2: Add foreign keys to assignable entity types” on page 275
• “Step 3: Create new assignment type for extension entity type TestClaimAssignable_Ext” on page 275
• “Step 4: Create enhancement class TestClaimAssignableExtEnhancement” on page 277
• “Step 5: Create delegate class TestClaimAssignableMethodsImpl” on page 278
• “Step 6: Add the necessary permission for the extension entity type” on page 279
• “Step 7: Test assignment of the assignable entity type” on page 281

IMPORTANT The code and objects in this example refer to Guidewire ClaimCenter. However, the
principles involved in extending the data model apply to all Guidewire applications.

Step 1: Create extension entity type TestClaimAssignable_Ext

Before you begin
• “Making your extension entity type eligible for round-robin assignment” on page 267

About this task

The first step is to create the assignable entity type. As with any assignable entity type, it must implement the
following:
• CCAssignable delegate class
• CCAssignableMethods interface
Example: Creating assignable entities 273
Guidewire PolicyCenter 9.0.9 Configuration Guide

Procedure
1. Create the new extension entity type.
a. In Studio, navigate to configuration→config→extensions→Entity.
b. Right-click Entity and select New→Entity.
2. Provide the required information for the new entity type definition.
a. Enter the name of the extension entity type in the text field.
To follow the rest of this procedure, use the name TestClaimAssignable_Ext.
b. In Entity Type, select entity.
c. In Desc, type:
CCAssignable extension entity, which has a foreign key back to Claim, used for testing
d. In Type, select retireable.
e. Select the check boxes Extendable and Final.
f. Click OK.
3. In the entity editor, add the following items to TestClaimAssignable_Ext.

Element type Attribute Value

exportable true

fulldescription Simple test assignable with a foreign key back to Claim. This foreign
key, together with the CCAssignableMethods delegate in
TestClaimAssignableMethodsImpl, allows this entity type to participate
in manual assignment, assignment to claim owner and cascading. An
instance of this type also creates history events as it is assigned.

implementsEntity name Extractable

implementsEntity name CCAssignable

implementsInterface iface [Link]

impl [Link]

foreignkey name Claim

fkentity Claim

nullok false

columnName ClaimID

desc The Claim for this test assignable

exportable false

Result
Notice the following:
• Entity TestClaimAssignable_Ext implements the CCAssignable delegate.
• Entity TestClaimAssignable_Ext uses class TestClaimAssignableMethodsImpl, which implements the
CCAssignableMethods interface, to define the necessary assignment methods and properties.
• Entity TestClaimAssignable_Ext has a foreign key back to Claim.

Next steps
• “Step 2: Add foreign keys to assignable entity types” on page 275
• “Step 3: Create new assignment type for extension entity type TestClaimAssignable_Ext” on page 275
• “Step 4: Create enhancement class TestClaimAssignableExtEnhancement” on page 277
274 chapter 18: Example: Creating assignable entities
 Guidewire PolicyCenter 9.0.9 Configuration Guide

• “Step 5: Create delegate class TestClaimAssignableMethodsImpl” on page 278

• “Step 6: Add the necessary permission for the extension entity type” on page 279
• “Step 7: Test assignment of the assignable entity type” on page 281

Step 2: Add foreign keys to assignable entity types

To link your assignable entity type to a base configuration assignable entity type, you need a foreign key from that
base configuration entity type to your assignable entity type.

Before you begin

• “Step 1: Create extension entity type TestClaimAssignable_Ext” on page 273

Procedure
1. In Guidewire Studio, open [Link] for editing or create a new entity extension.
a. Press Ctrl-N and start entering the entity type name.
Studio displays a number of matches because files with the name Claim already exist.
b. Find [Link] in the list and double-click that file.
2. In the entity editor, add the following items to the Claim extension.

Element type Attribute Value

array name TestClaimAssignables

arrayentity TestClaimAssignable_Ext

desc Test assignables for this claim

3. Add fields to the file [Link]. If this file does not exist, you need to create it. Follow the instructions in
In Guidewire Studio, open [Link] for editing or create a new entity extension. to search for
[Link].
4. In the entity editor, add the following items to the Activity extension.

Element type Attribute Value

foreignkey name TestClaimAssignable

arrayentity TestClaimAssignable_Ext

nullok true

Next steps
• “Step 3: Create new assignment type for extension entity type TestClaimAssignable_Ext” on page 275
• “Step 4: Create enhancement class TestClaimAssignableExtEnhancement” on page 277
• “Step 5: Create delegate class TestClaimAssignableMethodsImpl” on page 278
• “Step 6: Add the necessary permission for the extension entity type” on page 279
• “Step 7: Test assignment of the assignable entity type” on page 281

Step 3: Create new assignment type for extension entity type

TestClaimAssignable_Ext
The AssignmentType class contains getter and setter methods that inform the round-robin mechanism of the
location of fields in the AssignmentState entity types.
Example: Creating assignable entities 275
Guidewire PolicyCenter 9.0.9 Configuration Guide

Before you begin

• “Step 1: Create extension entity type TestClaimAssignable_Ext” on page 273
• “Step 2: Add foreign keys to assignable entity types” on page 275

Procedure
1. Create a new class file in the package [Link] and name it
TestClaimAssignableExtAssignmentType.
a. In Studio, navigate to configuration→gsrc→gw→assignment.
b. Right-click assignment and select New→Gosu Class.
c. Enter the name of the class in the text box.
For this example, enter the following class name.
TestClaimAssignableExtAssignmentType

Studio creates a skeleton class file in the assignment folder and opens the file in an editor tab.
d. Click OK.
Studio creates a skeleton class file in the assignment folder and opens the file in an editor tab.
2. Enter the following code in the class file.
package [Link]

uses [Link]
uses [Link]
uses [Link]

class TestClaimAssignableExtAssignmentType extends AssignmentType {

construct() { }

override function getLastAssignedUser(groupState : GroupAssignmentState) : Key {

return [Link]
}

override function getLastAssignedUser(dynamicState : DynamicAssignmentState) : Key {

return [Link]
}

override function setLastAssignedUser(groupState : GroupAssignmentState, user : Key) {

[Link] = [Link](user) as User
}

override function setLastAssignedUser(dynamicState : DynamicAssignmentState, user : Key) {

[Link] = [Link](user) as User
}

override function getUserLoad(groupUserState : GroupUserAssignmentState) : int {

return [Link]
}

override function setUserLoad(groupUserState : GroupUserAssignmentState, load : int) {

[Link] = load
}

override function getLastAssignedGroup(groupState : GroupAssignmentState) : Key {

return [Link]
}

override function getLastAssignedGroup(dynamicState : DynamicAssignmentState) : Key {

return [Link]
}

override function setLastAssignedGroup(groupState : GroupAssignmentState, group : Key) {

[Link] = [Link](group) as Group
}

override function setLastAssignedGroup(dynamicState : DynamicAssignmentState, group : Key) {

[Link] = [Link](group) as Group
}

276 chapter 18: Example: Creating assignable entities

 Guidewire PolicyCenter 9.0.9 Configuration Guide

override function getGroupLoad(groupState : GroupAssignmentState) : int {

return [Link]
}

override function setGroupLoad(groupState : GroupAssignmentState, load : int) {

[Link] = load
}

protected override property get AssignableClass() : IEntityType {

return TestClaimAssignable_Ext
}
}

Next steps
• “Step 4: Create enhancement class TestClaimAssignableExtEnhancement” on page 277
• “Step 5: Create delegate class TestClaimAssignableMethodsImpl” on page 278
• “Step 6: Add the necessary permission for the extension entity type” on page 279
• “Step 7: Test assignment of the assignable entity type” on page 281

Step 4: Create enhancement class TestClaimAssignableExtEnhancement

Create an enhancement to the TestClaimAssignable_Ext entity type for use in creating entities of that type.

Before you begin

• “Step 1: Create extension entity type TestClaimAssignable_Ext” on page 273
• “Step 2: Add foreign keys to assignable entity types” on page 275
• “Step 3: Create new assignment type for extension entity type TestClaimAssignable_Ext” on page 275

Procedure
1. Create a new enhancement file and name it TestClaimAssignableExtEnhancement.
a. In Studio, navigate to configuration→gsrc→gw→assignment.
b. Right-click assignment and select New→Gosu Enhancement.
c. Enter the TestClaimAssignable_Ext in the Enhanced type text box.
d. Enter the name of the class in the Type to enhance text box.
For this example, enter the following class name.
TestClaimAssignableExtEnhancement

Studio creates a skeleton class file in the assignment folder and opens the file in an editor tab.
e. Click OK.
2. Enter the following code in the enhancement file.
package [Link]

uses [Link]

enhancement TestClaimAssignableExtEnhancement : TestClaimAssignable_Ext {

static property get ASSIGNMENT_TYPE() : AssignmentType {
return new TestClaimAssignableExtAssignmentType()
}
}

Next steps
• “Step 5: Create delegate class TestClaimAssignableMethodsImpl” on page 278
• “Step 6: Add the necessary permission for the extension entity type” on page 279
• “Step 7: Test assignment of the assignable entity type” on page 281
Example: Creating assignable entities 277
Guidewire PolicyCenter 9.0.9 Configuration Guide

Step 5: Create delegate class TestClaimAssignableMethodsImpl

Any new assignable entity type must implement the CCAssignableMethods interface.

Before you begin

• “Step 1: Create extension entity type TestClaimAssignable_Ext” on page 273
• “Step 2: Add foreign keys to assignable entity types” on page 275
• “Step 3: Create new assignment type for extension entity type TestClaimAssignable_Ext” on page 275
• “Step 4: Create enhancement class TestClaimAssignableExtEnhancement” on page 277

About this task

The TestClaimAssignable_Ext entity type that you created specified the delegate class
TestClaimAssignableMethodsImpl to implement the CCAssignableMethods interface.
The following procedure defines a delegate class that provides an implementation of the methods in the
CCAssignableMethods interface. In this example, the TestClaimAssignableMethodsImpl class extends the
abstract superclass CCAssignableMethodsBaseImpl. The CCAssignableMethodsBaseImpl abstract superclass
provides standard implementations of some of the functionality for which the CCAssignableMethods interface
provides method signatures.

Procedure
1. Create a new class file in the package [Link] and name it TestClaimAssignableMethodsImpl.
a. In Studio, navigate to configuration→gsrc→gw→assignment.
b. Right-click assignment and select New→Gosu Class.
c. Enter the name of the class in the text box.
For this example, enter the following class name.
TestClaimAssignableMethodsImpl

d. Click OK.
Studio creates a skeleton class file in the assignment folder and opens the file in an editor tab.
2. Enter the following code in the file.
package [Link]

uses [Link]
uses [Link]
uses [Link]
uses [Link]

/**
* Example CCAssignableMethods implementation for an assignable entity that is related to a claim,
* and which can be manually assigned, assigned to claim owner, or cascaded. Also creates a history
* event as it is assigned.
*/

class TestClaimAssignableMethodsImpl extends CCAssignableMethodsBaseImpl {

construct(testEntity : TestClaimAssignable_Ext) {
super(testEntity)
}

override property get AssignmentReviewActivitySubject() : String {

return "Test Claim Assignable Assignment Review"
}

override property get AssignmentReviewActivityLinkProperty() : ILinkPropertyInfo {

return [Link]("TestClaimAssignable") as ILinkPropertyInfo
}

override property get Owner() : TestClaimAssignable_Ext {

return [Link] as TestClaimAssignable_Ext
}

278 chapter 18: Example: Creating assignable entities

 Guidewire PolicyCenter 9.0.9 Configuration Guide

override property get OwningClaim() : Claim {

return [Link]
}

override function pushAssignmentPopup(assignables : List<CCAssignableMethods>) {

// Needed for user interface
[Link]
([Link](TestClaimAssignable_Ext).toTypedArray())
}

override property get ChildrenForCascadeAssignment() : List<CCAssignableMethods> {

return null
}

override function createAssignmentHistoryEvent(assignable : Assignable) : History {

var result = [Link](assignable)
[Link] = "Test Claim Assignable History Event"
return result
}

override function shouldCascadeAssignment(parent : Assignable,

defaultOwnerUserId : Key,
defaultGroupId : Key) : boolean {
return true
}
}

Studio indicates that your newly created class contains a serious error because there is no method definition
for [Link]. You need to provide at least a skeleton body
of this method. The next step resolves this issue.
3. Open [Link] for editing and add the following code.

static function pushAssignTestClaimAssignables(testclaimassignables : TestClaimAssignable_Ext[]) {

// Implementation to do
}

Next steps
• “Step 6: Add the necessary permission for the extension entity type” on page 279
• “Step 7: Test assignment of the assignable entity type” on page 281

Step 6: Add the necessary permission for the extension entity type
Each extension entity type that has a foreign key to another entity type must set up and handle the permissions for
users to assign instances of this entity type.

Before you begin

• “Step 1: Create extension entity type TestClaimAssignable_Ext” on page 273
• “Step 2: Add foreign keys to assignable entity types” on page 275
• “Step 3: Create new assignment type for extension entity type TestClaimAssignable_Ext” on page 275
• “Step 4: Create enhancement class TestClaimAssignableExtEnhancement” on page 277
• “Step 5: Create delegate class TestClaimAssignableMethodsImpl” on page 278

About this task

The TestClaimAssignable_Ext extension entity type has foreign keys to the entity types Claim and Activity. You
must do the following tasks so that PolicyCenter can ensure that only authorized users assign
TestClaimAssignable_Ext instances.
• Define a permission of permKey="own" in [Link].
• Add this permission to the SystemPermissionType typelist.
• Assign this permission to a user role.
Example: Creating assignable entities 279
Guidewire PolicyCenter 9.0.9 Configuration Guide

• Assign this role to any user that needs to assign the new assignable entity.
If you do not perform these steps correctly, you see the following error if you attempt to assign your assignable
entity:

[Link]: No user defined

at [Link]([Link])
at [Link]([Link])
...

Procedure
1. Navigate to configuration→config→Security.
2. In this folder, double-click [Link].
The file [Link] opens in an editor tab. You use this file to define system permissions for the
data model entities.
3. Inside the SecurityConfig element, add the following code.
This code defines a permission that you can assign to a user to enable that person to assign an entity instance
of types TestClaimAssignable_Ext and UserAssignableEntity_Ext.
<!-- Permission key needed for assigning extension entity in testing-->
<StaticHandler entity="UserAssignableEntity_Ext" permKey="own">
<SystemPermType code="ownsensclaim"/>
<SystemPermType code="InternalTools"/>
<SystemPermType code="ext_entity_perms"/>
</StaticHandler>

<StaticHandler entity="TestClaimAssignable_Ext" permKey="own">

<SystemPermType code="ownsensclaim"/>
<SystemPermType code="InternalTools"/>
<SystemPermType code="ext_entity_perms"/>
</StaticHandler>

4. In Guidewire Studio, open [Link] for editing.

You need to add the new system permission to the SystemPermissionType typelist.
a. Press Ctrl-N and start entering the typekey name.
Studio displays a number of matches because files with the name SystemPermissionType already exist.
b. Double-click the [Link] file.
The typelist extension opens in the editor.
5. Add the following typecode.

Field Entry
code ext_entity_perms

name Own ext entity

desc Permission to access extension entity

6. To see your new system permission in Guidewire PolicyCenter, stop and restart the application server.
a. Stop the server, if it is running.
b. Start the server from within Studio.
c. Correct any problems that occur and repeat the previous steps until the server starts without errors.
7. Log into PolicyCenter, using an administrative account.
This example assumes the use of Guidewire ClaimCenter. You must be logged in as an administrator to be
able to access the Administration tab. Additionally, that administrator account must have a role with the Manage
Roles and View Roles permissions to be able to view and edit the Roles screen.
8. If you have not already done so, load the demonstration data into the database.
The next step requires this data.
280 chapter 18: Example: Creating assignable entities
 Guidewire PolicyCenter 9.0.9 Configuration Guide

9. Click the Administration tab and navigate to Users & Security→Roles.

10. Assign the Own ext entity system permission to a specific user role such as Adjuster.
11. Assign that role with the necessary permission to a specific user such as aapplegate.

Next steps
• “Step 7: Test assignment of the assignable entity type” on page 281

Step 7: Test assignment of the assignable entity type

After you create your assignable entity type that uses a foreign key, you must test your work to verify that you have
performed the previous steps correctly.

Before you begin

• “Step 1: Create extension entity type TestClaimAssignable_Ext” on page 273
• “Step 2: Add foreign keys to assignable entity types” on page 275
• “Step 3: Create new assignment type for extension entity type TestClaimAssignable_Ext” on page 275
• “Step 4: Create enhancement class TestClaimAssignableExtEnhancement” on page 277
• “Step 5: Create delegate class TestClaimAssignableMethodsImpl” on page 278
• “Step 6: Add the necessary permission for the extension entity type” on page 279

Procedure
1. In Studio, click Tools→Gosu Scratchpad to open the Studio Gosu Scratchpad.
2. Enter the following code in the Gosu Scratchpad tab.
var _users = Query. make(User).join(User# Credential).compare(Credential# UserName, Equals, "aapplegate")
var _usr = _users.select(). AtMostOneRow
var _group = _usr. GroupUsers[ 0]. Group
//Print out the members of the chosen group
print( "\nChosen group " + _group. DisplayName + " contains the following members:")
_group. [Link](\name -> print( "\t" + name. User. DisplayName))

var _claim = [Link]. make(Claim).compare(Claim# ClaimNumber, Equals,

"235-53-365870").select(). AtMostOneRow
print( "Claim number = " + _claim. ClaimNumber)
[Link](\bundle -> {
for (i in 1.. 5) {
var testAssignable = new TestClaimAssignable_Ext()
testAssignable = [Link](testAssignable)
[Link] = _claim
[Link](_group, _usr)
print("Pass " + i + ": Assigning claim (with claim number = " + testAssignable. Claim +
") to the test assignment object ")
print ("\tThe assigned user is " + testAssignable. AssignedUser)
print ("\tThe assigned group is " + testAssignable. AssignedGroup)

if ([Link]( false, _group) != true) {

print("Cannot perform round-robin assignment.")
break
}
print("\tFor assignUserByRoundRobin, AssignedUser = " +
[Link])
}
}, "su")

3. Click Run.
Output similar to the following lines appears in the Console tab.
Chosen group Auto1 - TeamA contains the following members:
Elizabeth Lee
Charles Shaw
Heidi Johnson
Cathy Clark
Felicity Wagner
Gary Wang

Example: Creating assignable entities 281

Guidewire PolicyCenter 9.0.9 Configuration Guide

Dan Henson
Eugene Nyugen
Betty Baker
Chris Craft
Andy Applegate
Sue Smith
Claim number = 235-53-365870
Pass 1: Assigning claim (with claim number = 235-53-365870) to the test assignment object
The assigned user is Andy Applegate
The assigned group is Auto1 - TeamA
For assignUserByRoundRobin, AssignedUser = Dan Henson
Pass 2: Assigning claim (with claim number = 235-53-365870) to the test assignment object
The assigned user is Andy Applegate
The assigned group is Auto1 - TeamA
For assignUserByRoundRobin, AssignedUser = Eugene Nyugen
Pass 3: Assigning claim (with claim number = 235-53-365870) to the test assignment object
The assigned user is Andy Applegate
The assigned group is Auto1 - TeamA
For assignUserByRoundRobin, AssignedUser = Felicity Wagner
Pass 4: Assigning claim (with claim number = 235-53-365870) to the test assignment object
The assigned user is Andy Applegate
The assigned group is Auto1 - TeamA
For assignUserByRoundRobin, AssignedUser = Gary Wang
Pass 5: Assigning claim (with claim number = 235-53-365870) to the test assignment object
The assigned user is Andy Applegate
The assigned group is Auto1 - TeamA
For assignUserByRoundRobin, AssignedUser = Heidi Johnson

282 chapter 18: Example: Creating assignable entities

chapter 19

Data types

This topic describes the Guidewire data types, what they are, how to customize a data type, and how to create a new
data type.

See also
• Globalization Guide

Related concepts
“Overview of data types” on page 283
“The data types configuration file” on page 285
“Customizing base configuration data types” on page 287
“Working with the medium text data type (Oracle)” on page 289
“Working with the VARCHAR data type (SQL Server)” on page 289
“The data type API” on page 290
“Defining a new tax identification number data type” on page 292

Related tasks
“Define a new data type” on page 291

Overview of data types

In the Guidewire data model, a data type is an augmentation of an object property, along three axes:

Axis Description
Constraint A data type can restrict the range of allowable values. For example, a String data type can restrict values to a
maximum character limit.
Persistence A data type can specify how PolicyCenter stores a value in the database and in the object layer. For example,
one String data type can store values as CLOB (Character Large Object) objects. Another String data type can
store values as VARCHAR objects.
Presentation A data type can specify how the PolicyCenter interface treats a value. For example, a String data type can spec‐
ify an input mask to use in assisting the user with data entry.

Data types 283

Guidewire PolicyCenter 9.0.9 Configuration Guide

Guidewire stores the definitions for the base configuration data types in *.dti files in the datatypes directory.
Each file corresponds to a separate data type, which the file name specifies.
Every data type has an associated Java or Gosu type (defined in the valueType attribute). For example, the
associated type for the datetime data type is [Link]. Thus, you see the following XML code in the
[Link] file.
<DataTypeDef xmlns="[Link]
type="[Link]"
valueType="[Link]">
...

In a similar manner, the decimal data type has an associated type of [Link].
<DataTypeDef xmlns="[Link]
type="[Link]"
valueType="[Link]">
...

Working with data types

In working with data types, you can do the following:

Operation Description
Customize an exist‐ Modify the data type definition in file [Link], which you access through Studio. You can modify
ing data type only a select subset of the base configuration data types.
See “Customizing base configuration data types” on page 287.
Create a new data Create a .dti definition file and place it in modules→configuration→config→datatypes. You also need to
type create Gosu code to manage the data type.
See “Define a new data type” on page 291.
Override the data Override the parameterization of the data type on individual columns (fields) on an entity. For example,
type on a column you can make a VARCHAR column in the base data model use encryption by extending the entity and
setting the encryption parameter on a <columnParam> element.

Using data types

You can use any of the data types for data fields (except for those that are internal). This includes data types that are
part of the base configuration or data types that you create yourself. If you add a new column to an entity or create a
new entity, then you can use any data type that you want for that column. You do this by setting the type attribute on
the column. For example:
<extension entityName="Policy">
<column name="NewCompanyName" type="CompanyName" nullok="true" desc="Name for the new company."/>
</extension>

If you add too many large fields to any one table, you can easily reach the maximum row size of a table. In
particular, this is a problem if you add a large number of long text or VARCHAR fields. Have your company database
administrator (DBA) determine the maximum row size and increase the page size, if needed.

Guidewire‐reserved data types

Guidewire reserves the right to use the following data types exclusively. Guidewire does not support the use of these
data types except for its own internal purposes. Do not attempt to create or extend an entity using one of the
following data types:
• foreignkey
• key
• typekey
• typelistkey
284 chapter 19: Data types
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Database data types

Guidewire bases its base configuration data types on the following database data types:
• BIT
• BLOB
• CLOB
• DECIMAL
• INTEGER
• TIMESTAMP
• VARCHAR

Data types and database vendors

It is possible to see both VARCHAR and varchar in the Guidewire documentation. This usage has the following
meanings.

All uppercase characters

This refers to database data types generally, for example VARCHAR and CLOB (Character Large Object). Of the
supported database vendors, the Oracle (and H2) databases use uppercase data type names, while the SQL Server
database uses lowercase data type names. To view the entire set of database data types, consult the database vendor's
documentation.

All lowercase characters

This refers to Guidewire data types generally, for example, varchar and text. You can determine the set of
Guidewire data types by viewing the names of the data type metadata definition files (*.dti) in config→datatypes.

Defining a data type for a property

Guidewire associates data types with object properties using the following annotation:
[Link]

The annotation requires you to provide the name of the data type along with any parameters that you want to supply
to the data type.
• You associate a data type with a metadata property by specifying the type attribute on the <column> element.
• You specify any parameters for the data type with <columnParam> elements, which are children of the <column>
element.
Each data type has a value type. You can associate a data type only with a property that has a feature type that
matches the data type of the value type. For example, you can only associate a String data type with String
properties.
Note: Guidewire PolicyCenter does not enforce this restriction at compile time. (However,
PolicyCenter does check for any exception to this restriction at application server start up.) Guidewire
permits annotations on any allowed feature, as long as you supply the parameters that the annotation
requires. Therefore, you need to be aware of this restriction and enforce it yourself.

The data types configuration file

IMPORTANT If you make changes to the [Link] file, you must increment the version number
in [Link].

PolicyCenter lets you modify certain attributes on a subset of the base configuration data types by using the
[Link] configuration file. You can access this file in Guidewire Studio™ from
Data types 285
Guidewire PolicyCenter 9.0.9 Configuration Guide

configuration→config→fieldvalidators. You can modify the values of certain attributes in this file to customize how
these data types work in PolicyCenter.
This [Link] file contains the following elements:

XML element Description

<DataTypes> Top XML element for the [Link] file.
<...DataType> Subelement that defines a specific customizable data type (for example, PhoneDataType, YearDataType,
MoneyDataType) and assigns one or more default values to each one.

WARNING Modify the [Link] file with caution. If you modify the file incorrectly, you
can invalidate your PolicyCenter installation.

<...DataType>
The <...DataType> element is the basic element of the [Link] file. It assigns default values to base
configuration data types that you can customize. This element starts with the specific data type name. For example,
the element for the PercentageDec data type in the [Link] file is <PercentageDecDataType>.
The <...DataType> element has the following attributes:

Attribute Description
length Assigns the maximum character length of the data type.
validator Binds the data type to a given validator definition. It must match the name attribute of the validator definition.

precision Used for DECIMAL types only.

scale • precision is the total number of digits in the number.
• scale is the number of digits to the right of the decimal point. The default value is 2.
The value of scale must be less than the value of precision.
For more information, see “The Precision and Scale attributes” on page 287.
appscale Optional attribute for use with money data types.
For more information, see “The Money data type” on page 289.

Deploying modifications to the data types configuration file

If you change the [Link] file, then you need to deploy those changes to the application server. Most
modifications to the [Link] file take effect the next time the server reboots.
• PolicyCenter reloads the validator attribute for data type definitions upon server reboot. This is so that you can
rebind different validators to data types.
• PolicyCenter does not reload other data type attributes such as length, precision, and scale. This is because
PolicyCenter applies these attributes only during the initial server boot. (It uses them during table creation in the
database.) PolicyCenter ignores any changes to these attributes unless something triggers a database upgrade. For
example, if you modify a base entity, then PolicyCenter triggers a database upgrade at the next server restart.

Recommendations for modifying data types

Guidewire recommends the following:
• Make modifications to the data types before creating the PolicyCenter database for the first time.
• Make modifications to the data types before performing a database upgrade that creates a new extension column.
PolicyCenter looks at the data type definitions only at the time it creates a database column. Thus, it ignores any
changes after that point. However, any differences between the type definition and the actual database column can
286 chapter 19: Data types
 Guidewire PolicyCenter 9.0.9 Configuration Guide

cause upgrade errors or failure warnings. Therefore, Guidewire recommends that you exercise extreme caution in
making changes to type definitions.

Customizing base configuration data types

You can customize the behavior of the data types listed in [Link]. To see exactly what you can customize
for each data type, see “List of customizable data types” on page 288. In general, though, you can customize some
or all of the following attributes on a listed data type (depending on the data type):
• length
• precision
• scale
• validator

See also
• For information on field validators in general, see “Field validation” on page 297.
• For information on how to localize field validation, see the Globalization Guide.

Related concepts
“Field validation” on page 297

Related references
“List of customizable data types” on page 288

The Length attribute

Data types based on the VARCHAR data type have a length attribute that you can customize. This attribute sets the
maximum allowable character length for the field (column).

The Precision and Scale attributes

Data types based on the DECIMAL data type have precision and scale attributes that you can customize. These
attributes determine the size of the decimal. The precision value sets the total number of digits in the number and
the scale value is the number of digits to the right of the decimal point.
There are special requirements for these attributes in working with monetary amounts. For more information, see
Globalization Guide.

The Validator attribute

Most data types have a validator attribute that you can customize. This attribute binds the data type to a given
validator definition. For example, PhoneDataType (defined in [Link]) binds to the Phone validator by its
validator attribute. This matches the name attribute of a <ValidatorDef> definition in file [Link].
//File [Link]
<DataTypes xmlns:xsi="[Link]
xsi:noNamespaceSchemaLocation="../../../../platform/pl/xsd/[Link]">
...
<PhoneDataType length="30" validator="Phone"/>
...
</DataTypes>

//File [Link]
<FieldValidators>
...
<ValidatorDef description="[Link]" input-mask="###-###-#### x####" name="Phone"
value="[0-9]{3}-[0-9]{3}-[0-9]{4}( x[0-9]{0,4})?"/>

Data types 287

Guidewire PolicyCenter 9.0.9 Configuration Guide

...
</FieldValidators>

List of customizable data types

The following table summarizes the list of the data types that you can customize. PolicyCenter defines these data
types in [Link]. If a data type does not exist in [Link], then you cannot customize its attributes.
PolicyCenter builds the all of its data types on top of the base database data types of CLOB, TIMESTAMP, DECIMAL,
INTEGER, VARCHAR, BIT, and BLOB.
Note: Only decimal numbers use the precision and scale attributes. The precision attribute
defines the total number of digits in the number. The scale attribute defines the number of digits to
the right of the decimal point. Therefore, precision must be greater than or equal to scale.

Guidewire data type Built on Customizable attributes

ABContactMatchSetKey VARCHAR length

Account VARCHAR length, validator

AddressLine VARCHAR length, validator

ClaimNumber VARCHAR length, validator

CompanyName VARCHAR length, validator

ContactIdentifier VARCHAR length, validator

CreditCardNumber VARCHAR length, validator

DaysWorkedWeek DECIMAL precision, validator

DriverLicense VARCHAR length, validator

DunAndBradstreetNumber VARCHAR length, validator

EmploymentClassification VARCHAR length, validator

ExchangeRate DECIMAL precision, validator

Exmod DECIMAL precision, validator

FirstName VARCHAR length, validator

HoursWorkedDay DECIMAL precision, validator

LastName VARCHAR length, validator

MediumText VARCHAR length

PercentageDec DECIMAL precision

Phone VARCHAR length, validator

PolicyNumber VARCHAR length, validator

PostalCode VARCHAR length, validator

ProrationFactor DECIMAL precision, validator

Rate DECIMAL precision, validator

RatingLineBasisAmount DECIMAL precision, validator

Risk DECIMAL precision, validator

Speed INTEGER validator

SSN VARCHAR length, validator

VIN VARCHAR length, validator

288 chapter 19: Data types

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Guidewire data type Built on Customizable attributes

Year INTEGER validator

The percentage decimal data type

Guidewire builds the PercentageDec data type on top of the DECIMAL (3,0) data type. Only use decimal values
from 0 to 100 inclusive.

The Money data type

Guidewire provides the Money data type as the basis for the <monetaryamount> subelement in metadata definition
files. The <monetaryamount> subelement is a compound field type, with a Money data type as one component and a
typekey to the Currency typelist as the other component.

See also

• Globalization Guide

Working with the medium text data type (Oracle)

In working with the MEDIUMTEXT data type, take extra care if you use multi-byte characters, excluding CLOB-based
data types such as LONGTEXT, TEXT, or CLOB in the Oracle database. (CLOB stands for Character Large OBject.) On
Oracle, Guidewire supports any single-byte character set, or the multi-byte character sets UTF8 and AL32UTF8.
Oracle has a maximum column width, for non-LOB columns, of 4000 bytes. Thus, with a single-byte character set,
you can store up to 4000 characters in a single column (because one character requires one byte). However, with a
multi-byte character set, you can store fewer characters, depending on the ratio of bytes to characters for that
character set. For UTF8, the ratio is at most three-to-one, so you can always safely store up to 4000 / 3 = 1333
characters in a single column.
Thus, Guidewire recommends:
• Limit the number of characters to 4000 if using a single-byte character set.
• Limit the number of characters to 1333 if using UTF8 or AL32UTF8. However, it is possible that some AL32UTF8
characters can be four bytes, and thus 1333 of them can potentially overflow 4000 bytes.

Working with the VARCHAR data type (SQL Server)

When invoking the VARCHAR data type in SQL Server, you must distinguish between the varchar and text
Guidewire data types. SQL Server has two alternatives for invoking the VARCHAR data type:
• VARCHAR(N) where N is a number of bytes less than 8000
• VARCHAR(MAX) where MAX represents a number of bytes equal to 231-1 or 2 gigabytes
These alternatives correspond respectively to the varchar and text Guidewire data types.
If you intend to create a variable that can have a size in excess of 8000 bytes, you cannot use the varchar Guidewire
data type. Doing so will result in a VARCHAR(N) invocation in SQL Server. In this case, Guidewire Studio will allow
you to set the variable to a value that exceeds 8000 bytes. The development environment will not provide a warning
or error message. Instead, Guidewire Studio will throw an exception on the next server startup.
You must use the text Guidewire data type if you intend to create a variable that can exceed 8000 bytes in size.
Using the text Guidewire data type will result in a VARCHAR(MAX) invocation in SQL Server. This invocation will
provide the variable access to 2 gigabytes of storage.
Data types 289
Guidewire PolicyCenter 9.0.9 Configuration Guide

The data type API

The classes in [Link] form the core of the data type API. Most of the time, you do not need to use data types
directly, as Guidewire uses these internally in the system. However, there can be cases in which you need to access a
data type, typically to determine the constraints information.

Retrieving the data type for a property

To retrieve the data type for a property, you could look up the annotation on the property. You could then look up the
data type reflectively, using the name and parameters properties of the annotation. However, this is a cumbersome
process. As a convenience, use the following method instead:
[Link]([Link])

For example:
var property = [Link]("ClaimNumber")
var claimNumberDataType = [Link](property)

The [Link]([Link]) method also has provides some

performance optimizations. Therefore, Guidewire recommends that you use this method rather than looking up the
annotation directly from the property.

Retrieving a particular data type in Gosu

If you need an instance of a particular data type, use the corresponding method on [Link]. A
static method exists on this type for each data type in the system. Some data types have two methods:
• One method that takes all parameters
• One method that takes only the required parameters
For example:
var varcharDataType = [Link](10)
var encryptedVarcharDataType = [Link](10,
/* validator */ null,
logicalSize */ null,
/* encryption */ true,
/* trimwhitespace */ null)

Retrieving a data type reflectively

In rare cases, you may need to look up a data type reflectively. To do this, you need the name of the data type, and a
map containing the parameters for the data type. For example:
var varcharDataType = [Link]("varchar", { "size" -> "10" ))

Using the IDataType methods

After you have a data type, you can access its various aspects using one of the asXXXDataType methods, which are:
• asConstrainedDataType() : IConstrainedDataType
• asPersistentDataType() : IPersistentDataType
• asPresentableDataType() : IPresentableDataType
For example, suppose that you want to determine the maximum length of a property:
var claim : Claim = ...
var claimNumberProperty = [Link]("ClaimNumber")
var claimNumberDataType = [Link](claimNumberProperty)
var maxLength = [Link]().getLength(claim, claimNumberProperty)

290 chapter 19: Data types

 Guidewire PolicyCenter 9.0.9 Configuration Guide

It may seem odd that the getLength([Link], [Link]) method (in this
example) takes the claim and the claim number property. The reason for this is that the constraint and presentation
aspects of data types are dynamic, meaning that they are based on context.
Many of the methods on [Link] and [Link] take a
context object, representing the owner of the property with the data type, along with the property in question. This
allows the implementation to provide different behavior, based on the context. If you do not have the context object
or property, then you can pass null for either of these arguments.
If you implement a data type, then you must handle the case in which the context is unknown.

Define a new data type

About this task

Procedure
1. Create a .dti file (data type declaration file) to register the data type within Guidewire PolicyCenter. In
Guidewire Studio, do the following:
a. In the Project tool window, navigate to configuration→config→datatypes.
b. Right-click datatypes, and then click New→File.
c. Enter the name of the data type, followed by the .dti extension.
For example, to create a data type named Age, type [Link].
You must enter definitions for the following items for the data type. If necessary, view other samples of
datatype definition files to determine what you need to enter.
• Name
• Value type
• Parameters
• Implementation type
2. Create a data type definition class that implements the [Link] interface. This class
must include writable property definitions that correspond to each parameter that the data type accepts.
3. Create data type handler classes for each of the three aspects of the data type (constraints, persistence, and
presentation). These classes must implement the following interfaces:
• [Link]
• [Link]
• [Link]
Guidewire provides a number of implementations of these three interfaces for the standard data types. For
example, you can create your own CLOB-based data types by defining a data type that uses the
ClobPersistenceHandler class. To access the handler interface implementations or to view a complete list,
enter the following within Gosu code:
[Link].*

Result
After you create the data type, you will want to use the data type in some useful way.

Example
For example, you can create an entity property that uses that data type and then expose that property as a field within
PolicyCenter.
Data types 291
Guidewire PolicyCenter 9.0.9 Configuration Guide

Next steps
For a discussion of constraints, persistence, and presentation as it relates to data types, see “Overview of data types”
on page 283.

Defining a new tax identification number data type

The following examples illustrates the steps involved in defining a new data type and using it. The example defines
a new data type for Tax Identification Number objects, called TaxID. The data type has one required property, the
name of the property on the context object. This property, countryProperty, identifies which country is in context
for validating the data.
This example contains the following steps:
• “Step 1: Register the data type” on page 292
• “Step 2: Implement the IDataTypeDef Interface” on page 293
• “Step 3: Implement the data type aspect handlers” on page 294

Step 1: Register the data type

About this task
To register a new data type, create a file named [Link], with XXX as the name of the new data type. In this case,
create a file named [Link]. To do this:

Procedure
1. In Guidewire Studio, in the Project tool window, navigate to configuration→config→datatypes.
2. Right-click datatypes, and then click New→File.
3. Enter [Link] as the file name. This action creates an empty data type file and places it in the datatypes
folder.
4. Enter the following text in the file:

<?xml version="1.0"?>
<DataTypeDef xmlns="[Link] type="[Link]"
valueType="[Link]">
<ParameterDef name="countryProperty" desc="The name of a property on the owning entity,
whose value contains the country with which to validate and format values."
required="true" type="[Link]"/>
</DataTypeDef>

The root element of [Link] is <DataTypeDef> and the namespace is [Link]

This example defines the following:

data type name TaxID

value type String

parameter contactType

implementation type [Link]

Next steps
After completing this task, complete “Step 2: Implement the IDataTypeDef Interface” on page 293.

See also
• For details on the attributes and elements relevant to the data type definition, see “The PolicyCenter data model”
on page 169.
292 chapter 19: Data types
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Step 2: Implement the IDataTypeDef Interface

Before you begin
Before beginning this task, complete “Step 1: Register the data type” on page 292.

About this task

The implementation class that you create to handle the TaxID data type must do the following:
• It must implement the [Link] interface.
• It must have a no-argument constructor.
• It must have a property for each of the data type parameters.
For example, suppose that you have a new data type that has a String parameter named someParameter. The
implementation class (specified in the type attribute) must define a writable property named someParameter, so
that the data type factory can pass the argument values to the implementation. The implementation can then use the
parameters in the implementation of the various handlers, which are:
• [Link]
• [Link]
• [Link]
Class TaxIDDataTypeDef
For our example data type, the [Link] class looks similar to the following. To create
this file, first create the package, then the class file, in the Studio Classes folder.
package [Link]

uses [Link]
uses [Link]
uses [Link]
uses [Link]
uses [Link]
uses [Link]
uses [Link]
uses [Link]
uses [Link]

class TaxIDDataTypeDef implements IDataTypeDef {

private var _countryProperty : String as CountryProperty

override property get ConstraintsHandler() : IDataTypeConstraintsHandler {

return new TaxIDConstraintsHandler(CountryProperty)
}

override property get PersistenceHandler() : IDataTypePersistenceHandler {

return new VarcharPersistenceHandler(/* encrypted */ false,
/* trimWhitespace */ true,
/* size */ 30)
}

override property get PresentationHandler() : IDataTypePresentationHandler {

return new TaxIDPresentationHandler(CountryProperty)
}

override property get ValueHandler() : IDataTypeValueHandler {

return new SimpleValueHandler(String)
}

override function validate(prop : IPropertyInfo, errors : IDataTypeDefValidationErrors) {

// Check that the CountryProperty names an actual property on the owning type, and that
// the type of the property is [Link].
var countryProp = [Link](CountryProperty)

if (countryProp == null) {

[Link]("Property \"" + CountryProperty + "\" does not exist on type " +

[Link])

Data types 293

Guidewire PolicyCenter 9.0.9 Configuration Guide

} else if (not [Link]([Link])) {

[Link]("Property " + countryProp + " does not resolve to a " + [Link])

}
}
}

Note that the class defines a property named CountryProperty, which the system calls to pass the
countryProperty parameter. Also notice how the implementation reads the value of CountryProperty as its
constructs its constraints and presentation handlers. Guidewire guarantees to fill the implementation parameters
before calling the handlers.
In the example code, the class refers to constraints and presentation handlers created specifically for this data type.
However, it also reuses a Guidewire-provided persistence handler, the VarcharPersistenceHandler. You do not
usually need to create your own persistence handler, as Guidewire defines persistence handlers for all the basic
database column types.

Next steps
After completing this task, complete “Step 3: Implement the data type aspect handlers” on page 294.

Step 3: Implement the data type aspect handlers

Before you begin
Before beginning this task, complete “Step 2: Implement the IDataTypeDef Interface” on page 293.

About this task

As you define a new data type, it is possible (actually likely) that you need to define one or more handlers for the
data type. These handler interfaces are different than the Data Type API interfaces. For example, clients that use the
Data Type API use the following:
[Link]

However, if you define a new data type, you must implement the following:
[Link]

This separation of interfaces allows the definition of a caller-friendly interface for data type clients and a
implementation-friendly interface for data type designers.
The example data type defines a handler for both constraints and presentation.
Class TaxIDConstraintsHandler
This class looks similar to the following:
package [Link]

uses [Link]
uses [Link]
uses [Link]
uses [Link]
uses [Link]
uses [Link]

class TaxIDConstraintsHandler implements IStringConstraintsHandler {

var _countryProperty : String

construct(countryProperty : String) {
_countryProperty = countryProperty
}

override function validateValue(ctx : Object, prop : IPropertyInfo, value : Object) {

var country = getCountry(ctx)

switch (country) {
case "US": validateUSTaxID(ctx, prop, value as [Link])

294 chapter 19: Data types

 Guidewire PolicyCenter 9.0.9 Configuration Guide

break
// other countries ...
}

override function validateUserInput(ctx : Object, prop : IPropertyInfo, strValue : String) {

validateValue(ctx, prop, strValue)
}

override function getConsistencyCheckerPredicates(columnName : String) : Iterable<CharSequence> {

return {}
}

override function getLoaderValidationPredicates(columnName : String) : Iterable<CharSequence> {

return {}
}

override function getLength(ctx : Object, prop : IPropertyInfo) : Integer {

var country = getCountry(ctx)

switch (country) {
case "US": return ctx typeis Person ? 11 : 10
// other countries ...
}

return null

private function getCountry(ctx : Object) : Country {

return ctx[_countryProperty] as Country
}

private function validateUSTaxID(ctx : Object, prop : IPropertyInfo, value : String) {

var pattern = ctx typeis Person ? "\\d{3}-\\d{2}-\\d{4}" : "\\d{2}-\\d{7}"
if (not [Link](pattern)) {
throw new DataTypeException("${value} does not match required pattern ${pattern}", prop,
"[Link]", { value })
}
}

Class TaxIDPresentationHandler
This class looks similar to the following:
package [Link]

uses [Link]
uses [Link]

class TaxIDPresentationHandler implements IStringPresentationHandler {

private var _countryProperty : String

construct(countryProperty : String) {
_countryProperty = countryProperty
}

function getEditorValue(ctx : Object, prop : IPropertyInfo) : Object {

return null
}

override function getDisplayFormat(ctx : Object, prop : IPropertyInfo ) : String {

return null
}

override function getInputMask(ctx : Object, prop : IPropertyInfo) : String {

switch (getCountry(ctx)) {
case "US": return ctx typeis Person ? "###-##-####" : "##-#######"
// other countries ...
}

return null

Data types 295

Guidewire PolicyCenter 9.0.9 Configuration Guide

override function getPlaceholderChar(ctx : Object, prop : IPropertyInfo) : String {

return null
}

private function getCountry(ctx : Object) : Country {

return ctx[_countryProperty] as Country
}

Notice how each of these handlers makes use of the context object in order to determine the type of input mask and
validation string to use.

296 chapter 19: Data types

chapter 20

Field validation

Field validators handle simple validation for a single field. A validator definition defines a regular expression,
which a data field must match to be valid. It can also define an optional input mask that provides a visual indication
to the user of the data to enter in the field.
Each field in PolicyCenter has a default validation based on its data type. For example, integer fields can contain
only numbers. However, it is possible to use a field validator definition to override this default validation.
• You can apply field validators to simple data types, but not to typelists.
• You can modify field validators for existing fields, or create new validators for new fields.
For complex validation between fields, use validation-specific Gosu code instead of simple field validators.

Specifying the properties of a specific field

Field validators specify only the validation properties for a general kind of input (for example, any postal code).
They do not specify the properties of a specific field in a particular data view. Instead, detail views and editable list
views include additional validation attributes in their configuration files.

Specifying field validators on a delegate entity

Apply any field validators for elements existing on a delegate entity to the delegate entity. Do not apply any field
validators to the entities that inherit the elements from the delegate. Applying a field validator to an element on the
delegate entity ensures that PolicyCenter applies the field validator uniformly to that data element in whatever code
utilizes the delegate.

Field validator definitions

PolicyCenter stores field validator definitions in the [Link] file, located in Guidewire Studio under
configuration→config→fieldvalidators. The [Link] file contains a list of validator specifications for
individual fields in PolicyCenter. The [Link] file contains the following sections:

XML element Description More information

<FieldValidators> Top XML element for the [Link] file. “<FieldValidators>” on
page 298
<ValidatorDef> Subelement that defines all of the validators. Each validator must have “<ValidatorDef>” on page 298
a unique name by which you can reference it.

Field validation 297

Guidewire PolicyCenter 9.0.9 Configuration Guide

Using the [Link] file, you can do the following:

• You can modify existing validators. For example, it is common for each installation site to represent policy
numbers differently. You can define field validation to reflect these changes.
• You can add new validators for existing fields or custom extension fields.
The following XML example illustrates the structure of the [Link] file:
<FieldValidators>
<ValidatorDef name="Email"
description="[Link]"
input-mask=""
value=".+@.+"/>
<ValidatorDef name="SSN"
description="[Link]"
input-mask="###-##-####"
value="[0-9]{3}-[0-9]{2}-[0-9]{4}|[0-9]{2}-[0-9]{7}?"
/>
...
</FieldValidators>

In the previous example, each validator definition specifies a value and an input-mask. These attributes have
different uses, as follows:

value A value is a regular expression that the field value must match for the data to be valid. PolicyCenter persists this
value to the database, including any defined delimiters or characters other than the # character.
input- An input-mask, which is optional, assists the user in entering valid data. PolicyCenter displays the input mask when
mask the field opens for editing. For example, a # character indicates that the user must enter a digit for this character.
These characters disappear when the user starts to enter data.

The input mask guides the user to enter to valid sequences for the regular expression defined in the value attribute.
After the user enters a value, PolicyCenter uses the regular expression to validate the field data as it sets the field on
the object.

See also
• Globalization Guide

Related references
“<FieldValidators>” on page 298
“<ValidatorDef>” on page 298

<FieldValidators>
The <FieldValidators> element is the root element in the [Link] file. It contains the XML
subelement <ValidatorDef>.

<ValidatorDef>
The <ValidatorDef> subelement of <FieldValidators> is the beginning element for the definition of a validator.
This element has the following attributes:
• “description” on page 299
• “floor, ceiling” on page 299
• “input-mask” on page 299
• “name” on page 299
• “placeholder-char” on page 299
• “validation-level” on page 299
• “validation-type” on page 300
298 chapter 20: Field validation
 Guidewire PolicyCenter 9.0.9 Configuration Guide

• “value” on page 300

The following sections describe these attributes.

description
The description attribute specifies the validation message to show to a user who enters bad input. The description
refers to a key in the display_languageCode.properties file that contains the actual description text. The naming
convention for this display key is Validator.validator_name.
In the display text in the properties file, {0} represents the name of the field in question. PolicyCenter determines
this at runtime dynamically.

floor, ceiling
The floor and ceiling attributes are optional attributes that specify the minimum (floor) and maximum
(ceiling) values for the field. For example, you can limit the range to 100-200 by setting floor="100" and
ceiling="200".
Use floor and ceiling range values for numeric fields only. For example, use the floor and ceiling attributes to define
a Money validator:
<ValidatorDef description="[Link]"
input-mask="" name="Money"
ceiling="9999999999999999.99"
floor="-9999999999999999.99"
value=".*"/>

input‐mask
The input-mask attribute is optional. It specifies a visual indication of the characters that the user can enter.
PolicyCenter displays the input mask temporarily to the user during data entry. When the user starts to enter text, the
input mask is no longer visible.
The input mask definition consists of the # symbol and other characters:
• The # symbol represents any character the user can type.
• Any other character represents itself in a non-editable form. For example, in an input mask of ###-###-##, the
two hyphen characters are a non-editable part of the input field.
• Any empty input mask of "" is the same as not having the attribute at all.
• A special case is a mask with fixed characters on the end. PolicyCenter displays those characters outside of the
text field. For example ####mph appears as a field #### with mph on the outside end of it.

name
The name attribute specifies the name of the validator. A field definition uses this attribute to specify which validator
applies to the field.

placeholder‐char
The placeholder-char attribute specifies a replacement value for the input mask display character, which defaults
to a period (.) For example, use the placeholder-char attribute to display a dash character instead of the default
period.

validation‐level
This attribute can be set to one of the following values:

Attribute Description
none Disables the validator.

Field validation 299

Guidewire PolicyCenter 9.0.9 Configuration Guide

Attribute Description
relaxed Ignores warnings or partial validation.
strict (default) Treats partially validation or warnings as errors.

validation‐type
Specifies whether to use a regular expression or Gosu class for the validation.
This attribute can be set to one of the following values:

Attribute Description
gosu The value of the <ValidatorDef> is a Gosu class. The Gosu class must extend FieldValidatorBase and override
the validate method. See [Link] for an example. Ensure that any Gosu valida‐
tors that you define are low‐latency for performance reasons.
regex (de‐ The value of the <ValidatorDef> defines a regular expression that PolicyCenter uses to validate data entered
fault) into a field that uses the field validator.

value
The value attribute specifies the acceptable values for the field. It is in the form of a regular expression.
PolicyCenter does not persist this value (the regular expression definition) to the database.
Use regular expressions with String values only. Use floor and ceiling range values for numeric fields, for example,
Money.
PolicyCenter uses the Java regex package described in the following location for regular expression parsing:
[Link]

The following list describes some of the more useful items:

() Parentheses define the order in which PolicyCenter evaluates an expression, just as with any parentheses.
[] Brackets indicate acceptable values. For example:
• [Mm] indicates the letters M or m.
• [0-9] indicates any value from 0 to 9.
• [0-9a-zA-Z] indicates any alphanumeric character.
{} Braces indicate the number of characters. For example:
• [0-9]{5} allows five positions containing any character (number) between 0 and 9.
• {x} repeats the preceding value x times. For example, [0-9]{3} indicates any 3‐digit integer such as 031 or 909, but
not 16.
• {x,y} indicates the preceding value can repeat between x and y times. For example, [abc]{1,3} allows values such
as cab, b, or aa, but not rs or abca.
? A question mark indicates one or zero occurrences of the preceding value. For example, [0-9]x? allows 3x or 3 but not
3xx. ([Mm][Pp][Hh])? means mph, MpH, MPH, or nothing.

()? Values within parentheses followed by a question mark are optional. For example, (-[0-9]{4})? means that you can
optionally have four more digits between 0 and 9 after a dash -.
* An asterisk means zero or more of the preceding value. For example, (abc)* means abc or abcabc but not ab.
+ A plus sign means one or more of the preceding value. For example, [0-9]+ means any number of integers between 0
and 9 (but none is not an option).

300 chapter 20: Field validation

 Guidewire PolicyCenter 9.0.9 Configuration Guide

. A period is a wildcard character. For example:

• .* means anything.
• .+ means anything but the empty string.
• ... means any string with three characters.

Modifying field validators

You configure field validation in Guidewire Studio by editing [Link] files in various locations in the
fieldvalidators folder. In Studio, navigate in the Project tools window to configuration→config→fieldvalidators.
• You define global field validators once in the [Link] file located in the root of the
fieldvalidators folder.
• You define national field validators in [Link] files located in country-specific packages in the
fieldvalidators folder.
You can, for example:
• Create a new field validator. For example:
<!-- Create a new validator -->
<ValidatorDef name="ExampleValidator" value="[A-z]{1,5}" description="[Link]"
input-mask="#####" />

• Modify attributes of an existing validator. For example:

<!-- Modify a validator definition. Adding a ValidatorDef element with the same name as one defined
in the base [Link] file replaces the base validator. -->
<ValidatorDef name="PolicyNumber" value="[0-9]{3}-[0-9]{5}" description="[Link]"
input-mask="###-#####" />

• Define field validators for a specific country.

See also
• Globalization Guide

Using <column‐override> to modify field validation

You use the <column-override> element in an extension file to override attributes on a field validator or to add a
field validator to a field that does not contain one.

Adding a field validator to a field

About this task
To add a validator to an application field that currently does not have one, use a <column-override> element in the
specific entity extension file. Use the following syntax:
<extension entityName="SomeEntity">
<column-override name="SomeColumn">
<columnParam name="validator" value="SomeCustomValidator"/>
</column-override>
</extension>

Suppose that you want to create a validator for a Date of Birth field ([Link]). To create this validator,
you need to perform the following steps in Studio.

Procedure
1. Create a [Link] file if one does not exist and add the following to it.
<extension entityName="Person">
<column-override name="DateOfBirth">
<columnParam name="validator" value="DateOfBirth"/>

Field validation 301

Guidewire PolicyCenter 9.0.9 Configuration Guide

</column-override>
</extension>

2. Add a validation definition for the DateOfBirth validator to [Link].

For example:
<ValidatorDef description="[Link]" ... name="DateOfBirth" .../>

In this case, you can potentially create different DateOfBirth validators in different country-specific
fieldvalidators files.

Changing the length of a text field

About this task
You can use the <column-override> element to change the size (length) of the text that a user can enter into a text
box or field. Guidewire makes a distinction between the size attribute and the logicalSize attribute.
• The size attribute is the length of the database column (if a VARCHAR column).
• The logicalSize attribute is the maximum length of the field that the application permits. It must not be greater
than size attribute (if applicable).
In this case, you set the logicalSize parameter, not a size parameter. This parameter does not change the column
length of the field in the database. You use the logicalSize parameter simply to set the field length in the
PolicyCenter interface. For example:
<column-override name="EmailAddressHome">
<columnParam name="logicalSize" value="42"/>
</column-override>

The use of the logicalSize parameter does not affect the actual length of the column in the database. It merely
affects how many characters a user can enter into a text field.

302 chapter 20: Field validation

chapter 21

Working with typelists

Within Guidewire PolicyCenter, a typelist represents a predefined set of possible values, with each separate value
defined as a typecode. Typically, you experience a typelist as drop-down list within Guidewire PolicyCenter that
presents the set of available choices. You define and manage typelists through Guidewire Studio.

See also
• Globalization Guide

Related concepts
“What is a typelist?” on page 303
“Terms related to typelists” on page 304
“Typelists and typecodes” on page 304
“Typelist definition files” on page 305
“Different kinds of typelists” on page 306
“Working with typelists in Studio” on page 307
“Typekey fields” on page 311
“Removing or retiring a typekey” on page 313
“Typelist filters” on page 314
“Static filters” on page 315
“Dynamic filters” on page 320
“Typecode references in Gosu” on page 322
“Mapping typecodes to external system codes” on page 323

What is a typelist?
IMPORTANT Ensure that you fully understand the dependencies between typelists and other
application files before you modify a typelist. Incorrect changes to a typelist can cause damage to the
PolicyCenter data model.

Guidewire PolicyCenter displays many fields in the interface as drop-down lists of possible values. The list of
available values for a drop-down field is called a typelist. Typelists limit the acceptable values for many fields within
Working with typelists 303
Guidewire PolicyCenter 9.0.9 Configuration Guide

the application. Thus, a typelist represents a predefined set of possible values, with each separate value defined as a
typecode. Whenever there is a drop-down list in the PolicyCenter interface, it is usually a typelist.
For example, the PolicyCenter Contact page that you access as you edit policy vehicle information contains several
different typelists. One of these is the Marital Status typelist that provides the available values from which you can
choose as you enter information about a vehicle owner.
Typelists are very common for coding fields on the root objects of an application. They are also common for status
fields used for application logic. Some typelist usage examples from the Data Dictionary include:
• [Link] uses a simple list.
• [Link] uses a list filtered by VehicleType (that is, choices for this body type depend on
the value of the vehicle type).
Besides displaying the text describing the different options in a drop-down list, typelists also serve a very important
role in integration. Guidewire recommends that you design your typelists so that you can map their typecodes
(values) to the set of codes used in your legacy applications. This is a very important step in making sure that you
code a policy in PolicyCenter to values that can be understood by other applications within your company.

Terms related to typelists

There are several terms related to customizing drop-down lists within PolicyCenter. Since they sound quite similar,
it is easy to confuse the meaning of each term. The following is a quick definition list for you to refer back to at any
time for clarification purposes:

Term Definition
typelist A defined set of values that are usually shown in a drop‐down list within PolicyCenter.
typecode A specific value in a typelist.
typefilter A typelist that contains a static (fixed) set of values.
keyfilter A typelist that dynamically filters another typelist.
typekey The identifier for a field in the data model that represents a direct value chosen from an associated typelist.

Related concepts

“Different kinds of typelists” on page 306

“Typelists and typecodes” on page 304
“Static filters” on page 315
“Dynamic filters” on page 320
“Typekey fields” on page 311

Typelists and typecodes

In Guidewire PolicyCenter, a typelist represents a predefined set of possible values, with each separate value defined
as a typecode. If Guidewire defines a typelist as final, it is not possible to add or delete typecodes from the typelist.

Typelist size recommendation

Limit the size of typelists to 2,000 typecodes. Because of Java's limit on the size of the class initialization method,
PolicyCenter makes nested classes to implement typelists that have more than 2,048 typecodes. These nested classes
affect how you refer to individual typecodes.
The maximum supported number of typecodes in a typelist is 8,192.
304 chapter 21: Working with typelists
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Note: For a SystemPermissionType typelist, the upper limit on the number of typecodes is 7,000
rather than 8,192.
If you have more than 2,048 typecodes in a typelist, PolicyCenter creates nested classes that can each contain an
additional 2,048 typecodes. A new nested class is created if you create a new typecode and the currently used class
contains 2,048 typecodes. To keep the number of nested classes in the base typelist class to a minimum, the entity
code generator adjusts the nested classes as you add and subtract typecodes. These adjustments can change the path
that you use to refer to a particular typecode.
Adhering to a soft limit of 2,000 typecodes provides some room to grow your typelist. This soft limit also aids in
avoiding splitting the typelist into multiple typelists or a nested-class typelist. To adhere to this soft limit, consider
breaking up large typelists by prominent characteristics of your business.

IMPORTANT If at all feasible, keep the size of your typelists under 2,048 typecodes, the maximum
number of typecodes for a single-class typelist. A typelist with more than 2,048 typecodes uses nested
classes. In this case, you must maintain proper references to the typecodes as their allocation among
the nested classes changes. If you fail to maintain appropriate typecode references, PolicyCenter does
not compile.

Using a lookup table for a typelist with more than 2,048 typecodes
If your PolicyCenter implementation does require a typelist with more than 2,048 typecodes, Guidewire strongly
recommends that you use a lookup table, such as a custom entity type, instead of a typelist. By using a custom entity
type, you can ensure referential integrity by using foreign keys to reference the codes in other entity types. If you
add or remove codes from the list, you need to update only the lookup table. You do not need to change your code
that accesses the codes through the lookup table.
If you use a database table to perform the look up, you can use a query to retrieve the codes.
Alternatively, you can use other lookup structures such as XML files.

Internal typecodes
Some typelists contain required internal typecodes that PolicyCenter references directly. Therefore, PolicyCenter
requires that these typecodes exist. Guidewire Studio™ displays internal typecodes in non-editable cells so that you
cannot edit or delete an internal typecode.

Localized typecodes
PolicyCenter supports localizing the individual typecodes in a typelist. See the Globalization Guide for more
information.

Mapping typecodes to external system codes

See the following:
• “Mapping typecodes to external system codes” on page 323
• Integration Guide

Typelist definition files

Similar to entity definitions, Guidewire PolicyCenter stores typelist definitions in XML files. There are three types
of typelist files:

File Contains...
type
tti A single typelist declaration. The name of the file prior to the extension corresponds to the name of the typelist. This
can be either a Guidewire base configuration typelist or a custom typelist that you create through Studio.

Working with typelists 305

Guidewire PolicyCenter 9.0.9 Configuration Guide

File Contains...
type
ttx A single typelist extension. This can be a Guidewire‐exposed base application extension or a custom typelist exten‐
sion that you create.
tix A single typelist extension for use by Guidewire only. These are generally Guidewire internal extensions to base ap‐
plication typelists, for use by a specific Guidewire application.

Always create, modify, and manage typelist definition files through Guidewire Studio. Do not edit the XML typelist
files directly.

See also
• “Data entity metadata files” on page 171

Different kinds of typelists

PolicyCenter organizes typelists into the following categories:

Catego‐ Description More informa‐

ry tion
Internal Typelists that Guidewire controls, as PolicyCenter requires these typelists for proper application “Internal type‐
operation. PolicyCenter depends on these lists for internal application logic. Guidewire designa‐ lists” on
tes internal typelists as final (meaning non‐extendable). Thus, Guidewire limits what you can page 306
modify for these typelists.
You can override the following attribute values on these types of typelists:
• name
• description
• priority
• retired
Extend‐ Typelists that you can customize. These typelists come with a set of example typecodes, but it is “Extendable
able possible to modify these typecodes and to add your own typecodes. In some cases, these ex‐ typelists” on
tendable typelists have internal typecode values that must exist for PolicyCenter to function page 307
properly. You cannot remove the internal typecodes, but you can modify any of the example
typecodes.
PolicyCenter designates internal typecodes by placing their code values in gray, non‐editable
cells. This makes these values inaccessible, and thus, impossible to modify.
Custom Typelists that you add for specific purposes, such as working with a new custom field. These “Custom type‐
typelists are not part of the Guidewire base configuration. Guidewire Studio™ automatically lists” on
makes all custom typelists non‐final (meaning extendable). page 307

Internal typelists
A few of the typelists in the application are internal. Guidewire controls these typelists because PolicyCenter needs
to know the list of acceptable values in advance to support application logic. Guidewire makes these typelists final
by setting the final attribute to true in the data model. For example, ActivityType is an internal typelist because
PolicyCenter implements specific behavior for known activity types.
Guidewire Studio™ disables your ability to add additional typecodes to internal typelists.
The following are examples of internal typelists that you cannot change:
• ActivityStatus
• ArrangementType
• BindOption
306 chapter 21: Working with typelists
 Guidewire PolicyCenter 9.0.9 Configuration Guide

• BOPCost

Overriding attributes on internal typelists

While you cannot change an internal typelist, you can override the following attributes on the typecodes of an
internal typelist:
• name
• description
• priority
• retired
Studio does not permit you to add additional items (typecodes) to an internal typelist. However, you can create a
filter for the typelist.
To override a modifiable typelist attribute, first open the typelist in Guidewire Studio by selecting it under
configuration→config→Extensions→Typelist. Then, select the typecode cell that applies and enter the data. You cannot
change the typecode itself. You can change only the attributes associated with the typecode.

Extendable typelists
Many of the existing typelists are under your control. You cannot delete them or make them empty, but you can
adjust the values (typecodes) within the list to meet your needs. PolicyCenter includes default typelists with sample
typecodes in them. You can customize these typelists for your business needs by adding additional typecodes, if you
want.
The ActivityCategory typelist is an example of an extendable typelist. If you want, you can add additional
typecodes other than the sample values that Guidewire provides in the base configuration.

Custom typelists
If you add a new field to the application, then it is possible that you also need to add an associated typelist. You can
only access these typelists through new extension fields. For more information on how to add a new field to the data
model, see “Extending a base configuration entity” on page 242.
To create a custom typelist, in the Project tools window, navigate to configuration→config→Extensions→Typelist. Right-
click on Typelist, and then click New→Typelist. Enter a name for the typelist, and then define your typecodes.
PolicyCenter limits the number of characters in a typecode to 50 or less.

Working with typelists in Studio

You create, manage and modify typelists within PolicyCenter using Guidewire Studio:
• To work with an existing extendible typelist, expand the Typelist folder in the Project tools window and open the
typelist from the list of existing typelists. The typelist opens in its editor, in which you can change non-internal
values or define new typecodes and filters.
• To view the values set for an internal typelist, open the typelist in the Typelist editor.
• To create a new custom typelist, navigate to configuration→config→Extensions→Typelist. Right-click on Typelist,
and then click New→Typelist. Enter its name, and then define typecodes and filters for the typelist.
You cannot add a new typecode to or modify an existing typecode of a final typelist. However, you can create filters
for the typelist that modify its behavior in Guidewire PolicyCenter.

The typelist editor

If you modify an existing typelist, ensure that you thoroughly understand which other typelists depend on the
typecode values in the typelist being modified. You must also update any related typelists.
Working with typelists 307
Guidewire PolicyCenter 9.0.9 Configuration Guide

For example, any modifications that you make to the AdditionalInsuredType typelist can potentially affect the
PolicyLine typelist that the AdditionalInsuredType typelist filters. Therefore, you must update all of the related
typelists.
After you open a typelist, Studio opens a typelist editor showing configuration options for that typelist.

The Studio typelist editor interface

The right side of the Typelist editor contains the following fields:
• Description
• Table name
• Final

The Description field

PolicyCenter transfers the value that you enter in the New→Typelist dialog for the type list name to the Description
field in the typelist editor. It is possible to edit this field.
Guidewire recommends that you add an _Ext suffix to the value that you enter for the type list name. This ensures
that the name of any typelist that you create does not conflict with a Guidewire typelist implemented in a future
database upgrade.

The Table Name field

By default, Guidewire uses pctl_typelist-name as the name of the typelist table. However, if you want a different
table name, you can override the default value by specifying a value in the Table name field for that typelist in Studio.
If you override the default value, the table name becomes pctl_table-name.
Guidewire restricts the typelist table name to ASCII letters, digits, and underscore. Guidewire also places limits on
the length of the name. However, if you choose, you can override the name of the typelist, which, in turn, overrides
the table name stored in the database.
Therefore:
• If you do not provide a value for the Table name field, then PolicyCenter uses the Name value and limits the table
name to a maximum of 25 characters.
• If you do provide a value for the Table name field, then this overrides the value that you set in the Name field.
However, the maximum table name length is still 25 characters.

Field Value entered in... Maximum length Database table name

Name New Typelist dialog 25 characters pctl_typelist-name

Table name Typelists editor 25 characters pctl_table-name

The Final field

A final typelist is a typelist to which you cannot add additional typecodes. You can, however, override the name,
description, priority, and retired attributes. All custom typelists that you create are non-final.

Search for an existing typelist definition

Procedure
1. In Guidewire Studio, press Ctrl+Shift+N.
2. In the Enter file name dialog, start typing the name of the typelist that you want to find.
Studio displays a list of matching entries that begin with the character string that you type.
3. In the list, click the name of the typelist that you want to view.
308 chapter 21: Working with typelists
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Pay attention to the typelist file extension. For example, if you type AccidentPremises, Studio displays a list
that includes all components whose name contains that text. Typelists will have a file extension of .tti, .tix,
or .ttx. Look for the typelist that ends with the appropriate extension.

Result
Studio opens the file in the appropriate editor.

Create a new typelist definition

Procedure
1. In the Project tools window, navigate to configuration→config→Extensions→Typelist.
2. Right-click on Typelist, and then click New→Typelist.
3. Enter the typelist name in the New Typelist dialog. PolicyCenter uses this name to uniquely identify this typelist
in the data model.
4. Enter a description. Use the Description field to create a longer text description to identify how PolicyCenter
uses this typelist. This text appears in places like the Data Dictionary.
5. Verify that the (Boolean) Final field is set to false. Studio automatically sets this field to false for any typelist
that you create. You have no control over this setting. This field has the following meanings:

True You cannot add or delete typecodes from the typelist. You can only override certain attribute fields.
False You can modify or delete typecodes from this typelist, except for typecodes designated as internal, which you
cannot delete. (You cannot remove internal typecodes, but you can modify their name, description, and other
fields.)

Extend an existing typelist definition

About this task
You can extend non-internal typelists that are in the following Guidewire Studio location:
configuration→config→Metadata→Typelist.

Procedure
1. In Guidewire Studio, in the Project tool window, navigate to configuration→config→Metadata, and then expand
Typelist.
2. Right-click the non-internal typelist that you want to extend, and then click New→Typelist Extension.
The file that you want to extend must be non-internal and have either a .tti or .tix file extension.
3. In the Typelist Extension dialog, Studio displays the name and location of the extension file it will create. Click
OK.

Result
Studio displays the name of your new file in the Extensions→Typelist folder and stores the new file at the following
location:
configuration/config/extensions/typelist

Studio then opens your new file in the appropriate editor.

Entering typecodes
Each typecode represents one value in the drop-down list. Every typelist must have at least one typecode.
Working with typelists 309
Guidewire PolicyCenter 9.0.9 Configuration Guide

Creating a new typecode

You must open or create a non-internal typelist extension or a custom typelist in the Typelist editor to create a new
typecode for a typelist. You cannot add a typecode to an internal typelist or typelist extension. See “Data entity
metadata files” on page 171 and “Different kinds of typelists” on page 306 for more information.
In the Typelist editor. In the Typelist editor, click Add .
With the new typecode selected, you can set the following values:
code
A unique identifier for internal Guidewire use. Enter a string containing only letters, digits, or the following
characters:
• Dot (.)
• Colon (:)
Do not include white space or use a hyphen (-).
Use this code to map to your legacy systems for import and export of PolicyCenter data. The code must be
unique within the list. The maximum number of characters in a typecode is 50.
See also “Mapping typecodes to external system codes” on page 323.
name
The text that is visible in PolicyCenter in the drop-down lists in the application. You can use white space and
longer descriptions. However, limit the number of characters so the drop-down list does not become too wide
on the screen. The maximum name size is 256 characters.
desc
A longer description of this typecode. The maximum description size is 512 characters. PolicyCenter displays
the text in this field in the PolicyCenter Data Dictionary.
identifierCode
Determines how typelist codes become Gosu programmatic identifier codes. See the Gosu Reference Guide.
priority
A value that determines the sort order of the typecodes (lowest priority first, by default). You use the priority
to sort the codes in the drop-down list and to sort a list by priority. If you omit this value, PolicyCenter sorts
the list alphabetically by name. You can specify priorities for some typecodes but not others, causing
PolicyCenter to order the prioritized typecodes at the top of the list with the unprioritized typecodes
alphabetized afterwards.
retired
A Boolean flag that indicates that a typecode is no longer in use. The value is still valid, but is not offered as a
choice in the drop-down list as a new value. PolicyCenter does not make changes to any existing objects that
reference this typecode. If you do not enter a value, PolicyCenter uses the default value of false.

Naming new typecodes

Guidewire recommends that you add the _Ext suffix to the code value for any new typecodes that you create. Do this
only if the code value is legal on any external system that needs to use the value. If that value is not legal, then omit
the _Ext suffix.

Maximum typelist size

Guidewire strongly recommends that you limit the size of a typelist to 2,000 typecodes. More than 2,000 typecodes
in a typelist can cause performance issues. If you need more than 2,000 typecodes, use a lookup (reference) table.
Guidewire does not support the use of more than 8,192 typecodes on a typelist.

See also
• “Typelist size recommendation” on page 304

Typelists and the data model

Guidewire recommends that you regenerate the Data Dictionary after you add or modify a typelist. Regenerating the
Data Dictionary is an excellent way to identify any flaws with your new or modified typelist.
310 chapter 21: Working with typelists
 Guidewire PolicyCenter 9.0.9 Configuration Guide

During application start up, Guidewire upgrades the application database if there are any changes to the data model,
which includes any changes to a typelist or typecode.

See also
• “Typelists and typecodes” on page 304
• “Mapping typecodes to external system codes” on page 323
• Integration Guide

Typekey fields
A typekey field is an entity field that PolicyCenter associates with a specific typelist in the user interface. The
typelist determines the values that are possible for that field. Thus, the specified typelist limits the available field
values to those defined in the typelist. (Or, if you filter the typelist, the field displays a subset of the typelist values.)
For a PolicyCenter field to use a typelist to set values requires the following:
1. The typelist must exist. If it does not exist, then you must create it using Guidewire Studio.
2. The typelist must exist as a <typekey> element on the entity that you use to populate the field. If the
<typekey> element does not exist, then you must extend the entity and manually add the typekey.
3. The PCF file that defines the screen that contains your typelist field must reference the entity that you use to
populate the field.

See also
• “Example: Typekey field” on page 311

Example: Typekey field

The following example illustrates how to use the Priority typelist to set the priority of an activity that you create in
PolicyCenter.
This example requires the following steps:
• “Step 1: Define the typelist in Studio” on page 311
• “Step 2: Add typekeys to the entity definition file” on page 311
• “Step 3: Reference the typelist in the PCF file” on page 312
• “Step 4: Update the data model” on page 313

Step 1: Define the typelist in Studio

It is possible to set a priority on an activity, a value that indicates the priority of this activity with respect to other
activities. In the base configuration, the Priority typelist includes the following typecodes:
• High
• Low
• Normal
• Urgent
You define both the Priority typelist and its typecodes (its valid values) through Guidewire Studio, through the
Typelist editor. For information on using the Typelist editor, see “Working with typelists in Studio” on page 307.
After completing this step, complete “Step 2: Add typekeys to the entity definition file” on page 311.

Step 2: Add typekeys to the entity definition file

Before beginning this step, complete “Step 1: Define the typelist in Studio” on page 311.
For an entity to be able to access and use a typelist, you need to define a <typekey> element on that entity. Use the
<typekey> element to specify the typelist in the entity metadata.
Working with typelists 311
Guidewire PolicyCenter 9.0.9 Configuration Guide

For example, in the base configuration, Guidewire declares a number of <typekey> elements on the Activity entity
([Link]), including the Priority typekey:
<entity entity="Activity" ... >
...
<typekey default="task"
desc="The class of the activity."
name="ActivityClass"
nullok="false"
typelist="ActivityClass"/>
<typekey desc="Priority of the activity with respect to other activities."
name="Priority"
nullok="false"
typelist="Priority"/>
<typekey default="open"
desc="Status of the activity."
exportable="false"
name="Status"
nullok="false"
typelist="ActivityStatus"/>
<typekey default="general"
desc="Type of the activity."
name="Type"
nullok="false"
typelist="ActivityType"/>
<typekey desc="Validation level that this object passed (if any) before it was stored."
exportable="false"
name="ValidationLevel"
typelist="ValidationLevel"/>
...
</entity>

Notice that the <typekey> element uses the following syntax:

<typekey desc="DescriptionString" name="FieldName" typelist="Typelist" />

After completing this step, complete “Step 3: Reference the typelist in the PCF file” on page 312.

See also
• For information on the <typekey> element, see “<typekey>” on page 220.
• For information on how to create data model entities, see “The PolicyCenter data model” on page 169.
• For information on how to modify existing data model entities, see “Modifying the base data model” on
page 237.

Step 3: Reference the typelist in the PCF file

Before beginning this task, complete “Step 2: Add typekeys to the entity definition file” on page 311.
Within Guidewire PolicyCenter, you can create a new activity. As you do so, you set a number of fields, including
the priority for that activity. In order for PolicyCenter to render a Priority field on the screen, it must exist in the PCF
file that PolicyCenter uses to render the screen.
Thus, the PolicyCenter NewActivityDV PCF file contains a Priority field with a value of [Link].

312 chapter 21: Working with typelists

 Guidewire PolicyCenter 9.0.9 Configuration Guide

After completing this step, complete “Step 4: Update the data model” on page 313.

See also

• For information on working with the PCF editor, see “Using the PCF editor” on page 349.
• For information on working with PCF files in general, see “Introduction to page configuration” on page 363.

Step 4: Update the data model

Before beginning this task, complete “Step 3: Reference the typelist in the PCF file” on page 312.
Guidewire recommends that you regenerate the PolicyCenter Data Dictionary before proceeding. If you have made
any mistakes in the previous steps, regenerating the Data Dictionary helps to identify those mistakes.
In any case, you need to stop and restart the application server before you can view your changes in the PolicyCenter
interface. Restarting the application server forces PolicyCenter to upgrade the data model in the application
database.

Removing or retiring a typekey

Ensure that you fully understand the dependencies between typelists and other application files before you modify a
typelist.
In general, Guidewire does not recommend that you make changes to existing typelists other than the following:
• Extending a non-final typelist to add additional typekeys.
• Retiring a typekey, which makes it invisible in the PolicyCenter interface, but leaves the typekey in the
application database.
Be very careful of removing typekeys from a typelist as it is possible that multiple application files reference that
particular typekey. Removing a typekey incorrectly can cause the application server to not start. Guidewire
recommends that you retire a typekey rather than remove it.
Working with typelists 313
Guidewire PolicyCenter 9.0.9 Configuration Guide

It is not possible to remove a typekey from a typelist marked as final. It is also not possible to remove a typekey
marked as internal. PolicyCenter indicates internal typekeys by placing their typecode values in gray, non-editable
cells. This makes these typecode values inaccessible and impossible to modify.

Remove a typekey
If you remove a typekey, you must ensure that PolicyCenter does not contain code that refers to that typekey.

About this task

Suppose that you delete the email_sent typekey from the base configuration DocumentType typelist. If you remove
this typekey, you must also update all other parts of PolicyCenter and prohibit the production of documents of that
type. In particular, you must remove references to the typekey from any .descriptor file that references that
typekey. In this case, a search of the document template files finds that the
[Link] file references email_sent.

Procedure
1. Navigate to the typelist that contains the typekey that you want to remove.
2. Click the typekey, and then click Remove .
3. Search for additional references to the typekey in the application files and remove any that apply. Pay
particular attention to .descriptor files. To remove a typekey reference:
a. Perform a case-insensitive text search throughout PolicyCenter files to find all references to the deleted
typekey.
b. Open these files in Studio and modify as necessary.

Retire a typekey
Procedure
1. Navigate to the typelist that contains the typekey that you want to retire.
2. Select the Retired cell of the typekey that you want to retire.
3. Set the cell value to true.

Next steps
If you retire a typekey, Guidewire recommends that you perform the steps outlined in “Remove a typekey” on
page 314 to identify any issues with the retirement:
• Verify all Studio resources.
• Perform a case-insensitive search in the application files for the retired typekey.

Typelist filters
It is possible to configure a typelist so that PolicyCenter filters the typelist values so that they do not all appear in the
drop-down list (typelist) in the PolicyCenter interface. Guidewire divides typelist filters into the following
categories:

Type Creates More information

Static A fixed (static) subset of the values on a typelist. You can create filters that: “Static filters” on
• Include certain specific typecodes on the typelist only. page 315
• Include certain specific categories of typecodes on the typelist.
• Exclude certain specific typecodes from the full list of the typecodes on the typelist.

314 chapter 21: Working with typelists

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Type Creates More information

Dynamic A dynamic subset of the values on a typelist. You can create filters that: “Dynamic filters” on
• Associate one or more typecodes on a parent typelist with one or more typecodes on a page 320
child typelist.
• Associate all the typecodes on a parent typelist with one or more typecodes on a child
typelist.

Static filters
A static typelist filter causes the typelist to display only a subset of the typecodes for that typelist. Therefore, a static
filter narrows the list of typecodes to show in the typelist view in the application. Guidewire calls this kind of
typelist filter a static typefilter.
In the Typelist editor of Guidewire Studio™, you define a static filter at the level of the typelist by defining a
typefilter for that particular typelist.
Studio manages the typelist XML file for you automatically. If you examine this file, you see that Studio uses the
following XML syntax to define a static typelist filter. (In this case, a static filter that defines—or includes—a subset
of the available typecodes.)
<typelistextension xmlns="[Link] desc="Yes, no or unknown" name="YesNo">
<typecode code="No" desc="No" name="No" priority="2"></typecode>
<typecode code="Yes" desc="Yes" name="Yes" priority="1"></typecode>
<typecode code="Unknown" desc="Unknown" name="Unknown" priority="3"/>
<typefilter desc="Only display Yes and No typelist values" name="YesNoOnly">
<include code="Yes"/>
<include code="No"/>
</typefilter>
</typelistextension>

The XML in this example declares each typecode on the typelist (Yes, No, and Unknown). It then defines a filter
named YesNoOnly that limits the available values to simply Yes and No. This filter is the static (fixed) filter.

See also

• For information on the <typefilter> element, see “<typekey>” on page 220

• “Create a static filter” on page 315

Create a static filter

About this task

See “Working with typelists in Studio” on page 307.

Procedure

1. Open Guidewire Studio™.

2. Define the typecodes for this typelist in the Typelist editor.

3. In the selector next to Add , click typefilter.

4. Set the following information for your static filter:

Attribute Description
name The name of the filter. PolicyCenter uses this value to determine if a field uses this filter.
desc Description of the context for which to use this typefilter.

Working with typelists 315

Guidewire PolicyCenter 9.0.9 Configuration Guide

Attribute Description
includeAll (Boolean) Typically, you only set this value to true if you use the exclude functionality.
• true indicates that the typelist view starts with the full list of typecodes. You then use exclusions to
narrow down the list.
• false (the default) instructs PolicyCenter to use values set in the various subpanes to modify the
typelist view in the application.

5. In the selector next to Add , click one of the following:

Subpane Use to More information

Add Categories Specify one or more typecodes to include by category “Creating a static filter using catego‐
within the filtered typelist view. ries” on page 316
Include Into Filter Specify one or more typecodes to include within the fil‐ “Creating a static filter using includes”
tered typelist view. on page 318
Exclude From Filter Specify one or more typecodes to exclude from the full list “Creating a static filter using excludes”
of typecodes for this typelist. on page 319

6. In the appropriate data model file, add a <typefilter> element to the child <typekey> for this typelist. To be
useful, you must declare a static typelist filter (a typefilter) on that entity. Use the following XML syntax:
<typekey name="FieldName" typelist="Typelist" desc="DescriptionString" typefilter="FilterName"/>

You must manually add a typelist to an entity definition file. Studio does not do this for you.
For example:
• The following code adds an unfiltered YesNo typelist to an entity:
<typekey desc="Some Yes/No question." name="YesNoUnknown" typelist="YesNo"/>

• The following code adds a YesNoOnly filtered YesNo typelist to an entity:

<typekey desc="Some other yes or no question." name="YesNo" nullok="true"
typefilter="YesNoOnly"
typelist="YesNo"/>

7. (Optional) Regenerate the Data Dictionary and verify that there are no validation errors.
8. Stop and restart the application server to update the data model.

See also
• “Typekey fields” on page 311

Creating a static filter using categories

Suppose that you want to filter a list of United States cities by state. (Say that you want to show a list of appropriate
cities only if you select a certain state.) To create this filter, you need to first to define a City typelist (if one does not
exist). You then need to populate the typelist with a few sample cities:

City typecode Location

ABQ Albuquerque, NM
ALB Albany, NY
LA Los Angeles, CA
NY New York, NY
SF San Francisco, CA
SND San Diego, CA

316 chapter 21: Working with typelists

 Guidewire PolicyCenter 9.0.9 Configuration Guide

City typecode Location

SNF Santa Fe, NM

Then, for each City typecode, you need to set a category, similar to the following:
1. Click on a typecode.
2. In the selector next to Add , click Add Categories.
3. Select one or more typecodes to apply to this category.
4. Click Next.
5. In the Typelist pane, click the associated category typelist.
6. In the Category pane, click the associated category typecode.
7. Click Finish.
Do this for each of the following:

City typecode Associated typelist Associated typecode

ABQ State NM
ALB State NY
LA State CA
NY State NY
SF State CA
SND State CA
SNF State NM

To generalize this example to regions outside the United States, you could associate the Jurisdiction typelist and a
specific jurisdiction with each city typecode instead.
After making your choices, you have something that looks similar to the following:

This neatly categorizes each typecode by state.

Now you can create a static filter that contains only cities that are in a certain state. Do the following:
1. In the selector next to Add , click typefilter.
2. Type California for the filter name and description.
3. Click the typefilter, and then in the selector next to Add , click category.
Working with typelists 317
Guidewire PolicyCenter 9.0.9 Configuration Guide

4. For the category, set the code to CA, and the typelist to State.
This action creates a static category filter that contains only cities that are in the state of California. Initially, the
typelist contains Los Angeles, San Francisco, and San Diego. If you add additional cities to the list at a later time
that also exist in California, then the typelist displays those cities as well.
To be useful, you need to also do the following:
• Add the typelist to the entity that you want to display the typelist in the PolicyCenter user interface.
• Reference the typelist in the PCF file in which you want to display the typelist.
See “Typekey fields” on page 311 for more information on declaring a typelist on an entity and referencing that
typelist in a PCF file. In general, though, you need to add something similar to the entity definition that want to
display the typelist:
<typekey name="California" typelist="City" typefilter="California" nullok="true"/>

Creating a static filter using includes

Suppose that you want to create a filtered typelist that displays zone codes that are in use only in Canada and not any
other country. One way to create the filter is to use an Includes filter on the ZoneType typelist.
In this example, you want the typelist to display only the following:
• fsa
• province
The following table shows the typecodes in the ZoneType typelist:

ZoneType typecode Associated typelist Associated typecode Include in filter

city Country CA (Canada)
US (United Stated)
county Country US
fsa Country CA •
postalcode Country AU
CA
DE
province Country CA •
state Country AU
DE
US
zip Country US

To create an includes filter

1. Open the typelist that you want to filter in the Guidewire Studio™ Typelists editor.

2. In the selector next to Add , click Include Into Filter.

3. In the Typecodes list, select fsa and province.
4. Click Next.
5. On the New Filter tab, in the Name and Description text boxes, type CAOnlyFilter.
6. Click Finish.

318 chapter 21: Working with typelists

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Creating a static filter using excludes

Suppose that you want to create a filtered typelist that displays all of the zone codes except those that are in use in
Canada. You want to display the complete list of typecodes in the ZoneType typelist except for the following:
• city
• fsa
• province
The following table shows the typecodes in the ZoneType typelist:

ZoneType typecode Associated typelist Associated typecode Include in filter

city Country CA (Canada)
US (United Stated)
county Country US •
fsa Country CA
postalcode Country AU
CA
DE
province Country CA
state Country AU •
DE
US
zip Country US •

To create an excludes filter

1. Open the typelist that you want to filter in the Guidewire Studio™ Typelists editor.
2. In the selector next to Add , click Exclude From Filter.
3. In the Typecodes list, select the typecodes that you want to exclude. For example, select city and fsa.
4. Click Next.
5. On the New Filter tab, in the Name and Description text boxes, type ExcludesCanada.
6. Set the Include all typecodes check box true. This ensures that you start with a full set of typecodes.
7. Click Finish.
Working with typelists 319
Guidewire PolicyCenter 9.0.9 Configuration Guide

Dynamic filters
A typecode filter uses categories and category lists at the typecode level to restrict or filter a typelist. Typecode
filters use a parent typecode to restrict the available values on the child typecode.
You define a typecode filter directly on a typecode in Guidewire Studio™. In the Typelist editor, you select a specific
typecode and set a filter, or category, on that typecode.
There are two types of typecode filters that you can define:

Filter type Use to More information

Category Associate one or more typecodes on a parent typelist with one or more typeco‐ “Dynamic filters” on page 320
des on a child typelist.
Category list Associate all of the typecodes on a parent typelist with one or more typecodes “Dynamic filters” on page 320
on a child typelist.

Category typecode filters

• You use a category filter to associate one or more typecodes from one or more typelists with a specific typecode
on the filtered typelist.
• You define a category filter in the Typelist editor by adding a category to a typecode.

Category list typecode filters

• You use a category list filter to associate all of the typecodes from one or more typelists with a specific typecode
on the filtered typelist.
• You define a category list filter in the Typelists editor by adding a category list to a typecode.

Creating a dynamic filter

In general, to create a dynamic filter, you need to do the following:
• “Step 1: Set the category filter on each typecode” on page 321
• “Step 2: Declare the category filter on an entity” on page 321
• “Step 3: Set the PolicyCenter field value in the PCF file” on page 322
• “Step 4: Regenerate the Data Dictionary” on page 322
As the process of declaring a typecode filter on an entity can be difficult to understand conceptually, it is simplest to
proceed with an example. Within Guidewire PolicyCenter, a user with administrative privileges can define a new
320 chapter 21: Working with typelists
 Guidewire PolicyCenter 9.0.9 Configuration Guide

activity pattern (Administration→Business Settings→Activity PatternsNew Activity Pattern). Within the New Activity Pattern
screen, you see the following drop-down lists:
• Type
• Category
PolicyCenter automatically sets the default value of Type to General. This value determines the available choices
that you see in the Category drop-down list. For example:
• Correspondence
• General
• Interview
• New mail
• ...
The ActivityCategory typelist is the typelist that controls what you see in the Category field in PolicyCenter. If you
open this typelist in the Studio Typelist editor, you can choose each typecode in the list one after another. As you
select each typecode in turn, notice that the Studio associates each typecode with a category containing typelist and
code values. In this case, Studio associates each ActivityCategory typecode with an ActivityType typecode.
Thus, PolicyCenter filters each individual typecode in this typelist so that it is available for selection only if you first
select the associated typelist and typecode.

Step 1: Set the category filter on each typecode

The process is the same to create a category list typecode filter. In that case, you associate a single typelist (and all
its typecodes) with each individual typecode on the dependent typelist. You make the association by selecting a
typecode in the dependent typelist and adding a category.
Open the ActivityCategory typelist and select each typecode in turn. As you do so, you see that Studio associates
each typecode with an ActivityType code value as a category. For example, if you select the interview typecode,
you see that PolicyCenter associates this typecode with an ActivityType code value of general. You would need
to duplicate this process if you create a custom filtered typelist or if you customize an existing typelist. The
following graphic illustrates this process.

After completing this task, complete “Step 2: Declare the category filter on an entity” on page 321.

Step 2: Declare the category filter on an entity

Before beginning this task, complete “Step 1: Set the category filter on each typecode” on page 321.
The question then becomes how do you set this behavior on the ActivityPattern entity. In other words, what XML
code do you need to add to the ActivityPattern entity to enable the ActivityType typelist to control the values
shown in the PolicyCenter Category field? The following sample illustrates what you need to do. You must add a
typekey for both the parent (ActivityType) typelist and the dependent child (ActivityCategory) typelist.

Working with typelists 321

Guidewire PolicyCenter 9.0.9 Configuration Guide

The sample defines a typekey element with name="Type" and typelist="ActivityType". This is the controlling
(parent) typelist. The sample also defines a second typelist (ActivityCategory) with a keyfilter name="Type". It is
the typelist referenced by the keyfilter element that controls the behavior of the typelist named in the typekey
element. Thus, the value of the ActivityType code controls the associated typecode on the dependent
ActivityCategory typelist.
For more information on the <keyfilter> element, see “<typekey>” on page 220.
After completing this task, complete “Step 3: Set the PolicyCenter field value in the PCF file” on page 322.

Step 3: Set the PolicyCenter field value in the PCF file

Before beginning this task, complete “Step 2: Declare the category filter on an entity” on page 321.
After you declare these two typelists on the ActivityCategory entity, you need to link the typelists to the
appropriate fields on the PolicyCenter New Activity Pattern screen. To access an entity typelist, you need to use the
[Link] syntax. For example, to access the ActivityCategory typelist on the ActivityPattern entity,
use [Link] with Category being the name of the typelist.
After completing this task, complete “Step 4: Regenerate the Data Dictionary” on page 322.

Step 4: Regenerate the Data Dictionary

Before beginning this task, complete “Step 3: Set the PolicyCenter field value in the PCF file” on page 322.
Guidewire recommends that you regenerate the PolicyCenter Data Dictionary before proceeding. If you have made
any mistakes in the previous steps, regenerating the Data Dictionary helps to identify those mistakes.
In any case, you need to stop and restart the application server before you can view your changes in the PolicyCenter
interface. Restarting the application server forces PolicyCenter to upgrade the data model in the application
database.

Typecode references in Gosu

To refer to a specific typecode in Gosu, use the following syntax.
[Link].TC_Typecode

For example, the default State typelist has typecodes for states in the US and provinces in Canada.
To refer to the typecode for the state of California in the typelist State, use the following Gosu expression.
[Link].TC_CA

You must prefix the code in the object path expressions for typecodes with TC_.

322 chapter 21: Working with typelists

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Note: In the typecode reference syntax, use the appropriate nested class name if and only if your
typelist has over 2,048 typecodes. This modified syntax is as follows:
[Link].[NestedClassName.]TC_Typecode

Note: Use code completion in Studio to build complete object path expressions for typecodes. Type
“typekey.” to begin, and work your way down to the typecode that you want.

See also
• “Typelists and typecodes” on page 304

Mapping typecodes to external system codes

Your PolicyCenter application can share or exchange data with one or more external applications. If you use this
functionality, Guidewire recommends that you configure the PolicyCenter typelists to include typecode values that
are one-to-one matches to those in the external applications. If the typecode values match, sending data to, or
receiving data from, those applications requires no additional effort on the part of an integration development team.
However, there can be more complex cases in which mapping typecodes one-to-one is not feasible. For example,
suppose that it is necessary to map multiple external applications to the same PolicyCenter typecode, but the
external applications do not match. Alternatively, suppose that you extend your typecode schema in PolicyCenter.
This can possibly cause a situation in which three different codes in PolicyCenter represent a single (less granular)
code in the other application.
To handle these more complex cases, edit the file [Link] in the
configuration→config→[Link] folder. This file specifies a namespace for each external application. Then you
identify the individual unique typecode maps by typelist.

A typecode mapping example

The following code sample illustrates a simple [Link] file:
<?xml version="1.0"?>
<typecodemapping>
<namespacelist>
<namespace name="accounting"/>
</namespacelist>

<typelist name="AccountSegment">
<mapping typecode="PR" namespace="accounting" alias="ACT"/>
</typelist>
</typecodemapping>

The namespacelist element contains one or more namespace elements—one for each external application. Then, to
map the actual codes, specify one or more typelist elements as required. Each typelist element refers to a single
internal or external typelist in the application. The typelist, in turn, contains one or more mapping elements. Each
mapping element must contain the following attributes:

Attribute Description
typecode The PolicyCenter typecode.
namespace The namespace to which PolicyCenter maps the typecode

alias The code in the external application.

In the previous example, the PR PolicyCenter code maps to an external application named accounting. You can
create multiple mapping entries for the same PolicyCenter typecode or the same name space. For example, the
following specifies a mapping between multiple PolicyCenter codes and a single external code:
<typelist name="BoatType">
<mapping typecode="AI" namespace="accounting" alias="boat"/>

Working with typelists 323

Guidewire PolicyCenter 9.0.9 Configuration Guide

<mapping typecode="HY" namespace="accounting" alias="boat"/>

</typelist>

After you define the mappings, from an external system you can use the TypelistToolsAPI web service to translate
the mappings. See the Integration Guide.

324 chapter 21: Working with typelists

chapter 22

The PolicyCenter archive domain

graph

The archive domain graph defines the cluster of entity types that PolicyCenter treats as a single aggregate for
purposes of archiving data.

See also
• Application Guide

Understanding archiving in Guidewire PolicyCenter

PolicyCenter supports archiving policy terms as serialized streams of data, with one serialized stream per
PolicyPeriod entity in the term. Each serialized stream is an XML document. You can choose how to store the
XML documents in an external system. Store the data as files, as database binary large objects, or documents in a
document storage system.
From the user perspective, PolicyCenter archives or retrieves a policy term. A policy term is the
logical unit of archiving.
PolicyCenter does not store a policy term as a single XML document. Instead, PolicyCenter serializes and stores one
XML document for every PolicyPeriod graph in the policy term. A PolicyPeriod graph means one
PolicyPeriod object and its subobjects. The PolicyPeriod graph is the physical unit of archiving. PolicyCenter
archives each PolicyPeriod graph in the term sequentially in an internally-defined order. PolicyCenter stops
archiving that term if there are any errors with any PolicyPeriod.
After archiving, PolicyCenter deletes most PolicyPeriod subobjects. However, PolicyCenter retains the
PolicyPeriod entity instance and its associated entity instances of type EffectiveDatedFields and Document.
Additionally, in certain circumstances certain other objects are retained:
• PolicyCenter deletes Note objects associated with the job of the archived policy period if and only if it has no
associated activity.
• PolicyCenter deletes UWIssueHistory objects if and only if it is an auto-approved issue
• PolicyCenter deletes FormTextData objects only with the last remaining PolicyPeriod to archive in that term.
In other words, it is always deleted, but in the last database transaction along with the last remaining archived
PolicyPeriod in the term.
PolicyCenter documentation refers to a PolicyPeriod object as the root info object for that archived data. The
name root info object refers to the RootInfo delegate, which the PolicyPeriod entity type implements. Some
The PolicyCenter archive domain graph 325
Guidewire PolicyCenter 9.0.9 Configuration Guide

archiving APIs use the RootInfo object as a method argument or return type. For PolicyCenter, when you see
RootInfo, this refers to a PolicyPeriod instance.
After archiving, PolicyCenter makes the PolicyPeriod data effectively immutable while that period is archived.
However, within one policy term, at any given instant, it is possible that one or more periods are archived but not all.
From the user interface standpoint, PolicyCenter considers a given policy term archived if one or more of the
periods in the term is archived, even if not all are archived.

Overview of the archive domain graph

The archive domain graph defines the cluster of related entity instances that PolicyCenter treats as a single
aggregate for purposes of archiving data. The archive domain graph begins with a root entity type and ends at a
boundary of related entity types.

Root The root of the archive domain graph is a specific entity type. Starting with the root entity type, the graph follows
ownership relationships in the data model to other entity types until the boundary of the graph is reached. In
PolicyCenter, the root entity type in the archive domain graph is PolicyPeriod.
Boun‐ The boundary of the archive domain graph defines which entity types terminate the traversal of owner relationships
dary from the root and thus prescribe the extent of entities within the graph. In PolicyCenter, the boundary includes the
major entities that relate to the PolicyPeriod entity type, including effective dated entity types such as
PolicyAddress and PolicyDriver.

In PolicyCenter, for an entity to be in the archive domain graph:

• The entity must implement the Extractable delegate.
• The entity must have a foreign key relationship with an entity in the archive domain graph.
In PolicyCenter, most entity types in the archive domain graph implement the Extractable delegate by inheritance
through the EffDatedBase entity.
All entities in the archive domain graph must set the entity effDatedBranchType attribute to PolicyPeriod. For
example:
<entity xmlns="[Link] ...
effDatedBranchType="PolicyPeriod"
entity="BAStateCov"
type="effdated">

There is only one root to the archive domain graph, PolicyPeriod, and it implements the RootInfo delegate.
Note: There are other PolicyCenter entities that implement the RootInfo delegate, for example, Job
and Policy, among others. These entities are not in the archive domain graph, however, because they
do not set attribute effDatedBranchType to PolicyPeriod. Instead, PolicyCenter uses these entities
during purging of unnecessary data such as policy quotes not taken.
Note: If PolicyCenter has a database upgrade trigger that updates an entity in the archive domain
graph, PolicyCenter also includes an upgrade trigger to update this entity upon retrieval from the
archive.

The archive domain graph is a directed acyclic graph

The archive domain graph is an example of a directed acyclic graph:
• It is a graph that comprises nodes and the relationships between the nodes.
• It is a directed graph because you can traverse a relationship in one direction only. For example, if node A and
node B have a relationship, you can traverse from A to B or from B to A but not in both directions.
• It is a directed acyclic graph because the graph does not permit the traversal of cycles in the graph. For example,
if you can traverse from node A to node B and from node B to node C, you then cannot traverse from C to A.
The PolicyCenter data model itself also is a directed acyclic graph based on foreign key relationships between entity
types.
326 chapter 22: The PolicyCenter archive domain graph
 Guidewire PolicyCenter 9.0.9 Configuration Guide

IMPORTANT Guidewire expressly prohibits bidirectional relationships between PolicyCenter entity

types. This prohibition ensures that PolicyCenter can commit related entity instances in a transactional
bundle in a safe order without exceptions or deadlocks.

The archive domain graph and entity instance graphs

The archive domain graph is a subset of the of data model graph and begins with the root entity PolicyPeriod.
There are two ways to think of the archive domain graph:
• The entity graph defines the archive root entity and the specific PolicyCenter entity types that the archive root
owns.
• The instance graph is a single specific instance of the archive domain graph. It includes the archive root entity
and the set of entity instances that link to the archive root.
It is important to fully understand the distinction between the two types of archive domain graphs.

Graph type Description

Entity type An entity archive domain graph defines the set of entity types that the archive root entity owns. PolicyCenter
builds this graph a single time at server startup and thereafter uses the graph to create individual instances of
the archive domain graph.
The PolicyCenter data model contains exactly one entity type archive domain graph.
Instance type An instance archive domain graph is the graph of all individual entity instances that belong to the archive root.
PolicyCenter builds this graph by following the foreign key links from the archive root, using the entity type
graph to determine which keys to follow. The PolicyCenter database contains as many instances of the archive
instance graph as there are instances of the archive root entity. It is possible to archive each separate instance
of the archive domain graph.

The archive domain graph and reference data

Within the PolicyCenter data model there are entity types outside the archive domain graph to which an entity type
inside the graph refers through a foreign key link. Guidewire refers to these types of entities as reference entities or
reference data. Although linked to an entity type inside the graph, PolicyCenter does not actually archive reference
data during the archive process.
Guidewire requires that all such reference entities be retireable, and not just editable or versionable. Otherwise, if
PolicyCenter actually deleted a reference entity (rather than just marking the entity as retired), attempting to retrieve
the entity would cause a foreign key violation. The following example illustrates this concept.
Suppose that there exists an archive domain graph entity A that has a foreign key link to some reference data entity
B. Suppose also that PolicyCenter archives an instance of entity A (and its link to an entity instance of B) at some
point in time. A PolicyCenter user then deletes that particular instance of B, which remove it from the PolicyCenter
database. At some later time, PolicyCenter attempts to retrieve the archived instance of entity A. However, as entity
B no longer exists in the database, PolicyCenter generates a foreign key violation because the link from A points to
nothing.
Reference data entities must not implement either of the following delegates:
• Extractable
• Overlap
If you do not mark reference entities correctly, PolicyCenter generates a fatal validation error at server startup.

Understanding PolicyCenter entity ownership

Guidewire defines the ownership of one entity by another by defining a foreign key between the two entities.
Generally, foreign keys point from owned entities to owning entities in the archive domain graph. Thus, a foreign
key to entity A from entity B indicates that entity A owns entity B.
The PolicyCenter archive domain graph 327
Guidewire PolicyCenter 9.0.9 Configuration Guide

Guidewire explicitly defines the relationship between the owned and owning entity in an entity metadata definition
by adding an archivingOwner attribute to the <foreignkey> element definition. For example:
<?xml version="1.0"?>
<entity xmlns="[Link] desc="Notes added by users" entity="Note"... >
...
<foreignkey
columnName="ActivityID"
desc="The activity associated with the note."
archivingOwner="..."
exportable="false"
fkentity="Activity"
name="Activity"
nullok="true"/>
...
</entity>

The archivingOwner attribute can be any of the following values:

• none – There is no ownership relationship between the source and the target of the link.
• target – The target of the foreign key owns the link.
• source – The source of the foreign key owns the link. Guidewire calls this type of link an inverse foreign key.
You use the value of the archivingOwner attribute to set the direction of the link that the foreign key represents.
The following table summarizes these concepts.

Ownership Description
Entity owner‐ A child entity (B) has a foreign key to its parent entity (A). The foreign key definition includes setting attribute
ship archivingOwner to target, which indicates that A (the target) owns B (the source). If this attribute is missing
from the foreign key definition, PolicyCenter assumes a value of target, the default.
For example, in the base PolicyCenter configuration, entity Note has a foreign key relationship with the
PolicyPeriod entity. See also “Ownership through the effective dated branch” on page 329.

Inverse owner‐ A child entity (B) has a foreign key to its parent entity (A). However, the foreign key definition sets attribute
ship archivingOwner to source, which indicates that B (the source) owns A (the target). Thus, the direction of the
foreign key for ownership is the inverse of typical entity ownership.
For example, in the base PolicyCenter configuration, entity Contact has a foreign key relationship with the
Address entity.
IMPORTANT Guidewire discourages the use of inverse ownership relationships. The PolicyCenter data model
supports inverse ownership relationships for the rare case in which upgrading the database is unduly cumber‐
some or time consuming. As a general rule, do not use this type of relationship.

Foreign key ownership in the archive domain graph

A foreign key defines an ownership relationship between two entities. Generally, foreign keys point from owned
entities to owning entities in the archive domain graph.
The following graphic illustrates this concept.

Owning Object Owned Object

Foreign key
Ownership flow

To illustrate, in the base PolicyCenter configuration, Note has a foreign key to PolicyPeriod. The following Note
metadata definition extension shows this relationship.
<internalExtension xmlns="[Link]
entityName="Note" javaClass="[Link]">

328 chapter 22: The PolicyCenter archive domain graph

 Guidewire PolicyCenter 9.0.9 Configuration Guide

...
<foreignkey columnName="PolicyPeriodID"
desc="Associated Policy Period."
exportable="false"
fkentity="PolicyPeriod"
name="PolicyPeriod"/>
...
</internalExtension>

As the code does not provide a value for the archivingOwner attribute, PolicyCenter uses its default value, which is
target. Thus, the owner of the Note entity is the PolicyPeriod entity.
Note: A Note also can be owned by other entities, such as Job.

Inverse foreign key ownership in the archive domain graph

IMPORTANT Guidewire discourages the use of inverse ownership relationships. The PolicyCenter
data model supports inverse ownership relationships for the rare case in which upgrading the database
is unduly cumbersome or time consuming. Do not use this type of relationship as a general rule.

A foreign key defines an ownership relationship between two entities. Generally, foreign keys point from owned
entities to owning entities in the archive domain graph. However, in certain rare cases, it is possible to define a
foreign key that points from the owning entity to the owned entity in the archive domain graph.
The following graphic illustrates this concept.

Owning Object Owned Object

Foreign key
Ownership flow

To illustrate, in the base PolicyCenter configuration, Contact and Address have an ownership relationship, with a
foreign key from Contact to Address. The following Contact metadata definition shows this relationship.
<?xml version="1.0"?>
<entity desc="Represents a generic contact like a person or a business." entity="Contact" ...>
...
<foreignkey archivingOwner="source"
columnName="PrimaryAddressID"
desc="Primary address associated with the contact."
fkentity="Address"
name="PrimaryAddress"
nullok="true"
triggersValidation="true"/>
...
</entity>

The archivingOwner attribute of source on the Address foreign key indicates an inverse ownership relationship.
Thus, the Contact entity is the owner of the Address entity.

Ownership through the effective dated branch

In PolicyCenter, an effective dated entity is owned by the root of the effective dated branch. For example,
PolicyLocation is an effective dated entity owned by PolicyPeriod.
The following PolicyLocation metadata definition illustrates how an effective dated entity is owned by
PolicyPeriod.
<entity ... effDatedBranchType="PolicyPeriod" entity="PolicyLocation" ... type="effdated">

The PolicyCenter archive domain graph 329

Guidewire PolicyCenter 9.0.9 Configuration Guide

Ownership relationships in the PolicyCenter archive domain

graph
The following graphic illustrates the relationships between a subset of the entity types in the PolicyCenter data
model. The graphic contains entities in the archive domain graph, in reference data, and in overlap tables.
In the diagram:
• A solid arrow line with a single tail indicates that the two graph entities are related in the data model by a foreign
key. The tail of the arrow indicates the entity type on which the data model declares the foreign key. The head of
the arrow indicates the owning entity. For example, the arrow between Document and Account indicates that
there is a foreign key between Document and Account and that an account can have (own) a document.
• A solid arrow line with a multiline tail indicates that the two graph entities are related in the data model by a
foreign key and an array. The head of the arrow indicates the entity type on which the data model declares the
array. For example, a PolicyPeriod instance can have (own) an array of forms.

Relationship between domain graph, overlap tables, and reference data

Domain graph

PolicyPeriod EffectiveDatedFields

Revision graph

Form PATransaction PolicyLocation PolicyLine

Overlap tables

Note Document

Reference
data Legend

User Account Contact A B B has an A

A B B has an array of A

AccountLocation Job PolicyTerm

In the PolicyCenter archive domain graph:

• The PolicyPeriod entity type—and only that entity type—implements the RootInfo delegate.
• The entity types in the archive domain graph must implement the Extractable delegate either directly or by
inheritance through the EffDatedBase entity.
• The EffectiveDatedFields entity type is part of the revision graph and the archive domain graph. PolicyCenter
retains this entity in the database during archiving.
• The Note and Document entity types implement the OverlapTable delegate, as well as the Extractable
delegate. Entity types that implement both of these delegates can exist as members of the archive domain graph
and as reference data outside the graph. Individual rows in an overlap table can exist only as part of the archive
domain graph or as reference data, but not both.
330 chapter 22: The PolicyCenter archive domain graph
 Guidewire PolicyCenter 9.0.9 Configuration Guide

During the archive process:

• PolicyCenter does not remove the PolicyPeriod entity instance from the database.
• PolicyCenter does not remove the EffectiveDatedFields entities associated with the PolicyPeriod entity
instance from the database.
• PolicyCenter removes the entities in the revision graph from the database.
• PolicyCenter removes entities in the overlap tables if they apply to the policy period.
• Entity types that do not implement either the Extractable or OverlapTable delegate are reference data.
PolicyCenter does not archive reference data.

See also

• “<implementsEntity>” on page 214

• “<delegate> elements and related data object types” on page 180
• “The archive domain graph and reference data” on page 327
• “Archive entities and the EffDated delegate” on page 333

Entities in the archive domain graph

For PolicyCenter to consider an entity as part of the archive domain graph, that entity must implement one or more
delegates. A delegate adds an interface and a default implementation of that interface to entity types that implement
the delegate. Some delegates also add columns that the delegate implementation manages. The archiving delegates
help define the extent of the archive domain graph and are necessary for successful operation of the archive process.

WARNING Do not change or remove the archiving delegates on Guidewire entities in the base
configuration. Otherwise, it is possible for the PolicyCenter server to not start due to errors in the
archive domain graph.

In addition, any new entity that you want to add to the archive domain graph must have an ownership relationship
with another entity already in the graph. You can establish ownership in one of the following ways:
• By defining a foreign key in the new entity to another entity already in the graph.
• By defining a foreign key to the new entity from an entity already in the graph and setting the attribute
archivingOwner="source".
The following table summarizes the entity types that exist in the archive domain graph.

Entity type Delegate Implementation For more information

Graph root entity The root of archive domain graph must implement the RootInfo delegate. “Archive entities and the
You cannot change this designation. For PolicyCenter, the RootInfo entity is RootInfo delegate” on
PolicyPeriod. page 332
EffDated entities Entities in the PolicyCenter archive domain graph implement the “Archive entities and the
Extractable delegate through the EffDated delegate. EffDated delegate” on
page 333
Overlap table enti‐ Overlap tables are tables in which individual table rows can exist either in the “Archive entities and the
ties archive domain graph or as part of reference data, but not both. The database OverlapTable delegate”
table itself exists in the archive domain graph and as reference data. All over‐ on page 334
lap table entities, and only overlap table entities, must implement the
OverlapTable delegate.
In PolicyCenter, only Note and Document entities implement the
OverlapTable delegate.
The primary use for these types of entities is for Guidewire code. The use of
overlap tables by non‐Guidewire code is not common.

The PolicyCenter archive domain graph 331

Guidewire PolicyCenter 9.0.9 Configuration Guide

See also
• “<delegate> elements and related data object types” on page 180
• “The archive domain graph and reference data” on page 327
• “Ownership relationships in the PolicyCenter archive domain graph” on page 330
• “Ownership through the effective dated branch” on page 329

Archive entities and the RootInfo delegate

Whenever PolicyCenter archives an instance of the archive domain graph, PolicyCenter keeps the following entities
in the main PolicyCenter database:
• The PolicyPeriod entity instance
• The related EffectiveDatedFields entity instance for the PolicyPeriod
• Other, optional, entity instances
The root of the archive domain graph must implement the RootInfo delegate. In PolicyCenter, the PolicyPeriod
entity type implements the RootInfo delegate. You cannot change which entity type implements the RootInfo
delegate. It must always be PolicyPeriod.
The PolicyPeriod instance provides the following:
• Sufficient information to retrieve the archival data
• Sufficient information for a minimal search on archival data
The following sample code shows the metadata definition of the PolicyPeriod entity implementing the RootInfo
delegate.
<entity xmlns="[Link]
desc="Policy Period allows a point in time reconstruction of all key policy attributes."
effDatedContainerField="Policy"
entity="PolicyPeriod"
exportable="true"
loadable="false"
lockable="true"
table="policyperiod"
type="effdatedbranch">
...
<implementsEntity name="RootInfo"/>
...
</entity>

PolicyCenter does not archive the PolicyPeriod table. PolicyCenter archives only the tables that the PolicyPeriod
entity type owns.

IMPORTANT Because PolicyCenter does not archive the PolicyPeriod table, the table continues to
grow regardless of archiving. Therefore, Guidewire recommends against extending the PolicyPeriod
entity to store large amounts of data, such as BLOB fields.

Archive entities and the Extractable delegate

All entities in the archive domain graph must implement the Extractable delegate. Entities outside the archive
domain graph must not implement the Extractable delegate. The Extractable delegate creates the
ArchivePartition column that PolicyCenter uses during the archive process.
In Guidewire PolicyCenter, most entity types in the archive domain graph implement the Extractable delegate by
inheritance through the EffDatedBase entity.

See also
• “Archive entities and the EffDated delegate” on page 333
332 chapter 22: The PolicyCenter archive domain graph
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Specifying the Extractable delegate on entities

The following extension metadata definition of the Document entity shows that it implements the Extractable
delegate, which makes Document part of the archive domain graph.
<internalExtension xmlns="[Link] entityName="Activity">
...
<implementsEntity name="Extractable"/>
...
</entity>

See also
• “Archive entities and the EffDated delegate” on page 333

Specifying the Extractable attribute on edge foreign keys

In Guidewire PolicyCenter, an edge foreign key defines a reference link to another entity in the similar manner as a
foreign key does. However, you use an edge foreign key in place of a standard foreign key to break a cycle of
foreign keys in the data model.
If you add an edge foreign key to an entity that is part of the archive domain graph, set the extractable attribute on
the edge foreign key to true. The value true causes PolicyCenter to add the Extractable delegate to the
associative table generated for the edge foreign key. In addition, the entity type that the edge foreign key relates to
must implement the Extractable delegate.

IMPORTANT If the extractable attribute is not set to true for an edge foreign key on an entity that
is part of the archive domain graph, the server does not start.

The following entity metadata definition illustrates this concept.

<entity xmlns="[Link]
desc="Policy Period allows a point in time reconstruction of all key policy attributes."
effDatedContainerField="Policy"
entity="PolicyPeriod"
exportable="true"
loadable="false"
lockable="true"
table="policyperiod"
type="effdatedbranch">
...
<edgeForeignKey desc="The workflow that is active from the perspective of the UI."
edgeTableName="PRActiveWorkflow"
exportable="false"
fkentity="PolicyPeriodWorkflow"
name="ActiveWorkflow"
extractable="true"
nullok="true"/>
...
</entity>

Archive entities and the EffDated delegate

In PolicyCenter, certain entities in the archive domain graph implement the Extractable delegate through the
EffDated delegate. The following illustration shows how PolicyLocation implements Extractable.

The PolicyCenter archive domain graph 333

Guidewire PolicyCenter 9.0.9 Configuration Guide

Implementing the Extractable delegate

<<delegate>>
Extractable

<<delegate>>
EffDatedBase
Legend

A B A has a B

<<delegate>>
EffDated A B A delegates to B

Domain graph
PolicyPeriod

Revision graph

PolicyLocation

See also
• “Ownership relationships in the PolicyCenter archive domain graph” on page 330

Archive entities and the OverlapTable delegate

Overlap tables are tables with rows that can exist either in the archive domain graph or either as part of reference
data, but not both. Any attempt to create a table row that exists in both the archive domain graph and the reference
data causes archiving to fail.
Entities that use overlap tables must implement the OverlapTable delegate. As these entities are both inside and
outside the archive domain graph, they must also implement the Extractable delegate as well.

Specifying the OverlapTable delegate on entities

In PolicyCenter, the Document and Note tables are overlap tables. The following metadata definition of a data model
extension to the Document entity type illustrates how to implement the OverlapTable delegate.
<implementsInterface iface="[Link]"
impl="[Link]"/>
...
<implementsEntity name="Extractable"/>
<implementsEntity name="OverlapTable"/>
...
</internalExtension>

Specifying the OverlapTable attribute on edge foreign keys

In the base configuration, PolicyCenter does not implement the OverlapTable delegate through edge foreign keys.
Guidewire recommends that you do not use edge foreign keys to implement the OverlapTable delegate.
334 chapter 22: The PolicyCenter archive domain graph
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Data model changes that impact archiving

Sometimes changes that you make to the data model inadvertently affect archiving. In general, there are two
categories of data model changes that can affect the archive domain graph. They are:
• A new entity becomes part of the archive domain graph
• An entity no longer exists as part of the archive domain graph

A new entity becomes part of the archive domain graph

Suppose, for example, that you add an additional entity type to the PolicyCenter archive domain graph. If the
archive domain graph never referred to that entity previously, it does not appear in any XML representation of the
archived entity instance. There is no issue.
However, suppose that an archived graph does refer to an entity type newly added to the graph:
• The entity instance appears as a referenced entity in the XML.
• On retrieve, the archive process looks for that entity in the database and links to it.
• On re-archive of the entity instance, the archive process correctly exports the entity instance in the XML. There
is no issue as long you do not delete the entity.

An entity no longer exists as part of the archive domain graph

It is possible for an entity to no longer exist as part of the graph. This can happen, for example, if the entity type was
part of reference data that was shared by multiple policy periods, but is now removed from the archive domain
graph.
Suppose, for example, that you remove an entity type from the PolicyCenter archive domain graph. If the archive
domain graph never referred to that entity, it does not appear in any XML representation of the archived entity
instance. There is no issue.
However, suppose that PolicyCenter archived the entity instance already, before you removed it from the graph.
Then, at a later time, someone or PolicyCenter retrieves the instance. On retrieve, the archived instance causes a
duplicate key violation as the archive process attempts to insert the already archived instance into the database. To
handle this scenario, do the following:
1. Search for the duplicate instance in the database.
2. If found, call the [Link] method to create a new IArchivedEntity
that is a referenced entity. The referenced entity must exist in the [Link] can create a new referenced
entity of any type.

See also

• “The archive domain graph and reference data” on page 327

Working with shared entity data

PolicyCenter does not permit an entity instance to exist in more than one instance of the archive domain graph.
Existence in more that one instance of the archive domain graph violates the boundary of a unit of work. However,
there are cases in which you might want to share entity instance data across multiple policies and their individual
instances of the archive domain graph.
For example, you cannot have two separate policy period instances that own the same Note instance. If you want to
share an entity, such as a Note, across multiple policy periods, extend the PolicyPeriod entity type and add a
foreign key to the shared entity table.

The PolicyCenter archive domain graph 335

Guidewire PolicyCenter 9.0.9 Configuration Guide

If you share an entity type across multiple policy periods, there are several considerations of which you need to be
aware:
• You cannot create a foreign key from that shared entity to any entity in the archive domain graph.
• Any code that you construct around the shared entity must take archiving into account. For example, the code
must handle the possibility that not all related policy periods the code references necessarily exist in the main
application database.

About cycles in the archive domain graph

Two types of cycles can cause issues in the PolicyCenter data model and the archive domain graph:
• Circular foreign key references – Cycles that involve circular references between entities through the use of
foreign keys. The concern with this type of cycle is the safe ordering of foreign keys between entities upon
bundle commit.
• Ownership cycles – Cycles that involve the ownership of entities in the archive domain graph. The concern with
this type of cycle is the ownership, both overt and implicit, of one entity by another in the archive domain graph.

Circular foreign key references

A chain of foreign keys can form a cycle, also known as a circular reference. As an example of a circular reference,
entity A has a foreign key to entity B, and B has a foreign key to A. Circular references can occur with more
extensive chains of foreign keys, such as A refers to B, which refers to C, which refers to A.
The PolicyCenter data model and the archive domain graph do not permit circular references. Given a bundle that
contains a circular reference between entities A and B, PolicyCenter cannot determine which entity to commit first.
For example, entity A references new entity B, which has not been committed yet. Thus, committing A before B is
committed and present in the database causes a constraint violation.
Edge foreign keys provide the ability to avoid circular references in the data model. An edge foreign key from A to
B introduces a new, hidden associative entity with a foreign key to A and a foreign key to B. The edge foreign key
associates A and B without foreign keys directly between them. So, PolicyCenter can safely commit entity A first,
then new entity B, and finally the hidden edge foreign key entity.

Ownership cycles
A chain of ownership relationships can form a cycle known as an ownership cycle in the archive domain graph.
Ownership cycles are hard to detect because ownership can flow either to or from an entity that has a foreign key to
another entity.
By default, ownership flows in the same direction as foreign keys. For example, if B has a foreign key to A, B is
owned by A. Sometimes it is necessary to invert the flow of ownership, so a foreign key points from the owner to
the owned entity instead.
Guidewire strongly recommends against the use of edge foreign keys to resolve ownership cycles in the archive
domain graph. Introduce edge foreign keys into the archive domain graph only to resolve circular foreign key
references that require edge foreign keys for safe ordering during bundle commit.

Validation of the archive domain graph

The PolicyCenter server performs a series of tests on the archive domain graph during startup. For some of these
tests, failure prevents the server from starting. For other tests, failure allows the server to start with warnings. These
tests uncover potential problems with the archive domain graph. You can then use these warnings to fix issues with
the archive domain graph.
PolicyCenter writes any issues that it finds with the archive domain graph to the application and console log during
server startup. You can also view non-fatal warnings in the Warnings tab of the Server Tools Domain Graph Info screen.
336 chapter 22: The PolicyCenter archive domain graph
 Guidewire PolicyCenter 9.0.9 Configuration Guide

IMPORTANT Guidewire strongly recommends that you review the Warnings tab on the Domain Graph
Info screen for possible issues every time you change the data model.

Graph validation errors that prevent the server from starting

The following list describes validation tests that PolicyCenter performs on the archive domain graph during startup.

Test Description
Domain graph not parti‐ Verifies that all tables in the archive domain graph are reachable through the root entities.
tioned
Edge tables in domain graph Verifies that if edgeTable is set on an entity in the archive domain graph, it must have all of the
have required foreign keys following:
• An owned foreign key back to one of its parents
• An unowned foreign key to that same parent.
No cycles in domain graph Looks for circular references in the archive domain graph. Circular references in the graph cause
issues for the archive process.
The archive domain graph cannot have any cycle in its is owned by relationships. Thus, the fol‐
lowing example fails validation:
A is owned by B is owned by C is owned by A
You need to resolve any cycles by sorting out the ownership relationships.
The server reports the error and prints the graph problem in DOT format. See “Viewing the ar‐
chive domain graph” on page 343 for information on how to view the graph in a graphical for‐
mat.
Domain graph entities im‐ Ensures that all entities inside the archive domain graph implement the Extractable delegate.
plement Extractable PolicyCenter uses the following column on Extractable during the archive process:
• ArchivePartition
This test also verifies that no entities outside the archive domain graph implement the
Extractable delegate.

Overlap tables implement Verifies that all overlap tables implement the OverlapTable delegate. An overlap table contains
OverlapTable rows that can exist either in the archive domain graph or as part of reference data, but not both.
Overlap tables must implement the following delegates:
• Extractable
• OverlapTable
Entities in domain graph Verifies that all entities in the archive domain graph are keyable. This requirement enables you
keyable to reference the entity by ID.
Reference entities retirea‐ Verifies that all reference entities in the archive domain graph are retireable. See “The archive
ble domain graph and reference data” on page 327 as to why this is important.
Exceptions to links from Verifies that exceptions to links from outside the archive domain graph are actually from entities
outside the domain graph that are outside of the archive domain graph.
are outside the domain
graph

If any one of these tests fails, it prevent the server from starting. You must identify and correct these errors before it
is possible to start the PolicyCenter server.

Graph validation warnings that do not prevent the server from starting
The following list describes validation tests that PolicyCenter performs on the archive domain graph during startup.

The PolicyCenter archive domain graph 337

Guidewire PolicyCenter 9.0.9 Configuration Guide

Test Description
Archive domain graph enti‐ All foreign keys from entities in the archive domain graph must reference other entities in the
ties refer only to administra‐ domain graph only. Otherwise, foreign key violations can occur as PolicyCenter traverses the
tive data and domain enti‐ domain graph during the archiving processes.
ties
Nothing outside the archive There must not be foreign keys from entities outside the archive domain graph to entities inside
domain graph points to the the archive domain graph.
graph
Null links cannot make a PolicyCenter constructs the archive domain graph by looking at foreign keys. If enough links are
node unreachable null, the graph becomes partitioned and the archiving process is not able to correctly identify
the necessary entities for archiving. This test is a warning rather than one that prevents the
server from starting because it is possible to use business logic to prevent the issue.

None of these issues prevent the PolicyCenter server from starting. PolicyCenter permits the server to start even
upon failure of these tests because it is possible to prevent the erroneous situation through business logic. After the
server starts, you can view the warnings from these tests on the Warnings tab of the Server Tools Domain Graph Info
screen.

About archive domain graph errors

There are several types of archive domain graph errors that can occur:
• Graph validation issues that occur during server startup caused by incorrect entity type definitions
• Runtime issues that occur during a PolicyCenter archive operation caused by a failure to store or retrieve archive
data correctly
Graph validation issues are either fatal errors or non-fatal warnings:
• Validation graph errors do not permit the application to start. PolicyCenter logs the error but does not continue
the startup process.
• Validation graph warnings generate log entries but PolicyCenter continues to start.

Resolve archive graph errors

About this task

Guidewire recommends the following workflow to use in correcting fatal validation errors with the archive domain
graph that occur at server startup.

Procedure

1. Stop the application server.

2. Ensure that archive logging is set to logging level DEBUG in [Link]. If necessary, enable
archive logging or add this functionality if it is missing.
3. Disable archiving by setting configuration parameter ArchiveEnabled to false in file [Link].
4. Start the server in Development mode.
By starting the server in Development mode and disabling archiving, it is possible to start the application
server even if there are archive domain graph errors. PolicyCenter treats all issues with the archive domain
graph as non-fatal warnings. It writes these warnings to the application console log, or, if redirected, to the
server log.
5. Within PolicyCenter, navigate to Server Tools→Info Pages→Domain Graph Info.
338 chapter 22: The PolicyCenter archive domain graph
 Guidewire PolicyCenter 9.0.9 Configuration Guide

6. Click Download to generate a ZIP file that contains the following:

• An index file that contains links to the other download files.
• A log file named [Link] that details how PolicyCenter constructed the graph.
• A [Link] file that provides a representation of the archive domain graph in DOT format.
7. Using these tools, work through the reported warnings until PolicyCenter reports no more issues.

8. Enable archiving by setting configuration parameter ArchiveEnabled to true in file [Link].

Result

It is now possible to start the application server with a fully valid archive domain graph.

Resolve archive graph warnings

Before you begin

Before you attempt to correct any non-fatal issues with the archive domain graph, first ensure that you have
eliminated all fatal errors in the graph.

About this task

IMPORTANT Guidewire recommends that you review the Warnings tab on the Server Tools Domain
Graph Info screen for issues every time that you make changes to the PolicyCenter data model.

Procedure

1. After the server starts successfully with no archive domain errors, perform a test archive operation.
2. If any runtime errors occur, correct those issues before continuing.
3. After no more runtime errors occur, navigate to Server Tools→Info Pages→Domain Graph Info within
PolicyCenter.
4. Review and analyze any warnings shown in the Warnings tab.
5. Fix these issues as appropriate.

Result

The end result is that there are no more warnings remaining on the Warnings tab on the Domain Graph Info screen.

Resolving issues with custom archive entities

If you add a custom entity or entity extension to the archive domain graph, you must not violate any of the rules that
govern the ownership relationships in the graph. Otherwise, you can cause graph validation errors that can prevent
the PolicyCenter server from starting.
The following figure illustrates some of the potential problems that can occur in adding to the base configuration
graph. The figure shows problematic foreign key links in red.

The PolicyCenter archive domain graph 339

Guidewire PolicyCenter 9.0.9 Configuration Guide

Custom
entity /
extension
c

Archive
Root
a
Overlap or
potential
Overlap entity
aCustom
a entity /
Custom
entity / extension
b
extension

Ownership Cycle Error Archive

entity
a
Custom
entity /
extension

Archive Domain Graph

Boundary
d Custom
entity /
extension

The following list describes how to resolve the archive domain graph issues shown in the previous diagram.

Graph Issue Resolution More information

a Custom entity Ensure that all custom archive entities implement the Extractable • “Archive entities and the
does not imple‐ delegate. Also, ensure that any custom entity type you create that OverlapTable delegate” on
ment correct can be both inside and outside the archive domain graph imple‐ page 334
delegate ments the OverlapTable delegate. • “Archive entities and the
EffDated delegate” on
page 333
• “Archive entity incorrect in
graph” on page 342
• “Overlap data entity not
handled properly” on
page 343
b Foreign key Reverse the link ownership direction on one of the foreign keys that • “Understanding
ownership rela‐ cause the ownership cycle error. To change a link direction, use the PolicyCenter entity
tionships cause archivingOwner attribute on a foreign key. ownership” on page 327
cycle in graph
c Foreign key link Set the archivingOwner attribute on the foreign key to source. • “Archive entity incorrect in
from outside This prevents PolicyCenter from attempting to archive the linked graph” on page 342
graph to archive entity during an archive operation.
root in graph

340 chapter 22: The PolicyCenter archive domain graph

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Graph Issue Resolution More information

d Foreign key link Do the following: • “<tag>” on page 219
from outside • Set the archivingOwner attribute on the foreign key to none. • “Defining a cross‐domain
graph points to • Add a CrossDomainPlublicID tag to the foreign key that tag” on page 341
non‐root archive specifies an alternate column to hold the PublicID of the entity
entity in graph instance
The CrossDomainPlublicID tag forces the creation of an additional
column on the entity to store the publicID of the target archive
entity. PolicyCenter requires this ID in order to re‐establish the for‐
eign key link upon retrieval of the PolicyPeriod graph instance.

It is possible that there are other issues with the data model that you must resolve before you can successfully
archive your custom entity type. For example, suppose that an entity outside the graph has a foreign key that points
to an non-root entity inside the graph. This foreign key has its nullok attribute set to false. As such, it is not
possible to use a CrossDomainLink tag to resolve the issue. Instead, set the nullok attribute on the foreign key to
true to resolve the issue.

Defining a cross‐domain tag

Suppose, for example, that you create a custom TestAccount entity type that is outside the archive domain graph,
meaning that it does not implement the Extractable delegate. Entity TestAccount has a foreign key link to a
custom Charge entity, which is inside the graph. In this case, the foreign key links an entity type outside the graph to
a non-root entity type inside the graph.
This situation causes a validation error at server startup. To resolve the issue, do the following:
• Set attribute archivingOwner to none on the foreign key.
• Define a cross-domain tag on the foreign key.
• Add a PublicID column to store the public ID of the archive entity deleted during archiving.
The following entity metadata definition illustrates these concepts.
<?xml version="1.0"?>
<extension xmlns="[Link] entityName="TestAccount">
<column name="ArchivedChargePublicID" nullok="true" type="publicid"/>
<foreignkey archivingOwner="none" fkentity="Charge" name="Charge" nullok="true">
<tag name="CrossDomainPublicID" value="ArchivedChargePublicID"/>
</foreignkey>
</extension>

Defining a revisioned entity from a purge‐only domain graph tag

PolicyCenter generates a validation error at server startup if a purge-only domain graph attempts to include a
revisioned entity under the PolicyPeriod entity. This is because the PolicyPeriod domain graph, and any super-
sets of that graph, can include revisioned entities. To suppress this error, add the data model
ExcludeFromNonRevisionedOwner tag to the foreign key and set its value to true.
The following entity metadata definition illustrates these concepts.
<?xml version="1.0"?>
<extension xmlns="[Link] entityName="CostExt">
<foreignkey archivingOwner="target" fkentity="Transaction" name="Charge" nullok="true">
<tag name="ExcludeFromNonRevisionedOwner" value="true"/>
</foreignkey>
</extension>

In this example, notice that the code defines the following:

• A foreign key from CostExt to Transaction.
• An ExcludeFromNonRevisionedOwner tag with a value of true.
The PolicyCenter archive domain graph 341
Guidewire PolicyCenter 9.0.9 Configuration Guide

See also

• “<tag>” on page 219

• “Understanding PolicyCenter entity ownership” on page 327

About archive graph error messages

If PolicyCenter finds issues with the archive domain graph during server startup or while performing an archive
operation, it prints out error messages to the application console log. The error message indicates the nature of the
issue and provides a suggested solution to resolve the issue. Use these error messages to troubleshoot and correct the
issue.

Graph validation errors generated during server startup

If PolicyCenter finds issues with the archive domain graph during server startup, it prints out error messages to the
application console log. The error message indicates the nature of the issue and provides a suggested solution to
resolve the issue. The reported graph validation issues fall into the following categories:
• Archive entity incorrect in graph
• Non-archive entity in graph
• Overlap data entity not handled properly
Use these error messages to troubleshoot and correct the issue.

Archive entity incorrect in graph

The following error at server startup indicates that graph validation logic found one or more entities that are
incorrectly defined in the archive domain graph.
[Link]: Archiving graph validation failed. Error details:
The graph construction algorithm determined that the following are in the PolicyPeriod graph.
[...]

To correct this:
1. To include the entity in PolicyPeriod graph, please change them to implement Extractable.
OR
2. To avoid including it in PolicyPeriod graph, foreignkey must point out of the PolicyPeriod graph and configure
cross graph relationship. For details please see documentation.

The error message indicates that there are two ways to resolve this issue:
• Add ImplementsEntity="Extractable" to the metadata definition of any listed entity. This action includes that
entity type in the archive domain graph.
• Reverse the direction of the foreign key that points from an entity outside the graph to an entity inside the graph.
This action removes the entity from the archive domain graph.

Non‐archive entity in graph

The following error at server startup indicates that graph validation logic found one or more entities in the graph that
do not belong there.
[Link]: Archiving graph validation failed. Error details:
The graph construction algorithm determined that the following are not in the Claim graph.
To confirm this, please change them so that they do not implement Extractable.
[...]

To resolve this issue, remove ImplementsEntity="Extractable" from the metadata definitions of the entity types
that the error message lists.
342 chapter 22: The PolicyCenter archive domain graph
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Overlap data entity not handled properly

The following error at server startup indicates that graph validation logic found a link from various entity types to an
entity type that is possibly in the graph. Guidewire refers to entities for which an individual instance of the entity
possibly exists in the graph as overlap entities.
ERROR An exception was thrown while starting a component. Setting runlevel to SHUTDOWN
[Archiving graph validation failed. Error details:

The graph construction algorithm found the 'entity.CustomEntity1' in the graph is referencing entity
that is identified as an overlap table through the link: entity.CustomEntity1.CustomEntity2.
Please refer to documentation for resolving this graph validation error.

The graph construction algorithm found the 'entity.CustomEntity2' in the graph is referencing entity
that is identified as an overlap table through the link: [Link].
Please refer to documentation for resolving this graph validation error.]

This error occurs because the listed entities reference CustomOverlapTable which is an overlap table. Therefore,
you need to mark the listed entities types as overlap. To do so, add ImplementsEntity="OverlapTable" to the
following entity metadata definition:
• CustomEntity1
• CustomEntity2
In this scenario, CustomOverlapTable already implements the OverlapTable delegate.

Graph validation errors generated at run time

If PolicyCenter is unable to store an instance of the archive domain, it reports the issue in the application log. The
error message indicates the nature of the issue and provides a suggested solution to resolve the issue.
The following runtime error message is an example of the type of error generated if PolicyCenter is unable store an
archive entity instance in the archive store.

Failed to archive policy period : Exclude Reason Excluding from archive because some data
is shared with the reference graph

This error occurs because it is not possible to determine in advance of run time whether the PolicyPeriod instance
solely owns the linked entity instance. To resolve this issue, add a cross graph link on the reference entity type as
described in “Defining a cross-domain tag” on page 341.

About archiving and event messages

Any event message that non-Guidewire code generates within the archive bundle during the archive process causes
archiving to fail. Thus, do not automatically create messages in response to entity update events within the archive
bundle. Any archive-related Event Fired rule code that you create must explicitly take this restriction into account.
During the archive process and within the archive bundle, PolicyCenter updates any archive graph object with a
cross-domain relationship. If you enable event updates for one of these archive objects, the archive process fails.

IMPORTANT Do not create custom code that generates update events for any entity type that can
possibly be part of the archive bundle.

See also
• “Defining a cross-domain tag” on page 341
• Rules Guide

Viewing the archive domain graph

Guidewire uses the DOT plain text graph description language to represent the archive domain graph. The DOT
language describes complex graph relationships in a way that both humans and computers can use. Files that contain
The PolicyCenter archive domain graph 343
Guidewire PolicyCenter 9.0.9 Configuration Guide

DOT text generally end with a .dot extension. Specialized software can generate a visual presentation of the archive
domain graph from DOT text.
Guidewire provides access to the DOT text description of the archive domain graph through the Server Tools→Info
Pages→Domain Graph Info screen. You must have system administration privileges to access the Server Tools screens.

Generate the archive domain graph in PDF format

About this task
Use the following procedure to create a graphical representation of the archive domain graph in PDF format.

Procedure
1. Log into PolicyCenter by using an administrative account.
2. Navigate to Server Tools.
3. In the left-hand navigation pane, select Info Pages→Domain Graph Info.
4. Click Download and save the ZIP file to your local machine.
5. Extract the contents of the ZIP file into a permanent directory.
6. In a command prompt, run the following command.
[Link] -Tpdf -[Link] dot-file
In the command, the pdf-file parameter is the name to give to the PDF file. The dot-file parameter is the
name of the DOT-formatted file to use to generate the archive domain graph.

Generate the archive domain graph in PNG format

About this task
Use the following procedure to create a graphical representation of the archive domain graph in PNG format.

Procedure
1. Log into PolicyCenter by using an administrative account.
2. Navigate to Server Tools.
3. In the left-hand navigation pane, select Info Pages→Domain Graph Info.
4. Click Download and save the ZIP file to your local machine.
5. Extract the contents of the ZIP file into a permanent directory.
6. In a command prompt, run the following command.
[Link] -Tpng -[Link] dot-file
In the command, the png-file parameter is the name to give to the PNG file. The dot-file parameter is the
name of the DOT-formatted file to use to generate the archive domain graph.

Using archive logging

Guidewire recommends that you enable archive logging in your PolicyCenter installation during the development
and testing phases of archive implementation. If you enable archive logging, PolicyCenter adds information to the
application log regarding archiving issues that you can use in identifying, debugging, and correcting issues with the
archive process.
It is also possible to temporarily set the archive logging level in the PolicyCenter Server Tools Set Logging Level
screen that is available to system administrators. Restarting the application server resets any logging level set
through this screen.
344 chapter 22: The PolicyCenter archive domain graph
 Guidewire PolicyCenter 9.0.9 Configuration Guide

See also
• “Viewing the archive domain graph” on page 343
• System Administration Guide

The PolicyCenter archive domain graph 345

Guidewire PolicyCenter 9.0.9 Configuration Guide

346 chapter 22: The PolicyCenter archive domain graph

Part 5

User interface configuration

Guidewire PolicyCenter 9.0.9 Configuration Guide
chapter 23

Using the PCF editor

This topic covers how to work with PCF (Page Configuration Format) files in Guidewire Studio.

Page configuration (PCF) editor

Guidewire PolicyCenter uses page configuration format (PCF) files to render the PolicyCenter interface. You use
the PCF editor in Studio to manage existing PCF files and create new ones.
The PCF editor provides the following features:
• Intelligent Gosu coding
• Instant feedback whenever a PCF file changes
• Drag-and-drop composition of PCF pages and their graphical elements
• High-level view of PCF page groupings
• Ability to localize the display keys used in a PCF page
The PCF editor comprises three areas:
• In the center pane, the graphical page canvas, which provides drag-and-drop capabilities for composing and
managing the graphical and interactive elements on a page.
• In the right-hand pane, the following tabs:
◦ Toolbox – Contains a search box and a list of elements that you can insert into the page
◦ Structure – Shows the containment hierarchical of the elements on the page
• At the bottom, the Properties tabs at the bottom of the screen.

Page canvas overview

The center pane of the PCF editor provides the graphical page canvas. The page canvas provides drag-and-drop
capabilities for composing and managing the graphical and interactive elements on a page.

Using the PCF editor 349

Guidewire PolicyCenter 9.0.9 Configuration Guide

The page canvas displays the following:

• Elements that represent page content, such inputs and similar items, in simplified versions to illustrate how they
appear within the PolicyCenter user interface.
• Elements that function primarily as containers (data views, for example) as light gray boxes, with a header
indicating the element type and ID.
• Elements that define or expose additional Gosu symbols to their descendants as light gray boxes, with a list of
symbols at the top. If you move your mouse over a symbol, Studio shows a tooltip with the name, type, and
initial value of the symbol.
◦ If the symbol represents a Require, the tooltip indicates this as well.
◦ If you click a symbol name, Studio selects the containing element, and then opens the appropriate properties
tab for editing whatever is providing the symbol. Finally, if necessary, Studio selects the symbol in the
Properties tab.
• Elements that are conditionally visible with a dotted border.
• Elements that iterate over a set of data and produce their contents once for each element in the data by a single
copy of the contents. It follows this with an ellipsis to indicate iteration.
• RowIterator widgets with inferred header and footer cells in the position in which they appear within
PolicyCenter.

Creating a new PCF file

Guidewire Studio displays PCF files in an organizational hierarchy. To create a new PCF file, you need to first
decide its location in the PCF hierarchy. If the hierarchy does not contain a PCF folder at the organization level that
suits your needs, first create one before you create your new PCF File.
PCF folder names are case-insensitive and must be unique within the PDF hierarchy. You cannot create a PCF folder
name that differs from an existing PCF folder name by case only.

Create a new PCF folder

Procedure

1. In the Project window, navigate to configuration→config→Page Configuration, and expand it.

2. Select a node one level above the level in which you need to create the new PCF folder (node).
3. Right-click and click New→PCF folder.
4. Enter the folder name in the New Folder dialog.

Create a new PCF file

Procedure

1. In the Project window, navigate to configuration→config→Page Configuration, and expand it.

2. Select the node in which you want to create the new PCF file.
3. Right-click and click New→PCF file.
4. Enter the file name in the New PCF File dialog.
5. Select the PCF file type to create.
6. Enter a mode. (Any element that dynamically includes this widget must specify the same mode.) This field is
only active with specific file types. See “Working with shared or included files” on page 351 for more
information.
350 chapter 23: Using the PCF editor
 Guidewire PolicyCenter 9.0.9 Configuration Guide

See also
• “PCF file type icons” on page 351

PCF file type icons

The following table lists the file type icons.

Icon File type Icon File type Icon File type Icon File type
Page Input Set Navigation Tree Toolbar Buttons

Popup List View Panel Row Wizard

Card View List‐Detail View Panel Set Wizard Steps

Chart View Location Group Popup Wizard Wizard Step Subgroup

Detail View Menu Actions Set Row Set Worksheet

Entry Point Menu Items Screen

Exit Point Menu Links Set Tab Bar

Info Bar Navigation Forward Template Page

Working with shared or included files

A shared element or shared section is any PCF element that has the following characteristics:
• The PCF element is not a top-level element, meaning it is not a Page, Popup, or Wizard, for example.
• The PCF element exists in its own file.
Guidewire calls this element a shared section because it is possible to share the element (or file) between multiple
top-level elements. PolicyCenter automatically propagates any changes that you make to the shared section to all
other PCF elements that include the shared section.
You cannot select elements within the included file and the included elements do not display a highlight or a tooltip
as you move the mouse cursor over it. For all intents and purposes, included elements are flat content of the element
in the current file that includes them.
However, Guidewire Studio™ for PolicyCenter displays a PCF element that includes the contents of another file or
element with a blue overlay. This overlay is cumulative. Studio displays included elements that are several levels
deep in a darker shade of blue. If you double-click an area with a blue overlay, Studio opens the included file in a
new editor view.
Right-clicking anywhere on the canvas and toggling Show included sections or toggling Show included sections from the
Page Config menu disables the representation of the included files. Studio displays the text of the reference expression
instead.

Understanding PCF modes

Certain included files or elements are modal. The basic idea is that you can define several different file versions, or
modes, of a single shared section. Thus, any PCF page that includes the section can decide at run-time which file
version to use, possibly based on the value of some variable.
If it is possible for the PCF file to have multiple modal versions, then you see Shared section mode above the shared
area (which Studio shades or high-lights in blue). If you click the mode, Studio shows a drop-down of all the
possible modes. You can use the drop-down to select a different modal file. If you do so, then Studio updates the
screen to reflect your change.
Using the PCF editor 351
Guidewire PolicyCenter 9.0.9 Configuration Guide

For example, in ClaimCenter (the other Guidewire applications provide similar examples), PCF file
ExposureDetailScreen contains a shared area. The mode drop-down contains a number of possible modal files that
you can embed into the ExposureDetailsScreen. In this screen, the drop-down shows the following:
• Baggage
• Bodilyinjurydamage
• Content
• EmployerLiability
• ...
To determine if a PCF file has multiple modal versions, you can also look at the PCF file names in Studio. If you see
multiple file names that include a common name followed by a dot then a different name, then this is a modal file.
For example, in ClaimCenter, you see the following under the exposures node in the Resources tree:
• [Link]
• [Link]
• [Link]
• [Link]
• ...
Each individual file is a modal version of the ExposureDetailDV PCF file, which you can embed into another file,
in this case, the ExposureDetailsScreen.

Setting a PCF mode

It is only possible to set a mode on a PCF file as you create that PCF file. Selecting a file type that allows modes
enables the Mode text field in the New PCF File dialog. Selecting a file type that does not allow modes disables the
Mode text field.
You are able to set a mode with the following file types only:

• Accelerated Menu Actions • List View • Row Set

• Card View • Menu Action Set • Screen
• Chart View • Menu Items • Toolbar Buttons
• Detail View • Menu Links Set • Wizard Steps
• Info Bar • Modal Cell • Wizard Step Subgroup
• Input Set • Panel Set

Typically, you use a Gosu expression to define the mode for an included section. You can make this expression
either a hard-coded string literal or you can use the expression to evaluate a variable or a method call. For example,
PCF file AddressPanelSet (in PolicyCenter) uses [Link] as the mode expression
variable.
A hard-coded string guarantees that the included section always uses the same mode regardless of the data on the
page. If using a hard-coded string expression, Studio shows only that mode and does not show a drop-down above
the blue area.

352 chapter 23: Using the PCF editor

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Create new modal PCF files

About this task

It is not possible to change or modify the mode of a base configuration PCF file. You can, however, use an existing
modal file as a template to create a new (different) modal version of that file. To do this:
• Select the template file and duplicate it.
• Select the newly created file and change the mode of that file.
For example, suppose that you wanted to add a new modal version of the ExposureDetailDV PCF file, say
[Link]. To do this:

Procedure

1. Select the file that you intend to use as the template. For this example, select [Link].
2. Right-click the template file and select Duplicate.
3. Enter the name of the new modal file in the Duplicate PCF File dialog and click OK. For this example, enter -
[Link]
Studio inserts the new file into the directory structure, colors the file name blue, and opens a view of the file
automatically.
4. Modify the new modal file as required.

Include files with multiple modes

About this task

PolicyCenter provides the ability to use a single include file with multiple modes. In this way, you can re-use a
single modal file in multiple PCF files. For example, in the base configuration, ClaimCenter defines PCF file
[Link] with multiple modes:
• PersonVendor
• Attorney
• Doctor
To see this, open [Link] and select the entire file. (You see a solid
blue line surrounding the file.) Examine the mode attribute in the Properties pane at the bottom of the screen. You see
the following:
PersonVendor|Attorney|Doctor

Procedure

1. Select the include file.

2. Right-click and select Change mode....
3. Enter the individual modes separated by a pipe symbol (|) in the Change Mode dialog.

Page Config menu

If you open the PCF editor, Studio displays a Page Config menu on the main Studio menu bar. This menu contains a
number of useful items.

Using the PCF editor 353

Guidewire PolicyCenter 9.0.9 Configuration Guide

Menu com‐ Use to... See

mand
Change element Substitute a different element for the selected element. The dialog con‐ “Changing the type of an ele‐
type... tains a list of element types that you can substitute for the selected ele‐ ment” on page 358
ment within the constraints of the PCF schema.
Edit comment... Attach a comment to any element on the canvas. “Adding a comment to an ele‐
ment” on page 359
Delete comment Remove a comment from an element. “Adding a comment to an ele‐
ment” on page 359
Disable element Disable an element by commenting out the widget. This prevents “Adding a comment to an ele‐
PolicyCenter from rendering the widget in the interface. ment” on page 359
Enable element Enable a previously disabled element. This action removes the surrounding “Adding a comment to an ele‐
comment tags from the element. ment” on page 359
Link widgets Link widgets on a parent page that spans multiple child PCF files. You use “Linking widgets” on page 361
this particularly for explicit iterator references.
Show included Toggle the visibility of child files embedded in a parent PCF file. If you disa‐ “Page canvas overview” on
sections ble the representation of the included files, Studio displays the text of the page 349
reference expression instead.
Find by ID Find an element by its ID. The dialog contains a filter text field and a list of “Find a PCF element on the can‐
all elements on the canvas that have their id attribute set: vas” on page 360
Show element View the XML code for an element. Studio displays the XML code in a pop‐ “View the source of a PCF ele‐
source up window. ment” on page 360

Toolbox tab
The Toolbox tab contains a search box and a list of widgets, divided into categories and subcategories.
• Clicking on a category name expands or collapses that category.
• Clicking on a subcategory name expands or collapses that subcategory as well.
Within the toolbox, Studio persists the state of each category (expanded or collapsed) across all PCF editor views. It
also persists the state of each category to each new Studio session.
Studio only displays widget categories containing widgets that are valid and available for use in the current PCF file.
If you hover the mouse cursor over a widget name in the list, then Studio displays a description of that widget in a
tooltip.

Search box
You use the search box to filter the full set of widgets. Typing in the search box temporarily expands all widget
categories and highlights:
• Any widgets whose category name matches the typed text
• Any widgets whose name matches the typed text
• Any widgets whose actual name in the XML matches the typed text
• Any widgets whose description contains the typed text
Clicking the X icon by the search box clears text from the box and stops filtering the widget list. Keyboard shortcut
Alt+/ gives focus to the search box.

354 chapter 23: Using the PCF editor

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Structure tab
The Structure tab shows the hierarchical structure of the PCF file as a tree. Each node in the tree represents a PCF
element. Any children of the node are children of that element:
• If you click an element that represents a concrete element on the canvas, Studio selects that element on the
canvas.
• If you click on an element that does not represent a concrete element on the canvas, then Studio first selects the
containing element on the canvas. It then selects the appropriate properties tab with which to edit the clicked
element. Finally, if necessary, Studio selects the clicked element in the properties tab (at the bottom of the
screen).

Properties tab
The Properties tab (at the bottom of the screen) displays all attributes of the selected element. Studio divides the
attribute workspace into Basic and Advanced sections. You can expand or collapse a workspace section by clicking
the title of that section. Studio maintains the expanded or collapsed state of a section across all element selections
and persists this state to new Studio sessions.
The workspace displays each attribute as a row in a table, with the attribute name in the left column and the value in
the right column. Studio grays out the name if you have not set a value for that attribute (if the attribute value is
nothing or is only a default value). Studio also grays out the attribute value if it is a default value. If the PCF schema
requires an attribute, Studio displays the attribute name in bold font, with an asterisk, and with a different
background color.
If you hover the mouse cursor over an attribute name, Studio displays a tooltip with the documentation for that
attribute.
For each attribute:
• If the attribute takes a non-Gosu string value, Studio displays the value in a text field.
• If the attribute takes a non-Gosu Boolean value, Studio displays the value in a drop-down menu with two
choices, true and false.
• If the attribute takes an enumeration value, Studio displays the value in a drop-down menu with a choice for each
value of the enumeration, plus a <none selected> option.
• If the attribute takes a Gosu value, Studio displays the value in a single-line Gosu editor. Gosu editor commands
that operate on multiple lines have no effect in a single-line editor. (For example, the SmartFix Add uses statement
command does not work in a single-line editor.) Studio displays the single-line editor with a red background if it
contains any errors, and a yellow background if it contains warnings but no errors.
• If the attribute requires a return type, Studio colors the value background red under the following circumstances:
◦ If the entered expression does not evaluate to that type
◦ If the entered statement does not return a value of that type
• If the attribute requires a Boolean return value, Studio displays a drop-down menu on the right side with two
options, true and false. If you select one of these options, Studio sets the text of the editor to the appropriate
value.
If the value editor for an attribute has focus, Studio displays the attribute name in a different background color and
adds an X icon. If you click the X icon, Studio sets the value of the attribute to its default.
If you press Enter on the keyboard while editing a property, Studio moves the focus to the next property in the list.

Child lists
Some of the Properties tabs contain a child list. A child list contains a list of the selected element's child elements of a
certain type, and a properties list for the selected child element. You can perform a number of operations on a child
list, using the following tool icons.
Using the PCF editor 355
Guidewire PolicyCenter 9.0.9 Configuration Guide

If the child list represents a single child type, Studio adds a new child element. Studio selects the newly added child auto‐
matically. If the child list represents multiple child types, Studio opens a drop‐down menu of available child types. If you
select a child type from the drop‐down, Studio adds a child of that type and selects it automatically.
If you select a child and click the delete icon, Studio removes the selected child. Studio disables this action if there is no
selected child.
If you select a child and click the up icon, Studio moves the selected child above the previous child. Studio disables the up
icon if you do not first select a child, or if there are no other children above your selected child.
If you click the down icon, Studio moves the selected child below the next child. Studio disables the down icon if you do
not first select a child, or if there are not other children below your selected child.

Additional properties tabs

Depending on the children of a selected element, Studio displays additional subtabs.

Addition‐ Description
al tabs
Axes If an element can have DomainAxis and RangeAxis children, Studio displays the Axes properties tab. This tab con‐
tains a child list of the DomainAxis and RangeAxis children for the selected element. If you select a RangeAxis,
Studio displays a child list for its Interval children.
Code If an element can have a Code child, Studio displays the Code properties tab. This tab contains a Gosu editor for
editing the contents of the Code child. The Code editor has access to all the top‐level symbols in the PCF file (for
example, any required variables). However, you cannot incorporate any uses statements, nor does the Gosu editor
provide the SmartFix to add uses statements automatically.
Data Series If an element can have DataSeries and DualAxisDataSeries children, Studio displays the Data Series properties
tab. This tab contains a child list of the DataSeries and DualAxisDataSeries children for the selected element.
Entry If an element can have LocationEntryPoint children, Studio displays the Entry Points properties tab. This tab con‐
Points tains a child list of the LocationEntryPoint children for the selected element.
Exposes If a parent PCF page contains an iterator that controls a ListView element defined in a separate PCF file, then
Studio displays the Exposes tab on the child PCF file. You use this tab to set the iterator to use for the ListView
element.
Filter Op- If an element can have ToolbarFilterOption and ToolbarFilterOptionGroup children, Studio displays the Filter
tions Options properties tab. This tab contains a child list of the ToolbarFilterOption and ToolbarFilterOptionGroup
children for the selected element.
Next Condi- If an element can have NextCondition children, Studio displays the Next Conditions properties tab. This tab con‐
tions tains a child list of the NextCondition children for the selected element.
Reflection If an element can have a Reflect child, Studio displays a Reflection properties tab. The Reflection tab has a check
box for Enable client reflection, which indicates whether that element has a Reflect child. If you enable client reflec‐
tion, the Reflection tab also contains a properties list for the Reflect element and a child list for its
ReflectCondition children.

Required If an elements can have Require children, Studio displays the Required Variables properties tab. This tab contains a
Variables child list of the Require children for the selected element.
Scope If an element can have Scope children, Studio displays the Scope properties tab. This tab contains a child list of the
Scope children for the selected element.

Sorting If an element can have IteratorSort children, Studio displays the Sorting properties tab. This tab contains a child
list of the IteratorSort elements for the selected element.
Toolbar If an element can have ToolbarFlag children, Studio displays the Toolbar Flags properties tab. This tab contains a
Flags child list of the ToolbarFlag children of the selected element.
Variables If an element can have Variable children, Studio displays the Variables properties tab. This tab contains a child list
of the Variable children for the selected element.

356 chapter 23: Using the PCF editor

 Guidewire PolicyCenter 9.0.9 Configuration Guide

PCF elements
Studio displays a down arrow icon to the right of a non-menu element that contains menu-item children.
• If you click the down arrow, Studio opens a pop-up containing the children of the element.
• If you click anywhere on the canvas outside the pop-up, Studio dismisses the pop-up.
Studio displays elements that contain a comment with a comment icon in the upper right-hand corner of the widget.
It shows disabled elements (commented-out elements) in a faded-out manner
Studio displays elements that cause a verification error with either a red overlay or a thick red border. It displays
elements that cause a verification warning (but not an error) with either a yellow overlay or a thick yellow border.
If you move your mouse over an element:
• Studio highlights the element with a light border.
• If the element has a comment, Studio displays the text of the comment in a tooltip.
• If the element does not have a comment, but does have its desc attribute set, Studio displays the value of the
desc attribute in a tooltip.
• If the element has any errors or warnings, Studio displays these in a tooltip along with any comment or desc text.

PCF elements and the Properties tab

If you click an element on the canvas, Studio selects that element and highlights it in a thick border. This action also
opens the Properties tab in the workspace area at the bottom of the screen, if it is not already visible.
• If the element has an error or warning that is attributable to one of its attributes, Studio highlights that attribute in
the Properties tab.
• If the element contains child elements not shown on the canvas, Studio displays additional Properties tabs in the
workspace area.
• If the element has no errors or warnings, but a non-visible child element does, Studio brings the appropriate
Properties tab for that child element to the front. If necessary, Studio selects that child element in the Properties tab.
• If there are additional Properties tabs that do not apply to the selected element, Studio closes them.
• If the tab that was at the front before you selected the element is still visible, it remains at the front. Otherwise,
Studio brings the Properties tab to the front.
Clicking in the canvas area outside the area representing the file being edited, or clicking Escape, deselects the
currently selected element and closes all open Properties tabs.

Working with elements

Page configuration format files contain three basic types of elements:
• Physical elements (buttons and inputs, and similar items) that have a visual presence in a live application.
• Behavioral elements (iterator sorting and client reflection, and similar items) that exist only to specify behavior
of other elements.
• Structural elements (panels, screens, and similar items) that do not represent a single element in the Web
interface, but instead indicate some grouping or other structure.
After you create a new page, you can select page elements from the Toolbox tab for inclusion in the page.
PolicyCenter does not permit you to insert elements that are invalid for that page or grouping. After adding an
element to a page, you can change its type if needed, rather than removing it and starting again.
Guidewire strongly recommends that you label the widgets that you create with unique IDs. Otherwise, you may
find it difficult to identify that widget later.

Using the PCF editor 357

Guidewire PolicyCenter 9.0.9 Configuration Guide

You can perform the following actions with PCF elements:

• “Adding an element to the canvas” on page 358
• “Changing the type of an element” on page 358
• “Adding a comment to an element” on page 359
• “Find a PCF element on the canvas” on page 360
• “View the source of a PCF element” on page 360
• “Duplicate a PCF element” on page 360
• “Delete a PCF element” on page 361
• “Copy a PCF element” on page 361
• “Cut a PCF element” on page 361
• “Paste a PCF element” on page 361

Adding an element to the canvas

To add a widget, click its name in the Toolbox and hold the mouse cursor down. As you begin to drag the widget,
Studio changes the mouse cursor so that it includes the icon for that widget. Studio places a green line on the canvas
at every location on the canvas that it is possible to place the widget. Studio highlights the green line that is nearest
on the canvas to the cursor. Studio also overlays in green the element containing the highlighted green line.
• If the widget is a menu item of some sort, Studio overlays in green those widgets that can accept the item as a
menu item.
• If a green widget is closer to the cursor than any of the green lines, Studio overlays it with a brighter green.
If you click Esc, Studio cancels the action, returns the cursor to normal, and makes the green lines and overlays
disappear.
If you click again (or end the dragging operation), Studio adds the new widget at the location of the highlighted
green line. (Or, Studio adds the widget as a child of the highlighted widget.) Studio sets all attributes of the new
widget to their default value.
After Studio adds the new widget to the canvas, the cursor returns to normal and the green lines and overlays
disappear. Studio selects this new widget automatically.

Moving an element on the canvas

If you click on a widget on the canvas, Studio picks up (selects) the widget. As you drag the widget, Studio moves
the widget from its current location to the new location. This makes no changes to the attributes or descendants of
the widget.
You can also Ctrl+drag a widget on the canvas. This time, however, as you place the widget, Studio creates a
duplicate of the original widget (including all attributes and descendants) and places the cloned widget at the target
location.

Changing the type of an element

If you right-click an element and select Change element type, Studio opens the Change Element Type dialog. You can also
select the element and then select Change element type from the Page Config commands on the menu bar.
This dialog contains a list of element types that you can substitute for the selected element within the constraints of
the PCF schema. If you then select a new element type and click OK, Studio replaces the selected element with an
element of the new type. It also transfers all attribute values and descendants that are valid on the new type.
However:
• If is possible to select a new element type that does not allow one or more attributes supported by the selected
(existing) element. In this case, Studio displays a message that indicates which attributes it plans to discard.
• If it is possible to select an element type that can not contain one or more children of the selected widget. In this
case, Studio displays a message that indicates which children it plans to discard.
358 chapter 23: Using the PCF editor
 Guidewire PolicyCenter 9.0.9 Configuration Guide

If there are no valid element types to which you can change the selected element, Studio disables the Change element
type command.

Adding a comment to an element

It is possible to attach a comment to any element on the canvas. Studio indicates an element has a comment by
placing a yellow note icon in the comment’s upper right corner. If you hover the mouse over that element, then
Studio displays the comment in a tooltip.

Add a comment to a PCF element

About this task
If you do one of the following, Studio opens a modal dialog with a text field for the element's comment:
• Right-click an element and select Edit comment
• Select the element and then select Edit comment from the Page Config commands on the menu bar

Result
If the element already has a comment, Studio pre-populates the text field with the contents of the comment.

Deleting a comment from a PCF element

About this task
If you do one of the following, Studio deletes the comment for that element:
• Right-click an element and select Delete comment
• Select the element and then select Delete comment from the Page Config commands on the menu bar

Result
However, if the element has no comment, Studio disables the Delete comment command.

Disable (comment out) a PCF element

About this task
Commenting out a widget effectively prevents PolicyCenter from rendering the widget in the interface. If you do
any of the following, Studio disables the element by surrounding it and its descendants with comment tags in the
XML:
• Right-click an enabled element and select Disable element.
• Select the element and type CTRL+/.
• Select Disable element from the Page Config commands on the menu bar.

Result
If the element or any of its descendants have comments, Studio informs you that it is deleting the comments and
prompts you to confirm the disable operation.
It is also possible to set the visible attribute on the widget to false to prevent PolicyCenter from rendering the
widget. In this case, however, the XML file retains the widget. It still exists server-side at run time, although
PolicyCenter does not render it, and the widget does not post data. Thus, commenting out the widget can possibly
give you a marginal performance increase. Also, disabling the widget prevents it from causing errors, for example, if
the signature of some function called by one of its attributes changes.
As it is the use of XML comment tags that disable the widget, you cannot then add a comment to the widget to
describe why you disabled it. If you would like to add an explanation associated with the widget (recommended),
Using the PCF editor 359
Guidewire PolicyCenter 9.0.9 Configuration Guide

then use the widget desc attribute. Studio displays this text in the tooltip if you hover the mouse of over the widget
in the PCF editor. (This does not produce a yellow note icon, however.)

Enable a PCF element

About this task
If you do one of the following, Studio enables the element by removing the surrounding comment tags:
• Right-click a disabled element and select Enable element.
• Select the element and click Ctrl+/.
• Select Enable element from the Page Config commands on the menu bar.

Find a PCF element on the canvas

About this task
If you do one of the following, Studio opens a semi-modal dialog. This dialog contains a filter text field and a list of
all elements on the canvas that have their id attribute set:
• Right-click in the canvas area and select Find by ID.
• Click Ctrl+F12.
• Select Find by ID from the Page Config commands on the menu bar.

Result
As you type in the text field, Studio filters the visible elements to those whose ID matches the typed text. Selecting
an element from the list selects it on the canvas.

View the source of a PCF element

About this task
To view the XML representation of an element, select the widget, then do one of the following:
• Right-click, and then select Show element source.
• Select Show element source from the Page Confg menu.

Result
Studio opens a small text window and displays the XML code associated with the selected element.

Duplicate a PCF element

About this task
If you do one of the following, Studio creates a duplicate of the element immediately after the current element:
• Right-click an element and select Duplicate.
• Select a widget and click Ctrl+D.
• Select Duplicate from the Edit commands on the menu bar.
This includes all attribute values and descendants. Studio selects the duplicate widget automatically.

Result
If the PCF schema permits the target widget to occur one time only within the parent widget (for example, a Screen),
then attempting to duplicate the widget has no effect.
360 chapter 23: Using the PCF editor
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Delete a PCF element

About this task
You cannot delete the root element of a PCF.
If you do one of the following, Studio deletes the element from the canvas:
• Right-click an element, and then click Delete.
• Select a widget, and then press Delete.
• Click Edit→Delete.
• On the toolbar, click Delete.

Copy a PCF element

About this task
If you do one of the following, Studio copies an XML representation of that widget and its descendants to the
clipboard:
• Right-click an element, and then click Copy.
• Select a widget, and then type Ctrl+C.
• Click Edit→Copy.
• On the toolbar, click Copy.

Cut a PCF element

About this task
You cannot cut (remove) the root element of a PCF file.
If you do one of the following, Studio copies an XML representation of that widget and its descendants to the
clipboard and deletes the widget:
• Right-click an element, and then click Cut.
• Select a widget, and then type Ctrl+X.
• Click Edit→Cut.
• On the toolbar, click Cut.

Paste a PCF element

About this task
If the content of the clipboard is valid XML representing a PCF widget, you can paste the widget by doing one of
the following:
• Right-click the canvas and select Paste.
• Click Ctrl+V.
• Select Paste from the Edit commands on the menu bar.
• Select the Paste icon from the menu bar.

Linking widgets
A common feature in PCF pages is a ListView element controlled by a RowEditor iterator. PolicyCenter renders the
list view as a table with multiple rows, with the iterator populating the data in the table rows. Frequently, the user
clicks a button to activate certain functionality within the list view, for example, adding or deleting rows in the table.
Using the PCF editor 361
Guidewire PolicyCenter 9.0.9 Configuration Guide

In many cases, the PCF file is a parent page that contains embedded child PCF files that contain individual
ListView elements. If this is the case, then you need to link the button on the parent PCF file with the iterator used
to populate the child PCF files. To do so, you use the Link widgets command on the Page Config menu. This menu item
provides a visual tool to link widgets on a parent page that spans multiple child PCF files. You use this particularly
for explicit iterator references.

See also
• “Link two widgets” on page 362

Link two widgets

Procedure
1. Select a widget, for example a CheckedValuesToolbarButton widget.
2. Do one of the following:
• Select Link widgets from the Page Config menu.
• Right-click and select Link widgets from the context menu.
• Press Ctrl+L.
Studio changes the look of the mouse cursor to cross-hairs. Studio also changes the color of the target widget
to light green.
3. Click the widget to which you want to link. Studio links the two widgets.

362 chapter 23: Using the PCF editor

chapter 24

Introduction to page configuration

This topic provides an introduction to the concepts and files involved in configuring the web pages of the
PolicyCenter user interface.

Page configuration files

The pages in the PolicyCenter user interface are defined by XML files stored within each installed instance of the
application. To configure your PolicyCenter interface, use Guidewire Studio to open and edit these files. The page
configuration files are named with the file extension .pcf, and are therefore often called PCF files.
PCF files are stored in PolicyCenter/modules/configuration/config/web/pcf. Guidewire does not support
editing PCF files outside of Guidewire Studio.

Page configuration elements

This section discusses the following topics:
• “What is a PCF element?” on page 363
• “Types of PCF elements” on page 364
• “Identifying PCF elements in the user interface” on page 366

What is a PCF element?

Guidewire defines each PCF file as a set of XML elements defined within the root <PCF> tag. Guidewire calls these
XML elements PCF elements. These PCF elements define everything that you see in the PolicyCenter interface, as
well as many things that you cannot see. For example, PCF elements include:
• Editors
• List views
• Detail views
• Buttons
• Popups
• Other PolicyCenter interface elements
• Non-visible objects that support the PolicyCenter interface elements, such as Gosu code that performs
background actions after you click a button.
For a reference of all PCF elements and their attributes, see the PCF Format Reference in PolicyCenter/modules/
[Link] in your installation.
Introduction to page configuration 363
Guidewire PolicyCenter 9.0.9 Configuration Guide

Every page in PolicyCenter uses multiple PCF elements. You define these elements separately, but PolicyCenter
renders then together during page construction. For example, consider the tab bar available on most PolicyCenter
pages:

Using Ctrl+Shift+W, you can discover that these elements are defined in the PCF file [Link]. In Guidewire
Studio, you can open [Link] in the PCF Editor. Clicking on the arrow next to the Search tab in this file causes
the search menu items to appear:

Types of PCF elements

There are many kinds of PCF elements that you can define. These elements follow a hierarchical, container-based
user interface model. To design them most effectively, you need understand the relationships between them
thoroughly. Most PCF elements are of one of the following types:
• “Locations” on page 364
• “Widgets” on page 365

Locations
A location is a place to which you can navigate in the PolicyCenter interface. Locations are used primarily to
provide a hierarchical organization of the interface elements, and to assist with navigation.
Locations include pages, wizards, worksheets, forwards, and location groups. Locations themselves do not define
any visual content, but they can contain screens that do, as illustrated in the following diagram:

364 chapter 24: Introduction to page configuration

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Locations

Location
Page Wizard Worksheet Popup Forward
Group

Screen Screen Screen Screen

Screen
Screen

You can define the following types of locations:

Location Description
Page A location with exactly one screen. The majority of locations defined in PolicyCenter are pages.
Wizard A location with one or more screens, in which only one screen is active at a time. The contents of a wizard are
usually not defined in PCF files, but are configured either in other configuration files or are defined internally by
PolicyCenter.
Work‐ A page that can be shown in the workspace, the bottom pane of the web interface. The main advantage of work‐
sheet sheets is that they can be viewed at the same time as regular pages. This makes them appropriate for certain kinds
of detail pages such as creating a new note.
Popup A page that appears on top of another page, and that returns a value to its invoking page. Popups allow users to
perform an interim action without leaving the context of the original task. For example, a page that requires the
user to specify a contact person could provide a popup to search for the contact. After the popup closes,
PolicyCenter returns the contact to the invoking page.
Forward A location with zero screens. Since it has no screens, it has no visual content. A Forward must immediately forward
the user to some other location. Forwards are useful as placeholders and for indirect navigation. For example, you
might want to link to the generic Desktop location. This would then forward the user directly to the specific
Desktop page (for example, Desktop Activities) most appropriate for that kind of user.

Location A collection of locations. Typically a location group is used to provide the structure and navigation for a group of
group related pages. PolicyCenter can automatically display the appropriate menus and other interface elements that al‐
low users to navigate among these pages.

Widgets
A widget is an element that PolicyCenter can render into HTML. PolicyCenter then displays the HTML visually.
Buttons, menus, text boxes, and data fields are all examples of widgets. There are also a few widgets that you cannot
see directly, but that otherwise affect the layout of widgets that you can see.
For most locations, a screen is the top-most widget. It represents a single HTML page of visual content within the
main work area of the PolicyCenter interface. Thus, a screen typically contains other widgets. You can reuse a single
screen in more than one location.
The following diagram shows a possible widget hierarchy:

Introduction to page configuration 365

Guidewire PolicyCenter 9.0.9 Configuration Guide

Screen

Widget
Widget
Widget

Widget

Widget Widget

Identifying PCF elements in the user interface

To modify a particular page in PolicyCenter, you must first understand how it is constructed. This includes
understanding the PCF elements which compose the page, what files define the PCF elements, and how they are
pulled together.
For example, consider the Claim Summary page within ClaimCenter. If you look at this page in the ClaimCenter
interface, you cannot immediately tell how it is constructed. If you want to modify this page, some of the important
things to know about it are illustrated in the following annotated diagram:

This diagram shows:

• The location is a page named ClaimSummary.
• The page contains a screen named ClaimSummaryScreen.
• The screen contains a “panel set” widget named ClaimSummaryHeadlinePanelSet.
• The screen contains a “detail view” widget named ClaimSummaryDV.
• The screen contains a “list view” widget named ServiceRequestV.
366 chapter 24: Introduction to page configuration
 Guidewire PolicyCenter 9.0.9 Configuration Guide

PolicyCenter provides the following tools that allows you to view the structure of any page and to see which PCF
elements it uses:
• “Location info” on page 367
• “Widget inspector” on page 367
To enable these tools, the EnableInternalDebugTools configuration parameter must be set to true.

Location info
The Location Info window shows you information about the construction of the page you are viewing. It includes the
location name, screen names, and high-level widgets defined in the page, and the names of the PCF files in which
they are all defined. Typically, the widgets that appear in this window are the ones that are defined in separate files,
such as screens, detail views, list views, and so on. The Location Info is most useful if you are making changes to a
page as it tells you which files you need to modify.
To view the location information for a particular page, go to that page in the PolicyCenter interface, and then press
Alt+Shift+I. This opens the Location Info window for the active page. For example, the following is the Location Info
window for the ClaimCenter Claim Summary page:

With this information, you can see the following:

• The location is a page named ClaimSummary, defined in the [Link] file on line 10.
• The page contains a screen named ClaimSummaryScreen, defined in the [Link] file on line 26.
• The screen contains one detail view widget, and multiple list view widgets, each defined in a different file.

Widget inspector
The Widget Inspector window shows detailed information about the widgets that appear on a page. This includes the
widget name, ID, label text, and the file in which it is defined. The widget information is most useful during
debugging a problem with a page. For example, suppose that a defined widget does not appear on a page. You could
then look at the widget information to determine whether the widget exists (but perhaps is not visible) or does not
exist at all.
To view the widget inspector for a particular page, go to that page in the PolicyCenter interface, and then press Alt
+Shift+W. This opens the Widget Inspector window for the active page. For example, the following graphic shows the
Widget Inspector window for the ClaimCenter Claim Summary page:
Introduction to page configuration 367
Guidewire PolicyCenter 9.0.9 Configuration Guide

The first part of the window shows the variables and other data objects defined in the page. After that, all of the
widgets on the page are listed in hierarchical order.

Getting started configuring pages

This section provides a brief introduction to the most useful and common tasks that you might need to perform
during page configuration. It covers the following topics:
• “Finding an existing element to edit” on page 368
• “Creating a new standalone PCF element” on page 369

Finding an existing element to edit

The first step in modifying the PolicyCenter interface is finding the PCF element that you want to edit, whether this
is a page, a screen, or a specific widget. There are several ways to do this:
• “Browse the PCF hierarchy” on page 368
• “Find an element by ID” on page 369

Browse the PCF hierarchy

About this task
You can browse the PCF elements under the Page Configuration folder in Guidewire Studio:

368 chapter 24: Introduction to page configuration

 Guidewire PolicyCenter 9.0.9 Configuration Guide

These elements are arranged in a folder hierarchy that is related to how they appear in the PolicyCenter interface.
For example, the admin, claim, and dashboard folders generally contain PCF elements that are related to the
Administration, Claim, and Dashboard pages within ClaimCenter.

Find an element by ID
About this task
If you know the ID of the element, such as by using the location info or widget inspector windows, you can find it
within Studio. Press Ctrl+N to open the Find By Name dialog box, and then start typing the ID of the element. As you
type, PolicyCenter displays a list of possible elements that match the ID you are entering.

After you see the one you want, click on it and PolicyCenter opens the file in the PCF Editor.

Creating a new standalone PCF element

About this task
You can create a new PCF standalone element in Guidewire Studio. Each standalone element is stored in its own
file.

Procedure
1. Browse the Page Configuration folder in the Project window, and locate the folder under which you want to
create your new element.
2. Right-click on that folder, and then click New→PCF File. (You can also click New→PCF Folder to create a new
folder). The PCF File dialog appears.

Introduction to page configuration 369

Guidewire PolicyCenter 9.0.9 Configuration Guide

3. In the File name text box, type the name of the element.
4. Click the type of element to create. If an element has a naming convention, it is shown next to the File name
text box.
For example, the name of a detail view must end with DV.
5. Click OK, and the new element is created and opened for editing in Studio.

Modifying style and theme elements

Changing or adding images
About this task

Images used in the application reside in PolicyCenter/modules/configuration/webresources/themes/

theme-9/resources/images. Images can be switched by replacing an existing image file with one of the same
name. We recommend ensuring that replaced images are the same size as the original to avoid sizing issues.
To add a new image, place it in this folder or one of its children, then reference it as appropriate.
To update your application with these new images, run gwb updateTheme from the command line.

Overriding CSS
About this task

To override specific CSS classes, make edits to PolicyCenter/modules/configuration/webresources/themes/

theme-9/resources/theme_ext.css. Changes in this file override other CSS properties in your application.

Changing theme colors

About this task

Guidewire applications are themed using SASS technology. To make significant changes to the style of your
application, see “Advanced theming” on page 371. However, you can change the theme colors of your application
by following these steps.
For more information about SASS, visit [Link]

Procedure

1. Open PolicyCenter/ThemeApp/packages/theme-9/sass/var/[Link] in a text editor. This is

where all of the PolicyCenter colors are defined.
2. You can modify the definition to be any other hexadecimal color, or to be relative to another.
For example, $base-light-color takes the $base-color and lightens it appropriately across the application.
3. After making changes, run gwb updateTheme from the command line. This incorporates your changes into the
CSS generated by the SASS Theme.

370 chapter 24: Introduction to page configuration

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Advanced theming
PolicyCenter uses SASS to define a robust set of styling rules for ensuring a consistent look across the application.
To make more detailed styling and theme changes, we recommend referencing the SASS documentation for details.
There are, however, a few things specific to the Guidewire implementation:
• You cannot create a new theme and apply it to the application. All changes to the styling need to be made in the
current theme definition, under PolicyCenter/ThemeApp/packages/theme-9/sass/.
• SASS condenses its CSS definition for performance purposes. To see the expanded, debuggable CSS in your web
development tool, run the command gwb webResources and refresh your browser.
◦ gwb updateTheme condenses your CSS for production use.

Introduction to page configuration 371

Guidewire PolicyCenter 9.0.9 Configuration Guide

372 chapter 24: Introduction to page configuration

chapter 25

Data panels

This topic provides an introduction to the concepts and files involved in configuring the web pages of the
PolicyCenter user interface.

Panel overview
A panel is a widget that contains the visual layout of the data to display in a screen. There are several types of
panels:
• “Detail view panel” on page 373 – A series of widgets laid out in one or more columns.
• “List view panel” on page 377 – A list of array objects, or any other data that can be laid out in tabular form.
You can place as many panels in a screen as you like, dividing the screen into one or more areas.

Detail view panel

A detail view is a panel that is composed of a series of data fields laid out in one or more columns. It can contain
information about a single data object, or it can include data from multiple related objects. Any input widget can
appear within a detail view.
The following is an example of a detail view as it appears both as it is being viewed and as it is being edited:

Data panels 373

Guidewire PolicyCenter 9.0.9 Configuration Guide

You can do the following:

• “Define a detail view” on page 374
• “Add columns to a detail view” on page 375
• “Format a detail view” on page 376

Define a detail view

About this task
Define a detail view by dragging the Detail View element onto the PCF canvas. You can place the element
anywhere a green line appears. For example:

The id attribute is required; it identifies the panel so that it can be referenced by other PCF elements. The ID must
be unique, and it must end with the text string DV.
A detail view must contain at least one vertical column, defined by the Input Column element. The column contains
the input widgets to display, as in the following example:

374 chapter 25: Data panels

 Guidewire PolicyCenter 9.0.9 Configuration Guide

This definition produces the following detail view:

Add columns to a detail view

About this task
A detail view must contain at least one vertical column, but it can contain more. The following illustration shows
detail views with one and two columns:

Column 1 Column 1 Column 2

A column is defined by the Input Column element. This element must appear at least once, to define the first
column. To add additional columns, include the Input Column element multiple times. The following example
defines a two-column detail view:

PolicyCenter automatically places a vertical divider between the columns.

The full definition of the previous example produces the following two-column detail view:

Data panels 375

Guidewire PolicyCenter 9.0.9 Configuration Guide

Format a detail view

About this task

You can add the following formatting options to a detail view:

• “Label” on page 376
• “Input divider” on page 377
These are illustrated in the following diagram:

Label
A label is bold text that acts as a heading for a section of a detail view. All input widgets that appear after a label are
slightly indented to indicate their relationship to the label. The indenting continues until another label appears or the
detail view ends. Thus, you cannot manually end a label indenting level at any point that you choose.
Include a label with the Label element:

376 chapter 25: Data panels

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Set the label attribute to the display key to use for the label.

Input divider
An input divider draws a horizontal line across a detail view column. You can place an input divider wherever you
like between other elements.
Include an input divider with the Input Divider element:

List view panel

A list view is a panel that displays rows of data in a two-dimensional table. The data can be an array of entities,
results of a database query, reference table rows, or any other data that can be represented in tabular form.
In most cases, data is viewed in list views and then edited in detail views. However, there are some places—for
example, in the ClaimCenter financial transaction entry screens—in which it makes more sense to edit a list of items
in place. For this purpose, you can make a list view editable so that you can add or remove rows, or modify cells of
data.
The following is an example of a list view:

Data panels 377

Guidewire PolicyCenter 9.0.9 Configuration Guide

Define a list view

About this task
Define a list view by dragging the List View element onto the PCF canvas. You can place the element anywhere a
green line appears. For example:

The id attribute is required; it identifies the panel so that it can be referenced by other PCF elements. The ID must
be unique, and it must end with the text string LV.
A list view contains one or more rows, each containing one or more cells. The structure of the simplest one-row list
view is illustrated below:
List view

Row

Cell 1

Cell 2
...

Cell n

End row

End list view

To define the rows and cells of the list view, use Row and one of the *Cell elements such as TextCell or DateCell.
Each occurrence of Row starts a new row, and each *Cell creates a new column within the row. The following
example creates a one-row, three-column list view:

378 chapter 25: Data panels

 Guidewire PolicyCenter 9.0.9 Configuration Guide

The id attribute of a *Cell element is required. It must be unique within the list view, but does not need to be
unique across all of PolicyCenter. The value attribute contains the Gosu expression that appears within the cell. In
the previous example, the value of each cell is set to 10, 20, and 30, respectively. You can set other attributes of a
*Cell to control formatting, sorting, and many other options.
This simple example demonstrates the basic structure of a list view. However, you will almost never use a list view
with a fixed number of rows. The more useful list views iterate over a data set and dynamically create as many rows
as necessary. This is illustrated in “Iterate a list view over a data set” on page 380.
A list view requires a toolbar so that there is a place to put the paging controls, as well as any buttons or other
controls that are necessary.
You can define a list view in the following ways:
• “Standalone” on page 379
• “Inline” on page 379

Standalone
You can define a list view in a standalone file, and then include it in other screens where needed. This approach is
the most flexible, as it allows you to define a list view once and then reuse it multiple times.
For example, suppose you define a standalone list view called MyLV.
You can then include this list view in a screen with the PanelRef element:

Set the def attribute of the Panel Ref to the name of the list view; in this example, that is MyLV.

Inline
If a list view is simple and used only once, you can define it inline as part of a screen. This approach often makes it
easier to create and understand a screen definition, as all of its component elements can be defined all in one place.
However, an inline list view appears only where it is defined, and cannot be reused in other screens.
The following example defines an inline list view in a screen:

Data panels 379

Guidewire PolicyCenter 9.0.9 Configuration Guide

Iterate a list view over a data set

About this task
Most list views iterate over a data set and dynamically create a new row in the list for each record in the data set.
The most common usage is showing an array of objects that belong to another object. For example, listing all
activities that belong to a claim, or all users that belong to a group.
To construct a list view that iterates over a data set, use a row iterator. The structure of this kind of list view is
illustrated in the following diagram:
List view

Row iterator Data source

Row

Cell 1

Cell 2
...

Cell n

End row

End iterator

End list view

The row iterator specifies the data source for the list. For each record in the data source, the iterator repeats the row
(and other elements) defined within it.
Define a row iterator with the Row Iterator PCF element. For example:

The value attribute of the Row Iterator specifies the data source, such as an array of entities or the results of a
query. For more information on setting a data source, see “Choose the data source for a list view” on page 381.
The elementName attribute is the variable name that represents the “current” row in the list. You can use this
variable anywhere within the row iterator as the root object that refers to the current row.
380 chapter 25: Data panels
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Consider the following example, in which a Claim variable represents a claim:

To iterate over the array of activities in the claim, this list view creates a row iterator whose value attribute is
[Link]. For each activity in this array, the iterator creates a row with multiple cells. The elementName
attribute of the iterator is Activity; it represents the current row, and is used to get the values of the Activity
object’s fields in each cell.
This example produces the following list view:

Choose the data source for a list view

List views use different kinds of data sources to support different application requirements. The simplest data source
is an array field on an entity type. An array field generally has a limited set of items that do not require a database
query to retrieve. For example, the list of exposures for a claim is relatively short and is retrieved from the database
as part of the overall claim, without a separate database query.
Other data sources for a list view involve a query and are more complex. This is especially true for search results or
lists of items (activities, claims, and so on) on the Desktop. For example, a query as the source for a list view could
be “all activities assigned to the current user that are due today or earlier.”
You specify the data source for a list view with the value property of the row iterator for the list view.

Source Description
Array An array field on an entity type is identified in the Data Dictionary as an array key. For example, the Officials field
field on a Claim is an array key. Thus, you can define a list view based on [Link]. In this case, each official
listed on a specified claim is shown on a new row in the list view. You can also define your own custom Gosu meth‐
ods that return array data for use in a list view. The method must return either a Gosu array or a Java list
([Link]).
Query A query processor field on an entity type is identified in the Data Dictionary as a derived property returning
process‐ [Link]. It represents an internally‐defined query, and usually provides a more con‐
or field venient and efficient way to retrieve data. For example, the [Link] field performs a database query
to retrieve only the notes on a claim that the current user has permission to view. This is more efficient than using
the [Link] array field, which loads both viewable and non‐viewable notes and filtering the non‐viewable
ones out later.

Data panels 381

Guidewire PolicyCenter 9.0.9 Configuration Guide

Source Description
Finder A finder method on an entity type is similar to a query processor field, except that it is not defined as field in the
method Data Dictionary. Instead, a finder method is an internally‐defined Java class that performs an efficient query on in‐
stances of an entity type. For example, the Activities page of the Desktop uses a list view based on the finder method
[Link].

Query A query builder result uses the result of an SQL query. For more information, see the Gosu Reference Guide.
builder
result

List views behave differently depending on whether the source is an array or one of the query-backed sources.

Behavior Array‐backed list view Query‐backed list view

Loading data The full set of data is loaded upon initially render‐ Only the data on the first page shown is fetched and load‐
ing the list view. ed.
Paging The full set of data is reloaded each time you The query is re‐run. Data is loaded only for the page that is
move to a different page within the list view. viewable.
Sorting The full set of data is reloaded each time the list The query is re‐run and sorted in the database. Therefore,
view is sorted. you can sort only on columns that exist in the physical data‐
base, and not (for example) on virtual columns. Data is
loaded only for the page that is viewable.
Filtering The full set of data is reloaded each time the list The query is re‐run and filtered in the database. Therefore,
view is filtered. you can filter only on columns that exist in the physical da‐
tabase, and not (for example) on virtual columns. Data is
loaded only for the page that is viewable.
Editing Paging, sorting, and filtering work as noted above, Paging, sorting, and filtering are disabled.
as long as any modified (but uncommitted) data is
valid. Sorting and filtering can result in modified
rows being sorted to a different page or filtered
out of the visible list.
Best suited Short lists Long lists
for
Additional Do not use a query‐backed editable list view in a wizard.
notes

382 chapter 25: Data panels

chapter 26

Location groups

This topic provides an introduction to location groups.

Location group overview

A location group is collection of locations. It is typically used to provide the structure and navigation for a group of
related pages. PolicyCenter can automatically display the appropriate menus and other interface elements that allow
users to navigate among these pages.

Define a location group

About this task
Define a location group with the Location Group PCF element. In the configuration→config→Page Configuration tree,
click the desired folder and then right-click New→PCF file. In the New PCF File dialog, click LocationGroup, and give the
location group a name. For example:

Location groups 383

Guidewire PolicyCenter 9.0.9 Configuration Guide

A location group must contain one or more references to another location. Any time that you navigate to the location
group, PolicyCenter uses the locations defined within it to determine what page and surrounding navigation to
display. The following example is the location group defined for a claim in ClaimCenter:

Location groups as navigation

Depending on how a location group is used, PolicyCenter displays menus and other screen elements for navigating
to the locations within that group. Any time that you navigate to a location group, PolicyCenter displays the first
location within that group.
You can use location groups as navigation elements in the following ways:
• “Location groups as tab menus” on page 384
• “Location groups as menu links” on page 385
• “Location groups as sidebar navigation” on page 386

Location groups as tab menus

A location group can be used to define the menu items that appear in a tab. As an example, consider the Desktop tab
in ClaimCenter with the menu items as shown in the following diagram:

384 chapter 26: Location groups

 Guidewire PolicyCenter 9.0.9 Configuration Guide

This tab is defined in the element named TabBar (under the util folder):

This tab is defined with its action attribute set to [Link](). This specifies that the action to take if you click
the Desktop tab is to go to the Desktop location.
This location is a location group:

Inside this location group, there are multiple Location Ref elements defined, each one specifying a location. In this
example, the locations referenced in the group correspond to the items in the Desktop menu. If the action for a tab is a
location group containing more than one location, ClaimCenter adds each location in that location group to the menu
in the tab.

Location groups as menu links

A location group can be used to define the menu links that appear on the sidebar of the PolicyCenter interface. As an
example, consider the Search page in ClaimCenter, shown in the following diagram:

Location groups 385

Guidewire PolicyCenter 9.0.9 Configuration Guide

The following is the definition of the Search location group:

Inside this location group, there are multiple Location Ref elements defined, each one specifying a location.
As ClaimCenter displays this location, it notices that it is a location group, and automatically creates menu links for
each location within the group. Notice in this example that the Location Ref elements referenced in this group
correspond to the items in the menu links.

Location groups as sidebar navigation

A location group can be used to define navigation items that appear in the sidebar. As an example, consider the
claim Loss Details page in the following diagram:

This is a location group defined in ClaimLossDetailsGroup as follows:

386 chapter 26: Location groups

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Inside this location group, there are multiple LocationRef elements defined, each one specifying a location.
As ClaimCenter displays this location, it notices that it is a location group, and automatically creates sidebar items
for each location within the group. Notice in this example that the LocationRef elements referenced in this group
correspond to the items in the sidebar.

Location groups 387

Guidewire PolicyCenter 9.0.9 Configuration Guide

388 chapter 26: Location groups

chapter 27

Navigation

This topic provides an introduction to the concepts and files involved in configuring the web pages of the
PolicyCenter user interface.

Navigation overview
Navigation is the process of moving from one place in a Guidewire application interface to another. If you click on a
link, you “navigate” to the location the link takes you.
A Guidewire application interface provides many elements that you use to navigate within the application. The
following diagram identifies the most common navigation elements:
Tab bar

Menu actions Options menu

Tab menu items
Unsaved work list

Menu links

Sidebar

You can define the following types of navigation elements:

Tab bar A set of tabs that run across the top of the application.
Tabs Items in the tab bar that navigate to particular locations or show a drop‐down menu.
Tab menu items A set of links shown in the drop‐down menu of a tab.
Menu links Links in the sidebar that take you to other locations, typically within the context of the current tab.
Menu actions Links under the Actions menu in the sidebar that perform actions that are typically related to what you can do
on the current tab.

Navigation 389
Guidewire PolicyCenter 9.0.9 Configuration Guide

Tab bars
A tab bar contains a set of tabs that run across the top of the application window, as in the following example:
Tabs

You can do the following:

• “Configure the default tab bar” on page 390
• “Specify which tab bar to display” on page 390
• “Define a tab bar” on page 390
You can also configure the individual tabs on a tab bar. For more information, see “Tabs” on page 391.

Configure the default tab bar

About this task
PolicyCenter defines a default tab bar named TabBar. If no other tab bar is specified, then the default tab bar is used.
However, if necessary, you can explicitly specify a different tab bar to show instead.
We recommend that you rely entirely on the default tab bar within the primary PolicyCenter application. You can
customize the default tab bar to have it serve almost all of your needs. Consider defining a new tab bar only for
special pages, such as entry points that have limited access to the rest of the application.

Specify which tab bar to display

About this task
You rarely need to explicitly specify a tab bar to display. Instead, you almost always rely on the default tab bar
TabBar. However, to override the default and specify a different tab bar, set the tabBar attribute on the location
group. For example, you could set it to MyTabBar().
As you navigate to a location, PolicyCenter scans up the navigation hierarchy and checks whether a tab bar is
explicitly set on a location group. If so, then that tab bar is used. If no tab bars are set, then the default tab bar is
used.
For user interface clarity and consistency, we recommend that you set the tab bar only on the top-most location
group in the hierarchy. However, a tab bar set on a child location group overrides the setting of its parent.

Define a tab bar

About this task
Define a tab bar with the TabBar PCF element. For example:

390 chapter 27: Navigation

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Tabs
Tabs are items in a tab bar that you can click on. A tab can be a single link that takes you directly to another
location, it can be a drop-down menu, or it can be both. The following shows an example of tabs on a tab bar in
ClaimCenter:

You can do the following:

• “Define a tab” on page 391
• “Define a drop-down menu on a tab” on page 391

Define a tab
About this task
Define a tab by placing a Tab PCF element with a Tab Bar. For example:

The action attribute of a tab defines where clicking the tab takes you. For example, to go to the Desktop location,
set the action attribute to [Link]().

Define a drop‐down menu on a tab

About this task
A tab can contain a drop-down menu. As a tab has a menu, it shows the menu icon . Clicking this icon shows the
menu items, while clicking the other parts of the tab performs the tab action.
Menu items on a tab are defined in the following ways:
• implicitly, using a location group
• explicitly, defined by <MenuItem> elements

Define a tab menu from a location group

About this task
As the action attribute of a tab is a location group, PolicyCenter automatically creates menu items on the tab that
correspond to the locations in that location group. For each location in the location group:
• a menu item is created in the tab
• the label attribute of the Location Ref is used as the label of the menu item
• the permissions of the location determine whether the menu item is available to the current user
For example, the action of the ClaimCenter Search tab goes to the Search location group. Its action attribute is
defined as: [Link]().
Navigation 391
Guidewire PolicyCenter 9.0.9 Configuration Guide

This Search location group contains the Location Ref elements that appear as menu items on the tab:

This creates the menu items that appear on the Search tab:

Define a tab menu explicitly

About this task
You can create a menu on a tab by explicitly defining Menu Item elements within the Tab definition. This method of
creating a menu supersedes the automatic menu items derived from the location group. If you build a menu
explicitly, PolicyCenter does not automatically add any other items to it.

392 chapter 27: Navigation

chapter 28

Configuring search functionality

PolicyCenter provides a Search tab that you can use to search for specific entities. You can configure the Search tab to
add new search criteria or modify or remove existing criteria. Configuring search functionality involves modifying
the PolicyCenter functionality in Gosu classes and modifying the PolicyCenter interface through page configuration
files.

WARNING Guidewire strongly recommends that you consider all the implications before
configuring the Search tab. Adding new search criteria can result in significant performance
impacts, particularly in large databases. Guidewire recommends that you thoroughly test any
search customizations for performance issues before you move them into a production database.

Overview of search
PolicyCenter provides two types of search:
• Database search – Searches the relational database for policies, accounts, producers, activities, and contacts by
using Structured Query Language (SQL). You access these searches from the Search tab.
PolicyCenter also includes database search from screens besides those accessed through the Search tab. For
example, you can do a database search for policy form patterns, policy locations, regions, and other entities and
objects.
• Free-text search – Searches an external, full-text database for policies, by using the APIs of an external full-text
search engine. PolicyCenter includes free-text search for policies and submissions. You access free-text search
from the Search Policies→Basic screen.
Database search is fully enabled by default. Users can search policies, accounts, producers, activities, and contacts
with database search. Users can choose to include archived policies with each database search request. The user
interface for database search is known as advanced search.
Free-text search is available as an option that you must enable and configure. Free-text search is available only for
searching for policies and submissions. Free-text search results never include archived policies. The user interface
for free-text search is known as basic search.

Configuring search functionality 393

Guidewire PolicyCenter 9.0.9 Configuration Guide

IMPORTANT The PolicyCenter base configuration does not allow free-text search of entity types other
than policies and submissions. Guidewire will support customers in their development of additional
search types.

PolicyCenter Search Architecture

Relational database

Advanced search
(database search)

PolicyCenter application

Policy updates

Real‐time index Batch‐load index

documents documents
Policy Search

Basic search
(free‐text search)

Full‐text database

Free-text search involves two sets of data flows in which a user selects and reviews policies as well as updates them.
In the policy review data flows, the user searches, selects, and reviews policies with the PolicyCenter user interface.
Searching policies entails sending queries to and receiving policy results from a full-text search engine. Selecting
and reviewing policies entails requesting and receiving policies from a relational database:

394 chapter 28: Configuring search functionality

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Policy Review ‐ PolicyCenter Free‐Text Search Data Flows

2. PolicyCenter
1. User searches PolicyCenter Full‐text search
application sends query
policies with basic or application engine
to full‐text search engine.
free‐text search.
3. Full‐text search engine
returns query results to
PolicyCenter application.
4. User selects and
reviews policy from
query results. 5. Relational database
sends selected policy to
PolicyCenter application.
Relational
database

In the policy update data flow, the user updates policies with the PolicyCenter user interface. Updating policies
entails sending updates to a relational database as well as sending an index document with the updates to a full-text
search engine:

Policy Update ‐ PolicyCenter Free‐Text Search Data Flow

Relational
database
PolicyCenter 2. PolicyCenter application
application sends update to relational
database.
1. User updates policy.

3. PolicyCenter application
sends index document
with updates to full‐text
search engine.
Full‐text search
engine

If you enable free-text search, the Search Policies screen displays two tabs:
• Basic – Displays fields on which to search policies and submissions. The Basic screen uses free-text search to
return policies and submissions that match criteria users enter.
• Advanced – Displays fields on which to search policies and jobs. The Advanced screen uses database search to
return policies and jobs that match criteria users enter.
If you enable free-text search, the Search Policies screen displays the Basic and Advanced search screens. Otherwise,
the Search Policies screen displays the Advanced screen only.

Configuring search functionality 395

Guidewire PolicyCenter 9.0.9 Configuration Guide

Reasons that users choose the Basic or Advanced screens include:

• Users want to search policies with commonly used criteria and receive results quickly, which the Basic screen
provides.
• Users want to search policies with highly targeted criteria, which requires the Advanced screen.
• Users want to search policies with partial names, phonetic names, or sounds-like names, which the Basic screen
provides.
• Users want to search archived policies, which requires the Advanced screen.
• Users want to search for specific job types, such as all policy changes bound within a certain period.
An administrator hides the Basic search screen while the free-text batch load command runs, but users still can
search policies with the Advanced screen.

PolicyCenter Search Architecture (During Batch Load Process)

Relational database
Advanced search
(database search)

PolicyCenter application

Policy updates

Real‐time index Batch‐load index

documents documents
Policy Search

Basic search
(free‐text search)
(unavailable
during batch load
process)
Full‐text database

See also
• “Database search configuration” on page 396
• “Free-text search configuration” on page 406

Database search configuration

This section describes how to configure database search.

396 chapter 28: Configuring search functionality

 Guidewire PolicyCenter 9.0.9 Configuration Guide

WARNING Guidewire strongly recommends that you consider all the implications before
customizing the Search tab. Adding new search criteria can result in significant performance
impacts, particularly in large databases. Guidewire recommends that you thoroughly test any
search customizations for performance issues before you move them into a production database.

PolicyCenter database search functionality

To search for a specific entity, select the Search tab from the PolicyCenter interface. In the base configuration, you
can search for the following:
• Policies
• Accounts
• Producer Codes
• Activities
• Contacts
During a search, PolicyCenter uses only those fields on the form for which you enter data. For example, if you
search for a Policy and enter a Last Name but not a Policy Number, PolicyCenter omits Policy Number from the search.
In the base configuration, PolicyCenter also provides database search from screens other than those accessed
through the Search tab. For example, you can do a database search for policy form patterns, policy locations, regions,
and other entities and objects.
For each search, PolicyCenter uses one of the following types of objects to encapsulate search criteria.

Object type Description

Gosu class In the base configuration, PolicyCenter implements most search criteria with Gosu classes. An example of a Go‐
su class as a search criteria object is the AccountSearchCriteria class, which is defined in
[Link].

Virtual entity PolicyCenter implements some search criteria objects as virtual entities. A virtual entity has no underlying table
in the PolicyCenter database and do not persist beyond the session in which you use it. An example of a non‐
persistent entity as a search criteria object is DocumentSearchCriteria, defined in [Link].

Every field on the Search screen maps to an attribute on the relevant search criteria entity. For example, in the Activity
search screen:
• Assigned To maps to AssignedUser in the ActivitySearchDV PCF file.
• AssignedUser maps to [Link] in the same file.
• SearchAssignedUser maps to [Link], the Gosu class definition that contains
the business logic to search on the assigned user field.

Configuring PolicyCenter database search

You can configure database search functionality in multiple locations in PolicyCenter code. The file or files in which
you configure search depend upon whether the search criteria object is defined as a virtual entity or a Gosu class.

Gosu Classes as Search Criteria

If the search criteria object is a Gosu class, you modify the search by modifying the Gosu search criteria class. For
example, AccountSearchCriteria is a Gosu class. To modify the search behavior, you modify the
[Link] class.

Virtual Entities as Search Criteria

If the search criteria object is a virtual entity, you can modify the criteria by extending the virtual entity, modifying
[Link], or modifying the search criteria enhancement class. For example, DocumentSearchCriteria
Configuring search functionality 397
Guidewire PolicyCenter 9.0.9 Configuration Guide

is a virtual entity. To add new criteria columns, you can add them to the [Link] entity
extension file. In [Link], you can add new criteria to the actual search. You can also modify
[Link] to change how the search is called.

PolicyCenter entity and object searches

The following table lists the entity and object types for which you can search, and the specific file or files in the base
configuration. The Location in User Interface column describes one location in which you can search for this object.
You can access certain objects from more than one location.

Location in user interface Search for entity or object Configure search criteria object in...
Search Policies screen from the Search PolicyPeriodSummary [Link]
tab
Search Accounts screen from the AccountSummary [Link]
Search tab

Search Activities from the Search tab Activity [Link]

Account File Claims screen from Claims ClaimSet with array to Claim ob‐ [Link]
menu link in the Sidebar of an ac‐ jects in a particular date range.
count
Account File History screen from Histo- History [Link]
ry menu link in the Sidebar

Industry Code search popup from the IndustryCode [Link]

Search Accounts screen

Search Contacts screen from the Contact ContactSearchCriteria virtual entity

Search tab [Link]

Groups screen from the Administra- Group GroupSearchCriteria virtual entity

tion→Users & Security menu item [Link]

Organizations screen from the Admin- Organization OrganizationSearchCriteria virtual entity

istration→Users & Security menu item [Link]

Notes screen from Notes menu link in Note NoteSearchCriteria virtual entity
the Sidebar of a policy [Link]

Search Producer Codes screen from ProducerCode [Link]

the Search tab
Users screen from the Administra- User UserSearchCriteria virtual entity
tion→Users & Security menu item [Link]

Policy Form Patterns from the Adminis- FormPattern [Link]

tration→Business Settings menu item

Messages screen from the Administra- Message [Link]

tion→Monitoring menu item

Tools→Documents screen of a policy Document DocumentSearchCriteria virtual entity

Building Class Code in the Details pop‐ BOPClassCode [Link]

up in the Buildings screen of a Busi‐
nessowners job wizard
Property Class Code in the Building CPClassCode [Link]
popup of a Commercial Property
job wizard
Class Code in the Exposures screen of GLClassCode [Link]
a General Liability job wizard

398 chapter 28: Configuring search functionality

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Location in user interface Search for entity or object Configure search criteria object in...

Covered Employees→Class Code in the WCClassCode [Link]

State Info screen of a Workers’ Com‐
pensation job wizard
Account File History screen of an ac‐ History [Link]
count
Industry Code Search popup from the IndustryCode [Link]
Search→Accounts menu item

PolicyLocationSearchAPI web PolicyLocation [Link]

service
The popup that appears when you PolicyLocation [Link]
click Search for Nearby Locations in the
Reinsurance screen of a Business‐
owners policy file.
Risk Description search popup that RiskClass [Link]
appears when you add Spoilage to
the Location Information→Additional
Coverages screen in the Business‐
owners job wizard.
Account File Related Accounts screen AccountSummary [Link]
accessed from the Related Accounts
link in the sidebar of an account
Location Information popup from the TaxLocation [Link]
Location screen in a Workers’ Com‐
pensation job wizard
Territory Code Search popup that ap‐ DBTerritory [Link]
pears when you set the Businessown-
ers Line Territory Code in the Location
Information screen of a Businessown‐
ers job wizard.
Search Accounts popup from the Alt BCBillingAccountSearchResult BillingAccountSearchCriteria
Billing Account picker in the Payments Gosu class
screen of a job wizard
For forms, coverage patterns, and ClausePattern [Link]
policy holds
Additional Coverages→Add Coverages
button on the Vehicle Information pop‐
up in a Business Auto policy job wiz‐
ard.
Search for Regions popup that ap‐ Zone [Link]
pears when you click Add Hold Region
on the Hold Regions tab of a New Poli-
cy Hold.

Issue Type Search popup that appears UWIssueType [Link]

when you click to add a Type in a
new authority profile. Access au‐
thority profiles from Admin→Users &
Security→Authority Profiles

Rate Books screen from Administra- RateBook [Link]

tion→Rating menu This is a feature of Guidewire Rating Management.

Configuring search functionality 399

Guidewire PolicyCenter 9.0.9 Configuration Guide

Location in user interface Search for entity or object Configure search criteria object in...
Rate Routines screen from Administra- CalcRoutineDefinition [Link]
tion→Rating menu This is a feature of Guidewire Rating Management.
Rate Table Definitions screen from Ad- RateTableDefinition [Link]
ministration→Rating menu This is a feature of Guidewire Rating Management.
Search Programs from Reinsurance RIProgram [Link]
menu This is a feature of Guidewire Reinsurance Manage‐
ment.
Search Agreements from Reinsur- LocationRisk [Link]
ance→Agreements menu This is a feature of Guidewire Reinsurance Manage‐
ment.
Search Agreements with Arrangement RIAgreement [Link]
set to Treaty. Accessed through Rein- This is a feature of Guidewire Reinsurance Manage‐
surance→Agreements. ment.
Search Agreements with Arrangement RIAgreement [Link]
set to Facultative. Accessed through This is a feature of Guidewire Reinsurance Manage‐
Reinsurance→Agreements. ment.

Search criteria abstract classes

The EntitySearchCriteria abstract class provides a standard way of searching for entities, such as the
BOPClassCode entity. In general, the search criteria classes for entities extend this class. For the BOPClassCode
entity, the BOPClassCodeSearchCriteria class extends the EntitySearchCriteria class.
The SearchCriteria abstract class is a less restrictive superclass that provides a standard way of searching for
objects. In general, search criteria for objects other than entities extend this class.
If the Gosu search criteria class does not exist, you can create it.

See also
• Guidewire Contact Management Guide

Configuring database search criteria in XML

You use the [Link] file to define a mapping between the key data entities and certain non-persistent
entities used for search criteria. The entries in the file have the following basic structure.
<CriteriaDef entity="name" targetEntity="name">

<Criterion property="attributename" targetProperty="attributename" matchType="type"/>

</CriteriaDef>

You can map a single search criteria entity to more than one target entity.
Do not add new <CriteriaDef> elements into [Link]. Only modify the contents of existing criteria
definitions. Do not remove a required base CriteriaDef element. Adding or removing these elements can introduce
problems into your PolicyCenter installation.

WARNING Guidewire strongly recommends you do not remove <CriteriaDef> elements that
exist in the base configuration.

See also
• “The <CriteriaDef> element” on page 401
400 chapter 28: Configuring search functionality
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Search criteria XML elements

The following table describes the XML elements in the [Link] file.

Element name Subelement Description More information

SearchConfig CriteriaDef Root element in [Link].

CriteriaDef Criterion Specifies the mapping from a search criteria entity to the target entity “The <CriteriaDef>
on which to search. element” on
WARNING Do not add or remove CriteriaDef elements in search- page 401
[Link]. Modify only the contents of existing CriteriaDef ele‐
ments.
Criterion Specifies how PolicyCenter matches a column (field) on the search crite‐ “The <Criterion>
ria to the query against the target entity. Use this element to perform subelement” on
simple matching only. Simple matches are criteria that match values in a page 401
single column of the same type in the target entity.

The <CriteriaDef> element

A <CriteriaDef> element specifies the mapping from a search criteria entity to the target entity on which to search.
For example, a <CriteriaDef> element can specify a mapping between a DocumentSearchCriteria entity and a
Document entity. A <CriteriaDef> element uses the following syntax.
<CriteriaDef entity="entityName" targetEntity="targetEntityName">

These attributes have the following definitions.

<CriteriaDef> attribute Required Description

entity • Type name of the criteria entity

targetEntity • Type name of the target entity.

A <CriteriaDef> element can have the following subelement.

<CriteriaDef> subele‐ Description More information

ment
Criterion Performs simple, one‐to‐one mapping between a criteria en‐ “The <Criterion> subelement” on
tity attribute and a target entity attribute. page 401

The <Criterion> subelement

Within a <CriteriaDef> element you can define zero or more <Criterion> subelements. A <Criterion> element
performs simple, one-to-one mapping between a criteria entity attribute and a target entity attribute. A <Criterion>
element uses the following syntax.
<Criterion property="attributename"
targetProperty="attributename"
forceEqMatchType="booleanproperty"
matchType="type"/>

These attributes have the following definitions.

Configuring search functionality 401

Guidewire PolicyCenter 9.0.9 Configuration Guide

<Criterion> attrib‐ Re‐ Description

ute quired
property • The name attribute on the criteria entity. PolicyCenter uses this value to get the user's search
term from the criteria entity.
matchType • This attribute is dependent on the data type of the targetProperty. See the following table
for possible values.
forceEqMatchType The name of a Boolean property on the criteria entity:
• If this attribute evaluates to true, the Criterion uses an eq (equality) match.
• If this attribute evaluates to false, the Criterion uses the matchType that the Criterion
specifies to perform the match.
For example:
<Criterion property="StringProperty"
forceEqMatchType="FlagProperty"
matchType="startsWith"/>
This code uses a startsWith match for StringProperty unless the FlagProperty on the cri‐
teria entity is true, in which case, the match uses an eq match type.
targetProperty The name attribute on the entity on which to search.
IMPORTANT Do not use a virtual property on the entity as the search field.

The following list describes the valid matchType values. For String objects, matchType case-sensitivity depends on
the database, except for startsWith and contains, which are always case-insensitive.

Match type Evaluates to Use with data type Notes

contains String IMPORTANT Guidewire strongly recommends that you avoid using
the contains match type, if at all possible. The contains match type
is the most expensive type in terms of performance.
eq equals Numeric or Date
ge greater than or Numeric or Date
equal
gt greater than Numeric or Date
le less than or equal Numeric or Date
lt less than Numeric or Date
startsWith String The startsWith match type is very expensive in terms of perform‐
ance, second only to the contains match type. Use startsWith with
caution.

Performance tuning for specific search criteria

For some searches, adding an index can improve performance. The exact index to add depends on the database that
you use and the details of the situation. Whenever you change the search criteria by adding or modifying a
<Criterion> subelement, ensure that appropriate indexes are in place. Guidewire recommends that you consult a
database expert.
For example, suppose that you add a column that is the most restrictive equality condition in your search
implementation. In this case, consider adding an index with this column as the leading key column.

402 chapter 28: Configuring search functionality

 Guidewire PolicyCenter 9.0.9 Configuration Guide

IMPORTANT For performance reasons, Guidewire strongly recommends that you avoid the contains
match type. The contains match type is the most expensive type in terms of performance.

Do not attempt to modify the required search properties

Guidewire divides the main search screens into required and optional sections. Guidewire has carefully chosen the
properties in the required section to enhance performance. Therefore, do not change which properties are required
properties. Adding your own required search criteria can cause performance issues severe enough to bring down a
production database.
In addition, Guidewire has carefully chosen the match types of the existing required properties, due to restrictions on
configuring fields on tables that are joined to the search table. Therefore, do not change the match types of existing
required fields.

WARNING For performance reasons, Guidewire expressly prohibits the addition of new required
fields or changing the match type of existing required fields in the PolicyCenter search screens.

Configuring database search criteria in Gosu

You can add criteria to searches that use either Gosu classes or virtual entities.
In the base PolicyCenter configuration, Guidewire provides Gosu classes to configure database search for a number
of entity types. The following table lists some entity types for which users can search and the Gosu classes that you
modify to configure the user interface for that type of search.

Entity type to search Gosu search criteria class

Account [Link]

Activity [Link]

Claim [Link]

IndustryCode [Link]

History [Link]

PolicyPeriod [Link]

Guidewire also provides a Gosu enhancement that you can use to configure searches for Contact objects.
[Link]

To improve contact search, Guidewire adds fields to the Contact entity as denormalization fields from the Address
entity. These fields include:
• CityDenorm
• Country
• PostalCodeDenorm
• State

Configuring search functionality 403

Guidewire PolicyCenter 9.0.9 Configuration Guide

WARNING Guidewire strongly recommends that you consider all the implications before
customizing any search configuration object. Adding new search criteria can result in significant
performance impacts, particularly in large databases. Guidewire recommends that you thoroughly
test any search customizations for performance issues before you move them into a production
database.

See also
• “Configuring PolicyCenter database search” on page 397
• Guidewire Contact Management Guide

Adding a new optional search field to a Gosu class search

To expand the search capabilities of a Gosu search criteria class with additional optional search criteria, you do the
following general tasks:
1. Declare the variable in the Gosu class definition file.
2. Add a field in the PCF file that maps to that variable.
3. Incorporate the variable into the query defined within the Gosu search object class definition file.

See also
• “Add an optional search field to a Gosu class search” on page 404
• “Adding an optional search field to a virtual entity search” on page 405

Add an optional search field to a Gosu class search

About this task
The following example adds a new field to the Activity Search PCF, and then incorporates the field into the query in
ActivitySearchCriteria.

Procedure
1. Open [Link] for editing in PolicyCenter Studio.
2. Navigate to the definitions of search criteria.
In the base configuration, these definitions look like the following lines.
var _policyNumber : String as PolicyNumber
var _accountNumber : String as AccountNumber
var _overdueNow : Boolean as OverdueNow
var _activityStatus : ActivityStatus as SearchedActivityStatus
var _priority : Priority as SearchedPriority
var _assignedUser : User as SearchedAssignedUser

3. Add the following line at the end of this list.

var _recurring : Boolean as Recurring

4. Add a display key for the Recurring field label:

a. Navigate to configuration→config→Localizations in Studio, and open the display_en_US.properties file.
b. Find the display key entries that begin with [Link], and add the following line.

[Link] = Recurring

5. Add a widget for the new search field to the user interface.
a. Open ActivitySearchDV for editing in Studio.
b. Add an Input widget in the optional section directly under the Overdue Now field.
404 chapter 28: Configuring search functionality
 Guidewire PolicyCenter 9.0.9 Configuration Guide

c. Enter the following values for this widget in the Properties area at the bottom of the screen.

editable true

id Recurring

label [Link]

required false

value [Link]

PolicyCenter defines variable searchCriteria for this PCF file under Required Variables. To see the definition
of this variable, select the entire DetailViewPanel and then select the Required Variables tab. You see the following
variable definition in the base configuration.

name searchCriteria

type [Link]

6. Add the new search field to the search query.

a. Open [Link] for editing.
b. Add the following code to the list of if statements in the makeQuery function.
if (Recurring != null) {
[Link]("Recurring",Equals , Recurring)
}

7. Stop and restart the application server.

8. If your installation does not include a recurring activity, create one:
a. Open a currently active policy.
b. Select New Activity from the Actions menu, set Recurring to Yes, and redo the search.
9. Test your search screen by doing the following:
a. Open PolicyCenter and navigate to the Search→Search Activities screen.
b. Perform an activity search, setting Recurring to Yes.

Adding an optional search field to a virtual entity search

To expand the search capabilities of a virtual search entity type with additional optional search criteria, you need to
do the following general tasks. In the following instructions, replace Entity with the entity type that you need to
modify.
1. Extend the EntitySearchCriteria object and add your search field to it as an extension column. For
example, add a column to the EntitySearchCriteria extension ([Link]).
2. Add widgets for the additional search criteria fields to the search screen PCF file.
3. Modify [Link] by adding the new search criteria.
The following table lists PolicyCenter files and tasks that you use in modifying a search that uses virtual entities.

File Task
[Link] Add a CriteriaDef element for the search entity. PolicyCenter uses this for the
SearchObjectType in [Link].

[Link] Examine the values of the following properties. These properties determine the
classes and methods that you need to modify.
SearchPanel: Properties
criteriaName: searchCriteria
searchCriteria: new EntitySearchCriteria()
search: [Link]()
Configuring search functionality 405
Guidewire PolicyCenter 9.0.9 Configuration Guide

File Task
If the search screen supports multiple entity types, you see a range input widget
similar to the following one. The value property determines the classes and
methods that you need to modify.
SearchFor: Properties
value: [Link]
This PCF file also contains fields for all searchable criteria. Add your new search
fields to this file.
[Link] Base configuration data model definitions for standard fields on the
EntitySearchCriteria object. You cannot modify this base configuration file.

[Link] Base configuration enhancement fields on the EntitySearchCriteria object.

Modify this file and add your new search configuration criteria.
[Link] Modify the search method.

Deploying customized database search files

Guidewire recommends that you first make your search customization file changes in your development
environment. You must then create a .war or .ear file to deploy your changes to the production server.

See also

• Installation Guide

Search criteria validation on server start‐up

The PolicyCenter production server validates your search configuration whenever the server receives a start-up
request. If the validation fails, the server does not start. The production server validates the following:
• The CriteriaDef entity and targetEntity attributes reference real entities.
• The targetEntity type is a persistent entity.
• The targetProperty attributes reference searchable properties on the target entity, except for those on
ArrayCriterion elements that must reference an array column.
• The type of each property attribute on a Criterion element matches the type of its corresponding
targetProperty, for example, that both are strings or both are numbers.
• All Criterion match types (matchType) are suitable for the criterion property. For example, you can use
startsWith only for String properties.)

See also

• “The <CriteriaDef> element” on page 401

• “The <Criterion> subelement” on page 401

Free‐text search configuration

This topic describes how to enable and configure free-text search for PolicyCenter.

See also

• Installation Guide
• Integration Guide
406 chapter 28: Configuring search functionality
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Overview of free‐text search

Free-text search depends on a full-text search engine, the Guidewire Solr Extension. You can configure free-text
search and the Guidewire Solr Extension for different kinds of operation:
• External – Supported in production and development environments, the Guidewire Solr Extension runs as a
separate application in a different instance of the application server than the instance that runs PolicyCenter.
• Embedded – Supported only in development environments, the Guidewire Solr Extension runs automatically as
part of PolicyCenter in the application server instance that runs PolicyCenter, not as a separate application.

Free‐text search system architecture

The system architecture of the Guidewire free-text search feature comprises the following components:
• The Guidewire PolicyCenter application.
• The Guidewire Solr Extension, a modified version of the Apache Solr full-text search engine.
• The Guidewire free-text batch load command.
• The Free-text Search page on the Internal Tools tab in the PolicyCenter application as an alternative during
development to running the free-text batch load command.
The components of the free-text search feature depend on configuration parameters and configuration files in two
primary locations: the PolicyCenter home directory and a separate Guidewire Solr home directory.

Guidewire Solr Extension deployment options

Several deployment options are available for using Guidewire Solr Extension with PolicyCenter. While guidance
and caveats come later, the following four options are possible regardless of whether PolicyCenter operates in a
production environment or a development environment:
• Guidewire Solr Extension can run on a physical host or on a Java Virtual Machine (JVM). In the case of the latter
deployment type, a Tomcat, WebSphere, or other appropriate application server can host the JVM.
• Guidewire Solr Extension can run on the same host as PolicyCenter. It can also run on a separate host.
• Guidewire Solr Extension can run on a single server or a cluster of servers.
• Guidewire Solr Extension can use a number of host servers that is independent from whether PolicyCenter runs
in a clustered configuration or in an unclustered configuration.
In the development environment alone, Guidewire Solr Extension and PolicyCenter can run in an embedded mode.
In this mode, the two applications run as one in the same JVM. Guidewire does not support embedded mode in a
production environment.
Though options 1 through 4 lay out the possible deployments of Guidewire Solr Extension in the production
environment, please note two caveats. Guidewire recommends that most customers run Guidewire Solr Extension on
a separate physical host from PolicyCenter. Guidewire also recommends that larger customers running either
Guidewire Solr Extension or PolicyCenter in a clustered configuration or in high availability also run the other
application in a clustered configuration. Doing so avoids the other application becoming a single point of failure or
bottleneck.

Free‐text search system architecture in a production environment

The following diagram illustrates the system architecture for free-text search if you run PolicyCenter in a production
environment. In a production environment, you must configure free-text search for external operation. In a
development environment, such a configuration is an option but is not mandatory.

Configuring search functionality 407

Guidewire PolicyCenter 9.0.9 Configuration Guide

PolicyCenter Free‐Text Search Production Environment and Development Environment

System Architecture in External Operation

application server database server

Guidewire PolicyCenter
database engine

Free‐text search

application server

ISolrSearchPlugin
Guidewire Solr Extension
ISolrMessageTransportPlugin

Free‐text batch load command

Guidewire PolicyCenter home directory Guidewire Solr home directory

[Link] pc/[Link]
[Link] pc/solr/[Link]
[Link] pc/solr/policy_active/conf
[Link]
[Link]
used by the free-text batch load command
Legend
Running software [Link]|[Link]
Configuration files [Link]
[Link]
Host computer
[Link]|[Link]
SQL‐based data exchange

Text‐based data exchange

Note: Guidewire supports running the separate application server instances for PolicyCenter and the
Guidewire Solr Extension on the same hosts in production.

Free‐text search system architecture in a development environment

The following diagram illustrates the system architecture for free-text search if you run PolicyCenter in a
development environment. In a development environment, you may configure free-text search for either external
operation or embedded operation.

408 chapter 28: Configuring search functionality

 Guidewire PolicyCenter 9.0.9 Configuration Guide

PolicyCenter Free‐Text Search Development Environment System Architecture in Embedded Operation

database server

database engine

application server

Guidewire PolicyCenter

Free‐text search

Server tools > Free-text Search

Guidewire Solr Extension

ISolrSearchPlugin

ISolrMessageTransportPlugin

Guidewire PolicyCenter home directory Guidewire Solr home directory

[Link] pc/[Link]
[Link] pc/solr/[Link]
[Link] pc/solr/policy_active/conf
[Link]
[Link]
used by the free-text batch load batch process

[Link]
[Link]
[Link]|[Link]

Legend
Running software

Configuration files

Host computer

SQL‐based data exchange

Text‐based data exchange

With embedded operation, the Free-text Search page on the Internal Tools tab is available as an alternative to the free-
text batch load command.

Free‐text search configuration parameters and files

The components of the free-text search feature depend on configuration parameters and configuration files in two
primary locations: the PolicyCenter home directory and a separate Guidewire Solr home directory.

Configuration parameters and files for free‐text search in PolicyCenter

The following parameters and files enable and configure free-text search in PolicyCenter:
• FreeTextSearchEnabled – Defined as a configuration parameter in [Link], enables certain back-end
components of free-text search to fully operate. The default value is false.
Configuring search functionality 409
Guidewire PolicyCenter 9.0.9 Configuration Guide

• EnableDisplayBasicSearchTab – Defined as a script parameter in [Link], enables the

Search Policies Basic screen for free-text search. You define script parameters initially through Studio but
administer them on the Script Parameters page of the Administration tab in the application. The script
EnableDisplayBasicSearchTab parameter has no effect if the FreeTextSearchEnabled configuration
parameter is set to false.
Note: Set this script parameter to false before running the free-text search batch load command,
and set it back to true after the batch command finishes. Setting the parameter to false prevents
users from performing free-text searches while the batch process runs.

PolicyCenter Search Architecture (During Batch Load Process)

Relational database
Advanced search
(database search)

PolicyCenter application

Policy updates

Real‐time index Batch‐load index

documents documents
Policy Search

Basic search
(free‐text search)
(unavailable
during batch load
process)
Full‐text database

• [Link] – Provides detailed configuration of the fields that free-text search extracts from
the PolicyCenter database and sends to the full-text search database for indexing and searching.
• [Link] – Configures how PolicyCenter works with the Guidewire Solr Extension, including
connection information, and whether the mode of operation is external or embedded.

See also
• “Search parameters” on page 88
• “Script parameters” on page 125
• “Configuring the Guidewire Solr Extension” on page 413

410 chapter 28: Configuring search functionality

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Configuration files for the Guidewire Solr extension

The following files configure the Guidewire Solr Extension, the full-text search engine that the free-text search
feature depends on. These configuration files control how the Guidewire Solr Extension loads data that PolicyCenter
sends for indexing and how the Guidewire Solr Extension responds to search requests from PolicyCenter.
• [Link] – Defines the Guidewire Solr home directory for the Guidewire Solr Extension.
• [Link] – Defines the location in the Guidewire Solr home directory of the core for each searchable entity type
in the Guidewire Solr Extension.
• [Link] – Defines fields of data as known in the Guidewire Solr Extension.

See also
• “Configuring the Guidewire Solr Extension” on page 413
• “Configuring free-text search for indexing and searching” on page 423

Configuration files for the free‐text batch load command

The following files configure the free-text batch load command. The command extracts data directly from the
PolicyCenter database through native SQL commands and loads the extracted data into the Guidewire Solr
Extension.
• [Link] – Specifies the location of the index documents that the free-text batch load command creates
for the Guidewire Solr Extension to load. The file also specifies the mapping between fields in the index
documents and fields defined in [Link].
• [Link] – Specifies working resources for the free-text batch load command.
The file also contains the native SQL that the free-text batch load command uses to extract data from the
database server.
• [Link]/[Link] – Runs the free-text batch load command. The file sets the following
environment variables:
◦ APP_PREFIX – The designation for PolicyCenter to use in a path
◦ BASE_DIR – The root of the Guidewire Solr home directory
◦ GWSOLR_HOME – The root of the Guidewire Solr Extension home directory, including the path to PolicyCenter
files
◦ CONFIGFILE – The [Link] file to use
• [Link]/[Link] – Collates and compiles index documents for the Guidewire Solr Extension
using data selected from the relational database.

See also
• “Configuring the free-text batch load command” on page 424

Enabling free‐text search in PolicyCenter

Full-text search is disabled in the base configuration of PolicyCenter. Before you attempt to enable free-text search,
you must set up free text search and the Guidewire Solr Extension, a full-text search engine, for external or
embedded operation. After you complete the setup of free-text search, you enable free-text search in PolicyCenter
with:
• The script parameter EnableDisplayBasicSearchTab in the running PolicyCenter application
• Indexing System rules in the EventFired rule set
• The free-text search plugins ISolrMessageTransportPlugin and ISolrSearchPlugin
• The free-text message destination [Link]
None of the preceding free-text resources in PolicyCenter operate unless you set the turnkey configuration parameter
FreeTextSearchEnabled to true. After you make this change, use the FreeTextSearchEnabled parameter to
toggle the free-text search feature in PolicyCenter off and on temporarily.
Configuring search functionality 411
Guidewire PolicyCenter 9.0.9 Configuration Guide

Enable free‐text search in PolicyCenter

Before you begin
Follow the instructions for setting up free-text search:
• Installation Guide

Procedure
1. Start PolicyCenter Studio.
2. Set up the EventFired rules for free-text search:
a. In the Project window, navigate to configuration→config→Rule Sets→EventMessage.
b. Double-click EventFired to open [Link] in the Rules editor, and then ensure that the Indexing
System rules are enabled.
3. Configure the ISolrMessageTransportPlugin plugin:
a. In the Project window, navigate to configuration→config→Plugins→registry.
b. Double-click [Link] to open it in the Plugins Registry editor, and then
enable it with the Gosu class [Link].
c. In the Project window, navigate to configuration→config→Messaging.
d. Double-click [Link] to open it in the Messaging editor.
e. In the list box on the left, select the [Link] destination, and then enable it
with the ISolrMessageTransportPlugin transport plugin.
4. Configure the ISolrSearchPlugin plugin:
a. In the Project window, navigate to configuration→config→Plugins→registry.
b. Double-click [Link] to open it in the Plugins Registry editor, and then enable it with
the Gosu class [Link].
5. Enable free-text search:
a. In the Project window, navigate to configuration→config.
b. Double-click [Link] to open it in the XML editor, and then set FreeTextSearchEnabled to true.
6. Start the PolicyCenter application.

Result
If you enabled free-text search successfully, you see the following message at server startup on the server console
and in the server log file.
***** PCSolrMessageTransportPlugin is initialized *****

If you configured free-text search for embedded operation, you see the following messages at server startup on the
server console and in the server log file.
Solr Installing and provisioning embedded Solr in folder C:\opt\gwsolr
Solr Embedded server configured for automatic provisioning in /opt/gwsolr for appCode pc

See also
• Installation Guide
• Integration Guide

Enabling the free‐text search user interface in PolicyCenter

The EnableDisplayBasicSearchTab script parameter specifies whether to enable the free-text policy search user
interface. Whenever this script parameter is set to true, the Search Policies screen displays tabs labeled Basic and
Advanced. The Basic tab contains the user interface for free-text search. The Advanced screen contains the user
interface for database search.
412 chapter 28: Configuring search functionality
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Whenever this script parameter is set to false, the Search Policies screen displays the Advanced screen only. Setting
the EnableDisplayBasicSearchTab script parameter to true has no effect if the FreeTextSearchEnabled
configuration parameter in [Link] is set to false.
Whenever a systems administrator runs the free-text batch load command while PolicyCenter is available to users,
you must set this script parameter to false to hide the Basic search screen. Users continue to use the Advanced search
screen without interruption. After the free-text batch load command finishes, set the
EnableDisplayBasicSearchTab script parameter to true to restore the Basic search screen for users.
Changes to the value of the EnableDisplayBasicSearchTab script parameter take effect immediately. You do not
need to restart the server.
The default value of this parameter is true.

See also
• “Search parameters” on page 88
• “Script parameters” on page 125
• System Administration Guide

Configuring the Guidewire Solr Extension

You configure the Guidewire Solr Extension separately from configuring your PolicyCenter instance.

See also
• Installation Guide

Overview of configuring the Guidewire Solr Extension

The following configuration files are important when you configure the Guidewire Solr Extension for free-text
search:
• [Link] – Defines the Guidewire Solr home directory for the Guidewire Solr Extension.
• [Link] – Defines global properties and configuration settings for the Guidewire Solr Extension.
• [Link] – Configures how PolicyCenter connects to and works with the Guidewire Solr
Extension. Categories of configuration settings include:
◦ Connections with specific instances of the Guidewire Solr Extension
◦ Type of operating mode for instances of the Guidewire Solr Extension
◦ Provision of changed configuration files from the PolicyCenter home directory to instances of the Guidewire
Solr home directory

IMPORTANT Always use Studio to modify the free-text configuration files.

Generally, you work with these files during installation, at the time you set up free-text search in the application
server or servers dedicated to the Guidewire Solr Extension.
If you make changes to the configuration files within Studio, for the changes to take effect, you must run the
gwb packageSolr command. Then redeploy the [Link] file that this command creates. If you make
changes to the configuration files in the deployment folders outside Studio, you must copy your changes back to the
folders in the Navigation window Studio. If you do not copy your changes back to Studio, the files from Studio
replace your changed files. This occurs the next time you run the gwb packageSolr command and redeploy the pc-
[Link] file.

See also
• Installation Guide
Configuring search functionality 413
Guidewire PolicyCenter 9.0.9 Configuration Guide

Configuring connections with the Guidewire Solr Extension

You configure instances of the Guidewire Solr Extension and how PolicyCenter connects with them in the
[Link] file. Two XML elements help in this type of configuration: the <document> element and
the <solrserver> element.

The <document> element

In [Link], for each type of index document, such as policy data, a <document> element
associates that data type with an instance of the Guidewire Solr Extension. For example:
<document name="policy" servername="my_solr_instance"/>

The servername attribute specifies a <solrserver> element defined elsewhere in the [Link]
file.
The base configuration includes <document> elements for each type of data that free-text search supports. You must
modify the servername attribute to match the instances of the Guidewire Solr Extension that you define and use.

The <solrserver> element

In [Link], for each instance of the Guidewire Solr Extension, a <solrserver> element defines
its type of operation and how PolicyCenter connects with it.
<solrserver name="name" type={"embedded"|"http"|"cloud"} [env="env-variable-value"]>

The servername attributes of <document> elements must match the name attributes of <solrserver> elements. You
can map more than one <document> element to the same <solrserver> element.
The type attribute specifies the operating mode for the Guidewire Solr Extension. The attribute has three possible
values:
• embedded – The Guidewire Solr Extension operates embedded within PolicyCenter.
• http – The Guidewire Solr Extension operates externally from PolicyCenter, as a single server.
• cloud – The Guidewire Solr Extension operates externally from PolicyCenter, as a cluster of servers.
The base configuration includes <solrserver> elements that serve as examples for the <solrserver> elements that
you must define.

The env attribute

In [Link], the <document>, <solrserver>, and <param> elements support the env attribute.
During the development and testing of your implementation of free-text search, you often switch between different
instances of the Guidewire Solr Extension. For example, you may use the server in embedded mode for your own
unit testing and a local or remote server instance for system testing. To switch between server instances, you can
change the servername attribute in [Link] to reference the <solrserver> element for the
instance that you want to use.
However, switching between server instances by editing [Link] can be tedious. As an alternative,
use the env attribute on multiple <document> elements for the same index document type to associate each with a
different server definition. For example, your [Link] file contains the following document
definitions.
<document name="policy" archive="false" servername="embedded"/>
<document name="policy" archive="false" servername="localhttp" env="local"/>

In the preceding example, PolicyCenter runs with the embedded server by default. PolicyCenter does so for two
reasons. The first reason is because PolicyCenter base configuration does not have a setting for its Java VM
environment variable. The second reason is because the <document> element associated with an embedded server
has the same name and no setting for its env attribute.
To run PolicyCenter with the external server hosted locally instead, start PolicyCenter with the Java VM
environment variable -[Link]=local. In this case, PolicyCenter looks for the <document> element with the
414 chapter 28: Configuring search functionality
 Guidewire PolicyCenter 9.0.9 Configuration Guide

same name and with an env attribute having a value of “local.” The <document> element that has these
characteristics corresponds to an external server hosted locally.

Configuring the Guidewire Solr Extension for embedded or external operation

You configure the Guidewire Solr Extension for embedded or external operation in the [Link]
file. The file contains one or more <solrserver> elements. They define instances of the Guidewire Solr Extension.
You configure the Guidewire Solr Extension for embedded or external operation with the type attribute.
<solrserver name="name" type={"embedded"|"http"|"cloud"} [env="env-variable-value"]>

PolicyCenter supports the embedded type only in development environments. PolicyCenter supports the http and
cloud types in production and development environments. Setting the type to embedded configures the Guidewire
Solr Extension for embedded operation. Setting the type to http or cloud configures the Guidewire Solr Extension
for external operation.

Configuring the Guidewire Solr Extension for embedded operation

With embedded operation, the Guidewire Solr Extension runs as part of the PolicyCenter application, not as an
application in a different application server instance. Therefore, embedded server definitions do not specify HTTP
connection information. PolicyCenter supports embedded operation only in development environments.
The following example in [Link] shows a typical configuration of an embedded server in a
development environment set up on the bundled QuickStart application server.
<solrserver name="embeddedSolr" type="embedded">
<param name="solrroot" value="/opt/gwsolr"/>
</solrserver>
...
<document name="policy" archive="false" servername="embeddedSolr"/>

The name attribute of the <solrserver> element lets you bind document types, such as policies, to a server that has
cores for them. A <document> element may reference a <solrserver> element of type embedded only if you run
the PolicyCenter application in development mode. Otherwise, PolicyCenter generates an error message on the
server console and in the server log, and free-text search does not operate.
For Solr servers of embedded type, you must specify the solrroot parameter. The value is the absolute path to a
directory where the indexes for the cores are located. Generally, you specify a Guidewire Solr Home directory that
holds files extracted from the [Link] file as solrroot. In a typical development environment, the home
directory is on the same host as the one that hosts your PolicyCenter application. Free-text search creates the
directory specified by solrroot during server startup if the directory does not exist and extracts the files from pc-
[Link] into that directory.
The following example shows a typical configuration of an embedded server in a development environment set up
on a Tomcat application server.
<solrserver name="embeddedSolr" type="embedded">
<param name="solrroot" value="/opt/gwsolr"/>
<param name="gwsolrzip" value="/dev/PolicyCenter/solr/[Link]"/>
</solrserver>
...
<document name="policy" archive="false" servername="embeddedSolr"/>

For embedded operation on Tomcat, you must include the gwsolrzip parameter to specify the absolute path to the
[Link] file in your PolicyCenter home directory.

See also
• “Configuring the Guidewire Solr Extension for provisioning” on page 417

Configuring the Guidewire Solr Extension for external operation

With external operation, the Guidewire Solr Extension runs as an independent application in a different application
server instance than the one that runs PolicyCenter. Therefore, external server definitions must specify HTTP
connection information.
Configuring search functionality 415
Guidewire PolicyCenter 9.0.9 Configuration Guide

Note: Guidewire does not support configuring the Guidewire Solr Extension for external operation
with development environments installed on the bundled QuickStart application server.
The following example in [Link] shows a typical configuration of an external server for a
development environment.
<solrserver name="localhost" type="http">
<param name="host" value="localhost"/>
<param name="port" value="8983"/>
</solrserver>
...
<document name="policy" archive="false" servername="localhost"/>

The name attribute of the <solrserver> element lets you bind a document type, such as policy, to a server that has a
core for it.
For external servers, you must specify the host and the port parameters. Typically in a development environment,
you run the Guidewire Solr Extension in an application server instance hosted on the same machine where you run
the PolicyCenter application. If you run the Guidewire Solr Extension on the same machine that runs PolicyCenter,
specify localhost for the host parameter. Otherwise, specify the host name for the remote host.
The base configuration of the Guidewire Solr Extension configures its port number as 8983. For the port parameter
of a an external server definition, specify the port number that you configured for the Guidewire Solr Extension in
the application server that runs it.
With external servers, you can specify two kinds of HTTP timeout parameters: connectiontimeout and
readtimeout. The following example shows typical timeout parameter settings.
<solrserver name="localhost" type="http">
<param name="host" value="localhost"/>
<param name="port" value="8983"/>
<param name="connectiontimeout" value="300000"/>
<param name="readtimeout" value="300000"/>
</solrserver>

Specify timeout intervals in milliseconds. The connectiontimeout parameter specifies how long PolicyCenter
waits for the Guidewire Solr Extension to respond to a connection request. The readtimeout parameter specifies
how long PolicyCenter waits for the Guidewire Solr Extension to completely return results from a search request.
With external servers, you can also specify two connection quantity parameters: maxtotalconnections and
defaultmaxtotalconnectionsperhost. The following example shows typical connection quantity parameter
settings.
<solrserver name="localhost" type="http">
<param name="host" value="localhost"/>
<param name="port" value="8983"/>
<param name="maxtotalconnections" value="40"/>
<param name="defaultmaxtotalconnectionsperhost" value="40"/>
</solrserver>

The maxtotalconnections parameter places an upper limit on the total number of connections per application
server. The defaultmaxtotalconnectionsperhost parameter places an upper limit on the number of connections
to the specified host. The defaultmaxtotalconnectionsperhost parameter value cannot exceed the value of the
maxtotalconnections parameter. For the Guidewire Solr Extension server with a type of http, Guidewire
recommends that the two connection quantity parameters have the same value.
If the server type is cloud, you can set the maxtotalconnections parameter to a higher value than the value of the
defaultmaxtotalconnectionsperhost parameter. The maximum value for the maxtotalconnections parameter
is N times the value of the defaultmaxtotalconnectionsperhost parameter. In this equation, N is the number of
distinct Guidewire Solr Extension hosts.
Note: If the performance of free-text search is slow, increase the maximum number of connections to
the specified Guidewire Solr Extension host or hosts.

See also

• “Configuring the Guidewire Solr Extension for high availability” on page 418
416 chapter 28: Configuring search functionality
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Configuring the Guidewire Solr Extension logging level

Note: The instructions in this topic apply only when operating Guidewire Solr Extension in embedded
mode.
The Guidewire Solr Extension produces log entries to convey information about its operation. These entries appear
in the application log file. The number of log entries that the free-text search service produces in embedded mode
depends on the Guidewire Solr Extension logging level.
You can set the logging level to control the number of log entries in the application log file. The default logging
level for Guidewire Solr Extension processes is INFO. This level results in Guidewire Solr Extension log entries that
convey a sense of correct system operation as well as any potential or definite problems.
If the default logging level results in too many log entries in the application log file, you must change the level to
WARN or ERROR. When the logging level is WARN, the Guidewire Solr Extension log entries convey only potential or
definite problems. When the logging level is ERROR, the log entries convey only definite problems. Neither elevated
level results in log entries for routine or correct system operation.
Setting the logging level to WARN or ERROR requires modifying the [Link] file. You can access this
file at the following location in Guidewire Studio:
configuration→config →logging
In the [Link] file, set [Link] either to WARN or ERROR. Ensure that one
of the following lines is present in the file:
[Link]=WARN

[Link]=ERROR

If one of the lines present but commented out, remove the comment marker (#) preceding the line. If neither line is
present, add one of the lines.
For additional information, see the following topics:
• System Administration Guide

Configuring the Guidewire Solr Extension for provisioning

You can configure embedded server definitions to provision the Guidewire Solr Home directory with revised
configuration files after you edit them in Studio. Use the provision parameter in an embedded server definition in
[Link] to control whether and how to provision the Guidewire Solr Home directory with changed
configuration files.
<param name="provision" value="{"true"|"false"|"auto"}/>

If you set the provision parameter to true, free-text search deploys the files from PolicyCenter/gwsolr/pc-
[Link] to the solrroot directory every time you start the PolicyCenter application. If you set provision to
false, you must manually provision changed files that you edit in Studio. Set provision to auto only for
automated testing. With provision set to auto, the indexes are dropped each time you start the PolicyCenter
application.

Example Provisioning Configuration

The following example in [Link] shows a typical configuration of an embedded server with
provisioning.
<solrserver name="embedded" type="embedded">
<param name="provision" value="true"/>
<param name="solrroot" value="c:\opt\gwsolr"/>
</solrserver>

See also
• “Configuring the Guidewire Solr Extension for embedded or external operation” on page 415
Configuring search functionality 417
Guidewire PolicyCenter 9.0.9 Configuration Guide

Configure the Guidewire Solr Extension for provisioning

About this task
When configuring Guidewire Solr Extension for provisioning during development, you must run packageSolr to
rebuild the [Link] file. You must do so after modifying files in PolicyCenter Studio but before restarting
the PolicyCenter application.

Procedure
1. Start PolicyCenter Studio.
2. In the Project window, navigate to configuration→config→solr.
3. Double-click [Link] to open the file in the editor.
4. In a <solrserver> definition for an embedded server, set the value of the provision parameter to true.
For example:
<solrserver name="embedded" type="embedded">
<param name="provision" value="true"/>
<param name="solrroot" value="c:\opt\gwsolr"/>
</solrserver>

5. Stop the PolicyCenter application, if it is running.

6. Open a command prompt window and navigate to the application directory.
7. In the command prompt window, type the following command.

gwb packageSolr

The command rebuilds the [Link] file in PolicyCenter/solr.

8. Start the PolicyCenter application.
Free-text search deploys the contents of [Link] to the directory specified by solrroot. Files already
in solrroot are overwritten by new files from [Link].

Configuring the Guidewire Solr Extension for high availability

You configure the Guidewire Solr Extension for high availability by deploying it to multiple SolrCloud servers,
managed as a cluster, or ensemble, by Apache ZooKeeper.
You must download and install ZooKeeper on the hosts where you want to install and run the Guidewire Solr
Extension for high availability. The distribution of PolicyCenter does not include the ZooKeeper software.
Configuration for high availability requires you to modify the following files:
• [Link] – PolicyCenter file that configures PolicyCenter to connect with SolrCloud servers in a
ZooKeeper ensemble
• [Link] – ZooKeeper file that configures each SolrCloud server for membership in a ZooKeeper ensemble
• myID – ZooKeeper file that configures each SolrCloud server with its ordinal number in the ensemble
Your PolicyCenter instance connects directly with individual member servers in a ZooKeeper ensemble. A server
definition for high availability has the following syntax:
<solrserver name="cloud" type="cloud">
<param name="zkhosts" value="zookeeperHost[:port][,zookeeperHost[:port]][,...]/chRoot"/>
</solrserver>

The default port for a ZooKeeper host is to 2181. Specify ports if you need to use a port that is not 2181.
The chroot parameter identifies an application within a ZooKeeper ensemble. The parameter allows multiple
applications to use a single ZooKeeper ensemble for high availability. For the Guidewire Solr Extension included
with PolicyCenter, use pc as the value for chroot. Although you can use any value and although the parameter is
optional for stand-alone instances, Guidewire recommends chroot with the value pc.
418 chapter 28: Configuring search functionality
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Note: For Tomcat hosts, use the same value that you specify for zkhosts as the value for the launch
parameter zkRun for the Guidewire Solr Extension.

Example High Availability Configuration

The following example in [Link] shows a typical configuration of a server with high availability.
<solrserver name="cloud" type="cloud">
<param name="zkhosts" value="gwsolr1,gwsolr2,gwsolr3/pc"/>
</solrserver>

Configure solrserver‐[Link] for high availability

Procedure
1. Start PolicyCenter Studio.
2. In the Project window, navigate to configuration→config→solr.
3. Double-click [Link] to open the file in the editor.
4. Define the zkhosts parameter to specify the hosts and ports of all members of a ZooKeeper ensemble.
a. For the parameter value, specify the hosts and ports in a comma-separated list, using the following syntax:
value="zookeeperHost[:port][,zookeeperHost[:port]][,...]/chRoot"

b. Set the type attribute on the solrserver element to "cloud".

c. Specify ports if you need to use a port that is not 2181.
d. Use pc as the value of chroot.

Example
The following example shows a typical configuration for a high availability cluster of Guidewire Solr Extension
servers.
<solrserver name="cloud" type="cloud">
<param name="zkhosts" value="gwsolr1,gwsolr2,gwsolr3/pc"/>
</solrserver>

Next steps
You must now perform the following tasks:
• “Install ZooKeeper” on page 419
• “Configuring [Link] ” on page 420

Install ZooKeeper

Before you begin

You must perform the following task before you install ZooKeeper:
• “Configure [Link] for high availability” on page 419

Procedure
1. Download version 3.4.x from the Apache ZooKeeper web site. Here, x is at least 6 for versions of
PolicyCenter that are less than 9.0.5. For versions of PolicyCenter that are greater than or equal to 9.0.5, x is at
least 10. Do not use a ZooKeeper version that is version 3.5 or higher.
2. On each host where you want to run the Guidewire Solr Extension for high availability, create an installation
directory to use as the ZooKeeper home directory. For example:
• On Unix – /opt/zoo
• On Windows – C:\opt\zoo
Configuring search functionality 419
Guidewire PolicyCenter 9.0.9 Configuration Guide

3. Install the ZooKeeper software in the directory that you created. In addition, create a directory for the
ZooKeeper server to store its data. For example:
• On Unix – /opt/zoo/data
• On Windows – C:\opt\zoo\data

Next steps
You must now perform the following task:
• “Configuring [Link] ” on page 420

Configuring [Link]
In [Link], you configure a single ZooKeeper member server. Each ZooKeeper member within an ensemble has its
own copy of [Link]. The [Link] file configures a ZooKeeper server with its client port. PolicyCenter and the
Guidewire Solr Extension connect through the client port to the ZooKeeper server and the ensemble. The file also
lists the members of the ensemble, including their host names and ensemble ports. The members of the ensemble
connect with each other through the ensemble ports.
Important parameters that you can specify in [Link] include the following:
• tickTime – Unit of time in milliseconds for heartbeats and other timing parameters.
• initLimit – Timeout limit for followers to connect to a leader.
• syncLimit – How far out of date a follower can be from a leader.
• dataDir – Location to store the ZooKeeper coordination database, the transaction logs, and the myID file that
specifies the ordinal number for the server within the ensemble. For example:
◦ On Unix – /opt/zoo/data
◦ On Windows – C:\opt\zoo\data
The directory stores only ZooKeeper data and client-uploaded data. The latter data includes the SolrCloud global
configuration and the core configuration. Otherwise, the directory stores no Guidewire Solr Extension data.
• dataLogDir – Location to store the transaction logs. If you do not specify dataLogDir, the server stores
transaction logs in the directory specified by dataDir. To reduce latency on updates, use dataLogDir to specify
a logging directory on a dedicated logging device.
• clientPort – The port on which to listen for connection requests from PolicyCenter and Guidewire Solr
Extension servers. The value for clientPort must match the port specified for the server in the zkhosts
parameter of [Link]. The port defaults to 2181 in both [Link] and solrserver-
[Link].
• server.N – For each member of a ZooKeeper ensemble, its host name, its ensemble port for peer
communication, and its ensemble port for leader election. A member server finds its ensemble ports in the
membership list by matching N with the numerical value in the myID file, located in the directory specified by
dataDir.
The following example [Link] file configures an ensemble of three SolrCloud servers in a ZooKeeper ensemble.
Each server runs on its own host, so all members listen for connections from PolicyCenter through the same client
port. The parameter clientPort is commented out in the example because port 2181 is the default. Because each
member server is on its own host, they all use the same ensemble ports for peer communication and leader election.
Such ensemble ports can include 2888 and 3888.
tickTime=2000
initLimit=10
syncLimit=5
dataDir=/opt/zoo/data
# clientPort=2181
server.1=gwsolr1:2888:3888
server.2=gwsolr2:2888:3888
server.3=gwsolr3:2888:3888

You can find a copy of [Link] in Studio by navigating in the Project window to configuration→config→solr.
Generally, the members servers in a ZooKeeper ensemble use the same copy of the file. Use the copy in Studio as
you master copy and deploy it yourself to the ZooKeeper home directory on the host of each member server.
420 chapter 28: Configuring search functionality
 Guidewire PolicyCenter 9.0.9 Configuration Guide

myID
Each ZooKeeper member server has an assigned ordinal number. The myID file for each member specifies its ordinal
number.
The myID file is an ASCII text file that resides in the directory specified by the dataDir parameter in the [Link].
For example, store each version of myID in the following directory:
• On Unix – /opt/zoo/data
• On Windows – C:\opt\zoo\data
The member server uses the ordinal number in its myID file to locate its assigned ensemble ports in its copy of
[Link].

See also
• For complete information on configuring and administering a SolrCloud cluster in a ZooKeeper ensemble,
consult the Apache Solr and ZooKeeper documentation at the following respective links:
[Link]
[Link]

Communicating with Guidewire Solr Extension in high availability

The following diagram illustrates the communicative arrangement of a PolicyCenter cluster, a ZooKeeper ensemble,
and a cluster of SolrCloud servers. An arrow in the diagram represents a connection route for opening a select port
with a select protocol:

PolicyCenter Cluster Zookeeper Ensemble

PC 1 ZK 1 TCP:
2888,
TCP: 2181 3888

PC 1 PC 1 ZK 2 ZK 3

SolrCloud Server Cluster

TCP: 2181
HTTP(S): 8983
HTTP(S):
8983
Solr 1 Solr 4

Solr 2 Solr 3

Configuring the Guidewire Solr Extension for secure transport (HTTPS)

You can configure PolicyCenter and the Guidewire Solr Extension to use the Hypertext Transfer Protocol Secure
(HTTPS) communication protocol to exchange data. By default, PolicyCenter and the Guidewire Solr Extension use
the unsecured HTTP protocol to exchange data. HTTPS provides a more secure exchange of data than HTTP by
Configuring search functionality 421
Guidewire PolicyCenter 9.0.9 Configuration Guide

authenticating the PolicyCenter and Guidewire Solr Extension web sites and associated web servers before
connecting to exchange data. In addition, HTTPS provides bidirectional encryption of exchanged data.
The way you configure PolicyCenter and the Guidewire Solr Extension to use HTTPS depends on the way you
configure the Guidewire Solr Extension for external operation:
• HTTP – Configures a single instance of the Guidewire Solr Extension that runs externally from the application
server in which PolicyCenter runs
• Cloud – Configures a cluster of Guidewire Solr Extension instances, managed as a cluster, or ensemble, by
Apache ZooKeeper
With secure transport enabled, HTTPS authentication and encryption apply to indexing, querying, administration,
and the free-text batch load command.

HTTP Configuration for secure transport (HTTPS)

To configure PolicyCenter and a single instance of the Guidewire Solr Extension to use secure transport, set the
securetransport parameter in [Link] to true. The securetransport parameter is valid for
servers of type http only.
The following example configures a single instance of the Guidewire Solr Extension for secure transport with the
HTTPS communication protocol.
<solrserver name="https" type="http">
<param name="host" value="localhost"/>
<param name="port" value="8983"/>
<param name="securetransport" value="true"/>
</solrserver>

PolicyCenter inserts a host property in [Link], in the following format, whenever you run the gwb packageSolr
command:
<str name="host">${serverHost:[Link]}</str>

Note: If you modify [Link] manually for any reason, PolicyCenter no longer inserts a host
property when you run the gwb packageSolr command.
The base configuration of PolicyCenter does not include [Link]. To create a [Link] file to edit in Studio or to
retain changes that you make to [Link] in GWSOLR_HOME/pc/solr, copy the file in GWSOLR_HOME/pc/solr. In
PolicyCenter Studio, navigate in the Project window to configuration→config→solr, and then, from the menu, click
Edit→Paste.
PolicyCenter uses host number [Link] by default for locally hosted instances of the Guidewire Solr Extension.
For remotely hosted instances, override the value in the JVM where PolicyCenter runs using the serverHost system
property. For example, if your application server is Tomcat, create or edit the shell script [Link] or, on
Windows, the batch file [Link] in the directory Tomcat_Home/bin. Then, add the following line:
set JAVA_OPTS=%JAVA_OPTS% -DserverHost=mySolrHost

If HTTPS is configured for a port other than 8983, which is the standard port for the Guidewire Solr Extension,
change the port definition in [Link]. Change the port definition in [Link] before you start instances of the
Guidewire Solr Extension for the first time. Alternatively, start the application server with the -DserverPort=####
option.
Run the gwb packageSolr command after you modify free-text search configuration files in Studio to produce an
updated [Link] file to deploy to the Guidewire Solr home directory.

Cloud configuration for secure transport (HTTPS)

To configure PolicyCenter and a cluster of Guidewire Solr Extension instances, managed as a cluster or ensemble by
Apache ZooKeeper, requires no changes to free-text search configuration files like [Link].
Instead, PolicyCenter provides Guidewire versions of the ZooKeeper command line interface, shell script
([Link]) and batch file ([Link]). These command files are located in the following deployment
directory:
/opt/gwsolr/pc/scripts

422 chapter 28: Configuring search functionality

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Use the gwzkcli -zkhost command to set the secure flag that enables the Guidewire Solr Extension instances for
secure transport. Use the command after you deploy the Guidewire Solr Extension and the ZooKeeper software to
hosts where you want them to run. Then, before you start the Guidewire Solr Extension on a host for the first time,
run the gwzkcli -zkhost command as the following example shows:
• On Unix
gwzkcli -zkhost localhost:2181 -cmd put /pc/[Link] {"urlScheme":"https"}

• On Windows
gwzkcli -zkhost localhost:2181 -cmd put /pc/[Link] {\"urlScheme\":\"https\"}

If you started an instance of the Guidewire Solr Extension before running the preceding command, run the following
commands to reset that instance:
gwzkcli -zkhost clear /pc
gwzkcli -zkhost localhost:2181 -cmd put /pc/[Link] {\"urlScheme\":\"https\"}
gwzkcli -Dbootstrap_conf=true

Public key certificates

You must configure the application servers in which PolicyCenter and the Guidewire Solr Extension run with public
key certificates. The HTTPS protocol uses these certificates to authenticate the PolicyCenter and the Guidewire Solr
Extension instances when they open connections with each other. The application servers for each instance of
PolicyCenter and each instance of the Guidewire Solr Extension need their own private keys. In addition, the
application servers each need all the public keys from all the servers in their clusters.
See the documentation for your brand of application server to learn how to manage the certificates required by the
HTTPS protocol.

Batch load command

When you configure the Guidewire Solr extension for secure transport, you also must enable the batch load
command to use secure transport. The batch load command runs on a host where you deployed the Guidewire Solr
Extension. You must configure the Java VM on startup on that host with the location and password for the local trust
store.
For example, you can add the following options to the Java command at end of the shell script ([Link]) or
batch file ([Link]) for the batch load command.
-[Link]=pathToTrustStore -[Link]=password

For improved security, prompt the user for the trust store password instead of including it directly in the shell script
or batch file.
You can locate and edit the shell script or batch file for the batch load command in the Project window in Studio by
navigating to configuration→config→solr.

Configuring free‐text search for indexing and searching

The following files configure how free-text search and the Guidewire Solr Extension operate together to index and
search for policies.
• [Link] – Defines search fields as known in the Guidewire Solr Extension
• [Link] – Defines the mapping between PolicyCenter fields and full-text search fields and
configures how the full-text fields are indexed and searched
• [Link] – Used by the Guidewire Solr Extension at startup to locate the Guidewire Solr home
directory
These files are pre-configured in the base configuration to index and search policy data. You do not need to modify
these files unless you want to change the default set of search fields or their behaviors. The files also contain
connection-related parameters that you set at the time you initially install and set up free-text search.
Configuring search functionality 423
Guidewire PolicyCenter 9.0.9 Configuration Guide

See also
• “Modifying free-text search for additional fields” on page 426
• Installation Guide

Configuring the free‐text batch load command

The configuration and support files for the free-text batch load command and the command itself are located in the
following directory on the host where the Guidewire Solr Extension resides.
opt/gwsolr/pc/solr/policy_active/conf

The following files configure the free-text batch load command:

• [Link]/[Link] – Specifies the batch load configuration file to use for your database brand.
• [Link] – Defines the connection to the relational database that the free-text
batch load command uses to query for policy data, as well as other system resources that the command requires.
In addition, the batch load configuration file contains the native SQL Select statements that the batch load
command uses to extract data from the PolicyCenter database.

Initial Configuration of the Free‐text Batch Load Command

Generally, you configure the free-text batch load command when you first install and set up free-text search.
Afterward, you need to modify your initial configuration only if resources in your computing environment change,
such as the connection to your database.

SQL Select Statement Configuration for the Free‐text Batch Load Command
The free-text batch load command extracts data from the PolicyCenter database by using native SQL. The native
SQL Select statements that the batch loader uses are defined in configuration files for specific database brands. The
configuration files that contain native SQL are:
• For H2 databases – [Link], suitable only for development
• For Oracle databases – [Link], suitable for development or production
• For SQL Server databases – [Link], suitable for development or production
You do not need to modify the native SQL when you first set up and configure the free-text batch load command.
The native SQL correctly selects data for the search fields in the default configuration of free-text search. You must
modify the native SQL only when you want to extend or modify the search fields for your configuration of free-text
search.

See also
• “Modifying free-text search for additional fields” on page 426
• Installation Guide

Configuring the basic search screen for free‐text search

The following table provides implementation details for each field on the Search Policies→Basic screen. The columns
contain the following information:
• Field – The field on the Search Policies→Basic screen.
• Entity – The entity type of the object that corresponds to this field.
• Search type – Exact or inexact depending upon the search type.
• Revisioned – The marked cells indicate a revisioned field in which the contents can vary over time.
Use this information to help configure the Basic screen for free-text policy search.
424 chapter 28: Configuring search functionality
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Field Entity Search type Revisioned

Policy Number PolicyPeriod Inexact •
Name PolicyContactRole subtype of: Inexact
• PolicyPriNamedInsured
• PolicyAddlNamedInsured
Street PolicyAddress Inexact •
City PolicyAddress Inexact •
State PolicyAddress Exact •
Postal Code PolicyAddress Exact •
Phone Accessing the Contact through the [Link] field, Exact
get the phone number from the following fields:
• HomePhone
• PrimaryPhone
• FaxPhone
• WorkPhone
ID Number Accessing the Contact through the [Link] field, Exact
get the ID number from the following fields:
• FEINOfficialID
• SSNOfficialID
Underwriting Company PolicyPeriod Exact
Product Policy Exact
Jurisdiction PolicyPeriod Exact •
Producer of Record [Link] Exact
Producer Code [Link] Exact •
In Force On Date Across multiple PolicyPeriod objects Exact

Limits on the number of free‐text search results

You can limit the number of free-text search results returned from the Guidewire Solr Extension in two ways:
• Limit the number of free-text search results returned
• Set the number of free-text search results per page

Limiting the Number of Free‐text Search Results Returned

The ISolrSearchPlugin plugin implementation limits the number of results that the Guidewire Solr Extension
returns to PolicyCenter. You may want to increase or decrease the default value of 100 result items. Change the
default by editing the ISolrSearchPlugin plugin registry to change the fetchSize parameter.

Setting the Number of Free‐Text Results per Page

In the default configuration for free-text search, the basic search displays 10 search results per page. You can
configure the number of search results per page by modifying the pageSize property on the page configuration file.
Regardless of the number of results that you configure, users can change the page size to suit their needs after
PolicyCenter displays the first page of results.
For basic policy search, modify the SolrPolicySearchPanelSet page configuration file. View and edit the file in
the Project window in Studio by navigating to Page Configuration (PCF)→search→SolrPolicySearchPanelSet.
Configuring search functionality 425
Guidewire PolicyCenter 9.0.9 Configuration Guide

See also

• Integration Guide

Modifying free‐text search for additional fields

You can modify the configuration of free-text search in many ways. For example, you can add or remove fields for
search criteria, modify how fields are stored in the Guidewire Solr Extension, and configure how fields are matched
to search criteria. For complete information on how to modify the Guidewire Solr extension, consult the online
documentation for Apache Solr 4.
This section shows by example the configuration files that you typically modify to change how the Guidewire Solr
Extension loads, indexes, and searches data. The example is a simple configuration change to add a field to free-text
search.

IMPORTANT Adding multi-valued fields can affect free-text search performance. In particular, adding
fields with too many values significantly degrades full-text search performance.

Configuration files for full‐text loading, indexing, and searching

Typically, you modify the multiple files to configure the way the Guidewire Solr extension loads, indexes, and
searches information in the Guidewire Solr Extension. Specific files configure each component of the extension.
The following table lists the configuration files for PolicyCenter:

Configuration file Description

[Link] Defines the mapping between PolicyCenter fields and Guidewire Solr Extension, and
configures how the Guidewire Solr Extension indexes and searches its index docu‐
ments.
PolicyCenter/modules/configuration/config/search/
policy‑search‑[Link]

[Link] The implementation class for the free‐text plugin ISolrSearchPlugin. This plugin
sends search criteria to the Guidewire Solr Extension and receives the search results.
PolicyCenter/modules/pc/gsrc/gw/solr/[Link]

PCSolrMessageTransportPlugin The implementation of ISolrMessageTransportPlugin. This plugin sends update

messages to Guidewire Solr Extension when entities in the Guidewire Solr Extension
index undergo changes in the PolicyCenter database.
[Link] (IndexingSystem Rules file containing a top level rule that defines which entities and which events on
rule) those entities are of interest to Guidewire Solr Extension. This is the point of
creation for the messages that the associated ISolrMessageTransportPlugin
instance sends.

The following table lists the configuration files for Guidewire Solr Extension.

Configuration Description More information

file
[Link] Defines the document schema structure for [Link]
the Guidewire Solr Extension. Provides gener‐ [Link]
al configuration for how Guidewire Solr Ex‐ guide/[Link]
tension uses a document, the index definition
for a document, and the analyzers available
for index assignment or usage.
/opt/gwsolr/pc/solr/policy_active/conf/[Link]

426 chapter 28: Configuring search functionality

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Configuration Description More information

file
data- Defines where to locate and how to interpret [Link]
[Link] data from the batch load command. Set to DataImportHandler#Configuration_in_data-
read‐only mode at start‐up. [Link]-1

/opt/gwsolr/pc/solr/policy_active/conf/data‑[Link]

The following table lists the configuration files for the free-text batch load command.

Configuration file Description

[Link] | [Link] Represents the batch load command.
/opt/gwsolr/pc/solr/policy_active/conf/[Link]

batchload-config- Contains database connection information and brand‐specific native SQL for selecting
[Link] data from the PolicyCenter relational database.
/opt/gwsolr/pc/solr/policy_active/conf/[Link]

[Link] | [Link] Collates and compiles index documents for the Guidewire Solr Extension using data
selected from the relational database.
/opt/gwsolr/pc/solr/policy_active/conf/[Link]

Sequence of steps for adding a field to free‐text search

Perform these high-level steps to configure free-text search with an additional field. The examples in the following
topics add a policy postal code as a free-text field.

IMPORTANT The PolicyCenter base configuration does not support free-text search of entity types
other than policies and submissions. The addition of such free-text search fields is a complex
endeavor. When engaging in all such endeavors, proceed with competence and care. Guidewire will
support customers in their development of additional search types.

Defining a new free‐text field in the Guidewire Solr Extension

Use the following file to define a new free-text field in the Guidewire Solr Extension.
/opt/gwsolr/pc/solr/policy_active/conf/[Link]

The Guidewire Solr Extension defines the format of this file.

The schema configuration file contains <field> elements, one for each full-text field of the index documents in the
Guidewire Solr Extension.
The following example defines a full-text field that stores postal codes.
<field name="postalCode" type="gw_unanalyzed" indexed="true"
stored="true" required="false"
multiValued="false"/>

The definition directs the Guidewire Solr Extension to index the values of postal code fields, so search criteria can
include postal codes. The definition directs the Guidewire Solr Extension to store the values of postal code fields, so
items returned in search results include them.
The type attribute in the preceding definition identifies the analyzer with which Guidewire Solr Extension processes
postal code fields. The analyzer type indicates the category of matches that are possible on applicable search fields.
In this case, a value for the type attribute of gw_unanalyzed indicates that postal codes are raw text fields and that
Guidewire Solr Extension does not analyze them. Given this value, only exact matches are possible for searches on
the values of postal code fields.
Configuring search functionality 427
Guidewire PolicyCenter 9.0.9 Configuration Guide

Defining a new free‐text field in PolicyCenter

Use the following file to define a new free-text field in PolicyCenter.
PolicyCenter/modules/configuration/config/search/[Link]

Access the file in the Project window in Studio by navigating to configuration→config→search policy-search-
[Link]. PolicyCenter defines the format of this file.
Free-text search configuration files have these main elements:
• <Indexer> – Contains <IndexField> elements to define field names and their locations within object graphs of
the root object and in the index documents sent to the Guidewire Solr Extension.
• <Query> – Contains the following types of elements:
◦ <QueryTerm> elements define how specific fields are matched and how a match contributes to the overall
score. A query term is one of two types: term and subquery. A term type searches a single index for a single
field. A subquery type searches multiple indices for multiple fields simultaneously and scores the most
appropriate match.

IMPORTANT Do not confuse the term type query term with the subquery type query term. A
subquery type can search multiple indexes for multiple fields. A term type can only search one
index for a single field. An XSD only validates the structure of a query. The XSD does not
validate the inputs for a term type. Thus, if you attempt to enter multiple terms in a term type, the
XSD will not catch this error. Instead, the platform will throw a run-time exception.

◦ <FilterTerm> elements restrict Guidewire Solr Extension from returning a result if a field in that result
matches given search criteria. The elements do not affect the score of any results. Instead, they help users to
limit the results that a search returns, such as by a date range. The elements can also facilitate security by
controlling the results that users receive.
• <QueryResult> – Contains <ResultProperty> elements to configure whether and how specific fields are
returned in query results from the Guidewire Solr Extension.
To add a free-text field to [Link], first add an <IndexField> element to the <Indexer>
element. The following example defines a free-text field for postal codes.
<IndexField field="postalCode">
<DataProperty path="[Link]"/>
</IndexField>

The definition specifies that values of postalCode fields in the index documents sent to the full-text engine come
from addresses on policy periods, the root object.
Next, add <FilterTerm> elements for the new free-text field to the <Query> element. The following example
specifies how the Guidewire Solr Extension matches PostalCodeCriteria values in search criteria with
postalCode values in the Guidewire Solr Extension.
<FilterTerm>
<DataProperty path="[Link]"/>
<QueryField field="postalCode"/>
</FilterTerm>

The definition directs the Guidewire Solr Extension to accept postal codes in search criteria and where to find them
in the XML structure of the search criteria.
Finally, add a <ResultProperty> element to the <QueryResult> element. The following example defines how the
Guidewire Solr Extension returns postalCode values in query results.
<ResultProperty name="PostalCode">
<ResultField name="postalCode"/>
</ResultProperty>

The definition assigns the postalCode value in the result to the PostalCode on the result object.

428 chapter 28: Configuring search functionality

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Defining a new free‐text field in the batch load command

To load data from an existing PolicyCenter database, the new free-text field must be listed in the batchload-
config-database [Link] files and the [Link] file. You decide whether to include or exclude the
field from the digest that prevents duplicate index entries.

Generating the SQL Query

Add the new free-text field in the SELECT portion of the query that corresponds to the data. The SQL for postal
codes looks like following sample SELECT statement.
SELECT DISTINCT
...
[Link]
...
FROM pc_policyperiod AS pp
...
INNER JOIN pc_policyaddress paddr
ON [Link] = [Link]
...
INNER JOIN pc_address addr
ON [Link] = [Link]
...
WHERE
...
AND ([Link] IS NULL OR [Link] &lt;= [Link] )
AND ([Link] IS NULL OR [Link] &gt; [Link] )
...

You duplicate this change in [Link], [Link], and

[Link]. Each database brand uses a separate configuration file because the syntax of the SQL
Select statement for each database is slightly different.
Note: Because the SQL is included in an XML file, you must escape the less than (<) symbol as
“&lt;” and the greater than (>) symbol as “&gt;”. Do not include the quotation marks in the escape
sequence.
The query is processed into an XML document that will be loaded into SQL. Batch loading of XML into Solr is
described in [Link]
The processed field names are all in upper case, and the structure of the XML document is:
<CONTAINER_ELEM>
<POLICY>
<!-- data for one policy -->
</POLICY>
</CONTAINER_ELEM>

To include the postalCode in the index, put an entry in [Link] that looks like the following XML code:
<field column="postalCode" xpath="/CONTAINER_ELEM/POLICY/POSTALCODE"/>

Within the row for one policy, the fields will be in the same order as they were returned by the SELECT statement.
You can have fields in the SQL result that do not become part of the XML of the index documents. The Guidewire
Solr Extension ignores such fields when it loads the SQL result. These fields are not part of the index document
schema. The batch load command uses these kinds of fields to sort and manipulate the data returned from the
database to XML to produce the final XML index documents to load.

Computing the Hash Value to Eliminate Duplicates

To avoid a chain of policy changes or renewals generating identical, duplicate index entries, the Guidewire Solr
Extension makes an SHA-1 hash value of most of the index data. This hash value is included in the URN (Unique
Record Name) of the index entry. Entries on the same policy and with the same SHA hash value are collapsed into a
single entry.
First, you decide whether the field is part of the hash value. If so, you must modify the file
[Link] to include that data in the digest when generating a new index entry. The free-text batch
load command includes fields by default.
To include a new field in the hash value requires one line of Gosu code:
Configuring search functionality 429
Guidewire PolicyCenter 9.0.9 Configuration Guide

[Link]("postalCode", [Link])

If this field is not part of the hash value, you must make the batch load command ignore the field for digest
purposes. An example of such a field is sliceDate. The configuration for the digester is near the bottom of the
batchload-config-database [Link] files. The sliceDate column is among the columns to ignore.
<transformer
name="digestTransformer"
class="[Link]"
ignoreElems="urn, periodID, policyPublicID, sliceDate, periodStart, periodEnd, policyStart,
policyEnd, periodIdWithSliceDate, jobType"
algorithm="SHA"
/>

For default columns, include this field in [Link] as well.

static function initXformer() : [Link] {
try {
var xml =
"<transformer name=\"digestTransformer\"
class=\"[Link]\""
+ " algorithm=\"SHA\""
+ " ignoreElems=\"urn, periodID, policyPublicID, sliceDate, periodStart, periodEnd, ""
+ " policyStart, policyEnd, periodIdWithSliceDate, jobType\"/>";
var xf = new [Link](false)
var doc = [Link](xml)
[Link]([Link]())
}
}

The final stage to the de-duplication is in the postprocess script. The postprocess script sorts the data by a
combination of URN, slice date, and term number. The script then removes rows with duplicate urn values. Slice
date and term number are used in the initial sort to retain the latest version of the duplicate data, which is the same
way that PolicyCenter indexes the data.

Localizing free‐text search

The base configuration of free-text search operates linguistically only on U.S. English words and phrases. To
configure free-text search for languages other than U.S. English, view the Apache Solr Language Analysis page at
the following address:
[Link]

430 chapter 28: Configuring search functionality

chapter 29

Configuring special page functions

This topic describes how to configure special functionality related to pages.

Note: The code samples included in this topic assume that you are using the ClaimCenter application.
Any listed data model objects or fields are specific to that application. However, the features
documented in this topic are universal to all Guidewire applications.

Adding print capabilities

You can customize the print functions on the PolicyCenter interface. This section explains the print capabilities and
how to use them.

Overview of print functionality

You can use the PolicyCenter print functionality to print the list view parts of the data visible on a PolicyCenter
screen. For example, you can print object lists such as the Activities list on the Desktop. You can control both the
output format and which list view objects are printed. Most commonly, pages print as PDF. PolicyCenter also
supports a limited comma-separated values (CSV) format. You can send the output of a print action to a local printer
or save it to disk.
To support printing, a client computer must have a supported version of Acrobat Reader available.

Configuration parameters related to printing

The following optional print parameters in [Link] control the default print settings globally. For information
on configuration parameters, see “Application configuration parameters” on page 41.

DefaultContentDispositionMode Specifies the Content‐Disposition setting to use if the content to be printed is returned to
the browser. Must be either “attachment” (the default) or “inline”.
PrintFontFamilyName Sets the name of font family to use for output. The default is “sans‐serif”.
PrintFontSize Sets the page font size. The default is 10 points.
PrintFOPUserConfigFile (Optional) Sets the fully qualified path to a valid FOP user configuration file. Use this to
specify or override the default FOP configuration.
PrintHeaderFontSize Sets the header’s font size. The default is 16 points.
PrintLineHeight Specifies the line height. The default is 14 points.
PrintListViewBlockSize Sets the block size of the list elements if printing a list with elements.

Configuring special page functions 431

Guidewire PolicyCenter 9.0.9 Configuration Guide

PrintListViewFontSize Sets the font size for printing list views. The default is 10 points.
PrintMarginBottom Sets the bottom margin. The default is .5 inches.
PrintMarginLeft Specifies the size of left margin. The default is 1 inch.
PrintMarginRight Specifies the size of right margin. The default is 1 inch.
PrintMarginTop Specifies the size of top margin. The default is .5 inches.
PrintMaxPDFInputFileSize Sets the size of the intermediate XML file to create if printing to PDF.
PrintPageHeight Specifies the height of the page. The default is 8.5 inches.
PrintPageWidth Specifies the width of the page. The default is 11 inches.

You can modify any of the page formatting attributes using property values defined in the CSS2 specification. The
specification resides at the following location: [Link]

Security related to printing

The system permission lvprint allows a user to print the information that appears in a list view. .

Gosu classes for printing

The Gosu package [Link] provides classes that support print functionality. Guidewire recommends that your
print configurations use only the ListViewPrintOptionPopupAction and PrintSettings classes.

Types of printing configuration

To add print capabilities to a PCF page you must decide which type of printing you require. You can configure the
following types of printing behaviors in PolicyCenter:
• List view printing that prints a list in PDF or CSV format

List view printing

List view printing supports choosing the output format delivered by the Print button. If you choose to print a list in
comma-separated values (CSV) format, you can also choose which columns to print. For example, on the Desktop
Activities page, the Print/Export button uses list view printing to provide three print options.
The action attribute of the ToolbarButton element supports list view printing. Set the value of the action attribute
to a Gosu expression that calls the printListViewWithOptions method. The following example code implements a
list view printing button:
<ToolbarButton
action=[Link](&quot;MyListView&quot;)"
id="PrintButton"
label="[Link](&quot;[Link]&quot;)"/>

Linking to a specific page using an EntryPoint PCF

It is possible to connect directly to PolicyCenter using a URL that leads to a specific PolicyCenter page. You can
define your own links or entry points. Thus, if the PolicyCenter server receives a connect request from an external
source and the request has both the correct format and parameters, PolicyCenter serves the requested page.
In the base configuration, PolicyCenter provides a number of EntryPoint PCF examples. You can find these in the
following location in Studio:
configuration→config→Page Configuration→pcf→entrypoints
These PCF pages are examples only. If you use one, you must customize it to meet your business needs. You can
also use them as starting points for your own EntryPoint PCF pages.
432 chapter 29: Configuring special page functions
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Entry points
An entry point takes the form of a URL with a specific syntax. The entry URL specifies a location that a user enters
into the browser. If the PolicyCenter server receives a connection request with a specific entry point, PolicyCenter
responds by serving the page based on the entry point configuration.
To implement this functionality, you must create an EntryPoint PCF (in the entrypoints folder). The following
graphic illustrates an EntryPoint PCF.

The EntryPoint PCF contains the following parameters:

authenticationRequired Specifies that PolicyCenter must authenticate the user before the user can access the URL. If true,
PolicyCenter requires that the user already be authenticated to enter. If the user is not already
logged in, PolicyCenter presents a login page before rendering the entry point location.
The default is true. Guidewire strongly recommends that you think carefully before setting this
value to false.
clearSession If true, clears the server session for this user as the user enters this entry point
desc Currently, does nothing.
failurePage Specifies the page to send the user if PolicyCenter cannot display the entry point. Failures typically
happen any time that the data specified by the URL does not exist. The default is Error.
id Required. The PolicyCenter uniform resource identifier to show, minus its .do suffix. Typically, this
is the same as the page ID. No two EntryPoints can use the same URI. Do not use the main
application name, PolicyCenter, as the URI.
For example, if the URI is XXX, then it is possible to enter the application at [Link]
myapp/[Link].

location Required. The ID of the page, Forward, or wizard to which you want to go. Guidewire recommends
that if you want the entry point to perform complex logic, use a Forward.
See “Create a Forwarding EntryPoint PCF” on page 434 for a definition of a forward.

Each EntryPoint PCF can contain one or more EntryPointParameter subelements that specifies additional
functionality.

Configuring special page functions 433

Guidewire PolicyCenter 9.0.9 Configuration Guide

The EntryPointParameter subelement has the following attributes:

conversionExpression Gosu expression that PolicyCenter uses to convert a URL parameter to the value passed to the loca‐
tion parameter.
desc Currently, does nothing.
locationParam Required. The name of the LocationParameter on the EntryPoint target location that this parame‐
ter sets.
optional Specifies whether the parameter is optional. If set to true, PolicyCenter does not require this param‐
eter.
type Required. Specifies what type to cast the incoming parameter into, such as String or Integer.
urlParam The name of the parameter passed with the URL. For example, if the urlParam is Activity and the
entry point URI is ActivityDetail,you would pass Activity 3 as:
[Link]

Create a Forwarding EntryPoint PCF

About this task
A forward is a top-level PCF location element similar to a page or wizard. However, it has no screen. It merely
forwards you to another [Link] define a forward separately from the EntryPoint PCF. However, you set the
forward for a PCF in the EntryPoint PCF location attribute.
Suppose that there are several destinations to which you wish the user to go. In this case, consider passing a
parameter to the entry point forward, so you can have the seamless login logic all in that one place.

Procedure
1. Define a separate entry point (PCF) with authenticationRequired property set to false. This PCF is
effectively a forwarding page to handle the seamless login.
2. Set the location attribute of the entry point to use a Forward to call the AuthenticationServicePlugin.
3. Do one of the following:
• If the plugin login is successful, forward the user onto the actual page (the desktop, for example) to which
you intended to send the user in the first place. (This is the page to which the user would have gone if
authenticationRequired had been set to true.)
• If the plugin login is not successful, redirect the user to an error page or an alternate login page.
434 chapter 29: Configuring special page functions
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Example
For an example of how to define a forward, see ActivityForward in PolicyCenter Studio at
pcf→activity→ActivityForward.

Linking to a specific page using an ExitPoint PCF

It is possible to create a link from a PolicyCenter application screen to a specific URL. This URL can be any of the
following:
• A page in another Guidewire application
• A URL external to the Guidewire application suite
You provide this functionality by creating an ExitPoint PCF file and then using that functionality in a PolicyCenter
screen.
In the base configuration, PolicyCenter provides a number of ExitPoint PCF examples. You can find these in the
following location in Studio:
configuration→config→Page Configuration→pcf→exitpoints
Note: These PCF pages are examples only. If you use one, Guidewire expects you to customize it to
meet your business needs. You can also use them as starting points for your own ExitPoint PCF
pages.

Creating an ExitPoint PCF

The following example takes you through the process of creating a new exit point PCF and then modifying a
PolicyCenter interface screen to use the exit point. It does the following:
• Step 1 creates a new ExitPoint PCF page with the required parameters.
• Step 2 modifies the Activity Detail screen by adding a new Dynamic URL button. If you click this button, it opens a
new popup window and loads the Guidewire Internet home page into it.
• Step 3 tests your work and verifies that the button works as intended.
It is possible to use any action attribute to activate the ExitPoint PCF. This example uses a button input as it is the
easiest to configure and test. This example pushes the URL to a popup window that leaves the user logged into
PolicyCenter. You can also configure the ExitPoint PCF functionality to log out the user or to possibly reuse the
current window.

Step 1: Create the ExitPoint PCF file

About this task

The first step is to create a new ExitPoint PCF file and name it AnyURL.

Procedure
1. In Guidewire Studio, in the Project tool window, navigate to configuration→config→Page
Configuration→pcf→exitpoints.
2. Right-click exitpoints, and then click New→PCF File.
3. In the New PCF File dialog, in the File name text box, type AnyURL.
4. In the File type list, click Exit Point.
5. In the [Link] file editor, click the Exit Point box.
6. In the Properties tab at the bottom of the window, set the following properties:
7. Select the AnyURL file, so that Studio outlines the ExitPoint element in blue.
Configuring special page functions 435
Guidewire PolicyCenter 9.0.9 Configuration Guide

8. Select the Properties tab at the bottom of the screen and set the listed properties. This example pushes the URL
to a popup window that leaves the user logged into PolicyCenter. You can also configure the ExitPoint PCF
functionality to log out the user or to possibly reuse the current window.
• logout – false
• popup – true
• url – {exitUrl}
9. Click the Entry Points tab, and then click Add .
10. In the signature text box, type the following entry point signature:
AnyURL(url : String)
11. In the Toolbox, expand the Special Navigation node, click the Exit Point Parameter widget, and drag it into your exit
point PCF.
12. Select the Exit Point Parameter widget and enter the following in its Properties tab:
• locationParam – url
• type – String
• urlParam – exitUrl

Next steps
After completing this task, complete “Step 2: Modify the user interface screen to use the exit point” on page 436.

Step 2: Modify the user interface screen to use the exit point
Before you begin
Before beginning this task, complete “Step 1: Create the ExitPoint PCF file” on page 435.

About this task

After you create the ExitPoint PCF, you need to link its functionality to a PolicyCenter screen. The Activity Detail
screen contains a set of buttons across the top of the screen. This example adds another button to this set of buttons.
It is this button that activates the exit point.

Procedure
1. In Guidewire Studio, create a new [Link] display key. You need this display key as a
label for the button that you create in a later step.
a. Open the Display Key editor and navigate to Button→Activity.
b. Select the Activity node, right-click and select Add.
c. Enter the following in the Display Key Name dialog:
• Display Key Name — [Link]
• Default Value — Dynamic URL
2. Open the PCF for the page on which you want to add the exit point. For the purposes of this example, open the
ActivityDetailScreen PCF file.
Note: The simplest way to find a Studio resource is to press CTRL+N and enter the resource
name.
3. Select the entire ActivityDetailScreen element on the PCF page. Studio displays a blue border around the
selected element.
4. In the Code tab at the bottom of the screen, enter the following as a new function:
// This function must return a valid URL string.
function constructMyURL() : String { return "[Link] }

You can make the actual function as complex as you need it to be. The function can also accept input
parameters as well. The only stipulation is that it must return a valid URL string.
436 chapter 29: Configuring special page functions
 Guidewire PolicyCenter 9.0.9 Configuration Guide

5. In the Toolbox for the PCF page that you just opened, find a Toolbar Button widget and drag it into the line of
buttons at the top of the page.
6. Select the new button widget so that it has a blue border around it.
7. Select the Properties tab at the bottom of the screen and set the listed properties. It is possible to use any action
attribute to activate the ExitPoint PCF. This example uses a button input as it is the easiest to configure and
test.
• action – [Link](constructMyURL())
• id – DynamicURL
• label – [Link]

Next steps
After completing this task, complete “Step 3: Test your work” on page 437.

Step 3: Test your work

Before you begin
Before beginning this task, complete “Step 2: Modify the user interface screen to use the exit point” on page 436.

About this task

After completing the previous steps, you need to test that the button you added to the Activity Detail screen works as
you intended.

Procedure
1. Start the PolicyCenter application server, if it is not already running. It is not necessary to restart the
application server as you simply made changes to PCF files. You did not actually make any changes to the
underlying PolicyCenter data model, which would require a server restart.
2. Log into PolicyCenter using an administrative account.
3. Press Alt+Shift+T to open the Server Tools screen. This screen is only available to administrative accounts.
4. Choose Reload PCF Files in the Internal Tools→Reload screen. PolicyCenter presents a success message after it
reloads the PCF files from the local file system.
5. Log into PolicyCenter under a standard user account and search for an activity. The Activity Detail screen now
contains a Dynamic URL button.
6. Click the Dynamic URL button and PolicyCenter opens a popup window and loads the URL that you set on the
constructMyURL function.

Result
If you followed the steps of this example exactly, PolicyCenter loads the Guidewire Internet home page into the
popup window.

Configuring special page functions 437

Guidewire PolicyCenter 9.0.9 Configuration Guide

438 chapter 29: Configuring special page functions

Part 6

Workflow, activity patterns, and email

configuration
Guidewire PolicyCenter 9.0.9 Configuration Guide
chapter 30

Using the workflow editor

This topic covers basic information about the workflow editor in Guidewire Studio.

Workflow in Guidewire PolicyCenter

Guidewire PolicyCenter uses workflow to drive various key business processes (Renewals, Policy Changes,
Submissions, and similar items). Guidewire defines and stores each base configuration workflow process as a
separate file in the following directory:
PolicyCenter/modules/configuration/config/workflow

Each file name corresponds to the workflow process that it defines (for example, CompleteCancellationWF.
[Link]). Each workflow file name contains a version number. If you create a new workflow, Studio creates a
workflow file with version number 1. If you modify an existing base configuration workflow, Studio creates a copy
of the file and increments the version number. In each case, Studio places the workflow file in the following
directory:
modules/configuration/config/workflow

See also
• For a discussion of workflow as it relates to specific job types (Submissions, for example), see the Application
Guide.
• “Guidewire workflow” on page 445.

Workflow in Guidewire Studio

Even though Guidewire defines the workflow scripts in XML files, you use Guidewire Studio to view, edit, manage,
and create new workflows scripts. Thus, you do not work directly with XML files. Instead, you work with their
representation in Guidewire Studio, in the Studio Workflows editor.

Access the workflow editor

Procedure
Navigate to configuration→config→Workflows, and then select a workflow.
Using the workflow editor 441
Guidewire PolicyCenter 9.0.9 Configuration Guide

Workflow editor window

Within the Workflows editor, there are multiple work areas, each of which performs a specialized function:

Area View Description

1 Tree view Studio displays each workflow type as a node in the Resources tree. If you have multiple versions of a
workflow type, Studio displays each one with an incremental version number at the end of the file name.
2 Outline view Studio displays an outline of the selected workflow process in the Outline pane. This outline lists all the
steps and branches for the workflow in the order that they actually appear in the workflow XML file. You
can re‐order these steps as desired. You can also re‐order the branches within a step. First, select an
item, then right‐click and select the appropriate menu item.
3 Layout view Studio displays a graphical representation of the workflow in the workflow pane. You use this represen‐
tation to visualize the workflow. You also use it to edit the defining values for each step and branch.
4 Proper‐ Studio displays detailed properties for the selected step or branch, much of which you can modify.
ty view

For example, in the PolicyCenter base configuration, Guidewire defines a CompleteCancellationWF script. In
Studio, it looks similar to the following:

Workflow editor elements

The following table lists the main workflow elements and describes each one.

Element Edi‐ Description More information

tor
<Context> Every workflow begins with a <Context> block. You use it to conveniently define “<Context> work‐
symbols that apply to the workflow. flow element” on
page 450

442 chapter 30: Using the workflow editor

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Element Edi‐ Description More information

tor
<Start> Defines the step on which the workflow starts. It optionally contains Gosu blocks “<Start> workflow
to set up the workflow or its business data. It runs before any other workflow element” on
step. page 451
AutoStep Defines a workflow step that finishes immediately, without waiting for time to “AutoStep workflow
pass or for an external trigger to activate it. step” on page 453
MessageStep Supports messaging‐based integrations. It automatically generates and sends a “MessageStep work‐
single integration message and then stops the workflow until the message com‐ flow step” on
pletes. (Typically, this is through receipt of an ack return message.) After the page 454
message completes, the workflow resumes automatically.
ActivityStep An ActivityStep is similar an AutoStep, except that it can use any of the branch “ActivityStep work‐
types, such as a TRIGGER or a TIMEOUT, to move to the next step. However, be‐ flow step” on
fore an ActivityStep branches to the next step, it waits for one or more activi‐ page 455
ties to complete.
ManualStep Defines a workflow step that waits for someone—or some thing—to invoke an “ManualStep work‐
external trigger or for some period of time to pass. flow step” on
page 456
GO Indicates a branch or transition to another workflow step. It occurs only within “GO” on page 459
an AutoStep workflow step.
• If there is only a single GO element within the workflow step, branching
occurs immediately upon workflow reaching that point.
• If there are multiple GO elements within the workflow step, each GO element
(except the last one) must contain conditional logic. The workflow then
determines the appropriate next step based on the defined conditions.
TRIGGER Indicates a branch or transition to another workflow element. It occurs only “TRIGGER” on
within a ManualStep workflow step. Branching occurs only upon manual invoca‐ page 460
tion from outside the workflow.
TIMEOUT Indicates a branch or transition to another workflow element. It occurs only “TIMEOUT” on
within a ManualStep workflow step. Branching to another workflow step occurs page 461
only after a specific time interval has passed.
Outcome Indicates a possible outcome for the workflow. This step is special. It indicates “Outcome workflow
that it is a last step, out of which no branch leaves. step” on page 457
<Finish> (Optional) Defines a Gosu script to run at the completion of the workflow to per‐ “<Finish> workflow
form any last clean up after the workflow reaches an outcome. It runs after all element” on
other workflow steps. page 451

Understanding workflow steps

Each workflow step represents a location in the workflow. It does not have a business meaning outside of the
workflow. Therefore, you can use any value for the IDs and arrange them in the order that is most convenient for
you. (Beware of infinite cycles between steps. PolicyCenter treats too many repetitions between steps as an error.)
A workflow script can contain any of the following steps. It must contains at least one Outcome step. It must also
start with one each of the <Context> and <Start> steps described in “Workflow structural elements” on page 450.

Type Workflow con‐ Icon Step Description

tains
AutoStep Zero, one, or more Step that PolicyCenter guarantees to finish immediately. See “AutoStep
workflow step” on page 453.

Using the workflow editor 443

Guidewire PolicyCenter 9.0.9 Configuration Guide

Type Workflow con‐ Icon Step Description

tains
ManualStep Zero, one, or more Step that waits for an external TRIGGER to occur or a TIMEOUT to pass.
See “ManualStep workflow step” on page 456.

ActivityStep Zero, one, or more Step that waits for one or more activities to complete before continu‐
ing. See “ActivityStep workflow step” on page 455.

MessageStep Zero, one, or more Special‐purpose step designed to support messaging‐based integra‐
tions. See “MessageStep workflow step” on page 454.

Outcome One or more Special final step that has no branches leading out of it. See “Outcome
workflow step” on page 457.

Using the workflow right‐click menu

You can modify a workflow step by first selecting it, then selecting different items from the right-click menu.

Desired result Actions

To change a work‐ Select Rename from the right‐click menu. This opens the Rename StepID dialog in which you can en‐
flow step name ter the new step name.
To change a work‐ Select Change Step Type from the right‐click menu, then the type of workflow step from the sub‐
flow step type menu. This action opens a dialog in which you set the new workflow step type parameters.
To move a work‐ Select Move Up (Move Down) from the right‐click menu. The editor only presents valid choices for
flow step up or down you to select. This action moves the workflow step up or down within the workflow outline view.
To create a new branch Select New <BranchType> from the right click menu. The editor presents you with valid branch
types for the workflow step type. This action opens a dialog in which you set the new branch
parameters.
To delete a workflow step Select Delete from the right‐click menu. This action removes the workflow step from the workflow
outline. The workflow editor does not permit you to remove the workflow step that you desig‐
nate as the workflow start step.

See also
• Globalization Guide

Using search with workflow

It is possible to search for a specific text string within a workflow by selecting Find in Path from the Studio Edit menu.
You can search on a localized text strings as well. You can also select a workflow and select Find in Path from the
right-click menu.
• If you use the Search menu option, you can filter the resources to check.
• If you use the right-click menu option, then the search encompasses all active resources.
In either case, Guidewire Studio opens a search pane at the bottom of the screen and displays any matches that it
finds. You can click on a match to open the workflow in which the match exists.

444 chapter 30: Using the workflow editor

chapter 31

Guidewire workflow

This topic covers PolicyCenter workflow. Workflow is the Guidewire generic component for executing custom
business processes asynchronously.

Understanding workflow
There are multiple aspects of workflow:

Term Definition
workflow, workflow in‐ A specific running instance of a particular business process. Guidewire persists a workflow in‐
stance stance to the database as an entity called Workflow.
workflow type A single kind of flow process, for example, a Cancellation workflow.
workflow process A definition of a workflow type in XML. Guidewire defines workflow processes in XML files that
you manage in Guidewire Studio through the graphical Workflows editor.

Discussions about workflow in general or the workflow system refer usually to the workflow infrastructure as a
whole.

Workflow instances
PolicyCenter saves a workflow instance as a row in the database marking the existence of a single running business
flow. PolicyCenter creates a workflow instance in response to a specific need to perform a task or function, usually
asynchronously. For example, in the base configuration, PolicyCenter creates a macro workflow as a companion to
each newly-created Job (Submission, PolicyChange, Renewal, for example). This workflow is responsible for
pushing the Job through its life cycle.
The newly created instance takes the form of a database entity called Workflow. Because PolicyCenter creates the
Workflow entity in a bundle with other changes to its associated business data, PolicyCenter does nothing with the
workflow until it commits the workflow. PolicyCenter does not send messages to any external application unless the
surrounding bundle commits successfully.
Note: For more information on the Workflow entity, consult the PolicyCenter Data Dictionary.
After creation of the Workflow entity, nothing further happens from the viewpoint of the code that created the
workflow. The workflow merely continues to execute asynchronously, in the background, until it completes. It is not
possible, in code, to wait on the workflow, as you can wait for a code thread to complete, for example. This is
because some workflows can literally and deliberately take months to complete.
Guidewire workflow 445
Guidewire PolicyCenter 9.0.9 Configuration Guide

All workflows have a state field ,a typekey of type WorkflowState, that tracks how the workflow is doing. This
state, and the transitions between states, is simple:
• All newly beginning Workflow entities start in the Active state, meaning they are still running.
• If a Workflow entity finishes normally, it moves to the Completed state, which is final. A workflow in the
Completed state takes no further action and exists from then on only as a record in the database.
• If you suspend a workflow, either from the PolicyCenterAdministration interface, from the command line, or
through the Workflow API, the workflow moves to the Suspended state. A workflow in the Suspended state does
nothing until manually resumed from the Administration interface, from the command line, or through the
Workflow API.
• If an error occurs to a workflow executing in the background, the workflow moves into the Error state after it
attempts the specified number of retries. A workflow in the Error state does nothing until manually resumed
from the Administration interface, the command line, or the Workflow API.
The following graphic illustrates the possible workflow states:

This diagram does not convey any information about how an active workflow, a workflow in the Active state, is
actually processing. For active workflows, Guidewire defines the workflow state in the WorkflowActiveState
typelist, which contains the following states:
• Running
• WaitManual
• WaitActivity
• WaitMessage
Whether the workflow is actually running depends on whether it is the current work item being processed.

Work items
Each running workflow instance can have a work item. If a running workflow does not have a work item associated
with it, the workflow writer picks up the workflow instance at the next scheduled run. The state of this work item is
one of the following:
• Available
• Failed – PolicyCenter retries a Failed work item up to the maximum retry limit.
• Checkedout – PolicyCenter processes a Checkedout work item in a specific worker's queue after the work item
reaches the head of that queue.
446 chapter 31: Guidewire workflow
 Guidewire PolicyCenter 9.0.9 Configuration Guide

See also

• System Administration Guide

Workflow process format

To structure a workflow script, Guidewire uses the concept of a directed graph that shows how the Workflow
instance moves through the various states. This directed graph is known formally as a Petri net or P/T net.
Guidewire calls each state a Step and calls a transition between two states a Branch. Guidewire defines multiple
types of steps and branches.
Even though Guidewire defines the workflow scripts in XML files, you use Guidewire Studio to view, edit, manage,
and create new workflows scripts.

See also

• “Workflow in Guidewire Studio” on page 441

Workflow step summary

The workflow process consists of the following steps (or states). The table lists the steps in the approximate order in
which they occur in the workflow script. A designation of structural indicates that these steps are mandatory and
that Studio inserts them into the workflow process automatically. Studio marks the structural steps with brackets
(<...>) to indicate that they are actually XML elements. Some of the structural elements have no visual
representation within the workflow diagram itself. You can choose them only from the workflow outline.

Step Script Description

contains
“<Context> workflow ele‐ Exactly Structural. Element for defining symbols used in the workflow. Generally, you define a
ment” on page 450 one symbol to use as convenience in defining objects in the workflow path. For example,
you can define a symbol such that inserting “Cancellation” into the text workflow ac‐
tually inserts “[Link]”.
“<Start> workflow ele‐ Exactly Structural. Element defining on which step the Workflow element starts. It can option‐
ment” on page 451 one ally contain Gosu code to set up the workflow or its business data.
“AutoStep workflow Zero, one, A step is one stage that the Workflow instance can be in at a time. There can be zero,
step” on page 453 or more one, or more of any of these steps, in any order.
“ActivityStep workflow Each of these steps in turn can contain one or more of the following:
step” on page 455 • Any number of Assert code blocks for ensuring the conditions in the step are met.
“ManualStep workflow • An Enter block with Gosu code to execute on entering the step.
step” on page 456 • Any number of Event objects that generate on entering the step.
“MessageStep workflow • Any number of Notification objects that generate on entering the step.
step” on page 454
• An Exit block with Gosu code to execute on leaving a step.
Several of these steps can contain other, step‐specific, components:
• An ActivityStep can contain any number of Activity steps that generate on
entering the step.
• An AutoStep or ActivityStep can contain any number of GO branches which lead
from this step to another step.
• A ManualStep can contain any number of TRIGGER branches which lead from this
step to another step, if something or someone from outside the workflow system
manually invokes it. (This happens typically through the PolicyCenter interface.)
• A ManualStep can contain any number of TIMEOUT branches that lead to another
step after the elapse of a certain time.
“Outcome workflow step” One or A specialized step that indicates a last step out of which no branch leaves.
on page 457 more

Guidewire workflow 447

Guidewire PolicyCenter 9.0.9 Configuration Guide

Step Script Description

contains
“<Finish> workflow ele‐ Zero or Structural. An optional code block that contains Gosu code to perform any last clean‐
ment” on page 451 one up after the workflow reaches an Outcome.

See also

• “Using the workflow editor” on page 441

Workflow Gosu
Workflow elements Start, Finish, Enter, Exit, GO, TRIGGER, and TIMEOUT can all contain embedded Gosu. The
Workflow engine executes this Gosu code any time that it executes that element. The specific order of execution is:
• The Workflow engine runs Start before everything else
• The Workflow engine runs Enter on entering a step.
• The Workflow engine runs Exit upon leaving a step. It runs Exit before the branch leading to the next step.
Thus, the actual execution logic from Step A to Step B is to Exit A, then do the Branch, then Enter B.
• The Workflow engine runs GO, TRIGGER, TIMEOUT elements as it encounters them upon following a branch.
• The Workflow engine runs Finish after it runs everything else.
Within the Gosu block, you can access the currently-executing workflow instance as Workflow. If you need to use
local variables, declare them with var as usual in Gosu. However, if you need a value that persists from one step to
another, create it as an extension field on Workflow and set its value from scripting. You can also create subflows in
the Gosu blocks.
The current bundle for workflow actions is the bundle that the application uses to load the Workflow entity instance.
The expression [Link] returns the workflow bundle.

See also

• Gosu Reference Guide

Workflow versioning
After you create a workflow script and make it active, it can create hundreds or even thousands of working instances
in the PolicyCenter application. As such, you do not want to modify the script as actual existing workflow instances
can possibly be running against it. (This is similar to modifying a program while executing it. It can lead to very
unpredictable results.)
However, you might choose to modify a script. Then, you would want all newly created instances of the workflow to
use your new version of the script.
Guidewire stores each workflow script in a separate XML file. By convention, Guidewire names each file a variant
of xxxWF.#.xml:
• xxx the workflow name (which is camel-cased LikeThis)
• # is the version number of the workflow process (starting from 1)
Every newly created (copied) workflow script has a different version number from its predecessor. (The higher the
version number, the more recent the script.) Thus, a script file name of [Link] means workflow
type ManualExecution, version 2. As PolicyCenter creates new instances of the workflow script, it uses the most
recent script—the highest-numbered one—to run the workflow instance against.
It is possible to start a specific workflow with a specific version number. For details, see “Instantiating a workflow”
on page 466.

448 chapter 31: Guidewire workflow

 Guidewire PolicyCenter 9.0.9 Configuration Guide

The Workflow engine enforces the following rules in regards to version numbers:
• If you create a new workflow instance for a given workflow subtype, thereafter, the Workflow engine uses the
script with the highest version number. PolicyCenter saves this number on the workflow instance as the
ProcessVersion field.
• From then on, any time that the Workflow instance wakes up to execute, the Workflow engine uses the script
with the same typecode and version number of the instance only.
• It is forbidden to have two workflow scripts with the same subtype and version number. The server refuses to
start if you try.
• If a workflow instance cannot find a script with the right subtype and version number, it fails with an error and
drops immediately into the Error state. (This might happen, perhaps, if someone inadvertently deleted the file or
the file did not load for some reason.)

When to create a new workflow version

Guidewire recommends, as a general rule, that you create a new workflow version under most circumstances if you
modify a workflow. For example:
• If you add a new step to the workflow, then create a new workflow version.
• If you remove an existing step from the workflow, then create a new workflow version.
• If you change the step type, for example, from Manual to an automatic step type, then create a new workflow
version.
More specifically, for each workflow, PolicyCenter does the following:
• Records the current step of an active workflow in the database. Each change to the basic structure of a workflow
requires a new version.
• Records the branch that an active workflow selects in the database. A change to the Branch ID requires a new
version.
• Records the activity associated with an Activity step in the database. A change to an Activity definition
requires a new version.
• Records the trigger activity that occurs in an active workflow in the database. A removal of a trigger requires a
new workflow version.
• Records the messageID of each workflow message in the database. A modification to a MessageStep requires a
new workflow version.
You do not need to create a new workflow version if you modify a constant such as the timeout value in the TIMEOUT
step. PolicyCenter does record the wake-up time (for a TIMEOUT step) that it calculates from the timeout time in the
database. However, changing a timeout value does not affect workflows that are already on that step. Therefore, you
do not need to create a new workflow version.
If you do modify a workflow, be aware that:
• If you convert a manual step to an automatic step, it can cause issues for an active workflow.
• If you reduce a timeout value, any active workflows that have already hit that step will only wait the previously
calculated time.

IMPORTANT If there is an active workflow on a particular step, do not alter that step without
versioning the workflow.

Workflow localization
At the start of the workflow execution, PolicyCenter evaluates the workflow locale and uses that locale for notes,
documents, templates, and similar items. However, it is possible to set a workflow locale that is different from the
default application locale through the workflow editor. This change then affects all notes, documents, templates,
email messages, and similar items that the various workflow steps create or use.
Guidewire workflow 449
Guidewire PolicyCenter 9.0.9 Configuration Guide

You can also:

• Set a different locale for any spawned subworkflows.
• Set a locale for a Gosu block that a workflow executes.
• Set Studio to display a workflow step name in a different locale.

See also
• “Set a workflow locale” on page 450
• Globalization Guide

Set a workflow locale

About this task
To view or modify the locale for a workflow, do the following:

Procedure
1. Click in the background area of the layout view.
2. In the properties area at the bottom of the screen, in the Locale field, enter a valid ILocale type to set the
overall locale for a workflow.

See also
• Globalization Guide

Workflow structural elements

A workflow (or, more technically, a workflow XML script) contains a number of elements that perform a structural
function in the workflow. For example, the <Start> element designates which workflow step actually initiates the
workflow.
The workflow elements include the following:

Element More information

<Context> “<Context> workflow element” on page 450

<Finish> “<Finish> workflow element” on page 451

<Start> “<Start> workflow element” on page 451

<Context> workflow element

Every workflow begins with a <Context> block. You use it to conveniently define symbols that apply to the
workflow. You can use these symbols over and over in that workflow. For example, suppose that you extend the
Workflow entity and add User as a foreign key. Then, you can define the symbol user for use in the workflow script
with the value [Link].
Within the workflow, you have access to additional symbols, basically whatever the workflow instance knows about.
For example, you can define a symbol such that inserting Cancellation into the text workflow actually inserts
[Link].

Defining Symbols
You must specify in the context any foreign key or parameter that the workflow subtype definition references. To
access the <Context> element, select it in the outline view. You add new symbols in the property area at the bottom
of the screen.
450 chapter 31: Guidewire workflow
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Field Description
Name The name to use in the workflow process for this entity.

Type The Guidewire entity type.

Value The instance of the entity being referenced.

<Start> workflow element

The <Start> structural block defines the step on which the workflow starts. To set the first step, select <Start> in
the outline view (center pane). In the properties pane at the bottom of the screen, choose the starting step from the
drop-down list of steps. Studio displays the downward point of a green arrow on the step that you chose.
This element can optionally contain Gosu code to set up the workflow or its business data.

<Finish> workflow element

The <Finish> structural block is an optional block that contains Gosu code to perform any last cleanup after the
workflow reaches an Outcome Workflow Step.

Common step elements

It is possible for each step in the workflow to also contain some or all of the following:‘
• “Enter and exit scripts in workflows” on page 451
• “Asserts in workflows” on page 452
• “Events in workflows” on page 452
• “Notifications in workflows” on page 452
• “Branch IDs in workflows” on page 453
The PolicyCenterAdministration tab displays the current step for each given workflow instance.

Enter and exit scripts in workflows

A workflow step can have any amount of Gosu code in the Enter and Exit blocks to define what to do within that
step. (Enter scripts are far more common.) To access the enter and exit scripts block, select a workflow step and
view the Properties tab at the bottom of the screen.

Enter Script Gosu code that the workflow runs just after it evaluates any Asserts in Workflows (conditions) on the step.
(That is, if none of the asserts evaluate to false. If this happens, the workflow does not run this step.)
Exit Script Gosu code that the workflow runs as the final action on leaving this step.

For example, you could enter the following Gosu code for the enter script:
var msg = "Workflow " + [Link] + "started at " + [Link]
print(msg)

Guidewire workflow 451

Guidewire PolicyCenter 9.0.9 Configuration Guide

Note: If you rename a property or method, or change a method signature, and a workflow references
that property or method in a Gosu field, PolicyCenter throws a ParseResultsException. This is the
intended behavior. You must reload the workflow engine to correct the error (Internal
Tools→Reload→Reload Workflow Engine).

Asserts in workflows
A step can have any number of Assert condition statements. An Assert executes just before the Enter block. If an
Assert fails, the workflow throws an exception and handles it like any other kind of runtime exception. To access
the Assert tab, select a workflow step.

Condition Each condition must evaluate to a Boolean value.

Error message If a condition evaluates to false, then the workflow logs the supplied error message.

For example, you could add the following assert condition and error message to log if the assertion fails:

Condition
[Link] == “start”

Error message to log if assertion fails

“Some error message if condition is false”

Events in workflows
A step can have any number of Event elements associated with it. An Event runs right after the Enter block, and
generates an event with the given name and the business object. To access the Events tab, select a workflow step.

Entity Name Entity on which to generate the event. This must be a valid symbol See also:
name. • “<Context> workflow element” on
page 450
Event Name Name of the event to generate. This must be a valid event name. See also:
• Integration Guide

For example:

Entity Name account

Event Name someEvent

Notifications in workflows
A step can have any number of non-blocking Notification activities. A notification in workflow terms is an
activity that PolicyCenter sends out, but which does not block the workflow from continuing. PolicyCenter only
uses it to notify you of something. The workflow generates any notifications immediately after it executes the Enter
code, if any. See “ActivityStep workflow step” on page 455 for more information on activity generation.

Name Name of the activity.

Pattern Activity pattern code. This must be a valid activity pattern as defined through Guidewire PolicyCenter.

Init Optional Gosu code that the workflow executes immediately after it creates the activity. Typically, you use this code to
assign the activity. If you do not explicitly assign the activity, the workflow auto‐assigns the activity.

For example:
452 chapter 31: Guidewire workflow
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Name notification

Pattern general_reminder

Branch IDs in workflows

A branch is a transition from one step to another. Every branch has an ID, which is its reference name. An ID is
necessary because the Workflow instance sometimes needs to persist to the database which branch it is trying to
execute. (This can happen, for example, if an error occurs in the branch and the workflow drops into the Error
state). A branch ID must be unique within a given step.
Generally, as you enter information in a dialog to define a step, you also need to enter branch information as well.

Basic workflow steps

Guidewire uses the following steps (or blocks) to create a workflow:

Workflow step More information

AutoStep “AutoStep workflow step” on page 453
MessageStep “MessageStep workflow step” on page 454
ActivityStep “ActivityStep workflow step” on page 455
ManualStep “ManualStep workflow step” on page 456
Outcome “Outcome workflow step” on page 457

AutoStep workflow step

An AutoStep is a step that PolicyCenter guarantees to finish immediately. That is, it does not wait for anything else
such as an activity, a manual trigger, or a timeout before continuing to the next step. The Workflows editor indicates
an autostep with an arrow icon in the box the represents that step.

Each AutoStep step must have at least one “GO” on page 459 branch. (It can have more than one, but it must have
at least one.) Each GO branch that leaves an AutoStep step—except for the last one listed in the XML code—must
contain a condition that evaluates to either Boolean true or false.
After the AutoStep completes its Assert, Enter, and Activity blocks, it goes through its list of GO branches (from
top to bottom in the XML code):
• It picks the first GO branch for which the condition evaluates to true.
• If none of the other GO branches evaluate to true, it picks the last GO element (without a condition).
At that point, it executes the Exit block and proceeds to the step specified by the chosen GO element.

Create an auto workflow step

Procedure
1. Right-click in the workflow workspace, and then click New AutoStep.
2. Enter the following fields:

Field Description
Step ID ID of the step to create.

Guidewire workflow 453

Guidewire PolicyCenter 9.0.9 Configuration Guide

Field Description
ID ID of a branch leaving this step. It defaults to the To value if you do not supply a value.
To ID of the step to which the workflow goes if the condition specified for this branch evaluates to true.

For example:

Step ID Step1

ID -

To DefaultOutcome

3. Click on your newly created step. It is possible that there are additional tabs to fill out in the properties area at
the bottom of the screen. See “Common step elements” on page 451 for information on the various tabs.

MessageStep workflow step

A MessageStep is a special-purpose step designed to support messaging-based integrations. It automatically
generates and sends a single integration message and then stops the workflow until the message completes.
(Typically, this is through receipt of an ack return message.) After the message completes, the workflow resumes
automatically.
The Workflows editor indicates an message step with a mail icon in the box the represents that step.

Just before running the Enter block, the workflow creates a new message and assigns it to [Link]. Use
the Enter block to set the payload for the message. After the Enter block finishes, the workflow commits its bundle
and stops. This commits the message. At this point, the messaging subsystem picks up the message and dispatches
it.
If something acknowledges the message (either internal or external), PolicyCenter stores an optional response string
(supplied with the ack) on the message in the Response field. PolicyCenter then does the following:
• It copies the message into the MessageHistory table
• It updates the workflow to null out the foreign key to the original message and establishes a foreign key to the
new MessageHistory entity.
It then resumes the workflow (by creating a new work item).
There can be any number of GO branches that leave a message step (but only GO branches). As with AutoStep
Workflow Step, the workflow evaluates each GO condition, and chooses the first one that evaluates to true. If none
evaluate to true, the workflow takes the branch with no condition attached to it.

Create a message workflow step

Procedure
1. Right-click in the workflow workspace, and select New MessageStep.
2. Enter the following fields:

Field Description
Step ID ID of the step to create.
Destination ID ID of the destination for the message. This must be a valid message destination ID as defined through the
Studio Messaging editor.
EventName Event name on the message.
ID ID of a branch leaving this step. It defaults to the To value if you do not supply a value.

454 chapter 31: Guidewire workflow

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Field Description
To ID of the step to which the workflow goes if the condition specified for this branch evaluates to true.

For example:

Step ID Step4

Dest ID 89

Event Name EventName

ID

To DefaultOutcome

3. Click on your newly created step. It is possible that there are additional tabs to fill out in the properties area at
the bottom of the screen.

See also
• “Common step elements” on page 451

ActivityStep workflow step

An ActivityStep is similar an AutoStep Workflow Step, except that it can use any of the branch types—
including a TRIGGER or a TIMEOUT—to move to the next step. However, before an ActivityStep branches to the
next step, it waits for one or more activities to complete. PolicyCenter indicates the termination of an activity by
marking it one of the following:
• Completed (which includes either being approved or rejected)
• Skipped
• Canceled
Activities are a convenient way to send messages and questions asynchronously to users who might not even be
logged into the application.
The Workflows editor indicates an activity step with a person icon in the box the represents that step.

Within an ActivityStep, you specify one or more activities. The workflow creates each defined activity as it enters
the step. (This occurs immediately after the workflow executes the Enter Script block, if there is one.) The activity is
available on all steps.
The only difference between an Activity and a Notification within a workflow is that:
• An Activity pauses the workflow until all the activities in the step terminate.
• A Notification does not block the workflow from continuing.
If more than one Activity exists on an ActivityStep, then the workflow generates all of them immediately after
the Enter block (along with any events or notifications). The step then waits for all of the activities to terminate. If
desired, an ActivityStep can also contain TIMEOUT and TRIGGER branches as well. In that case, if a timeout or a
trigger on the step occurs, then the workflow does not wait for all the activities to complete before leaving the step.
After PolicyCenter marks all the activities as completed, skipped or canceled, the ActivityStep uses one or more
“GO” on page 459 branches to proceed to the next step. There can be any number of GO branches that leave an
activity step. As with AutoStep Workflow Step, the workflow evaluates each GO condition, and chooses the first
one that evaluates to true. If none evaluate to true, the workflow takes the branch with no condition attached to it.
Notice that it is possible for the condition statement of a GO branch to reference a generated Activity by its logical
name. For instance, it is possible that you want to proceed to a different step depending on whether PolicyCenter
marks the Activity as completed or canceled.
Guidewire workflow 455
Guidewire PolicyCenter 9.0.9 Configuration Guide

Create an activity workflow step

Procedure
1. Right-click in the workflow workspace, and select New ActivityStep.
2. The dialog contains the following fields:

Field Description
Step ID The ID of the step to create.

Name Name of the activity.

Pattern Activity pattern code. This must be a valid activity pattern as defined through Guidewire PolicyCenter.

ID ID of a branch leaving this step. It defaults to the To value if you do not supply a value.
To ID of the step to which the workflow goes if the condition specified for this branch evaluates to true.

3. Click on your newly created step and open the Activities tab at the bottom of the screen. After you create the
ActivityStep, you need to create one or more activities. (Each ActivityStep must contain at least one
defined activity.) These fields on the Activities tab have the following meanings:

Name Name of the activity.

Pattern Activity pattern code value. This must be a valid activity pattern code as defined through Guidewire
PolicyCenter. To view a list of valid activity pattern codes, view the ActivityPattern typelist. Only enter a value
in the Pattern field that appears on this typelist. For example:
• approval
• approvaldenied
• general
• ...

Init Gosu code that the workflow executes immediately after it creates the activity. Typically, you use this code to
assign the activity. If you do not explicitly assign the activity, the workflow auto‐assigns the activity. For exam‐
ple, the following initialization Gosu code creates an activity and assigns it SomeUser in SomeGroup.
[Link](Activity)
[Link](SomeGroup, SomeUser)
The initialization code creates an activity based on the activity pattern that you set in the Pattern field.

ManualStep workflow step

A ManualStep is a step that waits for an external TRIGGER to be invoked or a TIMEOUT to pass. Unlike AutoStep
Workflow Step or ActivityStep Workflow Step, a ManualStep must not have, and cannot have, GO branches
leaving it. However, it can have zero or more TRIGGER branches or zero, or more, TIMEOUT branches. It must have at
least one of these branches. Otherwise, there would be no way to leave this step.
The Workflows editor indicates a manual step with an hour-glass icon in the box the represents that step.

Manual Step with Timeout

If you specify a timeout for this step, then you also need to specify one of the following. (See also “TIMEOUT” on
page 461 for more discussion on these two values.)

Time Del- The amount of time to wait or pause before continuing. Enter an integer number with its units (3600s, for example).
ta

Time Ab- A fixed point in time, as defined by a Gosu expression that resolves to a date. You can use the Gosu code to define
solute the date, as in the following:
456 chapter 31: Guidewire workflow
 Guidewire PolicyCenter 9.0.9 Configuration Guide

[Link]
Or, you can use Gosu to calculate the point in time, as in the following:
[Link](-105)

This defines the terms of the TIMEOUT branch that leaves this step. To view these details later, click the branch (the
link) between the two steps.

Manual Step with Trigger

If you specify a trigger for this step, then you need only enter the branch information. This defines the terms of the
TRIGGER branch that leaves this step. To view these details later, click the branch (the link) between the two steps.

Create a manual workflow step

Procedure
1. Right-click in the workflow workspace, and select New ManualStep.
2. Enter the following fields. What you see in the dialog changes slightly depending on the value you set for Type
(TIMEOUT or TRIGGER).

Field Description
Step ID ID of the step to create.
Type Name of the activity.
ID If you select the following Type value:
• Trigger: A valid trigger key as defined in typelist WorkflowTriggerKey.
• Timeout: ID of a branch leaving this step. It defaults to the To value if you do not supply a value.
To ID of the step to which the workflow goes if the condition specified for this branch evaluates to true.
Time Delta Specifies a fixed amount of time to pause before continuing. For example, the following sets the wait time to
60 minutes (one hour): 3600s,
Time Ab- Specifies a fixed point in time. For example, the following sets the point to continue to after the policy
solute CancelProcessDate:
[Link]

If the WorkflowTriggerKey typelist does not contain any trigger keys, then you do not see the Trigger option in
the dialog.
3. Click on your newly created step. It is possible that there are additional tabs to fill out in the properties area at
the bottom of the screen.

Outcome workflow step

An Outcome is a special step that has no branches leading out of it. It is thus a final or terminal step. If a workflow
enters any Outcome step, it is complete. It is possible (and likely) for a workflow to have multiple outcomes or final
steps.
The Workflows editor indicates an outcome step with a gray bar in the box to indicate that this is a final step.

After the workflow successfully enters an Outcome step (meaning that the workflow successfully executes the Enter
block of the Outcome step), it does the following:
1. The workflow generates all the listed events and notifications.
2. It executes the <Finish> Workflow Element block of the workflow process.
Guidewire workflow 457
Guidewire PolicyCenter 9.0.9 Configuration Guide

3. It changes the state of the workflow instance to Completed.

You must structure each workflow script so that its execution eventually and inevitably leads to an Outcome.
Otherwise, you risk infinitely-running workflows, which means that the load on PolicyCenter can increase linearly
over time, crippling performance.

Create an outcome workflow step

Procedure

1. Right-click in the workflow workspace, and select New Outcome.

2. Enter a step ID in the New Outcome dialog.
3. Click on your newly created step. It is possible that there are additional tabs to fill out in the properties area at
the bottom of the screen.

Step branches
A branch is a transition from one step to another. There are multiple kinds of elements that facilitate branching to
another step. They are:
• GO
• TRIGGER
• TIMEOUT
The Workflows editor indicates a branch by linking two steps with a line and placing one of the following icons on the
line to indicate the branch type.

Type Icon Description

GO A branch or transition to another workflow step. It occurs only within an AutoStep Workflow Step workflow
step.
• If there is only a single “GO” on page 459 branch within the workflow step, branching occurs immediately
upon workflow reaching that point.
• If there are multiple GO branches within the workflow step, all GO branches (except one) must contain
conditional logic. The workflow then determines the appropriate next step based on the defined
conditions.
TRIGGER A branch or transition to another workflow element. It occurs only within a ManualStep Workflow Step
workflow step. Branching occurs only upon manual invocation from outside the workflow.
TIMEOUT A branch or transition to another workflow element. It occurs only within a ManualStep Workflow Step
workflow step. Branching to another workflow step occurs only after the passing of a specific time interval.

All branch elements contain a To value that indicates the step to which this branch leads. It can also contain an
optional embedded Gosu block for the workflow to execute if a workflow instance follows that branch.
How a workflow decides which branch to take depends entirely on the type of the branch. However, the order is
always the same:
• The workflow executes the Enter block for a given step and generates any events, notifications, and activities
(waiting for these activities to complete).
• The workflow attempts to find the first branch that is ready to be taken. It starts with the first branch listed for
that step in the outline view, then moves to evaluate the next branch if the previous branch is not ready.
• If no branch is ready (which is possible only on a ManualStep), the workflow waits for one to become ready.
• After the workflow selects a branch, it runs the Exit block, then executes the Gosu block of the branch.
• Finally, the workflow moves to the next step and begins to evaluate it.
458 chapter 31: Guidewire workflow
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Working with branch IDs

Every branch also has an ID, which is its reference name. An ID is necessary because the Workflow instance
sometimes needs to persist to the database which branch it is trying to execute. (This can happen, for example, if an
error occurs in the branch and the workflow drops into the Error state). A branch ID must be unique within a given
step.
If you do not specify an ID for a branch (which occurs frequently), the workflow uses the value of nextStep
attribute as a default. This works well except in the special case in which you have more than one branch leading
from the same Step A to the same Step B. (This can happen, for example, if you want to OR multiple conditions
together, or if you want different Gosu in the different branches but the same nextStep.) In that case, you must add
an ID to each of those branches. Studio complains with a verification error upon loading (or reloading) the workflow
scripts if you do not do this.
Do the following to assign an ID to each type of branch:

Type Action to take

GO Optionally add an ID to a GO branch. If you do not provide one, Studio defaults the ID to the value of the nextStep
attribute. However, Guidewire recommends that you create specific IDs if there are multiple GO branches that all
move to the same next step.
TRIGGER Always add an ID to a TRIGGER branch. Guidewire requires this as you must invoke a trigger explicitly. You must use a
value from the WorkflowTriggerKey typelist for the branch ID.
TIMEOUT Optionally add an ID to a TIMEOUT branch. If you do not provide one, Studio defaults the ID to the value of the
nextStep attribute.

GO
The simplest kind of branch is GO. It appears on AutoStep, ActivityStep and MessageStep. There can be a single
GO branch or a list of multiple GO branches. If there is a single GO branch, then you need only specify the To field and
any optional Gosu code. The workflow takes this GO branch immediately as it checks its branches.
The Workflows editor indicates a GO branch with an arrow icon superimposed on the line that links the two steps.
(That is, the initial From step and the To step to which the workflow goes if the GO condition evaluates to true.)
To access the dialog that defines the GO branch, right-click the starting step—in this case, CheckOnOrder—and select
New GO from the menu. (Studio only displays those choices that are appropriate for that step.) This dialog contains
the following fields:

Field Description
Branch ID ID of the branch to create

From ID of the step on the which the GO branch starts.

To ID of the step on the which the GO branch starts.

It is not necessary to enter a branch ID. However, if you create multiple GO branches from a step, then you must
enter a unique ID for each branch.
After you create the GO branch, click on the link (line) that runs between the two steps. You will see a dialog that
contains the following fields:

Field Description
Branch ID Automatically generated.
From Automatically generated. Workflow step ID of the beginning point of the branch.
To Workflow step ID of the ending point of the branch.

Guidewire workflow 459

Guidewire PolicyCenter 9.0.9 Configuration Guide

Field Description
Arrow Visible Show an arrow head on the branch line to indicate direction.

Description Description of this branch.

Condition Must evaluate to either true or false.
Execution Gosu code to execute if the workflow takes this branch.

Notice that this branch definition sets a condition. The From and To fields set the end-points for the branch.
If there are multiple GO branches, all the GO branches except one must define a condition that evaluates to either
Boolean true or false. The workflow decides which GO branch to take by evaluating the GO branches from top to
bottom (within the XML step definition). It selects the first one whose condition evaluates to true. If none of the
conditions evaluate to true, then the workflow uses the GO branch that does not have a condition. A list of GO
branches is thus like a switch programming block or a series of if...else... statements, with the default case at
the bottom of the list.

Infinite Loops

Beware of infinite, immediately-executing cycles in your workflow scripts. For example:

From To
StepA StepB

StepB StepA

If the steps revolve in an infinite loop, PolicyCenter catches this only after 500 steps. This can cause other problems
to occur.

TRIGGER
Another kind of branch is TRIGGER, which can appear in a ManualStep Workflow Step or an ActivityStep
Workflow Step. It also has a To field and an optional embedded Gosu block. However, instead of a condition
checking to see if a certain Gosu attribute is true, someone or something must manually invoke a TRIGGER from
outside the workflow infrastructure. (Typically, this happens from either PolicyCenter interface or from a Gosu call.)
Guidewire requires a branch ID field on all TRIGGER elements, as outside code uses the ID to manually reference the
branch.
Unlike all other the IDs used in workflows, TRIGGER IDs are not plain strings but typelist values from the extendable
WorkflowTriggerKey typelist. This provides necessary type safety, as scripting invokes triggers by ID. However, it
also means that you must add new typecodes to the typelist if you create new trigger IDs.

Invoking a trigger

How does one actually invoke a TRIGGER? Almost anything can do so, from Gosu rules and classes to the
PolicyCenter interface. Typically, in PolicyCenter, you invoke a trigger though the action of toolbar buttons in a
wizard. This is done through a call to the invokeTrigger method on Workflow instances. (As it is also a scriptable
method, you can call it from Gosu rules and the application PCF pages.) See “Synchronicity, transactions, and
errors” on page 469 for a discussion of the invokeTrigger method and its parameters.
Internally, the method works by updating the (read-only) database field triggerInvoked on Workflow to save the
ID. (See the PolicyCenter Data Dictionary entry on Workflow.)
PolicyCenter then wakes up the workflow instance and the TRIGGER inspects the triggerInvoked field to see if
something invoked the trigger. Depending on how you set the invokeTrigger method parameters, the workflow
handles the result of the TRIGGER either synchronously or asynchronously.
460 chapter 31: Guidewire workflow
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Creating a trigger branch

To access the TRIGGER branch dialog, right-click the starting step and select New Trigger from the menu. (Studio only
displays those choices that are appropriate for that step.) This dialog contains the following fields:

Field Description
Branch ID Name of this branch as defined in the WorkflowTriggerKey typelist. Select from the drop‐down list.

From Automatically generated. Workflow step ID of the beginning point of the branch.
To Workflow step ID of the ending point of the branch.

After you create the branch, click on the link (line) that runs between the two steps. You see the following fields,
which are identical to those used to define a GO branch:

Field Description
Branch ID Automatically generated.
From Automatically generated. Workflow step ID of the beginning point of the branch.
To Workflow step ID of the ending point of the branch.
Arrow Visible Show an arrow head on the branch line to indicate direction.

Description Description of this branch.

Condition Must evaluate to either true or false.
Execution Gosu code to execute if the workflow takes this branch.

Trigger availability
Simply because you define a TRIGGER on a ManualStep does not mean it is necessarily available. You can restrict
trigger availability in the following different ways:
• You can specify user access permission through the use of the Permission field.
• You can add any number of Available conditions on the Available tab to further restrict availability. If the
condition expression evaluates to true, the trigger is available. Otherwise, it is unavailable.
For example (from PolicyCenter), the following Gosu code indicates that the workflow can only take this branch
if a user has permission to rescind a policy. (The condition evaluates to true.)
[Link]().Okay

TIMEOUT
Another kind of branch is TIMEOUT, which (like TRIGGER) can appear on ManualStep Workflow Step or an
ActivityStep Workflow Step. You still have a To field and optional Gosu block. However, instead of using a
condition to determine how to move forward, the workflow executes the TIMEOUT element after the elapse of a
specified amount of time.
You can use a TIMEOUT in the following ways:
• As the default behavior for a stalled workflow. For example:
Do x if PolicyCenter has not invoked a trigger for a certain amount of time.
• As a deliberate delay. For example:
Go to sleep for 35 days.
You can specify the time to wait using one of the following attributes. (Studio complains if you use neither or both.)
• timeDelta
• timeAbsolute
Guidewire workflow 461
Guidewire PolicyCenter 9.0.9 Configuration Guide

The time delta value

The Time Delta value specifies an amount of time to wait, starting from the time the Workflow instance successfully
enters the step. (The wait time starts immediately after the workflow executes the Enter Script block for the step.) You
specific the time to wait with a number and a unit, for example:
• 100s for 100 seconds
• 15m for 15 minutes
• 35d for 35 days
You can also combine numbers and units, for example, 2d12h30m for 2 days, 12 hours, and 30 minutes.

The time absolute value

Often, you do not want to wait a certain amount of time. Instead, you want the step to time out after passing a certain
point relative to a date in the business model (for example, five days after a specific event occurs). In that case you
can set the Time Absolute value, which is a Gosu expression that must resolve to a date.

IMPORTANT Do not use the current time in a Time Absolute expression. The workflow reevaluates this
expression each time it checks TIMEOUT. For example, the time-out never ends for the following
expression, [Link] + 1, as the expression always evaluates to the future.

Creating a timeout branch

You use the Workflows editor to define a Timeout branch. To access the Timeout branch dialog, right-click the
starting step and select New Timeout from the menu. You must enter either a time absolute expression or a time delta
value. This dialog contains the following fields:

Field Description
Branch ID Name you choose for this branch.
From Automatically generated. Workflow step ID of the beginning point of the branch.
To Workflow step ID of the ending point of the branch.
Time Delta Time to wait, starting from the time the Workflow instance successfully enters the step.
Time Absolute Gosu expression that must resolve to a fixed date.

After you create the branch, click on the link that runs between the two steps. You see the following fields:

Field Description
Branch ID Automatically generated.
From Automatically generated. Workflow step ID of the beginning point of the branch.
To Workflow step ID of the ending point of the branch.
Arrow Visible Show an arrow head on the branch line to indicate direction.
Time Delta Time to wait, starting from the time the Workflow instance successfully enters the step.
Time Absolute Gosu expression that must resolve to a fixed date.

Execution Gosu code to execute if the workflow takes this branch.

Creating new workflows

To create a new workflow, you can do the following:
462 chapter 31: Guidewire workflow
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Action Description
Clone an Existing Creates an exact copy of an existing workflow type, with the same name but with an incremented ver‐
Workflow sion number. (This process clones the workflow with highest version number, if there multiple versions
already exist.) Perform this procedure if you merely want a new version of an existing workflow.
Extend an Existing Creates a new (blank) workflow with a name of your choice based on the workflow type of your
Workflow choice.

Clone an existing workflow

About this task
Cloning an existing workflow is a relatively simple process. Also, if you clone an existing, fully built workflow,
then you can leverage the work of the original workflow. However, you can only clone existing workflow types. You
cannot use this method to create a new workflow type.

Procedure
1. Open the Workflows node in the Project window tree.
2. Select an existing workflow type, right-click and select New→Workflow from the menu.

Result
Studio creates a cloned, editable copy of the workflow process and inserts it under the workflow node with an
incremented version number. You can then modify this version of the workflow process to meet your business
needs.

Extend an existing workflow

About this task
To extend an existing workflow, you must create an eti (extension) file and populate it correctly. To assist you,
Studio provides a dialog in which you can enter the basic workflow information. You must then enter this
information in the eti file.

Procedure
1. First, determine the workflow type that you want to extend.
2. Select Workflows in the Project window, right-click and select Create metadata for a new workflow subtype from the
menu.
3. In the New Workflow subtype metadata dialog, enter the following:

Field Description
Entity The workflow object to create.
Supertype The type or workflow to extend. You can always extend the Workflow type, from which all subtypes extend.
Description Optional description of the workflow.
Foreign keys Click the Add button to enter any foreign keys that apply to this workflow object.

4. Click Gen to clipboard. This action generates the workflow metadata information in the correct format and
stores on the clipboard.
5. Expand the Extensions folder in the Project window.
6. Right-click the Entity folder and select New→Entity from the menu.
Guidewire workflow 463
Guidewire PolicyCenter 9.0.9 Configuration Guide

7. Enter the name of the file to create in the New File dialog. Enter the same value that you entered in the New
Workflow subtype metadata dialog for Entity and add the eti extension. Studio then creates a new <entity>.eti
file.
Open this file, right-click, and choose Paste from the menu. Studio pastes in the metadata workflow that you
created in a previous step.
For example, if you extend Workflow and create a new workflow named NewWorkflow, then you must create a
new [Link] file that contains the following:
<?xml version="1.0"?>
<subtype desc="" entity="NewWorkflow" supertype="Workflow"/>

8. (Optional) To provide the ability to localize the new workflow, add the following line of code to this file (as
part of the subtype element):
<typekey desc="Language" name="Language" typelist="LanguageType"/>

Continuing the previous example, you now see the following:

<?xml version="1.0"?>
<subtype desc="" entity="NewWorkflow" supertype="Workflow">
<typekey desc="Language" name="Language" typelist="LanguageType"/>
<subtype>

9. Stop and restart Guidewire Studio so that it picks up your changes.

• You now see NewWorkflow listed in the Workflow typelist.
• You now see an NewWorkflow node under Resources→Workflows.
10. Select the NewWorkflow node under Workflows, right-click and select New Workflow Process from the menu.
Studio opens an empty workflow process that you can modify to meet your business needs.

Extending a workflow: a simple example

This simple examples illustrates the following steps:
• “Step 1: Extend an existing workflow object” on page 464
• “Step 2: Create a new workflow process” on page 464
• “Step 3: Populate Your workflow with steps and branches” on page 465

Step 1: Extend an existing workflow object

To extend an existing workflow object, review the steps outlined in “Extend an existing workflow” on page 463. For
this example, you create a new ExampleWorkflow object by extending (subtyping) the base Workflow entity.

To extend a workflow object

1. Create a new [Link] file and enter the following:
<?xml version="1.0"?>
<subtype desc="" entity="ExampleWorkflow" supertype="Workflow">
<typekey desc="Language" name="Language" typelist="LanguageType"/>
</subtype>

2. Close and restart Studio.

You now see an ExampleWorkflow entry added to the Workflow typelist and a new ExampleWorkflow workflow
type added to Workflows in the Resources tree.
After completing this task, complete “Step 2: Create a new workflow process” on page 464.

Step 2: Create a new workflow process

Before beginning this task, complete “Step 1: Extend an existing workflow object” on page 464.
Next, you need to create a new workflow process from your new ExampleWorkflow type.
464 chapter 31: Guidewire workflow
 Guidewire PolicyCenter 9.0.9 Configuration Guide

To create a new workflow process

1. Select ExampleWorkflow from Workflows in the Project window.
2. Right-click and select New Workflow from the menu.
Studio opens an outline view and layout view for the new workflow process:
• The outline view contains the few required workflow elements.
• The layout view contains a default outcome (DefaultOutcome).
After completing this task, complete “Step 3: Populate Your workflow with steps and branches” on page 465.

Step 3: Populate Your workflow with steps and branches

Before beginning this task, complete “Step 2: Create a new workflow process” on page 464.
Finally, to be useful, you need to add outcomes, steps, and branches to your workflow. This examples creates the
following:
• A Step1 (AutoStep Workflow Step) with a default GO branch to the DefaultOutcome step, which you designate
as the first step in the <Start> Workflow Element element
• A Step2 (ManualStep Workflow Step) with a TRIGGER branch to the DefaultOutcome step
• A Step3 (ActivityStep Workflow Step) with a GO branch to the DefaultOutcome step
• A TIMEOUT branch from Step2 to Step3, with a 5d time delta set
• A Step4 (MessageStep Workflow Step) with a “GO” on page 459 branch from Step1 to Step4
The example workflow looks similar to the following:

This example does not actually perform any function. It simply illustrates how to work with the dialogs of the
Workflows editor.

To add steps and branches to a workflow

1. Right-click within an empty area in the layout view and select New AutoStep from the menu:
• For Step ID, enter Step1.
• Do not enter anything for the other fields.
Studio adds your autostep to the layout view and connects Step1 to DefaultOutcome with a default “GO” on
page 459 branch.
1. Select <Start> Workflow Element in the outline view (middle pane):
• Open the First Step drop-down in the property area at the bottom of the screen.
• Select Step1 from the list. This sets the initial workflow step to Step1.
• Save your work.
Guidewire workflow 465
Guidewire PolicyCenter 9.0.9 Configuration Guide

2. Right-click within an empty area in the layout view and select New ManualStep from the menu:
• For Step ID, enter Step2.
• For branch Type, select TRIGGER.
• For trigger ID, select Cancel.
The ID value sets a valid trigger key as defined in typelist WorkflowTriggerKey. If Cancel does not exist, then
choose another trigger key. If no trigger keys exist in WorkflowTriggerKey, then you must create one before you
can select TRIGGER as the type.
1. Select the GO branch (the line) leaving Step1:
• In the property area at the bottom of the screen, change the To field from DefaultOutcome to Step2. Studio
moves the branch to link the specified steps.
• Realign the steps for more symmetry, if you choose.
2. Right-click within an empty area in the layout view and select New ActivityStep from the menu:
• For Step ID, enter Step3.
• For Name, enter ActivityPatternName.
• For Pattern, enter NewActivityPattern.
3. Select Step3, right-click, and select New TIMEOUT from the menu:
• For Branch ID, enter TimeoutBranch.
• For Time Delta, enter 5d. This sets the absolute time to wait to five days.
• For To, select Step3.
Studio adds a branch from Step2 to Step3 and adds the timeout symbol to it.
1. Right-click within an empty area in the layout view and select New MessageStep from the menu:
• For Step ID, enter Step4.
• For Dest ID, enter 89 (or any valid message destination ID).
• For Event Name, enter EventName.
Studio adds the step to the layout view and creates a link between Step4 and DefaultOutcome.
1. Select the new link from Step4 to DefaultOutcome.
• In the property area at the bottom of the screen, change Arrow Visible to false to delete this link.
Studio removes the link (branch).
1. Select Step1, right-click, and select New GO from the menu:
• For Branch ID, enter Step4.
• For To, select Step4.
Studio adds the new GO branch between Step1 and Step4.

Instantiating a workflow
It is not sufficient to create a workflow. Generally, you want to do something moderately useful with it. To perform
work, you must instantiate your workflow and call it somehow.
Suppose, for example, that you create a new workflow and call it, for lack of a better name, HelloWorld1. You can
then instantiate your workflow using the following Gosu:
var workflow = new HelloWorld1()
[Link]()

Starting a workflow
There are multiple workflow start methods. The following list describes them.

start() Starts the workflow.

466 chapter 31: Guidewire workflow

 Guidewire PolicyCenter 9.0.9 Configuration Guide

start(version) Starts the workflow with the specified process version.

startAsynchronously() Starts the workflow asynchronously.
startAsynchronously(version) Starts the workflow with the specified process version asynchronously.

See also
• “Workflow versioning” on page 448

Logging workflow actions

There are several different Gosu statements that you can use to view workflow-related information.

[Link] Statement written to the application server log

[Link] Statements viewable in the PolicyCenterWorkflow console

See Also
• “Workflow debugging, logging, and testing” on page 474

A simple example of instantiation

The following example creates a trivial workflow named HelloWorld1. The objective of this example is not to show
the branching structure that you can create in workflow. Rather, the purpose of this exercise is to construct the
workflow, trigger the workflow, and examine the workflow in the PolicyCenterWorkflow console. The example keeps
the workflow as simple as possible. The workflow consists of the following components:
• <Context> Workflow Element
• <Start> Workflow Element
• Step1
• Step2
• DefaultOutcome
• <Finish> Workflow Element

A Simple ClaimCenter Example

Note: This example uses business entities and rules that apply specifically to the Guidewire
ClaimCenter application. However, the particular business objects are not important. What is more
important is how you create and instantiate a workflow process.
For the workflow to run and do some work and appear on the workflow console, the example instantiates it from a
Claim Update rule. If you attempt to instantiate the workflow from a link or button on a Claim view screen (Claim
Summary, for example) the workflow executes but does not update anything. Also, it does not appear in the Workflow
console.
To cause updates to happen, the example instantiates the workflow from an Edit screen in ClaimCenter. It then calls a
Claim Pre-Update Rule in Studio.

To create a simple workflow and instantiate it

1. Create a [Link] file (in Extensions→Entity) and populate it with the following:
<?xml version="1.0"?>
<subtype desc="HelloWorld 1 Example Workflow"
entity="HelloWorld1"
supertype="ClaimWorkflow">
<typekey desc="Language" name="Language" typelist="LanguageType"/>
</subtype>

2. Stop and restart Studio.

Guidewire workflow 467
Guidewire PolicyCenter 9.0.9 Configuration Guide

3. Select your new workflow type from the Workflows node. Right-click and select New→Workflow Process.
4. Create a simple workflow process similar to the following. It does not need to be complex, as it simply
illustrates how to start a workflow from the ClaimCenter interface.

Notice that it has a claim symbol set in “<Context> workflow element” on page 450.
1. For Step1, add the following to the Enter block for that step:
[Link]( "HelloWorld1 step 1, step called ClaimNumber " + [Link])
[Link]( "HelloWorld Step 1", "HelloWorld1 step 1 entered: Claim Number " + [Link] )

2. For Step2, add the following to the Enter block for that step:
[Link]( "HelloWorld1 step 2, step called ClaimNumber " + [Link])
[Link]( "HelloWorld Step 2", "HelloWorld1 step 2 entered: Claim Number " + [Link] )

3. Create a simple Claim Pre-Update rule similar to the following:

• The rule condition specifies that PolicyCenter instantiates the workflow only if the claim
PermissionRequired property is set to fraudriskclaim.
• The rule action instantiates the HelloWorld1 workflow. It first tests for an existing HelloWorld1 workflow
that is not in the completed state and that has the same claim number as the one being updated. If it does not
find a matching workflow, then PolicyCenter instantiates HelloWorld1 and logs the information.
Rule Conditions:
[Link]=="fraudriskclaim"

Rule Actions:
[Link]( "Entering Pre-Update" )

var hw_wf = [Link]( \ c -> [Link] == "HelloWorld1"

&& (c as entity.HelloWorld1).State !="completed"
&& (c as entity.HelloWorld1).[Link]==[Link])

if (hw_wf == null) {
[Link]( "## Studio instantiating HelloWorld1 and starting it!" )
var workflow = new entity.HelloWorld1()
[Link] = claim
[Link]()
}

1. Log into ClaimCenter and open any sample claim.

2. Navigate to the Claim Summary page, then select the Claim Status tab.
3. Click Edit and set the Special Claim Permission value to Fraud risk.
4. Click Update. This action triggers the HelloWorld1 workflow.

468 chapter 31: Guidewire workflow

 Guidewire PolicyCenter 9.0.9 Configuration Guide

To view the server console

1. Navigate to the application server console.

2. View the logger statements.

To view the Workflow console

1. Log into ClaimCenter using an administrative account.

2. Navigate to the Administration tab and select Workflows from the left-side menu.
3. Click Search in the Find Workflows screen. You do not need to enter any search information. Studio displays a
list of workflows, including HelloWorld1.
4. Select HelloWorld1 from the list and view its details.

The workflow engine

The workflow engine is responsible for processing a workflow. It does this by looking up and executing the
appropriate workflow process script. This script (often just called workflow process or workflow script) is an XML
file that the Studio workflow editor generates, and which you manage in Studio. The base configuration workflow
scripts are in the modules/configuration/config/workflow directory.

Distributed execution
PolicyCenter uses a work queue to handle workflow execution. This, in simple terms, means that you can have a
whole cluster of machines that:
• Wake up internal Workflow instances,
• Advance them as far as they can go,
• Then, let them go back to sleep if they need to wait on a timeout or activity.
Asynchronous workflow execution always works the same way:
1. PolicyCenter creates a WorkflowWorkItem instance to advance the workflow.
2. The worker instance picks up the work item.
3. The work item retrieves the workflow and advances it as far as possible (to a ManualStep or Outcome).
You can create a work item in any of the following different ways:
• By a call to the [Link] method
• By invoking a trigger with asynchronous = true
• By completing a workflow-linked activity
• By the Workflow batch process, which queries for active workflows waiting on an expired timeout
• By a call to [Link], typically initiated by an administrator using the workflow management
tool
After the workflow advances as far as it can, PolicyCenter deletes the work item and execution stops until there is
another work item.

Synchronicity, transactions, and errors

Error handling for workflows depends on whether the workflow is running synchronously or asynchronously.

Guidewire workflow 469

Guidewire PolicyCenter 9.0.9 Configuration Guide

Synchronous and asynchronous workflow

It is possible to start workflow either synchronously or asynchronously. To do so, use one of the start methods
described in “Instantiating a workflow” on page 466. These methods are:
• start()
• start(version)
• startAsynchronously()
• startAsynchronously(version)
If a workflow runs synchronously, then it continues to go through one AutoStep Workflow Step or ManualStep
Workflow Step after another until it arrives at a stop condition. This advance through the workflow can encompass
one or multiple steps. The workflow executes the current step (unless there is an error), and then continues to the
next step, if possible. There can be many different reasons that a workflow cannot continue to the next step.
For example, the workflow can encounter:
• An activity step (ActivityStep Workflow Step), which can result in the creation of one or more activities,
causing the workflow to pause until the closure of all the activities.
• A communication step (MessageStep Workflow Step), which can result in a message being sent to another
system, causing the workflow to wait until receiving a response.
• A step that stipulates a timeout (ManualStep Workflow Step), which causes the workflow to wait for the
timeout to complete.
• It can encounter a step that requires a trigger (ManualStep Workflow Step), which causes the workflow to wait
until someone (or something) activates the trigger.
Ultimately, the workflow can run until it reaches an Outcome Workflow Step, at which point, it is done.
After pausing, the workflow waits for one of the following to occur:
• If waiting on one or more activities to complete, the workflow continues after the closure of the last activity.
• If waiting for an acknowledgment of a message, the workflow continues after receiving the appropriate response.
• If waiting on a timeout, the workflow continues after the timeout elapses.
• If waiting on an external trigger, then someone or something must manually invoke a TRIGGER from outside the
workflow infrastructure. Invoking a trigger can be done either from the PolicyCenter interface, such as a user
clicking a button, or from Gosu. In either case, the trigger is invoked through a call to the invokeTrigger
method on a Workflow instance.
The action of completing an activity or the receipt of a message response automatically creates a work item to
advance the workflow. A background batch process checks for timeout elements. The batch process is responsible
for finding timed-out workflows that are ready to advance and creating a work item to advance them.

The invokeTrigger method

If a user (or Gosu code) invokes an available trigger (TRIGGER) on a ManualStep Workflow Step, the workflow can
execute either synchronously or asynchronously. A Boolean parameter in the invokeTrigger method determines the
execution type. This method takes the following signature:
void invokeTrigger(WorkflowTrigger triggerKey, boolean synchronous)

For example (from PolicyCenter):

[Link]( trigger, false )

The trigger parameter defines the TRIGGER to use. It must be a valid trigger defined in the WorkflowTriggerKey
typelist.
The synchronous value in this method has the following meanings:

true (Default) Instructs the workflow to immediately execute in the current transaction and to block the call‐
ing code until the workflow encounters a new stopping point.

470 chapter 31: Guidewire workflow

 Guidewire PolicyCenter 9.0.9 Configuration Guide

false Instructs the workflow to run in the background, with the calling code continuing to execute. The work‐
flow continues until it encounters a new stopping point.

Trigger availability

For a trigger to be available, the workflow execution sequence must select a branch for which both of the following
conditions are true:
• A trigger must exist on the step.
• There is no other determinable path, which usually means that no timeout has already expired.
If both these conditions are true, after an invocation to the invokeTrigger method, the Workflow engine starts to
advance the workflow from the selected branch again.

Invoking a trigger

Invoking a trigger (either synchronously or asynchronously) does the following:

1. It updates the workflow. Any changes made to a transaction bundle that were committed by the actual
invocation of the trigger, are committed.
2. It causes the workflow to create a log entry of the trigger request. If there is an error in the workflow advance,
any request to the workflow to resume causes the process to start again.
3. If the Workflow engine determines that all the preconditions are met for continuing, it does the following:
a. It determines the locale in which to execute.
This is the locale that PolicyCenter uses for display keys, dates, numbers, and other similar items. By
default, this is the application default locale. It is important for the Workflow engine to determine the
locale as it is possible to override this locale for any specific workflow subtype. You can also override the
locale in the workflow definition on the workflow element.
4. It steps through each of the workflow steps (meaning that it performs all the actions within that step) until it
cannot keep going.
5. It commits the transaction associated with the executed steps to the database.

Error handling and transaction rollback

If there is an error during a workflow step, the Workflow engine rolls the database back and leaves it in the state that
it was previously in. If working with an external system, you need to do one of the following:
• Design the services in the external system.
• Use the Guidewire message subsystem to keep an external system state in synchronization with the application
database state.
It is important to understand whether a workflow executes synchronously or asynchronously because the type of
execution affects errors and transaction rollbacks.

Execution type Application behavior

Synchronous If any exception occurs during synchronous execution, even after the workflow has gone through
several steps, PolicyCenter rolls back all workflow steps, along with everything else in the bundle.
The error cascades all the way up to the calling code, which is the code that started the workflow or
invoked the trigger on the workflow.
• If you start the workflow or invoke the trigger from the PolicyCenter interface, PolicyCenter
displays the exception in the interface.
• If some other code started the workflow, that code receives the exception.
Asynchronous If any exception occurs during asynchronous execution (as it executes in the background),
PolicyCenter logs the exception and rolls back the bundle, in a similar manner to the synchronous
case.
Guidewire workflow 471
Guidewire PolicyCenter 9.0.9 Configuration Guide

Execution type Application behavior

PolicyCenter then handles workflow retries in the standard way through the worker. PolicyCenter
leaves the work item used to advance the workflow checked out. It simply waits until the
progressinterval defined for the workflow work queue expires. At that point, a worker picks it up
and retries it. The work queue configuration limits the number of retries. If all retries fail,
PolicyCenter marks the work item as failed and it puts the workflow into the Error state. A workflow
in the Error state merely sits idle until you restore it from the Administration tab within PolicyCenter.
Restoring the workflow creates another work item.
After you manually restore a workflow from an Error to an Active state, it again tries to resume
whatever it was doing as it left off, such as:
• Entering the step
• Following the branch
• Attempting to perform whatever it was doing at the time the exception occurred
Of course, if you have not corrected the problem that caused the error, then the workflow can drop
back into Error state again. It does so only after the work item performs its specified number of
retries.

Workflow guidelines
In practice, Guidewire recommends that you keep the following guidelines in mind as you work with workflows:
• If you invoke a workflow TRIGGER, do so synchronously if you need to make immediate use (in code) of the
results of that trigger. For this reason, the PolicyCenter rendering framework typically always invokes the trigger
synchronously. But notice that you only get immediate results from an AutoStep Workflow Step that might
have executed. If the workflow encounters a ManualStep Workflow Step or an ActivityStep Workflow Step,
it immediately goes into the background.
• If you complete an activity, it does not synchronously (meaning immediately) advance the workflow. Instead, a
background process checks for workflows whose activities are complete and which are therefore ready to move
forward. Guidewire provides this behavior, as otherwise, if an error occurs, the user who completes the activity
sees the error, which is possibly confusing for that user.
• If you invoke a workflow TRIGGER from code that does not necessarily care whether there was a failure in the
workflow, you need to invoke the TRIGGER asynchronously. (You do this by setting the synchronous value in the
workflow method to false.) That way, the workflow advances in the background and any errors it encounters
force the workflow into the Error state. The exception does not affect the caller code. However, the calling code
creates an exception if it tries to invoke an unavailable or non-existent workflow TRIGGER. Messaging plugins, in
particular, need to always invoke triggers asynchronously.

Workflow subflows
A workflow can create another child workflow in Gosu by using the scriptable createSubFlow method on
Workflow. There are multiple versions of this method:
[Link](workflow)
[Link](workflow, version)

A subflow has the same foreign keys to business data as the parent flow. It also has an edge foreign key reference to
the caller Workflow instance, accessed as [Link]. (If internal code, and not some other workflow, calls a
macro workflow, this field is null.)
Each workflow also has a subFlow array that lists all the flows created by the workflow, including the completed
ones. (This array is empty for workflows that have yet to create any subflows.) The Gosu to access this array is:
[Link]

You can use subflows to implement simple parallelism in internal workflows, which is otherwise impossible as a
single workflow instance cannot be in two steps simultaneously. For example, it is possible for the macro flow to
create a subflow in step A. It can then leave this subflow to do its own work, and only wait for it to complete in step
472 chapter 31: Guidewire workflow
 Guidewire PolicyCenter 9.0.9 Configuration Guide

E. It is your responsibility as the one configuring the macro workflow to decide how to react if a subflow drops into
Error mode or becomes canceled for some reason.

See also
• Globalization Guide

Workflow administration
You can administer workflow in any of the following ways:
• Through the PolicyCenterAdministration→Workflows page
• Through the command line, such as running a batch process to purge the workflow logs
• Through class [Link], which the command line uses
The most likely need for using the PolicyCenterAdministration interface is error handling. Errors can include the
following:
• A few workflows fail
• In a worst case scenario, thousands of workflows fail simultaneously
Finding workflows that have not failed but have been idling for an extremely long time is also likely. A secondary
use is just looking at all the current running flows to see how they work. Guidewire therefore organizes the
Administration interface for workflow around a search screen for searching for workflow instances. You can filter the
search screen, for example, by instance type, state (especially Error state), work item, last modified time, and
similar criteria.
A user with administrative permissions can search for workflows from the Administration→Workflows page. However,
to actually manage workflows, that user must have the workflowmanage permission. In the base PolicyCenter
configuration, only the superuser role has this permission.
With the correct permission, you can do the following from the Administration→Workflows page:
• Search for a specific workflow or see a list of all workflows:
• Look at an individual workflow details, for example:
◦ View its log and current step and action
◦ View any open activities on the workflow
• Actively manage a workflow

Manage workflow
If you have the workflowmanage permission, PolicyCenter enables the following choices on the Find Workflows page:
• Manage selected workflows (active after you select one or more workflows)
• Manage all workflows (active at all times with the correct permission)
Choosing one of these options opens the Manage Workflows page. This page presents a choice of workflow and step
appropriate commands that you can execute. It is only possible to select one command (radio button) at a time.
Choosing either Invoke Trigger or Timeout Branch provides further selection choices.

Command Description
Wait - max Select and enter a time to force the workflow to wait until either that amount of time has expired or the cur‐
time (secs) rently active work item is no longer active. (The work item has failed or has succeeded and has been deleted.)
This option is only available if there is a currently available work item on this workflow.
Invoke Trigger Select to chose a workflow trigger to invoke. After selecting this command, PolicyCenter presents a list of availa‐
ble triggers from which to choose, if any are available on this workflow.
Suspend Select to suspend any active workflows that are currently selected in the previous screen. After you execute this
command, PolicyCenter suspends the selected workflows. This action is appropriate for all workflow and steps.
However, PolicyCenter executes this command only against active workflows.

Guidewire workflow 473

Guidewire PolicyCenter 9.0.9 Configuration Guide

Command Description
Resume Select to resume workflow execution of any suspended workflows that are currently selected in the previous
screen. This action is appropriate for all workflows and steps.
Timeout Select to choose a workflow timeout branch. After selecting this command, PolicyCenter presents a list of time‐
branch out branches from which to choose, if any are available on this workflow.

After you make your selection and add any relevant parameters, clicking Execute immediately executes that
command. Using these commands, you can:
• Restore workflows from the Error or Suspended state back to the Active state. However, if you have not
corrected the underlying error, presumably a scripting error, the workflow might drop right back into Error
mode.
• Force a waiting workflow to execute:
◦ By setting the specific timeout branch
◦ By setting a specific trigger
• Force an active workflow to wait for a specified amount of time

Workflow Statistics tab

PolicyCenter collects workflow statistics periodically and captures the elapse and execution time for individual
workflow types and steps. You can search by workflow type and date range.

Workflow and server tools

Those with access to the Server Tools, can also access the following:

Batch Process In- Use to view information on the last run‐time of a writer, and to see the schedule for its next run‐time. From
fo this page, you also have the ability to stop and start the scheduling of the writer.
Work Queue Info Use to view information on a writer, what items it picked up and the workers. From this page, you also have
the ability to notify, start and stop workers across the cluster.

Workflow debugging, logging, and testing

Debugging a workflow is a more challenging task than debugging the standard PolicyCenter interface flow, as most
of the work happens asynchronously, away from any user. Currently, there is no way to set breakpoints in a
workflow in a similar fashion to how you can set a breakpoint for a Gosu rule or class.
Guidewire does provide, however, workflow logging. Each instance of a workflow has its own internal log that you
can view from within PolicyCenter. (You access this log from Workflows page by first by finding a workflow, then by
clicking on the Workflow Type link.) This log includes successful transitions in the current step and action. It also
contains any exceptions. Workflow can access this log, but PolicyCenter only commits these log message with the
bundle.
Use the following logging method, for example, in an Enter Script block to log the current workflow step:
[Link](summary, description)

The method returns the log entry (WorkflowLogEntry) that you can use for additional processing:
var workflowLog = [Link]("short description", "stack trace ...")
var summary = [Link]

Process logging
The following logging categories can be useful:
474 chapter 31: Guidewire workflow
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Category Use for

WorkQueue A category for general logging from the work queue.
[Link] Capturing of runner state for a specific execution of the runner.

[Link] Logging (by workers) of each work item executed at the “info” level.
[Link] Logging runners.

To write every message logged by every workflow, set the logging level of the workflow logger category to DEBUG
(using [Link]). The directive in the [Link] file is:
[Link]=DEBUG

Workflow testing
It can often be difficult to test a workflow. This is especially true for one that is asynchronous and that requires the
workflow to wait a specific amount of time before advancing to the next step. To facilitate testing, Guidewire
PolicyCenter supports a testing clock that permits the advancing of time (for development-mode servers only). If
you have permission, you can access this functionality from the (unsupported) PolicyCenter Internal Tools page.
Depending on which clock you define in the [Link] plugin registration file, you can do one of the
following:
• Increment the current clock by a given period.
• Change the setting of the clock to a specific time. The clock remains at that time until another specific time is set.

Enable the ITestingClock plugin

Before you begin
If the ITestingClock plugin is not already implemented, then you need to implement it.

Procedure
1. In Studio, navigate to Plugins→gw→plugin→system.
2. Right-click ITestingClock, and select Implement.
3. Click Add→Java.
4. Type the following in the Class field:
[Link]

Guidewire workflow 475

Guidewire PolicyCenter 9.0.9 Configuration Guide

476 chapter 31: Guidewire workflow

chapter 32

Defining activity patterns

This topic discusses activity patterns, what they are, and how to configure them.

What is an activity pattern?

Activity patterns standardize the way that Guidewire PolicyCenter creates activities. Activity patterns describe the
kinds of activities that people perform while handling policies within an organization. For example, reviewing and
approving a policy renewal is a common activity. Thus, it has its own activity pattern that creates a reminder to
perform this activity.
Patterns act as templates for creating activities. Activity patterns define the typical practices for each activity. For
example, this is its name, its relative priority, and the standards for how quickly it is to complete (that is, its due
dates). If a user (or a rule) adds an activity to the workplan for a policy, PolicyCenter uses the activity pattern as a
template to set default values for the activity. (For example, an activity pattern can set the subject, priority, or target
date for the activity.)
You can set up and customize the Activity Patterns that make sense for your policies business processes from the
Administration tab in PolicyCenter. It is possible to create activities from activity patterns in different ways:
• You can manually create activities in PolicyCenter.
• A business rule or some other Gosu code create activities as part of generating workplans or while responding to
escalations, policy exceptions, or other events.
• PolicyCenter automatically creates activities to handle manual assignment or approvals, for example.
• External applications create activities through API calls.
You can view the list of available Activity Patterns by selecting New Activity from the Actions menu on one of the
Summary pages.

IMPORTANT After an activity pattern is in production, do not delete it as there can be old activities
tied to it. Instead, edit the activity pattern and change the Automated only field to Yes. This prevents
anyone from creating new activities of that type.

An activity pattern does not control how PolicyCenter assigns an activity. Instead, activity assignment methods in
Gosu expressions control how PolicyCenter assigns an activity. Using the pattern name, the assignment methods
determine to whom to assign the activity.

Defining activity patterns 477

Guidewire PolicyCenter 9.0.9 Configuration Guide

Pattern types and categories

PolicyCenter applies a type attribute to every activity pattern. You can also use a category attribute to classify
patterns into related groups. This topic describes how PolicyCenter makes use of these two attributes.

Activity pattern types

Each activity pattern has a set type, for example, General or Approval. It is only possible to add a custom activity
pattern of type General or Assignment Review through the PolicyCenter interface. It is not possible, for example, to
create a custom Approval activity pattern through the PolicyCenter Activity Patterns screen.
Guidewire defines a number of internal activity pattern types in the base configuration. All pattern types other than
General or Assignment Review are internal. Only internal PolicyCenter code can use an internal pattern type. Do not
attempt to remove an internal activity pattern type as this can damage your installation. You can, however, customize
attributes of the internal activity patterns, such as adjusting the due date.

The ActivityType typelist

Guidewire defines activity pattern types in the ActivityType typelist. Guidewire defines this typelist as final.
Typelists marked as final are internal typelists and used by internal application code. You cannot add typecodes to—
or delete typecodes from—a typelist marked as final. You can, however, modify some of the fields on an existing
typecode, if you wish. For more information on typelists marked as final, see “Internal typelists” on page 306.
Any pre-existing activity patterns of type General in the base configuration are examples that Guidewire provides.
You can fully customize any of them. Activity patterns with other activity types are typically not available in the
PolicyCenter interface. You use them only within Gosu and PolicyCenter uses them internally.

Categorizing activity patterns

About this task
Guidewire recommends that you categorize your activity patterns so that it is possible to choose among the different
activity categories during new activity creation. These categories serve as the first level of navigation in the
PolicyCenter New Activity menu. The activity pattern categories appear only within the PolicyCenter interface.
The ActivityCategory Typelist
Guidewire defines activity categories in the ActivityCategory typelist. You are free to add or delete typecodes
from this typelist. If you change a typelist, remember that you must restart the application server to view your
changes in the PolicyCenter interface.
PolicyCenter displays the activity categories in the New Activity Pattern editor screen.

Using activity patterns in Gosu

About this task

IMPORTANT You must use the activity pattern code to refer to an activity pattern in Gosu code. Do
not use a pattern ID or PublicID value.

There are two operations that you can perform in Gosu involving activity patterns:
• One is to test which activity pattern an existing activity uses.
• The other is to retrieve an activity pattern for use in creating a new activity.
To test for a specific activity pattern
Use the following Gosu code, which compares an activity pattern Code value with a string value that you supply.
[Link] == "activity_pattern_code"

478 chapter 32: Defining activity patterns

 Guidewire PolicyCenter 9.0.9 Configuration Guide

To retrieve an activity pattern

To find (retrieve) a specific activity pattern, use one of the following Gosu find or get methods. The find method
returns a query object and the get method returns an ActivityPattern object.

Calculating activity due dates

The activity made from a pattern always has a specific date as a deadline. Each activity pattern defines how to
calculate the due date for a specific activity instance.

Target due dates (deadlines)

A target date (or due date) suggests the date to complete an activity. Settings in the New Activity Pattern editor
determine how PolicyCenter calculates the due date for an activity. PolicyCenter can calculate a target due date in
hours or days. PolicyCenter calculates due dates using the following pieces of information:
• How much time? How much time to take or how many hours or days to allow to complete the activity. You
specify this using the Target days or Target hours value.
• What is the starting point? What point in time does PolicyCenter use as the start point in calculating the target
date? You specify this using the Target start point field.
• What days to count? PolicyCenter can count calendar days or only business days. You specify this with the Target
Include Days field.
PolicyCenter reports deadlines only at the level of days. For example, if something is due on 6/1/2008, it becomes
overdue on 6/2/2008, not some time in the middle of the day on 6/1. PolicyCenter does track activity creation dates
and marks completion at the level of seconds so that you can calculate average completion times at a more granular
level.
If you do not specify Target Days or Target Hours as you define an Activity Pattern Detail, PolicyCenter uses 0 for both. A
target date is optional for activities.
The maximum number of hours that you can specify is 23, and the maximum number of days that you can specify is
1825. Any value greater than the maximum is automatically limited to the maximum.

Escalation dates
While the target date can indicate a service-level target (for example, complete within five business days), there can
possibly be some later deadline after which the work becomes dangerously late. (This can be, for example, a 30 day
state deadline.) PolicyCenter calls this later deadline an escalation date.
The escalation date is the date at which activity requires urgent attention. While work is shown as overdue after the
target date, PolicyCenter does not actually escalate (take action on) an activity until the escalation date passes.
Within Studio, you can define a set of rules that define what actions take place if an activity reaches its escalation
date. For example, it could be company policy to inform a supervisor if an activity passes an escalation date. You
might also want to reassign the activity.
PolicyCenter calculates the escalation date using the methodology it uses for target dates. You can specify escalation
timing in days and hours. If you do not specify Escalation Days or Escalation Hours as you define an activity pattern,
PolicyCenter uses 0 (zero) for both. An escalation date, like a target date, is optional for activities.
The maximum number of hours that you can specify is 23, and the maximum number of days that you can specify is
1825. Any value greater than the maximum is automatically limited to the maximum.

Base configuration activity patterns

PolicyCenter uses file [Link] to load the base activity pattern definitions upon initial server
startup after installation. You access file [Link] in Guidewire Studio in the following location:
configuration→config→import→gen
Defining activity patterns 479
Guidewire PolicyCenter 9.0.9 Configuration Guide

IMPORTANT Do not remove any internal (non-General type) activity patterns or change their type,
category, or code values. Internal PolicyCenter application code requires them. You can change other
fields associated with these types, however.

See also

• System Administration Guide

Activity pattern objects

The following list describes the properties on the ActivityPattern object.

Property User inter‐ Description

face field
ActivityClass Activity Class Indicates whether the activity is a task or an event. A task has a due date. An event does
not.
AutomatedOnly Automated A Boolean value that defines whether only automated additions (by business rules) to
only the workplan use the activity pattern.
• If true, the activity pattern does not appear as a choice in PolicyCenter interface.
• If you do not specify this value, the default is false.
Guidewire recommends that you set this flag set to true for all patterns with a non‐
general type. This ensures that they are not visible in the PolicyCenter interface.
Category Category The category for grouping ActivityPatterns in the PolicyCenter interface.
Code Code Any unique text with no spaces. Maximum length is 60 characters. This property is re‐
quired. The Code property is used to identify the activity pattern when accessing the pat‐
tern in rules or Gosu code. You can see this value only through the Administration tab.
Command Not Applica‐ Do not use. For Guidewire use only.
ble
Data-Set Not Applica‐ The value of the highest‐numbered data set of which the imported object is a part.
ble PolicyCenter typically orders a data set by inclusion. Thus, data set 0 is a subset of data‐
set 1, and data set 1 is a subset of data set 2, and so forth.
Description Description Describes the expected outcome at the completion of this activity. It is visible only if you
view the details of the activity.
DocumentTemplate Document Document template to display if you choose this activity. Enter the document template
Template ID.
EmailTemplate Email Tem- Email template to display if you choose this activity. Enter the email template file name.
plate

EntityId Not Applica‐ Required. The unique public ID of the activity pattern.
ble
EscalationDays Escalation The number of days from the escalationstartpt to set the Escalation Date for an activity.
days

EscalationHours Escalation The number of hours from the escalationstartpt to set the Escalation Date for an activi‐
hours ty.
EscalationInclDays Escalation In- Specifies which days to include. You can set this businessdays or elapsed.
clude Days

EscalationStartPt Escalation The initial date used to calculate the target date. If you specify escalationdays or
start point escalationhours, you need to specify this parameter. Otherwise, this parameter is op‐
tional.

480 chapter 32: Defining activity patterns

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Property User inter‐ Description

face field
Mandatory Mandatory A Boolean value that defines whether you can skip an activity. Non‐mandatory activities
act as suggestions about what might be a useful task without forcing you into doing un‐
necessary work. This value is optional. If you do not specify a value, the application uses
a default of true.
PatternLevel Pattern Level The level that this pattern is for. Valid choices are:
• Account
• All
• Job
Priority Priority Used to sort more important activities to the top of a list of work. This property is re‐
quired. You can set this property to the following values:
• urgent
• high
• normal
• low.
Recurring Recurring A Boolean value indicating that an activity is likely to recur on a regular schedule. If you
do not specify a value, the application uses a default of true.
ShortSubject Short Subject A brief description of the activity used on small areas of the PolicyCenter interface such
as a calendar event entry. Maximum length of 10 characters.
Subject Subject A short text description of the activity that PolicyCenter shows in activity lists. This prop‐
erty is required.
TargetDays Target days The number of days from the targetstartpoint to set the activity’s Target Date.
TargetHours Target hours The number of hours from the targetstartpoint to set the activity’s Target Date.
TargetIncludeDays Target Include This field answers the “what days to count” part of calculating the target date. Your op‐
Days tions are the following:
• elapsed—the count all days
• businessdays—as defined by the business calendar
TargetStartPoint Target start The initial date used to calculate the target date. You need specify this value only if you
point specify targetdays or targethours. Otherwise, this value is optional.
Type Type This specifies what activity type to create.
Note It is only possible to create a custom activity pattern of type General or Assignment
Review. Guidewire reserves all other activity pattern types for internal use. See “Pattern
types and categories” on page 478 for more information.

Use activity patterns with documents and emails

About this task

You can attach a document or email template to an activity pattern. Then, if PolicyCenter displays an activity based
on this activity pattern, it also displays a Create Document or Create Email button in the Activity Detail worksheet. This
button indicates that this type of activity typically has a document or email associated with that activity.

To associate a document or email template with an activity pattern:

Procedure

1. Log into Guidewire PolicyCenter with an administrative account.

2. Click the Administration tab and navigate in the Sidebar to Business Settings→Activity Patterns.
Defining activity patterns 481
Guidewire PolicyCenter 9.0.9 Configuration Guide

3. Open the activity pattern edit screen either by creating a new activity pattern or by selecting an activity pattern
to update.
• To create a new activity pattern, click New Activity Pattern.
• To edit an existing activity pattern, click the activity pattern name, and then click Edit.
4. Use the search icon next to the Document Template or Email Template field to open a search window.
5. Find the document or email template, and then add it to the activity pattern.

Result
If you associate a document or email template with an activity pattern, you can do the following in PolicyCenter:
1. If you create a new activity from this activity pattern, PolicyCenter automatically populates any template field
for which you specified a template with the name of that template.
2. If you open this activity, PolicyCenter displays a Create Document button or a Create Email button or both in
the Activity Detail worksheet at the bottom of the screen.
3. If you then click the Create Document or the Create Email button, PolicyCenter opens a pop-up window enabling
you to create the document or email from the specified template.

Specifying document and email templates in CSV files

You can also specify the document or email template in file [Link]. Add a column for that
template and then enter either the document template ID or the email template file name as appropriate. See “Base
configuration activity patterns” on page 479 for details of working with the [Link] file.

Localizing activity patterns

PolicyCenter stores activity pattern data directly in the database. Thus, it is not possible to localize fields such as the
subject or description of an activity pattern by localizing a display string. In the base configuration, you can localize
the following activity pattern properties through the PolicyCenter interface—if you configure PolicyCenter for
multiple locales:
• Description
• Subject
If you configure PolicyCenter correctly to use multiple locales, then you see additional fields at the bottom of the
New Activity Pattern screen. You use these fields to enter localized subject and description text for that activity pattern.

See also
• For information on how to make a database column localizable (and thus, an object property localizable), see the
Globalization Guide.

482 chapter 32: Defining activity patterns

chapter 33

Guidewire PolicyCenter and Email

Guidewire includes support for sending emails from PolicyCenter. Sending an email is one of several possible
actions to take, for example, if a user escalates an activity.
The email includes the following items:
• To and From properties
• A subject
• The name of the template used to generate the body of the email
• The object that the message references
PolicyCenter initially saves email messages and then sends them to an SMTP email server in a background process.

Emails and Gosu code

You can send an email from any Gosu code. Thus, you can create and send an email from Gosu rules or in Gosu
embedded in the PolicyCenter PCF screens.

PolicyCenter email support

PolicyCenter provides support for the following email functionality:
• Support for various types of email recipients (To, CC, and BCC)
• Support for templates that can be used to populate the subject and body of the email
• Support for attaching documents stored in the configured DMS (Document Management System) to the email
message
• Support for SMTP authentication using the JavaxEmailMessageTransport class, which supports encryption

Monitoring email messages

Because PolicyCenter sends email messages using the same integration infrastructure as event-based messages, you
can use the same administrative tools for monitoring the status of messages. The PolicyCenter Message Queues
screen, available to administrators, provides information on the various message destinations, including the Email
message destination. In addition, PolicyCenter provides a Messages screen in which you can search for, and view,
information on various message types, including email messages.

Default email plugin implementation

Guidewire provides a default email message plugin named emailMessageTransport. To set PolicyCenter for email
notifications, configure the plugin parameters in Guidewire Studio.
Guidewire PolicyCenter and Email 483
Guidewire PolicyCenter 9.0.9 Configuration Guide

Configure the email plugin class and parameters

Configure the class and parameters that affect the email plugin in the Studio Plugin Editor.

Procedure
1. In the Guidewire Studio Project window, expand configuration→config→Plugins→registry.
2. Double-click emailMessageTransport to open it.
3. If the Java Class is [Link], change the class
that implements the plugin:
a. Click Remove Plugin to remove the class.
b. To use the supported Gosu plugin class in the base configuration, click Add Plugin , and then click Add
Gosu Plugin.
c. In Gosu Class, type [Link], or click Browse to
navigate to the class.
If you have created a different Gosu, Java, or OSGi plugin class for the email plugin, use that class,
specifying the appropriate plugin type, instead of the JavaxEmailMessageTransport class.
4. If the Disabled check box is checked, clear the check box to enable the plugin.
5. Enter appropriate values for the following parameters:
• [Link]
• defaultSenderAddress
• defaultSenderName
• smtpHost
• smtpPort
The JavaxEmailMessageTransport email plugin class also supports many other parameters for SMTP
operation, and SSL and TLS security.
6. Save your changes.
7. Restart the PolicyCenter server.

See also
• “Add an implementation to a Plugins Registry item” on page 134
• "Sending emails" in the Integration Guide

The email object model

Guidewire PolicyCenter uses the following two classes to define email messages:
• [Link]
• [Link]
Both of these classes are simple data containers with almost no logic. The classes also contain a number of utility
methods that perform operations on the fields defined in the class.

[Link]
The Email class contains the following fields, most of which are self-explanatory:

Field Description
Subject Subject of the email
Body Content of the email

484 chapter 33: Guidewire PolicyCenter and Email

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Field Description
Sender Sender of the email
ReplyTo Contact object (It is possible for this to be different from the Sender.)

ToRecipients List of Contact objects

CcRecipients List of Contact objects
BccRecipients List of Contact objects

Documents List of DocumentBase entities for attachment to the email

[Link]

The EmailContact class contains the following fields:

Field Description
Name Name of contact
EmailAddress Email address of contact

Contact Contact object, which can be null. If this parameter exists, it sets the Name and EmailAddress fields to the
appropriate values from the specific Contact entity.

Email utility methods

In addition to the Email and EmailContact classes, Guidewire also provides a set of static utility methods in the
[Link] class for generating and sending emails from Gosu, for example:
[Link]( KeyableBean entity, Email email )

[Link]( KeyableBean entity,

Contact to,
Contact from,
String subject,
String body )

[Link]( KeyableBean entity,

String toEmailAddress,
String toName,
String fromEmailAddress,
String fromName,
String subject,
String body )

These methods all take an entity as the first parameter. This parameter can be null. However, if specified, use the
application entity to which this email is related, such as a specific policy or activity. PolicyCenter uses this
parameter only while processing the email for transmission. See “Email transmission” on page 486.

Emails that use an Email object

One variation of the sendEmailWithBody method requires that you create a [Link] entity, and then
define its properties to build the Email entity. For example:
...
var testEmail : [Link]
[Link] = "This is a test."
[Link] = "Test"
...
[Link]( thisClaim, testEmail )

You can also attach multiple To, CC, and BCC addresses to the email.

Guidewire PolicyCenter and Email 485

Guidewire PolicyCenter 9.0.9 Configuration Guide

Emails that use Contact objects

Another variation of the sendEmailWithBody method uses Contact objects for the to and from parameters. In
Gosu, you can obtain Contact objects from various places. For example, in a policy rule, to send an email from an
insurance company employee to the insured, do the following:
• Set the to parameter to [Link].
• Set from to [Link].
The following Gosu example generates an email from the current assigned user to that user’s supervisor:
[Link](thisPolicy, [Link],
[Link], "A policy got a PolicyValid event", "This is the text." )

Emails that use an email address

Use the following variation of the sendMailWithBody method if you do not have a full Contact object for a
recipient or sender. It is possible that another application dynamically generated the Contact object, providing an
incomplete version of the object. The sendMailWithBody method uses a name and email address instead of entire
Contact records and does not require that you have access to a Contact record.
In the following example, all arguments are String objects:
[Link]( Entity, toName, toEmail, fromName, fromEmail, subject, body)

Email transmission
Guidewire PolicyCenter, from the user's perspective, sends emails asynchronously by using the PolicyCenter
Messaging subsystem. If there is a method call for one of the [Link] methods, PolicyCenter creates
a Message entity with the contents and other information from the Email object.
In the sendEmail method parameters:
• If the entity parameter is non-null, PolicyCenter adds the Message entity to the entity transaction bundle.
PolicyCenter persists the Message entity any time that it creates the bundle.
• If the entity parameter is null, PolicyCenter persists the Message entity immediately.
PolicyCenter then processes the messages one at a time and sends out the emails associated with that message.
Note: You must configure a MessageTransport class to consume the email messages and perform the
actual transmission of the email.

About email templates

You use email templates to create the body of an email message. Typically, email templates are generally suitable
only for boilerplate text that does not require modification, or, for presenting in the application interface as the
starting point for further modification. However, email templates do support Gosu expressions, both in the Subject
string, and in the Body string. It is also possible for an email template to be in HTML-formatted text. However, you
cannot use Email templates for mail-merge types of operations.
By default, email templates live in the following location in Studio:
configuration→config→resources→emailtemplates

Email template files

An email template consists of two separate files:
• A descriptor file that contains some metadata about the template. The file name must end in .[Link],
• A template file that contains the desired contents of the email body. The file name must end in .gosu.

IMPORTANT The file names of the descriptor and template files must match.

An email descriptor file contains the following fields:

486 chapter 33: Guidewire PolicyCenter and Email
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Field Description
body The email body of the emails created using this template
keywords A list of keywords for use in searching the templates

name The name of the template

subject The email subject of the emails created using this template
topic The topic of the template

For example, [Link] defines an Email Received descriptor file:

<?xml version="1.0" encoding="UTF-8"?>
<serialization>
<emailtemplate-descriptor
name="Email Received"
keywords="email"
topic="reply"
subject="Email Received"
body="[Link]"
/>
</serialization>

The [Link] file pairs with the actual template file ([Link]):
Thank you for your correspondence. It has been received and someone will contact you shortly to follow up on your
feedback.
Sincerely,

Create an email template file

Procedure
1. In the PolicyCenter Studio Project window, expand configuration→config→resources.
2. Select emailtemplates, right-click, then select one of the following items from the context menu:

Template type Menu path Extension to add Note

Text New→File .gosu Select Text from the list of file types to associate with the .gosu
extension, if necessary.
HTML New→HTML File .[Link] Set the HTML version to use in the HTML File dialog.

Studio opens an editable file with the given name in a new tab.
3. Enter the text of the email message to send in the template.
For example:
Greetings:

Please contact <%= [Link] %> at <%= [Link] %>

in regards to <%= [Link] %>

Thank you for your patience while we resolve this issue.

Sincerely,

Create an email template descriptor file

Procedure
1. In the PolicyCenter Studio Project window, expand configuration→config→resources.
Guidewire PolicyCenter and Email 487
Guidewire PolicyCenter 9.0.9 Configuration Guide

2. Select emailtemplates, right-click, then select one of the following items from the context menu:

Descriptor Menu path Extension to add Note

type

Text New→File .[Link] Select Text from the list of file types to associate with
the .[Link] extension, if necessary.
HTML New→HTML File .[Link] Set the HTML version to use in the HTML File dialog.

Studio opens an editable file with the given name in a new tab.
3. Enter text similar to the following, modifying the given text to suit your business needs.

<?xml version="1.0" encoding="UTF-8"?>

<serialization>
<emailtemplate-descriptor name="Test Email" keywords="email" topic="reply" subject="Test Email"
body="[Link]" />
</serialization>

Localize an email template

Localizing an email template is generally a straightforward process of creating localized versions of the template
and its descriptor file and placing the files in the correct location.

About this task

Note: To use a localized email template in PolicyCenter, perform a search for the localized template as
you create a new email.

Procedure
1. In Studio, create a locale folder for the template files in the resources→emailtemplates folder.
The following example illustrates how to create a locale folder for Japanese.
resources→emailtemplates→ja_JP
2. Within the locale folder, place localized versions of the email template file and its associated template
descriptor file.

Sending emails from Gosu code

To send an email from Gosu, you need to do the following:
• First, create the email, typically through the use of email templates.
• Send the email using one of the [Link] methods.

Transaction bundle commits

It is possible to send an email either from a Gosu rule or directly from Gosu code. Which method you use affects
whether you need to commit the email transaction.

Rule If you create and send an email as part of rule workflow, you do not need to commit the email transaction as it
execution is already part of the rule transaction commit. Creating an email message and storing it in the Send Queue
occurs as part of the same database transaction in which the rules run. This is the same as regular message
creations triggered through rules.
Gosu If you create and send an email directly from Gosu code, outside of a Gosu rule, it is more likely that you need
execution to commit the email transaction, depending on the exact circumstances of your Gosu code.

488 chapter 33: Guidewire PolicyCenter and Email

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Saving an email message as a document

PolicyCenter does not store email objects created through the “The email object model” on page 484 class in the
database. However, it is possible to save the contents, recipient information, and other information of an email as a
document in the configured DMS application.
Because all variations of the [Link] methods take all of the sending
information explicitly, you can save the email information by using the following process in Gosu code:
1. Create the email subject and body and determine recipients.
2. Send the email by calling one of the sendEmailWithBody methods.
3. If PolicyCenter does not encounter an exception, create a document recording the details of the sent email.

Example code
For a simple example of the code needed to save an email as a document, refer to the either the BillingCenter or
ClaimCenter [Link] PCF file. To see the example, select the highest level element, then open the
Code tab at the bottom of the screen.
If desired, it is possible to replicate this functionality in Gosu code using the sample code as the basis for your code.
Possible improvements to the example code include the following:
• Adding a header to the document with metadata to determine the docContainer object.
• Adding a BCC to archive email addresses.
• Creating a batch process that fetches the emails in a specific account and stores any outgoing email as a
document.
It is important to understand that the sample code in the [Link] PCF file performs a transaction
bundle commit. In most cases, you do not need to perform the bundle commit in your code:
• If calling the code from a Gosu rule, the rule is already in a commit bundle.
• If calling the code from workflow, the workflow is already in a transaction bundle.
• If calling the code from a work queue, the workqueue is mostly likely already in a transaction bundle.

Creating an HTML email within code

The PolicyCenter email subsystem sets the email content type to HTML only if the HTML property on the email is
set to true. The following examples show how to work with HTML emails:
• The EmailEnhancement example is an email enhancement that sets the HTML property based on the template
file extension. The enhancement also sets other useful header values that exist in an email object.
• The CreateEmailScreen example shows how to modify the base configuration CreateEmailScreen to add
HTML template-related fields.
Note: If you are creating an email inline and you are sure that there is no possibility for an attack in
the HTML, you can set the email HTML property directly. However, if you do so, ensure that you
encode any user-supplied strings.

[Link]
The following code first populates a number of message headers, then provides a useEmailTemplate method that
example PCF screen CreateEmailTemplate calls to set up the HTML email.
package [Link]

uses [Link]
uses [Link]
uses [Link]
uses [Link]
uses [Link]
uses [Link]
uses [Link]
uses [Link]

Guidewire PolicyCenter and Email 489

Guidewire PolicyCenter 9.0.9 Configuration Guide

enhancement EmailEnhancement : [Link] {

// list of headers, note the value should be ascii-7 or encoded

property get AUTOMATION_HEADER() : String { return "x-gw-Automation" }

property get EXPIRATION_HEADER() : String { return "Expiry-Date" }

property get REPLY_TO_ID_HEADER() : String { return "In-Reply-To" }
property get ID_HEADER() : String { return "Message-ID" }
property get REF_IDS_HEADER() : String { return "References" } // space delimited

property get RETURN_RECEIPT_ADDR_HEADER() : String { return "Return-Receipt-To" }

property get RETURN_READ_ADDR_HEADER() : String { return "Disposition-Notification-To" }

property get THREAD_HEADER() : String { return "Thread-Topic" }

property get THREAD_INDEX_HEADER() : String { return "Thread-Index" }

property get PRIORITY_HEADER() : String { return "Priority" }

property get PRIORITY_LOW() : String { return "5" }
property get PRIORITY_HIGH() : String { return "1" }

property get IMPORTANCE_HEADER() : String { return "Importance" }

property get IMPORTANCE_LOW() : String { return "low" }
property get IMPORTANCE_HIGH() : String { return "high" }

property get SENSITIVITY_HEADER() : String { return "Sensitivity" }

property get SENSITIVITY_CONFIDENTIAL() : String { return "Company-Confidential" }
property get SENSITIVITY_HIGH() : String { return "high" }

function useEmailTemplate(template : IEmailTemplateDescriptor, beans : Map<String,Object>) {

[Link] = [Link]
try {
var locale = [Link]
if (locale == null) {
locale = [Link]()
}
[Link]( locale,
{new StringReader([Link]), new StringReader([Link])},
// setup the symbol table for the template processing, this is the same between email and note
\ iScriptHost -> {
// load the symbols supplied by the caller
var seen = new HashSet<String>()
for (entry in [Link]()) {
var bean = [Link]()
[Link]([Link], typeof(bean) as String, bean)
[Link]([Link]())
}
// now load (or copy from other possible symbol names) the symbols that could be expected
// cc: claim, ...
// pc: policy, account, policyperiod, job, ...
if (not [Link]( "activity" )) {
[Link]( "activity", Activity as String, null )
}
if (not [Link]( "user" )) {
[Link]( "user", User as String, [Link] )
}
},
// process the result of the template expansion
\ results -> {
[Link] = results[0]
[Link] = results[1]
} )
} catch (e : Throwable) {
PLLoggerCategory.MESSAGING_EMAIL.info("On ${[Link]()}", e)
throw new DisplayableException("On ${[Link]()} caught ", e);
}
}
}

[Link]
The following example code adds additional functionality to the base configuration PolicyCenter
CreateEmailScreen PCF. This example version of the PCF screen adds HTML template-related fields to the screen,
include a read-only view of the HTML template. This field (a TextAreaInput widget) contains a PostOnChange
action that calls method executeTemplate, which, in turn, calls the useEmailTemplate method from
[Link].
490 chapter 33: Guidewire PolicyCenter and Email
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Note: This example uses display keys that do not exist in the base configuration. You must add the
missing display keys to [Link] in order to see the correct labels.
<?xml version="1.0"?>
<PCF
xmlns:xsi="[Link]
xsi:noNamespaceSchemaLocation="../../../../../../[Link]">
<Screen
editable="true"
id="CreateEmailScreen">
<Require
name="srcBean"
type="Activity"/>
<Require
name="docContainer"
type="Activity"/>
<Require
name="emailTemplateName"
type="String"/>
<Require
name="documentsToSend"
type="Document[]"/>
<Variable
initialValue="null"
name="documentToSave"
type="Document"/>
<Variable
initialValue="emailTemplateName == null"
name="noDefaultTemplate"
type="Boolean"/>
<Variable
initialValue="false"
name="saveAsDocument"
type="boolean"/>
<Variable
initialValue="false"
name="showCC"
type="boolean"/>
<Variable
initialValue="false"
name="showBCC"
type="boolean"/>
<Variable
initialValue="[Link]()"
name="language"
type="LanguageType"/>
<Variable
initialValue="initializeSymbolTable()"
name="symbolTable"
type="[Link]&lt;String,Object&gt;"/>
<Variable
initialValue="new String()"
name="content"
type="String"/>
<Variable
initialValue="emailTemplateName == null ? null : fetchTemplate()"
name="template"
type="[Link]"/>
<Variable
initialValue="initNewEmail()"
name="NewEmail"
type="[Link]"/>
<Toolbar>
<ToolbarButton
action="sendEmailToRecipients(NewEmail)"
available="true"
id="ToolbarButton0"
label="[Link](&quot;[Link]&quot;)"
visible="true"/>
<ToolbarButton
action="[Link]()"
available="true"
id="ToolbarButton1"
label="[Link](&quot;[Link]&quot;)"
visible="true"/>
<ToolbarDivider/>
<PickerToolbarButton
action="[Link](createSearchCriteria())"

Guidewire PolicyCenter and Email 491

Guidewire PolicyCenter 9.0.9 Configuration Guide

id="EmailWorksheet_UseTemplateButton"
label="[Link](&quot;[Link]&quot;)"
onPick="template = PickedValue;
language = [Link]([Link]);
executeTemplate(NewEmail)"
shortcut="P"
visible="noDefaultTemplate"/>
</Toolbar>
<AlertBar
id="NoDefaultTemplate"
label="[Link](&quot;[Link]&quot;, emailTemplateName)"
showConfirmMessage="false"
visible="emailTemplateName != null and noDefaultTemplate"/>
<DetailViewPanel>
<InputColumn>
<TypeKeyInput
editable="true"
id="Language"
label="[Link](&quot;[Link]&quot;)"
required="true"
value="language"
valueType="[Link]"
visible="[Link]( false ).Count &gt; 1 and emailTemplateName != null">
<PostOnChange
onChange="template = fetchTemplate(); executeTemplate(NewEmail)"/>
</TypeKeyInput>
<ListViewInput
editable="true"
id="ToRecipientLVInput"
label="[Link](&quot;[Link]&quot;)"
labelAbove="true"
visible="true">
<Toolbar
visible="true">
<IteratorButtons
addVisible="true"
iterator="ToRecipientLV"
removeVisible="true"/>
<ToolbarDivider/>
</Toolbar>
<ListViewPanel
editable="true"
id="ToRecipientLV"
visible="true">
<RowIterator
autoAdd="true"
editable="true"
elementName="ToRecipient"
numEntriesRequired="1"
numEntriesToAdd="1"
toCreateAndAdd="var newEmailContact = new [Link]();
[Link](newEmailContact); return newEmailContact;"
toRemove="[Link]( ToRecipient )"
validationLabel="[Link](&quot;[Link]&quot;)"
value="[Link]?.toTypedArray()"
valueType="[Link][]">
<Row
editable="true">
<TextCell
editable="true"
id="ToName"
label="[Link](&quot;[Link]&quot;)"
maxChars="60"
numCols="15"
value="[Link]"/>
<TextCell
editable="true"
id="ToEmail"
label="[Link](&quot;[Link]&quot;)"
numCols="15"
requestValidationExpression="VALUE == null ?
[Link](&quot;[Link]
.[Link]&quot;) : null"
required="true"
value="[Link]"/>
</Row>
</RowIterator>
</ListViewPanel>
</ListViewInput>

492 chapter 33: Guidewire PolicyCenter and Email

 Guidewire PolicyCenter 9.0.9 Configuration Guide

<ButtonInput
action="showCC = true"
id="ShowCCRecipients"
labelAbove="true"
value="[Link](&quot;[Link]&quot;)"
visible="!showCC"/>
<ListViewInput
editable="true"
id="CcRecipientLVInput"
label="[Link](&quot;[Link]&quot;)"
labelAbove="true"
visible="showCC">
<Toolbar
visible="true">
<IteratorButtons
addVisible="true"
iterator="CcRecipientLV"
removeVisible="true"/>
</Toolbar>
<ListViewPanel
editable="true"
id="CcRecipientLV"
visible="true">
<RowIterator
editable="true"
elementName="CcRecipient"
toCreateAndAdd="var newEmailContact = new [Link]();
[Link](newEmailContact); return newEmailContact;"
toRemove="[Link]( CcRecipient )"
value="[Link]?.toTypedArray()"
valueType="[Link][]">
<Row
editable="true">
<TextCell
editable="true"
id="CcName"
label="[Link](&quot;[Link]&quot;)"
numCols="15"
value="[Link]"/>
<TextCell
editable="true"
id="CcEmail"
label="[Link](&quot;[Link]&quot;)"
numCols="15"
required="true"
value="[Link]"/>
</Row>
</RowIterator>
</ListViewPanel>
</ListViewInput>
<ButtonInput
action="showBCC = true"
id="ShowBCCRecipients"
labelAbove="true"
value="[Link](&quot;[Link]&quot;)"
visible="!showBCC"/>
<ListViewInput
editable="true"
id="BccRecipientLVInput"
label="[Link](&quot;[Link]&quot;)"
labelAbove="true"
visible="showBCC">
<Toolbar
visible="true">
<IteratorButtons
addVisible="true"
iterator="BccRecipientLV"
removeVisible="true"/>
</Toolbar>
<ListViewPanel
editable="true"
id="BccRecipientLV"
visible="true">
<RowIterator
editable="true"
elementName="BccRecipient"
toCreateAndAdd="var newEmailContact = new [Link]();
[Link](newEmailContact); return newEmailContact;"
toRemove="[Link]( BccRecipient )"

Guidewire PolicyCenter and Email 493

Guidewire PolicyCenter 9.0.9 Configuration Guide

value="[Link]?.toTypedArray()"
valueType="[Link][]">
<Row
editable="true">
<TextCell
editable="true"
id="BccName"
label="[Link](&quot;[Link]&quot;)"
numCols="15"
value="[Link]"/>
<TextCell
editable="true"
id="BccEmail"
label="[Link](&quot;[Link]&quot;)"
numCols="15"
required="true"
value="[Link]"/>
</Row>
</RowIterator>
</ListViewPanel>
</ListViewInput>
<InputDivider/>
<CheckBoxInput
editable="true"
id="SaveAsDocument"
value="saveAsDocument"
valueLabel="[Link](&quot;[Link]&quot;)"/>
</InputColumn>
<InputColumn>
<TextInput
editable="true"
id="SenderName"
label="[Link](&quot;[Link]&quot;)"
value="[Link]"/>
<TextInput
editable="true"
id="SenderEmail"
label="[Link](&quot;[Link]&quot;)"
value="[Link]"/>
<TextInput
editable="true"
id="Subject"
label="[Link](&quot;[Link]&quot;)"
requestValidationExpression="VALUE == null ?
[Link](&quot;[Link]&quot;) : null"
required="true"
value="[Link]"/>
<TextAreaInput
editable="true"
id="Content"
label="[Link]"
numCols="60"
numRows="10"
required="false"
value="content"
visible="[Link]">
<PostOnChange
onChange="executeTemplate(NewEmail)"/>
</TextAreaInput>
<TextAreaInput
editable="true"
id="Body"
label="[Link](&quot;[Link]&quot;)"
numCols="60"
numRows="10"
requestValidationExpression="VALUE == null ?
[Link](&quot;[Link]&quot;) : null"
required="true"
value="[Link]"
visible="![Link]"/>
<ListViewInput
editable="true"
id="AttachedDocuments"
label="[Link](&quot;[Link]&quot;)">
<Toolbar>
<PickerToolbarButton
action="[Link](docContainer)"
id="AddDocumentButton"
label="[Link](&quot;[Link]&quot;)"

494 chapter 33: Guidewire PolicyCenter and Email

 Guidewire PolicyCenter 9.0.9 Configuration Guide

onPick="[Link](PickedValue)"
shortcut="A"
visible="true"/>
<IteratorButtons
addVisible="false"
iterator="AttachedDocumentsLV"/>
</Toolbar>
<ListViewPanel
editable="true"
id="AttachedDocumentsLV">
<RowIterator
editable="true"
elementName="AttachedDocument"
toRemove="[Link]( AttachedDocument )"
value="[Link]?.toTypedArray()"
valueType="[Link][]">
<Row>
<TextCell
editable="true"
id="Document"
label="[Link](&quot;[Link]&quot;)"
value="[Link]"/>
</Row>
</RowIterator>
</ListViewPanel>
</ListViewInput>
</InputColumn>
</DetailViewPanel>
<TemplatePanel>
<TemplatePanelContents><![CDATA[
<% if (template != null && [Link]) printContent([Link], false) %>]]>
</TemplatePanelContents>
</TemplatePanel>
<Code><![CDATA[function initializeSymbolTable() : [Link]<String,Object> {
return { "activity" -> srcBean }
}

function createSearchCriteria() : [Link] {

var rtn = new [Link]()
[Link] = language
[Link] = [Link]?.toTypedArray()
return rtn
}

function initNewEmail() : [Link] {

var rtn = new [Link]()
if (documentsToSend != null) {
for (document in documentsToSend) {
[Link]( document )
}
}
if (template != null) {
executeTemplate(rtn)
}
return rtn
}

function fetchTemplate() : [Link] {

template = [Link]([Link])
.getEmailTemplate([Link](language), emailTemplateName);
if (template == null) {
noDefaultTemplate = true
throw new [Link](DisplayKey
.get("[Link]", emailTemplateName, language))
}
return template
}

function executeTemplate( email : [Link]) {

[Link](template, { "activity" -> srcBean, "content" -> content })
}

function sendEmailToRecipients(emailToSend : [Link]) {

var warnings = [Link](emailToSend)
if ([Link] > 0) {
throw new [Link](warnings)
}
if (saveAsDocument) {
var templatePlugin = [Link]([Link])

Guidewire PolicyCenter and Email 495

Guidewire PolicyCenter 9.0.9 Configuration Guide

var emailSentDocTemplate = templatePlugin

.getDocumentTemplate("[Link]", [Link]())
if (emailSentDocTemplate == null) {
throw new [Link]("Could not save email as a document
because the \"[Link]\" does not exist!")
} else {
documentToSave = documentToSave != null ? documentToSave : new Document()
[Link] = [Link]
[Link] = [Link]
[Link] = [Link]([Link])
[Link] = [Link]
.get([Link]( "section" ) as String)
[Link] = [Link]
.get([Link])
[Link] = TC_FINAL
var recpName = [Link]().Name
[Link] = recpName == null ? [Link]().EmailAddress : recpName
[Link] = docContainer
[Link] = [Link]()
[Link] = [Link]
[Link] = false

var paramMap = new [Link]()

[Link]("User", [Link])
[Link]("Email", emailToSend)
[Link]("DateSent", [Link]())
[Link]
.createAndStoreDocumentSynchronously(emailSentDocTemplate, paramMap, documentToSave);
}
} else if (documentToSave != null) {
[Link]();
}
[Link](srcBean, emailToSend);
// it didn't throw so reset email [Link] so that other templates can be used
if (emailTemplateName != null and srcBean typeis Activity) {
if ([Link] == emailTemplateName) {
[Link] = null
}
}
[Link]();
}]]></Code>
</Screen>
</PCF>

496 chapter 33: Guidewire PolicyCenter and Email

Part 7

Testing Gosu code

Guidewire PolicyCenter 9.0.9 Configuration Guide
chapter 34

Testing and debugging your

configuration

After you use Guidewire Studio to make configuration changes to your application, you will typically want to run
the application to test those changes. Guidewire Studio provides powerful features to help you make sure that your
application works the way you intend.

Testing PolicyCenter with Guidewire Studio

After you make configuration changes to PolicyCenter, you can start it directly from within Guidewire Studio and
test your changes. You can also use the powerful debugging features that Studio provides.
This topic contains:
• “Running PolicyCenter without debugging” on page 499
• “Debugging PolicyCenter within Studio” on page 500
• “Debugging a PolicyCenter server that is running outside of Studio” on page 500

Running PolicyCenter without debugging

About this task
If you do not plan to use debugging features, then you can run PolicyCenter directly from within Studio to quickly
test your configuration changes. Running PolicyCenter this way is similar to starting it from the command line with
the command gwb runServer, but without having to switch out of Studio.
• In Studio, click Run→Run ‘Server’.

Result
The PolicyCenter server starts, and debug messages appear in the Run tool window in Studio.

Testing and debugging your configuration 499

Guidewire PolicyCenter 9.0.9 Configuration Guide

Debugging PolicyCenter within Studio

About this task
You can run PolicyCenter in the Studio debugger, which provides additional features to help you verify that your
configuration changes are working as desired.
• In Studio, click Run→Debug ‘Server’.

Result
The PolicyCenter server starts, and debug messages appear in the Debug tool window in Studio.

See also
• “The Studio debugger” on page 502

Debugging a PolicyCenter server that is running outside of Studio

Instead of running PolicyCenter within the Studio debugger, you can have the debugger connect to a PolicyCenter
server that is running outside of Studio. The debugger can connect to a PolicyCenter server running either on the
local computer or on a remote computer.
You must choose one of the following ways for Studio to connect to the server:

Connec‐ Description See

tion type
shared memory Connects Studio to a server running on the same comput‐ “Debugging a PolicyCenter server using a
er; faster than a socket connection. shared memory connection” on page 500
socket Allows Studio to connect to a server running on a remote “Debugging a PolicyCenter server using a sock‐
computer; slower than a shared memory connection. et connection” on page 501

Debugging a PolicyCenter server using a shared memory connection

About this task
Use a shared memory connection to connect Studio to a PolicyCenter server running on the same computer. You
must manually start the server in the proper debug mode, and create the proper debug configuration in Studio.

Procedure
1. Start the PolicyCenter server.
a. Start the server using the following command:
gwb runServer --debug-shmem --no-suspend
b. Towards the beginning of the server console message output, look for the label debug-shmem:, and then
the text that is similar to the following:
Listening for transport dt_shmem at address: javaAddress
c. Make a note of the string provided for javaAddress.
2. Create the debug configuration in Studio.
a. In Studio, click Run→Edit Configurations.
b. In the Run/Debug Configurations dialog, click Add New Configuration , and then click Remote.
c. In the Name text box, type a name for the debug configuration. For example, server-shmem.
d. Next to Transport, click Shared memory.
e. Next to Debugger mode, click Attach.
500 chapter 34: Testing and debugging your configuration
 Guidewire PolicyCenter 9.0.9 Configuration Guide

f. In the Shared Memory Address text box, type the javaAddress that you noted when you started the server.
g. Click OK.
3. Connect the Studio debugger to the PolicyCenter server using the shared memory connection.
a. In Studio, in the Select Run/Debug Configuration drop-down list, select the debug configuration that you
created.
b. Click Run→Debug ‘configName’, where configName is the name of the debug configuration that you
created.

Result
The debugger connects to the PolicyCenter server, and debug messages appear in the Debug tool window in Studio.

Debugging a PolicyCenter server using a socket connection

About this task

Use a socket connection to connect Studio to a PolicyCenter server running either on the same computer or a remote
computer. However, if running on the same computer, a shared memory connection is faster than a socket
connection.
You must manually start the server in the proper debug mode, and create the proper debug configuration in Studio.

Procedure
1. Start the PolicyCenter server.
a. Start the server using the following command:
gwb runServer --debug-socket --no-suspend
b. Towards the beginning of the server console message output, look for the label debug-socket:, and then
the text that is similar to the following:
Listening for transport dt_socket at address: portNumber
c. Make a note of the value provided for portNumber.
2. Create the debug configuration in Studio.
a. In Studio, click Run→Edit Configurations.
b. In the Run/Debug Configurations dialog, click Add New Configuration , and then click Remote.
c. In the Name text box, type a name for the debug configuration. For example, server-socket.
d. Next to Transport, click Socket.
e. Next to Debugger mode, click Attach.
f. In the Host text box, type the hostname of the computer on which the PolicyCenter server is running.
g. In the Port text box, type the portNumber that you noted when you started the server.
h. Click OK.
3. Connect the Studio debugger to the PolicyCenter server using the shared memory connection.
a. In Studio, in the Select Run/Debug Configuration drop-down list, select the debug configuration that you
created.
b. Click Run→Debug ‘configName’, where configName is the name of the debug configuration that you
created.

Result
The debugger connects to the PolicyCenter server, and debug messages appear in the Debug tool window in Studio.
Testing and debugging your configuration 501
Guidewire PolicyCenter 9.0.9 Configuration Guide

Debugging a PolicyCenter server in suspended mode

About this task

When you start a PolicyCenter server in debug mode, the server completes its full startup process until it becomes
ready for client connections. In this case, you cannot begin to debug the server until it is ready. However, if the
behavior that you want to debug occurs earlier in the startup process, then you can start the server in suspended
mode instead. In suspended mode, the PolicyCenter startup pauses as soon as its Java process is initially established.
The startup process continues only once you start the Studio debugger.
• To start the PolicyCenter server in suspended mode, use one the following commands:
◦ gwb runServer --debug-shmem
◦ gwb runServer --debug-socket

The Studio debugger

Guidewire Studio includes a code debugger to help you verify that your Gosu code is working as desired. It works
whether the code is in a Gosu rule, a Gosu class, or a PolicyCenter PCF page. You access this functionality through
the Studio Run menu and through specific debug icons on the Studio toolbar. You must be connected to a running
PolicyCenter server to use the Studio debugger. (If you do not have a connection to a running server, Studio attempts
to run one.) If the debugger is active, you can debug Gosu code that runs in the Gosu Scratchpad and Gosu code that
is part of the running application.
If instructed, Studio can pause (at a breakpoint that you set) before it runs a specified line of code. This can be any
Gosu code, whether contained in a rule or a Gosu class. The debugger can also run on Gosu that you call from a PCF
page, if the called code is a Studio class.
After Studio pauses, you can examine any variables or properties used by Gosu and view their values at that point in
the debugger pane. You can then have Studio continue to step through your code, pausing before each line. This
allows you to monitor values as they change, or simply to observe the execution path through your code.
Note: Do not perform debugging operations on a live production server.

Setting breakpoints
A breakpoint is a place in your code at which the debugger pauses execution, giving you the opportunity to examine
current values or begin stepping through each line. The debugger pauses before executing the line containing the
breakpoint. The debugger identifies a breakpoint by highlighting the related line of code and placing a breakpoint
symbol next to it.

Set a breakpoint
About this task

You can set multiple breakpoints throughout your code, with multiple breakpoints in the same block of code, or if
desired, breakpoints in multiple code blocks. The debugger pauses at the first breakpoint encountered during code
execution. After it pauses, the debugger ignores other breakpoints until you continue normal execution.
You can set a breakpoint in a rule condition statement, as well. You cannot set a breakpoint on a comment.

Procedure

1. Place the cursor on the line of code on which to set the breakpoint.
2. On the Run menu, click Toggle Line Breakpoint. You can also click in the gray column next to a code line:
502 chapter 34: Testing and debugging your configuration
 Guidewire PolicyCenter 9.0.9 Configuration Guide

View a breakpoint
Procedure
On the Run menu, click View Breakpoints.

Result
Selecting this menu item opens the View Breakpoints dialog in which you can do the following:
• View all of your currently set breakpoints
• Deactivate any or all of your breakpoints (which makes them non-functional, but does not remove them from the
code)
• Remove any or all breakpoints
• Navigate to the code that contains the breakpoint
Thus, from this dialog, you can deactivate, remove, or add a breakpoint.

Remove a breakpoint
Procedure
1. Place the cursor on the line of code containing the breakpoint to remove.
2. On the Run menu, click Toggle Line Breakpoint. You can also click the breakpoint symbol next to the line of
code.

Stepping through code

After the debugger pauses execution, you can step through the code one line at a time in one of the following ways:

Step over Execute the current line. If the current line is a method call, then run the method and return to the next line in the
current code block after the method ends. To step through your code in this manner, on the Run menu, click Step Over
.
Step into Execute the current line of code. If the current line is a method call, then step into the method and pause before
executing the first line for that method. To step through your code in this manner, on the Run menu, click Step Into .

The only difference between these two stepping options is if the current line of code is a method call. You can either
step over the method and let it run without interruption, or you can step into it and pause before each line. For other
lines of code that are not methods, stepping over and stepping into behave in the same way.
Testing and debugging your configuration 503
Guidewire PolicyCenter 9.0.9 Configuration Guide

While paused, you can navigate to other rules or classes if you want to look at their code. To return to viewing the
current execution point, on the Run menu, click Show Execution Point . Studio highlights the line of code to execute
the at the next step.

Viewing current values

After the debugger pauses at a breakpoint in your code, you can examine the current values of variables or entity
properties. You can watch these values and see how they change as each line of code executes.

Viewing variables
The Debugger tab of the Debug pane shows the root entity that is currently available. For example, in activity
assignment code, the root entity is an Actvity object. To view any property of the root entity, expand it until you
locate the property.
The Debugger tab also shows the variables that you have currently defined. Note, however, that you can view only
the entities and variables that are available in the current scope of the code. Suppose, for example, that an Activity
entity is available in an activity assignment class. However, if that class calls a different class and you step into that
class, the Activity entity is no longer part of the scope. Therefore, it is no longer available. (Unless, you pass the
Activity object in as a parameter.)

Defining a watch list

About this task

After executing each line of code, Studio resets the list of values shown in the Debug frame. In doing so, it collapses
any property hierarchies that you may have expanded. It would be inconvenient for you to expand the hierarchy after
each line and locate the desired properties all over again.
Instead, you can define a watch list containing the Gosu expressions in which you have an interest in monitoring.
The debugger evaluates each expression on the list after each line of code executes, and shows the result for each
expression on the list. For example, you can add [Link] to the watch list and then monitor the list
as you step through each line of code. If the property changes, you see that change reflected immediately on the list.
You can also add variables to the list so you can monitor their values, as well.
• In the Variables pane, right-click the expression, and then click Add to Watches.

Next steps

As you step through each line of code in the debugger, keep the Watches pane visible so that you can monitor the
values of the items on the list.

Resuming execution
After the debugger pauses execution of your code, and after you are through performing any necessary debugging
steps, you may want to resume normal execution. You can do this in the following ways:

Stop debugging Resume normal execution, and ignore all remaining breakpoints. To stop debugging, click Mute Breakpoints
, and then click Resume Execution .
Continue debug- Resume normal execution, but pause again at the next breakpoint, if any. To continue debugging, click Re-
ging sume Execution without having Mute Breakpoints set.

504 chapter 34: Testing and debugging your configuration

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Using the Gosu scratchpad

Use the Gosu scratchpad to execute Gosu programs and evaluate Gosu expressions. Instead of needing to perform
PolicyCenter operations to trigger your Gosu code, you can run your code directly in the Scratchpad and see
immediate results.

Run the Gosu scratchpad

Before you begin
To execute queries against the database in Studio or the Gosu scratchpad, you must first connect to a running
application server.

About this task

The result of a query is always a read-only query object. To work with this read-only object, you must add it to a
transaction bundle.
You can test the following in the Gosu scratchpad:

Code Description
Expression Returns the result of evaluating the (single‐line) expression.
Program Displays the output of the program, including calls to print and exception stack traces.

• To run the Gosu scratchpad, click Tools→Gosu Scratchpad .

Executing code in the Gosu scratchpad

Procedure
Type your code, and then click Run .

Accessing application data in the Gosu scratchpad

You can always use the Gosu scratchpad to test generic Gosu code. If the scratchpad code needs to access
application data, then the PolicyCenter server must be running in debug mode. For example, the following code
accesses group and user entities, and therefore requires access to the application server:
var group : Group = Group(2)
for (var member in [Link]) {
print([Link])
}

To access application data in the Gosu scratchpad, run the PolicyCenter server in debug mode, and then instruct the
scratchpad to run your code in that process. The DCEVM must be installed on the server. For information on
running the PolicyCenter server in debug mode, see “Testing PolicyCenter with Guidewire Studio” on page 499.

See also
• “Run scratchpad code in the application server debug process” on page 505.

Run scratchpad code in the application server debug process

Procedure

Type your code, and then click Run in Debug Process .

Testing and debugging your configuration 505
Guidewire PolicyCenter 9.0.9 Configuration Guide

Understanding internally generated code

Many configuration resources are defined in XML. To improve runtime performance, Guidewire Studio
automatically generates Java or Gosu code that implements the behavior defined by these XML resources. Studio
then compiles this generated code to internal bytecode. This process is called code generation, often shortened to
codegen.
In Studio, the generated code is stored in the configuration→generated folder. When debugging your application, the
Studio debugger may step you into this internal code, though you will typically not need to browse this code on your
own. Do not directly modify this generated code, as any changes will be overwritten when Studio generates it again.

Manually generate code for configuration resources

About this task
Guidewire Studio generates internal Java or Gosu code automatically for all necessary configuration resources
whenever they are modified. If code generation has never been run before, Studio runs it automatically the first time
that you run gwb studio.

Procedure
To generate the internal code manually, select one of the items in the Codegen menu.

Enable or disable code generation

About this task
If you are making changes that affect many configuration resources, then you may want to defer code generation in
Guidewire Studio until your changes are complete. For example, if you modify an XSD file, then Studio would
regenerate all types defined in that XSD file, and also any classes that use the modified types. In this case, you can
disable code generation while you make the changes, and then enable it again when you are finished.
While code generation is disabled, Studio keeps a list of all changes that you make to configuration resources, but
does not generate internal code for them. When you enable code generation again, Studio prompts you to run code
generation for the resources in the list. If you do not choose to immediately run code generation for the changes,
then you will need to rebuild the project later.
If you exit Studio while code generation is disabled, then Studio discards the list of changed resources, and you will
need to rebuild the project later.
Code generation in Guidewire Studio is enabled by default.

Procedure
1. In Guidewire Studio, click File→Settings.
2. In the Settings dialog, in the navigation list, expand Guidewire Studio, and then click Project Settings.
3. Do one of the following:
• To disable code generation, clear the Enable Automatic Code Generation check box.
• To enable code generation, set the Enable Automatic Code Generation check box.

Change code generation for XML classes to generate source code

About this task
By default, code generation for XML classes directly generates bytecode, rather than generating Java or Gosu source
code that is then compiled. You can change the behavior of code generation for XML classes so that it also produces
source code that is compiled. Note that producing source code is slower than directly generating bytecode.
506 chapter 34: Testing and debugging your configuration
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Procedure

1. In Guidewire Studio, in the Project tool window, navigate to configuration→res, and then to the file
[Link].
2. Double-click the file [Link] to edit it.
3. Edit the desired <module> element, and set the attribute generate-xml-sources to true.
For example:

<module xmlns="[Link] generate-xml-sources="true" ...>

To restore the default behavior, remove the attribute or set it to false.

Change PCF code generation error behavior

About this task

During a product upgrade, the configuration will contain a large number of errors that prevent the application from
building successfully. Many of these errors are likely to be in the code generation of PCF files. To help you
successfully build the application as quickly as possible, you can instruct Guidewire Studio to treat PCF errors as
warnings instead. Warnings during a build do not cause the build to fail, and so you can focus on fixing other
configuration files and producing a build that Studio considers successful.
Once you have a successful build, you can then run Build→Make Project to build only changed resources rather than
the entire project.

Procedure

1. In Guidewire Studio, click File→Settings.

2. In the Settings dialog, in the navigation list, expand Build, Execution, Deployment, then expand Compiler, and then
click Gosu Compiler.
3. To treat PCF errors as warnings that do not cause a build to fail, set Treat PCF code generation errors as warnings.

Suggestions for testing rules

Guidewire recommends that you practice the following simple suggestions to make testing and debugging your rules
a straightforward process:
• Enter one rule at a time and monitor for syntax correctness—check the green light (at the bottom of the pane)
before starting a new rule.
• Enter rules in the order in which you want the debugger to evaluate them: Condition and then Action.
• Maintain two sessions while testing. As you complete and save each rule in Studio, toggle to an open
PolicyCenter session and test before continuing. You only need save and activate your rules before testing. You
do not need to log in again.
For multi-conditioned rules, you can print messages to the console after each action for easy monitoring. The
command for this is print("message text"). The message prints in the server console. This is helpful if you want
to test complex rules and verify that Studio evaluated each case.
Other print-type statements that you can use for testing and debugging include the following:
[Link]
[Link]
[Link]
[Link]

These all log messages as specified by the PolicyCenter logging settings.

Testing and debugging your configuration 507
Guidewire PolicyCenter 9.0.9 Configuration Guide

Compiling and building the application

PolicyCenter provides a built-in QuickStart application server for running and testing your application without
needing to deploy it to your production environment. Before you can run the application this way, you must first
compile it.

508 chapter 34: Testing and debugging your configuration

chapter 35

Using GUnit

You use Studio GUnit to configure and run repeatable tests of your Gosu code in a similar fashion as JUnit works
with Java code. (GUnit is similar to JUnit 3.0 and compatible with it.) GUnit works automatically and seamlessly
with the embedded QuickStart servlet container, enabling you to see the results of your GUnit Gosu tests within
Studio.
GUnit provides a complete test harness with base classes and utility methods. You can use GUnit to test any body of
Gosu code except for Gosu written as part of Rules. (To test Gosu in Rules, use the Studio debugger. See “Testing
and debugging your configuration” on page 499 for details.)
Note: Guidewire does not recommend or support the use of classes that extend
[Link] or classes that reside in the [Link].* package in
a production environment. Guidewire provides GUnit as a development test facility only.

The TestBase class

Guidewire uses the TestBase class as the root class for all GUnit tests. Your test class must extend the Guidewire
TestBase class. This class provides the following:
• The base test infrastructure, setting up the environment in which the test runs.
• A set of assert methods that you can use to verify the expected result of a test.
• A set of beforeXX and afterXX methods that you can override to provide additional testing functionality (for
example, to set up required data before running a test method).
The TestBase class interacts with an embedded QuickStart servlet container in running your GUnit tests. This class
has access to all of the embedded QuickStart server files and servlets. (GUnit starts and stops the embedded
QuickStart servlet container automatically. You have no control over it.) This class also initializes all server
dependencies.

Overriding TestBase methods

Guidewire exposes two groups of beforeXX and afterXX methods in the TestBase class that you can use to
perform certain actions before and after the tests execute. These methods are a way to set up any required
dependencies for tests and to clean up after a test finishes.

Using GUnit 509

Guidewire PolicyCenter 9.0.9 Configuration Guide

To use one of these methods, you need to provide an overridden implementations of the method in your test class.
• Use beforeClass to perform some action before GUnit instantiates the test class.
• Use afterClass to perform some action after all the tests complete but before GUnit destroys the class.
• Use beforeMethod to perform some action before GUnit invokes a particular test method.
• Use afterMethod to perform some action after a test method returns.
These methods have the following signatures.
beforeClass() throws Exception {...}
afterClass() {...}
beforeMethod() throws Exception {...}
afterMethod(Throwable possibleException) {...} //If the test resulted in an exception, parameter
//posibleException contains the exception.

Initializing static and instance variables in a TestBase test class

When implementing a TestBase test class and running that class in Studio, do not use static initializers or initialize
variables in a constructor. Instead, initialize variables on the class as follows:
• Initialize static variables on the class by overriding the beforeClass method and initializing the variable in that
method.
• Initialize instance variables by overriding the beforeMethod method and initializing the variable in that method.
For example, when initializing a class that uses the typekey type:
class MyTypekeyRelatedTest extends TestBase
static var _transCurrency : Currency

override function beforeClass() {

[Link]() // must call super method!

_transCurrency = Currency.TC_EUR
...
}
...
}

The following is another example for initializing a class that uses a third-party library:
class MyComplicatedTest extends TestBase
var _testHelper : ThirdPartyClass

override function beforeMethod() {

[Link]() // must call super method!

_testHelper = new ThirdPartyClass()

...
}
...
}

Data builders

If you need to set up test data before running a test, Guidewire recommends that you use a “data builder” in one of
the beforeXX methods.
• See “Using entity builders to create test data” on page 516 for details on how to create test data.
• See “Creating and testing a builder for a custom entity” on page 523 for details of using the beforeClass
method to create test data before running a test.

Configuring the server environment

Annotations control the way GUnit interacts with the system being tested. There are two types of annotations:
510 chapter 35: Using GUnit
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Annotation type Description More information

Server Runtime This annotation indicates that this test interacts with the server. “Server runtime” on page 511
Server Environment These can provide additional test functionality. Use then to replace “Server environment” on
or modify the default behavior of the system being tested. page 511

To use an annotation, either enter the full path:

@[Link]

Or, you can add a uses statement at the beginning of the file, for example:
uses [Link]
...
@ServerTest

Server runtime
A server test is a test written in the environment of a running server. The test and the server exist in the same JVM
(Java Virtual Machine) and in the same class loader. This allows the test to communicate with the server using
standard variables. In the base configuration, Guidewire uses an embedded QuickStart servlet container pointing at a
Web application to run the tests.
PolicyCenter interprets any class that contains the annotation @ServerTest immediately before the class definition
as a server test. If you create a test class through Guidewire Studio, then Studio automatically adds the server
runtime annotation @ServerTest immediately before the class definition. At the same time, Studio also adds
extends [Link] to the class definition. All GUnit tests that you create must extend this class.
(See the “The TestBase class” on page 509 for more information on this class.)
Although Studio automatically adds the @ServerTest annotation to the class definition, it is possible to remove this
annotation safely. As the TestBase class already includes this annotation, Guidewire does not explicitly require this
annotation in any class that extends the TestBase class.
By default, the server starts at a run level set to Runlevel.NO_DAEMONS. To change this default, see the description
of the @RunLevel annotation in the next section.

Server environment
Environment tags provide additional functionality. You use environment tags to replace functionality specific to an
external environment. This can include defining new SOAP endpoints or creating tests for custom PCF page, for
example.
Guidewire provides the following environment tags for use in GUnit tests.

Annotation (@[Link]‐ Description

tharness.*)
@ChangesCurrentTime Sets up a mock system clock that allows the test to change the current time during the test.
@ProductionMode GUnit runs tests against the QuickStart servlet container, by default, in “development” mode. If de‐
sired, you can direct GUnit to runs tests against the QuickStart servlet container in “production”
mode, which duplicates the system functionality available to a running production application serv‐
er. If you do so, you may lose test functionality that is only available in development mode (for ex‐
ample, access to the system clock).
You can check the server mode in Gosu, using the following:
[Link]()

Using GUnit 511

Guidewire PolicyCenter 9.0.9 Configuration Guide

Annotation (@[Link]‐ Description

tharness.*)
@RunLevel Allows a test to run at a different run level. The default value is Runlevel.NO_DAEMONS. You can,
however, change the run level to one of the following (although each level takes a bit more time to
set up):
• [Link] ‐ Use if you do not want any dependencies at all.
• [Link] ‐ Use if you want all the basic dependencies set up, but with no database
connection support.
• Runlevel.NO_DAEMONS ‐ Use for a normal server startup without background tasks. (This is also
subtable for SOAP tests.)
• [Link] ‐ Use to start a complete server (batch process, events, rules, Web
requests, and all similar components).

Configuring the test environment

You define the run and debug parameter settings for a GUnit test class through the Run/Debug Settings dialog, which
you can access in any of the following ways:
• Click Run→Edit Configurations.
• On the main toolbar, in the Select Run/Debug Configuration drop-down list, click Edit Configurations.
• In the Project tool window, right-click the test package, and then click Create 'Tests in 'PackageName''.
• Open the test class in the editor, right-click anywhere in the method, and then click Create 'testName()'.
You can set various default configuration parameters for all tests, or configure parameters for a particular test.

Set default configuration parameters for all tests

About this task
It is possible to set a number of default configuration parameters that GUnit uses for all tests.

Procedure
1. In the Run/Debug Configurations dialog, expand Defaults, and then click Junit.
2. Enter the default configuration parameters as appropriate.

Add a named set of configuration parameters for tests

About this task
It is possible to create a defined set of configuration parameters to use with one or more tests.
• Add that configuration under the Application section of the list in the Run/Debug Configurations dialog.

View test configuration settings before launching

About this task
It is possible to turn on, or off, the Run/Debug Configurations dialog before running a test.

Procedure
1. To view the GUnit configuration settings before launching a test, expand the Before launch section of that
dialog.
2. Set the Show this page check box.
512 chapter 35: Using GUnit
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Result
If you unset this option, you do not see the Run/Debug Configurations dialog upon starting a test. Instead, the test starts
immediately. In addition, selecting Run or Debug from the Studio Run menu does not open this dialog either. To
access the Run/Debug Configurations dialog again, click Run→Edit Configurations.

Configuration parameters
Use the Run/Debug Configurations dialog to enter the following configuration parameters:
• “Name” on page 513
• “Test Kind” on page 513
• “VM options” on page 513
You may not see some of the parameter fields until you actually load a test into Studio and select it. See “Creating a
GUnit test class” on page 513 for information on how to create a GUnit test within Guidewire Studio.

Name
If desired, you can set up multiple run and debug GUnit configurations. Each named configuration represents a
different set of run and debug startup properties. To create a new named configuration, do one of the following:
• Click Add and create a new blank configuration.
• Select an existing configuration, then click Copy Configuration to copy the existing configuration parameters to
the new configuration.
• Select the test class in the Project window, and then click either Run ‘TestName’ or Debug ‘TestName’. Then, select the
name of the test from the list of GUnit tests and click OK. This has an advantage of populating the fully qualified
class name field.
After you add the new configuration node on the left-hand side, you can enter a name for it on the right-hand side of
the dialog.

Test Kind
Use to set whether to test all the classes in a package, a specific class, or a specific method in a class. The text entry
field changes as you make your selection.
• For All in Package, enter the fully qualified package name. Select this option to run all GUnit tests in the named
package.
• For Class, enter the fully qualified class name. Select this option to run all GUnit tests in the named class.
• For Method, enter both the fully qualified class name and the specific method to test in that class.

VM options
Use to set parameters associated with the JVM and the Java debugger. To set specific parameters for the JVM to use
while running this configuration, enter them as a space separated list in the VM Options text box. For example:
-client -Xmx700m -Xms200m -XX:MaxPermSize=100m -ea

You can change the JVM parameters based on the test. For example, while testing a large class or while running
numerous test methods within a class, you may want to increase your maximum heap size.

Creating a GUnit test class

The following is an example of a GUnit test class. Use this sample code as a template in creating your own test
classes.
package AllMyTests

Using GUnit 513

Guidewire PolicyCenter 9.0.9 Configuration Guide

uses [Link]
@[Link]
class MyTest extends TestBase {

construct(testname : String) {
super(testname)
}
...
function testSomething() {
//perform some test
assertEquals("reason for failure", someValue, someOtherValue)
}
...
}

Notice the following:

• The test class exists in the package AllMyTests. Thus, the full class path is [Link]. You
must place your test classes in the modules/configuration/gtest [Link] are free, however, to name your
test subpackages as you choose.
• The class file name and the class name are identical and end in Test.
• The test class extends TestBase.
• The class definition files contains a @ServerTest annotation immediately before the class definition.
• The class definition contains a construct code block. This code block can be empty or it may contain
initialization code.
• The class definition contains one or more test methods that begin with the word test. The word test is case-
sensitive. For example, GUnit will recognize the string testMe as a method name, but not the string TestMe.
• The test method contains one or more assert methods, each of which “asserts” an expected result on the object
under test.

Server tests
You specify the type of test using annotations. Currently, Guidewire supports server tests only. Server tests provide
all of the functionality of a running server. You must include the @ServerTest annotation immediately before the
test class definition to specify that the test is a server test. See “Configuring the server environment” on page 510 for
more information on annotations.

The construct block

Gosu calls the special construct method if you create a new test using the new Object construction. For example:
construct( testname : String ) {
super( testname )
}

This construct code block can be empty or it may contain initialization code.

Test methods
Within your test class, you need to define one or more test methods. Each test method must begin with the word
test. (GUnit recognizes a method as test method only if the method name begins with test. If you do not have at
least one method so named, GUnit generates an error.) Each test method uses a verification method to test a single
condition. For example, a method can test if the result of some operation is equal to a specific value. In the base
configuration, Guidewire provides a number of these verification methods. For example:
• assertTrue
• assertEquals
• verifyTextInPage
• verifyExists
• verifyNull
514 chapter 35: Using GUnit
 Guidewire PolicyCenter 9.0.9 Configuration Guide

• verifyNotNull
Many of these methods appear in multiple forms. Although there are too many to list in their entirety, the following
are some of the basic assert methods. To see a complete list of these methods in their many forms, use the code
completion feature in Studio.
assertArrayDoesNotContain
assertArrayEquals
assertBigDecimalEquals
assertBigDecimalNotEquals
assertCollection
assertCollectionContains
assertCollectionDoesNotContain
assertCollectionContains
assertCollectionSame
assertComparesEqual
assertDateEquals
assertEmpty
assertEquals
assertEqualsIgnoreCase
assertEqualsIgnoreLineEnding
assertEqualsUnordered
assertFalse
assertFalseFor
assertGreaterThan
assertIteratorEquals
assertIteratorSame
assertLength
assertList
assertListEquals
assertListSame
assertMethodDeclaredAndOverridesBaseClass
assertNotNull
assertNotSame
assertNotZero
assertNull
assertSame
assertSet
assertSize
assertSuiteTornDown
assertThat
assertTrue
assertTrueWithin
assertZero
...

The assertThat Method

Choosing the assertThat method opens up a whole variety of different types of assertions, dealing with strings,
collections, and many other object types. To see a complete list of this method in its many forms, use the code
completion feature in Studio.

Failure Reasons for Asserts

Guidewire strongly recommends that, as appropriate, you use an assert method that takes a string as its first
parameter. For example, even though Guidewire supports both forms of the following assert method, the second
form is preferable, as it includes a failure reason.
assertEquals(a, b)
assertEquals("reason for failure", a, b)

Guidewire recommends that you document a failure reason as part of the method rather than adding the reason in a
comment. The GUnit test console displays this text string if the assert fails, which makes it easier to understand the
reason of a failure.

Create a GUnit test class

Procedure
1. In the Project tool window, navigate to configuration→gtest.
Using GUnit 515
Guidewire PolicyCenter 9.0.9 Configuration Guide

2. Right-click gtest, and then click New→Package.

3. In the Enter new package name text box, type the name of the package.
4. Right-click the new package, and then click New→Gosu Class.
5. In the Name text box, type the name of the test class. This class file name must match the test class name and
both must end in “Test”. This action creates a class file containing a “stub” class.
For example, if your class file is [Link], Studio populates the file with the following Gosu:
package demo

@[Link]
class MyTest extends [Link] {
construct() {
...
}
...
}

Run a GUnit test

Procedure
1. In the Project tool window, navigate to configuration → gtest, and then to your test class.
2. Right-click the test, and then click either Run ‘TestName’ or Debug ‘TestName’. This action opens a test console at
the bottom of the screen.

Next steps
If desired, you can also create individual run/debug settings to use while running this test class. For details, see
“Configuring the test environment” on page 512.

Using entity builders to create test data

Note: Guidewire does not recommend or support the use of classes that extend
[Link] or classes that reside in the [Link].* package in
a production environment. Guidewire provides GUnit as a development test facility only.
As you run tests against code, you need to run these test in the context of a known set of data objects. This set of
objects is generally known as a test fixture. You use Gosu entity builders to create the set of data objects to use in
testing.
Guidewire provides a number of entity “builders” as utility classes to quickly and concisely create objects (entities)
to use as test data. The PolicyCenter base configuration provides builders for the base entities. However, if desired,
you can extend the base DataBuilder class to create new or extended entities. You can commit any test data that
you create using builders to the test database using the [Link] method.
For example, the following builder creates a new Person object with a FirstName property set to “Sean” and a
LastName property set to “Daniels”. It also adds the new object to the default test bundle.
var myPerson = new PersonBuilder()
.withFirstName("Sean")
.withLastName("Daniels")
.create()

For readability, Guidewire recommends that you place each configuration method call on an indented separate line
starting with the dot. This makes code completion easier. It also makes it simpler to alter a line or paste a new line
into the middle of the chain or to comment out a line.
Gosu builders extend from the base class [Link]. To view a list of valid builder types
in Guidewire PolicyCenter, use the Studio code completion feature. Type [Link]. in the Gosu editor
and Studio displays the list of available builders.
516 chapter 35: Using GUnit
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Package completion
As you create an entity builder, you must either use the full package path, or add a uses statement at the beginning
of the test file. However, in general, Guidewire recommends that you place the package path in a uses statement at
the beginning of the file.
uses [Link]

@[Link]
class MyTest extends TestBase {

construct(testname : String) {
super(testname)
}
...
function testSomething() {
//perform some test
var account = new AccountBuilder().create()
}
...
}

Guidewire provides certain of the Builder classes in [Link].* and others in [Link].
Verify the package path as you create new builders.

Creating an entity builder

To create a new entity builder of a particular type, use the following syntax:
new TypeOfBuilder()

This creates a new builder of the specified type, with the Builder class setting various default properties on the
builder entity. Each entity builder provides different default property values depending on its particular
implementation. For example, to create (or build) a default address, use the following:
var address = new AddressBuilder()

To set specific properties to specific values, use the property configuration methods. The following are the types of
property configuration methods, each which serves a different purpose as indicated by the method’s initial word:

Initial word Indicates

on A link to a parent. For example, PolicyPeriod is on an Account, so the method is onAccount(Account
account).

as A property that holds only a single state. For example, asSmallBusiness or asAgencyBill.
with The single element or property to be set. For example, the following sets a FirstName property:
withFirstName("Joe")

Use a [Link](...) configuration method to add a single property or value to a builder object. For
example, the following Gosu code creates a new Address object and uses a number of with(...) methods to
initialize properties on the new object. It then uses an asType(...) method to set the address type.
var address = new AddressBuilder()
.withAddressLine1( streetNumber + " Main St." )
.withAddressLine2( "Suite " + suiteNumber)
.withCity( "San Mateo" )
.withState( "CA" )
.withPostalCode( postalCode )
.asType(typeStr)
...

After you create a builder entity, you are responsible for writing that entity to the database as part of a transaction
bundle. In most cases, you must use one of the builder create methods to add the entity to a bundle. Which create
method one you choose depends on your purpose.
To complete the previous example, add a create method at the end.
Using GUnit 517
Guidewire PolicyCenter 9.0.9 Configuration Guide

var address = new AddressBuilder()

.withAddressLine1( streetNumber + " Main St." )
...
.create()

Builder create methods

The DataBuilder class provides the following create methods:
[Link]( bundle )
[Link]()
[Link]()

The following list describes these create methods.

Method Description
create() Creates an instance of this builder's entity type in the default bundle. This method does not commit the
bundle. Studio resets the default bundle before every test class and method.
createAndCommit() Creates an instance of this builder’s entity type in the default bundle, and performs a commit of that
default bundle.
create(bundle) Creates an instance of this builder’s entity type, with values determined by prior calls to the entity. The
bundle parameter sets the bundle to use while creating this builder instance.

The no‐argument create method

The no-argument create method uses a default bundle that all the builders share. This is adequate for most test
purposes. However, as all objects created this way share the same bundle, committing the bundle on just one of the
created objects commits all of the objects to the database. This also makes them available to the PolicyCenter
interface portion of a test. For example:
var address = new AddressBuilder()
.withCity( "Springfield" )
.asHomeAddress()
.create()

new PersonBuilder()
.withFirstName("Sean")
.withLastName("Daniels")
.withPrimaryAddress(address)
.create()

[Link]()

In this example, Address and Person share a bundle, so committing [Link] also stores Person in the
database. If you do not need a reference to the Person, then you do not need to store it in a variable.
GUnit resets the default bundle before every test class and method.

The create and commit method

The createAndCommit method is similar to the create method in that it adds the entity to the default bundle. It
then, however, commits that bundle to the database.

The create with bundle method

If you need to work with a specific bundle, use the create(bundle) method. Guidewire recommends that you use
this method inside of a transaction block. A transaction block provides the following:
• It creates the bundle at the same time as it creates the new builder.
• It automatically commits the bundle as it exits.
The following example illustrates the use of a data builder inside a transaction block.
uses [Link]

518 chapter 35: Using GUnit

 Guidewire PolicyCenter 9.0.9 Configuration Guide

function myTest() {
var person : Person

[Link]( \ bundle -> {

person = new PersonBuilder()
.withFirstName( "John" )
.withLastName( "Doe" )
.withPrimaryAddress( new AddressBuilder()
.withCity( "Springfield" )
.asHomeAddress() )
.create( bundle )
} )

assertEquals( "Doe", [Link] )

Notice the following about this example:

• The example declares the person variable outside the transaction block, making it accessible elsewhere in the
method.
• The data builder uses an AddressBuilder object nested inside PersonBuilder to build the address.
• The [Link] statement creates the bundle and automatically commits it after Gosu
Runtime executes the supplied code block.
In summary, the create(bundle) method does not create a bundle. Rather, it uses the bundle passed into it.
Guidewire recommends that you use this method inside a transaction block that both creates the bundle and commits
it automatically.
If you do not use this method inside a transaction block that automatically commits a bundle, then you must commit
the bundle yourself. To do so, add [Link] to your code.

Entity builder examples

The following examples illustrate various ways that you can use builders to create sample data for use in GUnit
tests.
• “Creating multiple objects from a single builder” on page 519
• “Nesting builders” on page 519
• “Overriding default builder properties” on page 520

Creating multiple objects from a single builder

The Builder class creates the builder object at the time of the create call. Therefore, you can use the same builder
instance to generate multiple objects.
uses [Link]

var activity1 : Activity

var activity2 : Activity

[Link]( \ bundle -> {

var activityBuilder = new [Link]()
.onClaim(new ClaimBuilder().uiReadyAuto().create(bundle) )
.withType( "general" )
.withPriority( "high" )
activity1 = [Link]( "this is test activity one" ).create( bundle )
activity2 = [Link]( "this is test activity two" ).create( bundle )
}, "su")

Nesting builders
It is possible to nest one builder inside of another by having a method on a builder that takes another builder as an
argument. For example, suppose that you want to create an Account that has an AccountLocation. In this situation,
you might want to do the following:
Using GUnit 519
Guidewire PolicyCenter 9.0.9 Configuration Guide

var account = new AccountBuilder()

.withAccountLocation(new AccountLocationBuilder()).createAndCommit()

Overriding default builder properties

The following code samples illustrates multiple ways to create an Account object. The first code sample shows a
simple test method and uses a transaction block. The Transaction object takes a block, which assigns the new
account to the variable in the scope outside of the transaction.
function myTest(){
var account : Account
[Link]( \ bundle -> {
account = new AccountBuilder().create(bundle)
})
}

There are generally two kinds of accounts: person and company. By default, AccountBuilder creates a person
account. If you want a company account, then you need to assign a company contact as the account holder, as shown
in the following code sample:
uses [Link]
uses [Link]

var account = new AccountBuilder(false)

.withAccountHolderContact(new CompanyBuilder(42))
.createAndCommit()

In this example, passing false to AccountBuilder tells it not to create a default account holder. Instead, you pass in
your own account holder by calling withAccountHolderContact, which takes a ContactBuilder. In this case,
CompanyBuilder suffices. The passed in number 42 seeds the default data with something unique (ideally) and
identifiable.
The following example creates a company account and overrides some of the default values. Anywhere you see
code, it means a seed value. (String variants derive from the given values.) It also illustrates how to nest the results
of one builder inside another.
uses [Link]
uses [Link]
uses [Link]
uses [Link]

var code = 48

var address = new AddressBuilder()

.withAddressLine1(code + " Main St.")
.withAddressLine2("Suite " + code)
.withCity("San Mateo")
.withState("CA")
.withPostalCode("94404-" + code)
.asBusinessAddress()

var company = new CompanyBuilder(code, false)

.withCompanyName("This Company " + code)
.withWorkPhone("650-555-" + code)
.withAddress(address)
.withOfficialID(new OfficialIDBuilder().withType("FEIN").withValue("11-222" + code))

var account = new AccountBuilder(false)

.withIndustryCode("1011", "SIC")
.withAccountOrgType( "Corporation" )
.withAccountHolderContact(company)
.createAndCommit()

The following example takes the previous code and presents it as a single builder that takes other builders as
arguments. While more compact, it also takes more planning and understanding of builders to create. Notice the
successive levels of indenting used to signal the creation of a new (embedded) builder.
uses [Link]
uses [Link]
uses [Link]
uses [Link]

520 chapter 35: Using GUnit

 Guidewire PolicyCenter 9.0.9 Configuration Guide

var account = new AccountBuilder(false)

.withIndustryCode("1011", "SIC")
.withAccountOrgType("Corporation")
.withAccountHolderContact(new CompanyBuilder(code, false)
.withCompanyName("This Company " + code)
.withWorkPhone("650-555-" + code)
.withAddress(new AddressBuilder()
.withAddressLine1(code + " Main St.")
.withAddressLine2("Suite " + code)
.withCity("San Mateo")
.withState("CA")
.withPostalCode("94404-" + code)
.asBusinessAddress()
)
.withOfficialID(new OfficialIDBuilder()
.withType("FEIN")
.withValue("11-222" + code))
)
.createAndCommit()

Creating new builders

If you need additional builder functionality than that provided by the PolicyCenter base configuration builders, you
can do either of the following:
• Extend an existing builder class and add new builder methods to that class.
• Extend the base DataBuilder class and create a new builder class with its own set of builder methods.
You can also create a builder (by extending the DataBuilder class) for a custom entity that you created, if desired.
For more information, see the following:
• “Extending an existing builder class” on page 521
• “Extending the DataBuilder class” on page 522
• “Creating and testing a builder for a custom entity” on page 523

Extending an existing builder class

To extend an existing builder class, use the following syntax:
class MyExtendedBuilder extends SomeExistingBuilder {
construct() {
...
}
...
function someNewFunction() : MyExtendedBuilder {
...
return this
}
...
}

The following MyPersonBuilder class extends the existing PersonBuilder class. The existing PersonBuilder
class contains methods to set a home phone number and mobile phone number. The new extended class contains a
method to set the person’s alternative phone number. As there is no static field for the properties on a type, you must
look up the property by name. Note that you must first define the new property in the data model.
uses [Link]

class MyPersonBuilder extends PersonBuilder {

construct() {
super( true )
}

function withAltPhone( testname : String ) : MyPersonBuilder {

set(Person#AltPhone, testname)
return this
}

Using GUnit 521

Guidewire PolicyCenter 9.0.9 Configuration Guide

The PersonBuilder class has two constructors. This code sample uses the one that takes a Boolean that means
create this class withDefaultOfficialID.
Another more slightly complex example would be if you extended the Person object and added a new
PreferredName property. In this case, you might want to extend the PersonBuilder class also and add a
withPreferredName method to populate that field through a builder.

Extending the DataBuilder class

To extend the DatabBuilder class, use the following syntax:
class MyNewBuilder extends DataBuilder<BuilderEntity, BuilderType> {

...

The DataBuilder class takes the following parameters:

Parameter Description
BuilderEntity Type of entity created by the builder. The create method requires this parameter so that it can return a
strongly‐typed value and, so that other builder methods can declare strongly‐typed parameters.
BuilderType Type of the builder itself. The with methods require this on the DataBuilder class so that it can return a
strongly‐typed builder value (to facilitate the chaining of with methods).

If you choose to extend the DataBuilder class ([Link]), place your newly created
builder class in the [Link] package in the Studio Tests folder. Start any method that you define in
your new builder with one of the recommended words (described previously in “Creating an entity builder” on
page 517):

Initial word Indicates

on A link to a parent. For example, PolicyPeriod is on an Account, so the method is onAccount(Account
account).

as A property that holds only a single state. For example, asSmallBusiness or asAgencyBill.
with The single element or property to be set. For example, the following sets a FirstName property:
withFirstName("Joe")

Your configuration methods can set properties by calling [Link] and [Link].
You can provide property values as any of the following:
• Simple values.
• Beans to be used as subobjects.
• Other builders, which PolicyCenter uses to create subobjects if it calls your builder's create method.
• Instances of [Link], which can, for example, generate a different value (to
satisfy uniqueness constraints) for each instance constructed.
[Link] and [Link] optionally accept an integer order argument that
determines how PolicyCenter configures that property on the target object. (PolicyCenter processes properties in
ascending order.) If you do not provide an order for a property, Studio uses DataBuilder.DEFAULT_ORDER as the
order for that property. PolicyCenter processes properties with the same order value (for example, all those that do
not have an order) in the order in which they are set on the builder.
In most cases, Guidewire recommends that you omit the order value as you are implement builder configuration
methods. This enables callers of your builder to select the execution order through the order of the configuration
method calls.

522 chapter 35: Using GUnit

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Constructors for builders can call set, and similar methods to set up default values. These are useful to satisfy null
constraints so it is possible to commit built objects to the database. However, Guidewire generally recommends that
you limit the number of defaults. This is so that you have the maximum control over the target object.

Other DataBuilder classes

The [Link] package also includes [Link]. You can use this class,
for example, to generate a different value for each instance constructed to satisfy uniqueness constraints. The
databuilder package includes ValueGenerator class variants for generating unique integers, strings, and
typekeys:
• [Link]
• [Link]
• [Link]

Custom builder populators

Ideally, all building can be done through simple property setters, using the [Link] or
[Link] methods. However, you may want to define more complex logic, if these
methods do not suffice. To achieve this, you can define a custom implementation of
[Link] and pass it to [Link]. Guidewire
provides an abstract implementation, AbstractBeanPopulator, to support short anonymous BeanPopulator
objects.
The following example uses an anonymous subclass of AbstractBeanPopulator to call the withCustomSetting
method. This code passes the group to the constructor, and the code inside of execute only accesses it through the
vals argument. This allows the super-class to handle packaging details.
public MyEntityBuilder withCustomSetting( group : Group ) {

addPopulator( new AbstractBeanPopulator<MyEntity>( group ) {

function execute( e : MyEntity, vals : Object[] ) {

[Link]( vals[0] as Group )
}
} )

return this

The AbstractBeanPopulator class automatically converts builders to beans. That is, if you pass a builder to the
constructor of AbstractBeanPopulator, it returns the bean that it builds in the execute method. The following
example illustrates this.
public MyEntityBuilder withCustomSetting( groupBuilder : DataBuilder<Group, ?> ) : MyEntityBuilder {

addPopulator( new AbstractBeanPopulator<MyEntity>( groupBuilder ) {

function execute( e : MyEntity, vals : Object[] ) {

[Link]( vals[0] as Group )
}
} )

return this

Creating and testing a builder for a custom entity

About this task
It is also possible, if you want, to create a builder for a custom entity. For example, suppose that you want each
PolicyCenter user to have an array of external credentials (for automatic sign-on to linked external systems,
perhaps). To implement, you can create an array of ExtCredential on User, with each ExtCredential having the
following parameters:
Using GUnit 523
Guidewire PolicyCenter 9.0.9 Configuration Guide

Parameter Type
ExtSystem Typekey

UserName String
Password String

After creating your custom entity and its builder class, you would probably want to test it. To accomplish this, you
need to do the following:

Task Affected files More information

1. Create a custom ExtCredential array entity and [Link] “Creating and testing a builder for a
extend the User entity to include it. [Link] custom entity” on page 523

2. Create an ExtCrendentialBuilder by extending [Link] “Creating and testing a builder for a

the DataBuilder class and adding withXXX methods custom entity” on page 523
to it.
3. Create a test class to exercise and test your new [Link] “Creating and testing a builder for a
builder. custom entity” on page 523

Create a custom entity

To create a new array ExtCredential custom entity, do the following:
• Add the ExtSystem typelist (in the Typelist editor in Guidewire Studio).
• Define the ExtCredential array entity (in [Link], accessible through Guidewire Studio).
• Modify the array entity definition to include a foreign key to User (in [Link]).
• Add an array field to the User entity (in [Link]).

Procedure
1. Add an ExtSystem typelist. Within Guidewire Studio, navigate to config→Extensions→Typelist, and then right-
click New→Typelist. Add a few external system typecodes. (For example, add SystemOne, SystemTwo, or
similar items.)
2. Create ExtCredential. Right-click Entity, and then click New→Entity. Name this file [Link] and
enter the following:
<?xml version="1.0"?>
<entity xmlns="[Link] entity="ExtCredential" table="extcred"
type="retireable" exportable="true" platerform="true" >
<typekey name="ExtSystem" typelist="ExtSystemType" desc="Type of external system"/>
<column name="UserName" type="shorttext"/>
<column name="Password" type="shorttext"/>
<foreignkey name="UserID" fkentity="User" desc="FK back to User"/>
</entity>

3. Modify the User entity. Find [Link] (in Extensions→Entity). If it does not exist, then you must create it.
However, most likely, this file exists. Open the file and add the following:
<array name="ExtCredentialRetirable" arrayentity="ExtCredential"
desc="An array of ExtCredential objects" arrayfield="UserID" exportable="false"/>

See also
• For information on extending the Guidewire PolicyCenter base configuration entities, see “Extending a base
configuration entity” on page 242.
Create an ExtCredentialBuilder class
Next, you need to extend the base DataBuilder class to create the ExtCredentialBuilder class. Place this class in
its own package under configuration and in the gsrc folder.
524 chapter 35: Using GUnit
 Guidewire PolicyCenter 9.0.9 Configuration Guide

For example:
package AllMyClasses

uses [Link]

class ExtCredentialBuilder extends DataBuilder<ExtCredential, ExtCredentialBuilder > {

construct() {
super(ExtCredential)
}

function withType ( type: [Link] ) : ExtCredentialBuilder {

set([Link]( "ExtSystem" ), type)
return this
}

function withUserName( somename : String ) : ExtCredentialBuilder {

set([Link]( "UserName" ), somename)
return this
}

function withPassword( password : String ) : ExtCredentialBuilder {

set([Link]( "Password" ), password)
return this
}

Notice the following about this code sample:

• It includes a uses ... DataBuilder statement.
• It extends the Databuilder class, setting the BuilderType parameter to ExtCredential and the BuilderEntity
parameter to ExtCredentialBuilder. (See “Extending the DataBuilder class” on page 522 for a discussion of
these two parameters.)
• It uses a constructor for the super class—DataBuilder—that requires the entity type to create.
• It implements multiple withXXX methods that populate an ExtCredential array object with the passed in values.
Create an ExtCredentialBuilderTest class
Finally, to be useful, you need to reference your new builder in Gosu code. You can, for example, create a GUnit test
that uses the ExtCredentialBuilder class to create test data. Place this class in its own package in the Tests folder.
package MyTests

uses [Link]
uses [Link]

@[Link]
class ExtCredentialBuilderTest extends [Link] {

static var credential : ExtCredential

construct() {

function beforeClass () {
[Link]( \ bundle -> {
credential = new ExtCredentialBuilder()
.withType( "SystemOne" )
.withUserName( "Peter Rabbit" )
.withPassword( "carrots" )
.create( bundle )
}
)
}

function testUsername() {
assertEquals("User names do not match.", [Link], "Peter Rabbit")
}

function testPassword() {
assertEquals("Passwords do not match.", [Link], "carrots")
}

Using GUnit 525

Guidewire PolicyCenter 9.0.9 Configuration Guide

Notice the following about this code sample:

• It includes the uses statements for both ExtCredentialBuilder and [Link].
• It creates a static credential variable. As the code declares this variable outside of a method—as a class
variable—it is available to all methods within the class. (GUnit maintains a single copy of this variable.) As you
run a test, GUnit creates a single instance of the test class that each test method uses. Therefore, to preserve a
variable value across multiple test methods, you must declare it as a static variable. (For a description of the
static keyword and how to use it in Gosu, see the Gosu Reference Guide.)
• It uses a beforeClass method to create the ExtCredential test data. This method calls ExtCredentialBuilder
as part of a transaction block, which creates and commits the bundle automatically. GUnit calls the beforeClass
method before it instantiates the test class for the first time. Thereafter, the test class uses the test data created by
the beforeClass method. It is important to understand that GUnit does not drop the database between execution
of each test method within a test class. However, if you run multiple test classes together (for example, by
running all the test classes in a package), GUnit resets the database between execution of each test class.
• It defines several test methods, each of which starts with test, with each method including an assertXXX
method to test the data.
If you run the ExtCredentialBuilderTest class as defined, the GUnit tester displays green icons, indicating that
the tests were successful:

526 chapter 35: Using GUnit

Part 8

Guidewire PolicyCenter configuration

Guidewire PolicyCenter 9.0.9 Configuration Guide
chapter 36

PolicyCenter configuration guidelines

This topic provides guidelines for configuring PolicyCenter.

Guidelines for modularizing line‐of‐business code

Guidewire recommends that you define line-of-business code in the policy-line-methods classes. Avoid putting line-
of-business code in generic locations such as the rule sets, plugins, and non-line-of-business PCF files and Gosu
classes. This recommendation is intended to make upgrade easier by grouping line-of-business changes in the
[Link] package.

Example
The policy period plugin implementation ([Link]) implements the
postApplyChangesFromBranch method. Rather than putting code for each line of business directly in the plugin
implementation, this method calls postApplyChangesFromBranch for each line in the policy period:
override function postApplyChangesFromBranch(policyPeriod : PolicyPeriod, sourcePeriod : PolicyPeriod)
{
for (line in [Link]) {
[Link](sourcePeriod)
}
...
}

To implement functionality for the workers’ compensation line of business, the [Link]
class implements the postApplyChangesFromBranch method:
override function postApplyChangesFromBranch(sourcePeriod : PolicyPeriod) {
...
}

PolicyCenter configuration guidelines 529

Guidewire PolicyCenter 9.0.9 Configuration Guide

530 chapter 36: PolicyCenter configuration guidelines

chapter 37

Validation in PolicyCenter

This topic provides an overview of validation types in PolicyCenter, and also includes common validation topics.

Validation overview
PolicyCenter has several types of validation:
• Field validation – Is part of the PCF rendering framework and uses regular expressions to ensure that entry is
valid. For example, field validation checks that a phone number is in the correct format.
• Class-based – You can invoke Gosu class-based validation from PCF files, job processes, wizard steps,
workflow steps, integration plugins, and from any Gosu code. The validation class checks that certain conditions
are met. The class can raise errors or warnings that includes the validation level at which it failed. For example,
after entering vehicles on a Personal Auto policy in the submission wizard, your class-based validation code can
check that the policy has at least one driver. If not, the code raises an error at a particular validation level.
• Rules-based – On a database commit, for example when you click Next in wizard, PolicyCenter calls the
validation rules on each validatable object in the bundle. The rules check that certain conditions are met on the
object. If the conditions are met, the bundle can be saved. Otherwise, the rule raises a validation error or warning
that includes the validation level at which it failed.

Choosing between validation and underwriting authority

Both validation and underwriting authority provide mechanisms to stop the progress of a policy transaction. In the
base configuration, validation is checked before underwriting authority.
Use validation to prevent the progress of policy transactions that nobody can sign off on. Validation checks for:
• Missing or inconsistent data – Including things like a vehicle on a personal auto policy without a VIN at bind
time, as well as conflicting coverages or terms.
• Structurally inappropriate policies – For example, some insurers do not ever permit a personal auto policy with
no vehicles.
Use underwriting authority to restrict who can progress a policy transaction that at least somebody in the
organization could sign off on. If only certain people within the insurer organization can approve writing a policy in
California, then use an underwriting rule.
However, if the insurer will never write a policy in the state of California under any circumstances, then use a
validation rule.

Validation in PolicyCenter 531

Guidewire PolicyCenter 9.0.9 Configuration Guide

Field‐level validation
Field validators handle simple validation for a single field. A validator definition defines a regular expression, which
a data field must match to be valid. It can also define an optional input mask that provides a visual indication to the
user of the data to enter in the field.
PolicyCenter field-level validation is not part of the class- or rule-based validation framework. Field-level validation
does not involve Gosu business rules or classes. It is simply part of the PCF rendering framework.
The PolicyCenter rendering framework builds the user interface from sets of PCF files. During the rendering
process, PolicyCenter performs any field-level checks that have been configured in the PCF files. For example, if
you configure a specific field in a PCF as required, then if the user leaves that required field empty, the rendering
framework generates a user error.
This type of field-level validation is independent of class- or rule-based validation. PolicyCenter performs this type
of validation before policy validation and displays problems that occur at the PCF level before it runs policy
validation or other processes.
Suppose that a user does not enter a value for the Fleet field on the (Submission wizard) Policy Info page. In this case,
the rendering framework automatically generates a field-level validation error as the user attempts to move to the
next step in the Submission wizard.
PolicyCenter generates the error message text string from the MissingRequired display key, substituting the field
name for the {0} variable:
[Link] = Missing required field "{0}"

In this particular instance, you specify that the Fleet field in the [Link] PCF file is required. You do this by
setting the required property to true.

Guidewire recommends that you also implement most of the field validation checks as class-based validation as
well. For example, implement a class-based validation method for the BA line that ensures that all required fields
have been set.

See also
• “Field validation” on page 297

532 chapter 37: Validation in PolicyCenter

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Class‐based data object validation

PolicyCenter performs class-based data object validation on policy and policy-related data objects. Class-based
validation is implemented in Gosu classes. In a Gosu class, you specify how PolicyCenter validates a particular data
object. A database commit does not automatically trigger class-based validation.
At any time, you can invoke Gosu class-based validation from PCF files, job processes, wizard steps, workflow
steps, integration plugins, and from any Gosu code. The validation class checks that certain conditions are met. The
class can raise errors or warnings that includes the validation level at which it failed. For example, after entering
vehicles on a Personal Auto policy in the submission wizard, your class-based validation code can check that the
policy has at least one driver. If not, the code raises an error at a particular validation level.
PolicyCenter runs full validation on the policy graph at critical points in the job process, such as before quoting or
binding.

See also
• “Class-based validation” on page 535

Rules‐based data object validation

PolicyCenter performs rules-based data object validation on non-policy objects. You define this kind of validation in
business rules, in the Studio Rules editor. Committing a data bundles to the database triggers rules-based validation,
if the bundle contains a validatable entity.
On a database commit, for example when you click Next in wizard, PolicyCenter call the validation rules on each
validatable object in the bundle. The rules check that certain conditions are met on the object. If the conditions are
met, the bundle can be saved. Otherwise, the rule raises a validation error or warning that includes the validation
level at which it failed.
In the base configuration, the following entities implement the Validatable delegate and are validatable:
• Account
• Activity
• Contact
• Group
• Organization
• ProducerCode
• Region
• User

See also
• Rules Guide

Validation in PolicyCenter 533

Guidewire PolicyCenter 9.0.9 Configuration Guide

534 chapter 37: Validation in PolicyCenter

chapter 38

Class‐based validation

This topic describes the class-based validation in Guidewire PolicyCenter, how to use it, and how to configure it.

See also

• “Validation in PolicyCenter” on page 531

Class‐based validation overview

Class-based validation works on policy objects only. These objects must be part of the policy graph. PolicyCenter
uses Gosu classes to define the validation logic. In these classes, you specify how and when to validate a particular
object.
Note: The terms object and entity—while not absolutely identical—are used interchangeably
throughout this topic. See the Rules Guide for a description of each.
In the base configuration, Guidewire provides class-based validation only for policy objects. The objects are:

• PolicyContact • Line‐of‐business entities

• PolicyLocation • Policy‐specific entities
• PolicyPeriod

IMPORTANT Guidewire does not recommend, nor support, the use of class-based validation as a
feedback mechanism for user action. Instead, if you need to provide that feedback, use confirmation
dialog boxes and user-viewable exceptions. Class-based validation is not appropriate in all contexts,
nor in all situations—use it carefully and thoughtfully.

Some features of class-based validation are:

• PolicyCenter permits configuration of class-based validation on any data object, including those objects that you
create by extending a base object. These objects do not need to implement the Validatable delegate.
• PolicyCenter performs validation as designated by the appropriate Gosu class, and when it commits data to the
database.
• PolicyCenter displays validation error and warning messages in the user interface only if they apply to the
validation level of the given context.

Class‐based validation 535

Guidewire PolicyCenter 9.0.9 Configuration Guide

See also
• “Policy object validation levels” on page 537

Validation classes in the base configuration

PolicyCenter performs class-based validation on policy-related entities any time that you call for validation on the
entity. In the base configuration, Guidewire provides validation classes that you can use with a specific entity. The
name of the validation class contains the name of the entity to which it applies or its purpose. The validation classes
extend PCValidationBase or PolicyLineValidation, directly or through inheritance. Some examples of
validation classes are:

All Lines of Business

• AnswerValidation
• FormPatternValidation
• InvariantValidation

Personal Auto
• PALineAssignmentValidator
• PALineCoveragesValidator
• PALineDriversValidator
• PALineQuickQuoteValidation
• PALineStepsValidator
• PALineValidation
• PALineVehiclesValidator
• PersonalVehicleValidation
There is nothing particularly special about these entities. Thus, they are not validatable entities in the sense that
rule-based validation entities are defined as validatable. Guidewire provides these validation classes to illustrate how
to create validation classes for specific purposes. For example, the base configuration validation classes illustrate:
• How to create a Gosu class that validates an entity in the PolicyCenter data model. [Link] is an
example of a class that validates the PersonalAutoLine entity.
• How to create a Gosu class that validates a wizard step, such as the Policy Info step in the submission wizard.
[Link] and [Link] provide examples of this type of validation.
See “Invoking class-based validation” on page 547 for an example of how to invoke validation from a wizard
step.
You can write your own Gosu validation classes and implement validation logic on any entity that you choose.
However:
• Each validation class that you create must implement the PCValidation interface. A convenient way to do this is
to extend PCValidationBase or one of its subtypes.
• Each validation class that you create must provide an overridden validate function.

See also
• “Configuring class-based validation” on page 536

Configuring class‐based validation

Through the Gosu validation classes, Guidewire provides methods to help you write checks to determine if one of
the policy-specific entities is passing validation at a certain priority level.
For example, you can use the following code to check if the validation level being tested is at least at the bindable
level:
536 chapter 38: Class‐based validation
 Guidewire PolicyCenter 9.0.9 Configuration Guide

if [Link](TC_BINDABLE)

Depending on the result of your validation checks, you can configure PolicyCenter to display an error or warning
message to the user.
To illustrate, suppose that one class-based check validates that an underwriting company must be assigned before
binding a policy. Thus, you define the following condition in a validation class to enforce the constraint and generate
an error message in PolicyCenter if the condition is not met.
var atBindable = [Link](TC_BINDABLE)
if ( ([Link] == null) && (atBindable == true) {
[Link](Period, "bindable", [Link]("[Link]")
}

PolicyCenter displays an error if both are true.

Policy object validation levels

In the base configuration, PolicyCenter defines a set of validation levels that you can use to verify how valid data is
before continuing. You can also create your own validation levels. You can use these validation levels in your Gosu
validation classes.
PolicyCenter defines a ValidationLevel typelist that you can use to set how valid data must be before continuing.
You can create your own validation levels. PolicyCenter uses the priority attribute of the typekeys to order the
validation levels. Low priority numbers are more restrictive. Thus, in the base configuration bindable with a
priority of 6000 is more restrictive than quotable with a priority of 7000.
The validate-on-commit process always checks against the special validation level default, which is the second-
least restrictive level (priority=8000).
In the base configuration, Guidewire defines three immutable validation levels. You cannot delete these validation
levels because PolicyCenter code requires them.

Level Priority Description

loadsave 10000 The least restrictive validation level against which PolicyCenter validates policies entering PolicyCenter
from an external application. All data must pass loadsave to be saved to the database.
default 8000 The default validation level against which PolicyCenter runs the ordinary validate‐on‐commit process.
PolicyCenter executes the flowstep filter at this level.
quotable 7000 The level a policy must pass before it can be sent to a rating engine.

PolicyCenter provides other validation levels in the base configuration. However, as Guidewire defines these levels
in the ValidationLevel typelist, it is possible to modify, remove, or even add to them using the Studio typelist
editor.

Level Priority Description

bindable 6000 The level a policy must pass before it can be bound. Binding finalizes a given job and promotes an
associated policy period to the main branch.
quickquotable 7200 The level a policy must pass before it is ready for a quick quote.
readyforissue 5000 The level a policy must pass before it can be issued. Issuance is the special job that occurs after
submission, causing the policy to become legally in effect.

Adding new validation levels

It is possible to add additional validation levels to meet your business needs. In configuring validation levels, you
can do the following:
Class‐based validation 537
Guidewire PolicyCenter 9.0.9 Configuration Guide

Validation level Description

System You can override the name and the priority of the three system validations levels:
• loadsave
• default
• quotable
Non‐system You can modify or delete any non‐system validation level at will.
Custom You can add new validation levels to the ValidationLevel typelist. To do so:
1. Open the ValidationLevel typelist.
2. Click Add and fill in the required information.

Validation package
Guidewire provides the following validation-related classes and interfaces in the [Link] package.

Class or Interface Description

PCValidation Interface that all validation classes must implement.
PCValidationContext Class that takes a ValidationLevel and creates a new PCValidationResult object during initializa‐
tion.
PCValidationBase Abstract convenience class that takes a PCValidationContext instance.
PCValidationResult Class that contains the object methods to use in generating warnings and errors.

The following object diagram illustrates these relationships.

538 chapter 38: Class‐based validation

 Guidewire PolicyCenter 9.0.9 Configuration Guide

PolicyCenter Class‐based Validation

[Link]

«interface»
PCValidation

PCValidationBase PCValidationContext
Context
Level

Result
PCValidationContext

ValidationResult
Legend
A relates to B
«typelist»
A B ValidationLevel
B relates to A *
A B A has a B

A B A has 0 or more Bs
EntityValidation ValidationIssue
* A is a subtype of B
A B A delegates to B *
A is enhanced by B
A B A implements B
Class names in italics indicate
an abstract class
«typelist»
ValidationIssueType
Guidewire Platform

PCValidation
All Gosu validation classes must implement the PCValidation interface. Any Gosu class (or any interface defined
in Gosu) that implements PCValidation can perform validation logic. This interface contains a single validate
method.
Classes that implement this interface can create methods that test for a single issue and call those method from their
implementation of the validate method. For an example, see [Link]. Through object
inheritance, the method doValidate does the validation:
override function doValidate() {
qualifiedGoodDriver()
appliedGoodDriverDiscount()
licenseInfoRequired()
...
}

PCValidationBase
Class PCValidationBase is a convenience class that implements PCValidation. Its constructor takes a validation
context (PCValidationContext) instance that holds the level at which to perform validation and the validation
results (warnings and errors).
Class‐based validation 539
Guidewire PolicyCenter 9.0.9 Configuration Guide

PCValidationBase provides a number of getter property methods. Some of the more important are:
property get Context() : PCValidationContext
property get Level() : ValidationLevel
property get Result() : PCValidationResult

PCValidationContext
Class PCValidationContext takes a ValidationLevel and creates a new PCValidationResult during
initialization.
This class has several important methods for use in managing validation. The following list describes each briefly.
However, for the most complete information, consult the Gosu API Reference documentation associated with the
method.

Method Description
addToVisited(validation, Use to track a complete listing of the checks that PolicyCenter performed during the
methodName) validation. The method returns false if the given [Link] and methodName
have been visited before. You can use this to determine that this particular validation
method does not need to be checked again.
This method only checks against the class name, not the validation object itself (using
hasVisited). Thus, for example, if you are validating multiple vehicles, you can not
discern whether a method has been visited for a specific vehicle.
hasVisited(className, Use to test whether the given combination of validation class name and method
methodName) name have been seen before. If so, the method returns true.
isAtLeast(ValLevel) Use to perform a test to determine if the level specified by ValidationContext is at
least valLevel. This method does not actually perform validation. Instead, you use
the information to determine whether you want to perform validation.
showVisited() Use to produce a string that lists the validation methods that were visited as valida‐
tion was performed with the provided Context. You can then use this string for de‐
bugging.
resetVisited() Resets the set of visited validation methods.
raiseExceptionIfProblemsFound() Throws an EntityValidationException if either errors or warnings have been add‐
ed to the validation context.
raiseExceptionIfErrorsFound() Throws an EntityValidationException only if errors have been added to the vali‐
dation context.

PCValidationResult
Class PCValidationResult holds the warnings and errors added by the validation implementation classes as
problems are discovered. Warnings are non-blocking. The user can clear warnings and continue. In contrast, errors
block further progress until the user resolves the problem.
PCValidationResult contains a number of object methods that you use in generating warnings and errors. The
following list describes the more important ones briefly. However, for the most complete information, consult the
Gosu API Reference documentation associated with the method.

Method Description
addError Use to add a general error message. This method takes the following arguments, of which the first three
are mandatory and the last optional:
• keyable bean (entity) that is the source of the error
• validation level associated with the error
• error reason to display to users
• ID of the wizard step where the error can be corrected
540 chapter 38: Class‐based validation
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Method Description
If you supply a wizardstepID, the method creates a link to the wizard step with ID wizardStepId if the
error is not in the current step.
addFieldError Use to add an error message specifically associated with a field on the given keyable bean as defined by
the relative FieldPath. This method takes the following arguments:
• keyable bean (entity) that is the source of the error
• field path to the field that must be changed to resolve the error
• validation level associated with the error
• error reason to display to users
• ID of the wizard step where the error can be corrected
If you supply a wizardstepID, the method creates a link to the wizard step with ID wizardStepId if the
error is not in the current step.
addWarning Similar to the addError method, except that it generates a warning rather than an error.
addFieldWarning Similar to the addFieldError method except that it generates a warning rather than an error.

PCValidationResult inherits several different forms of the reject method from the (platform) ValidationResult
class (which it subclasses).

Method form Description

reject Indicates a problem and provides an error message, but does not point to a specific field.
rejectField Indicates a problem with a particular field, provides an error message, and indicates the correct field to fix.

Validation chaining
In the base configuration, the [Link] class is an example of policy-graph validation
in which one validation class successively calls (chains to) other validation classes to perform additional validation.
For example, while running its validation checks for the policy period, PolicyPeriodValidation chains to:
• [Link] to validate the contact roles on the policy.
• [Link] to validate multiple roles on the same contact.
• [Link] to validate each policy location.
• [Link] to validate each of its lines of business.
• [Link] to validate that all specified modifiers are valid modifier type codes.
Validation chaining is the process of one validation class calling another validation class to perform additional
validation checks. Thus, to chain validation:
• A validate method in one validation class first calls the validation methods defined in its class.
• This validate method then invokes the validate method on another validation class (often by looping through
a set of objects).
• In turn, these classes chain to validations of entities they hold. For example, to validate all vehicles on a policy
for a Personal Auto policy period, PolicyPeriodValidation chains to PALineValidation which then chains to
PALineVehiclesValidator. PALineVehiclesValidator calls PALineCoveragesValidator,
PALineDriversValidator, PALineVehiclesValidator and PALineAssignmentValidator.
• After executing the validate methods in each of the related classes, control returns to the calling class. The
calling class can then perform additional validation checks.
It is important to understand that validation chaining is not automatic. For a class to perform validation chaining,
you must specifically construct it to do so. Guidewire specifically designed the PolicyPeriodValidation class to
perform validation chaining.

Class‐based validation 541

Guidewire PolicyCenter 9.0.9 Configuration Guide

Validation Chaining Example

The following graphic illustrates the concept of validation chaining. This is a simplified diagram—it does not show
every validation method call in the actual implementation. The actual implementation provides an easy way to
perform a full validation of the policy period.

542 chapter 38: Class‐based validation

 Guidewire PolicyCenter 9.0.9 Configuration Guide

PolicyPeriod

1
2 PolicyPeriodValidation

3 4
checkPeriodDates()
validateImpl()
5
checkQuoteNeededDate()

6
checkProductIsValid()

7
checkMinimumDataForQuote()

8
checkBillingInformation()

9
checkReportingPolicyIsCreatedWithFinalAudit()

10
checkOfficialIDs()

11
checkUnderwritingCompany()

12
checkAnswers()

Loop
[Location in PolicyLocations]

13 PolicyLocationValidation

14 15
allAccountLocationsAreActive
validate()
16
territoryCodeAgressWithLocation

17
checkAnswers

Loop [Line in PolicyLines]

18 PolicyLineValidation

19 20
policyPeriodOneYearMax()
validate()
DriversValidator
21
qualifiedGoodDriver()

22
appliedGoodDriverDiscount()
23
licenseInfoRequired()

...
.
...
.
n
.

24
checkUniqueKeyBeansHaveNoDuplicates()

25
checkNamedInsuredIndustryCode()
26
checkPolicyLocationIndustryCode()

27
checkReinsuranceForBindablePeriod()

28
checkReinsuranceForBindablePeriod()

29
checkPolicyAddress()

Class‐based validation 543

Guidewire PolicyCenter 9.0.9 Configuration Guide

Initially, the validateImpl method defined in PolicyPeriodValidation (3 in the graphic) executes a number of
validation methods defined in PolicyPeriodValidation, each of which tests for a certain condition. These
methods (labeled 4 through 12) are:
• checkPeriodDates
• checkQuoteNeededDate
• checkProductIsValid
• checkMinimumDataForQuote
• checkBillingInformation
• checkReportingPolicyIsCreatedWithFinalAudit
• checkOfficialIDs
• checkUnderwritingCompany
• checkAnswers
After these checks complete—still in the validateImpl method—the code executes a loop through all of the
Location objects in PolicyLocations (labeled 13). For each Location, it calls the PolicyLocationValidation
validate method on that object (labeled 14). The validation methods within PolicyLocationValidation (labeled
15 through 17) are:
• allAccountLocationsAreActive
• territoryCodeAgreesWithLocation
• checkAnswers
The PolicyPeriodValidation validateImpl method continues by invoking the validate method for each policy
line to perform line-specific validation:
[Link](\ line -> validateLine(line, \ validator -> [Link]() )

For example, if validating a Personal Auto line policy period, the code calls the validate method in
[Link] (labeled 19). This validation override first calls the local method
policyPeriodOneYearMax. It then chains to validate methods in a series of other validation classes:
• [Link]
• [Link]
• [Link]
• [Link]
Each of these validation classes contains its own override of doValidate. Among these, only a few of the methods
in DriversValidator are shown in diagram (labeled 21 through n). These methods perform specific checks for
driver qualifications, including:
• qualifiedGoodDriver
• appliedGoodDriverDiscount
• licenseInfoRequired
Each of the validators loops as needed to validate all of the coverages, assignments, vehicles, and drivers that apply
within the policy period being validated.
Finally, control returns to the original validateImpl method in PolicyPeriodValidation and calls additional
local validation methods (labeled 24 through 29), including:
• checkUniqueKeyBeansHaveNoDuplicates
• checkNamedInsuredIndustryCode
• checkPolicyLocationIndustryCode
The following topics discuss parts of this example in more detail:
• “PolicyPeriodValidation:validateImpl method” on page 545
• “PolicyPeriodValidation validation checks” on page 545
• “Invariant validation checks” on page 546
544 chapter 38: Class‐based validation
 Guidewire PolicyCenter 9.0.9 Configuration Guide

• “Static validation checks” on page 546

For an explanation of Gosu block definition and syntax, refer to the Gosu Reference Guide.

PolicyPeriodValidation:validateImpl method
Ideally, the validateImpl method simply directs the flow of logic. Rather than check for problems itself, Guidewire
recommends instead that the validateImpl method call other methods, each with a specific purpose. The
[Link] method demonstrates this approach. (The following is a simplified
version of the method code.)
override protected function validateImpl() {
if (not [Link](this, "validateImpl")) {
return
}
checkPeriodDates()
checkQuoteNeededDate()
checkProductIsValid()
...
checkAnswers()
...
[Link](\ role -> new PolicyContactRoleValidation(Context, role).validate())
[Link](\ roles -> new PolicyContactRoleForSameContactValidation(Context,
roles).validate())
[Link](\ loc -> new PolicyLocationValidation(Context, loc, validatedTerritoryCodes).validate())
[Link](\ line -> validateLine(line, \ validator -> [Link]()))
checkUniqueKeyBeansHaveNoDuplicates()
checkNamedInsuredIndustryCode()
checkPolicyLocationIndustryCode()
checkReinsuranceForBindablePeriod()
checkPolicyAddress()
[Link](\ m -> new ModifierValidation(Context, m).validate() )
new InvariantValidation(Context, Period).validate()
}

First, validateImpl registers the fact that it has been called. Notice how the validateImpl method perform no
checks itself. Instead the validateImpl method calls other methods such as checkPeriodDates and
checkPolicyAddress, all of which have a very narrowly focused purpose. Also notice that validateImpl chains to
validations for entities held by PolicyPeriod:
• PolicyContactRoleValidation
• PolicyContactRoleForSameContactValidation
• PolicyLocationValidation
• PolicyLineValidation

PolicyPeriodValidation validation checks

The PolicyPeriodValidation check methods test for specific conditions. Guidewire strongly recommends that the
method name summarize the test condition. The following code is for method checkOfficialIDs. This test ensures
that if the validation level is at or above bindable, all required official IDs for the named insured have been set for
all states on the policy.
Notice that the check method always registers itself with the Context, whatever the validation level. This is useful
for debugging as it makes it clear that the method was called during the course of validation. This is true even if no
message was added, which would be the case if no problems were discovered.
private function checkOfficialIDs() {
[Link](this, "checkOfficialIDs")
var linePatterns = [Link]*.Pattern

var states = [Link]*.[Link]()

if ([Link](TC_BINDABLE)) {
// check official IDs for each covered state
for (covstate in states) {
var checkOfficialIDs = [Link]
([Link](covstate))
.where(\id -> id typeis PCOfficialID and [Link]([Link]))
for (officialID in checkOfficialIDs) {
[Link](Period, Result)

Class‐based validation 545

Guidewire PolicyCenter 9.0.9 Configuration Guide

}
}
}
}

Invariant validation checks

The validateImpl method in the [Link] class also calls the following code:
new InvariantValidation(Context, Period).validate()

This code initiates what Guidewire calls invariant checks. PolicyCenter uses these checks to determine whether a
policy has been modified in ways that violate implied constraints to the data model.
The method call creates a new InvariantValidation object, whose validate method initiates the actual invariant
tests and checks.
In the base configuration, these tests perform the following entity checks:

Entity PolicyCenter checks that...

Coverage • Required coverage terms are not null.
• Direct coverage terms are within minimum and maximum constraints.
BusinessAutoLine If the Business Auto Line exists, then the correct policy line pattern is applied.
CoverageSymbolGroup • The coverage symbol group is compatible with policy line pattern.
• The coverage symbol is compatible with coverage symbol group pattern.
• The coverage symbol pattern does not have multiple instances. (Each coverage symbol must
appear only once).
Modifier The rate modifier value is within the allowed minimum and maximum values.
PolicyLine • A policy line subtype exists for a policy line.
• A policy line pattern exists for a policy line.
• The policy line type matches the subtype of the policy pattern.
Product The referenced policy line pattern is compatible with this product.
RateFactor • The rate factor pattern is compatible with the schedule credit pattern.
• The rate factor is within the allowable minimum and maximum values

Constraint Errors
If a check indicates that the user-defined product model violates one or more constraints, PolicyCenter generates an
appropriate error message.
PolicyCenter stores the invariant errors in display keys. In Studio, in Project view, navigate to
configuration→config→locale. Assuming you are modifying the display key for English, open
display_en_US.properties and search for the following text string:
[Link].*

For example:
[Link]

contains the display key:

The rate modifier value “{0}” cannot exceed the allowed maximum “{1}”.
During product model verification, PolicyCenter replaces the variables {0} and {1} with the actual values.

Static validation checks

Within a validation class, you can define static methods that define the specific validation checks to perform at a
specific wizard step, reducing the need for full-policy inspections. For example, the Drivers steps on the submission
546 chapter 38: Class‐based validation
 Guidewire PolicyCenter 9.0.9 Configuration Guide

wizard for Personal Auto contains the following validation code (on the beforeSave property of the
[Link]):
[Link]([Link])

This code invokes the validateDriversStep method in PALineStepsValidator before committing the Drivers
wizard step.
static function validateDriversStep(paLine : PersonalAutoLine) {
[Link](\ context -> {
var validator = new PALineValidation(context, paLine)
[Link]()
})
}

Notice the following:

1. Wrapper method doPageLevelValidation provides the exception reporting necessary if a validation check
fails to pass. It is the [Link] method that calls the
raiseExceptionIfProblemsFound method if any of the [Link] validation checks
fail. The raiseExceptionIfProblemsFound(context) method instructs the PolicyCenter rendering
framework to display the appropriate warning or error automatically if there is an exception condition.
2. Validation class PALineDriversValidator provides the validation checks for validatDriversStep. This
validation class defines a number of validation checks, not all of which the validateDriversStep method
invokes.
3. The actual validation takes place in the doValidate override located in the CoveragesValidator class.
For a discussion of how to use this validation method to raise exceptions within PolicyCenter, see “Example:
Invoking validation in a job wizard step” on page 547.

Invoking class‐based validation

PolicyCenter does not automatically invoke class-based validation by virtue of the database commit cycle. Instead,
you must explicitly invoke class-based validation in configuration code. (The PolicyCenter user interface
framework, however, automatically handles the rendering of all errors and warnings raised through exceptions.)
PolicyCenter runs full validation on the policy graph at critical points in the job processes, such as before a quote
and before binding. At any time, however, you can also invoke class-based validation from PCF files, job processes,
wizard steps, workflow steps, integration plugins, and from any Gosu code.
Use the following to invoke class-based validation from a particular PolicyCenter location:

Location Use
Wizard step The beforeSave property for that step
Pop‐up The beforeCommit property for that pop‐up

The PolicyCenter user interface framework automatically handles the rendering of all errors and warnings raised
through exceptions.

Example: Invoking validation in a job wizard step

The following example walks through the process of invoking a static validation method from a job wizard step.
Specifically, it illustrates how to link the various Gosu validation classes and methods to the Vehicles step in the
Personal Auto (PA) Submission wizard.
The following graphic shows the Vehicles step in the PolicyCenter Submission wizard. The page failed a validation
check that occurred as the user clicked Next. (This is because there is no value set for the Length of Lease/Rental
(months) field.)
Class‐based validation 547
Guidewire PolicyCenter 9.0.9 Configuration Guide

Tracing the Validation Path

Starting with SubmissionWizard is a logical first step as the Vehicles page is part the PolicyCenter Submission
wizard. Examining SubmissionWizard PCF file (within Studio) shows that it contains a referenced PCF file named
[Link], which governs the PA Vehicles page in PolicyCenter.

It is the value of the beforeSave property within [Link] that invokes validation on the
Vehicles Details card of the Vehicles page. (You must open the [Link] PCF in its own
View tab before you can access its properties.)

548 chapter 38: Class‐based validation

 Guidewire PolicyCenter 9.0.9 Configuration Guide

The beforeSave value consists of the following expressions:

[Link]([Link])

The validateDriversStep method starts the validation chain for the Personal Auto Vehicles screen. You can use
similar techniques for class-based validation chaining in other screens.

Class‐based validation 549

Guidewire PolicyCenter 9.0.9 Configuration Guide

550 chapter 38: Class‐based validation

chapter 39

Configuring quote purging

Quote purging provides batch processes to purge jobs that did not result in bound policies and prune alternate policy
periods created through multi-version quoting and side-by-side-quoting. Quote purging also removes orphaned
policy periods. Purging and pruning removes these jobs, policy periods, and associated objects from the
PolicyCenter database. Quote purging is not a reversible operation. Quote purging is disabled in the base
configuration.

Quote purging configuration overview

Quote purging is accessed through the Purge and Purge Orphaned Policy Periods batch processes. These batch processes
make use of configuration parameters and a purge plugin.
You can configure quote purging by making modifications to the following:
• Batch processes – Specify how often, if ever, to run the batch processes that remove jobs and policy periods
from the database. For more information, see “Quote purging batch processes” on page 554.
• Configuration parameters – You can use these parameters to specify the number of days that must pass before
purging a job or pruning a policy period. For more information, see “Quote purging configuration parameters” on
page 81.
• Purge plugin – Modify quote purging through Gosu code. By configuring the purge plugin, you can control
which jobs are purged or pruned. You can also choose to retain certain information related to those jobs. For
more information, see the Integration Guide.
In addition, you can access quote purging through:
• Web services – From an external system, set a flag to prevent a job or policy period from being purged or
pruned. For more information, see the Integration Guide.

Quote purging object model

This topic provides information about objects and properties related to quote purging.

Configuring quote purging 551

Guidewire PolicyCenter 9.0.9 Configuration Guide

Quote Purging Object Model

Job
CloseDate
NextPurgeCheckDate
PurgeStatus
SelectedVersion

Submission PolicyChange Policy

DoNotPurge

Legend
*
A B A has a B
PolicyPeriod
A B A has 0 or more Bs
* A is a subtype of B DoNotPurge
A B A delegates to B
A is enhanced by B

In the default configuration, quote purging purges submission and policy change job subtypes.
If the DoNotDestroy flag on Policy is true, then quote purging does not purge the Job associated with this Policy
or prune PolicyPeriod objects.
If the DoNotDestroy flag on PolicyPeriod is true, then quote purging does not prune this PolicyPeriod.
You can manage the DoNotDestroy property in Gosu code and in the PurgeAPI web service. To set the
DoNotDestroy property, you must have the Enable purging for a policy period and Disable purging for a policy period
permissions. The codes for these permissions are purgeenable and purgedisable, respectively.

See also
• Integration Guide

Objects that get purged or pruned

The following illustration shows some of the objects that get purged or pruned.

552 chapter 39: Configuring quote purging

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Objects that Get Purged or Pruned

Legend
A relates to B
A B
B relates to A

A B A has a B
Account
A B A has 0 or more Bs
* A is a subtype of B
A B A delegates to B
A is enhanced by B
* A is purged or
A
Policy pruned
A is EffDated and is
A
purged or pruned

* *
Job * PolicyPeriod Document

Effective Dated Objects

*
Note *
EffectiveDatedFields Form ...

FormTextData

Purging and pruning remove the policy period and all effective dated objects in the policy period branch. Purging
and pruning also remove objects connected to the policy period through a foreign key that would otherwise point to
a removed object. These objects directly related to the policy period include notes, documents, activities, and forms.
Purging and pruning does not remove objects not directly related to the policy period.
Because form text data can be shared between policy periods, quote purging does not remove form text data. As a
result, form text data can be orphaned as a result of quote purging. The Form Text Data Delete batch process
removes orphaned form text data. For more information, see the System Administration Guide.
In addition to removing policy periods, purging also removes the job. If purging removes all jobs associated with a
policy, it also removes the Policy object, for example, when a Policy only exists because of an unbound
submission. Pruning only removes policy periods; pruning does not remove the job.
The following illustration shows objects related to underwriting issues that get purged or pruned.

Configuring quote purging 553

Guidewire PolicyCenter 9.0.9 Configuration Guide

Objects related to Underwriting Issues that Get Purged or Pruned

PolicyTerm Policy Legend

A relates to B
A B
B relates to A

* A B A has a B

PolicyPeriod A B A has 0 or more Bs

* A is a subtype of B
A B A delegates to B
A is enhanced by B

HumanTouchedIssues A A is pruned
*
A is EffDated and
* UWIssue A
is pruned

HumanTouched

*
UWIssueHistory

Purging and pruning also remove objects related to underwriting issues on the policy period. Human-touched
underwriting issues are not purged or pruned. A human-touched UWIssue has the HumanTouched property set to
true.

Quote purging batch processes

Quote purging purges jobs and prunes policy periods, and purges orphaned policy periods. You access quote purging
through batch processes. The quote purging batch processes are:

Name Code Description

Purge Purge Purges jobs and prunes policy periods that meet the purge and prune crite‐
ria. This batch process deletes jobs and other entities from the database. For
more information, see “Purge batch process” on page 555.
Purge Or‐ PurgeOrphanedPolicyPeriod Purges policy periods orphaned as a result of preemption. This batch proc‐
phaned ess deletes policy periods and other entities from the database. For more
Policy Peri‐ information, see “Purge Orphaned Policy Periods batch process” on
ods page 558.
Reset ResetPurgeStatusAndCheckDates Reset the purge status and purge or prune dates on the jobs. Run this batch
Purge Sta‐ process if and when you have a need to reset the purge status and purge
tus and date.
Check For each job, this batch process:
Dates • Sets the [Link] property to Unknown.
• Sets the [Link] to null.
For example, if a job has a PurgeStatus of NoActionRequired or Pruned,
the batch process resets the PurgeStatus to Unknown.

554 chapter 39: Configuring quote purging

 Guidewire PolicyCenter 9.0.9 Configuration Guide

IMPORTANT The Purge and Purge Orphaned Policy Periods batch processes remove jobs and other
entities from the database. These batch processes are not reversible operations. The Reset Purge Status
and Check Dates batch process is also not reversible.

Enable quote purging batch processes

About this task
In the base configuration, Guidewire disables the Purge and Purge Orphaned Policy Periods batch processes. To
enable these batch processes, you must do the following in Studio:

Procedure
1. In [Link], set the following parameters to true to enable running the batch processes from the Server
Tools Batch Process Info screen in PolicyCenter:

Batch process Parameter

Purge PruneAndPurgeJobsEnabled

Purge Orphaned Policy Periods PurgeOrphanedPolicyPeriodsEnabled

2. To enable the batch process to run on a regular schedule, uncomment the following ProcessSchedule entries
in [Link] and modify the schedule to meet your needs:

Batch process Process

Purge Purge

Purge Orphaned Policy Periods PurgeOrphanedPolicyPeriod

Batch processes to run prior to running the purge batch process

A policy period cannot be purged if it is associated with one or more workflows. To more effectively purge and
prune policy periods, clean up workflows before purging or pruning by running the following batch processes:
• Purge Workflow
• Purge Workflow Logs
• Workflow

Purge batch process

The Purge batch process purges jobs and prunes policy periods that meet the purge and prune criteria.
Jobs for which all of the following apply are placed into the Purge work queue:

Condition Configura‐ Configura‐

ble in Purge ble in con‐
plugin? [Link]?
Job subtype is allowed for purging or pruning. •
The batch process calls the following property getters in the PurgePlugin plugin interface:
• AllowedJobSubtypesForPurging
The Job is closed, and the CloseDate is at least PurgeJobsRecentJobCompletionDays or
PruneVersionsRecentJobCompletionDays in the past.

The NextPurgeCheckDate on the job has passed.

The PurgeStatus has a value other than NoActionRequired.

Configuring quote purging 555

Guidewire PolicyCenter 9.0.9 Configuration Guide

See also

• “Enable quote purging batch processes” on page 555

• Integration Guide

Purge worker
The Purge worker picks up a job from the Purge work queue and purges or prunes jobs that meet the criteria. The
following flow chart shows how the purge worker processes the job. Any job that emerges from step 7 will be
considered for purging by the batch process on or after the NextPurgeCheckDate.
Purge worker flowchart

Evaluate job
1 and
update PurgeStatus

2 Can purge job? Yes Purge job

No
5

4 Can prune job? Yes Prune job

No

6 Update PurgeStatus

Legend

Purge worker

Calculate
7 NextPurgeCheckDate Purger

The numbered items in the flow chart are described below.

1. In this step, the job is evaluated according to the following criteria:

Condition Configurable Configurable in

in Purge plu‐ [Link]?
gin?
Is the PurgeStatus not equal to NoActionRequired?
On the policy period that is the SelectedVersion, is the Status not bound, making
the job a candidate for purging?
Does the job have more than one policy period, making the job a candidate for prun‐
ing?

Then the worker updates the PurgeStatus.

2. This decision point evaluates whether the job and all of its policy periods can be purged. A job can be purged
if all of the following apply:
556 chapter 39: Configuring quote purging
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Condition Configu‐ Configura‐

rable in ble in con‐
Purge [Link]?
plugin?
The policy is not bound.

The job subtype is a subtype for purging. •

Calls the AllowedJobSubtypesForPurging getter in the PurgePlugin plugin interface.
The DoNotDestroy flag is set to false on the policy and all policy periods on the job.

The purge date returned by the getPurgeJobDate method is less than or equal to the current • •
date.
The purge date is calculated by comparing the job close and policy end dates with configuration
parameters. For more information, see “Quote purging configuration parameters” on page 81.
Calls the getPurgeJobDate method in the PurgePlugin plugin interface.
The job has no open activities.
The job has no archived policy periods.
There are no workflows on any policy period in the job.
For information about a process that purges workflows, see the System Administration Guide.

3. In this step, the purger purges the job in two separate bundles:
a. The first bundle calls the createContext and prepareForPurge methods in the PurgePlugin plugin
interface.
For each policy period in the job, the purger calls the skipPolicyPeriodForPurge method in the
PurgePlugin plugin interface. This bundle then purges the job and the related objects.
b. The second bundle calls the postPurge method in the PurgePlugin plugin interface.

IMPORTANT Guidewire recommends that you put business critical operations in the
prepareForPurge method so that the first bundle does the purge and business critical
operations. Do not put business critical operations in the second bundle. If by chance the
system fails while the purger is processing the job, the second bundle may not occur. If the
first bundle does not complete, the bundle transaction consisting of the prepareForPurge
and the purge-from-database action is rolled back. The job will be again be a candidate for
purging or pruning the next time the batch process picks it up.

4. This decision point evaluates whether the policy periods on a job can be pruned. The policy periods on a job
can be pruned if all of the following apply:

Condition Configura‐ Configura‐

ble in ble in con‐
Purge plu‐ [Link]?
gin?

The job subtype is a subtype for pruning. •

Calls the AllowedJobSubtypesForPruning getter in the PurgePlugin plugin interface.

The prune date returned by the getPruneJobDate method is less than or equal to the current • •
date.
The prune date is calculated by comparing the job close and policy end dates with configura‐
tion parameters. For more information, see “Quote purging configuration parameters” on
page 81.
Calls the getPruneJobDate method in the PurgePlugin plugin interface.
The job has no open activities.
The job has no archived policy periods.

Configuring quote purging 557

Guidewire PolicyCenter 9.0.9 Configuration Guide

If the previous conditions are met, then each individual policy period is evaluated for pruning. The policy
period is sent to the purger if the following apply:

Condition Configurable in Purge plu‐ Configurable in [Link]?

gin?
The policy period is not bound.
The DoNotDestroy flag is set to false on the policy period.
There are no workflows on the policy period.

5. In this step, the purger prunes policy periods on the job in two separate bundles:
a. The first bundle calls the prepareForPurge method in the PurgePlugin plugin interface.
For each policy period in the job except the selected version, the purger calls the
skipPolicyPeriodForPurge in the PurgePlugin plugin interface. This bundle then purges the policy
periods and the related objects.
b. The second bundle calls the postPurge method in the PurgePlugin plugin interface.

IMPORTANT Guidewire recommends that you put business critical operations in the
prepareForPurge method so that the first bundle does the purge and business critical
operations. Do not put business critical operations in the second bundle. If by chance the
system fails while the purger is processing the job, the second bundle may not occur. If the
first bundle does not complete, the bundle transaction consisting of the prepareForPurge
and the purge-from-database action is rolled back. The job will be again be a candidate for
purging or pruning the next time the batch process picks it up.

6. This step updates the PurgeStatus to one of the following values:

• NoActionRequired – This is the most common case. For example, PurgeStatus gets this value when the
only remaining period is bound.
• Pruned – When there is one and only one policy period version remaining.
• Unknown – If the purge status is unknown. For example if a version that is not the selected version is marked
DoNotDestroy, then pruning leaves that version as well as the selected version.
7. This step calculates the next purge check date. This step calls the calculateNextPurgeCheckDate method in
the PurgePlugin plugin interface.
When the batch process runs again, this job will be reevaluated for purging or pruning.

Purge Orphaned Policy Periods batch process

The Purge Orphaned Policy Periods batch process finds orphaned policy periods, which are policy periods not
associated with a job. Preempted jobs create orphaned policy periods.
For each orphaned policy period, this batch process calls the following method in the PurgePlugin plugin interface:
• skipOrphanedPolicyPeriodForPurge method that signals not to purge an orphaned policy period.
Note: If you wish to never purge orphaned policy periods, Guidewire recommends that you not enable
the Purge Orphaned Policy Periods batch process. Customizing this method is not an effective way to
never purge orphaned policy periods.

See also
• To enable this batch process, see “Enable quote purging batch processes” on page 555

558 chapter 39: Configuring quote purging

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Using events to notify external system of purged of pruned

entities
PolicyCenter generates an event when quote purging or pruning removes a PolicyPeriod, Job, or Policy entity
instance. You can use messaging to send this event to external systems that track PolicyCenter entities or data. The
events that PolicyCenter generates for quote purging are:
• JobPurged
• PolicyPurged
• PolicyPeriodPurged

See also
• Integration Guide

Purging test tool

The Purging Test tool is provided to help you see the effect of purging or pruning on one job. Use this tool during
development to see the effect of the Purge batch process on a selected job. This tool also has a link to run the Purge
batch process.
To access this tool, press ALT+SHIFT+T and select Internal Tools→Purging Test.

Flushing other work queues with the purging test tool

A policy period cannot be purged if it is associated with one or more workflows. To more effectively purge and
prune policy periods, clean up workflows before purging or pruning.
• In Flush other work queues (Purge workflows, etc.), click Run.
This command cleans up workflows by running the following batch processes:
◦ Purge Workflow
◦ Purge Workflow Logs
◦ Workflow

Purge or prune a job with the purging test tool

About this task
Follow these step-by-step instructions to purge or prune a particular job with the Purging Test tool.

Procedure
1. Enter the policy transaction number of the job you wish to purge.
2. Click Find/Refresh Job to fetch the job from the database.

Field Description
Job Number The number of the job to purge or prune.
Subtype The job subtype.
Close Date The job close date.
DoNotDestroy flag (Policy) The value of the DoNotDestroy flag on Policy.

Policy Period(s) The number of policy periods associated with this job. The Prune -- Purge Policy Period(s) section
displays more information about each policy period.

Configuring quote purging 559

Guidewire PolicyCenter 9.0.9 Configuration Guide

Field Description
Coverage End The coverage end date of the policy.

PolicyCenter displays a Purge or Prune Job section. This section displays the following information about the
job:
You can select to purge or prune the selected job.
3. To purge or prune the job without checking to see if the job is eligible for purging or pruning, select Skip
configurable Purging checks or Skip configurable Pruning checks.
If you did not choose to skip checks, then the job is purged or pruned based on the current configuration,
including the PurgePlugin implementation.
If you choose to skip checks, then the job is purged or pruned regardless of the Subtype, Close Date, or Coverage
End.
If you choose to skip checks, a job can be purged or pruned only if the following are true:
• The job’s CloseDate is not null.
• The DoNotDestroy flag is not set on the policy associated with the job.
• The job has no open activities.
• The job is not archived.
Additionally, if you choose to skip checks, the following criteria also apply. For purging, each policy period
on the job must meet this criteria. For pruning, the policy period being pruned must meet this criteria.
• The PolicyPeriod is not bound.
• The DoNotDestroy flag on the PolicyPeriod is not set.
• The PolicyPeriod has no workflows.
4. Click Purge Job or Prune Job to purge or prune the selected job.
PolicyCenter does not run the Purge batch process but performs equivalent actions to purge or prune the
selected job. The purge or prune accesses the configuration parameters and runs the PurgePlugin
implementation.

Prune policy periods with the purging test tool

About this task
After selecting a job with the Purging Test tool, the policy periods attached to the selected job appear in the Prune --
Purge Policy Period(s) section. This section displays the following information about each policy period:

Field Description
Policy Period The version number of the policy period, and whether it is the selected policy period.
Period Start The policy period start date.
Period End The policy period end date.
Period Status The policy period status.
DoNoDestroy (period) The value of the DoNotDestroy flag.

Flip DoNotDestroy bit A button to toggle the DoNotDestroy flag on this policy period.

Procedure
1. To prune policy periods without checking to see if the policy period is eligible for pruning, select Skip checks
for purging policy period.
If you choose to skip checks, then the policy period is pruned regardless of the Subtype, Close Date, or Coverage
End.
560 chapter 39: Configuring quote purging
 Guidewire PolicyCenter 9.0.9 Configuration Guide

If you did not choose to skip checks, then the policy period is pruned based on the current configuration,
including the PurgePlugin implementation.
2. Click Purge in the row of the policy period you wish to prune.
The Purge button is enabled for unselected policy period versions.
PolicyCenter does not run the Purge batch process, but performs equivalent actions to prune the selected
policy period. The purge or prune accesses the configuration parameters, and runs the PurgePlugin
implementation.

Run the Purge batch process from the purging test tool
About this task
You can run the Purge batch process from the Purging Test tool.

Procedure
In Run Purge Batch Process, click Run.
This is the same as running the batch process from the Server Tools→Batch Process Info screen. The batch process
purges jobs and prunes policy periods in the PolicyCenter database.

Configuring quote purging 561

Guidewire PolicyCenter 9.0.9 Configuration Guide

562 chapter 39: Configuring quote purging

chapter 40

Configuring quote cloning for business

intelligence

Some insurance companies have a need to capture information from quotes that users and other processes generate
through the course of the day. Quote cloning provides one approach for retaining some of this information long
enough to capture it for business intelligence (BI) needs.
Through configuration, you define the processing of the cloned quotes. When you have gathered the data from the
clones and no longer need them, you can run Purge Quote Clones batch processing to purge the cloned quotes.

See also

• Application Guide

Quote cloning configuration overview

Quote cloning provides a framework for creating cloned copies of policy period quotes. Clones can include quotes
that never result in a bound policy. Cloned quotes can be generated from submission, policy change, reinstatement,
renewal, and rewrite policy transactions.
This framework is disabled in the base configuration.
In your implementation, you define these characteristics:
• Which quotes to clone. You define this in your implementation of the Quote Clone plugin interface.
• How to process the quote clones. You define the processing of the clones in your implementation of the Quote
Clone plugin interface. Alternately, you can choose not to use the Quote Clone plugin interface and implement
your own integration or plugin to process the clones.
• How often to purge processed clones. According to a schedule you define, Purge Quote Clones batch processing
purges cloned quotes.
• Which processed clones to purge. You can add criteria to the query that Purge Quote Clones batch processing
uses for selecting purge candidates.
Quote cloning does not have an end-user interface. It provides a framework that automated processes can use to
generate BI data. Quote cloning is not intended to provide additional end-user functionality. The captured data does
not appear in the PolicyCenter user interface.

Configuring quote cloning for business intelligence 563

Guidewire PolicyCenter 9.0.9 Configuration Guide

IMPORTANT Before enabling quote cloning, evaluate the impact on system performance, including
the impact to memory and database.

Quote cloning object model

The PolicyPeriod object has two properties for quote cloning:
• TemporaryClone – If true, this policy period is a temporary clone. A clone does not appear in the PolicyCenter
user interface. This is a virtual property that PolicyCenter derives.
• TemporaryCloneStatus – The status of the cloned policy period. If Unprocessed, the policy period has not been
processed. If Purgeable, the cloned policy period is no longer needed and can be purged.

Enable quote cloning

About this task
In the base configuration, quote cloning is disabled. To enable quote cloning, you must do the following in Studio:

Procedure
1. Create an implementation of the PolicyPeriodQuoteClonePlugin plugin interface that implements your
functionality. See “Quote clone plugin” on page 564.
2. In the plugins registry for PolicyPeriodQuoteClonePlugin, enable the plugin and specify your
implementation as the Gosu class. See “Working with plugins” on page 134.
3. Enable Purge Quote Clones batch processing in [Link] by uncommenting the
ProcessSchedule entry for PurgeQuoteClones.
4. Modify the schedule of Purge Quote Clones batch processing to meet your needs.

Quote clone plugin

The Quote Clone plugin provide methods for you to define and customize how PolicyCenter creates and processes
cloned quotes. The plugin also provides a method for adding criteria to the query that selects cloned quotes for
purging.
In the base configuration, the DefaultPolicyPeriodQuoteClonePlugin Gosu class is an example implementation
of the PolicyPeriodQuoteClonePlugin plugin interface.
If the plugin is enabled, PolicyCenter calls the following methods in the order listed whenever it creates a policy
period that can be cloned:

Method See...
shouldCloneQuote “Determining whether to clone a quote” on page 565
cleanupAfterCloningPolicyPeriod “Cleaning up after cloning policy period” on page 565

processClonedPolicyPeriod “Processing the cloned policy period” on page 565

The plugin has one method for modifying Purge Quote Clones batch processing:

Method See...
addToPurgeClonedPeriodsQuery “Adding to the Purge Quote Clones query” on page 565

564 chapter 40: Configuring quote cloning for business intelligence

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Determining whether to clone a quote

PolicyCenter calls the shouldCloneQuote Boolean method after a policy period has finished quoting in a policy
transaction.
In the shouldCloneQuote method, include code that returns true to flag the policy period for cloning. For example,
the following implementation flags all submissions for cloning:
override function shouldCloneQuote (period: PolicyPeriod): boolean {
return [Link] == TC_SUBMISSION
}

When this method returns true, PolicyCenter creates a cloned policy period and sets its TemporaryClone property
to TC_UNPROCESSED.

Cleaning up after cloning policy period

After creating the cloned policy period, PolicyCenter calls the cleanupAfterCloningPolicyPeriod method.

IMPORTANT If this method is not properly implemented for your data model, loss of data or
functionality may occur.

The intent of this method is to fix up any problems caused by cloning. For example, the clone and the originating
policy period may have foreign keys pointing to the same object. If PolicyCenter attempts to delete the originating
policy period, PolicyCenter generates an error when it encounters the common object because the cloned policy
period still points to it. To avoid this, you can do a deep copy of the common object and point the foreign key on the
cloned policy period to the copy of the common object. If the common object has other relationships, you must
duplicate those relationships in copy of the common object and the clone. For example, if the common object has a
foreign key pointing back to the originating policy period, you must duplicate that relationship.
In the base configuration, if you have enabled and implemented a multicurrency system, this problem occurs with
PolicyFXRate objects. After cloning, the original policy period’s PolicyFXRate objects are also linked to from the
clone. In the example plugin implementation, the cleanupAfterCloningPolicyPeriod method provides code that
fixes the links to the PolicyFXRate object. The method does a deep copy of the FXRate and links the cloned policy
period to the PolicyFXRate copy.

Processing the cloned policy period

After cleaning up the cloned policy period, PolicyCenter calls the processClonedPolicyPeriod method. In this
method, add code that processes the cloned policy period. Alternately, you can leave the
processClonedPolicyPeriod method empty and create your own integration or plugin that processes the data and
extracts it to an external BI system.
In either case, after processing, mark the cloned policy period as purgeable by setting the TemporaryCloneStatus
property to Purgeable:
[Link](PolicyPeriodCloneStatus.TC_PURGEABLE)

Adding to the Purge Quote Clones query

Purge Quote Clones batch processing calls this method.
In the addToPurgeClonedPeriodsQuery method, you can add criteria to the query that Purge Quote Clones batch
processing uses to select cloned quotes for purging. For example, you can specify that purgeable policy periods must
be at least 2 hours old.
After returning from this method, the process uses the query to create the list of items to be purged.

Configuring quote cloning for business intelligence 565

Guidewire PolicyCenter 9.0.9 Configuration Guide

Purge quote clones batch processing

Quote cloning creates copies of policy period quotes, known as quote clones. The Purge Quote Clones work queue
deletes quote clones that are marked as processed from the PolicyCenter database.
By default, Guidewire disables the entry for this work queue in [Link] in the base configuration.
To schedule this work queue, remove the comment marks from around its entry in [Link].
To find candidate cloned quotes for purging, Purge Quote Clones batch processing uses a query to select policy
periods where the following are true:
• TemporaryClone property is true
• TemporaryCloneStatus property is Purgeable
You can modify the query that Purge Quote Clones batch processing uses to select candidates for purging. Modify
the query in the addToPurgeClonePeriodsQuery method of the PolicyPeriodQuoteClonePlugin plugin.

See also
• “Adding to the Purge Quote Clones query” on page 565
• System Administration Guide

566 chapter 40: Configuring quote cloning for business intelligence

chapter 41

Configuring contingencies

PolicyCenter manages work associated with a creating or changing a policy through policy transactions. A policy
transaction is completed when the policy is bound and issued, or when the policy transaction is withdrawn.
However, the policy may still require additional work. You can use contingencies to manage this additional work
and take actions, including policy change or cancellation transactions, if conditions are not met in a timely manner.

See also
• Application Guide

Contingency configuration overview

Through configuration, you can change the default behavior of contingencies. You can change the object model and
the code that creates contingencies and associated documents, notes, and activities. You can modify the batch
process that starts actions on contingencies.
Through configuration, you can add contingency actions that start job types other than policy change and
cancellation. You can add short rate calculation and custom calculation methods in addition to flat and prorated.

Contingency object model

The following illustration shows Contingency and related objects.

Configuring contingencies 567

Guidewire PolicyCenter 9.0.9 Configuration Guide

Contingency Objects

Legend Policy
A B A has a B

A B A has 0 or more Bs *
* PolicyPeriod

*
Job Contingency
ContingencyInitiator
*

Owner SpawnedJobs

* * * *
ContingencyJob Activity Document Note

Contingency
Each Contingency has a number of properties, including:

Property Description
Title Brief description enabling a user to quickly understand the type of contingency.
Description Longer description which can include specific details of this instance. Can include, for example, the condi‐
tions under which the contingency can be resolved.
Status Type key indicating if this contingency is, for example, still active, has been successfully resolved, or failed
to be resolved in a timely manner.
Action What action to start if the contingency is not resolved prior to the action start date. The action can start a
policy transaction.
ActionStartDate When to initiate action if the contingency is not resolved.

DueDate The due date for the contingency. If the contingency is not closed by this date, batch processing changes
the status to failed, and closes the contingency.
CloseDate When the contingency was closed.
CloseUser The user who closed the contingency.
Policy The policy associated with the contingency.
PolicyPeriod Generally the policy period that caused the contingency to be associated with the policy. If the contingen‐
cy was attached directly to the policy, policy period is null.

Contingency Job
If a contingency is not resolved in a timely manner, Unresolved Contingency batch processing initiates action on the
contingency. ContingencyJob is the job initiated by the action.

568 chapter 41: Configuring contingencies

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Contingency Gosu class

The main configuration class for contingencies is [Link]. This file contains methods that
set the action start date, define how notes and activities are added to a contingency, define how contingencies are
resolved and waived.

Action Start Date

You can specify action start dates in the updateActionStartDate method. In the base configuration, the values are:

Policy transaction Action start date

Policy change 5 day before the due date
Cancellation 30 days before the due date

Notes and Activities

Code that adds notes and activities to a contingency is in the createContingencyActivity and
createContingencyNote methods. For activities, you can customize the owner, title, and description, among others.
For notes, you can customize the subject and author, among others.
In the base configuration, notes and activities are related to the contingency through foreign keys. Through
configuration, notes and activities can be related to other objects.

Contingency batch processing

The batch processes associated with contingencies are:
• Handle Unresolved Contingency – Initiates action on pending contingencies. See the System Administration
Guide.
• Recalculate Contingency Action Start Date – Recalculates the action start date on all unresolved
contingencies. See the System Administration Guide.

Configuring contingencies 569

Guidewire PolicyCenter 9.0.9 Configuration Guide

570 chapter 41: Configuring contingencies

chapter 42

Configuring the Spotlight integration

The Spotlight integration in PolicyCenter provides access to interactive and risk assessment services available in
Guidewire Spotlight. Spotlight provides a map in PolicyCenter. If you update the address, PolicyCenter refreshes the
map. Spotlight provides risk information associated with a location.
In the base configuration, Spotlight is integrated with the commercial property line of business, and is accessible
from locations. You can add Spotlight interactive and risk assessment services to other lines of business.
The risk assessment service provides data for the selected risk profile, configured specifically for the customer.
Note: For information about obtaining access to Spotlight, contact your Guidewire support
representative.

Spotlight integration overview

In PolicyCenter you can interactively access risk assessment in Spotlight from a particular location. You can
interactively make changes and evaluate in Spotlight, then return the new data to PolicyCenter.
The risk assessment service provides Spotlight access in PolicyCenter when you updates risk evaluations. The
integration contacts Spotlight risk assessment service to update risk data for all locations on the policy period. This
access with Spotlight risk assessment service occurs non-interactively.
In the integration, Spotlight risk assessment data is delivered in a JSON payload, which contains all details of the
risk assessment. The payload is machine readable and can often be understood directly by users.
Spotlight returns data for all assessments in the risk profile. The Policy Location screen displays this data in a table
regardless of which specific assessments are configured for parsing.
The integration provides an example of how to parse out specific assessment results from the data returned from
Spotlight. The base implementation parses out flood data and some other fields from the JSON data. This risk
assessment data is added to specific objects. You can configure PolicyCenter to capture fields from the JSON
payload for your custom risk data in Spotlight. Data that has been extracted from the JSON payload and stored on
appropriate business objects can be used in rating or trigger underwriting issues.
Flood risk is not automatically returned when Spotlight is enabled. To get the flood risk data, you must include flood
in your Spotlight profile configuration. To work with the example configuration, Spotlight and the integration must
use the same assessment code.

Spotlight Integration Requires HTTPS

Communication with Guidewire Spotlight must be secured by serving PolicyCenter over HTTPS. Failure to do so
may result in various browser warnings as well as potentially transmitting sensitive information over insecure
channels. Therefore, implement HTTPS and disable HTTP on PolicyCenter servers.
Configuring the Spotlight integration 571
Guidewire PolicyCenter 9.0.9 Configuration Guide

For Spotlight services, in particular the interactive integration, to function properly and securely, the PolicyCenter
application server must be run using HTTPS with a valid certificate.

Accessing risk assessment interactively

When accessing Spotlight interactive service, you can go to the Spotlight application from PolicyCenter by clicking
View in Spotlight on the Location Information screen. In Spotlight, you can examine the location and its surroundings,
and perform risk evaluations. You can also move the location pin for longitude and latitude. Spotlight risk
assessment service provides risk data. Then you can return to PolicyCenter.
The following illustration shows the Spotlight interactive and risk assessment flow in PolicyCenter.

Spotlight Interactive and Risk Assessment Flow

PolicyCenter Spotlight

1
Location public ID through URL
6
16 User can move
location
PolicyCenter UI Spotlight UI
2
Location public ID through HTTPS

7
SpotlightServlet InboundPolicyRequestData
15

3
8

Location 4 LocationDetailsRequestHandler
5
Details JSON OutboundPolicyData

9
17 SpotlightReturnToPCRequestHandler

10

PolicyLocationRiskAssessmentGateway

11

12
JSON OutboundPolicyData
Spotlight risk
PolicyLocationRiskAssessmentPlugin 13 assessment
JSON InboundRiskAssessmentData service

14

Risk Assessment
Results

For interactive risk assessment flow, the following steps correspond to the numbers in the previous illustration.
1. PolicyCenter When the user clicks Evaluate in Spotlight, PolicyCenter sets a variable indicating that this button
was clicked. Then PolicyCenter stores the current policy location data into the
OutboundLocationRiskAssessmentTempStore, OutboundPeriodRiskAssessmentTempStore, and
OutboundReinsurableRiskAssessmentTempStore temporary objects. PolicyCenter uses these objects to
match the data that the risk assessment service returns.
For new locations that do not have latitude and longitude, PolicyCenter sends a formatted address. The
AddressFormatter class formats the address into a globalized address. In your customization, pass the fields
you require into the formatter. In the base configuration, the fields are stored in a static function called
GeoCodableAddressFields in [Link].

572 chapter 42: Configuring the Spotlight integration

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Policy Center passes three parameters to Spotlight through the URL. These parameters are used in requests to
transfer JSON data from Spotlight to PolicyCenter.
• policySystemServer – Base URL which prepends the other two page parameters
• encodedLocationDetailRequestPage – Page for requesting location details from PolicyCenter including
location public ID
• encodedReturnPage – Page for returning from Spotlight to PolicyCenter to display the risk assessment
calculated by Spotlight
The URL is in the following format:
[Link]
paramsUrlFragment/encodedLocationDetailRequestPage/returnUrlFragment/encodedReturnPage

2. Spotlight After PolicyCenter sends the public ID of the LocationForRiskAssessment object to Spotlight,
Spotlight sends a request to PolicyCenter to retrieve the details of that location. The request is made through
the URL:
policySystemServer/encodedLocationDetailRequestPage

In PolicyCenter the request goes to [Link].

3. PolicyCenter The SpotlightServlet delegates to [Link].
4. The LocationDetailsRequestHandler gets the location details.
5. The LocationDetailsRequestHandler responds to the request by sending JSON data from
[Link]. Jackson is used to serialize and deserialize the JSON data. This class implements
the JacksonEnabledSerializable interface so that Jackson works with Gosu.
6. Spotlight At this point, the user can modify the location pin or risk profile in Spotlight, then click PolicyCenter
to return to PolicyCenter. The Spotlight service uses the supplied latitude and longitude if present to identify
the location, in preference to the address information.
7. PolicyCenter When the user initiates the return to PolicyCenter, a request is sent to the URL:
policySystemServer/encodedReturnPage

The request arrives at [Link].

The request includes the location data as JSON data in a request parameter which is parsed with Jackson and
stored in [Link].
8. The SpotlightServlet passes control to SpotlightReturnToPCRequestHandler.
9. SpotlightReturnToPCRequestHandler matches the JSON data with temporary objects in database.
10. The request handler calls PolicyLocationRiskAssessmentGateway with the matched temporary objects. The
gateway ensures that the plugin methods are called correctly, checks permissions, and handles errors.
11. The gateway calls the PolicyLocationRiskAssessmentPlugin.
12. Spotlight PolicyLocationRiskAssessmentPlugin calls the Spotlight risk assessment service. The data is
sent by OutboundPolicyData.
13. The risk assessment data is returned with InboundRiskAssessmentData.
14. PolicyCenter The data is persisted in InboundLocationRiskAssessmentTempStore. The handler returns
control to SpolightServlet.
15. Spotlight The servlet returns control to Spotlight.
16. PolicyCenter Spotlight directs the URL back to PolicyCenter.
17. In PolicyCenter, the Location Information screen displays the risk assessment data below the map. The risk
assessment data includes Latitude, Longitude, and other fields.
When the user returns to PolicyCenter, the page reloads the OutboundLocationRiskAssessmentTempStore object
which contains the risk assessment data in InboundLocationRiskAssessmentTempStore.
PolicyCenter reloads the thumbnail map to display the latitude and longitude picked in Spotlight if moved. When
there is new risk assessment data, PolicyCenter displays a message below the thumbnail map saying Spotlight returned
new data. You can choose whether or not to Use this new data. The data in
Configuring the Spotlight integration 573
Guidewire PolicyCenter 9.0.9 Configuration Guide

InboundLocationRiskAssessmentTempStore object is added into the LocationRiskAssessment object if you

choose to use the new data and click Ok. If you click Cancel, the risk assessment data is not stored into the policy
graph. You can view the location in Spotlight multiple times and move the location pin each time resulting in
different risk assessment values. Only the last risk assessment value is preserved into the policy graph when you
select Ok.
You also see the risk assessment details after visiting Spotlight and clicking Evaluate. Next to the label Risk Profile: US
Large Commercial, click Show to view risk assessments and details.
When the new risk assessment is accepted, a LocationRiskAssessment object is created and populated with risk
assessment, including the hash of the data used to generate this risk assessment.

Accessing risk assessment non‐interactively

You can access risk assessment non-interactively by clicking Update Risk Evaluations on the Risk Analysis screen.
PolicyCenter runs risk assessment for all locations on the policy period.
When accessing risk assessment non-interactively, PolicyCenter calls the Spotlight risk assessment service, saves the
results, and creates an activity indicating whether the risk assessment succeeded or failed. This occurs without
providing the user access to Spotlight interactive services.
The following illustration shows the flow when accessing Spotlight non-interactively from PolicyCenter.
Spotlight Risk Assessment Flow

PolicyCenter Spotlight

PolicyCenter UI

PolicyLocationRiskAssessmentRequestor

PolicyLocationsRiskAssessmentWorkQueue

PolicyLocationRiskAssessmentGateway

5
JSON OutboundPolicyData
Spotlight Risk
PolicyLocationRiskAssessmentPlugin 6 assessment
JSON InboundRiskAssessmentData service

7 8

Risk Assessment
SpotlightNotificationActivityCreator
Results
9

Activity indicating
success or failure

For non-interactive risk assessment flow, the following steps correspond to the numbers in the previous illustration.
1. The user selects Update Risk Evaluations and PolicyCenter calls the
PolicyLocationRiskAssessmentRequestor class.
574 chapter 42: Configuring the Spotlight integration
 Guidewire PolicyCenter 9.0.9 Configuration Guide

This class requests risk assessments for all the locations on a policy period, by calling the
enqueueForLocationsRiskAssessment method. This method creates a RiskEvaluationWorkItem which
refers to the PolicyPeriod. It also sets the RequestingUser field to the current user. The workItem is created
and committed in the PolicyPeriod bundle.
The class also provides the static query isLocationsRiskAssessmentInProgress method to determine
whether there is already an active RiskEvaluationWorkItem for this policy period.
2. Policy Locations Risk Assessment batch processing writes items to the Policy Locations Risk Assessment
work queue. This work queue starts risk assessment for all locations on the policy.
This work queue does not have a finder. Therefore, batch requests are created explicitly by the
PolicyLocationsRiskAssessmentRequestor class.
3. The work queue calls PolicyLocationRiskAssessmentGateway class. The gateway ensures that the plugin
methods are called correctly, checks permissions, and handles errors.
4. The gateway class calls the PolicyLocationRiskAssessmentPlugin plugin.
5. The plugin calls the Spotlight risk assessment service. The data is sent by OutboundPolicyData.
6. The risk assessment data is returned with InboundRiskAssessmentData.
7. The data is persisted in InboundLocationRiskAssessmentTempStore objects.
8. For each location, the SpotlightNotificationActivityCreator class creates an activity indicating whether
risk assessment succeeded or failed.
9. Users can view the activities in PolicyCenter.

Risk assessment object model

The following illustration shows some of the objects and properties associated with risk assessment.
Risk Assessment Objects

PolicyPeriod OutboundPeriodRiskAssessmentTempStore InboundPeriodRiskAssessmentErrorTempStore

*

* * InboundLocationRiskAssessmentTempStore
PolicyLocation OutboundLocationRiskAssessmentTempStore
FloodRisk
SpatialPoint FloodScore
SpatialPoint
*
LocationRiskAssessment
InboundLocationRiskAssessmentErrorTempStore
FloodRisk
FloodScore *

OutboundReinsurableRiskAssessmentTempStore Legend

CoverageGroup A relates to B
A B
B relates to A
TotalInsuredValue
A B A has 0 or more Bs
*

The PolicyLocation provides access to risk assessment data for a policy location through an array of
LocationRiskAssessment objects. The PolicyLocation also has a one-to-one relationship with risk assessment
data to be sent to Spotlight in the OutboundLocationRiskAssessmentTempStore object.

Configuring the Spotlight integration 575

Guidewire PolicyCenter 9.0.9 Configuration Guide

Location risk assessment object

The LocationRiskAssessment object provides risk assessment data for a policy location.
LocationRiskAssessment is an effective dated object.

Property Description
AssessmentDate Time that the assessment was given to PolicyCenter.

BasedOnValue Pointer to the LocationRiskAssessment object on which this object is based.

Fixed Pointer to this object across all branches and policy periods.
FloodRisk The flood risk set to Unknown, Low, Medium, or High. This provides an example of parsed data from Spot‐
light.
FloodScore A score for the flood risk. This provides an example of risk score from Spotlight.
SpatialPoint Latitude and longitude of the risk evaluation.

Risk assessment temporary objects

Inbound objects store information that the Risk Assessment Service provides to PolicyCenter. Outbound objects
store information that PolicyCenter sends to the Risk Assessment Service.
• OutboundPeriodRiskAssessmentTempStore
• OutboundLocationRiskAssessmentTempStore
• OutboundReinsurableRiskAssessmentTempStore
• InboundLocationRiskAssessmentTempStore
• InboundLocationRiskAssessmentErrorTempStore
• InboundPeriodRiskAssessmentErrorTempStore

Inbound location risk assessment temporary store object

The InboundLocationRiskAssessmentTempStore object stores information that the Risk Assessment Service
provides to PolicyCenter. This object contains the latitude and longitude of the location and specific assessments
configured to be parsed, such as flood data which is provided as an example.

Property Description
AssessmentDate Time that the assessment was given to PolicyCenter.
FloodRisk The flood risk set to Unknown, Low, Medium, or High. This provides an example of
parsed data from Spotlight.
FloodScore A score for the flood risk. This provides an example of risk score from Spotlight.
RiskProfileCode The code in the risk assessment service indicating how the location risk was assessed.
SnapshotReportURL Reference to report of how risk assessment took place.
SpatialPoint Latitude and longitude of this location.
UnparsedRiskAssessmentResponse The raw text from the risk assessment.

Inbound location risk assessment error temporary store object

The InboundLocationRiskAssessmentErrorTempStore object holds an error associated with a location for a failed
request to the risk assessment service.

576 chapter 42: Configuring the Spotlight integration

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Inbound period risk assessment error temporary store

The InboundPeriodRiskAssessmentErrorTempStore object holds an error associated with a failed request to the
risk assessment service.

Outbound location risk assessment temporary store object

The OutboundLocationRiskAssessmentTempStore object store location information that PolicyCenter sends to
Risk Assessment Service. This object contains the address and latitude and longitude of the location.

Property Description
AddressLine1 The first line of the location address. This object also includes address properties, including City, County,
State, and Country.

SpatialPoint Latitude and longitude of this location.

Outbound period risk assessment temporary store

The OutboundPeriodRiskAssessmentTempStore object represents the risk assessment request which contains one
or more locations for risk assessment. This object stores request level errors.

Outbound reinsurable risk assessment temporary store object

The OutboundReinsurableRiskAssessmentTempStore object store reinsurance information for the associated
OutboundLocationRiskAssessmentTempStore object. PolicyCenter sends this information to the Risk Assessment
Service.

Property Description
CoverageGroup Coverage group type for reinsurance.
TotalInsuredValue The total insured value of the risk.

Configuring risk assessment in the Location Information

Screen
The Location Information screen displays risk assessment information and a thumbnail map.

Risk assessment information

In Commercial Property, the Location Information screen displays risk assessment information. When the user enters
this screen, [Link], the screen checks whether the current location data differs from what was used
to generate the existing LocationRiskAssessment, if one exists. If there is a difference, the screen displays a
warning indicating that the current risk assessment may be out-of-date, or stale. This warning also appears on the
Buildings and Locations screen for any location with a stale risk assessment. The
[Link] property indicates whether the risk assessment is stale or not.
To perform this check for stale risk assessments, a non-persisted OutboundLocationRiskAssessmentTempStore is
created and populated with the current location data. The spatial point and hash value of this object are calculated
and compared with the spatial point and hash value of the latest LocationRiskAssessment. The hash value is
available in the [Link] property.
The hash value is determined by a list of properties on the OutboundLocationRiskAssessmentTempStore. The list
of properties is specified in the RiskAssessmentInputDataHasher property in the
RiskAssessmentInputDataHasher class. The Location Risk Assessment plugin calls
RiskAssessmentInputDataHasher.
Configuring the Spotlight integration 577
Guidewire PolicyCenter 9.0.9 Configuration Guide

The hash value is calculated using the following list of properties:

• [Link]
• [Link]
• GeocodeableAddress
• City
• County
• PostalCode
• State
• Country
You can configure the list of fields in the hash to meet your needs.
Note: Do not include the SpatialPoint among the fields used for hashing. The spatial point on the
OutboundLocationRiskAssessmentTempStore does not reflect changes in spatial point that occur
while the user is in Spotlight.

Risk assessment thumbnail map

The Location Information screen in PolicyCenter displays a thumbnail map embedded in the [Link].
The map is provided by Spotlight and has a pin dropped on the current best-known location. If the location has
latitude and longitude, then the pin is placed on that location. Otherwise, the address fields are used to place the pin.
You can update the map to reflect changes to coordinates or address by clicking Update Map. As previously
mentioned, address-only changes do not affect the map if the location already has coordinates.
The embedded map uses the template panel to link to the Spotlight client and enables PolicyCenter to display the
embedded map. The createSpotlightMapURL method in [Link] creates the URL.
Note: The thumbnail map content returned by Spotlight is licensed and subject to change. You can
render the content but do not parse it.

Deleting temporary risk assessment objects

The risk assessment integration creates temporary objects for each policy location when accessing Spotlight
interactive and risk assessment services. PolicyCenter deletes these objects from the database in the following ways:
• Bound policy – During binding, right before it is bound, PolicyCenter deletes temporary objects that are
associated with the policy locations. This is done in [Link] in the
cleanUpLocationForRiskAssessment method.
• Unbound Policy – For policies that are withdrawn, not taken, or declined, PolicyCenter deletes the temporary
objects. The code that deletes the objects is not accessible.
• Bound policies and Spotlight interactive – Selecting Evaluate in Spotlight in a bound policy creates temporary
objects. These temporary objects are deleted by Purge Risk Assessment Temporary Store batch processing.

See also

• “Risk assessment temporary objects” on page 576

• System Administration Guide

Risk assessment configurable classes

The risk assessment integration includes the a number of classes which you can modify. The following are some of
the main classes in the integration.
578 chapter 42: Configuring the Spotlight integration
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Class Description
[Link] This servlet is used to handle all HTTP requests between PolicyCenter and the
Spotlight interactive service.
This servlet has two request handlers:
• URL contains [Link] – A request handler sends the
formatted address and spatial point to Spotlight interactive service so that
PolicyCenter displays the location on the Spotlight interactive map.
• URL contains [Link] – A request handler takes the data
assessed on the Spotlight Interactive side, and returns the new risk
assessment data to Policy Center. The handler redirects Spotlight
interactive back to Policy Center and the correct wizard step.
[Link] Handles HTTP requests for locationDetails and provides location data to
Spotlight.
[Link] Handles HTTP requests for SpotlightReturn. Takes Spotlight location details,
delegates to the Spotlight Policy Location Risk Assessment plugin gateway,
then redirects back to PolicyCenter.
[Link] Specifies configuration parameters for Spotlight.
[Link] Users to whom an activity is sent. In the base configuration, the producer and
underwriter associated with the policy transaction.
[Link] Handles temporary objects for policy location and location risk assessments
in [Link] and toggles the risk assessment information display.
[Link] Contains data Spotlight passes to PolicyCenter when longitude and latitude
are adjusted in Spotlight.
[Link] Contains data PolicyCenter passes to Spotlight to interactively display location
details in Spotlight.
[Link] Contains data the Spotlight risk assessment service passes to PolicyCenter af‐
ter calculating risk assessment values.
[Link] Contains the list of fields that are used determine if a previous risk assess‐
ment was performed on the same location and under similar conditions.

Spotlight service authentication for risk assessment

The Spotlight Policy Location Risk Assessment plugin uses the ClientLoginService service, provided by
[Link], using the credentials in [Link] for authentication.
The authorization cookie returned by the service is stored in the gwAuth variable in
[Link]. The plugin use that cookie to access the risk assessment service.
The Spotlight Policy Location Risk Assessment plugin uses the same gwAuth cookie for a specified period of time
before it requires a new authorization cookie. The maximum login session time is configurable by setting
SPOTLIGHT_MAX_LOGIN_SESSION_MILLISEC in [Link]. In the base configuration, the
default login session time is 1 hour.
If the risk assessment service connection is refused with an HTTP status code 403 with the current gwAuth cookie,
then the plugin resets the login session expiration time. The plugin obtains a new authorization cookie before
making a subsequent call to the risk assessment service.
The plugin communicates with Spotlight using secure HTTPS communication.

Risk assessment error handling

The Spotlight integration includes a framework that handles error conditions between PolicyCenter and Spotlight.
The [Link] class collects errors encountered while getting risk assessment details for a
Configuring the Spotlight integration 579
Guidewire PolicyCenter 9.0.9 Configuration Guide

PolicyLocation from Spotlight. This class passes the error collector to the RiskAssessmentErrorHandler which
has a method to handle the errors in the collector.
The error collector passes the errors to one of two error handler implementations:
SpotlightInteractiveErrorHandler and SpotlightNonInteractiveErrorHandler, for handling errors in
interactive and non-interactive modes, respectively. Each error is associated by a type specified in the type list
[Link].

Request and location level errors

All errors are specified in the RiskAssessmentError typelist and have an associated category from the
RiskAssessmentErrorType typelist. The error types are Request and Location. Request level errors are errors
associated with the entire request, and not the locations. These are errors such as the connection was refused,
insufficient permission, or something that causes the entire request to fail. Location level errors are errors associated
with a specific location. An example of a location level error is an invalid address.
Request level errors are stored in InboundPeriodRiskAssessmentErrorTempStore temporary objects. Location
level errors are stored in InboundLocationRiskAssessmentErrorTempStore temporary objects. These errors are
linked to their corresponding OutboundPeriodRiskAssessmentTempStore and
OutboundLocationRiskAssessmentTempStore objects so that these errors can be handled by the
RiskAssessmentErrorHandler.
In interactive and non-interactive modes, some errors are written to the log file.
In interactive mode, the errors are stored in their respective temporary objects and appear when the locations are
revisited in the user interface.
In non-interactive mode, an activity is created for each job and error type. The activity is assigned it to the
underwriter and the producer user roles on the current job. You can configure the roles that the activities are
assigned to in [Link].

Enabling Spotlight services

Access to Spotlight services requires a credential, consisting of a username and password. The
SpotlightPolicyLocationRiskAssessmentPlugin plugin signs into Spotlight using this credential. You specify
the credential in [Link]. In the base configuration, this file contains a placeholder.

IMPORTANT To determine whether your Guidewire PolicyCenter license agreement includes

Spotlight risk assessment services, contact your Guidewire sales representative. To obtain Spotlight
URLs, user names, and credentials, contact your Guidewire support representative.

Risk assessment configuration parameters

Risk assessment parameters in [Link] enable you to set the URL for log in to Guidewire Spotlight and to
access risk assessment services.
To enable access to Spotlight risk assessment services, set RiskAssessmentIntegrationEnabled to true, and then
enable or disable the individual services by setting configuration parameters for those individual services. If
RiskAssessmentIntegrationEnabled is false, then all Spotlight risk assessment services are disabled regardless
of whether the individual service is enabled.
Set URLs to point to the risk assessment services in the SpotlightRiskAssessmentServiceURL,
SpotlightInteractiveSerciveURL, and SpotlightThumbnailMapURL configuration parameters.
For individual Spotlight risk assessment services, the configuration parameters are:

Risk assessment service Parameter

Thumbnail map RiskAssessmentThumbnailMapEnabled

Request for single evaluation SingleLocationRiskAssessmentEnabled

580 chapter 42: Configuring the Spotlight integration

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Risk assessment service Parameter

Request for multiple location evaluation MultipleLocationRiskAssessmentEnabled

If risk assessment access is disabled for a service, PolicyCenter provides alert messages. In the base configuration,
the service is inaccessible from the user interface when the service is unavailable.
However, if a service is disabled and access is attempted through the user interface, PolicyCenter displays a message
indicating that the feature is not enabled. If an attempt is made programmatically to access a disabled service,
PolicyCenter sends an activity to users identified by a configured set of roles. The activity message reports a
permanent failure and advises that the administrator can provide access.

Spotlight session time‐out

You may need to adjust the session time-out to enable users to work in Spotlight and then return to PolicyCenter
without being automatically logged out. Check the value of the SessionTimeoutSecs parameter in [Link].

Configuring the Spotlight integration 581

Guidewire PolicyCenter 9.0.9 Configuration Guide

582 chapter 42: Configuring the Spotlight integration

chapter 43

Configuring underwriting authority

Underwriting authority in PolicyCenter provides an underwriting infrastructure which you can modify or augment.
This topic describes how to configure underwriting authority.

See also
• “Configuring underwriting authority and multicurrency” on page 697
• Application Guide

Overview of configuring underwriting authority

In PolicyCenter, underwriting authority includes underwriting rules which specify when to raise underwriting issues.
Approving underwriting issues requires authority profiles. Administrative users can create underwriting rules in the
PolicyCenter user interface. Through configuration, you can modify the functionality available in the user interface
for creating underwriting rules. If you have underwriting requirements that the underwriting rules framework cannot
accommodate, you can implement those requirements in Gosu code.
The base configuration contains authority profiles for agents, underwriters, and an underwriting manager. You can
modify the authority profiles and create new ones.

Underwriting Authority Components

Underwriting authority contains the following major components:
• Underwriting Rule – Includes the name of the rule and describes how the policy transaction is affected by
underwriting, and how issues can be approved. The rules includes the condition under which it will raise an
underwriting issue. PolicyCenter provides a user interface in Administration→Business Rules for defining
underwriting rules. Alternatively, you can implement the underwriting rule in Gosu code instead rather than
through the business rules interface.
• Underwriting Issue – A specific occurrence on a policy transaction where an underwriting condition was true.
• Authority – The ability to approve underwriting issues created by a rule, and to what degree.
• Authority Profile – A group of authorities that can be given to a user, allowing the user to approve underwriting
issues that were created by a particular rule.

Configuring authority grants

Authority profiles consist of one or more authority grants that give users the authority to approve particular types of
issues. Users can have more than one authority profile, and authority profiles can be shared among multiple users.
Configuring underwriting authority 583
Guidewire PolicyCenter 9.0.9 Configuration Guide

Like roles and permissions, authority grants are always additive. A user can approve an issue if the user has at least
one grant that allows them to approve that issue. For example, a user has one profile that grants a user authority to
approve total premium up to $1000. This user also has another profile that grants them the ability to approve total
premium up to $1500. In this case, the $1500 limit will be the one that is in effect.
An authority grant has an associated value if the comparator specifies a value type other than None. If the authority
grant for a given issue has an associated value, the grant can either be contingent on the given value or can apply to
any possible value. If the grant applies to any value then the ApproveAnyValue bit is set on the associated authority
grant. Otherwise, PolicyCenter sets the Value field on the authority grant, and compares the grant value to the issue
value to determine if the issue can be approved. In addition, PolicyCenter compares the grant value to the approval
value, to make sure that the approval falls within the limits of the grant.

See also
• The Application Guide for more information about creating authority profiles in the PolicyCenter application and
how to work with them.

Underwriting authority profile object model

Authority profiles consist of one or more authority grants. PolicyCenter stores authority profiles as
UWAuthorityProfile entities and authority grants as UWAuthorityGrants. You can access authority profiles from
the User entity through the UserAuthorityProfiles field. The relationship is many-to-many, such that users can
have more than one profile, and multiple users can share the same profile.
The following illustration shows the relationship between key entities for underwriting authority profiles.

Entities Relating to Underwriting Authority Profiles

User Legend
Array key
A is one-to-
A B one B
A is one-to-
A B many B
Derived array
A is a
A B
subtype of B

A B A implements B
UWAuthorityProfile UserAuthorityProfile
A has foreign key
A B
to B

Grants

UWAuthorityGrant

Value
IssueType

The following table describes entities associated with authority profiles.

Entity Description
User The PolicyCenter user.
UWAuthorityProfile This entity contains a series of UWAuthorityGrant entities. This entity is similar to a Role entity
which serves as a collection of RolePrivilege entities. Although this entity has a Grants array to
UWAuthorityGrant, each profile can have at most one grant for a given issue type. Profile names
must be unique.
UWAuthorityGrant This entity represents a grant of authority to approve a particular type of issue. For issues that have
an associated value type, that authority can either be restricted to a particular value or can be unre‐
stricted.
UserAuthorityProfile The authority profile contains a foreign key to UWAuthorityProfile.

584 chapter 43: Configuring underwriting authority

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Displaying authority grants in the user interface

The user configures authority grants on the Authority Profiles screen under the Administration tab. The second column
displays value of the ValueComparator typelist.
Note: Guidewire chose to display the comparators as the strings At most and At least rather than as the ≤
and ≥ symbols (U+2264 and U+2265, respectively). Guidewire made this choice because databases that
do not support Unicode characters may not store these characters correctly. These symbols may be
used in Unicode-compliant installations.

See also
• Application Guide

Configuring underwriting rules

Underwriting rules and the underwriting issues the rules create are at the core of the underwriting authority feature.
PolicyCenter raises underwriting issues at specific points in the job flow. The points are defined by the checking set.
Some issues block progress at points in the job flow until they are approved. These points are defined by blocking
points. Through configuration, you can add or remove checking sets and blocking points. You can also configure
other features of underwriting rules and underwriting issues.
Underwriting rules defined in Business Rules→Underwriting Rule can be viewed by authorized users in PolicyCenter.
They can edit, enable, and disable these rules. Using Import and Export, you can move rules between PolicyCenter
instances.
If the underwriting rule is too complex to be implemented in the Underwriting Rules user interface, you can use an
alternate implementation:
• If just the rule condition is too complex, use the Underwriting Rule user interface. In the Rule Condition call a custom
utility function that implements the rule condition.
See “Custom rule utility functions” on page 609.
• Use a Gosu implementation if:
◦ The rule is too complex to write within the Underwriting Rules framework.
◦ Has outcomes that are more complex than just adding an underwriting issue. For example, create an
underwriting issue and an activity or contingency.
See “Creating externally managed underwriting rules in Gosu code” on page 603.

Configuring underwriting rules through business rules

Underwriting rules are a part of the business rules functionality, which is configurable. For more information on how
to configure business rule functionality, see:
• “Business rules parameters” on page 48 – Configuration parameters for enabling, deploying, and configuring
business rules
• “Configuring methods and properties for business rule conditions” on page 608 – Specify which methods and
properties are visible in the rule condition builder
• “Business rule actions” on page 609 – Raises underwriting issues if conditions are met
• “Rule permission provider” on page 609 – Define permissions for underwriting rules
• “Custom rule utility functions” on page 609 – Adding functions for use in the Rule Condition editor
• “Rule contexts and rule context definitions” on page 610 – Adding new context objects for use in rules
• “The business rules plugin” on page 607 – For general information about the plugin that enables you to
configure business rule functionality

Underwriting rules object model

The following illustration shows the relationship between some of the entities for underwriting rules.
Configuring underwriting authority 585
Guidewire PolicyCenter 9.0.9 Configuration Guide

Entities relating to underwriting issues

Legend

A B A has a B

A B A has 0 or more Bs
*
Policy A B
A relates to B
IssueHistories B relates to A

A B B is a subtype of A

* * *
UWIssueHistory PolicyPeriod UWReferralReason Rule
IssueKey AvailableToRun
Name
RuleCondition
*
UWIssue UWIssueType
UWRule
ApprovalInvalidFrom Name
IssueKey Code Jurisdictions
IssueType BlockingPoint LinesOfBusiness
ShortDescription CheckingSet Versions
LongDescription Comparator
Value LimitOnly

IssueType

The following table describes some of the entities associated with underwriting issues.

Entity or object Description

PolicyPeriod Stores information for a specific period of a policy.
The UWIssuesIncludingSoftDeleted array provides access to all issues on this policy, including those
marked inactive.
UWIssue These are the issues that evaluator classes create. The issues link to issue types and can contain an appro‐
val. These entities can vary in effective time and are copied from branch‐to‐branch, just like any other
effective‐dated entity. Some fields on this entity are:
• IssueKey and IssueType – These two fields uniquely identify the issue.
• ShortDescription – Description of the issue that appears in the user interface.
• LongDescription – Long description of the issue that appears in the user interface. Some users may
have permission to view the short description but not the long description.
• Value – The value, if any, associated with this issue. If present, the value is compared with authority
grants to determine if the user can approve this issue. The value is also compared with approvals to
determine if the approval still applies.
UWIssueHistory This entity represents a history of issues and approvals on the policy. The IssueKey field is a reference to
the UWIssue with that IssueKey.
PolicyCenter maintains the history in a set of non‐effdated entities on the policy and outside of the con‐
text of any particular job or policy period. PolicyCenter maintains this history for the following reasons:
• The entity captures events that happen on branches that do not end up binding.
• The entity persists after issues are removed or approvals expire.
• The entity persists even if the related periods are archived.
Since this entity attaches directly to the policy, it is retireable rather than effdated.
Rule A rule defined in Administration→Business Settings→Business Rules.
UWRule This entity defines an underwriting rule as defined in Business Rules→Underwriting Rules. Has a foreign key
to UWIssueType.

586 chapter 43: Configuring underwriting authority

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Entity or object Description

UWIssueType This entity defines the characteristics of an underwriting issue type. Contains the Name and Code that are
defined in Underwriting Rules.
UWReferralReason This entity is similar to the UWIssue entity but is accessible from the policy rather than the policy period.
This entity is used for marking a policy issue outside of a job. It identifies the details of a corresponding
UWIssue that will be generated the next time the application checks for UWIssues. Because of the close
relationship between a UWReferralReason and the associated UWIssue, the default user interface dis‐
plays them in a similar way.
For more information, see Working With the Application Guide and “Configuring underwriting referral
reasons” on page 594.

The actual link between User and UWAuthorityProfile is through the array key from User to
UserAuthorityProfile then through the foreign key from that entity to UWAuthorityProfile. For convenience,
there is a derived array from User to UWAuthorityProfile.

Adding a new checking set

The default configuration of PolicyCenter provides a number of predefined checking sets. Checking sets represents
points in the job at which issues can be raised. PolicyCenter evaluates each checking set at specific blocking points
for each job type and determines whether or not to raise an underwriting issue. For each checking set, you can
modify when the checking set is evaluated. See “Triggering point mapping” on page 609.
However, you will need to add a new checking set if you have an underwriting rule that requires checking at a new
combination of job type and blocking point.
In the base configuration, the checking set values are:

Value In Description
UI?
All PolicyCenter checks this rule at all blocking points. PolicyCenter removes an existing underwriting issue if
the evaluators do not trigger this type of issue. Issues created by this checking set may come from external
systems in a way that is not necessarily synchronized with the job flow. For example, a claim system sends
notice of excessive claims, or a billing system sends notice of a delinquent account. If you have an issue that
cannot change once the policy is quoted (without re‐editing the policy), do not use this checking set.
Manual • The underwriting issue is created when the user manually added an issue to the policy period. PolicyCenter
displays Manual issues on the Risk Analysis screen.
MVR For motor vehicle record underwriting issues. PolicyCenter checks for this issue at quote, quote release,
bind, and issuance.
PolicyRene- • PolicyCenter checks this rule prior to calling policy renewal web services. Policy renewal web services pro‐
walAPI vides methods for managing renewals in PolicyCenter. See the Integration Guide.
PreBind • For underwriting issues that can only be detected immediately prior to binding the job. PolicyCenter checks
this rule prior to binding.
PreIssuance • For underwriting issues that can be detected immediately prior to issuance. For submission policy transac‐
tions, PolicyCenter checks this rule prior to issuing the policy. If the policy transaction does not have an issu‐
ance step, PolicyCenter checks this rule prior to binding.
PreQuote • For underwriting issues that can be detected on the policy period even before quote, such as issues related
to data entered in draft mode. PolicyCenter checks this rule prior to generating a quote.
PreQuoteR- • For underwriting issues that need information from a valid quote or that can be detected after a valid
elease quote. For example, use this checking set for issues that depend on the premium. PolicyCenter checks this
rule after a valid quote, but before releasing the quote.
Question For underwriting issues is based on answers to a question set. PolicyCenter checks this rule before quote.
For information on how to associate underwriting rules with questions, see the Product Model Guide.

Configuring underwriting authority 587

Guidewire PolicyCenter 9.0.9 Configuration Guide

Value In Description
UI?
Referral For underwriting issues is related to underwriting referral reasons on the policy. PolicyCenter checks this
rule at all blocking points. PolicyCenter displays these issues in the UW Referral Reasons tab of the Risk Analysis
screen.
You can also add a referral reason to a policy by using the addReferralReason API.
Regulatory- For underwriting issues related to policy holds with the Regulatory Hold hold type. PolicyCenter checks this
Hold rule at all blocking points. The user is notified each time the job advances to the next step.
Reinsur- For underwriting issues related to reinsurance. For example, you can use this checking set to raise an issue if
ance a policy has insufficient reinsurance. PolicyCenter checks this rule at all blocking points except quote.
Renewal • For underwriting issues related to renewals. PolicyCenter checks this rule in renewal policy transactions at
quote and issuance.
Upgrade In certain cases, Guidewire uses this value when upgrading PolicyCenter. Do not use this value for any other
purpose.
UWHold Use for underwriting issues related to policy holds with the Underwriting Hold hold type. PolicyCenter checks
this rule at all blocking points. Therefore, the user is notified each time the policy transaction advances to
the next step.

The In UI column indicates the values that appear in the Rule screen of the base configuration. The
TriggeringPointKey.TF_UWRULECHECKINGSETFILTER filter narrows the choices in the user interface. Modify this
filter to add hidden values such a RegulatoryHold.
Except for All, a rule can be associated with only one checking set.
Checking set values correspond to the [Link] property. The UWIssueCheckingSet typelist
defines these values.
The blocking point at which each checking set is evaluated is specified in the [Link]
class. The code specifies which checking sets are evaluated at all blocking points. For each blocking point, the code
specifies which additional checking sets are evaluated. Each job type can also specify when checking sets are
evaluated.
For more information about checking sets and blocking points, see:
• “Checking sets and evaluators” on page 592
• “Blocking points” on page 593
• “Job interactions with underwriting issues” on page 594

Add a new checking set affecting all job types

About this task
If a checking set will be evaluated at the same blocking points for all job types, then you can change the defaults in
JobProcessUWIssueEvaluator.

Procedure
1. In Studio, open the [Link] typelist extension.
2. Add a new typecode entering a code, name, description, and optional priority.
3. Add the same typecode to the [Link] typelist extension.
Next, link the checking set typecode to the triggering point key.
4. In [Link], add a category. Set typelist to TriggeringPointKey and code to the
typecode value.
5. Open [Link].
6. Modify the static function that returns a JobProcessUWIssueEvaluator associated with the specific job type
or types that you wish to affect. An example in the default configuration is the forRenewal method. This
588 chapter 43: Configuring underwriting authority
 Guidewire PolicyCenter 9.0.9 Configuration Guide

method overrides the built-in checking at the Quote and Issuance blocking points. (Both the
CheckedAtAllBlockingPoints as well as the blocking-point-specific lists are examined.)
7. If JobProcessUWIssueEvaluator has been modified in a way that affects the CheckedAt properties or logic,
then you may need to make modifications. Do a similar review of JobProcess and how it may call
JobProcessUWIssueEvaluator or otherwise affect the CheckedAt behavior.

Add a new checking set affecting a single job type

Procedure
1. In Studio, open the UWIssueCheckingSet typelist.
2. Add a new typecode entering a code, name, and description.
3. Add the same typecode to the [Link] typelist extension.
Next, link the checking set typecode to the triggering point key.
4. In [Link], add a category. Set typelist to TriggeringPointKey and code to the
typecode value.
5. Open [Link].
6. In the forJobtype method, instantiate a new JobProcessUWIssueEvaluator with the appropriate CheckedAt
properties set. Assign it to [Link]. If this code already exists, you can add a CheckedAt
property.
For example, the forSubmission method in the default configuration is as follows:
static function forSubmission() : JobProcessUWIssueEvaluator {
return new JobProcessUWIssueEvaluator() {
:CheckedAtAllBlockingPoints = {"All"}
}
}

Adding a new value comparator

In an underwriting rule, use the Value Comparator field to define how to compare the issue value. You can specify:
• If the value of an issue is within the authority granted to a user
• If the value of an issue is within the associated value of the approval
This comparator also specifies whether the value of an approval is within the authority granted to a user.
In the default configuration, the values are:

Value Code Description

At least Numeric_GE The issue value must be greater than or equal to the approval or authority grant value. Select this
value if the issue has an associated value where a smaller number is associated with more risk, such
as a deductible. Treat the value as a BigDecimal.
At least Monetary_GE The issue value must be greater than or equal to the approval or authority grant value. Select this
(mone- value if the issue has an associated value where a smaller number is associated with more risk, such
tary) as a deductible. Treat the value as a MonetaryAmount.
At most Numeric_LE The issue value must be less than or equal to the approval or authority grant value. Select this value
if the issue has an associated value where a larger number is associated with more risk, such as total
premiums or total insured value. Treat the value as a MonetaryAmount.
At most Monetary_LE The issue value must be less than or equal to the approval or authority grant value. Use this compa‐
(mone- rator for currency amounts. Select this value if the issue has an associated value where a larger num‐
tary) ber is associated with more risk, such as total premiums or total insured value. Treat the value as a
MonetaryAmount.

In set State_Set Treat the authority grant or approval value as a set of jurisdictions, and the issue value must be with‐
in that set.

Configuring underwriting authority 589

Guidewire PolicyCenter 9.0.9 Configuration Guide

Value Code Description

None None Has no associated value. Use for issues that either exist or do not exist.

The value comparator corresponds to the [Link] property.

The ValueComparator typelist defines these values. This typelist defines the comparators that issue values can use.
You can add to the ValueComparator typelist. Each ValueComparator typekey has an associated
UWIssueValueComparatorWrapper Gosu class that performs the comparison.
You may need to add a new value comparator if:
• The issue type needs to have an associated value because different PolicyCenter users have authority to
approve specific values or ranges of values. For example, issues of a certain type have an associated class code.
PolicyCenter users can be authorized to approve issues within certain class code ranges. There is no existing
value comparator for this type. Therefore, you need to create a new value comparator for this type, and
implement Gosu code that determines whether one class code or range contains another class code range.
• The existing comparators do not meet your needs because:
◦ There is no comparator for this kind of data – For example, you need a comparator that determines the
manufacturer of a car based on the Vehicle Identification Number (VIN).
◦ There is no comparator that compares two values in the way that you require – For example, there is a
state set comparator. However, you need a comparator which determines if a jurisdiction is in the northern,
southern, eastern, or western part of the country.
Comparators are used to determined whether one value associated with some UWIssueType is within the bounds set
by some other value. The comparator is used for two different comparisons:
• Ensuring that an approval value is within a grant value.
• Ensuring that an issue value is within an approval value.
Each new value comparator has a typekey in the ValueComparator typelist and a wrapper. There must be exactly
one UWIssueValueComparatorWrapper for each ValueComparator and one ValueComparator for each
UWIssueValueComparatorWrapper. When you instantiate the wrapper, you specify the associated
ValueComparator. There is a two-way association between typekey and wrapper.

See also
• “Comparing issue values” on page 598
• Application Guide

Add a value comparator

Procedure
1. In Studio, edit the ValueComparator typelist.
2. Add a new typekey entering a code, name, and description.
3. Instantiate a wrapper for your new typekey.
In the default configuration, the wrappers are instantiated in the UWIssueValueComparatorWrapper class
located in the [Link] package. Add code to instantiate a wrapper for your new typekey. Examples in the
default configuration can be seen at the top of the file:
// The wrappers for the various OOTB ValueComparators
static final var _ge : UWIssueValueComparatorWrapper as readonly NumericGEWrapper
= new NumericGEValueComparatorWrapper("Numeric_GE")

If you prefer not to instantiate the wrapper in UWIssueValueComparatorWrapper, you can instantiate the
wrapper in the location of your choice. However, the wrapper must be instantiated in a class that loads before
PolicyCenter calls [Link]. For example, you can instantiate your wrappers
in a startable plugin which runs after loading the database, but before serving any web pages. For more
information, see the Integration Guide.
590 chapter 43: Configuring underwriting authority
 Guidewire PolicyCenter 9.0.9 Configuration Guide

IMPORTANT Failure to guarantee that PolicyCenter instantiates the wrapper before loading
UWIssueValueComparatorWrapper may result in non-deterministic null pointer exceptions if
UWIssueValueComparatorWrapper returns null for an extended typekey.

4. Instantiate a new extension to UWIssueValueComparatorWrapper for your typekey in the

[Link] package. You can use existing comparators as an example.

Adding a new value formatter

The base configuration of PolicyCenter provides formatters for currency, numbers, jurisdictions, age, units, and U.S.
dollars. PolicyCenter even provides a formatter that does not format the data. If the formatter you need is not
provided in the default configuration, you can add new value formatters. You can also modify the existing value
formatters.
In the base configuration, the values are:

Value In UI Description
Age • Formats the value as an age followed by the abbreviation yrs.

Currency Formats the value as the currency associated with the current locale.
Integer • Formats the value as an integer.

MonetaryAmount Formats the value as a MonetaryAmount, which contains a value and a currency.
Number • Formats the value as a BigDecimal.

StateSet • Formats the value as a jurisdiction.

USD Formats the value as a U.S. dollar (with cents).

USDBrief Formats the value as a U.S. dollar (without cents).
Unformatted • Does not format the value.

Units • Formats the value as an integer followed by the word units.

TestFormatter Used only for testing.

The In UI column indicates values that appear in Rule screen of the base configuration. If you add hidden values
such as Currency, PolicyCenter supports those values without further configuration.
The value formatter type corresponds to the [Link] property.
The ValueFormatterType typelist defines these values. The code is the same as the value or name. The formatter
types allow the presentation of values in a localizable and consistent manner in the user interface. Only output uses
formatters. You can configure formatters to meet a wide range of output needs.

See also
• Application Guide

Add a new value formatter

Procedure
1. In Studio, edit the ValueFormatterType typelist.
2. Add a new typekey entering a code, name, and description.
3. Instantiate the formatter and link it to your new typekey. Write code to format the value.
In the default configuration, the value formatters are instantiated in the ValueFormatter class located in the
[Link] package. Add code to instantiate the value formatter for your new typekey. Also add code to
Configuring underwriting authority 591
Guidewire PolicyCenter 9.0.9 Configuration Guide

format the value. For example, the following is the code for the Integer value formatter in the
ValueFormatter class:
final public static var FOR_INTEGER : ValueFormatter = new ValueFormatter(TC_INTEGER) {

override function format(value : String) : String {

return formatInteger(value)
}
}

The code ValueFormatter = new ValueFormatter(TC_INTEGER) links the formatter to the Integer
typekey. The formatInteger method formats the value.
If you prefer not to instantiate a value formatter in the ValueFormatter class, you can instantiate it in the
location of your choice. However, the value formatter must be instantiated in a class that is guaranteed to load
before PolicyCenter calls the [Link] method. For example, you can instantiate your
wrappers in a startable plugin which runs after loading the database, but before serving any web pages. For
more information, see the Integration Guide.

IMPORTANT Failure to guarantee that the value formatter is instantiated before loading
ValueFormatter may result in non-deterministic null pointer exceptions if
[Link] returns null for an extended typekey.

Checking sets and evaluators

Checking sets represents points in the job at which issues can be raised. For each checking set, evaluator classes
determine whether or not to create underwriting issues. Each underwriting rule and its corresponding UWIssueType
type has a checking set property.
The IPolicyEvaluationPlugin triggers policy evaluation. For each underwriting rule, this plugin uses the
checking set to determine whether to add underwriting issues on a policy period. In the base configuration, this
plugin calls evaluator classes to raise issues. The plugin then removes orphaned issues. Orphaned issues are
underwriting issues that were generated at a checking set but are no longer an issue when that checking set runs at a
later time.
If you need to change this plugin, see the Integration Guide.

See also
• “Job interactions with underwriting issues” on page 594
• Application Guide

Evaluator Classes
The evaluator classes contain methods that raise underwriting issues based upon the checking set. In the base
configuration, the default evaluator class, [Link], raises underwriting issues for all
lines of business. Each line of business implements its own evaluator class. For example, the evaluator for the
personal auto line of business is PA_UnderwriterEvaluator.gs. These evaluator classes contain methods that raise
underwriting issues for a checking set. For example, the onRenewal method in the default evaluator raises
underwriting issues for the Renewal checking set.
Note: The evaluator classes ignore the Enabled setting of the underwriting rule defined in the
Underwriting Rule user interface. Therefore, these classes raise underwriting issues regardless of the
Enabled setting.
If you make code changes to the methods that raise underwriting issues, the code must adhere to the following:
• The method must raise issues only for that checking set.
• Only one checking set can raise a given underwriting issue type.
In the default configuration, the evaluators always raise auto-approvable issues regardless of whether the current (or
other) user has sufficient authority to approve them. The evaluators always raise these issues because the issue needs
to exist for the least-privileged user of the system. This approach separates the underwriting guidelines for things
require approval from the approval levels assigned to users. For users with sufficient authority to approve the
592 chapter 43: Configuring underwriting authority
 Guidewire PolicyCenter 9.0.9 Configuration Guide

resulting issue, PolicyCenter usually does not display the issue in the user interface. (The user can easily view the
issue by selecting different view options.)
You can configure the application to raise auto-approvable issues only when one or more users would be unable to
approve them. One reason to do this would be to improve performance by reducing the number of auto-approvable
issues being raised and silently approved.

See also
• “Creating externally managed underwriting rules in Gosu code” on page 603

Orphaned underwriting issues

Orphaned issues are underwriting issues that were generated at a checking set but are no longer an issue when that
checking set runs at a later time. Therefore, issues that resulted from a previous version of the policy graph are
removed if the data that caused them to be raised has been removed. For example, during a submission,
PolicyCenter raised an issue for an expensive car on the policy. When the agent removes that car from the policy, the
issue also disappears.
Note: PolicyCenter does not remove manual underwriting issues as orphans.
The IPolicyEvaluationPlugin removes orphaned issues after it runs the evaluators that create underwriting
issues. The plugin removes or deactivates any issues for the current checking set that were not raised during that
execution of the evaluators. Issues that currently have an approval or rejection associated with them are deactivated
by setting the Active bit to false. Other issues are removed by setting the ExpirationDate to the slice date after
which the conditions for the issue no longer exist. If a deactivated issue later reappears, the Active bit on the issue
is set back to true, and any unexpired approval or rejection present on the issue applies again.

Blocking points
Blocking points represent points in the job at which an issue can block progress of the job.
The blocking point values, listed in priority order from lowest to highest, are:

Value Code Description

Non- NonBlocking Sometimes referred to as informational issues. These issues do not block progress unless
Blocking specifically rejected by a user.
Blocks Issu- BlocksIssuance Prevents issuance for submission policy transactions. Prevents binding for policy transac‐
ance tions that do not have a separate issuance step.
Blocks Bind BlocksBind The issue blocks binding the policy.
Blocks BlocksQuoteRelease Allows quoting to be performed, but unauthorized users cannot view the quote until an
Quote Re- underwriter has the opportunity to review and approve it. The job cannot progress fur‐
lease ther.
Blocks BlocksQuote Prevents quoting and steps leading up to quoting. Use for issues that require intervention
Quote before the rating engine is called. You can use this blocking point for other types of issues,
as well. However, if a policy transaction has a Blocks Quote issue, PolicyCenter will not call
the rating engine, and the policy transactions remains in draft state.
Do not use for issues that need information from a valid quote. For example, do not use
for issues related to total premium.
Rejected Rejected The most restrictive value. Rejects the issue. A rejected issue prevents the policy transac‐
tion from crossing any blocking point.

The blocking point corresponds to the [Link] property.

Blocking points are defined in the UWIssueBlockingPoint typelist. This typelist represents the places at which an
issue can block. The priority of the typecode orders the blocking point, with larger numbers indicating a more
restrictive blocking point. The blocking point of an issue is based on the combination of the blocking point and
approval, if present.
Configuring underwriting authority 593
Guidewire PolicyCenter 9.0.9 Configuration Guide

The job process classes evaluate whether to raise underwriting issues and check for blocking issues in the
evaluateAndCheckForBlockingUWIssues method. For example, the job process calls this method before binding a
policy change. Before binding, the PolicyChangeProcess evaluates the all, pre-bind, and pre-issuance checking
sets and then checks to see if any issues block issuance. PolicyCenter determines the current point at which an issue
blocks both by its type and any associated approval or rejection. Thus, the issue blocks operation if the priority of
the current point is greater than or equal to the priority of the operation. Therefore, a rejected issue blocks
everything, a non-blocking issue blocks nothing. An issue that blocks bind also blocks issuance but does not block
quoting.

See also
• Application Guide

Configuring underwriting referral reasons

Underwriting referral reasons cause underwriting issues to be raised the next time a policy transaction is run on for
that policy. The object for underwriting referral reasons is UWReferralReason. Referral reasons raise underwriting
issue types that have the Checking Set equal to Referral.
In the base configuration, the policy evaluation plugin implementation always checks for referral reasons on the
policy, regardless of checking set or line of business. [Link] implements the
IPolicyEvaluationPlugin plugin interface. The onReferral method in the DefaultUnderwriterEvaluator class
raises underwriting issues for referral reasons. This method creates a UWIssue based on that underwriting referral
reason.

See also
• Application Guide
• Integration Guide

Job interactions with underwriting issues

At specific places in the job flow, the job classes raise issues at checking sets and stop job progress because of
blocking issues.
You can view and modify the Gosu code for each job. The Gosu code is in the [Link] package in Studio.
The following topics provide the checking and blocking points for each job type for which underwriting is provided
in the base configuration. Through configuration, you can extend underwriting to other job types, such as
cancellations.

Submission
The SubmissionProcess class handles checking sets and blocking points at the following times:

Submission job Checking sets Blocking points

Before quoting All BlocksQuote
Referral
PreQuote
Question

Before quote release All BlocksQuoteRelease

Referral
PreQuoteRelease

During bind, when not issuing All BlocksBind

Referral
PreBind

594 chapter 43: Configuring underwriting authority

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Submission job Checking sets Blocking points

During bind, when also issuing All BlocksIssuance
Referral
PreBind
PreIssuance

Renewal
Unlike other jobs, the RenewalProcess is often automated. As a result, renewal follows a different flow than the
other jobs. There are a few primary differences in the automated flow:
• Checks are done and then repeated at various timeout points in the process.
• Blocking issues generate exceptions. When this occurs, the renewal is escalated to the underwriter.
The renewal job handles checking sets and blocking points at the following times:

Renewal job Checking set Blocking point

Before quoting All BlocksQuote
Referral
PreQuote
Question

Before quote release All BlocksQuoteRelease

Referral
PreQuoteRelease

Before scheduling the first check All BlocksIssuance

Referral
Renewal
PreBind
PreIssuance

During the first check All BlocksIssuance

Referral
Renewal
PreBind
PreIssuance

During the final check All BlocksIssuance

Referral
Renewal
PreBind
PreIssuance

Before issuing the renewal All BlocksIssuance

Referral
Renewal
PreBind
PreIssuance

The code handles automated renewals differently from manual renewals. In automated renewals, all issues are run as
auto-approvable. Issues are given automated approvals if the special renewal user has sufficient authority to
progress the job. The runMethodAsRenewalUser method gets a user from the getAutomatedRenewalUser method
in the IPolicyRenewalPlugin. In the default configuration, the user is renewal_daemon. The automated renewal
runs the job as this user, using the authority profile of this user for approvals. This user approves the issues.
The runMethodAsRenewalUser method sets a flag on the RenewalProcess object indicating that the renewal is
automated.
Configuring underwriting authority 595
Guidewire PolicyCenter 9.0.9 Configuration Guide

See also
• For more information about the IPolicyRenewalPlugin, see the Integration Guide.

Policy Change
The PolicyChangeProcess class handles checking sets and blocking points at the following times:

Policy change Job Checking set Blocking point

Before quoting All BlocksQuote
Referral
PreQuote
Question

Before quote release All BlocksQuoteRelease

Referral
PreQuoteRelease

During bind All BlocksIssuance

Referral
PreBind
PreIssuance

The code handles automated policy changes differently from manual policy changes. In automated policy changes,
all issues are run as auto-approvable. Issues are given automated approvals if the special policy change user has
sufficient authority to progress the job. In the default configuration, the user is policychange_daemon. The
automated policy changes runs the job as this user, using the authority profile of this user for approvals. This user
approves the issues.

Rewrite
The RewriteProcess and RewriteNewAccountProcess classes handle checking sets and blocking points at the
following times:

Rewrite job Checking set Blocking point

Before quoting All BlocksQuote
Referral
PreQuote
Question

Before quote release All BlocksQuoteRelease

Referral
PreQuoteRelease

During bind All BlocksIssuance

Referral
PreBind
PreIssuance

Issuance
The IssuanceProcess class handles checking sets and blocking points at the following times:

Issuance job Checking sets Blocking points

Before quoting All BlocksQuote
Referral

596 chapter 43: Configuring underwriting authority

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Issuance job Checking sets Blocking points

PreQuote
Question

Before quote release All BlocksQuoteRelease

Referral
PreQuoteRelease

During bind, when also issuing All BlocksBind

Referral
PreBind
PreIssuance

Reinstatement
When you reinstate a canceled policy, approvals carry over from the canceled policy even if they were approved
only until the next change. PolicyCenter does not consider reinstatement a change.

Cancellation
Cancellation jobs do no checks for underwriting issues.

Audit
Audit jobs do no checks for underwriting issues.

Issue keys
The underwriting rule and issue key uniquely identify each underwriting issue. For any given combination of
underwriting rule and issue key, there can be only one issue on a policy period at a given time. When creating an
issue, any pre-existing issue with the given type and key will be returned, and any deactivated issue that matches
will be activated and then returned.
On the underwriting issue, the [Link] property specifies the UWIssueType of the corresponding the
underwriting rule. Issue key is specified in the [Link] property. The PolicyEvalContext object
automatically enforces this.
Guidewire recommends that you do not change the algorithm for forming the key for an issue after moving that
algorithm to production. If you change the algorithm, current issues may be treated as orphaned. PolicyCenter will
create new copies of the issues, requiring new approvals or rejections.

See also
• Application Guide

Issue Key Guidelines

Guidewire recommends these guidelines for forming issue keys.
For issues that affect the policy as a whole, such that there is only ever one such issue, use the code of the
underwriting rule as the issue key. Total policy premium is an example of this. Thus, if the premium goes up or
down, the same issues will be edited, rather than raising new issues each time.
For issues that relate to a particular entity, have the issue key encode the FixedID of the entity, or potentially some
other unique identifier such as the VIN number. For example, use this method for an issue relating to the collision
deductible on a given vehicle. This method allows that same issue to be raised for several different vehicles. It also
ensures that the same issue will be modified if changes affect that issue.
If the issue relates to a jurisdiction, create one issue for each jurisdiction, with the jurisdiction encoded as part of the
issue key. Since approvals for jurisdiction-based issues only apply to one jurisdiction at a time, rather than to a set of
jurisdictions, each jurisdiction must have its own issue. An issue relating to a different jurisdiction would not reuse
approvals or rejections. For example, an issue around the garage jurisdiction of a vehicle encodes both the FixedID
Configuring underwriting authority 597
Guidewire PolicyCenter 9.0.9 Configuration Guide

or VIN of the vehicle as well as the jurisdiction. Changing the garage jurisdiction generates a new issue, rather than
modifies the existing issue. This behavior also applies to set comparator types that you develop.
If the issue relates to a specific location, or a specific building at a certain location, encode the FixedID or other
invariant identifier into the issue key. This encoding ensures that approving Building 2 in San Francisco to go
without an alarm does not approve the same for Building 2 in Los Angeles.

Configuring underwriting issue history

Underwriting history preserves an audit trail of issues and approvals, even on abandoned branches. To keep track of
this history, every issue creation or removal and every issue approval generates an UWIssueHistory entity. The
Policy entity has an IssueHistories array. This array contains the history of changes to all underwriting issues
associated with the policy. The UWIssueHistory entity is non-effdated.
A UWIssueHistory entity is created automatically every time an issue is approved or rejected. Issue histories are
also generated when the issue is reopened, removed, or when the approval expires. See the
[Link] class for details.
An UWIssueHistory entry is also generated whenever an issue is either created or deactivated.
Note: In the default configuration, a history event is not created if values on an issue change. For
example, an issue exists on a policy because there are six cars. Later the policy only has three cars.
The checking set checks the current number of cars but does not generate a history event.

UWIssueHistoryStatus typelist
The Status field on the UWHistory entity is an UWIssueHistoryStatus typelist. The UWIssueHistoryStatus
typelist represents the type of action recorded by the history. Values are:

Value Description
Approved The issue was approved.

Created The issue was created.

Expired The issue approval expired.
Rejected The issue was rejected.

Removed The issue was removed.

Reopened The issue was reopened by removing approval or rejection.

Comparing issue values

The values associated with underwriting issues (UWIssue objects) can be either numeric or non-numeric, as needed
to describe level of risk or authority related to a specific issue type. The ValueComparator is used to determine if:
• The value of an issue is within the limits set on the existing approval
• The value of an issue is within the user’s authority to approve
• A requested approval is within the user’s authority to authorize
Additionally, the value itself is not strongly typed; its type is inferred from the ValueComparator assigned to the
issue type.
The ValueComparator typelist contains the list of possible comparisons, such as at least and at most. The
UWIssueValueComparatorWrapper class defines how to compare issue values. That class uses the
UWIssueValueType class to define what the underlying value type is. The UWIssueValueType class defines how to
convert the value that gets stored in the Value field on UWIssue or the ReferenceValue field on UWHistory. This
class also defines how to validate raw string values. More than one comparator can use the same underlying value
type.
The UWIssueValueType class has three methods: deserialize, serialize, and validate. This class defines two
primary value types, represented as constants on the UWIssueValueType interface. The two value types are
598 chapter 43: Configuring underwriting authority
 Guidewire PolicyCenter 9.0.9 Configuration Guide

BIG_DECIMAL type, and STATE_SET type. The BIG_DECIMAL type converts and validates to and from a big decimal
number. The STATE_SET is a comma-separated list of codes for jurisdictions. The STATE_SET type can either be an
inclusive or exclusive set. If the list is preceded by not, a jurisdiction is part of the set if it is not in the list.
You can use STATE_SET as an example for writing comparators for other types of sets.
You can create comparators for other types of numeric values such as dates. Dates would need a greater than or
equal comparator that operates on dates instead of numbers. The UWIssueValueComparatorWrapper is bound to a
particular UWIssueValueType. The comparator wrapper implements a compare(String, String) method, which
indicates whether or not the given issue value is within the bounds of the given grant value. The wrapper also
implements a calculateDefaultApprovalValue method. The wrapper ties together an issue type to its underlying
value type (if any). Every key in the ValueComparator typelist must have an associated subclass of
UWIssueValueComparatorWrapper.

See also
• Application Guide

Configuring default values for assignment type and value offset amount
For an underwriting rule, Default Value Assignment Type is used if the value comparator is At least, At least (monetary), or
At most. In turn, if Default Value Assignment Type is Offset Amount, the Default Value Offset Amount and Default Value Offset
Currency are used. These fields correspond to properties on the UWIssueType object.
You can extended this default setting behavior for other numeric types. Positive offsets reflect increased
underwriting risk for the at least and at most comparators. For example, the At most comparator can be used for
determining the risk associated with the value of a car. If the authority grant provides default approval at $100,000
with 10% offset, the user can approve a car whose value is as high as $110,000. The At least comparator can be used
for determining the risk of a deductible. If the authority grant provides default approval for at least $1000, with 10%
offset, then the user can approve a deductible as low as $900.

Underwriter issue type verifier class

The UWIssueTypeValidationRules Gosu rules enforce constraints on UWIssueType objects to prevent certain types
of configuration errors. These rules are in configuration→config→rules→Validation in Studio.
In the base configuration, these rules enforce the following:
• Either the [Link] must be one level higher than the issue
[Link], or both must be non-blocking.
• The DefaultValueAssignmentType must be defined if the Comparator is Numeric_LE, Numeric_GE,
Monetary_LE, or Monetary_GE. These correspond to Value Comparator set to At least, At most, At least (monetary), At
most (monetary) in the Underwriting Rule screen.
• The DefaultValueOffsetAmount must be set if the DefaultValueAssignmentType is OffsetAmount or
OffsetPercent. These correspond to Default Value Assignment Type set Offset Amount or Offset Percentage.

See also
• The UWIssueType entity in “Underwriting rules object model” on page 585

Localizing underwriting issue details

As part of the base PolicyCenter product, the Underwriting Rules and associated screens provide support for multiple
languages.
On the Underwriting Rule screen, the Underwriting Issue Details has Short Description and Long Description fields for
descriptions in the display languages, such as English (US) or Japanese (Japan). These descriptions will appear in the
associated underwriting issue. Localization is implemented using multiple parameters, with one parameter for each
language. Therefore, each field corresponds to a single parameter.
Configuring underwriting authority 599
Guidewire PolicyCenter 9.0.9 Configuration Guide

Configuring approvals
PolicyCenter creates an approval when you approve or reject an issue. The UWIssueApproval object represents an
approval. To approve an issue, you must have an authority grant in an authority profile for that issue type. If the
issue has a value, the authority grant must be valid for that value.
Note: In the default configuration, the Approve button is only available if the user has the authority to
approve the issue to its default level. You can modify the configuration if you have a different use
case.
Approvals can be generated either by a user clicking to approve or reject an issue, or automatically by the
application. Automatic approval is most commonly seen for auto-approvable issues, but also occurs during
unattended processing, such as in routine renewals or automated policy changes. You can identify automatically-
generated approval through the IsManual property.
At any point in effective time, each UWIssue can have at most one approval. If you reapprove an issue, PolicyCenter
removes any existing approvals from that point forward in effective time. Approvals always extend from the current
slice the user is working with until the end of the period. An issue is eligible for approval if it currently blocks
progress and has not been rejected. If the issue has already been rejected, it must be reopened before being
approved. If the issue has been approved through issuance with a sufficient value, it must be reopened before being
approved for a different value or different approval settings.

Rejecting an Issue
Rejections generate an approval, but with the BlockingPoint set to Rejected. A rejection prevents the job from
crossing any blocking point. The user must have the uwreject permission. The user can reject an issue if:
• It is eligible for approval.
• It is a non-blocking issue and has not already been rejected.
Note: The user need not have sufficient authority to approve the issue to reject it.

Reopening an Issue
Reopening an issue removes an approval from the issue. The issue then blocks at the blocking point associated with
the issue type. To reopen an issue, you must have the uwreopen permission or be able to approve the issue.

Approval expiration
Approvals can be set to expire after a certain point in time by specifying one or three years in the
DefaultDurationType of the UWIssueType. When an approval of this type is created, the expiration date is
calculated and written to the ApprovalInvalidFrom field.

Special approval permission

There is a special approval permission that allows a user to approve an issue for any value. This permission is
uwapproveall. Guidewire provides this permission to approve issues that no user can approve. Guidewire
recommends that you never use this permission unless there is a time-critical policy that cannot be advanced by any
underwriter. An incomplete or misconfigured set of authority profiles can cause this situation. In the default
configuration, only su is given this permission.
A user with the uwapproveall permission is presented with a Special Approve button that allows them to approve any
issue that they could not otherwise approve. The user must confirm that they wish to use this permission before the
application displays the screen that allows them to approve the issue.

Passing approval requests to underwriters

In the underwriting approval process, the policy period can be referred to users with higher or different authority
profiles. These users receive activities notifying them they need to approve issues on the policy. A particular policy
may be referred to several users before being approved. When the underwriter feels that the review of the policy is
600 chapter 43: Configuring underwriting authority
 Guidewire PolicyCenter 9.0.9 Configuration Guide

complete, whether issues have been approved or not, the underwriter clicks the Release Lock button. This action
releases the policy from underwriting, and PolicyCenter sends an activity to the user who initiated the referral. The
InitialReferrer role stores the name of this user. (The underwriter can modify the recipient and other fields in the
activity.)
To facilitate passing policies between agents and underwriters, a given policy period can be flagged as edit locked
and quote hidden. After an agent hands these policies to an underwriter, the agent usually cannot edit the policy or
view the quote. The permissions for editing or viewing the quote while under review are usually reserved for
underwriters.

Edit Locked Flag

When the EditLocked flag is true, only users with the editlockoverride permission can edit the policy. The
intention is that this permission is granted to underwriters but not to producers. The EditLocked flag is set to true
when the user clicks the Request Approval button to request approval from another user. If a policy has not been
formally submitted for underwriting review, the underwriter expects the quote to be hidden and the policy locked for
editing. Therefore, the EditLocked flag is also set to true whenever a user with the editlockoverride permission
quotes a policy. The EditLocked flag is set back to false when the underwriter sends the policy back to an agent by
clicking the Release button on the associated activity. (Click Release Lock to get to the activity.) The Release button is
available even if the policy has blocking issues. The EditLocked flag is also set to false when the policy is bound
and/or issued. The EditLocked flag is always set to false when a job starts.
Note: The PCF files check the EditLocked flag to determine whether or not the policy can be edited.
The EditLocked flag does not lock the PolicyPeriod object.

Quote Hidden Flag

When the QuoteHidden flag is set to true, only users with the quotehideoverride permission can see the quote for
that PolicyPeriod. Similar to the editlockoverride permission, the intention is that the permission only be
granted to underwriters.
The QuoteHidden flag is set to true when requesting approval if the job does not already have a valid quote. The
flag is also set to true during quoting if the PreQuoteRelease blocking point has blocking issues or if the policy
being quoted is marked as EditLocked. Thus, if an underwriter with editlockoverride quotes a policy, the policy
will end up both edit locked and quote hidden. The QuoteHidden flag is set to false if a user, such as a producer,
who does not have the editlockoverride permission approves all issues blocking quote release.
In the default configuration, when EditLocked is set to false, QuoteHidden is also set to false. Invalidating the
quote also sets QuoteHidden to false. However, for policies that are under edit lock, QuoteHidden is immediately
set to true on quoting. Thus any policy in underwriting review will have its quote hidden if it has ever had an
invalid quote while under review.
Note: The PCF files for the job wizards determine whether to display the quote step by calling the
canViewQuote method in the JobProcess class. The canViewQuote method checks the value of the
QuoteHidden flag. The QuoteHidden flag does not lock the PolicyPeriod object.

Initial Referrer User Role

The InitialReferrer user role facilitates passing policies between underwriting and producers. The initial referrer
is the user who referred the policy to underwriting. When requesting approval for issues on a policy period, if the
InitialReferrer user role is not set, the role is set to the current user. When the underwriter releases the policy by
clicking Release, the InitialReferrer role is unset. An activity is sent to the InitialReferrer on the period. You
can customize this by using activity assignment as described in the Rules Guide. You can also customize the
InitialReferrer user role.
The InitialReferrer user role is a transient role assigned to users in the context of their role in the job. Because it
is a transient role, it is assigned by the job code rather than being assigned to the user in the Administration tab.
Because it is a transient role, it is not in the UserRole typelist.

Configuring underwriting authority 601

Guidewire PolicyCenter 9.0.9 Configuration Guide

Handling underwriting issues in policy revisions

This topic describes how PolicyCenter handles underwriting issues in policy revisions. Policy revisions reflect
changes to the policy over a period of time.

Handling underwriting issues in out‐of‐sequence policy changes

This topic describes how PolicyCenter handles underwriting issues in out-of-sequence policy changes. For detailed
information on how PolicyCenter handles out-of-sequence changes, see the Application Guide.
PolicyCenter handles out-of-sequence policy changes by evaluating every future slice in the policy when it evaluates
whether to raise underwriting issues. PolicyCenter first evaluates the slice. Then PolicyCenter checks to see if the
slice is blocked and automatically approves auto-approvable issues. PolicyCenter evaluates whether to raise
underwriting issues on the slice. The data can change such that the value of an issue changes in the future, or the
issue can disappear and reappear in different slices. When this occurs, the issue is automatically split and removed as
necessary. The PolicyEvalContext object pulls issues forward or backwards in time as necessary during
evaluation. However, any issue with the same type and key will have the same FixedID if it is not completely
removed from the policy as of the period start date.
Approvals are effective as of the slice date on which they are approved until the end of the period. When an issue is
reopened or reapproved as of a particular effective date, PolicyCenter removes all approvals for that issue from that
date forward. The behavior is the same for reopened and reapproved issues because a reapproved issue is
automatically reopened. Thus, an approval at time T1 will extend through T2 until the end of the period, and any
approval already at T2 will be removed. If the approval given at T1 is insufficient for time T2, the user will need to
reopen the issue at T1 and create a more lenient approval. Alternately, the user can move T2 in effective time and
reapprove the issue at time T2. PolicyCenter expires the original approval at T2 and creates a new approval from T2
until the end of the period.
If underwriting issues block future slices, PolicyCenter uses the same slice selector that it uses for out-of-sequence
validation failures. PolicyCenter displays the selector if the FailedOOSEEvaluation flag is set to true on the
period. This flag indicates that the policy period is out-of-sequence. The flag is set if a future slice has blocking
issues but the current slice is not blocking. The flag can also be set if any issues that are generated have values that
vary over time (which includes the issue itself disappearing and reappearing).
In the default configuration, PolicyCenter adds a section sign, §, to indicate that the issue varies in time.
PolicyCenter displays the section sign if the ValueVariesAcrossSlices and IssueBlocksAtSomeSlice properties
in UWIssueEnhancement are true. PolicyCenter displays the section sign in parentheses, (§), if the value varies in
time but is not currently blocking any slice. Lastly, the user interface displays a Next Blocked Date button that
automatically takes the user to the next slice in effective time where issues are blocked. The Next Blocked Date button
appears if there are blocking issues in future slices. The user can step through the slices, approving issues from that
point forward until the policy is no longer blocked. To see how PolicyCenter displays this in the user interface, see
the Application Guide.

Handling underwriting issues in preempted jobs

This topic describes how PolicyCenter handles underwriting issues in preempted jobs.
A preemption occurs if one job is in progress when another job on the same policy binds. For example, a job starts
on a policy and creates policy period PP1, which is not yet bound. Then another job on the same policy binds,
resulting in a bound policy period PP2 that preempts PP1. When the user handles the preemption on PP1,
PolicyCenter create a new policy period PP3. PolicyCenter handles underwriting issues as follows:
• All issues and approvals which are present in PP2 are carried over to PP3. Approvals from PP2 are not expired.
Therefore, if PP2 includes an approval which is invalid from the next change, that approval remains in PP3.
• If PP1 includes a new issue that does not appear in PP2, that new issue does not appear in PP3.
• If PP1 includes changes to an issue or approval that is present in PP2, the issue appears in PP3 along with the
approval from PP2. However, the issue history includes links to an invalid job. (The links still refer to PP1,
which was preempted and is no longer valid.)
602 chapter 43: Configuring underwriting authority
 Guidewire PolicyCenter 9.0.9 Configuration Guide

See also
• Application Guide

Creating externally managed underwriting rules in Gosu code

In PolicyCenter, Business Rules→Underwriting Rules provides a user interface to define underwriting rules. However, if
your underwriting rule does not fit within the Underwriting Rules framework, you can implement the underwriting rule
in Gosu code. These rules are externally managed rules, which have their rule condition defined outside business
rules, often in Gosu code. This topic describes how to create an externally managed rule in Gosu code.
Use an externally managed rule if:
• The rule is too complex to write within the Underwriting Rules framework.
• Your underwriting rule has outcomes that are more complex than just adding an underwriting issue. For example,
create an underwriting issue and an activity or contingency.
Note: After upgrading from PolicyCenter 7.0 or 8.0, legacy underwriting rules are initially
implemented as externally managed rules. See “Upgrading Underwriting Authority” in the
Configuration Upgrade Guide.
Underwriting issues can be raised by the Rule Condition in the Underwriting Rules user interface, or by an externally
managed rule. Underwriting rules conditions written using the underwriting Rule screen can be viewed by authorized
users in PolicyCenter. These rule conditions can be edited, enabled, and disabled, and can be efficiently moved
between PolicyCenter instances. Externally managed underwriting rule conditions written in Gosu are not accessible
in the user interface, however the fields associated with the underwriting issue type are. However Gosu code can
handle more complex rules and, in some cases, improve system performance. In both cases, PolicyCenter creates
UWRule and UWIssueType entities. These entities have foreign keys to each other.
This topic describes how to write Gosu code that defines the rule condition that raises underwriting issues.

IMPORTANT To avoid unexpected results, specify the rule condition in either the user interface or in
Gosu code, but not in both. PolicyCenter first executes the Rule Condition defined in the user interface
and raises an underwriting issue when the condition evaluates to true. Then PolicyCenter executes the
rule condition in Gosu.

See also
• “Configuring underwriting rules” on page 585
• Application Guide

Gosu implementation overview

This topic describes how to write Gosu code that defines the rule condition that raises underwriting issues. Use the
Underwriting Rules interface to define basic information about the underwriting rule, primarily the name and
UWIssueType properties. Use Gosu code to define the rule conditions and raise the underwriting issue. In your Gosu
implementation, you can define rule conditions that correspond to the Start Date, End Date, Rule Condition, Applies to,
and Rule Context in the Underwriting Rules user interface.
If you implement an underwriting rule in Gosu:
• In the Underwriting Rules user interface, define the UWIssueType fields. See “UWIssueType fields in underwriting
rule” on page 604.
• In the underwriting Rule, set Enabled to No.
• In the underwriting Rule, set the Rule Condition to None. You will define the rule condition in Gosu.
• On the UWIssueType entity instance, set the ExternallyManaged property to true. In the base configuration, the
user interface does not have a button to set this property for a rule. You can write code that sets this property. You
can add a button to the user interface that accesses this code.
Configuring underwriting authority 603
Guidewire PolicyCenter 9.0.9 Configuration Guide

However, be careful about when the button is available. Rules cannot be toggled between ExternallyManaged
and not ExternallyManaged. Make this button available to set ExternallyManaged to true on a brand new rule
that has no information beyond the underwriting issue type fields defined.
If ExternallyManaged is true, then the business rules framework does not run the rule.
• Provide the rule condition logic in the Gosu code. See “Creating underwriting issues with policy evaluation
plugin” on page 604.
• Manage the rule execution in the Gosu code. See “Raise underwriting issues in Gosu code” on page 605.

UWIssueType fields in underwriting rule

If you implement an externally managed underwriting rule in Gosu code, you must define the UWIssueType
properties in the underwriting Rule user interface. The interface enables you to modify the UWIssueType object. The
following table shows the fields in the underwriting Rule user interface with the corresponding UWIssueType
property. For example, entering Name in the underwriting Rule sets Name on the corresponding UWIssueType object.

Underwriting Rule user interface UWIssueType property

Rule Details tab

Name Name

Code Code

Checking Set CheckingSet

Blocking Point BlockingPoint

Default Duration DefaultDurationType

Rule Description Description

Advanced tab

Auto-approvable AutoApprovable

Default Edit Before Bind DefaultEditBeforeBind

Default Approval Blocking Point DefaultApprovalBlockingPoint

Value Comparator Comparator

Value Formatter Type ValueFormatterType

Default Value Assignment Type DefaultValueAssignmentType

Default Value Offset Amount DefaultValueOffsetAmount

In an externally managed rule, values in the other underwriting Rule fields have no effect.
Note: After upgrading from PolicyCenter 7.0 or 8.0, legacy underwriting rules have a corresponding
externally managed underwriting Rule. You can modify the UWIssueType properties listed above in
the user interface.

Creating underwriting issues with policy evaluation plugin

The IPolicyEvaluationPlugin is the starting point for the rule which creates an underwriting issue. In the base
configuration, the IPolicyEvaluationPlugin interface is implemented by the PolicyEvalPlugin plugin. This
plugin creates a PolicyEvalContext object and then evaluates ([Link] method) whether to raise
issues for the current checking set and policy lines associated with the policy period. The evaluate method first
evaluates the underwriting rules defined in the user interface. Then the evaluate method evaluates underwriting
issues types implemented in Gosu code.
The plugin uses a default class ([Link]) and line-of-business-specific classes
(PA_UnderwriterEvaluator.gs for example) to determine whether or not to raise underwriting issues.
604 chapter 43: Configuring underwriting authority
 Guidewire PolicyCenter 9.0.9 Configuration Guide

When you evaluate each checking set, your implementation must raise issues and refresh existing issues with current
values. Your implementation must also remove orphaned issues. Guidewire recommends that your implementation
use the PolicyEvalContext class to create and remove orphaned issues because these are complex and error-prone
tasks.

See also
• Integration Guide

Raise underwriting issues in Gosu code

About this task
This topic describes how to raise underwriting issues using Gosu code.

Procedure
1. To raise underwriting issues for all lines of business, modify the default evaluator class,
[Link]. To raise underwriting issues for a particular line of
business, modify the evaluator class for that line of business, [Link].PA_UnderwriterEvaluator.gs, for
example.
2. Find the appropriate method for the checking set. For example, to raise underwriting issues for the Renewal
checking set, add code in the onRenewal method of the evaluator class. You can view and modify the
correspondence between checking set and method in the AbstractUnderwriterEvaluator class.
3. Use the [Link] method to add underwriting issues. To raise underwriting issues, you
need to write Gosu code which examines the PolicyPeriod and determines whether to raise one or more
issues of this type. For example, the code may raise multiple issues if the PolicyPeriod entity contains
multiple items of the same type, such as cars or buildings.
a. Add an addIssue method (using one the available method signatures). For example:
addIssue( issueType, key, shortDescriptionBlock, longDescriptionBlock, value)

b. Provide values for issueType and key:

issueType Code from the Underwriting Rule Details in the underwriting Rule definition. Becomes [Link].

key Issue Key in the Underwriting Issue Details on the underwriting Rule definition. Becomes
[Link].

c. Provide a block for the shortDescription and longDescription parameters (one each). This allows the
method to localize the description text for all available locales. (PolicyCenter performs the localization as
it evaluates the display key.) Use this format:
shortDescriptionBlock = \ -> shortDescriptionDisplayKey
longDescriptionBlock = \ -> longDescriptionDisplayKey

d. Enter the value, which is the value that PolicyCenter checks to determine whether to raise the issue.
4. Use the [Link] method to remove orphaned underwriting issues. The
removeOrphanedIssues method is called in the PolicyEvalContext plugin.

Configuring underwriting authority 605

Guidewire PolicyCenter 9.0.9 Configuration Guide

606 chapter 43: Configuring underwriting authority

chapter 44

Configuring business rules

This topic discusses how to implement the PolicyCenter business rule plugin.

The business rules plugin

Guidewire provides a business rules plugin, the IBizRulesPlugin plugin, that you configure to manage certain
business rule functionality. In the base configuration, Gosu class BizRulesPlugin provides the default
implementation for this plugin. BizRulesPlugin implements the IBizRulesPlugin interface.
By modifying the default IBizRulesPlugin plugin implementation, you can do the following:
• Create new rule contexts and add context symbols
• Add, modify, or delete rule contexts, rule actions, and rule triggers
• Modify the set of functions and entity properties that are visible in the Rule Condition editor in the Business Rules
screens
• Create methods on the Util class that are available in autocompletion in the Rule Condition editor
• Change the rule permission provider

What can you modify in the business rules plugin class?

To make modifications to business rules, you make modifications to the following objects in the BizRulesPlugin
class, the implementation class for the Business Rules plugin.

Object Function
BlackListedMethods Provides the list of blacklisted (not permitted) methods for types other than symbols that might
be present in the context definition. In the base configuration, PolicyCenter whitelists (permits) all
methods on types other than symbols present in the context definition.
BlacklistedProperties Provides a list of blacklisted (not permitted) properties on rule context symbols. In the base con‐
figuration, PolicyCenter whitelists (permits) all properties on context symbols. This action makes
the properties available in the Rule Condition builder in the business rule editor. Adding a property
to the list hides the property in autocomplete in the Rule Condition builder.
Note: Array properties such as [Link], do not allow de‐referencing. For example,
PolicyCenter does not allow [Link][0]. However, PolicyCenter does permit array
properties such as [Link].

Configuring business rules 607

Guidewire PolicyCenter 9.0.9 Configuration Guide

Object Function
RuleActions Provides the class that defines the valid rule actions. In the base configuration, this is Gosu class
AddUWIssueRuleAction. It is possible to modify or replace this Gosu class.

RulePermissionProvider Provides the set of user permissions used with business rules. In the base configuration,
PolicyCenter uses class UWRulePermissionProvider to define the permissions used by business
rules users. It is possible to implement your own permission provider class.
TriggeringPointMap Maps between triggering points and the associated rule context definitions for each triggering
point. It is not possible to add new triggering points.
WhiteListedMethods Provides a list of whitelisted (permitted) methods on the rule context symbols. In the base config‐
uration, PolicyCenter blacklists (does not permit) all methods on context symbols to ensure that
invoking a rule does not change the state of an entity. Adding a method to the list permits the
symbol method to show on autocomplete in the Rule Condition builder.

Working with the business rules plugin class

Configuring methods and properties for business rule conditions
It is possible to configure which methods and properties are visible in the business rule editor:
• Blacklisting an entity method or property makes that item not visible in the Rule Condition builder.
• Whitelisting an entity method or property makes that item visible in the Rule Condition builder.
The included topics discuss how to modify the BizRulesPlugin class to blacklist or whitelist an entity property or
method.

Blacklisting an entity method in the rule condition builder

To blacklist an entity method is to make that method unavailable for use in the Rule Condition builder in the business
rules editor. In the base configuration implementation of the BizRulesPlugin class, Guidewire does not blacklist
any entity methods.
The following code sample illustrates how to blacklist an entity method.
override property get BlackListedMethods(): Set<IMethodReference> {
return {
PolicyPeriod#activateDraftFacAgreements(),
UWIssueType#calculateDefaultValue(String)
}
}

Blacklisting an entity property in the rule condition builder

To blacklist an entity property is to make that property unavailable for use in the Rule Condition builder in the
business rules editor. In the base configuration implementation of the BizRulesPlugin class, Guidewire does not
blacklist any entity properties.
The following code sample illustrates how to blacklist an entity property.
override property get BlackListedProperties(): Set<IPropertyReference> {
return {
PolicyPeriod#Active,
PersonalAutoLine#AllClauses,
PersonalAutoLine#AllExclusions
}
}

608 chapter 44: Configuring business rules

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Whitelisting an entity method in the rule condition builder

To whitelist an entity method is to make that method available for use in the Rule Condition builder in the Business
Rules editor. In the base configuration implementation of the BizRulesPlugin class, Guidewire provides an
example of a business rule whitelisted method.
The following code sample illustrates how to whitelist an entity method.
override property get WhiteListedMethods(): Map<IMethodReference, String> {
return {
Object#toString() -> "converts instance to readable text",
PolicyContextDefinitionLibrary#hasGoodDriverDiscount(PolicyDriver) ->
"determines whether a driver qualifies for GoodDriverDiscount"
}
}

Business rule actions

In the base configuration, Guidewire provides the Gosu class AddUWIssueRuleAction which creates underwriting
issues.
override property get RuleActions(): Set<IRuleAction> {
return {new AddUWIssueRuleAction()}
}

Whenever PolicyCenter executes a rule, it evaluates the rule condition against a PolicyPeriod object. If the
condition meets the specified criteria, PolicyCenter calls the execute method on AddUWIssueRuleAction to create
an underwriting issue. This is the main functionality of this class. The CommandParameterDefinitions property
contains parameters needed during execution.

Triggering point mapping

In the base configuration implementation of the BizRulesPlugin class, Guidewire provides the following trigger
point mapping to supported context definitions.
override property get TriggeringPointMap(): Map<TriggeringPointKey, IRuleContextDefinition[]> {
return {
TriggeringPointKey.TC_ALL->_uwContexts,
TriggeringPointKey.TC_PREQUOTE->_uwContexts,
TriggeringPointKey.TC_QUESTION->_uwContexts,
TriggeringPointKey.TC_REFERRAL->_uwContexts,
TriggeringPointKey.TC_RENEWAL->_uwContexts
}
}

You can add, delete, or modify the default underwriting rule triggering points. See “Adding a new checking set” on
page 587.

Rule permission provider

In the base configuration, Guidewire provides Gosu class UWRulePermissionProvider that defines the permissions
available for use with the underwriting business rules.
override property get RulePermissionProvider(): IRulePermissionProvider {
return [Link]}
}

It is possible for you to modify this class or replace it entirely with a class of your own.

Custom rule utility functions

In the Business Rules editor, the Rule Condition builder permits the definition of expressions that contain custom
utility functions. It is possible for a custom function to return a string formatted as a money amount in the given
currency if given a big decimal value and a currency type.
Configuring business rules 609
Guidewire PolicyCenter 9.0.9 Configuration Guide

To access a custom function in the expression builder, use the following syntax, with xxxx being the name of the
custom method.
[Link]()
Gosu class PolicyContextDefinitionLibrary, in the [Link] package, defines
the available custom functions. In the base configuration, this class contains such functions as
hasGoodDriverDiscount and monetaryAmount.
To add new functions to this class, use the existing functions as examples of how to define a new function. In this
way, you can make a utility function accessible as a context symbol. You can also exclude a utility function from a
rule context.

Rule contexts and rule context definitions

A rule context and a rule context definition are not identical business rule constructs. It is important that you
understand the difference between the two concepts.

Rule Description
Context PolicyCenter uses the rule context definition to define the symbol table that provides the list of symbols availa‐
definition ble in the business rules editor while creating or editing a rule during rule development.
Context PolicyCenter uses the rule context as a runtime construct to populate the context definition symbols with actual
data from the rule that triggered the current action. It then uses these symbol data during execution of the
triggered rule.

PolicyCenter business rule context definition

Guidewire defines rule contexts in the following business rules package:
[Link]
This package contains context definition classes such as the following, plus many more:
• BusinessOwnersUWContextDefinition
• CommercialPropertyUWContextDefinition
• GenericUWRuleContextDefinition
A rule context definition can contain one or more context symbols. For example, Gosu class
CommercialPropertyUWContextDefinition contains the following addSymbol definitions in the class constructor:
construct() {
addSymbol(PARAM_CPLINE, CommercialPropertyLine, \ec -> [Link])
addSymbol(PARAM_CPLOCATIONS, CPLocation[], \ec -> [Link])
addSymbol(PARAM_CPBUILDINGS, CPBuilding[], \ec -> [Link]*.Buildings)
}

To add a new rule context definition, follow the steps outlined in “Add new underwriter rule context definition” on
page 610.

See also
• Application Guide

Add new underwriter rule context definition

Procedure
1. Open PolicyCenter Studio.
2. In the Studio Project window, navigate to configuration→gsrc→gw→bizrules→provisioning→contexts.
a. In the contexts package, create a class that extends the GenericUWRuleContextDefinition class.
b. In a similar manner to the existing symbol definitions, edit the class constructor:
– For each new context symbol, call the addSymbol method for that symbol.
610 chapter 44: Configuring business rules
 Guidewire PolicyCenter 9.0.9 Configuration Guide

– If this is to be an iterable rule context definition, call exactly one addIterativeSymbol method.
c. Define the applicability of the new rule context definition to the PolicyCenter policy lines in function
appliesToPolicyLines.
3. In the Studio Project window, navigate to configurtion→config→Extensions→Typelist.
a. Create a RuleContextDefinitionKey typelist extension, if one does not exist.
b. Add a typecode to this typelist for the rule context definition that you created in the previous step.
4. In the Studio Project window, navigate to configuration→gsrc→gw→plugin→[Link].
a. Open class BizRulesPlugins.
This class is the IBizRulesPlugin default implementation class. If you have changed the default
implementation class for this plugin, use that implementation class instead.
b. Add an entry to the class constructor for the new rule context definition. Use an existing entry as an
example.
5. In the Studio Project window, navigate to configuration→gsrc→gw→bizrules→provisioning→triggeringpoints.
a. Open class UnderwriterEvaluatorTriggeringPoint.
b. In function supportedContexts, add an entry for the typecode that you added to the
RuleContextDefinitionKey typelist. Use an existing entry as an example.
6. Restart the application server for these changes to become effective.
7. Open Guidewire PolicyCenter and navigate to Administration→Business Settings→Business Rules→Underwriting
Rules.
a. Create a new Underwriter rule.
b. Verify that the new context symbol shows in the Context drop-down of the rule editor.
c. Experiment with the different policy lines that show in the Applies To section of the rule editor.

Configuring applicability criteria

PolicyCenter application logic triggers the execution of a business rule if the rule meets all of the following:
• The trigger and context of the triggering point match that of the rule.
• The applicability criteria, as set in the Applies To section of the rule definition screen.

Base configuration applicability criteria

In the base configuration, PolicyCenter defines the following types of applicability criteria in the UWRule entity
metadata definition:

Applicability criteria Array name Array entity

Policy lines LinesOfBusiness AppCritLineOfBusiness

Jurisdictions Jurisdictions AppCritJurisdiction

Policy transactions PolicyTransactions AppCritLineOfBusiness

As part of the applicability criteria test, PolicyCenter also tests whether the rule execution date (today’s date) is
between the defined start and end dates for the rule.

Single‐ and multi‐value applicability criteria

Applicability criteria can encompass a single value, for example, a point in time. Or, applicability criteria can be
multi-valued, for example, encompassing both the states of California and Nevada.
The business rule data model handles single- and multi-value applicability criteria differently.
Configuring business rules 611
Guidewire PolicyCenter 9.0.9 Configuration Guide

Single‐value The business rule data model stores single applicability values as a property on the UWRule entity type. To use
rule criteria a single‐value criterion, add properties for single values to the UWRule entity type, then update the PCF file
that displays the rule.
Multi‐value The business rules data model stores multiple applicability values in their own entity type with a foreign key
rule criteria to the UWRule entity type. These linked entities need to implement the RuleVersionDependent interface.
Implementing this interface ensures that PolicyCenter imports and exports these entity properties as part of
the rule.

Filtering single‐ and multi‐value applicability criteria

Guidewire provides Gosu class UWRuleApplicabilityCriteriaPredicate to filter the execution of the business
rules based on applicability criteria. This class contains a test method that takes in a RuleVersion object and
returns true or false, depending on whether the associated rule matches the defined applicability criteria. Each
class that implements the ITriggeringPoint interface uses the UWRuleApplicabilityCriteriaPredicate class to
determine how to filter the rules for execution whenever application logic triggers the business rules framework.

See also

• Application Guide

Add a new PolicyCenter applicability criterion

About this task

Adding a new applicability criterion to the set of availability criteria available in the PolicyCenter base configuration
is a multistep process.

Procedure

1. Create a new data entity type for your applicability criterion.

Use the existing applicability criteria entity types as examples:
• AppCritLineOfBusiness
• AppCritJurisdiction
• AppCritPolicyTransation
Use the same naming conventions as the existing examples.
2. Add the applicability criterion to the UWRule entity type as an array of the entity type that you created in the
previous step.
Use an existing array definition as an example.
3. Extend class UWRuleApplicabilityCriteriaPredicate and override the default behavior of the test
method to add, modify, or remove filtering restrictions.
4. Create new ITriggeringPoint implementation classes that use the Predicate class that you created in the
previous step.
5. Update PCF UWRulePanelSet to include the new input sets in the ApplicabilityCriteria pane.
The PCF ApplicabilityCriteria pane shows as the Applies To section of the business rule definition screen.
6. (Optional) Update PCF UWRules so that the list view shows a column for the new applicability criterion.
7. (Optional) Update Gosu class UWRuleFilterCriteria and the associated UWRuleFilterCriteriaDV PCF to
improve the search filtering view on the Underwriting Rules screen.
You access the search functionality of the UWRuleFilterCriteriaDV PCF pane by clicking Show Filters on the
Underwriting Rules screen.
612 chapter 44: Configuring business rules
chapter 45

Configuring the Account Holder Info

screen

The Account Holder Info screen is an example of a summary screen which consolidates information about an account
holder from PolicyCenter and other applications. The Account Holder Info screen brings together account holder
profile information from PolicyCenter, BillingCenter, ClaimCenter, and ContactManager. You can create similar
screens which display summary and status information for an individual contact, based on selected account contact
roles held by that contact. This summary screen can gather this information from Guidewire PolicyCenter,
Guidewire BillingCenter, Guidewire ClaimCenter, and Guidewire ContactManager. You can configure this screen to
obtain information from other third-party applications.
In the default configuration, some fields in the Account Holder Info screen display meaningful data only if
PolicyCenter is integrated with BillingCenter, ClaimCenter, and ContactManager. Through configuration, you can
retrieve equivalent information from third-party billing, claims, and contact systems of record.
The Account Holder Info screen includes information such as:
• Basic information, including the account holder’s name, number of accounts on which this contact is the account
holder, and in-force premium value across all policies on those accounts.
• Billing summary, including total billed and unbilled, total past due, and total outstanding.
• Value metrics, including first policy effective year, number of active policies, number and type of cancellations,
lifetime premium value, open claim count, and net total incurred on those claims.
• Various alerts, such as past-due payments and open claims.
• Summary of policy transactions in progress, with links to policy transaction details.
• Summary of open claims, with links to the affected policies.
This topic provides configuration information about the Account Holder Info screen and guidance for creating similar
screens.

See also
• Application Guide

Ways to configure the Account Holder Info screen

The Account Holder Info screen displays a summary of account holder data retrieved from PolicyCenter and other
applications. You can configure the Account Holder Info screen to meet your needs. You can also use the Account Holder
Info screen as a starting point for creating your own summary screen. If you create a screen based on the Account
Holder Info screen, Guidewire suggests that you include the features described in this topic.
Configuring the Account Holder Info screen 613
Guidewire PolicyCenter 9.0.9 Configuration Guide

The Account Holder Info screen retrieves information from other InsuranceSuite applications of the same release
version. With additional configuration, the screen can work with other versions of these products, as well as with
third-party billing, claims, and contact management systems.

Consolidate account information

You can modify the Account Holder Info screen in the default configuration to meet additional requirements.
The Account Holder Info screen is implemented in the ContactFile_AccountHolder PCF file. You can view and edit
this PCF file in Studio by navigating to configuration→config→Page Configuration→pcf→contactfile. The canVisit
property on this screen determines access to this screen and its link in the left sidebar. The screen and its link are
visible only when the selected contact has a Contact Role of Account Holder on at least one account. You can extend
this configuration to display the screen for other roles.
To configure the Account Holder Info screen to appear when other contact roles are selected, change the screen’s
canVisit property.
The only built-in role for which the Account Holder Info screen displays meaningful, accurate data is the Account
Holder contact role. You can configure any contact role to display the Account Holder Info screen. However, the screen
displays data that reflects the value and responsibility of the contact. In the default implementation, the data focuses
on account ownership. For example, billing values summarize financial responsibility of the contact, and premium
metrics reflect the monetary value the contact has with the insurer. These values only make sense if the contact owns
an account or has a significant ownership role for the all of the policies on an account. If you enable the Account
Holder Info screen for non-ownership contact roles, the values it displays are misleading.
For example, the Account Holder Info screen displays meaningful data for a second account holder contact role (for
example, a spouse) that is on a policy. In this case, the spouse has significant ownership of the policies on the
account. The data for the second account holder is similar to the data for the primary account holder.
On the other hand, the Account Holder Info screen may display misleading, inaccurate data for a contact role such as
Named Insured. For example, an account includes a policy owned by a child. Displaying the Account Holder Info
screen for that named insured displays data for all policies on the account, not just the one owned by that named
insured. Therefore the screen does not reflect the overall value of the contact. For this reason, do not enable the
Account Holder Info screen for contact roles such as Named Insured.

Add a secondary account holder contact role

About this task
You can add a Secondary Account Holder contact role and display the Account Holder Info screen when you select a
contact with this role. To do this:

Procedure
1. Create an appropriate new contact role if needed; for example, SecondaryAcctHolder_Ext, then restart the
server.
2. In Studio, open the ContactFile_AccountHolder PCF file.
3. Select the Page element to display its properties in the workspace area at the bottom of the screen.
4. On the Properties tab, change the canVisit property to include the name of the new contact role. The default
canVisit property displays the screen if the user has viewaccountholderinfo permissions and the selected
contact is an account holder of more than zero accounts.
[Link] and
[Link](contact)

To keep the default behavior and display the Account Holder Info screen for the new contact role, you can add the
new contact to the array of roles in [Link]. The
canViewAccountHolderPage method uses this variable:
final static var _roles : Set<Type<AccountContactRole>> as RolesAllowedToViewTheAccountHoldersPage =
{
614 chapter 45: Configuring the Account Holder Info screen
 Guidewire PolicyCenter 9.0.9 Configuration Guide

AccountHolder,
SecondaryAcctHolder_Ext
}

Cross‐application alerts in a single location

On the Account Holder Info screen, you can view the alerts pertaining to the selected account holder. The default
implementation includes a framework for creating and displaying alerts.
The Account Holder Info screen displays alerts in an InputColumn of the AccountHolderDV detail view. The addAlert
method in the [Link] class adds alerts to this InputColumn. This class contains
two methods to create new alerts: createPolicyAlerts and createClaimAlerts. Each of these methods defines
one alert:
• createPolicyAlerts – Displays an alert if any cancellations are in progress on any policy belonging to the
selected contact.
• createClaimAlerts – Displays an alert if there are any open claims on any policy belonging to the selected
contact.
During implementation, you can add other alerts by modifying these methods.
Note: When extending the implementation, you can either modify the code directly in its class, or
make the needed changes in a subclass of the original class. Guidewire recommends extending the
implementation in a subclass to insulate your code modifications from future product updates.
Another type of alert is a label that the Account Holder Info screen displays when certain conditions exist. This
behavior is controlled by the visible property of the label. An example of this type of alert is the
NotDirectBillAlert label at the bottom of the billing summary InputColumn. This label is visible only if the
Billing Method is not Direct Bill. You can add additional alerts of this type by adding labels to the screen and
configuring their Visible properties.

Links to referenced objects

When the Account Holder Info screen displays information about an account, policy transaction, or claim, the screen
provides a link to the referenced item.
The Account Holder Info screen provides links that take you directly to the referenced item. Links enable you to jump
directly to:
• Accounts – The number of accounts listed in the upper left portion of the screen links directly to the Contact File
Accounts screen. The Contact File Accounts screen contains additional links for each account the contact holds. Each
of those additional links takes the user to the Account File Summary screen for that account.
• Policy Transaction – The Policy Transactions in Progress section lists each of the policy transactions that are currently
in progress on the accounts on which the contact is the account holder. This section also lists the policy
transaction creation date, policy number, policy transaction number, type, and status. Links enable you to jump
directly to the Policy Summary screen for the policy to which the policy transaction applies, and to the applicable
open policy transaction details screen.
• Claims – The Open Claims section lists each open claim associated with the selected account holder. This section
also lists the insurance product, named insured (which may be different than the account holder), loss date, claim
number, status, and total incurred amount. Links enable you to jump directly to the Policy Summary screen for the
policy in which the claim has been made. From there, you can easily jump to the account to which the policy
belongs. Then select Claims to view claim details, and jump directly to the claim in the claim system, assuming
you have the required permissions.

Controlled access to the Account Holder Info screen

As a first level of access control, administrators grant or revoke access to the Account Holder Info screen or summary
screen that you implement. Access is based on user role. The screen must not provide access to data to which the
user otherwise would not have access. For example, if you have access to the screen but do not have permission to
view billing data, the screen must not display billing data.
Configuring the Account Holder Info screen 615
Guidewire PolicyCenter 9.0.9 Configuration Guide

The Account Holder Info screen uses the Account Holder Info (viewaccountholderinfo) permission to control access.
You must add this permission to the roles for users who will view the Account Holder Info screen. Users who have
permission to navigate to and view the Account Holder Info screen need additional permissions to see some of the
summary information:
• View Claim System (viewclaimsystem) permission is required to view summary claim information.
• View Billing System (viewbillingsystem) permission is required to view billing summary information.
The Account Holder Info screen also respects producer code security. If you do not have permission to view a particular
account or policy, the Account Holder Info screen does not display that information, even though the screen itself is
available. Furthermore, any totals that the Account Holder Info screen displays apply only to the accounts and policies
for which you have permission to view.

Customizing Account Holder Info screen data

The Account Holder Info screen provides access to the underlying calculations and data. You can add or remove data
items.
For example, you can make the following types of changes:
• Display summary information for additional contact roles, such as a Secondary Account Holder
• Add and remove the individual data items
• Change the Gosu code that displays the summary information

Change the length of time for cancellations

About this task
You can change the length of time (going backwards from today) for which to display information about
cancellations.

Procedure
1. In Studio, navigate to the [Link] Gosu class.
2. Modify the constant CANCELLATION_MONTHS_SINCE from its default value of 12 to a different value. The
cancellationsResultFor method uses this constant.

Change the formula that calculates lifetime premium

About this task
You can change the formula that calculates Lifetime Premium.

Procedure
1. In Studio, navigate to the [Link] Gosu class.
2. Modify the code in the calculateLifetimePremium method.

Account Holder Info screen performance

Retrieving data for the Account Holder Info screen may take additional time when compared with the performance of
other screens. Ensure that the performance of this screen does not impact the performance of routine operations that
do not involve this screen.
For example, displaying the information requested by the Account Holder Info screen may be time-consuming. To
avoid a negative impact on other PolicyCenter operations, the Account Holder Info screen is not the default screen on
the Contact tab. Instead, when navigating to the Contact location, PolicyCenter displays the Summary screen. You must
click a link in the left sidebar to view the Account Holder Info screen.
616 chapter 45: Configuring the Account Holder Info screen
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Configuration files for the Account Holder Info screen

The following topics describe the configuration files that the Account Holder Info screen uses.

Entities and the Account Holder Info screen

On the Policy entity, the OriginalEffectiveDate property stores the date on which the policy was originally
issued or bound. This property enables the display of the First Policy Effective Year. The PriorPremiums_amt property
stores premiums for policy terms prior to converting from a legacy system to PolicyCenter. This property enables
the display of the Lifetime Premium. The system can set this value during conversion on renewal.

Permissions for the Account Holder Info screen

In Studio, the configuration→config→Extensions→Typelist folder contains the following permission:
• [Link] – Permission for viewaccountholderinfo

Display keys for the Account Holder Info screen

In Studio, the configuration→config→Localizations folder contains files that define properties for the Account Holder Info
screen.
• [Link] – Contains display key values for the Account Holder Info screen.

PCF files for the Account Holder Info screen

In Studio, the configuration→config→Page Configuration→pcf→contactfile folder contains files that the Account Holder
Info screen uses.
• [Link] – Location group (menu) that adds the Account Holder Info link.
• ContactFile_AccountHolder.pcf – The main Account Holder Info page container.
• ContactFile_WorkOrdersLV.pcf – The Policy Transactions in Progress list near the bottom of the Account Holder
Info screen.
• [Link] – The Open Claims list at the bottom of the Account Holder Info screen.

Gosu files for the Account Holder Info screen

In Studio, the [Link] package contains Gosu files that the Account Holder Info screen uses.
• [Link] – Helper class that provides access to billing account information to
calculate account holder billing metrics.
• [Link] – Helper class that provides access to claims for policies belonging to account
holders.
• [Link] – Helper class that provides access to metrics associated with policies
belonging to account holders.
• [Link] – Collects metrics for accounts associated with contacts through a specified
AccountContact role.
• [Link] – Creates new instances of ContactMetrics objects each time a contact with the
specified AccountContact role is selected.
• [Link] – Collects the policy metrics for the accounts associated with a contact through a
specified AccountContact role.

Gosu class that provides data to the Account Holder Info screen
Variables and methods defined in the [Link] Gosu class provide data for the
Account Holder Info screen. The helper class [Link] provides access to
various policy metrics for the selected account holder contact.
Configuring the Account Holder Info screen 617
Guidewire PolicyCenter 9.0.9 Configuration Guide

Note: If you extend the functionality of the Account Holder Info screen, you can modify the code directly
in its class, or make the needed changes in a subclass. Guidewire recommends that you extend the
implementation in a subclass to insulate your code modifications from future product updates.

618 chapter 45: Configuring the Account Holder Info screen

chapter 46

Configuring policy data spreadsheet

import/export

In the default configuration, policy data import/export is provided in the commercial property line of business for
buildings and locations. Policy data is imported and exported to a spreadsheet in .xlsx format. You can add policy
data import/export of buildings and locations to other lines of business. You can also implement policy data import/
export for other entity types, such as vehicles in a commercial auto policy.

See also
• Application Guide

Changing the spreadsheet protection password

The worksheets within the exported spreadsheets are protected and designed to be used while protected. In the base
configuration, the password is set to 1234.
The spreadsheet protection password is not intended to provide security. It exists to help spreadsheet users maintain
the integrity of the data in the spreadsheet. If the data in your exported spreadsheets is sensitive, you must
implement appropriate measures to ensure the required level of security.

Change the worksheet protection password

Procedure
1. In Studio, navigate to [Link] and open [Link].
2. In the ExcelExporter class, find the SpreadsheetPassword variable.
3. Change the value of SpreadsheetPassword.
4. Restart PolicyCenter to deploy the change.

Configuring policy data spreadsheet import/export 619

Guidewire PolicyCenter 9.0.9 Configuration Guide

Configuring spreadsheet import/export in commercial

property
In commercial property, policy data spreadsheet import/export is accessible on the Buildings and Locations screen,
[Link]. This PCF file contains controls that initiate import and export.

Adding spreadsheet import/export to other entities

In the default configuration, policy data import/export is provided in the commercial property line of business for
buildings and locations. You can add policy data import/export to other entities, including entities in other lines of
business, by performing these steps in the following order.

Create an XML file describing columns to import and export

About this task
For each entity that you want to export and import, create an XML file that describes the columns to export and
import.

Procedure
1. Create a new XML file that describes the fields to export from and import into the entity. Name the file
[Link] and save it in configuration→ config→resources→exportimport in Studio.
Use the [Link] and [Link] files as a model for creating additional EntityInfo
XML files.
2. Add the following root element to the file:

<EntityInfo
EntityTypeName="[Link]"
ParentEntityTypeName="[Link]"
ParentEntityColumnPath="[Link]">

Attribute Required? Description

EntityTypeName Required The name of the entity preceded by:
entity.

ParentEntityTypeName Optional If the parent entity is also to be imported and exported, the name of the parent
entity preceded by:
entity.

ParentEntityColumnPath Optional The path that identifies the unique ID column of the parent entity, if a parent
entity is specified.

3. Within the EntityInfo element, add a collection of ColumnInfo child elements. Each ColumnInfo element
specifies one column to be exported to and imported from the spreadsheet. The order of the ColumnInfo
elements determines the order of the columns in the exported spreadsheet.
<ColumnInfo
ColumnType="pathTypeName"
ExcludeFromTemplate="true|false"
FlagsAction="true|false"
FlagsEntityId="true|false"
Header="displayKeyPath"
id="columnName"
Locked="true|false"
Path="beanPathToColumnValue"
RequiredForImport="true|false">

620 chapter 46: Configuring policy data spreadsheet import/export

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Attribute Required? Description

ColumnType Optional The full path type name of the column’s data value. If the column type cannot be
handled by one of the predefined data column resolvers, you must define a new
data column resolver for each such type. Then adjust the
ColumnDataResolverFactory class to select the new type when appropriate. De‐
fault: String.
ExcludeFromTemplate Optional Whether to exclude the column when exporting a template. Default: false.
FlagsAction Optional Whether the column specifies the action for the spreadsheet row. Only one column
can have this attribute set to true, and this is the Action column, typically exported
as the first column in the spreadsheet. All other attributes except Header are ignor‐
ed. Default: false.
FlagsEntityId Optional Whether the column uniquely identifies the entity. Default: false.
Header Required The display key path that contains the string that is output as the column header.
Using a display key enables the column headers to be localized. Specify the Header
value for the Action column as [Link].
PolicyCenter writes the column display keys under Export→Entity, though a dis‐
play key for that name may already exist at some other location. You can quickly
look at all exported column data under the Export node.
Id Optional The name identifier of the column upon which other columns are dependent. Used
only when another ColumnInfo specifies a Required element with this ColumnInfo
as its target. For more information, see “Create an XML file describing columns to
import and export” on page 620.
Locked Optional Whether the column value cannot be modified. Locked columns are set to read‐
only and shaded gray in the exported spreadsheet. Default: False.
Path Optional Required except when FlagsAction is true. The bean path that accesses the col‐
umn value of the entity.
RequiredForImport Optional Whether the column value must be specified when the spreadsheet is imported.
Default: false.

4. If the entity you are defining is a child of another entity that is to be exported and imported, add a Parent
element within the EntityInfo element. Within the Parent element, add a map of the parent’s ColumnInfo
elements.
For example:
<EntityInfo ...>
.
.
.
<Parent>
<ColumnInfo
Path="[Link]"
Header="[Link]"
Locked="true"
ColumnType="[Link]" />
<ColumnInfo
Path="[Link]"
Header="[Link]"
ColumnType="[Link]" />
...
</Parent>
.
.
.
</EntityInfo>

5. Optionally, add dependent elements.

A ColumnInfo element can also contain an optional map of Dependent child elements, each of which
specifies another column on which the containing ColumnInfo is dependent. Each Dependent element takes a

Configuring policy data spreadsheet import/export 621

Guidewire PolicyCenter 9.0.9 Configuration Guide

single attribute, purpose, that is a key to the id of a ColumnInfo on which the containing ColumnInfo is
dependent. For example:
<!-- Column that can have dependent columns because it has an id attribute -->
<ColumnInfo
Path="[Link]"
Header="[Link]"
ColumnType="[Link]"
id="stateColumn"
RequiredForImport="true" />
.
.
.
<!-- Column that depends on another column -->
<ColumnInfo
Path="ClassCode"
Header="[Link]"
ColumnType="[Link]"
RequiredForImport="true" >
<Dependent purpose="State">stateColumn</Dependent>
</ColumnInfo>

Defining column data resolvers

Each type (class) other than String to be exported and imported must have its own ColumnDataResolver class.
This class specifies how to convert a value to a string on export and convert the string back into the correct value
type on import. PolicyCenter defines the following ColumnDataResolvers:
• NullColumnDataResolver – Imports nothing. Typically used for the Action column and for any informational
column that is processed during import or export operations.
• SimpleColumnDataResolver – Exports and imports strings and numbers. It is so named because processing
strings and numbers is simple compared to other types.
• TypeKeyColumnDataResolver – Exports a resolved type key as a string and imports a string as a type key.
• CoverageColumnDataResolver – Exports the display value of a coverage term as a string. Imports the localized
coverage term value using the dotted path to resolve the coverage pattern and coverage term pattern.
• TerritoryCodeColumnDataResolver – Exports a territory code value as a string and imports a string as a
territory code value.
• TaxLocationColumnDataResolver – Exports a tax location value as a string and imports a string as a tax
location value.
• ClassCodeColumnDataResolver – Exports a class code value as a string and imports a string as a class code
value.
• AbstractColumnDataResolver – An abstract class that uses iterative reflection to resolve the dotted bean path to
the value that needs to be exported and imported. Typically you extend this class when defining new column data
resolvers.
• ColumnDataResolver – An interface that is responsible for importing and exporting cell data values.
Implemented by AbstractColumnDataResolver.
If you need to export and import a type (class) that is not handled by one of the provided column data resolvers, you
must implement a new one. In Studio navigate to configuration→gsrc and define a new class in
my_domain_name.[Link] where my_domain_name is the package for your company’s files. Give
the class a name appropriate to the column type it is designed to resolve.
Typically it is sufficient to leverage the AbstractColumnDataResolver and implement the method
#calculateCellValue. This method constructs and returns a new object of a type that matches the ColumnInfo
type.
For example, you can implement a new TaxLocationColumnDataResolver using
CPClassCodeColumnDataResolver as a model. If the ColumnDataResolver needs more context to resolve the
value, you can define dependent data for the ColumnInfo. In this case, the TaxLocationColumnDataResolver
requires state information to calculate the jurisdiction and find the TaxLocation. This dependency must be
completed by using the Dependent element and id attribute in the EntityInfo XML file.
622 chapter 46: Configuring policy data spreadsheet import/export
 Guidewire PolicyCenter 9.0.9 Configuration Guide

See also
• For more information about dependent elements, “Create an XML file describing columns to import and export”
on page 620

Update the ColumnDataResolverFactory class

About this task
For each new column data resolver, edit the ColumnDataResolverFactory class to select the new type when
appropriate.

Procedure
1. To open this class, use Studio to navigate to configuration→gsrc and open the class
[Link].
2. Map each new column data resolver class to an appropriate type in the TYPE_RESOLVER_MAP.

Create an import strategy for each new data column resolver

About this task
The import strategy defines how (and whether) to create and delete entities during an import operation. To create an
import strategy:

Procedure
1. In Studio, navigate to configuration→gsrc and define a new class in [Link]. Name
the class to reflect the entity you are configuring. For example, if you are configuring the PersonalVehicle
entity for import and export, name the new class PersonalVehicleImportStrategy.
2. Implement the deleteEntity and createEntity methods as needed, using return values that are appropriate
to the entity.
3. Specify a true or false return value for the AllowCreate and AllowDelete properties. If the entity you are
configuring has complex deletion requirements, consider prohibiting delete during import.
Examine the [Link] and [Link] as models for creating
new import strategies.
• CPLocationImportStrategy illustrates how to allow creation of new entities and prevent deletion. Deleting
locations is prohibited. PolicyCenter does not allow deleting a location that is in use, and there is no easy
way to determine if a location is in use during an import operation.
• [Link] illustrates a somewhat more complex scenario of creating buildings within
a location as well as the scenario of deleting a building.

Modify the ImportStrategyRegistry class

About this task
The final implementation step is to register your new import strategies. To register an import strategy:

Procedure
1. In Studio, navigate to configuration→gsrc and edit the class
[Link].
2. In the TYPE_STRATEGY_MAP variable declaration, map the entity you are configuring to your new import
strategy. For example:
static final var TYPE_STRATEGY_MAP : Map<Type, EntityImportStrategy> = {
CPBuilding -> new CPBuildingImportStrategy(),

Configuring policy data spreadsheet import/export 623

Guidewire PolicyCenter 9.0.9 Configuration Guide

CPLocation -> new CPLocationImportStrategy()

PersonalVehicle -> new PersonalVehicleImportStrategy()
}

624 chapter 46: Configuring policy data spreadsheet import/export

chapter 47

Configuring earned premium

Earned premium is the portion of premium that applies to the expired part of the policy period. In other words,
earned premium is the amount of premium that has been earned as of the current date. This topic describes how to
configure the earned premium which appears on the Earned Premium field on the policy Summary screen.
For reporting policies, the calculation includes the earned-but-unreported (EBUR) amount prior to final audit. For
package policies, PolicyCenter displays earned premium for each line of business.

See also
• Application Guide
• Integration Guide

How PolicyCenter calculates earned premium

The earned premium calculation examines all financial transactions on the policy. The calculation checks a series of
conditions, most of which are based on the calculation, or as-of, date. For reporting policies where EBUR may be
included, it also uses the date of the last premium report period. The calculation evaluates a transaction as follows:
1. If the as-of date is prior to either the posted date or the written date of the transaction, then the earned amount
for the transaction is 0.
2. Else if the amount type on the related cost is not premium, for example taxes or surcharges, then the earned
amount for the transaction is 0.
3. Else if the transaction is to be accrued (ToBeAccrued is true), then:
a. If the as-of date is after the expiration date of the transaction, then the whole transaction amount counts
toward earned premium.
b. Else if the as-of date is prior to the effective date of the transaction, then the earned amount for the
transaction is 0.
c. Else, the only other possibility is that the as-of date is between the transaction’s effective and expiration
dates. The earned amount is calculated as a prorated portion based on the as-of date.
4. Else, the only transactions left are transactions that are not to be accrued (ToBeAccrued is false). These
transactions are of two types:
a. If the transaction is earned on the effective date of the policy, The whole transaction amount counts
toward earned premium. Transactions for flat-rated costs are an example.
b. Else if the transaction is for a cost that is subject to reporting, the transaction must meet both of the
following criteria.
1) The calculation includes EBUR.
Configuring earned premium 625
Guidewire PolicyCenter 9.0.9 Configuration Guide

2) And the as-of date is after the date of the last premium reporting period.
For these transactions, the earned amount is the prorated portion between the last premium report date
and the as-of date.

See also
• Application Guide

Methods that calculate earned premium

An enhancement on the Transaction entity, [Link], defines methods to calculate earned
premium. You can modify these methods.

Calculate Earned Premium

The earned method calculates the earned premium for the transaction as of the current date. The method signature
is:
earned(lastReportedDate: Date, includeEBUR: boolean): BigDecimal

This method calls the earnedAsOf method with the asof parameter set to the current date. The parameters are
described in that method.

Calculate Earned Premium As of Date

The earnedAsOf method calculates the earned premium as of a specific date passed in as a parameter.
EarnedAsOf(asof: Date, lastReportedDate: Date, includeEBUR: boolean)

• asof – The as-of date for determining the earned premium.

• lastReportedDate – The latest date for which a premium report was processed (the end date of the report). This
parameter is only applies to reporting policies.
• includeEBUR – Set to true to calculate EBUR on the current transaction. This parameter only applies to
reporting policies.
The calculations for earned premium include or exclude EBUR based on the includeEBUR parameter. In the base
configuration, PolicyCenter EBUR is configured as follows:
• The PCF that calculates earned premium automatically sets includeEBUR to true for reporting policies where
the final audit is not complete. For more information, see “PCF files that display earned premium” on page 626.
• For all other policies includeEBUR is set to false.
Through configuration, you can change whether PolicyCenter includes EBUR in the calculation.

PCF files that display earned premium

The Policy_Summary_EarnedPremiumDV.pcf displays earned premium. For reporting policies, this screen shows
whether or not the earned premium includes EBUR. The Earned As Of date is a link that enables you to change the as-
of date for the calculation.

626 chapter 47: Configuring earned premium

chapter 48

Configuring the Team tab

This topic describes how to configure the Team tab.

Configuring the Team Screens batch process for team

statistics
The Team Screens batch process generates the Summary statistics that the Team tab screens display. In the default
configuration, the Team Screens batch process runs once an hour. If the summary statistics are out-of-date and you
need to see more recent information, you can run the batch process manually. See the System Administration Guide.
Note: Through configuration, you can create additional categories for statistics. However, the Team
Screens batch process will not generate statistics for those categories. The Team Screens batch process
only calculates statistics for activities, submissions, renewals, and other policy transactions.
When configuring the Team Screens batch process, consider the following:
• How frequently the batch process runs. See “Scheduling the Team Screens batch process” on page 627 for
details.
• The time window used to calculate user statistics. See “Setting the window size for team statistics” on
page 628.
• The logic for calculating the summary statistics. See “How PolicyCenter calculates reporting categories” on
page 628

Scheduling the Team Screens batch process

Set the frequency that the Team Screens batch process runs in [Link] file. This batch process gets
and compiles the data for the statistics on the Team tab. The following lines in the [Link] file set
the frequency of the Team Screens batch process:
<!-- Hourly user statistics generation at three minutes past the hour -->
<ProcessSchedule process="TeamScreens">
<CronSchedule minutes="3"/>
</ProcessSchedule>

The time and database workload required for running the Team Screens batch process may be significant and may
adversely impact system performance if run too frequently.

See also
• System Administration Guide
Configuring the Team tab 627
Guidewire PolicyCenter 9.0.9 Configuration Guide

Setting the window size for team statistics

The window sets the boundary for submissions, activities, or other reporting categories that the Team tab
[Link] window applies to all columns except the Open column. The Calculated on field is the time when the
batch process ran and is the end of the window. The start of the window is calculated backwards from that time. In
the following illustration, the window for activities and other reporting categories are highlighted in red.

In the default configuration, the reporting categories for activities and policy transactions are for one week.
You can set the window for reporting categories to the following sizes:

Window Description
size
This week The window starts at the beginning of the current business week until the most current run of the Team Screens
batch process.
The start of current business week is the end of the last business week. In the base configuration, the end of a
business week is configured as Friday at 5:00 p.m. Therefore, the start of the current business week is 5:00 pm of
the Friday prior to the current day. If that day is a holiday, then PolicyCenter goes back to the last know business
day.
This The start of the current month until the most current run of the Team Screens batch process.
month The start of the current month is the first day of the current month at 12:00 a.m.
N days The window is the last N days of activity, including the current day.
The start of a day is 24 hours prior to the most current run of the Team Screens batch process. Therefore, for a one
day window, if the batch process runs at July 11 10:54 a.m., the start of the window is July 10 10:54 a.m.

You can configure the statistics window for all reporting categories except activities.
In Studio, you configure the window size in [Link] by modifying the following parameters:

Parameter name See also

ActivityStatisticsWindowSize “ActivityStatisticsWindowSize” on page 58
OtherWorkOrdersStatisticsWindowSize “OtherWorkOrdersStatisticsWindowSize” on page 58

RenewalsStatisticsWindowSize “RenewalsStatisticsWindowSize” on page 58

SubmissionsStatisticsWindowSize “SubmissionsStatisticsWindowSize ” on page 59

How PolicyCenter calculates reporting categories

The following tables describes how PolicyCenter calculates which activities, jobs, or policy transactions appear in
each reporting category depending upon the window. PolicyCenter calculates the status when it runs the Team Screens
batch process. The Team tab displays the time that the batch process ran in the Calculated on field.

628 chapter 48: Configuring the Team tab

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Note: You cannot change how PolicyCenter calculates the status of reporting categories.

Activities with a one day window

The Calculation column in the following table describes how PolicyCenter calculates the status for each activity in
the Activities reporting category.
The Example column describes which activities will be included. The example assumes that the statistics were last
calculated at July 11 10:54 a.m. and that the activities window is one day.

Status Calculation Example

Open Activity with open status Includes any open activity. The window does not apply.
Overdue Activity with open status and target date on or before Includes an open activity due on or before July 10 10:54
the start of the window. a.m.
Completed Activity with completed status and close date on or Includes an activity completed between July 10 10:54 a.m.
after to the window start date. and calculating the statistics.

Submissions with a this week window

The default window size for activities and policy transactions is this week.
The Calculation column in the following table describes how PolicyCenter calculates the status for each submission
in the Submission by User reporting category.
The Example column describes which submissions will be included. The example assumes that the statistics were
last calculated at July 11 10:54 a.m. and that the submissions window is this week. The July 11 date is a Friday. In the
base configuration, the end of the business week is Friday at 5:00 p.m. Therefore, the business week started on
Friday, July 4 at 5:00 p.m.

Status Calculation Example

Open The job close date field is not set. Includes any open submission. The window does not ap‐
ply.
New The job close date is not set, and the job create time is on Includes a submission if it was created between July 4
or after the window start date. 5:00 p.m. and calculating the statistics.
Bound Any policy period associated with the job has a non‐null Includes a submission bound between July 4 5:00 p.m.
model number. The job close date is on or after the win‐ and calculating the statistics.
dow start date.

Renewals with a this month window

The Calculation column in the following table describes how PolicyCenter calculates the status for each renewal in
the Renewals by User reporting category.
The Example column describes which renewals will be included. The example assumes that the statistics were last
calculated at July 11 10:54 a.m. and that the renewal window is this month. The month started on July 1 at 12:00 a.m.

Status Calculation Example

Open The job close date field is not set. Includes any open renewal for this user. The window
does not apply.
New The job close date is not set, and the job create time is on or Includes a renewal created between July 1 12:00
after the window start date. a.m. and calculating the statistics.
Renewed Any policy period associated with the job has a non‐null Includes a renewal issued between July 1 12:00 a.m.
model number. The job close date is on or after the window and calculating the statistics.
start date.

Configuring the Team tab 629

Guidewire PolicyCenter 9.0.9 Configuration Guide

Status Calculation Example

Non- Any policy period on the job is locked and the status field is Includes a renewal non‐renewed between July 1
Renewed non‐renewed. Also, the job close date is on or after the win‐ 12:00 a.m. and calculating the statistics.
dow start date.
Not-Taken Any policy period on the job is locked and the status field is Includes a renewal not taken between July 1 12:00
not taken. Also, the job close date is on or after the window a.m. and calculating the statistics.
start date.

Other policy transactions

The Other policy transactions category includes cancellations, reinstatements, policy changes, rewrites, rewrite new
accounts, and audit jobs.
The Calculation column in the following table describes how PolicyCenter calculates the status for each policy
transaction in the Other policy transactions reporting category.

Status Calculation
Open The job close date field is not set.
New The job close date is not set, and the job create time is on or after the window start date.
Approved Any policy period associated with the job has a non‐null model number. The job close date is on or after the window
start date.

Setting the maximum number of rows on the Team screens

You can use the TeamScreenTabVisibilityRowCountCutoff configuration parameter to set the maximum number
of rows that the Activities, Submissions, Renewals, and Other Policy Transactions screens shows on the Team tab.
Increasing this parameter potentially increases the amount of time that PolicyCenter takes to render the Team screens.
If the results exceed the value of this parameter, then PolicyCenter displays a message on that screen and does not
display the results.
If you select an individual user, PolicyCenter always displays the filtered results even if the number of results
exceeds the cutoff parameter.
Using submissions as an example, view the Summary screen. If the total number of Open, New, or Bound submissions
is greater than value of this parameter, then PolicyCenter does not display any submissions on the Submissions
screen. PolicyCenter displays a message on the Submissions screen.

See also
• “TeamScreenTabVisibilityRowCountCutoff ” on page 59

630 chapter 48: Configuring the Team tab

chapter 49

Configuring Rating Management

Guidewire Rating Management has been designed to be extended through configuration if required. However, major
configuration changes may not be required.

IMPORTANT To determine whether your Guidewire PolicyCenter license agreement includes

Guidewire Rating Management, contact your Guidewire sales representative. Rating Management
requires an additional license key. For instructions on obtaining and installing this key, contact your
Guidewire support representative.

Rating Management data model

This topic describes the data model for Guidewire Rating Management.

Rate table data model

The following illustration shows some of the object relationships for rate tables.
Rate Table Objects

Legend
RateBook
A B A has a B

A B A has 0 or more Bs
*
*
RateTable RateTableDefinition RateTableMatchOpDefinition
EntityName

Physical tables/entities for rate * * *

RateTableColumn RateTableMatchOp
factor rows
*
DefaultRateFactorRow

CoverageFactorRow

The RateTable entity represents a rate table. The rate table has a pointer to a RateTableDefinition.
Configuring Rating Management 631
Guidewire PolicyCenter 9.0.9 Configuration Guide

The RateTableDefinition entity represents a rate table definition. The EntityName property contains the name of
the physical table or entity of a rate factor row. The rate factor row entity describes the data types that you can assign
to parameters and factors.
In the default configuration, the rate factor row entities are DefaultRateFactorRow and CoverageRateFactor.

See also
• Application Guide

Rate routine data model

The following illustration shows some of the object relationships for rate routines.
Rating Objects

RateBook CalcRoutineDefinition
BookVersion UpdateTime
UpdateTime * * UpdateUser
UpdateUser Version

*
RateTable * * Legend
RateBookCalcRoutine
UpdateTime A B A has 0 or more Bs
UpdateUser *

The RateBook object represents a rate book and contains rate tables and rating routines.
The RateTable object represents a rate table.
The CalcRoutineDefinition object represents a rate routine definition. In PolicyCenter, you define rate routines
on the Administration→Rate Routines screen.
The RateBookCalcRoutine object represents a rate routine included in a rate book. In PolicyCenter, rate routines
included in a rate book appear on the Included Rate Routines tab on the Rate Book Details screen.
Rate Routine Objects

CalcRoutineDefinition
Legend
PolicyLinePatternCode
A B A has a B
UpdateTime
UpdateUser A B A has 0 or more Bs
Version *

* *
RateBookCalcRoutine CalcStepDefinition CalcRoutineParameterSet
Notes PolicyLinePatternCode

* *
CalcStepDefinitionOperand CalcRoutineParameter

*
CalcStepDefinitionArgument
InScopeParam

A rate routine is composed of multiple steps, represented by the CalcStepDefinition object.

632 chapter 49: Configuring Rating Management
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Rating Management performance

Improving startup and first access to Rating Management components
Guidewire Rating Management provides two features that can improve startup time and first access to Rating
Management components. These two features can be used together. Both features are configurable.
Preloading Rating Management components
Ensures that the first access to Rating Management components is quicker because they are loaded when the
system starts. When used alone, this feature increases startup time. This feature is enabled in the base
configuration.
Precompiling rate routines JAR file
Improves system startup time. Use this feature if you have so many rate routines that startup time is unacceptably
long. Rate routines are precompiled into a JAR file. Then the JAR file is built into the PolicyCenter application.
This feature is not enabled in the base configuration.
Rate routines are stored in the database and must be converted to executable code. When rate book preloading is
on, the conversion is done at start up which can cause very long start up times. Additionally, the conversion must
be done by each and every PolicyCenter instance. The rate routines JAR feature addresses these issues. The
conversion is done just once on a test/stage environment and the converted classes are combined into a JAR. On
production systems, the conversion is avoided altogether and the rate routines are simply read from the JAR.
This feature requires that you adhere to the rate book lifecycle as described in Application Guide.

Preloading Rating Management components

In the base configuration, PolicyCenter preloads all rate books and their included rate tables and rate routines into
cache on system startup. Generally preloading Rating Management components at startup is desirable. Otherwise,
components are loaded when the first quote request accesses them, causing the first quote request to be slower.
Preloading Rating Management components is recommended for production systems where an increase in server
start time is less important than having faster first quote times. In development mode, where developers often restart
PolicyCenter and wait for tests to run, it may be preferable to turn preloading off to speed up server start time while
absorbing slower first quote times. These tradeoffs may be more noticeable in systems with complex rating content.
Preloaded Rating Management components are resident in cache, therefore preloading increases the memory
requirements of the application. Preloading may load Rating Management components that are never used.

RateBookPreloadEnabled parameter
The RateBookPreloadEnabled configuration parameter controls whether Rating Management components are
preloaded on system startup. This parameter is set to true in the base configuration.
Note: Unrelated to whether this parameter is true or false, PolicyCenter always preloads some parts
of rate books that load quickly. After this, PolicyCenter writes this message to the log file:
INFO [Link] Preloading all ratebooks

Therefore, this message is not an indication of the RateBookPreloadEnabled parameter setting.

OverriddenTableArgsLabelSimple parameter
You can speed up rate table preloading by setting the configuration parameter OverriddenTableArgsLabelSimple
to true. (The RateBookPreloadEnabled parameter must also be true.)
When true, when viewing a rate routine on the Rate Routine screen, parameters in rate routine steps may appear as
ellipses (...).

Customizing how Rating Management components are preloaded

Through configuration, you can customize which Rating Management components are preloaded. For example, you
can modify the code to only preload frequently-used rate books. In the base configuration, Active rate books are
preloaded.
Configuring Rating Management 633
Guidewire PolicyCenter 9.0.9 Configuration Guide

To change which rate books are preloaded, you can modify the RateBooksToPreload getter in the
RateBookPreloadPlugin plugin implementation.
To preload Rating Management components, the [Link] method calls the primeForAllRateBooks
method in RTMLoadActions class. This class is not modifiable. You can create your own class and call it instead of
RTMLoadActions from [Link]. Use RTMLoadActions as a model. For example, consider checking
the RateBookPreloadEnabled parameter as the [Link] method does:
if ([Link]()) {
... // preload Rating Management components
}

In the [Link] method, you can also preload other Rating Management components, such as classes
outside of rate books. This can speed up the first visit to Rating Management screens.

Loading parameter sets

The code that loads parameter sets is in the prime method in the RatebookPrimer class. Independent of the setting
of RateBookPreloadEnabled parameter, this code always preloads parameters sets when the server is in
development mode.

Precompiling rate routines JAR file

Startup time in a PolicyCenter installation with a large number of rate routines can be very long. You can improve
system startup time by precompiling rate routines into a JAR file and building the JAR file into the PolicyCenter
application. This also improves performance when first accessing rate routines. This feature is not enabled in the
base configuration.
When you use this feature, you generate and download the rate routines JAR file in the stage/test environment. In
the base configuration, the JAR file contains rate routines from all Active rate books. You download the JAR file
from the stage/test environment and include it in the production build of PolicyCenter.
Note:
Precompiling rate routine JAR file is not supported on JBoss application servers.

Requirements

Precompiling rate routines JAR requires that you adhere to the following:
• You must adhere to the rate book lifecycle as described in Application Guide. In the lifecycle, the rate book
moves to Approved status in the stage/test environment. The rate book is imported to the production environment
and then updated to Active status.
• All rate routines used in rating must be in one of the rate books returned by RateRoutinesToExportToJAR getter
of the rate book preload plugin. PolicyCenter throws an exception when it attempts to use a rate routine that is
not in the list of rate books.
For example, rate book R contains rate routine X, and rate book R is not in the list of rate books returned by the
plugin. If rating attempts to use rate routine X, PolicyCenter throws an exception, even if R is in Active status.
PolicyCenter relies on the list of rate book returned by the RateRoutinesToExportToJAR getter.

Incremental updates to the JAR file on the production system

PolicyCenter keeps the JAR file up-to-date by responding to changes in rate books. In the base configuration, the
JAR file is updated when a rate book is imported from XML or when a rate book is promoted to Active status. (The
JAR file is updated only if the rate book's rate routines are not in the JAR file.) This enables you to make changes to
rate books without having to regenerate the JAR file and rebuild and redeploy PolicyCenter.

634 chapter 49: Configuring Rating Management

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Note: If the production environment contains Active rate books that are not in the stage/test
environment, then those rate routines are initially missing from the JAR file created in the stage/test
environment. When the production system starts up, PolicyCenter updates the JAR file with the
missing rate routines. However, this increases startup time.

Incremental updates on WebSphere

On WebSphere, incremental updates to the rate routines JAR file are lost when you restart the application. On
restart, WebSphere unpacks the WAR file to a new temporary directory. This means that any updates made to the
JAR during the previous run are lost, and the JAR may need to be updated at start up if there are any rate book
changes.

Propagating major changes to the production system

If you are making major changes that require rebuilding the PolicyCenter application, then generate and download
the rate routines JAR file on the stage/test system as part of the rebuilding process. Then include it in the production
system.
Another reason for regenerating the JAR file is that rate books can expire. PolicyCenter never removes any routines
that are already in the JAR, it only adds new routines. So the JAR file may contain rate routines from expired rate
books. These rate routines, which will never be used for rating, will be preloaded.

Enable and configure precompiling the rate routines JAR file

About this task

Follow these instructions to enable and configure precompiling the rate routines JAR file on the stage/test and
production systems.

Procedure
Enable
1. In Studio, open [Link].
2. Set the value of the EnableRateRoutinesJar parameter to true.
Setting this parameter to true:
• Causes the Rate Books screen to display the Generate JAR File and Download JAR File buttons and other user
interface elements for creating the rate routines JAR file. If you wish to hide these user interface elements in
the production system, you can modify the [Link] file.
• Enables preloading rate routines from the rate routines JAR file.
3. In the RateRoutinesJarFile parameter, specify the path where the rate routines JAR file will be located in
PolicyCenter. The recommended name and location is modules/configuration/plugins/Gosu/lib/
[Link]. SeeIntegration Guide for allowed locations.
4. If you are running on Windows Server:
a. Specify the rate routines update JAR file in the RateRoutinesUpdateJarFile parameter.
On Windows Server, PolicyCenter updates this JAR file when changes occur in rate books. If you do not
specify this parameter, the JAR file is not updated when changes occur. If you run PolicyCenter from
Studio, you get and exception and a message that the file is locked by another process.
b. Modify the startup process as described in “RateRoutinesUpdateJarFile” on page 84.
Configure
5. Review the base implementation of the RateBookPreloadPlugin plugin implementation and decide whether
you will use the base implementation or create your own. You can use the base implementation as a model.
6. If you only modified configuration parameters, restart PolicyCenter to pick up these changes. If you changed
the RateBookPreloadPlugin plugin, then recompile and restart PolicyCenter.
Configuring Rating Management 635
Guidewire PolicyCenter 9.0.9 Configuration Guide

Next steps
“Generate and download the rate routines JAR file” on page 636

Generate and download the rate routines JAR file

Before you begin

“Enable and configure precompiling the rate routines JAR file” on page 635

About this task

When rate books are ready to be deployed to the production system, then generate and download the rate routine
JAR file on the stage/test system.

Procedure
1. On the stage/test system, go to the Rate Books screen and click Generate JAR File to create the rate routines JAR
file. This action is asynchronous, so you can navigate to other screens.
If you make changes to rate books, redo this step.
2. When you have finalized the JAR file, click Download JAR file on the Rate Books page. This button becomes
active after you generate the JAR file. If Download JAR file is not active, navigate away from and back to this
page.
The downloaded JAR file is saved to a location specified by your browser and operating system. For example,
on Windows, the file may be saved to the Downloads folder.

Next steps
“Deploy the rate routines JAR to the production system” on page 636

Deploy the rate routines JAR to the production system

Before you begin

“Generate and download the rate routines JAR file” on page 636 on the stage/test system

About this task

Follow these instructions to build the rate routine JAR file into the production system. Perform these steps in the
PolicyCenter directory where you are building the production system.

Procedure
1. In the PolicyCenter application directory for the production system, copy the downloaded [Link]
to the directory you specified in the RateRoutinesJarFile configuration parameter.
2. Build PolicyCenter.

Rate book preload plugin

The preloading Rating Management components feature and precompiling rate routines JAR feature use the
RateBookPreloadPlugin plugin.
The default plugin implementation is in the RateBookPreloadPluginImpl class. You can use this implementation as
an example for creating your own plugin implementation.

Preloading Rating Management components feature

The preloading Rating Management components feature calls the RateBooksToPreload getter to get the list of rate
books to preload on system startup.
636 chapter 49: Configuring Rating Management
 Guidewire PolicyCenter 9.0.9 Configuration Guide

In the default implementation, the RateBooksToPreload getter returns the list of rate books that are in Active status.
The rate books must meet the following criteria:
• For all Active rate books with the same code, the rate book with the most recent effective date.
• All Active rate books with effective date in the future. The assumption is that the rate book will soon be in use.

Precompiling rate routines JAR file feature

The precompiling rate routines JAR file feature calls the RateBooksToExportToJar getter to get the list of rate
books whose rate routines will be included in the JAR file. PolicyCenter calls this getter when you generate the rate
routines JAR file by clicking Generate JAR file on the Rate Books screen. PolicyCenter then compiles the rate routines
in the list of rate books into the JAR file.
Note:
All rate routines used in rating must be in one of the rate books returned by
RateRoutinesToExportToJAR getter of the rate book preload plugin. PolicyCenter throws an
exception when it attempts to use a rate routine that is not in the list of rate books.
For example, rate book R contains rate routine X, and rate book R is not in the list of rate books
returned by the plugin. If rating attempts to use rate routine X, PolicyCenter throws an exception, even
if R is in Active status. PolicyCenter relies on the list of rate book returned by the
RateRoutinesToExportToJAR getter.
In the default implementation, the RateBooksToExportToJar getter returns the list of rate books that are in Active
status. Returning rate books whose status is not Active from this method may have undesirable effects.
This feature calls the update method when PolicyCenter needs to update the rate routines JAR file. The update
method uses the RateBooksToExportToJar getter.
In the default implementation, the JAR file is updated when:
• A rate book is promoted to Active status
• A rate book is imported
The input parameter to the update method is an event as defined by RateBookEvent enumerated list:
Activate
Rate book changed to Active status
Create
Rate book created with Draft status
Approve
Rate book changed to Approved status
Export
Rate book exported to XML
Import
Rate book imported from XML
Stage
Rate book changed to Stage status

Creating your own plugin implementation

You can use the default implementation, RateBookPreloadPluginImpl, as an example for creating your own plugin
implementation.
In your implementation, you may decide to preload one set of rate books, and compile a different set of rate books
into the JAR file.
Your implementation can update the JAR file for other rate book events.

Configuring Rating Management 637

Guidewire PolicyCenter 9.0.9 Configuration Guide

Configuration parameters and loading Rating Management components

You can use the preloading Rating Management components feature and precompiling rate routines JAR feature
together or separately.

Preloading Rating Management components only

In the base configuration, the preloading Rating Management components feature is enabled. Precompiling rate
routines JAR is disabled. The configuration parameters are set to these values:
• RateBookPreloadEnabled to true
• EnableRateRoutinesJar to false
When you start the server with only the preloading Rating Management components feature enabled:
• The RateRoutinesJarFile parameter is ignored.
• Rating Management components, including rate routines, are loaded into cache on system startup.

Preloading Rating Management components and precompiling rate routines JAR file
To use both the preloading Rating Management components feature and the precompiling rate routines JAR feature,
set the configuration parameters as follows:
• RateBookPreloadEnabled to true
• EnableRateRoutinesJar to true
When you start the server with both features enabled:
• If the RateRoutinesJarFile parameter points to a valid JAR file:
◦ Then all rate routines in the JAR file are preloaded.
◦ If the RateBooksToExportToJar method in the rate book preload plugin returns rate books whose rate routines
are not in the JAR file, the JAR file is recompiled. Then the JAR file is preloaded. Because this slows startup
time, you are encouraged to avoid this situation.
• If the RateRoutinesJarFile parameter points to an invalid JAR file:
◦ PolicyCenter throws an exception and does not start.

Precompiling rate routines JAR file only

To use only the precompiling rate routines JAR file feature, set the configuration parameters as follows:
• RateBookPreloadEnabled to false
• EnableRateRoutinesJar to true
• RateRoutinesJarFile
When you start the server with only this feature enabled:
• Rate routines are not preloaded.
• The file specified by RateRoutinesJarFile is created if it does not exist. If it exists, it is updated if it is a valid
JAR file.

Disable both features

To disable both the preloading Rating Management components feature and the precompiling rate routines JAR file
feature, set the configuration parameters as follows:
• RateBookPreloadEnabled to false
• EnableRateRoutinesJar to false
When you start the server with both features disabled:
• Rate routines are not preloaded.
• The rate routines JAR file is not used to load rate routines and is not updated.
638 chapter 49: Configuring Rating Management
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Improving rate table performance

For each rate table, you can choose whether to load the table into memory or access it from the database. By default,
PolicyCenter loads rate tables into memory. Loading the rate table in memory can provide quick access. Accessing
the table on disk is slower, but loading a large table into memory may slow system performance even more.
To decide whether or not to load the table into memory, consider how large the table will be and how often it will be
referenced. Consider database lookup if:
• The table has multiple thousands of rows and is referenced infrequently. For example, referenced only on a small
percentage of quotes.
• The table is very large (multiple tens of thousands of rows) and is only referenced once or twice per quote.
For anything smaller, or for a table referenced numerous times to quote a policy, use memory lookup, if possible.
Database lookup can result in significant slowdown.
Rating management consults the lookup setting when promoting the rate book status from Draft to Stage.
Therefore, you can only change the lookup setting when the rate book is in Draft status.
A rate table can be included in multiple rate books but can have only one setting for lookup. You can only change
the lookup setting in the first rate book that included the rate table, if it is in Draft status.
Performance depends on the rate table content, not just the row count. For a table that is small enough to fit in
memory, in-memory will usually outperform a call out to the database. For database-queried tables, if the query
tends to hit the correct row every time, database performance is better than if the query frequently goes through the
relaxing process. A query hitting on the first try usually corresponds to a table which is mostly filled out, with very
few null values. On the other hand, you can expect relaxation to occur often if the table has many null values.

See also
• Application Guide

Improving performance with a covering index

Doing repeated database queries against a generic physical table (such as DefaultRateFactorRow) can cause
performance issues.
If a rate table is large enough to warrant running the queries in the database, configure the physical table to have a
custom row entity with a covering index. The covering index on the row entity includes the foreign key to the
RateTable, the Retired property, and all parameters and factors.
For example, you have a custom row entity, CustomFactor. This row contains properties for parameters named
OptCode and Jurisdiction. The index for this row begins with the foreign key to rate table and Retired, followed
by the parameters and factors:
<index
name="factorlookup"
desc="Speeds lookup queries against this table.">
<indexcol
name="RateTable"
keyposition="1"/>
<indexcol
name="Retired"
keyposition="2"/>
<indexcol
name="OptCode"
keyposition="5"/>
<indexcol
name="Jurisdiction"
keyposition="6"/>
name="Factor"
keyposition="7"/>
</index>

See also
• Application Guide
Configuring Rating Management 639
Guidewire PolicyCenter 9.0.9 Configuration Guide

Improving performance of rate tables loaded in memory

To improve rate table lookups, these configuration parameters influence the behavior of the rate table row cache.
You can modify the values in [Link].

Parameter Description Default

RateBookCacheUpdateIntervalSecs The time in seconds after which the rate book cache is 307
rebuilt: all non‐active rate books are refreshed and any
rate books added after the last update are added to
the cache.
RateBookCacheEntryLifetimeSecs The maximum time in seconds that a non‐active rate 53
book can stay in the rate book cache without being
refreshed.
RateTableCacheConcurrency Provides guidance on the maximum number of 16
concurrent operations on the rate table cache.
RateTableCacheEntryLifetimeSecs The maximum time in seconds for which a rate table in 53
a non‐active rate book can stay in the rate table cache
without being refreshed.
RateTableCacheMaxSize The maximum number of rate tables that can be in the ‐1
rate table cache. For no limit, set to -1. To disable rate
table caching, set to 0.
RateTableCacheUpdateIntervalSecs The time in seconds after which the rate table cache is 307
cleared.
RateTableDefinitionCacheUpdateIntervalSecs The time in seconds after which the rate table 601
definition cache is cleared.

A non-active rate book is a rate book not in Active status.

Parameters and properties for Rating Management

This topic describes parameters and properties related to Rating Management.

Minimum rating level parameter

Rating Management has a configuration parameter to set the minimum rating level.
In production, only rate books in Active status are used for policy rating. However, since active rate books can
never be updated, it is useful to be able to test with rate books not yet in Active status. Then you can make changes
in the current version instead of creating another version of the rate book for the next cycle of testing.
Rating Management has a RatingLevel parameter to support rating with rate books not yet in Active status in a
development or test environment. This parameter controls the minimum rate book status that the rating query
considers as a candidate. The default level is Active, which is the recommended level for production environments.
A lower level can be set for development or test environments.
The rating level is set in a parameter on the IRatingPlugin plugin in [Link]. The parameter
can have one of the following RateBookStatus values (in decreasing order):
• Active
• Approved
• Stage
• Draft
The RatingLevel is passed to the query as part of the filter. The query considers all books that are of equal or higher
status than the minimum rating level.
640 chapter 49: Configuring Rating Management
 Guidewire PolicyCenter 9.0.9 Configuration Guide

See also

• Integration Guide

Rate table normalization configuration parameters

In a rate table that contains a range parameter and any other parameter, the table may have ranges that overlap. For
tables that fall within specified configuration parameters, PolicyCenter normalizes the rate table to speed up rate
factor lookups.
In [Link], two parameters control whether or not PolicyCenter normalizes a rate table by default. These
parameters are:
• RateTableManagementNormalizationRowThreshold
Default: 1000
If the number of rows in the normalized table would exceed this threshold, the user is given the option to store a
non-normalized version of the table.
• RateTableManagementNormalizationRowLimit
Default: 10000
PolicyCenter determines whether to normalize a rate table if the table contains this many rows or more.
If the number of rows in the normalized table would exceed this limit, the table is automatically marked as non-
normalizable. PolicyCenter stores the non-normalized version of the table.

See also

• Application Guide

Logging properties for Rating Management

Rating Management defines the following logging categories:

Category Description
[Link] Logging for messages related to Guidewire Rating Management.
[Link] Logging for messages related to rate table management.

[Link] Logging for messages related to creating and executing rate routines.

See also

• System Administration Guide

Third party libraries for Rating Management

Rating Management has the following third-party libraries.

POI library
The POI library supports reading and writing rate tables to and from Microsoft Excel workbooks. POI is an Apache
licensed library. This library provides Java APIs for manipulating various file formats based upon the Office Open
XML standards (OOXML) and Microsoft's OLE 2 Compound Document format (OLE2).

Configuring Rating Management 641

Guidewire PolicyCenter 9.0.9 Configuration Guide

User authority and permissions for Rating Management

The default configuration includes a starter set of permissions and roles related to Guidewire Rating Management.
Review and update these as required for your specific implementation. See the Application Guide for details on roles
and permissions.
The default configuration has the following permissions and roles.

Rating Management permissions

The permissions related to Rating Management are:
• ratebookview
• ratebookedit
• ratebookapprove
• editrateasofdate
• usereditlang
• rateimpacttesting

Rating Management roles

The roles related to Rating Management are:
• rating_analyst
• rating_supervisor

Assignment of permission to roles

Permissions are assigned to roles in the default configuration as follows:

Permission Code Assigned to roles

View rate books and tables ratebookview superuser
rating_analyst
rating_supervisor
underwriter
underwriter_supervisor

Edit rate books and tables ratebookedit superuser

rating_analyst
rating_supervisor

Approve rate books and tables ratebookapprove superuser

rating_supervisor

Edit Rate as of Date editrateasofdate superuser

underwriter
underwriter_supervisor

Edit user language usereditlang superuser

rating_analyst
rating_supervisor
underwriter
underwriter_supervisor

Rate policies for rate impact testing rateimpacttesting superuser

rating_analyst
rating_supervisor

642 chapter 49: Configuring Rating Management

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Custom physical tables for Rating Management

The default configuration includes two physical tables that can be used as-is and as models for other custom tables
that may be required for a particular implementation. These tables are:
• A default, generic physical table that can be used to store many of the rate tables required for most lines of
business. This table is the DefaultRateFactorRow entity.
• A sample custom physical table for simple coverage-based rate tables. This table is the CoverageRateFactor
entity.
If neither table is appropriate, you can configure a new custom physical table for one or a group of similar rate table
definitions.

See also
• Application Guide

Configuring a new custom physical table

To configure a new custom physical table, you must create an .eti file for a system entity. You can use the
CoverageRateFactor entity as a model for your new custom entity.
The following requirements must be satisfied when creating a custom entity for rate table factors:
• Must have a foreign key to RateTable entity.
• The name of the foreign key must be RateTable.
• Must define at least two columns to accommodate at least one parameter and at least one factor.
• Must have at least one column of either String, Integer, Decimal, Boolean, or Date type. These are the types
supported for parameters and factors.
The custom entity must be created in the modules/configuration/config/extensions directory.
The custom entity can be referenced in the Physical Table field in the Basics tab of the Rate Table Definition Editor.

Configuring value providers

The default configuration includes the following types of value providers:
• Typelist value provider
• PolicyCenter product model value provider
• Reference factor value provider
If none of these is appropriate, a new custom value provider can be configured.
All classes related to value providers are located in the [Link] package. A value provider
may use an optional list of string arguments. Value providers are instantiated though the
RateTableCellValueProviderFactory factory class.
This topic describes the value providers in the default configuration, and how to configure a new value provider.

See also
• The Application Guide for user-level information

Typelist value provider

The typelist value provide is:
• Implemented in TypelistValueProvider class.
• Tied to a typelist defined in the system.
• Does not support any optional attributes.
Configuring Rating Management 643
Guidewire PolicyCenter 9.0.9 Configuration Guide

• A list of values is sorted according to typelist priorities.

PolicyCenter product model value providers

This topic includes descriptions of the PolicyCenter product model value providers.
Note: Availability of coverages, terms and options is not checked by any of these value providers.

Coverage value provider

The coverage value provider, CoverageValueProvider:
• Extends the abstract AbstractProductModelValueProvider class.
• Provides a list of policy line coverages for a particular policy line.
• Returns:
◦ A list of coverage codes for values
◦ A composite label consisting of coverage category name and coverage name based on a string template defined
in the [Link] display key
• The list is sorted by coverage category priority first and then by coverage priority.
• Does not support any optional attributes.

Coverage term value provider

The coverage term value provider, CovTermValueProvider:
• Extends abstract AbstractProductModelValueProvider class.
• Provides a list of coverage terms for specific policy line coverage.
• Returns a list of coverage term codes sorted by priority.
• Supports one optional argument: coverage code.
• Use for rate table columns satisfying one of the following conditions:
◦ A rate table column depends on another column that contains coverage code.
◦ An argument is specified for this value provider.

Coverage term option value provider

The coverage term option value provider, CovTermOptionValueProvider:
• Extends the abstract AbstractProductModelValueProvider class indirectly through the
AbstractCovTermOptionValueProvider class.
• Provides a list of coverage term options for a specific coverage term of a specific coverage.
• Returns a list of coverage term option codes sorted by priority.
• Supports two optional parameters: coverage code and coverage term code
• Works with either none or both parameters.
• Use for rate table columns satisfying one of the following conditions:
◦ A rate table column depends on another rate table column that contains coverage term code.
◦ Both arguments are specified for this value provider.

Termless coverage value provider

The termless coverage value provider, TermlessCoverageValueProvider:
• Is similar to CoverageValueProvider but returns only those coverages that have no terms.
644 chapter 49: Configuring Rating Management
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Reference factor value provider

The reference factor value provider:
• Is implemented in the ReferenceFactorValueProvider class.
• Retrieves all distinct values used in a column of a rate table (source rate table).
• Must have two arguments configured:
◦ Rate table code – Code of a source rate table.
◦ Column name – Name of the column in the source rate table
• Returns a list of distinct values from a specific column (second argument) of the source rate table (first
argument).
• Does not return any specific labels, just the values themselves.
• Implements internal cache (a hash map): (argument 1 + argument 2) -> ({set of values}).
◦ Initialized when a value provider is constructed.
◦ Populated for each combination of argument values on each call to
ReferenceFactorValueProvider#getValues() method for those combinations of arguments that are not
found in the cache.
• The lookup of the source rate table is done in the same rate book as the table specifying this value provider.

Creating a new value provider

If none of the default value providers is appropriate, you can configure a new custom value provider.
You create new value providers by extending the RateTableCellValueProvider abstract class. Create new value
providers in the [Link] package. The user interface has the following restriction: the
package is hard-coded and does not display in the rate table definition user interface.
Performance considerations have to be taken into account when creating new value providers. Values may be
retrieved from value providers multiple times when the Rate Table Editor screen loads. Therefore, caching responses
that the value provider gets from certain sources may improve performance of the user interface. For an example of
caching in value providers, see any of the product model value providers.
For the new value provider to appear in the list of custom value providers in the Rate Table Definition Editor, you must
add a new typecode to the ValueProvider typelist. The Code of the added typecode must be the same as the name
of the value provider Gosu class.

Configuring matching rule operations

In a rate table, you define a matching rule for each parameter. You set the matching rule to one of the match
operations defined in the application.
If none of the default match operations is appropriate, you can configure a new custom match operation.

See also
• Application Guide

Configure a new match operation

About this task
To configure a new match operation:

Procedure
1. In Product Designer, navigate to the rtm_matchop_defs.xml system table.
Configuring Rating Management 645
Guidewire PolicyCenter 9.0.9 Configuration Guide

2. In RateTableMatchOpDefinition, add an entry to the system table. You must specify the following:
• OpCode – A code that uniquely identifies this match operation.
• OpName – Appears in PolicyCenter as a match operation choice when the user clicks Add in the Parameters
tab of the Rate Table Definition Editor screen.
• NumberOfParameters – The number of parameters.
• ImplClass – The fully qualified name of the new match operation factory class. For example, you can define
the class as [Link].
3. Create the following new classes:
• A factory class that extends abstract [Link]. See “Extending
the match operation factory class” on page 646.
• A class that extends abstract [Link]. See “Match operation
implementation” on page 646.
4. Optionally, create a custom validator for the match operation.
• A class that extends [Link]. See “Match operation validator” on
page 647.

Extending the match operation factory class

The match operation factory class, MatchOperationFactory, is an abstract base class that provides a static method
to get match operation factory by name: getFactoryByName(String). You must create a class that extends
[Link]. For an example, see
[Link].
Your new match operation factory implementation must implement at least the following two methods.

Method That Creates a Stateless Match Operator

This method signature is:
function createStatelessMatchOperator([Link]): <S extends StatelessMatchOperator>

This method must create and return a new instance of the match operation implementation class as described in
“Match operation implementation” on page 646.

Method That Creates a Validator

This method signature is:
function createValidator():MatchOpValidator

This method must create and return a new instance of the match operation validator class as described in “Match
operation validator” on page 647.

Match operation implementation

You must create a class that extends abstract [Link]. For an example,
see [Link].
The match operation implementation constructor accepts the following argument:
• An instance of RateTableMatchOp entity. This instance is part of the rate table definition.
Your new match operation implementation can provide implementations of methods from the base class, including
the following methods.

Filter That Evaluates Row Under Consideration

This filter method signature is:
function filter(List<OrderedPersistenceAdapter>, Comparable, boolean):List<OrderedPersistenceAdapter>

646 chapter 49: Configuring Rating Management

 Guidewire PolicyCenter 9.0.9 Configuration Guide

This in-memory filter evaluates all rows still under consideration, and returns only those rows which satisfy the
conditions for the match operation. This filter is only called when the match operation is active. A corresponding
relax method is not needed, because the list of results to be filtered are pre-partitioned according to whether the row
would match a filter or a relax. The input results must be fully ordered and stay that way upon output. For more
information about relaxing, see also the Application Guide.
A stateless match operation doing in-memory filtering expects its input to be in ascending order with respect to the
field or fields being matched by the match operation. For example, a range match operation matches the fields int1
(minimum) and int2 (maximum. This operation assumes that the rows are ordered according to increasing int1
value, with a tie being broken by comparing the int2 values.
The output of the stateless match operation must be a list that is properly formatted for the next match operation.
Therefore, the output must be in ascending order according to the field or fields matched by that next match
operation.
To meet this requirement, PolicyCenter sorts the rate table when it is first loaded, using order by/then by sorting.
The rate table is sorted by the first match operation’s columns. Then each region with equal values for the first
match operation is sorted for the second match operation’s columns, and so on. A match operation controls how its
rows are ordered by overriding the method:
compareRowValues(a : Comparable, b : Comparable) : int

If a match operation does not naturally produce correctly-ordered output from this form of input, it needs to reorder
the rows as part of its filtering process. For most match operations, an easy way to do this is to override the property
needsSubrangeMerge so that it returns true. The StatelessLessThanOrEqualMatch provides an example of this.

Filter That Adds a Constraint to the Database Query

This filter method signature is:
function filter(Query<KeyableBean>, Comparable<Object>)

Adds a constraint to the database query and returns the adjusted query.
Entity instances that are passed into the above functions represent rate factor entities such as RateFactorRow,
CoverageRateFactor, or any other custom entity.

Method Which Computes a Score

This method signature is:
function getScore(OrderedPersistenceAdapter, Comparable) : Comparable)

Used to compute a score for the input argument, Comparable, in relation to rate table row value,
OrderedPersistenceAdapter. This score is used during rate table matching to determine the best match.

Match operation validator

The match operation validator validates the parameter inputs to the match operation. To implement a validator, you
must create a class that extends abstract MatchOpValidator in the [Link] package. For an
example validator, see RangeMatchOpMaxInclValidator class in the [Link] package.
Note: If the match operation does not require a custom validator, you can use the NoOpValidator
when creating the MatchOperationFactory for the new match operation. For an example, see
ExactMatchOpFactory in the [Link] package.
A new match operation validator must implement the following methods.

Validate Method
This method signature is:
function validate(List<Comparable>) : boolean

Configuring Rating Management 647

Guidewire PolicyCenter 9.0.9 Configuration Guide

Returns true if all values are valid from the point of view of this match operation. For example, an exact match
accepts any value, so it always returns true. See Optionally, create a custom validator for the match operation. in
“Configure a new match operation” on page 645.
A range match operation accepts a list of two values where either value can be null or the first value is less then the
second value. Otherwise, return false.

Validate Pair Method

This method signature is:

function validatePair(List<Comparable>, List<Comparable>) : boolean

Validates two sets of values against each other and returns true if both sets are valid with regards to each other.
This method is mainly used to identify overlaps and other value conflicts. For example, for the range match
operation validator, this function checks if two numeric (or date) ranges have no overlap.

Configuring rate book matching

When selecting the most appropriate rate book, if an exact match is not found, PolicyCenter relaxes the optional
attributes by looking for null in the optional attributes. The relaxing rules build an ordered list of rate books by
relaxing the optional attributes.
The main entry point for rate book matching code is the RatingQueryFacade Gosu class. Some of the methods and
objects that this class provides are:
• The matchers method finds the most appropriate rate book.
• The matchersForHierarchy method defines the cascading hierarchy for rate book matching when a rate table or
rate routine is not found in the most appropriate rate book. Cascaded lookup must be enabled.
• Query for a rate book based on values in a RateBookQueryFilter. Uses the RateBookQueryFilter class.
• Query for a factor in the requested table based on RateQueryParam values. Uses the RateBookQueryParam class.
You can change the rate book matching logic by editing the RatingQueryFacade class and the associated
RateBookMatcher, RateBookQueryParam, and RateBookQueryFilter classes.

See also

• Application Guide

Configuring rate routines

Rate routines implement rating algorithms that calculate the properties on the cost for coverages, taxes, and other
costs on a policy. This topic describes how to configure rate routines.

Configuring the rating engine to execute the rate routine

You can add a rate routine in the PolicyCenter Rate Routines screen. However, that rate routine is not part of rating a
policy until you configure the rating engine to execute the rate routine.
In Rating Management, the built-in rating plugin implementation is PCRatingPlugin. This class implements rating
only for the personal auto and commercial property lines of business. The sample data in the default configuration
contains rate routines for these lines of business. The rate routines provided in the default configuration are already
configured in the rating engine.
This topic describes how to extend the PCRatingPlugin class to execute new rate routines that you add.
648 chapter 49: Configuring Rating Management
 Guidewire PolicyCenter 9.0.9 Configuration Guide

See also
• The Integration Guide for instructions on how to enable the PCRatingPlugin plugin and extend it to other lines
of business.
• Application Guide

Extend the rating engine to execute new rate routines

About this task
If you add new rate routines in PolicyCenter, you must extend the rating engine for the line of business specified in
the rate routine. The PCRatingPlugin class calls the rating engine for each line of business. In the base
configuration, the rating engine classes that use rating management are PARatingEngine and CPRatingEngine.

IMPORTANT When adding code that executes a rate routine, be aware that simply executing a rate
routine consumes both time and resources, whether or not the rate routine performs any actions.
Therefore, only execute the rate routine when necessary. For example if a rate routine applies to a
specific coverage on a policy, then make sure your code executes the rate routine only when the policy
contains that coverage. The executeCalcRoutine method executes the rate routine.

To extend the rating engine to execute new rate routines:

Procedure
1. In the rating engine, add code that calls the [Link] method. For example, to execute
a new rate routine in personal auto, modify the PARatingEngine class in the [Link] package.
The method signature for executeCalcRoutine method is:
function executeCalcRoutine(code : String, costData : CostData<Cost, PolicyLine>,
worksheetContainer : WorksheetEntryContainer,
paramSet : Map<CalcRoutineParamName,Object>)

The arguments are:

• code – The rate routine code that uniquely identifies the rate routine, as a String.
• costData – The cost data object which contains properties you can use to calculate a rate, as a CostData.
• worksheetContainer – Holds information for rating worksheets. Rating worksheets describe the series of
calculations to generate a rate, as a WorksheetEntryContainer. For more information, see the Application
Guide.
• paramSet – A map representing the parameters in the parameter set for the rate routine, as a
[Link].
2. If the rate routines does not calculate properties on the cost, set the costData parameter to null and the
worksheetContainer to a NoCostWorksheetContainer.
For example, the following code in [Link] executes the pa_assign_driver_style1_rr rate
routine:
[Link]("pa_assign_driver_style1_rr", null,
new NoCostWorksheetContainer(), assignDriverParameterMap)

The PARatingEngine class is in the [Link] package. The NoCostWorksheetContainer stores

data about what the rate routine executed. However, the default implementation of rating worksheets does not
save this information to the database nor display it on the Rating Worksheet screen.
The PARatingEngine class is in the [Link] package. The NoCostWorksheetContainer stores
data about what the rate routine executed. However, the default implementation of rating worksheets does not
save this information to the database nor display it on the Rating Worksheet screen.

See also
• Application Guide
Configuring Rating Management 649
Guidewire PolicyCenter 9.0.9 Configuration Guide

Example of how the rating engine executes the rate routine

The sample data for the personal auto line of business contains a PA Vehicle Coverage Premium Algorithm rate routine.
This rate routine provides a cost for vehicle level coverages on the policy. The code for this rate routine is
pa_veh_cov_premium_rr.
The PCRatingPlugin class calls the PARatingEngine class to rate a personal auto policy. The PARatingEngine
class is in the [Link] package.
In the PARatingEngine class, the rateVehicleCoverage method rates vehicle-specific coverages such as a
coverage with the PALiabilityCov code. If the policy has this coverage, the code executes the
pa_veh_cov_premium_rr rate routine.

Adding a new rate routine function

A rate routine function is a predefined function that you can include in a rate routine step. Rate routine functions are
defined in Gosu classes. You can define your own functions by adding a Gosu method to these classes. The function
can return a value of any type. Functions with a return value appear in the Operand column of a rate routine step.
Void functions appear in the Instruction column. Void functions do not return a value. An example of a void function
is logAmount.
The SharedRatingFunctions class in the [Link] package contains rating functions for use across
product lines.
For line-specific functions, create a class that extends the class RatingFunctionSource. By extending this class,
PolicyCenter calls your rate routine function class. Functions in this class appear on the policy lines specified in the
availableForLine method. This method takes a policy line code String and returns true if the class supports that
policy line. This class must implement the availableForLine method.
For example, the PARatingFunctions class in the [Link] package implements rate routine functions
only for the personal auto line.
A rate routine function cannot be a parameterized method. If you define a rate routine function as a parameterized
method, it does not appear in the list of functions on the Select a Function screen. PolicyCenter sends a warning to the
log file. For more information about parameterized methods, see the Gosu Reference Guide.

See also
• “Logging rate routine functions in a rating worksheet” on page 662

Configuring rounding operators

In the default configuration, you can use the following rounding operators in a rate routine:
• R – Round half up. Round towards the nearest number according to scale. If both numbers are equidistant, round
away from 0.
• RD – Round down. Round down to the nearest number according to scale. Always round towards 0.
• RU – Round up. Round up to the nearest number according to scale. Always round away from 0.
• RE – Round half-even. Round towards the nearest number according to scale, unless both numbers are
equidistant. If equidistant, round towards the even number.
Through configuration, you can make the following optional rounding operators available in rate routines:
• RC – Round ceiling. Round up to positive infinity.
• RF – Round floor. Round down to negative infinity.
• HD – Round half-down. Round towards nearest number according to scale, unless both numbers are equidistant.
If equidistant, round towards 0.
• NR – Unnecessary. The requested operation is expected to produce an exact result. Throws an exception if
rounding is necessary.
650 chapter 49: Configuring Rating Management
 Guidewire PolicyCenter 9.0.9 Configuration Guide

See also
• Application Guide

Make optional rounding operators available in rate routines

About this task
This topic describes how to configure PolicyCenter to make the optional rounding operators available for use in rate
routine steps. In the default configuration, PolicyCenter the optional rounding operators, RC, RF, HD, and NR, are not
available.
In Studio, the rounding operators are in the rounding category. Optional rounding operators are in the optrounding
category. This topic describes how to make the RF optional rounding operator defined by the floor typecode
available.

Procedure
1. In Studio, open the [Link] typelist. The Typelist tab lists the typecodes in the typelist.
2. Click the Outgoing Categories tab.
3. Expand the optrounding category.
This category contains the optional rounding operators. The floor operator is in this category.
4. Return to the Typelist tab.
5. In the Element hierarchy, expand the floor typecode to reveal the category contained within.
For the floor operator, the category value is optrounding.
6. In the Element hierarchy, click category in the floor typecode.
7. Change Value of the code to rounding.
8. Click the Categories tab to verify that floor now appears in the rounding category.

Configure prefixes that identify types in rate routine steps

About this task
For some instruction and operand types, you can add or change the prefix that appears in the rate routine step. For
example, in the default configuration, table: precedes the name of the rate table in a step. When changing the prefix,
be aware that the prefix takes up space in the rate routine step.
In the default configuration, Studio includes display keys for prefixes on properties on the cost, function, rate table,
and variable types.
To change the type prefix for properties on the cost, functions, rate tables, and variables:

Procedure
1. In Studio, localize the display key as described in .
For each type, the following table contains the name of the display key, the default prefix, alternate prefix, and
the unicode value of the alternate prefix. The alternate prefix is provided as a suggestion only. You can define
the prefix to a string of your choice. You can enter the unicode character directly into the Studio editor.

Instruction and op‐ Display key Default Alternate Unicode value

erand type prefix prefix of alternate
Properties on the [Link] None
cost
Function [Link] None ∫ \u222B

Rate table [Link] table: \u229E

Configuring Rating Management 651

Guidewire PolicyCenter 9.0.9 Configuration Guide

Instruction and op‐ Display key Default Alternate Unicode value

erand type prefix prefix of alternate
Variable [Link] None v:

If you add a variable prefix, the prefix appears for user defined variables and multiple factor variables.
2. In PolicyCenter, navigate to a rate routine to view the new prefix.

See also

• “Using the display keys editor” on page 157

• Application Guide

Configuring variant identifiers for a rate routine

A rate routine can have variant rate routines. The rate routine and its variant rate routines have the same code. In the
default configuration, the jurisdiction variant is an example of a variant identifier. Through configuration, you can
extend or change the definition of variants to have other identifiers. For example, you can configure a variant
identifier to other features of the policy such as the underwriting company. Through configuration, you can remove
the jurisdiction variant. For more information, see the Application Guide.
This topic describes how to configure a variant identifier for a rate routine.

Add the variant identifier to the data model

Procedure

1. In Studio, add a column with the name of the variant identifier to [Link] and include
the name in the index. For detailed instructions, see “Extending a base configuration entity” on page 242.
For example, add a column for the variant identifier named NewVariantIdentifier defined as follows:

Name Value
name NewVariantIdentifier

type shorttext

nullok true

desc A new variant identifier

localization a_table_name

2. Add a NewVariantIdentifier index to CalcRoutineDefinition defined as follows:

Name Value
name NewVariantIdentifier

keyposition 4

3. Change the Retired index keyposition from 4 to 5. The NewVariantIdentifier index is inserted before
Retired.

Next steps

Now you can go to the next step, “Add the rate routine variant identifier to PCF files” on page 653.

652 chapter 49: Configuring Rating Management

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Add the rate routine variant identifier to the rate routine plugin
Before you begin
Before you begin, you must complete “Add the variant identifier to the data model” on page 652.

About this task

The built-in implementation of the rate routine plugin (IRateRoutinePlugin) is [Link] in the
[Link] package. The getter for the BranchingFields property returns an ordered list of zero or more
variant identifiers.

Procedure
In the implementation of the rate routine plugin, add the name of the variant identifier to the fields variable of the
getter for the BranchingFields property.
For example, add NewVariantIdentifier to the fields variable as follows:
override property get BranchingFields() : IEntityPropertyInfo[] {
var fields : ArrayList<String> = {"Jurisdiction", "NewVariantIdentifier"}
...
}

Next steps
Now you can go to the next step, “Add the rate routine variant identifier to PCF files” on page 653.

Add the rate routine variant identifier to PCF files

Before you begin
Before you begin, you must complete “Add the rate routine variant identifier to the rate routine plugin” on page 653.

About this task

In Studio, add the rate routine variant identifier to the following PCF files.

Procedure
1. Add New Variant Identifier to the Rate Routine Details and New Rate Routine screens.
a. Add a [Link] display key and set the value to New
Variant. You can add the display key by adding it to the display_languageCode.properties file in
configuration→config→Localizations.
b. In [Link], add a basic input after the Jurisdiction input. For example, from the Toolbox,
go to Basic Inputs and insert an Input with the following properties:

Property Value Description

editable canEditIdentifyingFields or copyVersionType == BRANCH Whether the input is editable.
id NewVariantIdentifier A unique identifier for this widget.
label [Link] The input label.

value [Link] Set value to the

NewVariantIdentifer property on
the CalcRoutineDefinition entity
instance.

2. On the Rate Routine Details screen, change the name of the Create Jurisdiction Variant button to something more
descriptive such as Create Variant Rate Routines. This button will now create variants where you can set
Jurisdiction and New Variant.
Configuring Rating Management 653
Guidewire PolicyCenter 9.0.9 Configuration Guide

3. Add a New Variant column in the Search Results on the Rate Routines screen.
In [Link], add a basic cell just after the Jurisdiction cell. For example, go to Basic
Cells and insert a Cell with the following properties:

Property Value Description

id RateroutineNewVariantIdentifier A unique identifier for this cell.
label [Link] The cell label.

value [Link] Set value to the NewVariantIdentifier

property on the
CalcRoutineDefinition entity instance.

4. On the Rate Book Details screen, add New Variant to the Included Rate Routines tab.
In [Link], add a TextCell just after Jurisdiction with the following properties:

Property Value Description

id NewVariantIdentifier A unique identifier for this cell.
label [Link] The cell label.

value [Link] The cell value.

5. Add New Variant to other rate routine screens where the Jurisdiction variant appears.

See also
• “Rate routine plugin methods” on page 666
• Application Guide

Configuring the rate routine plugin

When PolicyCenter executes a rate routine, PolicyCenter calls the rate routine plugin defined by the
IRateRoutinePlugin interface. The rate routine plugin:
• Enables rating worksheets in the plugin.
• Sets up cost data wrappers that determine which properties on the cost appear when you select an instruction or
operand in a rate routine step.
For more information, see “Rate routine plugin” on page 665.

Using Gosu to get the rate factor from the rate table
You can get the rate factor from a rate table in a rate routine. In certain circumstances however, getting the rate
factor may involve more complex logic than rate routines support. This topic describes how to get the rate factor
from the rate table using Gosu code. You might add this code in the rating engine or in a rate routine function.
This topic provides an example of how to accomplish this using workers’ compensation as an example.

Create a class for getting the rate factor

Procedure
Create a class to contain methods that get the rate factors from all rate tables in this line of business. For workers’
compensation, you can define a [Link] class in the [Link] package.

Next steps
You can now move to the next step “Define a method to get the rate factor” on page 655.
654 chapter 49: Configuring Rating Management
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Define a method to get the rate factor

Before you begin
Before you begin, you must complete “Create a class for getting the rate factor” on page 654.

About this task

Follow these steps to define a getFactor method that gets the rate factor from a rate table. This method is general
purpose and is not specific to a particular line of business. If you are adding Rating Management to multiple lines of
business, you could choose to put this method in its own class.

Procedure
1. In the public method for the class, add private variables for storing the policy period and rate book status.
class WCRateFactorSearch {

private var _period : PolicyPeriod as readonly Period

private var _minRatingLevel : RateBookStatus as MinimumRatingLevel

construct() {

2. Insert uses statements after the package statement at the top of the file. The method that you define in the
following steps uses these classes.
package [Link]

uses [Link]
uses [Link]
uses [Link]
uses [Link]
uses [Link]
uses [Link]
uses [Link]

class WCRateFactorSearch {

3. After the class constructor, add the getFactor method that gets the rate factor.
construct() {

}
private function getFactor<Q extends Comparable>(jurisdiction : Jurisdiction,
inputParams : List<RateQueryParam<Q>>,
tableCode : String,
ratingDate : Date) : BigDecimal
{
/* Constructs a new rateBookQueryFilter object and sets properties such as Jurisdiction */
/* and UWCompany. */
var filter = new RateBookQueryFilter(ratingDate, [Link],
[Link])
{:Jurisdiction = jurisdiction,
:UWCompany = [Link],
:Offering = [Link],
:MinimumRatingLevel = MinimumRatingLevel,
:RenewalJob = [Link] typeis RenewalProcess
}
var result = new RatingQueryFacade().getFactor<Q, BigDecimal>(filter, tableCode, inputParams)
return ![Link] ? [Link] : [Link]
}

The input parameters to the getFactor method are:

• jurisdiction – The jurisdiction of the policy location.
• inputParams – Specify values for each parameter in the rate table.
• tableCode – The code of the rate table from which to obtain the rate factor. This is the TableCode property
on the RateTableDefinition object. In the user interface, tableCode is the Code on the Basics tab of the
Rate Table Definition screen.
Configuring Rating Management 655
Guidewire PolicyCenter 9.0.9 Configuration Guide

• ratingDate – The date for which to obtain rates. The date is compared against the
[Link] or [Link] properties depending upon the job type.
In the user interface, ratingDate is the Policy Effective or Coverage Reference Date or Renewal Effective Date in
Policy Criteria on the Rate Book Details screen.
This method return the rate factor as a BigDecimal. If no rate factor is found, the method return the value 1.

Next steps

Now you can go to the next step, “Define methods that get the rate factor” on page 656.

Define methods that get the rate factor

Before you begin

Before you begin, you must complete “Define a method to get the rate factor” on page 655.

About this task

In this series of steps, you define a method that gets the rate factor. The rate factor is used to calculate rates for
ratable objects such as coverables. Repeat these steps to define a method for each ratable object. This example gets
the rate factor for a workers’ compensation class code.

Procedure

1. If you must get the jurisdiction from a policy location, add a uses statement at the top of the file after the
package name.
The method that gets the jurisdiction for a particular ratable object uses methods in this class.
uses [Link]

2. In the public method for the class, add a private variable for storing the code of the rate table. The code is
passed to the getFactor method in the tableCode parameter.
class WCRateFactorSearch {

private var WC7_CLASS_CODE_TABLE = "WorkersComp_ClassCode_Rate"

The private variable is not strictly necessary. Instead of using this private variable, you could pass the
tableCode parameter directly in the call to the getFactor method.
3. Add a method that gets the rate factor for a particular ratable object. This method calls the getFactor method.
Name the method appropriately for the type of ratable object.
In this example, the method is getClassCodeRate. This method gets the rate for a covered employee’s class
code from the rate table.
function getClassCodeRate(covEmp : WCCoveredEmployee, ratingDate : Date) : BigDecimal {
var jurisdiction
[Link]([Link])
var params = {
new RateQueryParam<String>("CLASSCODE", [Link])
}
return getFactor(jurisdiction, params, WC7_CLASS_CODE_TABLE, ratingDate)
}

The input parameters to this method vary depending upon the ratable object. The input parameters to the
getClassCodeRate method are:
• covEmp – The WCCoveredEmployee object from which to get the class code.
• ratingDate – The date for which to get the rate.
This method returns the rate factor as a BigDecimal.
656 chapter 49: Configuring Rating Management
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Configuring new parameters in parameter sets

This topic describes how to create a new parameter and make the parameter available for inclusion in a parameter
set. The new parameter is available in PolicyCenter, and you can insert the new parameter in rate routine steps. For
example, in Administration→Rating→Parameter Sets, select a parameter set. In the Parameters panel, click Edit. To add a
new parameter, click Add. In the Name column, drop-down list contains the list of parameters. This topic describes
how to add a parameter to the list.
In PolicyCenter, parameter sets are associated with rate routines and rate table definitions. In addition, you must add
the parameter to the rating engine code so that the parameter can be used in rating.
To configure a parameter:
• In the PolicyCenter user interface, create the parameter for inclusion in a parameter set. Define the
parameter and specify a default type, such as [Link] for a personal vehicle entity. Then you
can include the parameter in a parameter set. In the parameter set, you can override the parameter’s default type.
Each rate routine that uses that parameter set can access that parameter in the rate routine steps.
For instructions, see “Creating a new parameter for inclusion in parameter sets” on page 657.
• In Studio, modify the rating engine so that it rates the object or entity instance that the parameter
specifies. For each rate routine that includes the parameter set, add a mapping from the parameter to an object
type. The object type could be the primary vehicle on a personal auto policy. When the rating engine executes the
rate routine, the parameter is used to reference the actual run-time instance or value. The run-time instance could
be the primary vehicle on Solomon’s personal auto policy.
For instructions, see “Adding a new parameter to the rating engine” on page 658.
• If the parameter uses a wrapper, create the wrapper code.
For instructions, see “Configuring new wrappers for parameter sets” on page 659.
The parameter definitions must meet the following criteria:
• Parameter types must be compatible. In the parameter set, the parameter’s type must be compatible with the
Gosu object that the rating engine passes to the method that executes the rate routine. If the user overrides the
parameter’s default type in the parameter set, the override takes precedence. The rating engine must pass an
object that is the same type or a subtype of the parameter type. PolicyCenter throws an exception if the rating
engine passes in an object that is not compatible with the parameter associated with the executing rate routine.
• In the rating engine, the parameter map must be a superset of the rate routine parameters. When the rating
engine executes a rate routine, one of the arguments is a map of the rate routine’s parameters. In the rate routine
parameter map, each parameter is mapped to an object or entity instance, such as a vehicle on Solomon’s policy.
The rate routine parameter map must contain all of the names in the parameter set defined in PolicyCenter for the
rate routine being executed. The parameter set may contain the names of additional parameters. The rating engine
throws an exception if it executes a rate routine and the parameter map is missing any parameters in the
parameter set.

See also
• “Adding a new parameter to the rating engine” on page 658
• Application Guide

Creating a new parameter for inclusion in parameter sets

These instructions describe how to create a new parameter for inclusion in parameter sets and accessible in rate
routines in the PolicyCenter user interface. To create a new parameter, you must complete the following instructions.

Add the parameter to the parameter name typelist for rate routines
About this task
Create a new typekey for the parameter. In a parameter set, the parameter Name appears in the Name column on the
Parameter Sets→Parameters tab in PolicyCenter.
Configuring Rating Management 657
Guidewire PolicyCenter 9.0.9 Configuration Guide

Procedure
1. In Studio, open [Link] in configuration→config→Metadata→Typelist.
2. Click typelist at the top of the Element hierarchy.

3. Click the drop-down list next to and choose typecode. This adds a typecode for the new parameter to this
typelist. For example, you can add a PATest parameter defined as follows:

code name desc

patest PATest Personal Auto Test

Next steps
You can now move to the next step, “Enter the default type for the parameter” on page 658.

Enter the default type for the parameter

Before you begin
Before you begin, you must complete “Add the parameter to the parameter name typelist for rate routines” on
page 657.

About this task

Enter the default type which appears in the Type column on the Rating→Parameter Sets→Parameters tab in
PolicyCenter. If you do not specify a default type, the Type column is blank.

Procedure
1. In Studio, open [Link] in the [Link] package.
2. In the mapFromCodeToType static variable, enter a mapping for the code of the new parameter.
Enter the code in capital letters prefixed by CalcRoutineParamName.TC_. Enter the default type as the fully
qualified object type. For example:
CalcRoutineParamName.TC_PATEST -> "[Link]"

Next steps
Now you can move to the next step, “Include the parameter in a parameter set in PolicyCenter” on page 658.

Include the parameter in a parameter set in PolicyCenter

Before you begin
Before you begin, you must complete “Enter the default type for the parameter” on page 658.

Procedure
In the PolicyCenter user interface, include the parameter in one or more parameter sets.
When you add the parameter, you can override the default type. Keep in mind that the object the rating engine
passes must be compatible with the type of object that rate routine expects. For instructions and more information,
see the Application Guide.

Adding a new parameter to the rating engine

These instructions describe how to add a new parameter to the rating engine. When the rating engine runs a rate
routine, the rating engine maps each parameter to an object or entity instance. The map is of type [Link].
The rating engine uses this map to pass run-time objects and entity instances to the method that executes the rate
658 chapter 49: Configuring Rating Management
 Guidewire PolicyCenter 9.0.9 Configuration Guide

routine. This object or entity instance must be compatible with the type specified in the parameter set associated
with the rate routine being executed. A compatible type is the same type or a subtype. If the object or entity instance
is not compatible, then PolicyCenter throws an exception.
Note: For instructions on how to add a new parameter for use in PolicyCenter, see “Configuring new
parameters in parameter sets” on page 657.
In these steps, you include the new parameter in Gosu code that executes each rate routine associated with this
parameter set.
The rating engine code executes each rate routine by calling the [Link] method. One of
the parameters to this method is a map of parameters that the rate routine uses. This map must be a superset of the
parameter set in PolicyCenter. By definition, a superset contains at least all of a set.

Include the parameter in the rating engine code

About this task
For each rate routine associated with the new parameter’s parameter set, you must add the new parameter to the
map. The parameter map is in the rating engine class in Studio.

Procedure
1. In Studio, open the rating engine class for the line of business that uses this parameter. For example, open
[Link] if this parameter is for the personal auto line. The PARatingEngine class is in the
[Link] package.
2. Modify the executeCalcRoutine method call for each rate routine associated with a parameter set that
includes this parameter.
The following example assumes that you added a parameter to the PIP NJ Parameter Set parameter set. The rate
routine with the pa_pip_nj_basic_rr code uses this parameter set.
The code that executes this rate routine is:
[Link]("pa_pip_nj_basic_rr",
:costData = data,
:worksheetContainer = data,
rateRoutineParameterMap)

The rateRoutineParameterMap argument is a map defined as:

var rateRoutineParameterMap : Map<CalcRoutineParamName, Object> =
{TC_POLICYLINE ->_line,
TC_VEHICLE ->vehicle,
TC_PAPIPNJ ->cov}

In the map, the Object must be compatible with the type for the parameter set being used by the executing
rate routine. You specify the type in the Type column on the Parameter Sets→Parameters tab in the PolicyCenter
user interface.
In the map, the Object must be compatible with the type for the parameter set being used by the executing
rate routine. You specify the type in the Type column on the Parameter Sets → Parameters tab in the PolicyCenter
user interface.
3. In the rateRoutineParameterMap variable, add a map entry for your new parameter.
4. Start or restart PolicyCenter to view your changes.

Configuring new wrappers for parameter sets

You may have parameters sets that are essentially the same, but each line of business uses a different coverage, for
example. Using wrappers, you can combine these parameters sets into one parameter set that uses a wrapper to
select the coverage by line of business.
The wrapper calls Gosu code that selects a coverage based upon characteristic of the policy. You must first create the
wrapper before you use it in a parameter set.
Configuring Rating Management 659
Guidewire PolicyCenter 9.0.9 Configuration Guide

In Studio, create a new Gosu class the implements [Link]. For an example, see
[Link] in the [Link] package.

See also
• Application Guide

Example with Wrappers

In the base configuration, the CP Coverage Parameter Set With Wrapped Coverages parameter set
(CPCoverageWrapperParamSet) uses a wrapper. The Coverage parameter uses the wrapper
[Link] to select either the Business Personal Property Coverage (CPBPPCov) or the
Building Coverage (CPBldgCov). In Product Designer, you can view these coverages in the Commercial Property Line.
The CP Coverage Premium Algorithm rate routine (cp_cov_premium_rr) uses the CP Coverage Parameter Set With Wrapped
Coverages parameter set. In this rate routine, the Basis is assigned the value of [Link]. The wrapper
calculates the value of the limit based upon whether the coverage is Business Personal Property Coverage or Building
Coverage.

Configuring rating worksheets

In the default configuration, rating worksheets are configured for the personal auto and commercial property lines of
business. To configure rating worksheets for other lines of business, you must do the following:
• Configure rating worksheets in the rate routine plugin – For more information, see “Enabling rating
worksheets in the rate routine plugin” on page 666.
• Configure the user interface – Implement the getWorksheetRootNode method in the policy-line-methods class
for the line of business. This method controls how the worksheets are organized in the user interface. See
[Link] class as an example. In this example, the code that traverses the cost version list is
similar to the code that displays the costs in the Policy Premium tab of the Quote screen.
The user must have the View rating worksheet permission to view a rating worksheet. The code for this permission is
ratingworksheetview.

See also
• Application Guide

Configuring extract and purge rating worksheets

Every time a user generates a rating worksheet, a copy of that rating worksheet gets stored in the PolicyCenter
database. To improve PolicyCenter performance, PolicyCenter provides processes for extracting rating worksheet
data and removing rating worksheet containers from the database. This is not an end user feature and is only
accessible through Server Tools. The Extract Worksheets batch process extracts the rating worksheet data to files and
marks worksheet containers for purging. The Purge Rating Worksheets batch process removes the worksheet
containers from the database. You must enable this batch process.
This topic describes how to configure these two batch processes and the associated plugins.

See also
• Application Guide

Extract Rating Worksheets batch process

Code – extractworksheets
The Extract Rating Worksheets batch process extracts rating worksheet data from worksheet container
(WorksheetContainer) objects to files in a specified directory on the batch server. The batch process also marks
WorksheetContainer objects for purging.
660 chapter 49: Configuring Rating Management
 Guidewire PolicyCenter 9.0.9 Configuration Guide

In the base configuration, this batch process is not scheduled to run on a regular basis. You can run it manually or
schedule it.
In the base configuration, the batch process extracts worksheet data to files to an extracted_worksheets directory
off the file system root. Extract Rating Worksheets processes WorksheetContainer objects attached to a Policy on
which all jobs are closed. Closed jobs have a non-null [Link]. The batch process does not process
WorksheetContainer objects that have already been extracted.
In Studio, you can change the extract destination directory by modifying [Link]. Modify
the value of the WorksheetExtractDestination parameter.
In Studio, you can modify the behavior of the batch process by modifying the worksheet extract plugin. For more
information, see “Worksheet Extract plugin” on page 661.

Purge Rating Worksheet batch process

Code – purgeworksheets
The Purge Rating Worksheets batch process removes worksheet container (WorksheetContainer) objects that meet
both of the following criteria:
• Are marked for purging
• That are on policies whose jobs have been closed more than a specified number of days (90 days in the base
configuration).
In the base configuration, the Extract Rating Worksheets batch process marks the worksheets container objects for
purging.
In the base configuration, this batch process is disabled. After you enable it, you can run it manually or schedule it.
A WorksheetContainer is marked for purging if its CanPurge flag is true.
The RatingWorksheetContainerAgeForPurging parameter in [Link] specifies the minimum number of days
after a job is closed before the WorksheetContainer associated with its policy is eligible for purging.
In Studio, you can modify the behavior of the batch process by modifying the worksheet purge plugin.

See also
• “Worksheet Purge plugin” on page 662

Enable Purge Rating Worksheets batch process

About this task
In the base configuration, the Purge Rating Worksheets batch process is disabled. To enable this batch process, you
must do the following in Studio:

Procedure
1. In [Link], set the PurgeWorksheetsEnabled parameter to true.
2. In [Link], to enable the batch process to run on a regular schedule, uncomment the
ProcessSchedule entry for PurgeWorksheets and modify the schedule to meet your needs.

Worksheet Extract plugin

The WorksheetExtractPlugin plugin interface identifies which rating worksheet to extract and extracts the
worksheet data to files.
PolicyCenter includes a built-in implementation of this plugin interface. See PCWorksheetExtractPlugin in the
[Link] package.

Identifying worksheets to extract

PolicyCenter calls the buildWorksheetCandidatesQuery method to determine which worksheets to extract.
Configuring Rating Management 661
Guidewire PolicyCenter 9.0.9 Configuration Guide

In PCWorksheetExtractPlugin, this method identifies WorksheetContainer objects attached to a Policy on

which all jobs are closed. Closed jobs have a non-null [Link]. The method ignores WorksheetContainer
objects that have already been extracted.

Extracting worksheet data

PolicyCenter calls the extractWorksheets method to extract the worksheet data into a file and flag the worksheet
container for purging.
In PCWorksheetExtractPlugin, the worksheet data is extracted to XML and compressed into Gzip format. The
format of the file name is:
PolicyNumber_TermNumber_JobNumber_BranchPublicID.gz

Can purge extracted worksheets

PolicyCenter calls the isExtracted method. The method returns a value which indicates whether data has been
extracted from a worksheet container.
In PCWorksheetExtractPlugin, this method retrieves the value of the CanPurge Boolean property on the worksheet
container. The CanPurge flag is false by default. This flag is true if:
• Data has been extracted
• There is no data to extract
The Purge Worksheet Containers batch process uses the CanPurge flag.

Worksheet Purge plugin

The WorksheetPurgePlugin plugin interface configures how PolicyCenter purges rating worksheets.
PolicyCenter includes a built-in implementation of this plugin interface. See PCWorksheetPurgePlugin in the
[Link] package.
The buildWorksheetCandidatesQuery method builds the list of worksheet containers that meet the requirements
for the Worksheet Purge batch process to purge.
In PCWorksheetPurgePlugin, the buildWorksheetCandidatesQuery method finds worksheet containers that have
the CanPurge property set to true, and whose jobs were completed more than
RatingWorksheetContainerAgeForPurging days ago. The RatingWorksheetContainerAgeForPurging
parameter is defined in [Link].
PolicyCenter calls the canPurgeWorksheetContainer method to determine if the rating worksheet can be purged.
In the base implementation, this method just returns the value of the CanPurge flag on the WorksheetContainer.
You can include additional logic in this method.

Logging rate routine functions in a rating worksheet

In the default configuration, logging to the rating worksheet occurs automatically for each step in the rate routine.
You can add logging to the rating worksheet for a rate routine function by using methods in the WorksheetLogger
class in the [Link] package.
In the default configuration, the capPremiumByPercent method in the SharedRatingFunctions class provides an
example of how to use the WorksheetLogger methods. The SharedRatingFunctions class in is the
[Link] package.
Note: In the default configuration, the personal auto and commercial property lines of business have
logging for rating worksheets. For information about configuring rating worksheet for other lines of
business, see “Configuring rating worksheets” on page 660.

See also
• “Adding a new rate routine function” on page 650
662 chapter 49: Configuring Rating Management
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Configuring impact testing

This topic describes how to configure impact testing. You can enable impact testing for a line of business and
modify the functionality of impact testing. In addition, there are batch processes associated with impact testing.

See also
• Application Guide

Impact testing warnings and recommendations

Impact testing is designed to work in a test environment on a copy of production data. Impact testing is accessible
only when the server is in development or test mode. Because impact testing affects system performance and creates
test policy periods that persist in the database, impact testing is not accessible in production mode.
When you run impact testing, impact testing creates test policy periods in the database. In the test environment,
observe the following warnings and recommendations:
• The work of users can interfere with impact testing results. During impact testing, Guidewire recommends that
only the single user performing impact testing be logged into PolicyCenter.
• Disable integrations to other systems. If you run impact testing with integrations enabled, the integration can
send test data to these production systems. For example, disable the free-text search integration that uses the
search engine Solr. The same applies to other integrations such as an integration with a billing system. To avoid
unnecessary costs, disable integrations to systems that charge access fees.
• While running impact testing batch processes, do not make changes in PolicyCenter that impact rating such as
doing a policy change, canceling, or changing rate books. For example, the baseline creation batch process or the
test period quote batch process is running. During this time, quoting test periods fails if a user changes or cancels
a policy which has a baseline.
• Do not include expired policies in the impact testing dataset. Specify an In Force On date to filter out expired
policies.
• Impact testing excludes archived policies.
• Stop the Job Expire batch process to prevent PolicyCenter from unexpectedly expiring policies during or between
impact testing runs. To manage batch processes on a test server, press ALT + SHIFT + T to display the Server
Tools page, then select Batch Process Info from the Server Tools tab.

Enabling impact testing for a line of business

In the default configuration, impact testing is enabled for the personal auto and commercial property lines of
business. To enable impact testing for another line of business, you must implement a getter for the Coverable
property in the cost adapter for that line of business. For more information, see “Cost adapter methods” on
page 672.

Rate renewals as renewal jobs in impact testing

About this task
In the default configuration, impact testing rates the baseline and test policy periods for all job types as submission
jobs. You can configure impacting testing to rate a renewal as a renewal job rather than a submission job. For
example, rate routines may include special steps for renewal jobs. Rate tables may contain factors based on job type.
In the default configuration, PolicyCenter prevents a renewal on a policy period which has a open renewal. If you
make this configuration change, PolicyCenter can create a renewal on a policy period which has an open renewal.
Making this configuration change impacts how PolicyCenter handles renewals in impact testing and in other areas of
the product.
To rate renewals and renewal jobs in impact testing, change the IPolicyPlugin in Studio.
Configuring Rating Management 663
Guidewire PolicyCenter 9.0.9 Configuration Guide

Procedure
1. In Studio, open [Link] in configuration→config→Plugins→registry.
2. Change Gosu Class from:
[Link]

to:
[Link]

The ImpactTestingPolicyPlugin plugin extends the PolicyPlugin plugin. The

ImpactTestingPolicyPlugin plugin only contains an override of the canStartRenewal method.

IMPORTANT The ImpactTestingPolicyPlugin plugin is only intended for use in a

development environment where you are performing impact testing. Do not use this plugin in a
production environment. If you enable the ImpactTestingPolicyPlugin plugin, PolicyCenter
allows the creation of a renewal on a policy period with an open renewal. In the default
configuration, PolicyCenter prevents a renewal on a policy period that has an open renewal.
Enabling the ImpactTestingPolicyPlugin changes how PolicyCenter handles renewals in
impact testing and in other areas of the product.

Modifying the functionality of impact testing

In the PolicyCenter default configuration, impact testing creates the test periods by creating policy renewals. You
can customize how impact testing creates the test periods. For example, you may want to create test periods in
another way, such as by copying submissions or spinning off policies. You can also change how to select alternate
rate books in impact testing.
You can make these changes by writing your own implementation of the impact testing plugin interface.

See also
“Impact testing plugin” on page 669

Work queues for impact testing

In Guidewire Rating Management, impact testing uses the following work queues:

Work queue name Code Description

Impact Testing Test ImpactTestingTestPrep This work queue generates baseline policy periods on the selected policies
Case Preparation when you click Create Baselines from the Create Baseline screen.
Impact Testing Test ImpactTestingTestRun This work queue generates test policy periods rated using the selected rate
Case Run books when you click Quote Test Periods from the Testing Periods screen.
Impact Testing Export ImpactTestingExport This work queue exports test periods to an Excel file when you click Create
Excel Export File on the Impact Results screen.

You can access impact testing in PolicyCenter by navigating to Administration→Rating→Impact Testing.

See also
• System Administration Guide

Configuring the impact testing plugin

You can use impact testing to see the impact that changing the rate book has on the policy premium.
The impact testing plugin (IImpactTestingPlugin) generates the baseline and test periods for impact testing. The
plugin also gets and sets the rate books for quoting the test periods.
664 chapter 49: Configuring Rating Management
 Guidewire PolicyCenter 9.0.9 Configuration Guide

The built-in plugin implementation, [Link], creates test periods by

creating policy renewals. You can create your own implementation of this plugin. For example, you may want to
create test periods in another way, such as by copying a submission or spinning off a policy. You can also change
how the alternate rate books are selected.
For more information, see “Impact testing plugin” on page 669.

Configuring rate book export to spreadsheet and XML

On the Rate Book screen, you can export the rate book details and its included rate tables and rate routines to
spreadsheet or XML format. There are several ways in which you can configure export:
• Spreadsheet appearance – You can configure the spreadsheet appearance by modifying [Link] in
the [Link] package.
• Purge downloads – Purge Rate Book Export Result batch processing removes rate books exported to
spreadsheets and XML.

See also
• Application Guide
• System Administration Guide

Rating Management plugins and interfaces

This topic describes plugins related to Guidewire Rating Management features.

Rate routine plugin

PolicyCenter provides the IRateRoutinePlugin to let you modify the processing of rate routines in PolicyCenter.
The default configuration of PolicyCenter uses a built-in implementation of the plugin, [Link].
You can create your own implementation of this plugin. To edit the registry for IRateRoutinePlugin, In Studio,
open [Link] in configuration→config→Plugins→registry.
When PolicyCenter executes a rate routine, PolicyCenter calls the rate routine plugin (IRateRoutinePlugin). The
rate routine plugin:
• Enables rating worksheets in the plugin.
• Sets up cost data wrappers that determine which properties on the cost appear when you select an instruction or
operand in a rate routine step.

See also
• “Configuring rate routines” on page 648
• Application Guide

Rate routine plugin implementation

PolicyCenter includes a built-in implementation of the rate routine plugin. This implementation contains classes for
the personal auto and commercial property lines of business. In Studio, the built-in plugin implementation is
[Link] in the [Link] package. To customize the rate routine plugin logic, you can
create your own implementation of this plugin.
The [Link] passes the processing to line-of-business-specific configuration classes, if a class
exists. The [Link] looks for the line-of-business configuration classes in the [Link] package. To
find these configuration classes, the plugin maps the policy line code to the product abbreviation as follows:
Configuring Rating Management 665
Guidewire PolicyCenter 9.0.9 Configuration Guide

Policy Line Code Product Abbreviation Configuration Class

PersonalAutoLine PA [Link]

CPLine CP [Link]

If the product abbreviation does not fit this mapping, the makeAbbrevMap and makeConfigClassName methods make
adjustments to the mapping. In the [Link], these methods make an adjustment for the business
auto line. If you need to make other adjustments, you must create your own version of the rate routine plugin.
The line-of-business configuration classes implement the IRateRoutineConfig interface.

Enabling rating worksheets in the rate routine plugin

The rate routine plugin has settings that enable the rate routine plugin to generate rating worksheets for a line of
business. If rating worksheets are enabled for a line of business, the Show Rating Worksheet button appears on the
Quote screen.
Enable rating worksheets in the plugin by making the following changes:
• Set the WorksheetsEnabled parameter to true in the IRateRoutinePlugin registry.
• In the [Link] class, modify the worksheetsEnabledForLine override method to return
true.
For example, you can turn on rating worksheets for a line of business by modifying the line-of-business
configuration classes with an override to the worksheetsEnabledForLine method. For example, the following
code in the CPRateRoutineConfig class enables rating worksheets for commercial property:
override function worksheetsEnabledForLine(linePatternCode : String) : boolean {
return true
}

In the RateRoutinePlugin class, the worksheetsEnabledForLine method calls the line-specific

implementation of worksheetsEnabledForLine.

See also
• “Configuring rating worksheets” on page 660 for additional steps to enable rating worksheet
• Application Guide

Cost data in the rate routine plugin

The rate routine plugin contains methods that set up cost data wrappers for the rate routine to use. These wrappers
are used to define which properties on the cost appear when you select an instruction or operand in a rate routine
step. The plugin must implement the getCostDataWrapperType and makeCostDataWrapper methods. In the built-in
implementation, the rate routine plugin simply transfers processing to line-of-business configuration classes, if they
exist.
The makeCostDataWrapper method returns a cost data wrapper for the given cost data. The wrappers in the sample
implementation are:
• CalcRoutineCostData
• CalcRoutineCostDataWithAmountOverride
• CalcRoutineCostDataWithPremiumCap
• CalcRoutineCostDataWithTermOverride
These wrappers are in the [Link] package.

Rate routine plugin methods

The rate routine plugin implementation must contain these methods.
The built-in implementation of the rate routine plugin is [Link] in the [Link]
package.
666 chapter 49: Configuring Rating Management
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Set Parameters
The setParameters method gets the values of the WorksheetsEnabled parameter defined in the plugin registry and
sets the values on internal variables. The value defined in the plugin registry overrides the plugin setting. The
method signature is:
override function setParameters(params : Map<Object, Object>)

Get Cost Data Wrapper Type

The getCostDataWrapperType method gets the cost data wrapper type. The method signature is:
override function getCostDataWrapperType(paramSet : CalcRoutineParameterSet) : IType

In the built-in implementation, RateRoutinePlugin class transfers processing to the method of the same name in
the line-specific rate configuration class, such as PARateRoutineConfig.
In the line-specific configuration class, the getCostDataWrapperType method gets the wrapper type that will be
used by rate routines for the given parameter set. The rate routine editor accesses a CostData instance using this
wrapper type. The rate routine editor uses the wrapper to display the desired set of properties related to CostData in
virtual form. For example, when entering an Instruction or Operand in a rate routine step in PolicyCenter, you can
select a property on the cost such as AdjustedRate. The wrapper implementation maps AdjustedRate to the correct
underlying CostData property: StandardAdjRate, OverrideAdjRate, or ActualAdjRate. For example, if the
CostData supports overrides, this could be the override or standard property. If the CostData does not support
overrides, it is almost certainly the standard property.
The parameter is:

paramSet The parameter set for which to return the corresponding wrapper type

The method returns the IType corresponding to the instance that makeCostDataWrapper would return for the given
paramSet.

Make Cost Data Wrapper

The makeCostDataWrapper method makes the cost data wrapper. The method signature is:
override function makeCostDataWrapper(
paramSet : CalcRoutineParameterSet,
costData : CostDataBase,
defaultRoundingLevel : Integer,
defaultRoundingMode : RoundingMode) : ICostDataWrapper

In the built-in implementation, [Link] transfers processing to the method of the same name in the
line-specific rate configuration class, such as [Link].
In the line-specific configuration class, the makeCostDataWrapper method makes a wrapper for the given CostData
instance.
The parameters are:

paramSet The parameter set for which to return the corresponding wrapper
costData An instance of the CostData subclass
defaultRoundingLevel The default rounding level of the CostData

defaultRoundingMode The default rounding mode of the CostData

The method returns a wrapper instance of the IType that getCostDataWrapperType returns for the paramSet.

Enable Worksheets for a Policy Line

The worksheetsEnabledForLine method returns true if worksheets are enabled for a policy line. The method
signature is:
Configuring Rating Management 667
Guidewire PolicyCenter 9.0.9 Configuration Guide

override function worksheetsEnabledForLine(linePatternCode : String) : boolean

In the built-in implementation, [Link] enables worksheets for a policy line if the
worksheetsEnabledForLine method in the line-specific configuration class returns true.
The parameter is:

linePatternCode Pattern code for a line of business

The method returns true if worksheets are enabled for the line of business with the given pattern.
For more information, see “Add an implementation to a Plugins Registry item” on page 134.

Treat Type as Primitive

You can call the treatTypeAsPrimitive method to determine whether to treat a type as a primitive (atomic) or
whether to expose its fields. When traversing the rating entity graph, PolicyCenter calls this method. If the type is
primitive, stop traversal of that branch.
The parameter is:

t The type under consideration.

The method returns true to treat the supplied type as a primitive.

Get Branching Fields

The property getter for BranchingFields returns an array which is an ordered list of zero or more branching fields
which represent variant identifiers of a rate routine. The fields together with Code and Version on the
CalcRoutineDefinition entity uniquely identify a rate routine. A rate routine and its variant identifiers have the
same code. The signature is:
override property get BranchingFields() : IEntityPropertyInfo[]

In the default configuration, jurisdiction is an example of a rate routine variant identifier. In the PolicyCenter user
interface, the jurisdiction variant is referred to as the jurisdiction variant.
If you add a new variant identifier, you must add the name of the variant identifier to the fields variable of the
getter for the BranchingFields property.
For more information about adding a variant identifier, see “Configuring variant identifiers for a rate routine” on
page 652.

Include Property
The includeProperty method is a filter on which properties on Parameters the user can select in an Instruction or
Operand of a rate routine step. Return true to make a property available. Return false to make a property
unavailable. Return null to retain the default value of this property. It is recommended that this method end with a
catch-all return null, so that any property which is not explicitly handled gets default behavior.
The signature is:
override function includeProperty(policyLinePatternCode : String, prop : IPropertyInfo) : Boolean

The parameters are:

policyLinePatternCode The code for the policy line.

prop The descriptor for the property to include.

This method operates during the traversal of the policy graph, and controls whether a reference from one class to
another will be traversed. (In contrast, the filterIrrelevantItems method runs after the traversal of the policy
graph.)
668 chapter 49: Configuring Rating Management
 Guidewire PolicyCenter 9.0.9 Configuration Guide

For example, PolicyLocation has a foreign key to an AccountLocation. In the built-in implementation,
[Link] is not traversed. To change this behavior, you might add the condition:
if ([Link]([Link]) and [Link] == "AccountLocation") {
return true
}

Filter Irrelevant Items

Similar to the includeProperty method, the filterIrrelevantItems method is a filter on which properties on
Parameters the user can select in an Instruction or Operand of a rate routine step. However, this method runs after the
traversal of the policy graph.
This filter runs after the traversal of the policy graph.
The signature is:
function filterIrrelevantItems(input : List<InScopeUsageBase>, policyLinePatternCode : String) :
List<InScopeUsageBase>

In the built-in implementation, the RateRoutinePlugin class transfers processing to the method of the same name
in the line-specific rate configuration class, such as PARateRoutineConfig. The built-in implementation calls the
ItemFilter class which performs the default filtering. You can modify this class and add subclass helpers for
specific implementations.
In the built-in implementation, ItemFilter considers the following types as irrelevant items:
• Ignored paths – List of paths to filter out (defined in the _ignoredPaths variable). For example, the built-in
implementation filters out .EffectiveDate and .ExpirationDate. See the plugin implementation for the
complete list.
• Ignored types – List of object types to filter out (defined in the _ignoredTypes variable). For example, the built-
in implementation filters out policy period and policy line pattern. See the plugin implementation for the
complete list.
• Arrays or maps of [Link] can optionally filter by policy line pattern code.

Impact testing plugin

You can use impact testing to see the impact that changing the rate book has on the policy premium.
The impact testing plugin (IImpactTestingPlugin) generates the baseline and test periods for impact testing. The
plugin also gets and sets the rate books for quoting the test periods.
PolicyCenter provides the IImpactTestingPlugin plugin interface so that you can customize impact testing logic
in PolicyCenter. The default configuration of PolicyCenter uses a built-in implementation of the plugin,
[Link]. You can implement your own instance of this plugin by copying and customizing this
plugin implementation.
To edit the plugin registry for ImpactTestingPlugin in PolicyCenter Studio, open [Link] in
configuration→config→Plugins→registry.

See also
• “Configuring impact testing” on page 663
• Application Guide

Impact testing plugin implementation

In Studio, the built-in implementation of this plugin is the [Link] class in the
[Link] package.
This plugin creates test periods by creating policy renewals. You can customize the implementation of this plugin
directly. For example, you may want to create test periods in another way, such as by copying a submission or
spinning off a policy. You can also change how the alternate rate books are selected.
Configuring Rating Management 669
Guidewire PolicyCenter 9.0.9 Configuration Guide

Impact testing plugin methods

The impact testing plugin must implement these methods.

Create Baseline Policy Period

The createBaselinePeriod method creates a baseline policy period from the original bound policy period. The
baseline policy period is rated using the selected rate books. For more information on rate book selection, see the
Application Guide.
Impact testing compares the base policy period with the test policy period. The method signature is:
public PolicyPeriod createBaselinePeriod(PolicyPeriod original)

The parameter is:

Parameter Description
original The original bound policy period from which to create a baseline policy period.

This method returns the baseline policy period.

Create Test Policy Period

The createTestPeriod method creates a test policy period from the original bound policy period. The test policy
period is rated using the alternate rate books. The method signature is:
public PolicyPeriod createTestPeriod(PolicyPeriod original, PolicyPeriod baseline)

The parameters are:

Parameter Description
original The original bound policy period from which the baseline policy period was created.
baseline The baseline policy period created by createBaselinePeriod.

This method can create the test policy period using either the original or baseline policy period, or a combination of
both.
This method returns the test policy period.

Request a Quote on the Baseline Policy Period

The requestBaselineQuote method request a quote on the baseline policy period. The quote rates the policy using
the default rate books. The method signature is:
public void requestBaselineQuote(PolicyPeriod period)

The parameter is:

Parameter Description
period The baseline policy period

This method has no return value.

Request a Quote on the Test Policy Period

The requestTestQuote method requests a quote on the test policy period. The quote rates the policy using the
alternate rate books specified in “Impact testing plugin methods” on page 670. The method signature is:
public void requestTestQuote(PolicyPeriod period)

670 chapter 49: Configuring Rating Management

 Guidewire PolicyCenter 9.0.9 Configuration Guide

The parameter is:

Parameter Description
period The test policy period.

This method has no return value.

Flag to Include the Policy Period

The shouldIncludePeriod flag indicates whether to include or exclude the policy period in impact testing. The
method signature is:
public boolean shouldIncludePeriod(PolicyPeriod period)

The parameter is:

Parameter Description
period The policy period to be considered for inclusion or exclusion

If the return value is true, then include the policy period in the test policy periods.

Get Alternate Rate Books

The getter for the AlternateRatebooks property returns the rate books selected for rating the test policy periods. In
the Impact Testing, Select Rate Books screen in PolicyCenter, the alternate rate books appear under Rate Books for Impact
Testing. The getter signature is:
property get AlternateRatebooks() : List<ImpactTestingRateBook>

This getter returns a list of alternate rate books.

Set Alternate Rate Books

The setter for the AlternateRatebooks property sets the alternate rate books for rating the test policy periods. You
specify the alternate rate books in the books parameter. When querying for rate books, impact testing uses the
alternate rate books instead of the default rate books. The setter signature is:
property set AlternateRatebooks(books : List<ImpactTestingRateBook>)

The parameter is:

Parameter Description
books A list of alternate rate books. Pass null to not override rate books.

This method has no return value.

Rate query lookup plugin

PolicyCenter provides the IRateQueryLookupPlugin plugin interface so that you can customize the rate query fail-
over logic in PolicyCenter. The default configuration of PolicyCenter uses a built-in implementation of the plugin,
[Link]. You can implement your own instance of this plugin by copying and
customizing this plugin implementation.
To edit the plugin registry for IRateQueryLookupPlugin in PolicyCenter Studio, open
[Link] in configuration→config→Plugins→registry.
You can use the rate query lookup plugin to implement rate table lookup fail-over. For most implementations, fail-
over is not necessary. When a rate table lookup fails, it usually indicates that the table has a missing value that needs
to be added to the table. With fail-over when the lookup fails, the plugin provides an alternate return value.
Configuring Rating Management 671
Guidewire PolicyCenter 9.0.9 Configuration Guide

You can use this plugin to lookup values in a fail-over rate book. Extend the rate book entity to point to the fail-over
rate book. For example, if you change rate table codes between the old and new editions of the rate book, you can
extend the rate book to include a mapping table. Use the mapping table to fail-over to alternate rate tables.
You can also use this plugin to implementing capping. Capping uses the current renewal policy data and uses the
prior policy period’s rate book to determine the rate factor, or capping basis. Tables in the old edition of the rate
book may be missing values for the renewal policy. For example, the old rate table does not contain values for new
or changed coverages. With the plugin, lookup can fail-over to the table in the new edition of the rate book.

Rate query lookup plugin implementation

In Studio, the built-in implementation of this plugin is the [Link] class in the
[Link] package.

Rate query lookup plugin methods

The rate query lookup plugin must implement these methods.

Preempt Query with Fail‐over

The shouldPreemptQueryWithFailover method returns true to signal using fail-over if lookup fails.

Process Single Factor Query Fail‐over

The processSingleFactorQueryFailover method handles fail-over for a single factor rate table.
If you are not using cascaded lookup, pass the new book in a ThreadLocal variable. If you are using cascaded
lookup, pass the PolicyPeriod in the ThreadLocal variable to lookup the rate book hierarchy using
[Link].

Process Multiple Factor Query Fail‐over

The processMultiFactorQueryFailover method handles fail-over for a rate table with multiple factors.
If you are not using cascaded lookup, pass the new book in a ThreadLocal variable. If you are using cascaded
lookup, pass the PolicyPeriod in the ThreadLocal variable to lookup the rate book hierarchy using
[Link].

Adding line‐specific cost methods using cost adapters

Each line of business defines its own root cost entity. Every root Cost entity must implement the CostAdapter
interface and delegate it to a separate class that you create. For example, the root cost entity for the personal auto
line is PACost, and the cost adapter is [Link] in the [Link] package.
The cost adapter interface contains methods related to creating transactions and reinsurance. In addition, the
interface contains methods related to rating worksheets and impact testing in Guidewire Rating Management.

See also
• Application Guide

Cost adapter methods

The classes that implement the cost adapter interface must implement these methods.

Create Transactions
The createTransaction method creates a Transaction object in the given policy period branch that is appropriate
for the Cost type. The method signature is:
Transaction createTransaction( PolicyPeriod branch )

672 chapter 49: Configuring Rating Management

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Get Reinsurable
The getReinsurable method gets the single reinsurable that is associated with this cost. The method signature is:
Reinsurable getReinsurable()

This method returns null if the cost does not represent a premium. For example, a cost for taxes or fees does not
represent a premium.

Get Coverable
Implement a getter for the Coverable property. The getter returns a coverable if there is a coverable associated with
this cost. Impact testing uses this getter. The signature is:
override property get Coverable()

This getter returns the coverable associated with this cost or null if this cost is not associated with a coverable. This
method can return null if impact testing is not enabled for this line of business.

Get Name of Coverable

Implement a getter for the NameOfCoverable property.
The signature is:
override property get NameOfCoverable()

The getter returns the name of the coverable if there is a coverable associated with this cost. The name is usually, but
not always, equivalent to the display name or the coverable. An exception is in the Personal Auto line. All premium
costs are computed with respect to a vehicle. The getNameOfCoverable returns the DisplayName of the vehicle
even where getCoverable returns the Personal Auto Line instance.

Is Matching Bean
For reporting differences, returns true if the two beans are a match. The signature is:
override function isMatchingBean(bean : KeyableBean)

The bean parameter is the other bean to compare with this one.

Get Policy Line

Implement a getter that returns the PolicyLine associated with this cost. The signature is:
override property get PolicyLine()

Configuring Rating Management 673

Guidewire PolicyCenter 9.0.9 Configuration Guide

674 chapter 49: Configuring Rating Management

chapter 50

Configuring Reinsurance Management

This topic describes how to configure Reinsurance Management in PolicyCenter.

See also
• Integration Guide

Reinsurance Management object model

This topic describes the object model for Reinsurance Management and contains the following topics.

Reinsurance program object model

Reinsurance programs are represented by the RIProgram entity. Reinsurance programs contain one or more treaties.
Each reinsurance agreement is represented by the RIAgreement entity. A reinsurance agreement can be associated
with one or more programs. You can access the programs that an RIAgreement is associated with through the
Programs array. Each ProgramTreaty entity has a foreign key to an RIProgram.

Reinsurance Program Object Model

«delegate» RIProgram Legend

RIContract A relates to B
A B
B relates to A
Treaties
A B A has a B
*
A B A has 0 or more Bs
RIAgreement
* A is a subtype of B
A B
A delegates to B

Programs
* * *
RIAttachmentInclusion AgreementParticipant ProgramTreaty

Reinsurance agreement object model

Reinsurance agreements are represented by the RIAgreement entity. The following illustration shows the subtypes of
RIAgreement. Reinsurance agreements subtypes are proportional or non-proportional.
Configuring Reinsurance Management 675
Guidewire PolicyCenter 9.0.9 Configuration Guide

Reinsurance Agreement Object Model

«delegate» RIAgreement
RIContract

NonProportionalRIAgreement ProportionalRIAgreement
CalculateCededPremium
CedingRate
CedingRateAdjusted
GNPSubtotal FacProportionalRIAgreement

AnnualAggregateRITreaty QuotaShareRITreaty

ExcessOfLossRITreaty SurplusRITreaty

FacExcessOfLossRIAgreement

FacNetExcessOfLossRIAgreement
Legend
A relates to B
A B
B relates to A
NetExcessOfLossRITreaty
A B A has a B

A B A has 0 or more Bs
*
PerEventRITreaty A B
A is a subtype of B
A delegates to B

The following illustration shows the proportional reinsurance entities and their delegates.

Proportional Reinsurance Agreement Subtypes Object Model

ProportionalRIAgreement subtypes

«delegates» FacProportionalRIAgreement
Facultative
«delegates»
PerRisk
QuotaShareRITreaty

«delegates»
Treaty
SurplusRITreaty Legend

A B A delegates to B

The following illustration shows the non-proportional reinsurance entities and their delegates.

676 chapter 50: Configuring Reinsurance Management

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Non‐proportional Reinsurance Agreement Subtypes Object Model

NonProportionalRIAgreement subtypes

PerEventRITreaty

AnnualAggregateRITreaty
«delegates» «delegates»
Treaty LossDateAttachable

ExcessOfLossRITreaty

NetExcessOfLossRITreaty

«delegates»
PerRisk
FacExcessOfLossRIAgreement
«delegates»
Facultative
Legend
FacNetExcessOfLossRIAgreement
A B A delegates to B

Treaty entities

All entities that represent treaties delegate to the Treaty entity. In the default configuration, the treaty entities are:

Proportional Non‐proportional
QuotaShareRITreaty PerEventRITreaty

SurplusRITreaty AnnualAggregateRITreaty

ExcessOfLossRITreaty

NetExcessOfLossRITreaty

Facultative agreement entities

All entities that represent facultative agreements delegate to the Facultative entity. In the default configuration, the
facultative agreement entities are:

Proportional Non‐proportional
FacProportionalRIAgreement FacExcessOfLossRIAgreement

FacNetExcessOfLossRIAgreement

Loss date attachment agreement entities

All entities that represent loss date attachment agreements delegate to the LossDateAttachable entity. In the default
configuration, the loss date attachment agreement entities are:

Non‐proportional
PerEventRITreaty

Configuring Reinsurance Management 677

Guidewire PolicyCenter 9.0.9 Configuration Guide

Non‐proportional
AnnualAggregateRITreaty

ExcessOfLossRITreaty

NetExcessOfLossRITreaty

Per risk entities

All entities that represent per risk agreements delegate to the PerRisk entity. In the default configuration, the per
risk agreement entities are:

Proportional Non‐proportional
FacProportionalRIAgreement ExcessOfLossRITreaty

QuotaShareRITreaty NetExcessOfLossRITreaty

SurplusRITreaty FacExcessOfLossRIAgreement

FacNetExcessOfLossRIAgreement

Reinsurance coverage group object model

The Coverage entity has two fields related to reinsurance. The RICoverageGroup field returns the
RICoverageGroupType of the reinsurable. In the default configuration, RICoverageGroupType is a typelist with the
following values:
• Property
• Liability
• AutoPD
• AutoLiability
• WorkersComp
The RICoverageGroupType field groups coverages of the same reinsurance coverage group into reinsurable risks.
Two coverages of different reinsurance coverage groups cannot be grouped into the same reinsurable risk. This field
is also used in reinsurance programs and reinsurance agreements to specify which reinsurance coverage groups these
programs and agreements apply to.

678 chapter 50: Configuring Reinsurance Management

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Reinsurance Coverage Group Object Model

RICoverageGroupType
Coverage RICoverageGroup
GroupType

ReinsurableCoverable

«interface» AgreementCoverageGroup ProgramCoverageGroup

ReinsurableCoverable

PolicyLocation PolicyPeriod RIAgreement RIProgram

Reinsurable LossDateAttachmentProgram

TotalInsuredValue PolicyAttachmentProgram

Legend
A has a B
A B A implements the B
* * * * interface
LocationRisk PolicyRisk RIRisk A B A has 0 or more Bs
*
A B A is a subtype of B

Coverages of same RICoverageGroup are not all grouped into a same reinsurable risk, but are divided further by
what reinsurable coverable they apply to. In the default configuration, the reinsurable coverable entities are
PolicyLocation and PolicyPeriod. The reinsurable risks associated with these coverables are LocationRisk and
PolicyRisk, respectively. For example, if all property coverages for all buildings at the same policy location are
grouped into a single reinsurable risk, the reinsurable coverable is the policy location.
Reinsurable coverables implement the ReinsurableCoverable interface. One ReinsurableCoverable can create
multiple reinsurable risks depending upon how many RICoverageGroup entities the coverages under that
ReinsurableCoverable have.

Policy period reinsurance object model

This topic describes the reinsurance entities associated with jobs and policy periods.

Configuring Reinsurance Management 679

Guidewire PolicyCenter 9.0.9 Configuration Guide

Policy Period Reinsurance Object Model

Legend
Reinsurable
A relates to B
A B
B relates to A RiskNumber
A B A has a B

A B A has 0 or more Bs
* A is a subtype of B PolicyPeriod PolicyRisk LocationRisk
A B
A delegates to B
ValidReinsurance *
*
*
RIRiskVersionList RIAttachmentInclusion
RiskNumber *
AllVersions

*
RIRisk
RiskNumber

*
RIAgreement

The RiskNumber field is used to uniquely identify a risk in various entities in the object model. For example, the
RIRisk and PolicyRisk entities have the same risk if they have the same RiskNumber.
The RIRisk entity delegates to the SimpleEffDated delegate which has EffectiveDate and ExpirationDate
fields. Each instance of this entity represent a reinsurance risk for a period of time when it unchanged. The RIRisk
represents a version of the risk.
The RIRiskVersionList entity is the container for all versions of a RIRisk created by a policy period. The version
list has a link back to the policy period which created it.

Reinsurance Management permissions

The following table lists the permissions related to Reinsurance Management:

Permission Code Description

Edit active RI programs editreinsuranceactiveprogram Permission to edit active reinsurance programs
Edit fac agreements editreinsurancefacagreement Permission to edit facultative agreements
Edit RI policies advanced editreinsuranceforpolicyadvanced Permission to edit advanced reinsurance fields for policies

Edit RI policies basic editreinsuranceforpolicybasic Permission to edit basic reinsurance fields for policies
Edit RI programs editreinsuranceprogram Permission to edit reinsurance programs
View RI policies viewreinsuranceforpolicy Permission to view reinsurance for policies
View RI programs viewreinsuranceprogram Permission to view reinsurance programs

Configuring reinsurance coverage groups

This topic describes how to configure reinsurance coverage groups in Product Designer.
680 chapter 50: Configuring Reinsurance Management
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Configure reinsurance coverage group on individual coverages

About this task
For each coverage, you can configure whether the coverage is part of a reinsurance coverage group.

Procedure
1. In Product Designer, open a policy line and go to the Coverages page.
2. Select a coverage.
3. Go to the Reinsurance page for that coverage.
4. Select a Reinsurance Coverage Group from the drop-down list. You can also add a Reinsurance Coverage Group
Script.
Selecting a Reinsurance Coverage Group sets the RICoverageGroup on the Coverage entity.

Disable Reinsurance Management for a line of business

About this task
You can disable Reinsurance Management for a line of business.

Procedure
In Product Designer, open the policy line and make the following changes to each coverage on the
Coverages→Reinsurance page:
• Set Reinsurance Coverage Group to <none selected>.
• Remove any Reinsurance Coverage Group Script.
If no coverages are linked to a coverage group, then no reinsurable risk will be created. Therefore, there will be no
checking for reinsurance or linking to reinsurance agreements.

Reinsurance net retention underwriting issue type

Reinsurance Management has one underwriting issue type.
Reinsurance Management raises an RINetRetention underwriting issue if a policy period has reinsurable risks with
insufficient reinsurance. PolicyCenter checks for this issue at quote release, bind, and issuance.
PolicyCenter raises an underwriting issue if the net retention is greater than the Target Max Retention in the Reinsurance
screen of a policy file. In the base configuration, the [Link] class contains code to
raise this underwriting issue.
If you integrate with an external reinsurance management system and have defined your own reinsurance data
model, you will need to rewrite the Gosu code for raising this underwriting issue.

See also
• The Application Guide for more information about the Reinsurance checking set.

Implementing Gosu methods for Reinsurance Management

This topic describes the Gosu methods that you must implement for Reinsurance Management.

Gosu methods for calculating the total insured value

Each line of business calculates the total insured value.
Configuring Reinsurance Management 681
Guidewire PolicyCenter 9.0.9 Configuration Guide

In the default configuration, the calculateTotalInsuredValue method in

[Link] calculates the total insured value. For each coverage, this
method calls the getTIVForCoverage method. Each line of business overrides the getTIVForCoverage method. For
an example, see the getTIVForCoverage method in [Link].
If you implement a new policy line and do not use AbstractPolicyLineMethodsImpl, you must implement a
calculateTotalInsuredValue method.
If the new policy line inherits from AbstractPolicyLineMethodsImpl, the policy line needs to implement the
getTIVForCoverage method.

682 chapter 50: Configuring Reinsurance Management

chapter 51

Handling high volume quote requests

Some insurers need to handle high volumes of quote requests generated by external applications, such as the web
sites of comparative raters. A comparative rater’s web site enables its customer to view and choose between quotes
from multiple insurers. Insurers who receive these requests must generate large volumes of quotes. The comparative
rater’s customer expects to see information quickly, therefore PolicyCenter must quickly generate the quote.
Most of these high volume requests do not result in a policy. Therefore, it is desirable to save the quotes in an
external database rather than the PolicyCenter database. In general, this external database is partitioned to
concurrently handle requests from multiple instances of PolicyCenter.
For these types of insurers, Guidewire recommends a quoting architecture and provides an API and plugin interface
for generating quotes. To handle the high volume of quote requests, the architecture uses multiple instances of
PolicyCenter. All instances leverage the same PolicyCenter version and configuration. To avoid database
performance issues, the quote-only instances are not clustered. One or more quote-only instances process quotes
directly from comparative raters. The architecture uses a separate PolicyCenter system-of-record (SOR) to complete
submissions and issue policies.
Note: For efficient insertion and purging with an Oracle database, use composite range hash
partitioning with the range based on a time interval, such as monthly. Partitioning by time enables you
to easily purge old quotes. Use a similar mechanism if you are writing to another database.
Handling lower volumes of quote requests – Every PolicyCenter instance, even the SOR, includes the API which
provide quotes that are stored outside the PolicyCenter instance. If you handle a lower volume of quote requests,
you can use this API with the PolicyCenter SOR handling quote requests. Store the quotes outside the SOR database
until they are bound.
Keeping Quick Quotes outside the main database – In a submission, you can choose to do a Quick Quote rather
than a Full Application. In the base configuration, Quick Quote stores the quotes in the PolicyCenter SOR database. If
your bind rate on these policies is low, you can modify Quick Quote to store the quote outside the SOR database
until the quote is bound. You can do this by modifying the Quick Quote wizard to provide the quote and then call the
Quoting Data plugin to write the quote to the quoting table.

High volume quotes overview

This topic describes a suggested way of handling high volume quote requests with PolicyCenter.

Generating the quote

High volume quote requests can be generated in the following way:
1. Incoming quote requests from comparative raters are translated into a set of PolicyCenter policy objects in a
special quote-only instance of PolicyCenter. This instance only handles quote requests. Each request has a set
Handling high volume quote requests 683
Guidewire PolicyCenter 9.0.9 Configuration Guide

of inputs that affect rating. Before sending the request, the comparative raters can make external calls to
validate vehicle or address information.
2. The quote-only instance validates these objects. This validation may be customized for the comparative rater
or can be the same as for other channels, such as call centers or portals.
3. To enhance the quote data, the quote-only instance can make external service calls, such as credit checks.
4. The quote-only instance rates the policy. Rating can be done by Guidewire Rating Management or another
rating engine.
5. The rating engine returns pricing data and a reference number.
6. The quote-only instance stores both the original request and the completed quote in a Quote table, for
example, located in an external quoting database. This quoting database has its own schema which does not
necessarily follow the PolicyCenter object model, allowing for a different database storage strategy than the
SOR database. The Quote table stores high-level quote details for identification and verification. The SOR can
search this external quoting database without necessarily retrieving the full quote.
7. The quote-only instance sends the completed response back to the comparative rater.
8. The quote request/response data are immediately available for sending to a data warehouse for analytical
purposes. If the quote results in a bound policy, the reference number can be used for auditing.

Viewing the quote

The comparative rater’s customer may not immediately decide to purchase a policy. Later, the customer can return to
the comparative rater’s web site and view the quote again. The comparative rater retrieves the Quote from the
external quoting database.

Moving the quote into the system of record

When the comparative rater’s customer is ready to purchase a policy, the quote moves into the PolicyCenter SOR.

From the Comparative Rater’s Web Site

If the comparative rater’s customer wants to purchase a policy while still on the comparative rater’s web site:
1. The customer is automatically navigated to the insurer’s web portal. The portal simultaneously makes a web
service call to the PolicyCenter SOR to retrieve the Quote from the external quoting database using the
reference number.
2. The SOR retrieves the Quote from the external quoting database and transforms it into a PolicyCenter
submission. The SOR marks the record in the Quote table as converted to exclude it from further searches and
multiple conversions.
3. The portal guides the user through additional questions and validation required to complete the submission.

From the Call Center

If the comparative rater’s customer calls the call center to purchase a policy:
1. The call center consultant uses the PolicyCenter SOR screens to retrieve the Quote from the external quoting
database using the reference number or other quote details.
2. The SOR retrieves the Quote from the external quoting database and transforms it into a PolicyCenter
submission. The SOR marks the record in the Quote table as converted to exclude it from further searches and
multiple conversions.
3. In PolicyCenter, the consultant guides the user through additional questions and validation required to
complete the submission.

684 chapter 51: Handling high volume quote requests

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Other considerations for handling high volume quotes

When setting up a systems to handle high volume quotes, also consider the following:
• All quote-only instances of PolicyCenter access the same Quote table in the external quoting database for storage
and retrieval. Therefore, you can add additional instances as necessary to support peak loads. Each instance
operates independently.
• The Quote table can be purged on a regular basis to keep the size manageable. All quotes which are past a
specified validity date can be purged completely since the data warehouse has a record of the data.
• Maintenance on the PolicyCenter SOR will not impact the operation of the quote-only instances, and therefore
facilitates 24/7 operation.

High volume quotes implementation overview

To handle high volumes of quote requests, the Quoting Processor plugin provides an interface for generating quotes.
This plugin implementation calls methods on the Quoting Data (QuotingDataPlugin) plugin, which can save these
quotes to an external database. Guidewire provides:
• The Quoting Processor plugin interface
• The Quoting Data plugin interface
• A sample plugin implementation in StandAloneQuotingDataPlugin. This implementation is a placeholder; it
does not write to a database.
You must develop the Quoting Data plugin implementation that writes the GX model to your quoting database. You
must also develop other pieces of this implementation, including web services, the GX model, and additional
interactions with the quoting database. For example, you can write a custom web service that you publish from
PolicyCenter. Your web service receives quote requests from external applications and sends them to the Quoting
Processor plugin. See the Integration Guide.
The following illustration presents a simplified model of how an insurer can use this API and plugin to handle quote
requests.

Handling high volume quote requests 685

Guidewire PolicyCenter 9.0.9 Configuration Guide

1
Website A

Browsers

Quote request Quote request

2

Carrier
environment PolicyCenter
For handling quotes
PolicyCenter
For handling quotes
Web service
3 3

4 GX Model
...
QuotingProcessorPlugin

PolicyCenter
Database
(not system of QuotingDataPlugin
record)
5

GX Model

Quoting Database

PolicyCenter
System of record

7
PolicyCenter
Database
(system of record)

1. Website A is a comparative rater. Their web site enables potential customers to view policy quotes gathered
from multiple insurers. A potential customer on Website A enters basic policy information and requests
quotes. One of these insurers uses PolicyCenter to handle these requests.
2. Website A sends the policy information to multiple insurers. One of these requests goes to a insurer with
PolicyCenter.
The insurer has multiple instances of PolicyCenter to handle these requests.
3. Your web service formats the request. The base configuration does not contain an example of this type of web
service. The web service verifies the data, then formats the data in the GX model of a PolicyPeriod. See the
Integration Guide.
4. Your web service then calls the quoteSubmission method in the Quoting Processor plugin interface
(QuotingProcessorPlugin) to generate a quote.
5. The quoteSubmission method calls the Quoting Data plugin (QuotingDataPlugin) to obtain an account.
Then this method generates a policy period and a quote. This method returns the quote and a quote identifier.
Generating the policy period and quote access the PolicyCenter database attached to the PolicyCenter instance
for handling quotes. This database is not a system of record. In this proposed implementation, neither the
policy period nor the quote are committed to the PolicyCenter database. The external quoting database,
described in the next step, is optimized for storing the quoting information.
6. The quoteSubmission method calls the Quoting Data plugin to save this quote to the external quoting
database. The quoting database is partitioned so that it can concurrently handle requests from multiple
instances of PolicyCenter.

686 chapter 51: Handling high volume quote requests

 Guidewire PolicyCenter 9.0.9 Configuration Guide

7. If the potential customer decides to purchase the insurer’s policy, then the PolicyCenter system of record
retrieves the GX model of the quote from the external quoting database. The PolicyCenter SOR uses the quote
identifier to retrieve the GX model. You implement this step.
Optionally, the Customer Service Representative can display the quote on the screen and make changes. The
policy can be bound and saved to the PolicyCenter database.

Quoting processor plugin

The Quoting Processor plugin interface (QuotingProcessorPlugin) provides the quoteSubmission method to
generate a policy and obtain a quote. PolicyCenter requires an account and the producer code associated with the
account to produce a quote. This method calls the Quoting Data plugin (QuotingDataPlugin) to retrieve an account.
The quoteSubmission method queries the PolicyCenter database to find the producer code associated with the
account.
The input parameters to quoteSubmission are:
• productCode – The product code, such as PersonalAuto or WorkersComp. This is the Code defined in Product
Model → Products in Product Designer.
• policyPeriodData – The policy period data in XML format, XMLElement. This is the data with which to
populate the policy period. In the default implementation, the method expects the data in Guidewire XML format
(GX Model):
[Link]

The quoteSubmission method sends the quoting data to the Quoting Data plugin. The plugin saves the quoting data
to an external database. The quoteSubmission method does not commit the policy period to the PolicyCenter
database.
The quoteSubmission method returns a QuoteData object. This object contains a quote identifier and the quoting
data formatted as a policy period in GX model format.

Logging
The quoting processor plugin logs messages about quoting jobs (policy transactions) to the
[Link] category.

Quoting data plugin

The Quoting Data plugin (QuotingDataPlugin) interface provides methods for saving quoting data to an external
database. The built-in implementation of this plugin is [Link]. This
plugin is for demonstration purposes only. You can write your own implementation of this plugin interface to
communicate with your external database. For more information about plugins, see the Integration Guide.

Get Account
The getAccount method of the Quoting Data Plugin returns the account associated with the input parameter,
requestData. The method signature is:
getAccount(requestData : Object) : Account

When the QuotingProcessor class calls getAccount, the requestData is policy period data in GX model format.
To use the requestData argument, downcast it from Object to the appropriate GX model format. For example
[Link] (the policy period type fully
qualified name).
Configure the account to have one producer code and set the preferred underwriter on the producer code. The
preferred underwriter provides improved performance by avoiding round robin assignment.
Your implementation of this method can use the requestData parameter to retrieve a PolicyCenter account. If you
always use a single PolicyCenter account for these types of quotes, ignore the requestData argument and return
Handling high volume quote requests 687
Guidewire PolicyCenter 9.0.9 Configuration Guide

that account. For example, you might use a single account if rating does not depend upon properties of the account.
Using this single account avoids creating accounts for each request, since few of these accounts will be associated
with full submissions. Similarly, if rating depends upon only a few account properties, the Quoting Data Plugin
implementation can have one account per unique combination of properties.

Send Quoting Data

The sendQuotingData method of the Quoting Data Plugin sends the quoting data to an external database. The
return value of this method is a unique identifier for the quoting data. The unique identifier can be used later to
retrieve the quote and bind a policy in the PolicyCenter system of record. The method signature is:
sendQuotingData(data : String) : Object

The plugin implementation can return any type of object that you require for the unique identifier. For example, the
built-in implementation returns an Integer.

688 chapter 51: Handling high volume quote requests

chapter 52

Configuring multicurrency

This topic describes how to configure multicurrency.

See also
• Application Guide
• Globalization Guide

Configuring PolicyCenter for a single currency

When you run PolicyCenter with MultiCurrencyDisplayMode disabled, currency fields are not visible in the user
interface. Examples of currency fields in the user interface are currency selectors on screens and currency columns
in tables.
In the base configuration, PolicyCenter runs with MultiCurrencyDisplayMode disabled.
To run PolicyCenter with MultiCurrencyDisplayMode disabled, set the following parameters in [Link]:

Parameter Value Description

MulticurrencyDisplayMode SINGLE The multicurrency display mode. In the base configuration, this pa‐
rameter is set to SINGLE.
DefaultApplicationCurrency A typecode from the The default currency for the application. Set to the currency of your
Currency typelist. choice.

See also
• “MulticurrencyDisplayMode” on page 67
• “DefaultApplicationCurrency” on page 66

Creating multicurrency policy lines

This topic describes how to create policy lines that support more than one coverage currency. The tasks include:
• Identifying the coverage currencies that the line supports.
• Ensuring that the required foreign exchange conversions are available (not described in this topic)
• Adding appropriate coverage options for each of the currencies
Configuring multicurrency 689
Guidewire PolicyCenter 9.0.9 Configuration Guide

• Managing rating in each of the currencies (not described in this topic)

• Enabling producers to write business in various settlement currencies
The examples use the Wright Construction account in the small sample data set. The examples assume that Wright
Construction is based in the United States. The insurer provides a commercial property policy that insures buildings
and locations the United States and France. The following table contains currency information for these countries.

Country Currency Currency symbol ISO 4217 Code

United States U.S. dollar $ USD

France Euro € EUR

IMPORTANT The MulticurrencyDisplayMode configuration parameter setting is semi-permanent.

You can change the value of this parameter only once, from SINGLE to MULTIPLE After you change the
value, you must not later change it back. If you do change the value of MulticurrencyDisplayMode
back to SINGLE, subsequent attempts to start the server fail. This configuration parameters is in
[Link].

Adding coverage currencies to a policy line

This topic provides example of how to manage multiple coverage currencies for a given coverage. In these step-by-
step instructions, you add the euro as a coverage currency for the commercial property line and add euro values to a
money coverage term.

Create workspace and change list

Procedure
1. In Product Designer, create a workspace named “Multicurrency”.
2. In Product Designer, create a change list named “Multicurrency Coverage Currency” that uses the workspace.

Next steps
Now you can move to the next step, “Add a currency to a coverage” on page 690.

Add a currency to a coverage

Before you begin
Before you begin, you must complete “Create workspace and change list” on page 690.

Procedure
1. In Product Designer, navigate to Product Model→Policy Lines→Commercial Property Line.
2. Under Available Coverage Currencies, click Add and select EUR from the drop-down list.
Product Designer displays both EUR and the existing coverage currency as choices for coverages.
3. Go to Coverages and select Building Coverage.
4. Go to Terms and select the Limit coverage term.
The Value Type of this coverage term is Money.
5. Click to Add a currency.
6. Select EUR and enter 75,000, for example, as a default value. Optionally enter minimum and maximum values
such as 25,000 and 100,000.
7. Go to Terms→Deductible.
The Value Type of this coverage term is Money. This is a option coverage term which presents a list of values.
690 chapter 52: Configuring multicurrency
 Guidewire PolicyCenter 9.0.9 Configuration Guide

8. Go to Options.
9. Add options in euros, such as 250, 500, and 750. Prefix the Code with EUR to distinguish the euro options, for
example EUR250.
10. Commit the change list and synchronize the product model.

Next steps
Now you can go to the next step, “Check your work” on page 691.

Check your work

Before you begin

Before you begin, you must complete “Add a currency to a coverage” on page 690.

Procedure
1. Log in to PolicyCenter as a producer such as aapplegate.
2. Go to the Wright Construction account.
3. Create a Commercial Property submission.
4. On the Policy Info screen, verify that USD and EUR appear in the Preferred Currency→Coverage drop-down list and
select EUR.
The preferred coverage currency will be the default currency for coverables on the policy.
5. Advance to the Buildings and Locations screen.
6. Add a building to the primary location and fill in any required fields on the Building Information screen.
Verify that the Coverages in drop-down list includes USD and EUR, and the preferred coverage currency, EUR, is
selected.
7. Fill in required fields on the Details tab.
8. Go to the Coverages tab.
Notice that the Limit is set to the default value for EUR. The Deductible drop-down list contains the EUR options
you defined in Product Designer.
9. Deselect all coverages except for Building Coverage.
10. Advance to the Policy Review screen.
Notice that for the building, the Coverages in are in euros.
11. Quote the policy.
The quote is in U.S. dollars because that is the settlement currency.

Changing the settlement currency

The preferred settlement currency, PreferredSettlementCurrency, is a field on the contact, account, and policy
period entities.
In a job, the default settlement currency is the settlement currency on the account. In a job, you can pick a settlement
currency from the Preferred Currency→Settlement drop-down list on the Policy Info screen. The list of Settlement
currencies is populated from the Currency typelist.
A producer can quote a policy in any configured currency. However, when you bind or issue a policy, the producer
of record must have the authority to bind the policy in the settlement currency. In the base configuration, the user
interface enables you to select only one currency per producer code. You can configure PolicyCenter to allow more
than one currency per producer code. You can view producer codes by navigating in PolicyCenter to the
Administration→Producer Codes screen.
Configuring multicurrency 691
Guidewire PolicyCenter 9.0.9 Configuration Guide

PolicyCenter and product model configured for multicurrency

PolicyCenter does not start in single currency display mode if the product model is configured to use multiple
currencies.
Product Designer allows users to configure multicurrency features without regard for the setting of the
MultiCurrencyDisplayMode in the PolicyCenter [Link] file. If you configure multiple currencies in a product
model object, and the value of the MultiCurrencyDisplayMode property is SINGLE, PolicyCenter does not start.
For example, if you add clauses that specify multiple coverage currencies and the PolicyCenter
MultiCurrencyDisplayMode is set to SINGLE, the server fails to start and displays messages similar to the
following:

ERROR ... PolicyLinePattern : ... [field : AvailableCoverageCurrencies] : - Multiple Coverage

Currencies defined for product not allowed in single Currency mode
ERROR ... [ExclusionPattern] : ... [DirectCovTermPattern] : ... [LimitsSet] : - The pattern specifies
limits for different currencies in SingleCurrencyMode

If you intend to deploy a product model on PolicyCenter servers that are not configured for multiple currency
display mode, do not configure multiple currencies in any part of the product model. However, you can test
multicurrency products on a staging server configured for multicurrency while the production system is configured
for a single currency.

Configuring the coverage currency

In the base configuration, the coverage currency appears in various places in accounts and policies. In the base
configuration, accounts, policy periods, and coverables have coverage currency properties. Coverages and clauses
have a currency property.
In the base configuration, you set the coverage currency on a coverable. PolicyCenter sets the currency for each
coverage on the coverable to the same currency as the coverable. You can modify this behavior through
configuration.

Coverage currency in accounts

Accounts have a preferred coverage currency. You can view or set this value on the Account Summary screen. The
preferred coverage currency on account is in the [Link] property. In the base
configuration, PolicyCenter initially sets the account’s preferred coverage currency to the contact’s preferred
settlement currency, [Link]. You can change this behavior through
configuration.
In the base configuration, all contact objects have a preferred coverage currency even if PolicyCenter is configured
for a single currency. (When running PolicyCenter with MultiCurrencyDisplayMode disabled, the currency does
not appear in the user interface.) However, if a contact does not have a preferred coverage currency, then
PolicyCenter sets the account’s preferred coverage currency to the default system currency. A properly configured
system always specifies the currency and does not rely on this fail-safe behavior.

Coverage currency in policy periods

Policy periods have a preferred coverage currency which PolicyCenter initializes when initializing the policy term.
The preferred coverage currency on policy periods is in the [Link] property.
In the base configuration, this property is set to the account’s preferred coverage currency property,
[Link], if it exists. This is implemented in the initializeCurrencies method in
the PolicyPeriodPlugin class in the [Link] package.
In the base configuration, all accounts have a preferred coverage currency even if PolicyCenter is configured for a
single currency. However, if an account does not have this value, PolicyCenter sets the policy period’s preferred
coverage currency to the default system currency. A properly configured system always specifies the currency and
does not rely on this fail-safe behavior.
692 chapter 52: Configuring multicurrency
 Guidewire PolicyCenter 9.0.9 Configuration Guide

To get the default preferred coverage currency for the specified policy period, you can use the
lookupDefaultPreferredCoverageCurrency method in the [Link] Gosu class.

Coverage currency in coverages and clauses

Coverages, exclusions, and policy conditions include a currency which is the currency for the clause. The Currency
property on the Coverage, Exclusion, and PolicyCondition entities stores the currency. In the base configuration,
all coverages on the same coverable have the same currency. Therefore, the user interface does not provide a way to
change the currency on a specific clause. The user interface lets you change the currency on the coverable, and that
currency is propagated to all coverages on the coverable.
A coverable inherits its default currency from the owning coverable or policy period. In Commercial Property for
example, a new building (CPBuilding) automatically gets the preferred coverage currency,
PreferredCoverageCurrency, of its parent coverable, CPLocation.
Commercial Property Coverables

PolicyPeriod
PreferredCoverageCurrency
PreferredSettlementCurrency
Legend

* A B A has 0 or more Bs
CommercialPropertyLine *
A A is a Coverable
PreferredCoverageCurrency

*
CPLocation
PreferredCoverageCurrency

*
CPBuilding
PreferredCoverageCurrency

Coverage currency in coverables

Coverables have a preferred coverage currency which PolicyCenter uses to synchronize all coverages associated
with a coverable. The preferred coverage currency on coverables is in the
[Link] property. After updating the preferred coverage currency on a coverable,
PolicyCenter synchronizes the product model. The synchronizeCurrencies method in the
[Link] Gosu class synchronizes the product model.

Configuring the settlement currency

This topic describes Gosu classes and object related to the settlement currency. The settlement currency is used in
billing. In the base configuration, the contact, account, policy period objects have a settlement currency property.

Settlement currency in contacts

Contacts have a preferred settlement currency. The preferred settlement currency on contact is in the
[Link] property. PolicyCenter initializes the preferred settlement currency in the
[Link] class.
In the base configuration, the preferred settlement currency is based on the primary address of the contract. For
example, if the primary address is in California, which is in the United States, then PolicyCenter sets the currency to
U.S. dollars. The createAccountForContact method sets the preferred settlement currency.
Configuring multicurrency 693
Guidewire PolicyCenter 9.0.9 Configuration Guide

In the base configuration, the jurisdiction on the address maps to a country, and each country has a currency.
However, if for some reason an address does not map to a currency, the createAccountForContact method
initializes this property to the system default currency. A properly configured system always specifies the currency
and does not rely on this fail-safe behavior.
The ContactCurrencyInitializer class contains methods for editing the currency for a contact. PCF files that
enable a user to edit the currency for a contact use these methods. The ContactCurrencyInputSet PCF file uses
this class to set the Preferred Currency for a contact. You can see an example of this Preferred Currency field when you
view a contact on the Contact File Details screen.
The Account Holder Info screen uses the preferred settlement currency on the contact to aggregate policy, claim, and
billing metrics and display them in the settlement currency. The contact’s preferred settlement currency becomes the
default settlement currency for an account created from that contact.

Settlement currency in accounts

Accounts have a preferred settlement currency. The preferred settlement currency on account is in the
[Link] property. To create a new account with the given contact as the account
holder, you can use the createAccountForContact method in [Link]. In the base
configuration, this method initializes the account’s preferred settlement currency based on the contact’s primary
address. The code assumes that if the coverage currency is set, the settlement currency is also set.
In the base configuration, the jurisdiction on the address maps to a country, and each country has a currency. For the
rare jurisdiction that does not have a country, you can specify the currency directly for that jurisdiction. Map the
jurisdiction to currency in the definition of the jurisdiction and country typekeys. For an example, see the typecode
for Guam in the [Link] typelist extension. However, if for some reason an address does not map to a
currency, the createAccountForContact method initializes this property to the system default currency. A properly
configured system always specifies the currency and does not rely on this fail-safe behavior.
When the account is initially created, the country of the account’s address determines the preferred settlement
currency. Methods in the [Link] class determine the currency.
The AccountCurrencyInputSet PCF file displays the account’s settlement currency.
The AccountFile_Claims and SubmissionManager PCF files use the settlement currency to determine the currency
on the Account File Claims and Submission Manager screens. These files use the settlement currency for computing and
displaying the Total Incurred and Total Cost fields, respectively.

Settlement currency in policy periods

Policy periods have a preferred settlement currency. The preferred settlement currency is in the
[Link] property. PolicyCenter initializes this field when initializing the
policy term. You can modify the initialization by overriding the initializeCurrencies method in the
IPolicyPeriodPlugin plugin interface.
When you create a policy in the user interface, you set the policy period’s settlement currency (Preferred
Currency→Settlement) on the Policy Info screen.

Configuring multicurrency and reinsurance

PolicyCenter attaches a reinsurance program to a risk in a policy if the total insured value/sum insured (TIV/SI) for
that risk has the same currency as the risk. In the base configuration, the TIV/SI currency is the currency associated
with the jurisdiction of the risk. Through configuration, you can modify how PolicyCenter chooses the TIV/SI
currency.
The reinsurance currency is independent of the coverage and settlement currencies. In the base configuration,
PolicyCenter sets the reinsurance currency to the currency specified for the coverable’s jurisdiction in the
ReinsuranceConfigPlugin plugin. This plugin implements the IReinsuranceConfigPlugin plugin interface. The
plugin calculates the TIV/SI based on the coverage currency. If the coverage currency differs from the reinsurance
currency, the plugin converts the TIV/SI to the reinsurance currency. The Reinsurable object stores the TIV/SI
(TotalInsuredValue) and reinsurance currency (ReinsuranceCurrency). The Reinsurable is then used to create
694 chapter 52: Configuring multicurrency
 Guidewire PolicyCenter 9.0.9 Configuration Guide

the reinsurable risk (RIRisk) objects. If an appropriate reinsurance program is available, PolicyCenter attaches the
program to the reinsurable risk. The program has the same currency as the reinsurable risk.
In the ReinsuranceConfigPlugin plugin, the getReinsuranceCurrency method returns the currency that the
RIRisk uses for TIV/SI. To change how PolicyCenter selects the reinsurance currency, you can override this
method.
The input parameter to the getReinsuranceCurrency method is a list of all the coverages associated with a single
ReinsurableCoverable. The PolicyPeriodBaseEnhancement Gosu class calls this method when creating
Reinsurables. In the base configuration, the method gets the jurisdiction specified in the
[Link] property and looks up the currency associated with that jurisdiction. That mapping is
returned by the RegionCurrencyMappingUtil class and configured through the Country, Jurisdiction, State,
and Currency typelists.
The reinsurance program and reinsurance contract entities, RIProgram and RIAgreement respectively, delegate to
the reinsurance contract entity, RIContract. The RIContract entity has a non-nullable currency property,
Currency, that the RIProgram and RIAgreement entities implement. The program and agreements associated with
the program must have the same currency.
When PolicyCenter attaches an RIProgram or an RIAgreement to an RIRisk, the Currency properties must match.
The Premium Ceding batch process runs and calls the PCCedingCalculator class to process premium transactions.
This class does the conversion from the reinsurance currency to the settlement currency.

See also
• Integration Guide

Reinsurance objects and multicurrency

The following illustration shows some of the multicurrency properties on reinsurance objects.
Reinsurance Entities

RIRisk Reinsurable
RIContract RIProgram
Currency ReinsurableCurrency
Currency Currency TotalInsuredValue TotalInsuredValue

Legend
* A B A has a B
RIAgreement
A B A has 0 or more Bs
Currency * * A is a subtype of B
A B A delegates to B
A is enhanced by B

Configuring multicurrency and rating

In the base configuration, the rating engine creates cost data in the currency of the associated coverage.
For costs not associated with a coverage, the rating engine uses the PreferredCoverageCurrency on the policy
period associated with the line being rated.
The [Link] class defines a TaxRatingCurrency property and sets it to the
PreferredSettlementCurrency on the policy period associated with the line being rated. The
AbstractRatingEngineBase class is a read-only file.

See also
• Application Guide
Configuring multicurrency 695
Guidewire PolicyCenter 9.0.9 Configuration Guide

Costs and multicurrency

The rating engine rates the coverables in the coverage currency and returns cost data to PolicyCenter. PolicyCenter
converts the cost data into Cost objects. PolicyCenter stores the currency and the amount on Amount properties on
the Cost, for example [Link]. The Amount properties are of MonetaryAmount type which has
properties for an amount and a currency. If necessary, PolicyCenter coverts the amounts to the settlement currency.
The rating engine then stores the amounts in duplicate billing amount properties (AmountBilling) on the Cost
entity, for example [Link]. If the coverage currency differs from the settlement currency, the
rating engine also stores a pointer to the exchange rate. The [Link] Boolean property is set to true
if the PolicyCenter converted the currency on the cost.
The convertCostsToSettlementCurrency method in the AbstractRatingEngineBase class performs the currency
conversion and stores the converted amounts in duplicate AmountBilling properties.
The duplicate amount properties on the Cost entity are:

Property Description
ActualAmountBilling The ActualAmount in the settlement currency for accounting and reporting.
StandardAmountBilling The StandardAmount in the settlement currency for accounting and reporting.
OverrideAmountBilling The OverrideAmount in the settlement currency for accounting and reporting.
ActualTermAmountBilling The ActualTermAmount in the settlement currency for accounting and reporting.
StandardTermAmountBilling The StandardTermAmount in the settlement currency for accounting and reporting.

OverrideTermAmountBilling The OverrideTermAmount in the settlement currency for accounting and reporting.

PolicyFXRate If the coverage currency is not the same as the settlement currency, this property contains a
foreign key to a copy of the exchange rate from the exchange rate service. PolicyCenter uses
this PolicyFXRate to convert the as‐rated costs from the coverage currency to billing costs in
the settlement currency. When you configure PolicyCenter, do not keep more than one copy of
the same PolicyFXRate on a single policy period.

The policy period has an array of exchange rates used for monetary amount conversion. This array is
[Link].
Exchange rates on a policy period

Legend
PolicyPeriod
A B A has a B

A B A has 0 or more Bs
PolicyFXRates *
* * *
Cost PolicyFXRate Transaction
ActualAmount FromCurrency Amount
ActualAmountBilling Market AmountBilling
ActualTermAmount MarketTime
ActualTermAmountBilling Rate
ToCurrency

Each FXRate object records an exchange rate and the time that it was obtained from the market. Exchange rates can
vary over the life of the policy, come from different sources, or cover different currency pairs, therefore the policy
period maintains an array of exchange rates.
The following table describes some of the properties on the PolicyFXRate object:

696 chapter 52: Configuring multicurrency

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Property Description
Rate The exchange rate at which one currency can be converted to another.
MarketTime The time at which the market indicated the rate went into effect.
RetrievedAt The time at which the quotation was obtained from the market.
FromCurrency The currency to convert from.

ToCurrency The currency to convert to.

Market The exchange rate market, FXRateMarket, which set the rate.
PolicyPeriod A foreign key to the policy period to which this object belongs.

Transactions and multicurrency

In the base configuration, transaction amounts are computed using the as-rated currency amounts on the costs.
PolicyCenter then converts the transaction amounts to the settlement currency using the same exchange rate,
PolicyFXRate, as the cost associated with the transaction. This is one way that an insurer might handle exchange
rate changes during a policy term. You can configure PolicyCenter to handle the exchange rate in other ways during
transactions.
The createEntityTransactions method in the PolicyPeriodTransactionCalculator class converts the
transaction amount to the settlement currency using the exchange rate. The PolicyPeriodTransactionCalculator
class is a read-only file.
The properties on the Transaction entity are:

Property Description
Amount The transaction amount.
AmountBilling The Amount in the settlement currency for billing.

PolicyFXRate A foreign key to a copy of the exchange rate from the exchange rate service. This points to the same ex‐
change rate used to calculate the cost associated with this transaction.

Configuring underwriting authority and multicurrency

PolicyCenter raises underwriting issues based on characteristics of the policy, including ones that may be related to
monetary amounts. You can create and manage monetary underwriting issues with values, approvals, and authority
limits that include both an amount and a currency. The base configuration and sample data contain underwriting
issues that provide an example of how to compare values, approvals, and authority limits in different currencies.
In the base configuration examples, PolicyCenter creates an issue with a value in the currency on the policy. That
currency may differ from the currency of the user’s authority grant. In the base configuration, the monetary-issue
comparator automatically converts the value being tested to the currency of the reference value. The value being
tested might be the value of the user’s approval. The reference value currency might be the currency of the user’s
authority grant. In the sample data, the authority grants are in U.S. dollars, but this is not a requirement. Through
configuration, you can take a different approach.

See also
• “Configuring underwriting rules” on page 585
• Application Guide

Configuring underwriting issues and multicurrency

In the base configuration, certain underwriting rules handle multicurrency. An underwriting rule that handles
multicurrency has the following features:
Configuring multicurrency 697
Guidewire PolicyCenter 9.0.9 Configuration Guide

Field Description
Comparator Value Comparator set to At least or At most. These values correspond to the codes Monetary_GE
or Monetary_LE, respectively.
DefaultValueAssignmentType Set to OffsetAmount.

DefaultValueOffsetAmount Not equal to 0.

ValueFormatterType Optional. Set to MonetaryAmount to format the value as an amount and currency in the user
interface.

The PATotalPremium underwriting rule is an example that shows multicurrency. In PolicyCenter, you can view this
underwriting rule in Administration→Business Rules→Underwriting Rules. In the Personal Auto line of business, the
evaluator Gosu class (PA_UnderwriterEvaluator.gs) determines whether to raise PATotalPremium underwriting
issues.
As with other underwriting issues, the code that creates the issue determines the value for the issue. PolicyCenter
displays this value in the underwriting screens, therefore consider keeping the value (and approval) in the original
currency. In the base configuration, the value comparator for monetary issues does a conversion between currencies,
if needed. This conversion enables you to specify authority grants in a single currency per issue, yet have that grant
to apply to all currencies for the issue. Then PolicyCenter determines whether or not to raise an underwriting issue.
The UWIssueValueComparatorWrapper class in the [Link] package uses the
MonetaryGEValueComparatorWrapper and MonetaryLEValueComparatorWrapper classes to convert the currency
and compare monetary values.

See also

• “Configuring underwriting authority” on page 583

• Application Guide

Configuring authority profiles and multicurrency

For PolicyCenter users, you set the approval value and currency for these underwriting issue types in an authority
grant within an authority profile. Access authority profiles by navigating to Administration→Users & Security→Authority
Profiles in PolicyCenter.

See also

• “Configuring authority grants” on page 583

Implementing an exchange rate service

Each insurer has their own unique exchange rate requirements such as how often to refresh the exchange rate or
which market provides the rates. In some cases, the exchange rate market is not a market in the conventional sense,
but a set of rates specified by the company or one of its business associates. An insurer’s exchange rates may vary
by line of business. Certain policyholders may have custom rates which are negotiated with the insurer. Therefore,
the base implementation of PolicyCenter provides a simple exchange rate service which rates multicurrency policies.
In this simple implementation, PolicyCenter obtains the exchange rates from a static table containing rates for
conversion from one currency to another. Guidewire expects each insurer to implement their own exchange rate
service.

See also

• Application Guide
698 chapter 52: Configuring multicurrency
 Guidewire PolicyCenter 9.0.9 Configuration Guide

The Exchange Rate Service Plugin interface

The Exchange Rate Service plugin interface (IFXRatePlugin) is the interface for obtaining the exchange rate. In the
base configuration, the FXRateServicePlugin implements this interface. You can use the FXRateServicePlugin
implementation as a starting point for your own implementation of the IFXRatePlugin interface.
The IFXRatePlugin interface has the following methods:

Method Return value Description

canConvert Boolean For two currencies, this method returns true if you can convert from the first currency to the sec‐
ond currency.
getFXRate FXRate This method returns the rate for converting from one currency to another. You can optionally
specify:
• A date on which the rate was in effect
• The rate market from which to obtain the rate

The built‐in implementation of the Exchange Rate Service Plugin interface

The built-in implementation of the Exchange Rate Service Plugin (IFXRatePlugin) interface is the
FXRateServicePlugin plugin. This simple implementation gets exchange rates from a static table defined in the
plugin. This class is provided only as an example; it is not for production use. Although you can use this plugin as a
starting point, you must create your own implementation of the IFXRatePlugin interface.

Enabling multicurrency integration

You must perform certain tasks to enable multicurrency integration appropriately.
• “Set up currency-specific plans and authority limits” on page 699

Set up currency‐specific plans and authority limits

One of the administrative tasks you must perform when setting up BillingCenter is to create plans. Several of these
plans are currency specific, and therefore you must set up at least one plan for each currency. There are monetary
values that reflect various applicable fees and financial thresholds. For example, billing plans contain an invoice fee.
A Euro account must define the fee in euros. As another example, delinquency plans have monetary thresholds that
control when BillingCenter makes a policy delinquent. Such thresholds must be defined for each currency.
These currency specific administrative entities that need to be created in BillingCenter are:
• Billing plans
• Payment plans
• Commission plans
• Delinquency plans
• Agency bill plans
• Authority limits
BillingCenter requires all of these be defined to issue a policy in a given currency, except agency bill plans. You
must define agency bill plans for each currency in which you plan on issuing policies with agency billing. If you do
not define an agency bill plan for a given currency, Agency Bill will not appear in PolicyCenter as a choice for billing
method.

Set up billing plans in BillingCenter for multicurrency accounts

In BillingCenter, each account must have an associated billing plan. Billing plans determine how BillingCenter
handles automatic distributions, special circumstances such as low balance, and invoicing at the account level.
Billing plans are currency specific and therefore you must set up at least one billing plan in BillingCenter for each
currency.
Configuring multicurrency 699
Guidewire PolicyCenter 9.0.9 Configuration Guide

See also
• “Billing Plans” in the BillingCenter Application Guide

Set up payment plans in BillingCenter for multicurrency accounts

In BillingCenter, each policy must have an associated payment plan. Payment plans determine how payments are set
up and spread over the term of the policy. Payment plans are currency specific and therefore you must set up at least
one billing plan in BillingCenter for each currency. The payment plans that match the currency of a policy appear in
PolicyCenter as a list of choices for how to bill a policy.

See also
• “Payment Plans” in the BillingCenter Application Guide

Set up agency bill plans for multicurrency producer organizations

In PolicyCenter you set the currency for producer organizations through agency bill plans. PolicyCenter retrieves the
agency bill plans from BillingCenter. In a single currency system, you select an Agency Bill Plan on the Basics tab of
the Organization screen. In a multicurrency system, you select one or more agency bill plans on the Agency Bill tab.
Each agency bill plan specifies a currency.
When entering the Organizations or the New Organizations screens, PolicyCenter synchronizes with BillingCenter to
refresh the agency bill plans.

See also
• “Agency Bill Plans” in the BillingCenter Application Guide
• Application Guide

Set up delinquency plans in BillingCenter for multicurrency accounts

A BillingCenter delinquency plan defines a sequence of events to execute when a policy becomes past due. The
delinquency plan can be applied to the past-due policy only or to all policies in the account.
A special case exists when all policies in the account are considered delinquent and the account supports multiple
currencies. In this situation, the delinquency plan is applied only to the policies that use the same currency as the
policy that initiated the delinquency. In other words, only policies contained in the initiating policy’s currency silo
are considered to be delinquent. Other policies in the account that use a different currency (and are therefore in a
different currency silo) are not considered delinquent. This behavior describes the operation of the BillingCenter
base configuration. If you wish all policies in the multicurrency account to be considered delinquent, regardless of
their currency, BillingCenter can be configured to support that behavior.
Similarly, when a delinquent account is reinstated, the base configuration reinstates only the policies that reside in
the relevant currency silo. To reinstate all policies in the account, regardless of their currency, configuration can be
written to support that behavior.

See also
• “Delinquency Plans” in the BillingCenter Application Guide

Set up commission plans in BillingCenter in for multicurrency producer codes

In PolicyCenter, producer codes are associated with commission plans. Each commission plan is associated with a
currency. PolicyCenter retrieves the commission plans from BillingCenter. In a single currency system, each
producer code has a single commission plan. In a multicurrency system, a producer code must have multiple
commission plans, one for each currency.
When entering the Producer Codes or the New Producer Code screens, PolicyCenter synchronizes with BillingCenter to
refresh the commission plans for the current producer code.
700 chapter 52: Configuring multicurrency
 Guidewire PolicyCenter 9.0.9 Configuration Guide

See also
• “Commission Plans” in the BillingCenter Application Guide
• Application Guide

Set up authority limits in BillingCenter for multicurrency integration

Each user in BillingCenter can be assigned an authority limit profile. An authority limit profile specifies the types of
financial transactions the user is authorized to create or approve. The profile also specifies the maximum monetary
amount allowed for each financial transaction type.
BillingCenter supports multicurrency authority limits. If an integration includes Japanese yen, European Union
euros, and U.S. dollars, a separate authority limit must be created for each of the currencies. All three of the limits
can then be included in the same authority limit profile.

See also
• “Authority Limit Profiles” in the BillingCenter Application Guide

Configuring multicurrency 701

Guidewire PolicyCenter 9.0.9 Configuration Guide

702 chapter 52: Configuring multicurrency

chapter 53

Policy Term archiving

Archiving is the process of moving policy terms from the active PolicyCenter database to a document storage area.
You can still search for and retrieve archived policy terms, but they occupy less space in the active database while
archived.

Archiving in Guidewire PolicyCenter

PolicyCenter supports archiving policy terms as serialized streams of data, with one serialized stream per
PolicyPeriod entity in the term. Each serialized stream is an XML document. You can choose how to store the
XML documents in an external system. Store the data as files, as database binary large objects, or documents in a
document storage system.
From the user perspective, PolicyCenter archives or retrieves a policy term. A policy term is the
logical unit of archiving.
PolicyCenter does not store a policy term as a single XML document. Instead, PolicyCenter serializes and stores one
XML document for every PolicyPeriod graph in the policy term. A PolicyPeriod graph means one
PolicyPeriod object and its subobjects. The PolicyPeriod graph is the physical unit of archiving. PolicyCenter
archives each PolicyPeriod graph in the term sequentially in an internally-defined order. PolicyCenter stops
archiving that term if there are any errors with any PolicyPeriod.
After archiving, PolicyCenter deletes most PolicyPeriod subobjects. However, PolicyCenter retains the
PolicyPeriod entity instance and its associated entity instances of type EffectiveDatedFields and Document.
Additionally, in certain circumstances certain other objects are retained:
• PolicyCenter deletes Note objects associated with the job of the archived policy period if and only if it has no
associated activity.
• PolicyCenter deletes UWIssueHistory objects if and only if it is an auto-approved issue
• PolicyCenter deletes FormTextData objects only with the last remaining PolicyPeriod to archive in that term.
In other words, it is always deleted, but in the last database transaction along with the last remaining archived
PolicyPeriod in the term.
PolicyCenter documentation refers to a PolicyPeriod object as the root info object for that archived data. The
name root info object refers to the RootInfo delegate, which the PolicyPeriod entity type implements. Some
archiving APIs use the RootInfo object as a method argument or return type. For PolicyCenter, when you see
RootInfo, this refers to a PolicyPeriod instance.
After archiving, PolicyCenter makes the PolicyPeriod data effectively immutable while that period is archived.
However, within one policy term, at any given instant, it is possible that one or more periods are archived but not all.

Policy Term archiving 703

Guidewire PolicyCenter 9.0.9 Configuration Guide

From the user interface standpoint, PolicyCenter considers a given policy term archived if one or more of the
periods in the term is archived, even if not all are archived.

How PolicyCenter determines the date for archive eligibility

In the base configuration, PolicyCenter determines the date for archive eligibility as follows:
• If any open claims exist on the policy term, delay archiving by the value of ArchiveDefaultRecheckDays from
the current date.
• If any open jobs, open activities, or active messages exist on the policy term, delay archiving by the value of
ArchiveDefaultRecheckDays days from the current date.
• If any scheduled audits exist, delay archiving by the value of ArchiveRecentJobCompletionDays days from
initialization date of the last scheduled audit.
• If any active jobs based on policy periods from the policy term exist, delay archiving by the value of
ArchiveDefaultRecheckDays days from the current date.
• If there are recently completed jobs, delay archiving by the value of ArchiveRecentJobCompletionDays days
from the close date of the last completed job.
Both ArchiveDefaultRecheckDays and ArchiveRecentJobCompletionDays are configuration parameters defined
in file [Link].
If none of the above criteria apply or the dates calculated are prior to today, the archive date is the current date.
Otherwise, the archive date is the maximum date as calculated by the various conditions.

See also
• “Understanding the archiving plugins” on page 708
• Integration Guide

Batch processing and archiving

PolicyCenter has two types of batch processing that drive archiving operations:
• Archive Policy Term – Archives policy terms marked for archiving.
• Retrieve Policy Term – Restores archive policy terms marked for retrieval.
Note: PolicyCenter does not use the Archiving Item writer work queue.

Batch Processing to Run Prior to Running Archive Policy Term Batch Processing
PolicyCenter does not archive a policy term if the policy term is associated with one or more workflows. To more
effectively archive policy terms, run the following batch processing types to clean up workflows before archiving:
• Purge Workflow
• Purge Workflow Logs
• Workflow

See also
• System Administration Guide

Monitoring archiving activity

PolicyCenter provides server tools to help you monitor and supervise the archiving process:
704 chapter 53: Policy Term archiving
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Tool Description
Work Queue Info The Server Tools→Work Queue Info screen shows the status of the archive work queue. You can use tools on
this screen to run a work queue writer and to stop and restart workers.
Archive Info The Server Tools→Info Pages→Archive Info screen provides status information about the archiving process. The
screen includes information on the following:
• Entities archived
• Entities excluded because of business logic
• Entities excluded because of failure
The Archive Info screen provides tools to reset various archive items as well.
Domain Graph Info The Server Tools→Info Pages→Domain Graph Info screen provides information on the archive domain graph used
by PolicyCenter to construct the set of related entities to archive. The Warnings tab on this screen lists any
non‐fatal archive issues that occur during server startup.

See also
• “The PolicyCenter archive domain graph” on page 325
• System Administration Guide

Understanding errors in the archiving process

It is possible for the archiving process to generate errors:
• If an API or user interface operation attempts to open or work on an archived policy term or policy period,
PolicyCenter typically generates a PolicyTermInArchiveException exception.
• If an archive worker cannot archive a policy term for any reason, the worker marks the policy term with an
ExcludedFromArchive flag.
The Server Tools Archive Info screen Excluded from Archive value shows the number of policy periods that PolicyCenter
excluded from archiving.

See also
• System Administration Guide

Logging archiving activity

If enabled, PolicyCenter writes archive-related information to the system logs under the following circumstances:
• While processing the archive domain graph at server startup
• While performing an archive operation
If specified, PolicyCenter writes this information to the console log as well.
To configure archive logging, modify file [Link] to suit your business needs. Use the existing
loggers in the file as examples.

See also
• System Administration Guide

Archive configuration options

Archive data model
This topic describes the data model entities used for archiving.
Policy Term archiving 705
Guidewire PolicyCenter 9.0.9 Configuration Guide

Policy
The Policy entity has the following properties related to archiving:

Property Description
DoNotArchive Do not archive any of the terms for this policy. If you change this property from true to false, terms already
archived are not automatically retrieved.

PolicyTerm
The PolicyTerm entity has the following properties related to archiving:

Property Description
Archived Value is true if at least one policy period associated with this policy term is archived.
NextArchiveCheckDate The date to next evaluate this PolicyTerm for archiving. Value is null if archiving is to be checked at
the next opportunity.
RestoreRequests Array to PolicyTermRestoreRequest entity instances.

PolicyTermRestoreRequest
The PolicyTermRestoreRequest entity represents a request made to retrieve this term from the archive backing
store and restore it to the PolicyCenter application database. This entity has the following properties related to
archiving:

Property Description
PolicyTerm A foreign key to the policy term to retrieve from the archive.
Reason The reason provided by the user.
RequestingUser The user that initiated this request to retrieve the policy term.
ShouldCreateActivity A flag that indicates whether to create an activity after processing this request.

PolicyPeriod
The PolicyPeriod entity has the following properties related to archiving:

Property Description
Archived This value is true if this policy period is archived.
ArchiveDate The date on which archiving was attempted on the PolicyPeriod. Value is null if archiving has
never been attempted.
ArchiveFailure A foreign key to ArchiveFailure.
ArchiveFailureDetails A foreign key to ArchiveFailureDetails.

ArchiveSchemaInfo A foreign key to UpgradeDatamodelInfo, the schema version at which the PolicyPeriod was ar‐
chived. Value is null if it was not archived.
ArchiveState A type key that indicates the archive state of the graph. Values can be:
• archived – Graph has been archived
• retrieving – Graph is marked for retrieving
Locked The row is locked and cannot be edited. It is only possible to archive a locked policy period.

ArchiveFailure
The ArchiveFailure entity contains a short description of the reason that archiving failed.
706 chapter 53: Policy Term archiving
 Guidewire PolicyCenter 9.0.9 Configuration Guide

ArchiveFailureDetails
The ArchiveFailureDetails entity contains a detailed description of the reason that archiving failed.

Archive configuration parameters

Guidewire provides a set of configuration parameters in file [Link] that you use to enable and manage various
aspects of the archiving process. These configuration parameters are:
• ArchiveDaysRetrievedBeforeArchive
• ArchiveDefaultRecheckDays
• ArchivePolicyTermDays
• ArchiveRecentJobCompletionDays
• DomainGraphKnownUnreachableTables

See also
• “Archive parameters” on page 44

Archiving and the SQL Server database

Microsoft SQL Server 2014 introduced a new optimizer cardinality estimator. The use of this optimizer creates
suboptimal plans during archiving, which can eventually lead to deadlocks on SQL Server. Guidewire disables this
optimizer by adding a database hint at the end of the archiving UPDATE statement.
For a SQL Server database to use this hint, you must grant the sysadmin role to the database schema owner. Even if
you do not grant the sysadmin role to the database schema owner, the archiving process continues. However, not
granting this role can result in poor performance.

Gosu code and archiving

After archiving, PolicyCenter deletes most of the PolicyPeriod subtypes, but keeps the PolicyPeriod, its
associated EffectiveDatedFields, and optionally some other entities. The deleted subtypes are no longer
accessible through Gosu code. For more information about the entities that remain in PolicyCenter, see the
Application Guide.
If archiving is enabled and your code accesses policy periods, your code needs to check whether that policy period is
archived before attempting to traverse the subtypes. If your code attempts to traverse the subtypes in an archived
PolicyPeriod, PolicyCenter throws an exception.
If there is a need to change an archived policy period, you must retrieve the archived policy period from the archive
store.
In the default configuration, PCF files and code checks for archiving before traversing a policy period. For example,
you may see code checking for archiving in policy terms and policy periods such as:
• [Link]
• [Link] – If you are about to do a policy comparison, for example
• [Link]
A PolicyPeriod has been archived if the Archived bit is set to true.
The basedOn property of a given PolicyPeriod might be in a prior term, so that based-on policy period must also
be checked.

Displaying Jobs or Policies

In the default configuration, the JobForward and PolicyFileForward PCF files are used by other PCF files and
Gosu code to display a single job or policy. These PCF files figure out, among other things, whether or not the user
arrives at the wizard for a job or policy or the archived policy period screen instead.
Policy Term archiving 707
Guidewire PolicyCenter 9.0.9 Configuration Guide

A PCF file that displays or potentially modifies archivable entities calls the JobForward or PolicyFileForward
PCF file. These PCF files contain code to handle the display of an archived policy term or policy period. Care still
needs to be taken with actions (such as calculating differences or starting jobs) whose success is dependent on other
terms.

Jobs and Archiving

While writing Gosu code, be aware that PolicyCenter has the following restriction related to jobs and archiving:
• You cannot start a job on an archived policy term.
• You cannot start a job if there is a future archived policy term. You cannot start a job because an out-of-sequence
change may necessitate updates to future policy terms.
• You cannot archive a policy term if there is are open jobs in a previous term.

Search and Archiving

While writing Gosu code, be aware that search does not find properties on effective-dated entities removed from the
database through archiving. The search simply fails to return those archived rows. Search screens may need to be
aware of archiving and adjust the display when Include Archived or the like is selected.

Excluding a Policy from Archiving

The Policy entity has a DoNotArchive property. Users can manage the DoNotArchive property from the
application. You can also manage this property through the ArchiveAPI web service. To set the DoNotArchive
property requires the archivedisable and archiveenable privileges.

See also
• Application Guide
• Integration Guide

Understanding the archiving plugins

If you implement archiving, you must implement the following plugins.

Plugin interface Description Implementation class

IArchiveSource Provides methods to store and retrieve a serialized XML document that rep‐ PCArchiveSourcePlugin
resents one instance of the PolicyPeriod archive domain graph.
IPCArchivingPlugin Provides a single method to use to determine when to archive a policy term. PCArchivingPlugin

708 chapter 53: Policy Term archiving

chapter 54

Configuring personal data destruction

Note: The data destruction features described in these topics provide a set of features that help enable
insurers to comply with some of their data destruction requirements. These requirements may be
driven by insurers’ policies and practices, as well as by their interpretation of various regulatory
requirements. Such regulatory requirements may come from, for example, the European Union
General Data Protection Regulation (GDPR) or the New York State Cybersecurity Requirements for
Financial Services Companies law.
Data destruction is the process of requesting that data be destroyed, making the data impossible to retrieve. Data
destruction is typically initiated with a request that specifies a contact or user whose data is to be destroyed. In the
base configuration, PolicyCenter provides a web service that is intended to be called by an external application. You
use the external application to manage the destruction of the data across Guidewire applications.
Data destruction can be implemented as either purging or obfuscation of data, depending on the data to be destroyed.
Purging is a form of data destruction that completely removes contact data and policy or account data from
PolicyCenter. There can be multiple objects associated with the policy, account, or contact that are also removed as
they are detected by traversing the entity domain graph.
Obfuscation is a form of data destruction that permanently overwrites fields, such as user contact fields, with data
that replaces the original data. Some actual removal of data can also be involved, such as deletion of an address
referenced only by one user.
For example, obfuscation might be required if destroying the data affects policies that cannot be destroyed. Purging
user data for a former employee could affect hundreds or even thousands of accounts, policies, policy terms, and so
on. Therefore it makes more sense to obfuscate the data for the user and leave the other data alone.

Data destruction configuration parameters

In the base configuration of PolicyCenter, data destruction is not enabled. You must set the following configuration
parameters in [Link] to enable data destruction:
PersonalDataDestructionEnabled
Set this parameter to true to enable destruction of personal data. In the base configuration, this parameter is
false.
Note: The server will not start if both PersonalDataDestructionEnabled and
DisableDomainGraphSupport are true.
ContactDestructionRequestAgeForPurgingResults
Used by the RemoveOldContactDestructionRequest work queue to determine the age of
PersonalDataDestructionRequest objects that have a status of Finished. In the base configuration, this
parameter is set to 10 days.
Configuring personal data destruction 709
Guidewire PolicyCenter 9.0.9 Configuration Guide

ArchiveReferenceTrackingEnabled
During an archive operation, if this value is true, PolicyCenter stores references to objects outside an archive
graph in a specific table. The purpose of this table is to allow for the purging of non- archive graphs.
For PolicyCenter, set this value to true. If you have already archived policies before setting this parameter to
true, then you must run the ArchiveReferenceTrackingSync batch process in order to add reference tracking
for previously archived documents. The ArchiveReferenceTrackingSync batch process must first complete for
each previously archived document before you can use personal data purge.

See also
• “Identifying archived objects that affect destruction of data” on page 714
• Integration Guide
• Application Guide

Data model configuration for data destruction

There are data model configurations that apply to the objects being destroyed. Some are general configurations, and
some are specific to purging or obfuscation.
This topic includes:
• “DestructionRootPinnable delegate” on page 710
• “Do Not Process flag” on page 711
• “Display keys for data destruction messages” on page 711
• “Obfuscatable delegate” on page 711
• “Obfuscator interface” on page 712
• “Marking entity fields for obfuscation” on page 712

DestructionRootPinnable delegate
An entity that implements this delegate gets a Do Not Destroy flag that can be checked as part of the destruction
process. An entity that is intended to be the root of an entity graph must implement the DestructionRootPinnable
delegate if it is to be used in personal data destruction.

Root of entity graph

The destruction process uses entity domain graphs to determine what to destroy. An object that implements the
DestructionRootPinnable delegate and the RootInfo delegate is the root of an entity domain graph.

Do Not Destroy flag

A Do Not Destroy flag is provided in the DestructionRootPinnable delegate. If an entity implements this
delegate, instances of the entity have a DoNotDestroy Boolean field. The default value of this field is false.
Note: If this field is on a Contact or a subtype of Contact, it is maintained only in PolicyCenter.
Even if the contact is linked, the field is not sent to ContactManager, nor is it updated from
ContactManager.
In the base configuration of PolicyCenter, the entities Contact, Account, Policy, PolicyTerm, and PolicyPeriod
all implement the DestructionRootPinnable delegate and therefore have DoNotDestroy Boolean fields.
You can set this field in an instance of any of these entities, such as a specific contact or policy, by using the method
setDoNotDestroy. The method takes the following parameters:
Boolean value
Set the flag to false to allow destruction of the entity, or to true to prevent destruction of the entity.
710 chapter 54: Configuring personal data destruction
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Callable<String> getDescription
A block that returns either a String to be used as a history event comment or null.
PolicyCenter checks this flag as part of the destruction process. For example:
• If DoNotDestroy is set to true for the contact, the associated accounts, policies, and policy periods are not
destroyed.
• The contact specified in a personal data destruction request has two accounts, and only one of the accounts has
DoNotDestroy set to true. The other account has DoNotDestroy set to false. PolicyCenter does a partial purge
and deletes the account that has DoNotDestroy set to false.

Do Not Process flag

A Do Not Process flag is provided by the Operable delegate. If an entity implements this delegate, the entity than
has a DoNotProcess boolean field that can you use as needed in your configuration of PolicyCenter. This flag is not
used in the base configuration.

Display keys for data destruction messages

There are a number of display keys defined for use by the personal data destruction code. For example, error
messages use display keys. You can see them in Guidewire Studio by navigating to
configuration→config→Localizations and double-clicking display_en_US.properties. In this file, press Ctrl+F,
enter the search string PersonalData, and then click the down or up arrow button to go to each search result in the
file. For example:
[Link] = Obfuscation for '{0}' is not supported

Obfuscatable delegate
If you intend to use obfuscation with an entity, it must implement the Obfuscatable delegate. This delegate is
necessary to support marking fields as personally identifiable information with the PersonalData tag.
Note: A Delegate is a reusable type that defines database columns, an interface, and a default
implementation of that interface. A delegate permits an entity to implement an interface while
delegating the implementation of that interface to another class, that of the delegate. Each delegate
type provides additional columns on the affected tables.
The Obfuscatable delegate has one column, ObfuscatedInternal, which cannot be set in Gosu code. This
limitation exists because after the ObfuscatedInternal column has been set to true, it must not be set to false.
Note: If the parent of an entity implements the Obfuscatable delegate, all child entities inherit that
implementation.
The Obfuscatable delegate extends the interfaces Obfuscator and ObfuscatablePublicMethods. These interfaces
provide the following methods:
markAsObfuscated
Marks the entity instance as having been obfuscated by setting ObfuscateInternal to true on the delegate.
isObfuscated
Returns true if obfuscate has been called and completed successfully. Otherwise returns false.
obfuscate
Obfuscates the columns that are marked for obfuscation on this object.
obfuscateSimple
Works the same as obfuscate, but for objects that are not EffDated.

Configuring personal data destruction 711

Guidewire PolicyCenter 9.0.9 Configuration Guide

Obfuscator interface
If you intend to use obfuscation with an entity, the entity must implement the Obfuscator interface. Each entity that
implements the Obfuscator interface must also designate an implementation class, such as
UserContactObfuscator.
Note: If the parent of an entity implements the Obfuscator interface, all child entities inherit that
implementation, including the implementation class. You can override the parent implementation by
declaring implementsInterface in the child entity.
For example, in the base configuration, [Link] has the following definition:
<extension xmlns="[Link]
entityName="UserContact">
<implementsInterface
iface="[Link]"
impl="[Link]"/>
<column-override
name="EmployeeNumber">
<tag
name="PersonalData"
value="ObfuscateDefault"/>
</column-override>
</extension>

In the base configuration, an entity can implement the Obfuscatable delegate but have an Obfuscator interface
implementation of UnsupportedObfuscator. In this case, even if the entity is marked as obfuscatable, any attempt
to obfuscate it results in an UnsupportedOperation exception.
To be able to obfuscate an entity, you must use or write a suitable Obfuscator, such as one that extends
PCPersonalDataObfuscator.

Note
If the configuration of implementsInterface is coded incorrectly, then the server startup verification check will not
be able to detect the error. The error will be caught when the application is starting up instead.
For example, suppose you coded the impl part of implementsInterface with a misspelled class name,
OfuscatorImpl2:
<implementsEntity
name="Obfuscatable"/>
<implementsInterface
iface="[Link]"
impl="[Link].ObfuscatorImpl2"/>

The server startup verification check cannot detect this error. When the application starts up, it generates a Class Not
Found exception. If you see this exception on server startup, correct the code in the configuration.

See also
• “Personal data obfuscator classes” on page 723
• “Implementing the Obfuscator interface in an entity” on page 722

Marking entity fields for obfuscation

If an entity implements the Obfuscatable delegate, it is likely that you will want to tag some of its fields for
obfuscation. For each field that contains personal data, add the tag PersonalData. The value of the tag determines
the kind of obfuscation that will be applied to the field's contents. In the base configuration, two values are defined
in the typelist [Link]:
ObfuscateDefault
The field's contents are replaced with the default value or null if no default value is defined.
ObfuscateUnique
You specify how the field's contents are replaced.
712 chapter 54: Configuring personal data destruction
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Note: If a field is not nullable, it must be given a default value if you mark it for obfuscation. For one
of these fields, obfuscation will fail if you tag the field obfuscate_default and provide no default
value.
In the base configuration, all the entities that implement the Obfuscator interface have fields tagged PersonalData.
Additionally, many of the fields tagged as PersonalData are in .etx files to enable you to modify them. For
example, the Name field of Contact is defined in [Link] as follows:
<column-override
name="Name">
<tag
name="PersonalData"
value="ObfuscateUnique"/>
</column-override>

In addition, the following delegates have fields tagged PersonalData. An entity that implements one or more of
these delegates does not have to implement Obfuscator and Obfuscatable unless you want the entity to support
obfuscation.
• [Link]
• [Link]
• [Link]
• [Link]
• [Link]
• [Link]
• [Link]

See also
• For a list of entities that implement Obfuscator, see “Implementing the Obfuscator interface in an entity” on
page 722.

Entity domain graphs

PolicyCenter uses entity domain graphs to define the aggregate cluster of associated objects that it treats as a single
unit for purposes of data destruction. Each aggregate cluster has a root and a boundary.
Note: There are multiple entity domain graphs in PolicyCenter. Therefore, PolicyCenter uses a
pinnable hierarchy to determine the order in which a personal data destruction request uses the domain
graphs. See “Pinnable hierarchy in PolicyCenter” on page 715.
• The root is a single specific entity that the aggregate cluster contains. The root entity is the main entity in the
graph. A root entity is application-specific and must implement DestructionRootPinnable. Pinnable root is
another term for one of these root entities.
In PolicyCenter, the root entities are Policy, Account, PolicyTerm, PolicyPeriod, PolicyTerm, and Contact.
• The boundary defines what is inside the aggregate cluster of objects. It identifies all the entities that are part of
the graph.
In PolicyCenter, the boundary defines the entities that relate to an Account or Policy, such as jobs and effective
dated fields, or to a Contact,such as an address.
The unit of work for personal data destruction is a single instance of the domain graph, such as an Account and all
its associated entities.
To enforce the boundaries of the domain graph, all objects participating in the destruction process must implement
the following delegate:
• Extractable – All entities in the domain graph must implement the Extractable delegate.
You cannot define a new entity domain graph for use in personal data destruction. However, you can configure an
existing entity domain graph in the same way that you configure the archiving domain graph. For example, use the
archivingOwner data model attribute and the CrossDomainPublicID data model tag. If personal data destruction is
Configuring personal data destruction 713
Guidewire PolicyCenter 9.0.9 Configuration Guide

enabled, then at server startup, if there are validation issues with any entity domain graph, those issues are logged
and the server fails to start. This process is similar to how archiving domain graph validation works.

See also
• “The PolicyCenter archive domain graph” on page 325
• “<delegate> elements and related data object types” on page 180

Identifying archived objects that affect destruction of data

Destroying personal data can require navigating the entity domain graphs and possibly purging objects other than
the root objects. Therefore, it is possible that a purge can be affected by archived objects.
For example, purging a contact’s data affects several policy periods, one of which is archived.
If there are references from any archived documents to any object instances in the entity graph, the objects cannot be
destroyed until the archived objects are restored from the archive. Therefore PolicyCenter requires that a table of
archived objects be built and maintained to use in determining if references from archived objects exist.
If you already have archived policy periods in an existing installation of PolicyCenter, you must run the
ArchiveReferenceTrackingSync batch process once to build the initial table of archived objects.
Before running this batch process, you must set ArchiveReferenceTrackingEnabled to true. The batch process
adds entries to a reference table for every archived object that does not yet have an entry.

IMPORTANT Running this batch process is required to use the personal data destruction feature.
Running it can slow your system noticeably. It is suggested that you run it before deploying the
upgraded Guidewire application.

In the base configuration, PolicyCenter calls

[Link] to determine if the
ArchiveReferenceTrackingSync batch process has run. This method is called from:
PersonalDataContactDestructionWorkQueue
The class that implements the DestroyContactForPersonalData work queue.
PersonalDataDestructionNotifyExternalSystemsWorkQueue
The class that implements the NotifyExternalSystemForPersonalData work queue.
After you set the configuration parameter ArchiveReferenceTrackingEnabled to true, as you archive policy
periods, they are added to the reference table of archived objects. This table is checked whenever a personal data
destruction request is initiated.
The utility class [Link] provides methods for determining:
• If an object or set of objects is referred to by an archived document.
• Which archived documents refer to a given object or set of objects.

Data Protection Officer

A Data Protection Officer is expected to be available to handle problems with data destruction. Therefore, in the
base configuration, there is a Data Protection Officer role to which users can be assigned.

Data Protection Officer permissions

In the base configuration of PolicyCenter, the Data Protection Officer role has two permissions,
requestcontactdestruction and editobfuscatedusercontact. A user named DataProtection Officer with login
dpofficer, which has the Data Protection Officer role, is available in the sample data.
In the base configuration, PolicyCenter screens prevent a user from editing obfuscated user contacts if the user does
not have permissions to do so. In addition, PolicyCenter prevents a user without the correct permissions from adding
714 chapter 54: Configuring personal data destruction
 Guidewire PolicyCenter 9.0.9 Configuration Guide

obfuscated user contacts to or removing them from groups and roles. You can create additional permissions and
configure PolicyCenter to further limit editing of obfuscated objects.

Notifying the Data Protection Officer

The PersonalDataDestruction plugin interface provides a method that enables notification of the Data Protection
Officer, notifyDataProtectionOfficer.
In the base configuration, the class that implements the PersonalDataDestruction plugin interface,
PCPersonalDataDestructionPlugin, overrides the notifyDataProtectionOfficer method and notifies data
protection officers when a destruction request has failed.
The action performed by the notifyDataProtectionOfficer method is defined in the class
NotifyDataProtectionOfficerVisitor. This class creates an activity that uses the activity pattern
personal_data_destruction_error and assigns the activity to each user present in the system that has the Data
Protection Officer role. If no users are found with the Data Protection Officer role, in the base configuration, an
exception is thrown.
Note: PolicyCenter can purge retired pinnable roots from the system. However, if there are any issues
that occur while purging this data, an activity will be created against the retired root. This activity will
be listed in the user interface for users with the Data Protection Officer role. However, the user will
not be able to view the details of the activity because the root is retired.

Data destruction purge configuration

Purging is the process of completely removing contact, account, policy, policy term, and policy period data from the
PolicyCenter database. There can be multiple objects associated with a contact, account, policy, policy term, and
policy period that are also removed as they are detected by traversing the entity domain graph.

IMPORTANT Data destruction proceeds regardless of the work items that might be pointing to an
object to be destroyed. If you have a work item in progress, ensure that it is complete or removed
before any object used by the work item is destroyed.

See also
• “Entity domain graphs” on page 713
• “Data obfuscation in PolicyCenter” on page 721

Pinnable hierarchy in PolicyCenter

Because there are multiple entity domain graphs, it is necessary to use a hierarchy of domain graphs in PolicyCenter.
The PolicyCenter pinnable hierarchy defines how entity domain graphs interact.
Each pinnable root defines its parents and children in an adapter. For PolicyCenter, all the pinnable roots can have
multiple children. For parents, all the pinnable roots have only one parent except for account, which can be
associated with multiple contacts.
The following figure shows an example of a pinnable hierarchy of domain graphs. Each box in the diagram is the
root of a domain graph. Depending on how many contacts are on the account or how many accounts a contact is on,
or both, the objects in the diagram could change. However, the order of the hierarchy would be the same.

Configuring personal data destruction 715

Guidewire PolicyCenter 9.0.9 Configuration Guide

Contact Contact Contact

Account Account

Policy Policy Policy

Policy Term Policy Term Policy Term Policy Term Policy Term

PersonalDataPurgeTree
In PolicyCenter, entity domain graphs enable purging of Contact, Account, Policy, PolicyTerm, and
PolicyPeriod objects. The class PersonalDataPurgeTree creates a tree that stores the relationship of the relevant
nodes to determine if the specified pinnable root can or cannot be purged.
The PinnableDomainMethods class defines methods that can be used to find parents, children, and descendants of
the current object in the tree, like getPinnableChildren, getPinnableDescendants, and getPinnableParents.
The purge API can then be called, and best effort purging is performed. What gets purged is determined by the
results of multiple passes through the domain graphs configured for each pinnable root. Purging is determined by the
domain graphs configured for each pinnable root. The Account domain graph is a super-set of the Policy domain
graph, and the Policy domain graph is a super-set of the PolicyTerm domain graph. However, the Contact domain
graph intersects with the other domain graphs, but is not a super-set of the Account domain graph.
Note: Even though policy period and policy term are pinnable roots, in the base configuration,
PolicyCenter does not provide the ability to purge them directly. Personal data purge must get to them
through a higher level graph in the pinnable hierarchy.
The tree is constructed by using the pinnable hierarchy to determine the parents and children of each pinnable node.
Starting from the specified start node, all its ancestors are included. For each of the descendants, if there are multiple
parents, such as an account with multiple contacts, those parents will be included in the graph. Multiple parents are
included because the ability of the parents to be destroyed can affect the start node and the purgeability of the
children.
Purgeability for each node in the tree is then computed by performing a multi-step process for evaluating the nodes
in the tree. Values are propagated to the appropriate ancestors, descendants, and siblings.
In the base configuration, PolicyPeriod and PolicyTerm are not destroyable if they have a sibling that is not
destroyable.
Domain graphs are nested for Account, Policy, PolicyTerm, and PolicyPeriod. Consequently, purging at the
account level removes roots below it and does not require an explicit call to each of the pinnable roots below the
account. Based on the tree and ability of each node to be destroyed, the minimum set of roots necessary to purge all
destroyable roots is calculated and stored in the tree.
The main place that you control the objects that can be purged is in your implementation of
PersonalDataDestructionPlugin. In the class, you define MUST_NOT_DESTROY, MAY_DESTROY, and MUST_DESTROY
return values for shouldDestroyObject methods.
716 chapter 54: Configuring personal data destruction
 Guidewire PolicyCenter 9.0.9 Configuration Guide

The result of this process is one of the following values defined in PersonalDataPurgeStatus:
• CompletePurgeExecuted
• PartialPurgeExecuted
• NothingPurged
• ExceptionThrownOnPurge
• PurgeHasNotBeenAttempted

See also
• “Personal data destruction plugin implementation classes” on page 720

Traversing the pinnable hierarchy for personal data purge

To identify entities that can be purged, PolicyCenter makes multiple passes through the pinnable hierarchy.
PolicyCenter establishes the initial purge graph and then handles both the disposition of each node, like
MUST_NOT_DESTROY, and any Do Not Destroy flags. Based on these passes through the pinnable hierarchy,
PolicyCenter can perform a partial purge if necessary and maintain data integrity.
In general, the steps involve:
1. Starting with the root of the purge request, form a graph by traversing up and down the pinnable hierarchy.
See “Discovering the entity purge graph” on page 717.
2. Compute disposition of the root node and all descendants of the root. Exclude entities marked
MUST_NOT_DESTROY and their ancestors.
See “Traversing the purge tree to determine disposition” on page 718.
3. Exclude all ancestors of archived policy periods that are descendants of the root.
See “Traversing the purge tree to determine archived policy periods” on page 718.
4. Propagate the Do Not Destroy flag of any entity discovered while building the initial graph.
See “Propagating the Do Not Destroy flag” on page 718.
5. Purge entities that remain purgeable.
See “Purging eligible entities” on page 719.
6. Report conflicts to the Data Protection Officer. For example, an entity that is marked MUST_DESTROY is not
purgeable because it has a descendant with Do Not Destroy flag that is set.
See “Reporting purge tree conflicts” on page 719.

See also
• “Pinnable hierarchy in PolicyCenter” on page 715
• “PersonalDataPurgeTree” on page 716

Discovering the entity purge graph

In this initial step of the purge process, PolicyCenter makes an initial traversal through the pinnable hierarchy to
discover the graph on the basis of which purge logic will execute. PolicyCenter traverses the relationships between
contacts, accounts, policies, policy terms, and policy periods.
This traversal starts at the initial root of the personal destruction request and marks each entity as purgeable. It uses
the following logic:
• Contact traverses to all related Account entities.
• Account traverses to all related Policy entities and all related Contact entities (primary and non-primary).
• Policy traverses to all related PolicyTerm entities.
• PolicyTerm traverses to all related PolicyPeriod entities.
Configuring personal data destruction 717
Guidewire PolicyCenter 9.0.9 Configuration Guide

See also
• “PersonalDataPurgeTree” on page 716

Traversing the purge tree to determine disposition

This second step of purge graph traversal identifies entities that are eligible for purging. PolicyCenter excludes from
purging entities that have a MUST_NOT_DESTROY disposition and entities whose presence is required to preserve
data consistency. For an example of the latter, an entity in the graph that has a descendant that is not purgeable is
excluded in this pass.
The traversal starts from the initial root of the personal destruction request and visits all descendant nodes.
For each visited node, PolicyCenter invokes disposition logic and marks the node not purgeable if any of the
following are true:
1. The node has a disposition of MUST_NOT_DESTROY.
2. The node is an ancestor of a node that has a disposition of MUST_NOT_DESTROY.
3. The node is a PolicyPeriod or PolicyTerm sharing a Policy with another PolicyPeriod or PolicyTerm
that has a disposition of MUST_NOT_DESTROY. For example, two pairs of PolicyPeriod and PolicyTerm
objects are children of a Policy and are adjacent nodes to one another in the graph.
Sets of related Policy, PolicyTerm, and PolicyPeriod objects are kept or purged together. If a single object
in the set has a disposition of MUST_NOT_DESTROY, the entire set is kept. For example, a single PolicyTerm that
has a disposition of MUST_NOT_DESTROY prevents the purge of any Policy, PolicyTerm, and PolicyPeriod
objects in the set.

See also
• “PersonalDataDestruction plugin interface” on page 720

Traversing the purge tree to determine archived policy periods

In this step of the purge graph traversal, PolicyCenter excludes from purging any policies that have an archived
policy period and entities whose presence is required to preserve data consistency. For an example of the latter, an
entity in the graph that has a descendant that is not purgeable is excluded in this pass.
The traversal starts from the initial root of the personal destruction request and visits all descendant nodes.
For each visited node, PolicyCenter marks the node not purgeable if any of the following are true:
• The node is a Policy or PolicyTerm with an archived PolicyPeriod.
• The node is an ancestor of a Policy with an archived PolicyPeriod: for example, Account and primary Contact.
• The node is a PolicyTerm or PolicyPeriod sharing a Policy with an archived PolicyPeriod.
Sets of related Policy, PolicyTerm, and PolicyPeriod objects are kept or purged together. If a PolicyPeriod in the
set is archived, the entire set is kept.

Propagating the Do Not Destroy flag

In this step of the purge graph traversal, PolicyCenter processes any Do Not Destroy flags on entities in the
hierarchy. A Do Not Destroy flag on Contact, Account, and Policy propagates to all ancestors and descendants, but
not to siblings. A Do Not Destroy flag on PolicyTerm and PolicyPeriod does propagate to sibling PolicyTerm and
PolicyPeriod objects that share a Policy.
The detailed traversal logic follows.
1. Mark nodes with a Do Not Destroy flag as not purgeable.
2. Mark all descendant nodes of nodes with a Do Not Destroy flag as not purgeable.
3. Mark all ancestor nodes of nodes with a Do Not Destroy flag as not purgeable.
4. Mark as not purgeable all sibling PolicyPeriod and PolicyTerm objects sharing a Policy with a PolicyPeriod or
PolicyTerm object that is marked Do Not Destroy.
718 chapter 54: Configuring personal data destruction
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Sets of related Policy, PolicyTerm, and PolicyPeriod objects are kept or purged together. If a single object in
the set has a Do Not Destroy flag, the entire set is kept. For an example, a single PolicyTerm with a Do Not
Destroy flag prevents the purge of any Policy, PolicyTerm, and PolicyPeriod in the set.

See also
• “Do Not Destroy flag” on page 710

Purging eligible entities

After the purge graph has been built and all nodes have been marked as needed, PolicyCenter purges eligible entities
as follows:
1. Purge all purgeable nodes and associated non-root entities.
2. When purging a policy, if the AccountContactRole entity and the AccountContact entity on the account
associated with the policy have been orphaned, they are purged also.
Contacts whose only link to the graph is the policy being purged are unlinked from the graph in this step. If
the contact was marked not purgeable as a result of propagation of the Do Not Destroy flag, the contact
becomes purgeable again. If the contact had a Do Not Destroy flag that was directly set, that flag is left alone
and the contact remains not purgeable.
3. Purge any contacts that no longer have links with the graph and have a disposition other than
MUST_NOT_DESTROY.

Reporting purge tree conflicts

Entities with a disposition of MUST_DESTROY might remain after the final step of the purge process. Typically these
entities are not purged for data integrity reasons. For example, a descendant of an entity has a MUST_NOT_DESTROY
disposition.
PolicyCenter reports these entities to the Data Protection Officer by using an activity.

See also
• “Data Protection Officer” on page 714

Defining the destroyer

The PCPersonalDataDestroyer class extends PinnablePersonalDataDestroyer, which implements the
PersonalDataDestroyer interface. PCPersonalDataDestroyer overrides methods that determine how a
destruction request is carried out.
In the base configuration, the PCPersonalDataDestroyer class destroys contacts, accounts and policies. If a contact
is of type UserContact, the contact is obfuscated by calling [Link]. Otherwise the class uses the internal
implementation of PersonalDataDestroyer that purges the entity graph of the contact, account, or policy.
In the base configuration, PCPersonalDataDestroyer provides the destroyer that is obtained by the
PCPersonalDataDestruction plugin implementation class call to getDestroyer. PCPersonalDataDestruction is
registered by default in the PersonalDataDestruction and PersonalDataDestructionForPCRootsPlugin plugin
registries.

See also
• Integration Guide

PersonalDataPurge event
When a personal data purge of certain objects is committed, PolicyCenter generates a PersonalDataPurge event
that you can respond to in an Event Fired rule to send a message. For example, you might want to send a message to
a downstream system.
Configuring personal data destruction 719
Guidewire PolicyCenter 9.0.9 Configuration Guide

PolicyCenter generates a PersonalDataPurge event when a Contact, Account, Policy, PolicyTerm, or

PolicyPeriod purge is committed as part of a personal data purge. The EventFired rule PersonalDataPurge, in
the EventMessage rule set category, creates a message in response to the firing of the PersonalDataPurge event.
This message actually has no transport or destination, but you can define them or create your own rule.

See also
• Rules Guide

Specifying which objects in the graph can be destroyed

The PersonalDataDestruction plugin interface provides basic methods that define which objects can be destroyed
and how to contact the Data Protection Officer. You define a plugin implementation class to define this behavior and
register it in the [Link] plugin registry.

PersonalDataDestruction plugin interface

This interface provides the following methods for implementation by a PolicyCenter plugin implementation class:
PersonalDataDisposition shouldDestroyRoot(
Pinnable root, Collection<Pinnable> descendants, Pinnable origin);
PersonalDataDisposition shouldDestroyUser(UserContact userContact);
void notifyDataProtectionOfficer(Pinnable root, String title, String message, Date dateOfError);
void notifyExternalSystemsContactHasBeenPurged(
String AddressBookUID, String requestor, String requestID);
PersonalDataPurgeContext createContext(PersonalDataPurgeContext context);
void prepareForPurge(PersonalDataPurgeContext context);
void postPurge(PersonalDataPurgeContext context);
PersonalDataDestroyer getDestroyer();

In the base configuration, PolicyCenter registers the PCPersonalDataDestructionPlugin class as the default class
that implements PersonalDataDestruction, which prevents destruction of any of the pinnable root entities. A
more realistic starting point for your purge definition is the SamplePersonalDataDestructionPlugin class.

See also
• “Personal data destruction plugin implementation classes” on page 720
• “Entity domain graphs” on page 713

Personal data destruction plugin implementation classes

In the base configuration of PolicyCenter, the PCPersonalDataDestructionPlugin class is registered as the class
that implements both the PersonalDataDestruction plugin interface and the
PersonalDataDestructionforPCRoots plugin interface. This class provides default handling for destruction of
pinnable root entities in the base configuration.
SamplePersonalDataDestructionPlugin is the class you can use as an example when you implement your own
personal data destruction class to define both getDestroyer and how specific pinnable roots are handled. You must
then register your implementation class with both plugin registries, [Link] and
[Link].
These two classes define methods that control destruction of pinnable root entities by returning one of the following
values defined in the enum PersonalDataDisposition:
MUST_NOT_DESTROY
The object must not be destroyed. If this value is in conflict with a MUST_DESTROY value in the domain graph, the
Data Protection Officer must get involved.
MUST_DESTROY
The object must be destroyed.
MAY_DESTROY
The object can be destroyed.
720 chapter 54: Configuring personal data destruction
 Guidewire PolicyCenter 9.0.9 Configuration Guide

PCPersonalDataDestructionPlugin
In the base configuration, PCPersonalDataDestructionPlugin calls getDestroyer to obtain the destroyer defined
in PCPersonalDataDestroyer. Additionally, this class prevents data destruction by returning MUST_NOT_DESTROY
for all calls to destroy pinnable root entities. For example:
override function shouldDestroyPolicyTerm(
policyTerm: PolicyTerm, descendants: Collection<DestructionRootPinnable>,
origin: DestructionRootPinnable): PersonalDataDisposition {
return MUST_NOT_DESTROY
}
override function shouldDestroyPolicy(
policy: Policy, descendants: Collection<DestructionRootPinnable>,
origin: DestructionRootPinnable): PersonalDataDisposition {
return MUST_NOT_DESTROY
}
override function shouldDestroyAccount(
account: Account, descendants: Collection<DestructionRootPinnable>,
origin: DestructionRootPinnable): PersonalDataDisposition {
return MUST_NOT_DESTROY
}
override function shouldDestroyContact(
contact: Contact, descendants: Collection<DestructionRootPinnable>,
origin: DestructionRootPinnable): PersonalDataDisposition {
return MUST_NOT_DESTROY
}

SamplePersonalDataDestructionPlugin
You can use the class SamplePersonalDataDestructionPlugin as a guide for writing your own personal data
destruction code.
SamplePersonalDataDestructionPlugin has examples that use other return values than MUST_NOT_DESTROY for
the pinnable root entities. For example:
The method shouldDestroyUser determines if there is a User object associated with the UserContact object. If
not, it returns MUST_DESTROY. If the database query indicates that the users’s credential is active, the method returns
MUST_NOT_DESTROY. Otherwise, the credential is not active and destroying the UserContact is permitted, so the
method returns MAY_DESTROY.
The method shouldDestroyPolicy checks:
• If the policy is retired. If so, the method returns MUST_DESTROY.
• A number of scenarios that would prevent the policy from being destroyed, and returns MUST_NOT_DESTROY if
any of them are true, such as:
◦ Any open activities
◦ Any policy terms marked MUST_NOT_DESTROY
◦ Any pinnable dependents marked MUST_NOT_DESTROY
• If any pinnable dependents are marked MUST_DESTROY. If so, the method returns MUST_DESTROY.
• Returns a default value of MAY_DESTROY if the previous checks show that nothing is marked MUST_NOT_DESTROY
or MUST_DESTROY.
There are additional overridden methods for shouldDestroyPolicyTerm, shouldDestroyAccount, and
shouldDestroyContact that you can review to see how these pinnable root entities might be handled.

See also
• “DestructionRootPinnable delegate” on page 710
• “Entity domain graphs” on page 713

Data obfuscation in PolicyCenter

In general, personal data destruction in PolicyCenter is done through removal of database records. However, the
entities associated with an employee who works in your installation of PolicyCenter are not conducive to removal
Configuring personal data destruction 721
Guidewire PolicyCenter 9.0.9 Configuration Guide

because of the way data creation and changes are recorded. In particular, objects in the database are connected to the
user that created them, and, in many cases, the user that last modified them.
Because an employee is likely to create or modify hundreds of thousands of objects, it would be computationally
expensive to locate all those objects in the database. It would also be expensive to change those references to
something else. It is not necessary to destroy the relationship between all the work that the employee performed and
the fact that it was performed by a specific employee. If the employee's personally identifiable data is destroyed, the
set of objects associated with the employee can remain and not violate the need to destroy personal data.
Therefore, in the base configuration, PolicyCenter obfuscates data related to UserContact objects.

Obfuscated objects
Each object can indicate whether it has been obfuscated in its Obfuscated flag. The system has no special handling
for objects that have gone through obfuscation. Obfuscated objects act like any other active object in the system
regarding search results, batch processes, and so on. You can implement additional functionality to filter obfuscated
beans, according to PolicyCenter configuration capabilities. In your obfuscation implementation, you must take into
account how your custom obfuscation might affect existing processes in PolicyCenter.

Preupdate rules
Data obfuscation works the same as a normal entity editing, so changes made during obfuscation will trigger
preupdate rules for entity types that have rules registered.

Implementing the Obfuscatable delegate in an entity

To be obfuscatable, an entity must implement the Obfuscatable delegate. If the entity implements
DestructionRootPinnable, the DoNotDestroy field is set to false by default, which enables the entity to be
obfuscated.
If an entity implements this delegate, the fields to be obfuscated must be tagged PersonalData.
Note: Tagging is not supported for array references, nor does obfuscation cascade automatically
through foreign keys. Arrays and cascading through foreign keys must be handled in Gosu code in the
Obfuscator implementation class.

See also
• “Marking entity fields for obfuscation” on page 712
• “Implementing the Obfuscator interface in an entity” on page 722
• “Obfuscatable delegate” on page 711
• “Do Not Destroy flag” on page 710

Implementing the Obfuscator interface in an entity

To be obfuscatable, an entity must implement the Obfuscator interface and specify an implementation class other
than UnsupportedObfuscator. For example, use a class that extends PCPersonalDataObfuscator.
The entities that have Obfuscator implementations that support obfuscation are:
• Credential – CredentialDefaultObfuscator
• OfficialID – OfficialIDObfuscator
• PCOfficialID – PCOfficialIDObfuscator. This entity is a subtype of OfficialID and inherits that entity’s
implementation of the Obfuscation delegate.
• User – UserDefaultObfuscator
• UserContact – UserContactObfuscator. This entity is a subtype of Person and inherits that entity’s
implementation of the Obfuscation delegate.
722 chapter 54: Configuring personal data destruction
 Guidewire PolicyCenter 9.0.9 Configuration Guide

The following entities implement the Obfuscatable delegate, and in the base configuration their Obfuscator
interface implementation is UnsupportedObfuscator:
• Address
• AddressReplacement
• AffinityGroup
• Contact
• ContactAddress
• ContactCategoryScore
• ContactContact
• ContactTag
• OutboundLocationRiskAssessmentTempStore

See also
• “Obfuscator interface” on page 712

Personal data obfuscator classes

The personal data obfuscation classes, all of which ultimately inherit from PersonalDataObfuscator, define
obfuscation for specific entities. The specific class that an entity uses is defined in its implementsEntity element
for [Link].
This topic includes:
• “Personal data obfuscation class hierarchy” on page 723
• “PersonalDataObfuscator” on page 724
• “UnsupportedObfuscator” on page 725
• “PersonalDataObfuscatorUtil” on page 725

See also
• “Implementing the Obfuscator interface in an entity” on page 722
• “Obfuscator interface” on page 712
• “Marking entity fields for obfuscation” on page 712

Personal data obfuscation class hierarchy

PolicyCenter provides the following class hierarchy for personal data obfuscation:

Configuring personal data destruction 723

Guidewire PolicyCenter 9.0.9 Configuration Guide

PolicyCenter Personal Data Obfuscator Class Hierarchy

PersonalDataObfuscator

PCPersonalDataObfuscator DefaultPersonalDataObfuscator

RootPinnableObfuscator OfficialIDObfuscator UserContactLinkedObfuscator

UserContactObfuscator PCOfficialIDObfuscator UserDefaultObfuscator CredentialDefaultObuscator

UserContactDefaultObfuscator
Legend

A B A is a subclass of B

There are two main branches in this class hierarchy:

• DefaultPersonalDataObfuscator and its subclasses UserContactLinkedObfuscator,
UserDefaultObfuscator, CredentialDefaultObuscator, and UserContactDefaultObfuscator are available
in all core applications. Its subclasses define base configuration behavior to enable obfuscating User,
UserContact, and Credential and related objects. For example:
◦ UserContactLinkedObfuscator overrides the shouldObfuscate method. That method calls the
shouldDestroyUser method defined in the PersonalDataDestruction plugin to get the setting for
UserContact. For example, in the base configuration the setting is MUST_NOT_DESTROY.
◦ UserDefaultObfuscator overrides a beforeObfuscate method. That method throws an exception if the
user’s credential is active because that means the user is still active. If the user is not active, the method calls
[Link] and [Link] and removes the arrays of join entities
AttributeUser and UserRegion.
◦ UserContactDefaultObfuscator attempts to obfuscate or remove any contact addresses, official IDs,
category scores, and tags associated with the UserContact that can be destroyed.
◦ CredentialDefaultObfuscator overrides the beforeObfuscate method, which stops the obfuscation if the
credential is active.
• PCPersonalDataObfuscator is the base class of a set of classes used to define obfuscation of specific entities,
such as UserContact and PCOfficialID. You can extend this class to define how obfuscation works on an
entity. You specify the class in the entity’s implementsEntity declaration for the Obfuscation class. For
example:
◦ UserContactObfuscator attempts to remove any associated primary address, contact addresses, and official
IDs from the UserContact object. Additionally, the method getObfuscatedValueForPersonalDataField
defines obfuscation behavior for a field that is tagged ObfuscateUnique.

PersonalDataObfuscator
PersonalDataObfuscator is the parent class for the obfuscator classes. It is a general class that obfuscates the
fields for any entity. You are required to extend this class or one of its subclasses when implementing obfuscation
for entities that do not have obfuscator classes defined.
724 chapter 54: Configuring personal data destruction
 Guidewire PolicyCenter 9.0.9 Configuration Guide

PersonalDataObfuscator handles setting the obfuscation for effdated and non-effdated fields. If you have tagged
the entity fields PersonalData with value ObfuscateUnique, and there is no need to do any special preprocessing
of the fields, you can use this class.
The following methods are provided:
isObfuscated
Checks the field ObfuscatedInternal and returns true or false depending on the value.
obfuscate
Finds all the columns that are marked for obfuscation on this object.
• If the object is an instance of EffDated then the method obfuscates all versions of that column on the
EffDated object.
• Otherwise, the method sets the field value with the obfuscatedValue.
• Before obfuscating the column, the method calls preProcessPersonalDataFieldBeforeObfuscating to
do any preprocessing. If the column is marked PersonalData with a value of ObfuscateDefault, the
method sets the value to either null or the default value. If the column is marked PersonalData with a
value of something other than ObfuscateDefault, the method calls
getObfuscatedValueForPersonalDataField. That method passes the tag value, and you must provide the
object that the method uses to obfuscate the field.
• At the end, the method sets the ObfuscateInternal column to true by using
[Link].
obfuscateSimple
Works the same as obfuscate, but for objects that are not EffDated.
If you want to do preprocessing before obfuscation, you can extend PersonalDataObfuscator or a subclass of this
class and override the beforeObfuscate method. If you want to change the value of the personal data field before
obfuscation, you can override getObfuscatedValueForPersonalDataField.
The method getObfuscatedValueForPersonalDataField(Obfuscatable bean, IEntityPropertyInfo
personalDataField, String tagValue) defines default obfuscation behavior for fields that are tagged
OfuscateUnique and ObfuscateDefault.

See also
• “Marking entity fields for obfuscation” on page 712

UnsupportedObfuscator
This Java class provides a default implementation for any entity that implements the interface Obfuscator and
declares UnsupportedObfuscator as the implementation. When obfuscate is called, this class throws
unsupportedOperationException for the field.

PersonalDataObfuscatorUtil
This Gosu class is in the same package as the personal data obfuscation classes, [Link].
The class implements the method computeMD5Padding. If a personal data field has a PersonalData tag with value
ObfuscateUnique, this method is called to obfuscate the field.
The method computes an MD5 String based on the type of entity and the PublicID, and then returns that string so
the field can be obfuscated with that value.
For example, DefaultPersonalDataObfuscator calls this method in its
getObfuscatedValueForPersonalDataField method when the field’s PersonalData tag has the value
PersonalDataTagValue.TC_OBFUSCATEUNIQUE.Code.
See also
• “Marking entity fields for obfuscation” on page 712
Configuring personal data destruction 725
Guidewire PolicyCenter 9.0.9 Configuration Guide

Data destruction test tool

PolicyCenter includes a tool to help you test data destruction on a contact, policy, or account and test your
implementation of data destruction. You can use this tool during development.

IMPORTANT Do not include this tool in a production system.

To access this tool, log in to PolicyCenter, press Alt+Shift+T, and select Internal Tools→Personal Data Destruction Test.
The tool enables you to enter a contact public ID, an account number, or a policy number or policy public ID and
then:
• Click Preview Purge to see the domain graph nodes that the code traverses and the disposition for each node.
The disposition is the return value for the shouldDestroyObject methods you defined in your plugin
implementation class for the PCPersonalDataDestruction plugin.
• Depending on the object you want to test, click Purge Contact, Purge Account, or Purge Policy to attempt to purge all
objects in the graph.

See also
• “Personal data destruction plugin implementation classes” on page 720

726 chapter 54: Configuring personal data destruction

Part 9

Guidewire PolicyCenter job

configuration
Guidewire PolicyCenter 9.0.9 Configuration Guide
chapter 55

Configuring jobs

Configuring PolicyCenter jobs involves making changes to the product model, Gosu classes and rules, page
configuration files (PCF files), wizards, configuration parameters, plugins, and sometimes workflows. Each can be
configured based on your business requirements. It is the combination of these elements that allows you to create or
modify a policy.
Note: In PolicyCenter, the user interface uses the term policy transaction to refer to submissions,
policy changes, and other policy transactions. Policy transactions are implemented as jobs in the data
model, and referred to as jobs in PCF files, Gosu classes, and other configuration files. Therefore, the
configuration documentation refers to policy transactions as jobs.
In contrast to jobs, the product model defines the types of policies that you can offer to your customers. Each
product can contain one or more lines of business offering various coverages. For more information, see the
Application Guide.

Common ways to configure jobs

The following topics provide more detail on common ways that you can configure jobs (policy transactions).

Wizards for jobs

A wizard is a type of PCF file that contains a series of user interface screens. Wizards collect information and
perform operations while guiding the user through a complex business transaction.
Each job (policy transaction) has a wizard associated with it. For example, the submission job has the
[Link] file which contains the steps for collecting information about a submission. The wizard
pre-qualifies the applicant, collects policy information, performs risk analysis, reviews the policy, views a quote,
prints forms, and sets up billing.
Each wizard step has a screen such as the New Submissions, Pre-Qualification, Policy Info, Quote, and Submission Bound
screens. Each screen is a PCF file that defines the screen and its component parts.
As the user moves through the wizard, the wizard calls functions in the job code for processing and may indirectly
access rule sets and workflows. The job code contains most of the code for the job and also interacts with the rule
sets and workflows. In some cases, the wizard accesses the workflow directly.
You can modify wizards to gather the data that you want users to collect while processing a job. In Studio, you can
access the PCF and wizard files for jobs by navigating to Page Configuration→pcf→job.

See also
• “Introduction to page configuration” on page 363
Configuring jobs 729
Guidewire PolicyCenter 9.0.9 Configuration Guide

Gosu classes for jobs

The Gosu job code contains most of the programming logic for the job (policy transaction). In Studio, you can view
the code for each job type by navigating to Configuration→gsrc→gw→job. The types of files that make up the job
code are:
• Job Class – Each job type defines a subclass of the JobProcess class. For example, the [Link]
file defines the SubmissionProcess class. This class defines the steps of a job. It also defines the core
functionality and core properties of the job, such as request quote or bind. The job class is marked as @Export, so
you can modify the class directly.
Be careful when you modify the job class because it is the primary controller for how jobs work. Modifications
can easily cause the job process to break.
For information about classes, see the Gosu Reference Guide.
• Job Subclass – Rather than modifying the job class directly, you can indirectly change or adds methods and
properties to the job by defining a subclass. You may find it easier to maintain changes in a subclass rather than
the job class because the subclass contains your code only.
For example, to create a subclass for the submission class, you create a file such as
[Link] that extends the SubmissionProcess class:
class YourCompanySubmissionProcess extends SubmissionProcess {
...
}

Be careful when you modify a subclass because it modifies the job process and can easily cause the job process
to break.
If you create a subclass, you must modify the job process customization plugin. For more information, see the
Integration Guide.
• Enhancement – You can use a Gosu enhancement to add methods and properties to a class. These methods and
properties are available to all objects of the enhanced type. The default application contains some enhancements
to the job entities, and you may modify these or add your own enhancements. Enhancements often contain code
that is not the core functionality of the job and that you can customize to meet your business needs.
If you need to modify the enhancement for the submission class, edit [Link]:
enhancement SubmissionEnhancement : Submission {
...
}

IMPORTANT The job class code may change in future releases. Therefore, be sure to use comments in
the code to clearly delimit and document your changes. As part of moving to a new release, you may
have to implement (not just upgrade) your changes again. Review your modifications to the job class
and enhancement as well your modifications to job subclasses.

See also
• Gosu Reference Guide

Job rule sets

Another way to add business logic for jobs and workflows is through rule sets. You can use rules to check for a
simple set of conditions and then follow with a set of simple actions. Rule sets are grouped by function for the
purpose of customizing a process, such as a submission, to follow established business procedures.

730 chapter 55: Configuring jobs

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Note: Instead of using rules, you can also add your business logic in the Gosu job process code.
Inserting logic in the job code allows for a more centralized job flow and is easier to debug. The
default application puts most of the business logic in the Gosu job process code.

See also
• Rules Guide

Job workflows
PolicyCenter uses workflows for asynchronous steps and for automated processes. In the default installation, only
renewal and cancellation jobs have workflows. Cancellation has a workflow that handles the potential waiting
period between the time the cancellation is scheduled or issued and completed. Renewal has workflows to handle
automated renewals.
The workflow calls and is called by the job code and by rules in the rule sets. In some cases, the wizard calls the
workflow and sends control back to the wizard.

See also
• “Guidewire workflow” on page 445

System configuration parameters for jobs

There are configuration parameters that determine the behavior of the various jobs. You can find these parameters in
[Link] which you can view in Studio by navigating to configuration→config. For more information about these
parameters see:
• “Miscellaneous job-related parameters” on page 73
• “Job expiration parameters” on page 71

Changing jobs to expired status

A job in an Expired status indicates that it has been closed due to inactivity. An expired job is in a terminal state, and
you cannot reopen it. However, you can clone an expired job into a new, open job.
The Job Expire batch process changes jobs from New, Draft, or Quote status to Expired if they have passed an
expiration threshold. In the default configuration, the Job Expire batch process expires submission jobs with these
statuses that are at least seven days past the effective date of the policy. In addition to submission jobs, you can
enable expiration for other job types. You can configure the expiration threshold as the number of days past the
effective date or the creation date.
Expiring jobs at an appropriate time can impact searching and reporting, and have a critical impact on business
operations including purging and archiving. Select an expiration threshold that is consistent with the intended
behavior of impacted business operations.
A job is expired after a sufficient and configurable interval of time has elapsed. A policy version can be expired
when its status is either New, Draft, or Quoted. If the policy version is already closed by being withdrawn, issued, or
not taken, then it will not be expired because it is already closed. When a policy version expires, its status changes to
Expired. You can view the status in the Submission Manager screen or in the toolbar if you are in the submission
wizard. An branch is not editable.

Configuring the job expire batch process

The Job Expire batch process triggers job expiration. The batch process, by default, runs every day at 6 A.M. as
configured in the [Link] file. The batch process expires all versions of a policy in a job that can be
expired.
Configuring jobs 731
Guidewire PolicyCenter 9.0.9 Configuration Guide

You can configure both the scheduling and the amount of time that must elapse before expiration. Configure the
batch process by modifying the following parameters in the [Link] file:
• JobExpirationEffDateThreshold is the number of days past the effective date of the policy version before a
job can be expired. PolicyCenter compares this value with the effective date of the policy version, the default
value is 7 (a week).
• JobExpirationCreateDateThreshold is the number of days past the create date of the submission before a
submission can be expired. The create date is the day the submission entered the system. PolicyCenter compares
this value with [Link].

See also
• The System Administration Guide for more information on how to configure the Job Expire batch process.
• “Job expiration parameters” on page 71

Configuring job history events

History events record the progress of a job (policy transaction). PolicyCenter displays history events in the History
menu link in the Policy tab. In the default configuration, the submission and renewal jobs log history events. In
addition, creating a new account and changing an account creates history events. You can add history events to a job
by using the createCustomHistoryEvent method of the Job class. This method has two signatures:
• The first createCustomHistoryEvent method creates a History with the given CustomHistoryType and
description. The description argument is wrapped in a block so that it can be localized to the primary
language of the policy or account.
function createCustomHistoryEvent(type : CustomHistoryType, description : block() : String) : History

• The second createCustomHistoryEvent method is similar, but allows you to provide the originalValue and
newValue fields of the History.
function createCustomHistoryEvent(type : CustomHistoryType, description : block() : String,
originalValue : String, newValue : String) : History

For examples, view the job classes, such as [Link], in Studio.

The History screen displays a Type and Description for each event. In Studio, type names are defined in the
[Link] typelist. Descriptions are defined in Display Keys. The submission job display keys are
defined in [Link] entries. The renewal job display keys are defined in [Link]
entries. You can localize both the type and description.

Example Code that Localizes the Event Message to the Primary Language
The description argument of createCustomHistoryEvent is wrapped in a block so that it can be localized to the
primary language of the policy or account. This example describes the code that does this.
Code in [Link] calls the [Link] method:
private function startScheduledCancellation(processDate : Date) {
...
if (InitialNotificationsHaveBeenSent) {
[Link](CustomHistoryType.TC_CANCEL_RESCHEDULE, \ ->
[Link](processDate))
...
}

The second parameter of createCustomHistoryEvent method is defined as:

description : block() : String

The description parameter is a method, block(), that returns a String. In code above, the parameter is the
[Link] method.
The createCustomHistoryEvent method contains code which temporarily switches the locale to the primary
language of the policy and runs the description method. Therefore, the history event message is localized to the
language of the policy.
732 chapter 55: Configuring jobs
 Guidewire PolicyCenter 9.0.9 Configuration Guide

See also
• Gosu Reference Guide
• Globalization Guide

History events in the default configuration

In the default configuration, history events are logged when changes are made in an account, job, and policy term.

Account
PolicyCenter logs the following history events in an account:
• An Account created event is created when new accounts are created through the user interface or the AccountAPI.
• An Account changed event is created:
◦ When the account status changes from Pending to Active at the start of a submission.
◦ When the account holder is changed to a different contact. The event contains the old and new values.
You can add additional history events by configuring PolicyCenter.

Job
PolicyCenter logs the following history events for jobs (policy transaction):
• Cancellations
◦ A Cancel reschedule event is created when a cancellation is rescheduled.
• Policy change
◦ A PolicyChange created event is created when the job is created.
◦ A PolicyChange Effective Date change event is created when the edit effective date of the policy change changes.
• Questions
◦ An Answer changed event is generated when you change an incorrect answer to a blocking question to a correct
answer.
• Renewals
◦ A Renewal event is created for numerous events in a renewal job. Since renewals are typically automated, the
histories provide insight into the progress of the job. The Renewal event is created:
– When an automated renewal is escalated or manually edited.
– When a user presses the Renew, NonRenew, Not taken, or Issue Now buttons.
– When the automated renewal enters the pending renew, pending non-renew or pending not taken states.
– If the product is no longer available and the renewal will be non-renewed.
– When the renewal is quoted.
– When the renewal is withdrawn.
– When the renewal completes issuance, non-renewal, or not taken.
• Rewrite
◦ A Rewrite created event is created when the rewrite job starts.
• Submissions
◦ A Submission bound event is generated when the job is bound.
◦ A Submission created event is generated when the job is created.
◦ A Submission decline event is generated when the job is declined.
◦ A Submission issued event is generated when the job is issued.
◦ A Submission quoted event is generated when the job is quoted.
Configuring jobs 733
Guidewire PolicyCenter 9.0.9 Configuration Guide

Policy Term
PolicyCenter logs the following history event for policy terms:
• Pre-renewal
◦ A Pre-renewal event is created when a user sets the pre-renewal direction of a policy.
◦ A Pre-renewal event is created when a user non-renews a renewal. Although the non-renewal action occurs in
the renewal job, the history event is added to the PolicyTerm. The history description in the user interface is
made by concatenating certain pre-defined strings when the user adds or removes a non-renewal explanation
pattern.

Configuring history search criteria

You can configure the search criteria for history events in the Gosu class [Link].

See also
• Application Guide

Multiple revision jobs and the job selected branch property

To support multi-revision jobs (policy transactions), there is a property [Link], which indicates for
multi-revision jobs which branch is the selected branch. Knowing which branch is the selected branch is important
especially where there is more than one non-withdrawn branch in the job.
There is always a selected branch for any job. The selected branch is always one of the non-withdrawn branches, if
one or more remain. This makes the selected branch a safe way to obtain a PolicyPeriod from a Job. The selected
branch may or may not be the one that the user is actively modifying in the user interface. The selected branch
depends upon the user’s actions and any business logic that has been implemented. In some display and reporting
logic, the selected branch is the one that is used when more than one branch exists.
The SelectedVersion property is an edge foreign key from Job to PolicyPeriod. In the database, this creates a
join table called pc_jobpolicyperiod where the OwnerID column points to the job, and the ForeignEntityID
property points to the PolicyPeriod.
If you withdraw a revision from a multi-revision branch and there is only one non-withdrawn branch, PolicyCenter
automatically sets that branch to the active branch.
In the user interface for multi-revision jobs, you can select one revision by clicking Selected.

Selecting the underwriting company through segmentation

Guidewire PolicyCenter provides the ability to set the underwriting company for a policy on the Policy Info page for
Issuance, Rewrite, Renewal, and Submission jobs.
• If the user has the requisite underwriting permission (Multiple company quote), then PolicyCenter displays a list
of valid underwriting companies. The user can then select from the list and set the underwriting company.
• If the user does not have the necessary underwriting permission, then PolicyCenter displays an Autoselect button
instead.

Segmentation Example
Segmentation classes determine the segmentation, and, therefore, the available underwriting companies for a policy.
Large insurers typically license more than one subsidiary to underwrite policies on behalf of the insurer. The
primary reason for having multiple subsidiaries is to accommodate state regulatory requirements. (Many states do
not allow insurers to have more than one set of rates per underwriting company.) Therefore, if an insurer desires to
offer multiple sets of rates in that state, the insurer must file each set of rates under a separate underwriting company
for that state.
734 chapter 55: Configuring jobs
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Underwriters typically profile an account to determine the segment (category) into which an account falls. The
segment determines which underwriting company actually underwrites the policy. By extension, segmentation sets
the rates for which an account is eligible. The underwriter then uses appropriate set of rates to quote the policy.
For example, a workers’ compensation insurer can segment accounts into three different segments:
• High hazard
• Medium hazard
• Low hazard
The insurer has three underwriting companies corresponding to each of the segments. To generate a quote for the
policy, an underwriter indicates the underwriting company with which to place the policy. The rating engine takes
this information and uses it to calculate a quote for the policy with the appropriate set of rates.
In the following example from WC_SegmentEvaluator, segmentation sets the segmentation level for any policy
written for the state of Hawaii to high risk.
override property get IsHighRisk() : boolean {
return _policyPeriod.[Link] == TC_HI
}

Segmentation classes
The following Gosu classes implement segmentation:
• SegmentEvaluator – The interface
• AbstractSegmentEvaluator – Implements the SegmentEvaluator interface
• Subclasses – DefaultSegmentEvaluator and line specific ones like WC_SegmentEvaluator that is created from
PolicyLineMethods#createSegmentEvaluator.

PolicyPeriodBaseEnhancement
The [Link] enhancement ([Link]) contains
code for auto-selecting an underwriting company. In particular, it contains the following method:
autoSelectUWCompany

Guidewire intends that you customize this enhancement to meet your specific business needs.
This method contains simple logic for determining the best underwriting company for the PolicyPeriod based on
segment and lowest price.
A user triggers the autoSelectUWCompany method within PolicyCenter if the user clicks Autoselect for underwriter.
(As mentioned, this button is available only if the user does not have the Multiple company quote underwriting
permission.)
You set this method on PolicyPeriod in Studio, in any of the following PCF files:
• IssuanceWizard_PolicyInfoDV
• RenewalWizard_PolicyInfoDV
• RewriteWizard_PolicyInfoDV
• SubmissionWizard_PolicyInfoDV
To see this in the base configuration, open one of these files (IssuanceWizard_PolicyInfoDV, for example). Then,
find the Autoselect button on the PCF page and select it. View the action property for this widget (at the bottom of
the page). You see the following:
[Link]()

getUWCompaniesForStates
Use the following method to return a set of underwriting companies based on the effective dates and all the states
needed for the PolicyPeriod.
Configuring jobs 735
Guidewire PolicyCenter 9.0.9 Configuration Guide

[Link](boolean allStates)

For the allStates parameter:

• If true, the method returns only the underwriting companies that are valid for all states for the PolicyPeriod. For
example, suppose that the company requesting the policy does business in three different states (Colorado, New
Mexico, and Arizona). You might, therefore, want to find only those underwriting companies that can do
business in all three of those states.
• If false, the method returns underwriting companies that are valid for any state for the PolicyPeriod. For
example, suppose that you have the same company that does business in Colorado, New Mexico, and Arizona.
This time, you only want to find the set of underwriting companies that do business in at least one of those states.
You might want this, for example, if you wanted to split the policy between multiple underwriting companies
based on the state.
To verify that you have a valid underwriting company, use the following method:
[Link](true).contains(myUWCompany)

736 chapter 55: Configuring jobs

chapter 56

Configuring submissions

This topic describes how to configure submission jobs (submission policy transactions).
Note: In PolicyCenter, the user interface uses the term policy transaction to refer to submissions,
policy changes, and other policy transactions. Policy transactions are implemented as jobs in the data
model, and referred to as jobs in PCF files, Gosu classes, and other configuration files. Therefore, the
configuration documentation refers to policy transactions as jobs.

See also
• “Configuring jobs” on page 729
• “Selecting the underwriting company through segmentation” on page 734
• Application Guide

Configuring submissions overview

Use Studio to view and edit the Gosu classes and other files related to the renewal process.
Key files include:
• Gosu classes such as: [Link] class defines and begins the new submission process. You
can view and edit this class by navigating in Studio to Classes→gw→job, and finding the appropriate class.
• Gosu enhancement files such as: [Link]. This enhancement allows you to augment
classes and other types with additional methods and properties. An example is the addToGroup method which
groups it into the appropriate Submission group or creates a new one if a valid group does not exist.
• Page configuration files (PCF files) such as [Link] or
SubmissionWizard_PaymentScreen.pcf.
• Typelists such as JobGroup, or QuoteType.
Note: Since the submission process for any insurer can be configured based on business requirements,
all discussions apply to the default application only.

Submission process Gosu class

Gosu classes contain the code which primarily controls the submission process. In Studio, open
[Link] class in the [Link] package. This is the primary class for submissions. The job classes are
part of the default application.
The [Link] class contains the main actions involved in a submission. This class extends
NewTermProcess which extends the JobProcess class. The JobProcess class contains methods that enable you to
Configuring submissions 737
Guidewire PolicyCenter 9.0.9 Configuration Guide

get the job, the policy period, and a quote if it exists. It cancels any open activities on the submission, auto assigns
the user role, and checks to see if the job can be expired, withdrawn, or approved by an underwriter. It also checks to
see if the job can be started as new.
The [Link] starts a new submission and assigns a requestor and producer. The beginEditing
method moves a new submission to Draft status. Segmentation classes determines the available underwriting
companies for a policy.
Next, the submission process determines whether quoting can be initiated. The process determines if the branch can
be quoted in its current state by calling the canRequestQuote method. It also determines whether the submission
needs to be reviewed by an underwriter. If the submission began as a quick quote, it also converts it to a full
application. That in turn allows a job to be bound bindOnly and issue.
After PolicyCenter starts the bind process for the submission (branch), the submission may be rejected, marked for
review by an underwriter, or returned to Draft for additional editing. Otherwise, binding begins, which puts the
submission in the Binding status, updates the policy number, and sends an event for additional processing.
To complete binding, PolicyCenter calls the finishBinding method. This method completes the binding of a policy
period without issuing it. The policy period is marked as bound and the job is finished. However, if issuance is being
held, then PolicyCenter promotes the branch to the main policy period. Branches with no hold status must go
through the finishIssuing method. This method promotes the policy period by marking it Bound and the
completes job.
After issuing a submission, the user can bill the submission. The billing system plugin interface
IBillingSystemPlugin defines the contract between PolicyCenter and the billing system. For example, the billing
plugin implementation sends messages to the billing system about new billing instructions associated with a new
submission.
Note: The submission job no workflows because it has no background processes. PolicyCenter uses
workflows only for background processes.

Modifying the Submission Process

If you need to change or add methods to the submission process, you can edit the job class directly or create a
subclass (such as [Link]).
For more information about job classes and job subclasses, see “Gosu classes for jobs” on page 730.
If you create a subclass, you must modify the job process customization plugin. For more information, see the
Integration Guide.

Submission enhancements
There are other submission enhancements that contain additional functionality. You can modify these files.
• [Link] – This enhancement creates a copy of a submission and commits it. However,
PolicyCenter does not validate the copied submission during the commit.
In the copyPolicyPeriod method, you can insert code for any additional copying. For fields that you do not
want to copy, you can erase or reset them to default values.
For entities that you do not want to copy, you can implement the PolicyPeriod plugin method
returnTypesToNotCopyOnNewPeriod. In addition, you can implement the postCopyBranchIntoNewPolicy
method of this plugin which is called just after the copy. See the Integration Guide.
The [Link] method groups a submission job into the appropriate submission
group or creates a new one if a valid group does not exist.
• [Link] – This enhancement returns an array of the producers of the
submissions in the submission group. It also verifies, through the canAnySubmisssionSendLetter method, if
any submission in the batch can have a letter generated for it. If it does, then you see that option in the user
interface. Lastly, there is a sendConfirmationLetter that is a placeholder for implementing through integration,
a confirmation letter. Its purpose is to send a confirmation letter with every possible submission in the batch.
For more information about job enhancements, see “Gosu classes for jobs” on page 730.
738 chapter 56: Configuring submissions
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Submission integration
PolicyCenter integrates with many types of external systems through a diverse toolbox of services that can link
PolicyCenter with custom code and external systems. This topic describes web services and plugins that the
submission job uses.

Submission web services

JobAPI primarily adds an activity to a job by using an activity pattern. It also has methods to find and withdraw
jobs.
PolicyPeriodAPI is a web service for performing various operations on policy periods within PolicyCenter. There
are methods to add the following:
• Add a note to the policy and policy period
• Add a document to the policy period
• Add a referral reason code to the policy period
WorkflowAPI is a web service for performing various operations on workflows within PolicyCenter. It can:
• Start an action (by invoking a trigger) to advance the workflow to the next step.
• Resume a workflow or all the workflows. The workflow engine can attempt to advance the workflow (or all
workflows) to the next step. If there is an error, then it is logged.
• Suspend a workflow.

Submission plugins
Submissions use the following plugins.

Name Description
IAccountPlugin This account plugin interface contains methods for detecting existing accounts, performing name
clearance, generating account numbers, and doing risk reservation.
IBillingSystemPlugin This plugin notifies an external system about billing events.
IEffectiveTimePlugin This plugin determines the initial time component of effective/expiration dates (the
PeriodStart/PeriodEnd dates) for a policy period when starting a new job. Submission is one of
the affected jobs. All of the methods of this interface have a PolicyPeriod parameter, which can
be used to access additional information that might be used to determine the desired time, such
as:
• The line or lines of business
• The base jurisdiction
• Other revisions
The return value from each method is a Date, with its time component, HH:mm:ss, set to the de‐
sired time. The plugin discards the day component, dd/MM/yyyy. As a convenience, each method
returns null to leave the time component set to the default (midnight).
IJobNumberGenPlugin This plugin generates a new unique job number.
AccountLocationPlugin For account locations and policy locations, customize how PolicyCenter:
• Determines that two locations are the same
• Clones a location
IPolicyNumGenPlugin This plugin returns an identifier for a new period of a policy. The policy number may vary from
period to period. Call this plugin for the initial period of a policy as part of a Submission job. You
can also call this plugin if you want to generate a new identifier when renewing or rewriting a
policy.

Configuring submissions 739

Guidewire PolicyCenter 9.0.9 Configuration Guide

Name Description
IPolicyPeriodDiffPlugin This plugin does the following:
• Compares two policy periods, returning a list of DiffItems representing the differences
between them. The following call the compareBranches method:
◦ Multi‐version quote
◦ Comparing PolicyPeriods of a Policy
◦ Comparing Jobs of a Policy
• Filters a list of DiffItems that originate from the database.
IPolicyPeriodPlugin This plugin mainly calculates period end dates and creates the job process for that period.
IVinPlugin For a VIN (Vehicle Identification Number), the getVehicleInfo method returns the model,
make, year, and color of vehicle.

See also
• The Integration Guide for information about these plugins

Expiring submissions
The Job Expire batch process changes submission jobs from New, Draft, or Quote status to Expired if they have passed
an expiration threshold. In the base configuration, the batch process expires submission jobs with these statuses that
are at least seven days past the effective date of the policy. The batch process, by default, runs every day at 6 A.M.
as configured in the [Link] file. The batch process expires all versions of a policy in a job that can
be expired. If the policy version is already closed by being withdrawn, issued, or not taken, then it will not be
expired.

See also
• “Changing jobs to expired status” on page 731

Submission configuration examples

The following examples show the configuration of features from the base application, and provide guidance on how
to configure the features to meet your requirements.

Configuring the copy submission feature

You can copy any single PolicyPeriod on a submission. To modify the code, open the
[Link] in the [Link] package in Studio. Find the method copyPolicyPeriod.

740 chapter 56: Configuring submissions

chapter 57

Configuring issuance

This topic describes how to configure issuance jobs (issuance policy transactions).
Note: In PolicyCenter, the user interface uses the term policy transaction to refer to submissions,
policy changes, and other policy transactions. Policy transactions are implemented as jobs in the data
model, and referred to as jobs in PCF files, Gosu classes, and other configuration files. Therefore, the
configuration documentation refers to policy transactions as jobs.

See also
• “Selecting the underwriting company through segmentation” on page 734

Configuring issuance overview

The Gosu class, [Link], contains the main logic of an issuance job.
The beginEditing method starts the process of issuing by moving the policy to Draft status so it can be changed if
necessary. Like the submission job, it also invokes segmentation.
The issue method starts issuance for the policy period and withdraws any other active periods. The policy has an
Issuing status. The method also sends the policy to the [Link] class. The
FormInferenceEngine serves as the main access point for the rest of the application logic into the form inference
logic.
Note: The issuance job has no workflows because it has no background processes. PolicyCenter uses
workflows only for background processes.

Modifying the issuance process

If you need to change or create new methods in IssuanceProcess class, you can edit the class directly or create a
subclass (such as [Link]).
For more information about job classes and job subclasses, see “Gosu classes for jobs” on page 730.
If you create a subclass, you must modify the job process customization plugin. For more information, see the
Integration Guide.

Issuance integration
Issuance integrates with many types of external systems through a diverse toolbox of services and APIs that can link
PolicyCenter with custom code and external systems. This topic describes APIs, plugins, and events that the
Configuring issuance 741
Guidewire PolicyCenter 9.0.9 Configuration Guide

issuance job uses. There are multiple integration points that an issuance job requires. Most likely, you will integrate
to a print issuance system.

Issuance web services and plugins

The issuance job has the following web services and plugins.

Issuance web services

The issuance job has no web services. The JobAPI and PolicyPeriodAPI apply to jobs in general.

Issuance plugins
The issuance job uses the following plugin.

Billing System Plugin

When you complete an issuance policy transaction in the PolicyCenter user interface, PolicyCenter calls the
finishIssuing method, and the method performs some final checks. The method changes the policy status to
Bound and invokes the IBillingSystemPlugin.
The billing system plugin interface, IBillingSystemPlugin, defines the contract between PolicyCenter and the
billing system. This plugin is the primary mechanism for PolicyCenter to get information from a billing system or to
notify the billing system of changes to a policy.

742 chapter 57: Configuring issuance

chapter 58

Configuring renewals

This topic describes how to configure renewal jobs (renewal policy transactions).
Note: In PolicyCenter, the user interface uses the term policy transaction to refer to submissions,
policy changes, and other policy transactions. Policy transactions are implemented as jobs in the data
model, and referred to as jobs in PCF files, Gosu classes, and other configuration files. Therefore, the
configuration documentation refers to policy transactions as jobs.

See also
• “Selecting the underwriting company through segmentation” on page 734
• Application Guide

Configuring renewals overview

In PolicyCenter, you can configure the renewal job (policy transaction) through Studio. The job process is controlled
by:
• Gosu classes such as: [Link] in the [Link] package. This class contains the main functionality of
the renewal process.
• Gosu enhancement files such as: [Link]. This enhancement allows you to augment classes
and other types with additional methods and properties. An example is the addToGroup method which groups the
job into the appropriate renewal group or creates a new one if a valid group does not exist.
• Workflows such as StartRenewalWF.
• Page configuration files (PCF files) such as [Link].
• Typelists such as RenewalCode.
• Rule Sets such as Renewal AutoUpdate.
• System tables such as the NotificationConfig system table.
Note: Since the renewal process for any insurer can be configured based on business requirements, all
discussions apply to the default application only.

Renewal process Gosu class

The [Link] class is the main class controlling the renewal process. Use Studio to view and
edit the Gosu classes related to the renewal process.
This class contains the main logic of the renewal job, including referral direction handling. PolicyCenter checks
multiple methods to see if the renewal can be automatically processed based on certain conditions. If PolicyCenter
Configuring renewals 743
Guidewire PolicyCenter 9.0.9 Configuration Guide

cannot process the job automatically, it blocks the renewal from advancing, raises an issue, and refers the renewal to
an underwriter so that it can be manually processed.
Note: The [Link] Gosu class contains methods that are common to all jobs, including
renewal. You can view that class in Studio and see the complete list of methods.
The renewal process class includes methods that do the following:
• Starts the renewal
• Sends renewal documents
• Escalates the renewal
• Issues and binds the renewal
• Handles user actions such as:
◦ Issue Now – Immediately binds the policy.
◦ NonRenew – Puts the policy period in NonRenewing status.
◦ Not Taken – Puts the policy period in NotTaking status.
◦ Renew – Puts the policy period in Renewing status.
◦ Edit Policy Transaction – Puts the period back in Draft mode for editing and checks the conditions for which a
new version of the policy period can be created.
◦ Withdraw Transaction – Withdraws the policy period. If the renewal is at a point where it cannot be withdrawn,
then a message appears stating that the renewal cannot be withdrawn.

See also
• Gosu Reference Guide

Modifying the Renewal Process Class

If you need to change or create new the methods in that class, you can edit the class directly or create a subclass
(such as [Link]).
For more information about job classes and job subclasses, see “Gosu classes for jobs” on page 730.
If you create a subclass, you must modify the job process customization plugin. For more information, see the
Integration Guide.

Renewal enhancement
Enhancement files are editable, and you can add additional logic to the renewal process in
[Link].

Renewal workflows
Note: PolicyCenter uses workflows in certain job (policy transaction) situations. It is not necessary to
use workflows to start a job. Only job steps that are asynchronous use workflows. For synchronous
steps, Gosu classes and enhancements contain the logic.
In the default configuration of PolicyCenter, if the renewal process job is automated and not dependent on user
actions, then a workflow controls the process. However, if manual intervention is necessary, then the renewal
workflow is not used. The renewal process class handles manual renewal steps. See “Renewal process Gosu class”
on page 743.
The renewal job uses the following workflows:
• “Renewal workflows” on page 744
• “Renewal workflows” on page 744

Start Renewal Workflow

In the [Link] class, the start method begins the StartRenewalWF workflow.
744 chapter 58: Configuring renewals
 Guidewire PolicyCenter 9.0.9 Configuration Guide

This simple workflow has Begin and Done steps. The Begin step gets the user which the automated renewal will
use, and starts the automatic renewal by calling the beginAutomaticRenewal method defined in
[Link].

Renewal Timeout Workflow

The scheduleTimeoutOperation method calls the Renewal Timeout workflow. Various methods in the renewal
process class call this method to:
• Wait until a timer expires
• Edit the policy and change the policy to draft mode.
• Withdraw the policy
• Issue the policy renewal

See also
• “Renewal process Gosu class” on page 743

Renewal rule sets

In PolicyCenter, you can also embed your business logic in rule sets. Use the rule sets if there is a need to check for
a simple set of conditions. Follow with a set of simple actions if those conditions are met. Rule sets are grouped by
function for the purpose of customizing a process, such as a renewal, to follow established business procedures. Edit
rules in Studio in the configuration→config→Rule Sets directory.
Note: You can also add your business logic in Gosu, for example, putting additional renewal business
logic in the [Link] enhancement. Inserting logic in Gosu allows for a more
centralized job flow and is easier to debug.
See the Renewal topic in the Rules Guide for additional information.
The following table lists the rule sets that PolicyCenter provides in the base configuration.

Rule set Rule Acts on Description

Renewal RenewalAutoUpdate PolicyPeriod Called when PolicyCenter creates a renewal job. This rule set can be used to
perform automatic changes to policy information that need to occur during a
renewal.

Renewal integration
PolicyCenter integrates with many types of external systems through a diverse set of services. This topic describes
web services, plugins, and events that apply to the renewal job (policy transaction).

Renewal web services

Renewal jobs have the following web service APIs.

Name Description
PolicyRenewalAPI The policy renewal web service provides methods for managing renewals in PolicyCenter.
The policy renewal web service provides methods to:
• Start renewals on policies that exist in PolicyCenter. There is no gap in coverage between the renewal
and its based‐on policy period.
• Import a policy from a legacy system and renew the policy. There is no gap in coverage between the
renewal and its based‐on policy period.
• Process a renewal in a billing system
For more information see the Integration Guide.

Configuring renewals 745

Guidewire PolicyCenter 9.0.9 Configuration Guide

Name Description
JobAPI The job web service primarily adds an activity to a job by using an activity pattern. This web service also
has methods to find and withdraw jobs.
The job ID of the activity is set to the given job ID. The previous UserID of the activity is set to the current
user. The Assignment Engine assigns the newly created activity to the specified group and user. Finally,
the activity is saved to the database, and the public ID of the newly created activity is returned.
For more information, see the Integration Guide.
PolicyPeriodAPI The policy period web service provides methods for performing various operations on policy periods
within PolicyCenter. It allows you to do the following:
• Add a note to the policy and policy period
• Add a document to the policy period
• Add a referral reason code to the policy period
For more information, see the Integration Guide.
WorkflowAPI The workflow web service provides methods for performing various operations on workflows within
PolicyCenter. This web service can:
• Invoke a trigger that starts an action to advance the workflow to the next step.
• Resume a workflow or all workflows. The workflow engine can attempt to advance the workflow (or
all workflows) to the next step. If there is an error, then the API logs it.
• Suspend a workflow.
For more information, see the Integration Guide.

Renewal plugins
Renewal jobs use the following plugins. For the complete list, see the Integration Guide.

Name Description
IPolicyRenewalPlugin Determines whether to start a renewal job. For more information, see the Integration Guide.
INotificationPlugin Called by IPolicyRenewalPlugin. Returns the date a notification must be mailed. For more in‐
formation, see the Integration Guide.
IEffectiveTimePlugin This plugin determines the initial time component of a policy period's effective/expiration dates
(the PeriodStart/PeriodEnd dates) when starting a new job. Renewal is one of the affected
jobs. All of this interface's methods have a PolicyPeriod parameter, which can be used to ac‐
cess additional information that might be used to determine the desired time, such as:
• The line or lines of business
• The base jurisdiction
• Other revisions
The return value from each method is a Date, with its time component, HH:mm:ss, set to the de‐
sired time. The plugin ignores the day component, dd/MM/yyyy. As a convenience, each method
returns null to leave the time component set to the default (midnight)
IJobNumberGenPlugin This plugin generates a new unique job number.
AccountLocationPlugin For account locations and policy locations, customize how PolicyCenter:
• Determines that two locations are the same
• Clones a location
IPolicyNumGenPlugin This plugin returns an identifier for a new period of a policy. The policy number may vary from
period to period. Call this plugin for the initial period of a policy as part of a Submission job. You
can also call this plugin if you want to generate a new identifier when renewing or rewriting a
policy.

746 chapter 58: Configuring renewals

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Name Description
IPolicyPeriodDiffPlugin This plugin does the following:
• Compares two policy periods, returning a list of DiffItems representing the differences
between them. The compareBranches method is called in the following:
◦ Multi‐version quote
◦ Comparing PolicyPeriods of a Policy
◦ Comparing Jobs of a Policy
• Filters a list of Diff terms that originate from the database.
IPolicyPeriodPlugin This plugin calculates period end dates and creates the job process for that period.
IPolicyPlugin This plugin contains methods including canStartRenewal which checks to see whether the
PolicyPeriod can be renewed.

IVinPlugin For a VIN (Vehicle Identification Number), the getVehicleInfo method returns the model,
make, year, and color of vehicle.

Renewal events
Events are changes in PolicyCenter that might be of interest to an external system. The renewal job uses the
following events:
• SendRenewalDocuments
• SendNonRenewalDocuments
• SendNotTakenDocuments
• SendNotTaken
• SendNonRenewal
• IssueRenewal

See also
• Integration Guide

Configuring batch process renewals

PolicyCenter has a batch process that automatically finds policies that are ready for renewal. In the default
configuration, PolicyCenter starts renewals based upon the expiration date, the renewal process lead time, line of
business, jurisdiction, and time of year. If the expiration date of the policy period falls within the renewal process
lead time, then the Renewal plugin calculates whether to start a renewal for the policy. Because the renewal process
lead time is checked first, no policy will start automatic renewal sooner than this.
Renewal process lead time is specified in the RenewalProcessLeadTime parameter in the [Link] file.
Note: There are several factors to consider in scheduling the batch process. For more information, see
the Application Guide.
The following illustration shows how the Policy Renewal batch process evaluates whether to create renewal jobs for
policy periods.

Configuring renewals 747

Guidewire PolicyCenter 9.0.9 Configuration Guide

Policy Renewal Start

Batch Process
Calls Policy Renewal plugin Policy Renewal Plugin
For each policy period within the Plugin returns T/F
renewal process lead time: · Look for conflicting jobs
· Call Policy Renewal Plugin · Return whether or not to
· Create renewal job if plugin returns start a renewal job.
True

Calls Notification plugin

Notification plugin returns date
Starts renewal job

Notification Plugin

· Passed in LOB, Jurisdiction list,

Renewal Job Action Date, Action Type, and
Category.
· Look up notification date in
system table.
· Return the date a notification
must be mailed.

Looks up notification date

NotificationConfig
System Table

PolicyCenter handles the renewal job process through a series of workflows that monitor its progress and move it to
the next step. This series of workflows is the optimal way to begin renewals.

See also
• The Application Guide, which includes information on configuring the renewal process lead time.
• System Administration Guide

Renewal plugin calculation

The Renewal plugin (IPolicyRenewalPlugin) determines whether or not to start a renewal on a policy period. You
can modify this plugin to incorporate regulatory requirements and insurer practices for starting renewal processing.
In the default configuration, the Renewal plugin determines whether to start a renewal for the policy period in this
way. It first determines what the regulations require. Then it adds additional time for company practices. Finally, it
adds a delay for concurrent jobs, if any. These factors are described in:
• “Renewal lead time in notification config system table” on page 749
• “Example lead time by line of business” on page 749
• “Example lead time by time of year” on page 749
• “Delay for a conflicting job” on page 750
A renewal starts for a policy period when the current date is greater than or equal to the RenewalStartDate. The
renewal start can be delayed for a conflicting job.
The RenewalStartDate for a policy period is the expiration date of the current period, moved earlier in time by the
sum of the following:

Lead time See

Renewal lead time in Notification Config system table “Renewal lead time in notification config system table” on page 749
Example lead time by line of business “Example lead time by line of business” on page 749
Example lead time by time of year “Example lead time by time of year” on page 749

If the policy has multiple lines of business, then use the longest lead time determined across all lines of business on
the policy. You can configure how to calculate the renewal lead time.
748 chapter 58: Configuring renewals
 Guidewire PolicyCenter 9.0.9 Configuration Guide

See also
• Integration Guide

Renewal lead time in notification config system table

The Notification Config system table is one of the factors in calculating the renewal process lead time.
Note: If the policy has multiple lines of business, then default configuration uses the longest lead time
determined across all lines of business on the policy.
The Policy Renewal plugin calls the getMaximumLeadTime method in the Notification plugin. This method returns
the maximum lead time based on the values in the Notification Config table. There are two signatures for this
method. The Policy Renewal plugin calls the method with the signature that takes the Category, not the
ActionType. You can find this table by navigating to System Tables in Product Designer and opening
notification_configs.xml.

See also
• Product Model Guide

Example lead time by line of business

For renewals, the product lead time by line of business in the default configuration is listed in the following table.

Line of Business Lead Time

Businessowners 90
Business Auto 30
Commercial Property 60
Commercial Package 90
General Liability 60
Inland Marine 60
Personal Auto 30
Workers Compensation 60

If the policy has multiple lines of business, then the Renewal plugin uses the longest lead time determined across all
lines of business on the policy.
You can configure these values in the Renewal plugin.

Example lead time by time of year

The following table shows the default configuration of lead time by time of year (date ranges are inclusive):

Date Range Lead Time

January 1 through January 15 15
January 16 through July 31 0
August 1 through September 15 ‐10
September 16 through end of year 0

You can configure this in the Renewal plugin. For more information, see the Integration Guide.
Configuring renewals 749
Guidewire PolicyCenter 9.0.9 Configuration Guide

Delay for a conflicting job

The batch process does not start a renewal job if there is a conflicting job. A conflicting job is an open policy change
or cancellation job. A policy that would normally renew on a given day will wait three additional days to start if
there is a conflicting job. After three days, the next run of the batch process starts the renewal, whether or not there
is an open conflicting job.
The three day delay is set in the CONCURRENT_JOB_DELAY_DAYS variable which is defined in the Renewal plugin.
You can modify how this plugin calculates and uses the delay for a conflicting job.
Note: The frequency of the batch process is a factor in when a delayed renewal starts. For example,
you have a batch process that runs every Sunday. A delayed renewal that could start on Wednesday
will not start until the batch process runs on Sunday, several days later.

Configuring explanations in pre‐renewal directions

In a pre-renewal direction, the user can select a direction to not renew the policy. The user can add explanations to
non-renewal directions. These explanations are configured as non-renewal explanation patterns. In Studio,
configuration→config→Import→gen contains configuration files related to non-renewal explanation patterns:

File Description
[Link] Definitions for non‐renewal explanation patterns.

[Link] In the default configuration, this file specifies that

[Link] is imported when PolicyCenter is starts.

See also
• Application Guide

750 chapter 58: Configuring renewals

chapter 59

Configuring cancellations

This topic describes how to configure cancellation jobs (cancellation policy transactions).
Note: In PolicyCenter, the user interface uses the term policy transaction to refer to submissions,
policy changes, and other policy transactions. Policy transactions are implemented as jobs in the data
model, and referred to as jobs in PCF files, Gosu classes, and other configuration files. Therefore, the
configuration documentation refers to policy transactions as jobs.

See also
• Application Guide

Configuring cancellations overview

Use Studio to access the necessary files and code to configure the cancellation process to your business needs.
The key configuration files include:
• Gosu job process class: [Link]. This class contains the code behind the
cancellation job (policy transaction). For more information, see “Cancellation Gosu classes” on page 752.
• Gosu enhancement file: [Link]. This enhancement allows you to modify or add
additional functions and properties to the cancellation job class. For more information, see “Cancellation Gosu
classes” on page 752.
• Workflow files: CompleteCancellationWF.1. This file describes the workflow for completing the
asynchronous parts of cancellation. [Link] starts the workflow. Clicking Bind
Options→Schedule Cancellation or Cancel Now on the Cancellation screen calls the code to start the workflow. For
more information, see “Complete cancellation workflow” on page 753.
• Page configuration files (PCF files) such as [Link]. To view these PCF files, navigate in
Studio to configuration→config→Page Configuration→pcf→job→cancellation.
• Typelists such as CancellationSource or CalculationMethod. You can view this typelist by navigating in
Studio to configuration→config→Metadata→Typelist.
• System tables such as notification_configs.xml. You can view this table under System Tables in Product
Designer.

Configuring cancellations 751

Guidewire PolicyCenter 9.0.9 Configuration Guide

Note: Since the cancellation process for any insurer can be configured based on business
requirements, all discussions apply to the default application only.

See also
For more information about how to control jobs in Gosu and when to use workflows:
• “Configuring jobs” on page 729
For more information on configuration:
• “Cancellation Gosu classes” on page 752
• “Complete cancellation workflow” on page 753
• “Cancellation integration” on page 753
• “Calculating the cancellation effective date” on page 754
• “Configuring the premium calculation method” on page 755

Cancellation Gosu classes

Gosu classes primarily control cancellations. In Studio, you can configure the Gosu classes by modifying the
following types of files:
• “Cancellation process class” on page 752
• “Cancellation enhancements” on page 752

Cancellation process class

Navigate in Studio to configuration→gsrc to view or edit the [Link] Gosu class which
contains the majority of cancellation logic. The CancellationProcess class includes functions to start, schedule,
quote, rescind, and issue a cancellation. The [Link] class extends the JobProcess Gosu class.
The JobProcess class contains functions that allow you to get the job and the policy period.

Start Function
Pressing Start Cancellation (in [Link]) indirectly invokes the start function. The Start button calls
the [Link] method which indirectly calls start.

Modifying the Cancellation Process Class

If you need to change or create new methods in that class, you can edit the class directly or create a subclass (such as
[Link]).
For more information about job classes and job subclasses, see “Gosu classes for jobs” on page 730.
If you create a subclass, you must modify the job process customization plugin. For more information, see the
Integration Guide.

Cancellation enhancements
The cancellation enhancement, [Link], enhances the Cancellation entity with additional
functionality. You can edit this file.
This enhancement contains functions that do the following:
• Determines which refund calculation functions displays based on the cancellation reason.
• Calculates the earliest and latest effective date of the cancellation.
• Returns the last date of the underwriting period.
• Withdraws later cancellations with the same based on period.
752 chapter 59: Configuring cancellations
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Complete cancellation workflow

Note: PolicyCenter uses workflows primarily for automation and coordination of activities between
PolicyCenter and external systems and for observing time periods and other automation.
In a cancellation, the job process involves automation and waiting. You wait for a period of time before the
cancellation job completes and the policy is canceled. During this time period, the insured may remit payment and
the cancellation may be rescinded. The CompleteCancellatonWF.1 workflow manages the processes that are not
user driven.

Complete Cancellation Workflow Steps

The workflow begins when you select Bind Options→Schedule Cancellation or Cancel Now through the PolicyCenter user
interface.
In the default application, selecting Schedule Cancellation or Cancel Now in the user interface calls the
scheduleCancellation method in [Link]. After notices are successfully sent through
sendNotices, the finishSendNotices method starts the workflow.

Cancellation integration
PolicyCenter integrates with many types of external systems and custom code through a diverse toolbox of services.
This topic describes web services and events that the cancellation job uses.
A common integration is with a billing system to start a cancellation for non-payment or to rescind a cancellation
after receiving payment.
Another common integration is with a rating engine to calculate the premium amount.

Cancellation web services

The Cancellation API is a web service for use by external systems to begin, reschedule, rescind, or find a
cancellation.
Invoke the beginCancellation method to begin a cancellation job. This method does not attempt to automatically
push the cancellation through to completion. The method throws an exception if the cancellation cannot be started
for any reason.
The rescheduleCancellation method allows you to reschedule an cancellation. You must specify the new
cancellation effective date. Optionally, you can provide a new reason description. The cancellation can be in draft,
quoted, or canceling status.
The rescindCancellation method rescinds a cancellation job. The method throws an exception if the rescind
cannot be performed for any reason.

See also
• Integration Guide

Cancellation plugins
The following plugins might be useful for cancellation.

Name Description
IBillingPlugin If you need to integrate with an external billing system, use this plugin to notify an external billing
system about billing events.
MessageTransport Use this plugin to send a message to an external/remote system by using any transport protocol.
IEffectiveTimePlugin Determines the time of day (since midnight) for a job. Use to calculate the effective time.

IJobNumberGenPlugin Generates a new, unique job number. Use to generate cancellation job numbers.

Configuring cancellations 753

Guidewire PolicyCenter 9.0.9 Configuration Guide

Name Description
IPolicyPlugin Lets PolicyCenter know whether, based on dynamic calculations on the policy, it is OK to start various
jobs. Use to determine if a cancellation job can be started.
INotificationPlugin Returns cancellation lead time.

See also
Integration Guide

Cancellation events
PolicyCenter generates events for changes in PolicyCenter that might be of interest to an external system. You can
also programmatically generate an event. For example, in the [Link] class, the sendNotices
method generates a SendCancellationNotices event.
The Cancellation entity has the following events:
• CancellationAdded
• CancellationChanged
• CancellationRemoved
The PolicyPeriod entity has the following events pertaining to cancellation:
• SendCancellationNotices – Message to an external system to send cancellation notices.
• IssueCancellation – Message to an external System of Record (SOR) to send cancellation notices.
• SendRescindNotices – Message to an external system to send rescind cancellation notices.

See also
• Integration Guide

Calculating the cancellation effective date

PolicyCenter calculates the earliest cancellation effective date, based on cancellation reason, jurisdiction, line of
business, and other factors. Methods in [Link] calculate the date. In some cases, the
calculation calls the Notification plugin which references the notification_configs.xml system table. The
notification_configs.xml system table is where you specify the cancellation lead time by jurisdiction, line of
business, and cancellation reason. You can view this table by navigating to System Tables in Product Designer.

Calculating the cancellation effective date if the source is insured

If the Source is Insured, return the current date. However, if the reason is that the policy is not taken, return the date
that the policy went into effect.

Calculating the cancellation effective date if the source is insurer

This topic describes how PolicyCenter calculates the cancellation effective if the Source is Insurer.
Note: The cancellation lead time returned by the notification_config.xml system table is described in
the Product Model Guide. This topic also describes how the application determines the lead time.
1. If the cancellation reason is equal to Policy rewritten or replaced (flat cancel), then the cancellation effective date is
equal to starting date of the policy period. You are done.
2. Else, determine if the policy is in the underwriting period.
a. Calculate the number of the days (xDays) between the Policy Effective Date and the current date.
754 chapter 59: Configuring cancellations
 Guidewire PolicyCenter 9.0.9 Configuration Guide

b. The Notification plugin retrieves the underwriting period from the notification_configs.xml system
table. The underwriting period is specified in rows with ActionType of Underwriting Period. The
underwriting period is the value in the LeadTime column.
If xDays is less than or equal to the LeadTime, then the policy is in the underwriting period.
If the policy is in the underwriting period, the application will use underwriting period action types and
categories in the notification_configs.xml system table to determine the cancellation lead time.
3. The Notification plugin retrieves the maximum lead time required for notification from the
notification_configs.xml system table. The plugin retrieves the maximum lead time based on the
cancellation reason, whether the policy is in the underwriting period, the policy jurisdiction, and the line of
business.

Cancellation reason Category ActionType

Fraud Cancellation fraudcancel

UW Period Cancellation uwperiodfraudcancel

Non payment Cancellation nonpaycancel

UW Period Cancellation uwperiodnonpaycancel

Any other reason Cancellation othercancel

UW Period Cancellation uwothercancel

Note: If a policy includes multiple jurisdictions, there can be multiple matching rows. A policy that
includes more than one line of business (such as a commercial package policy) can include both
multiple jurisdictions and lines of business. In this case, the Notification plugin retrieves the
maximum lead time. Therefore, the plugin returns the longest lead time specified for any of the
jurisdiction and line of business combinations in the policy.
The cancellation effective date is equal to the current date plus the LeadTime for the matching row plus one day.
Cancellation does not take place until the full notification period has passed. If ten days notification is required,
cancellation does not take place earlier than 10:01 a.m. on day 11.

Configuring the premium calculation method

You cannot add or change the refund method (pro rata, short rate, and flat) except to change the calculation of
penalty in short rate. In short rate, a rating engine calculates the amount of penalty. The default configuration
contains rating system plugins. You can modify the plugin algorithms or integrate your own rating system to work
with PolicyCenter.

Configuring cancellations 755

Guidewire PolicyCenter 9.0.9 Configuration Guide

756 chapter 59: Configuring cancellations

chapter 60

Configuring policy change

This topic describes how to configure policy change jobs (policy change transactions).
Note: In PolicyCenter, the user interface uses the term policy transaction to refer to submissions,
policy changes, and other policy transactions. Policy transactions are implemented as jobs in the data
model, and referred to as jobs in PCF files, Gosu classes, and other configuration files. Therefore, the
configuration documentation refers to policy transactions as jobs.

See also
• Application Guide

Configuring policy change overview

Gosu classes primarily control policy changes. In Studio, navigate to configuration→gsrc to view or edit the
[Link] Gosu class that contains most of the policy change code.
In a policy change job, the [Link] class, the [Link] class, and the [Link]
class contain code for the main job actions. The default application spreads the policy change code among multiple
classes for better organization and use of code. For example, changing the quote logic can be done in one location
([Link]). You can modify the quote logic in one location and many types of jobs can access it.
Note: In the default configuration, the policy change job has no workflows because it has no
background processes. PolicyCenter uses workflows only for background processes.

Policy change process class

The PolicyChangeProcess class contains method for handling policy change jobs. The following table summarizes
some of the methods contained in the [Link] class.
Note: To see the complete list of methods, view the [Link] class in Studio.

Method Description
Starting a policy change
start This method starts the job and automatically assigns a requestor and producer.
startAutomatic This method calls three methods which start the job, request a quote, and bind the
policy. The PolicyChangeAPI calls this method.
Binding a policy change

Configuring policy change 757

Guidewire PolicyCenter 9.0.9 Configuration Guide

Method Description
canBind canBind – Checks that the policy can be bound. Some of the checks include:
• Has the policy been quoted?
• Does the user have the correct permissions to bind the policy?
bind Begins the binding process for a PolicyPeriod.
This method verifies if the branch can be bound. For multi‐version jobs, there is on‐
ly one selected branch on the job which is specified by [Link]. That
branch must have a valid quote. If the branch can be bound, then bind starts the
binding process and sets the policy status to Binding.
This method ensures that there is a producer of service on the policy.
This method also calls out to the FormInferenceEngine, which is the main integra‐
tion point for forms.
Lastly, the startBinding method has commented out code to add an
IssuePolicyChange event.

finishBinding Completes the policy change job. This method also checks new conditions and
sends billing information through the IBillingSystemPlugin.
failBinding If binding fails, then the policy can be edited again by an underwriter.
Editing the effective date
canStartChangeEditEffectiveDate Check to see if Actions→Edit→Effective Date is available.
canFinishChangeEditEffectiveDate Check to see if the current policy change can change its effective date to the input
parameter value.
changeEditEffectiveDate PolicyCenter invokes this method when you select Effective Date in the Actions menu.
If canStartChangeEditEffectiveDate is false, then this method is not called.
This method calls canFinishChangeEditEffectiveDate to verify that the change is
valid before applying it.
Handling future bound jobs
applyChangesToFutureBoundRenewal Applies changes from this policy change to a renewal that is bound in the future.
applyChangesToFutureUnboundRenewal Applies changes from this policy change to a renewal that is unbound in the future.

Flags
canRequestQuote Indicates whether quoting can be initiated on the PolicyPeriod.
canWithdraw Checks to see if a branch can be withdrawn.

The PolicyChangeProcess class also identifies and raises underwriting issues with the policy, using underwriting
rules to identify the types of issues to raise.

See also
• “Configuring underwriting authority” on page 583
• “Adding a new checking set” on page 587
• Application Guide

Modifying the policy change process class

If you need to change or create new methods in that class, you can edit the class directly or create a subclass (such as
[Link]).
For more information about job classes and job subclasses, see “Gosu classes for jobs” on page 730.
If you create a subclass, you must modify the job process customization plugin. For more information, see the
Integration Guide.
758 chapter 60: Configuring policy change
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Policy change integration

PolicyCenter integrates with many types of external systems through a diverse set of services that can link
PolicyCenter with custom code and external systems. This topic describes APIs and events that are relevant to the
policy change job (policy transaction).

Policy change web services

For the policy change job, the PolicyChangeAPI includes two methods to start policy change jobs:
• The startAutomaticPolicyChange method starts a policy change job for a policy (specified by policy number)
and an effective date. It returns the job number of the new job (its JobNumber property). In the default
configuration, this method does not make any changes to the policy data. You can add your own methods to
make changes to the data.
• The startManualPolicyChange method has the same arguments and return values, but does not attempt to bind
and quote automatically. The policy change starts and waits in draft mode for the user to quote and finish it
manually.

Policy change plugins

The policy change job has the following plugins.

IPolicyPlugin
The canStartPolicyChange method returns an error message if a change cannot be started for a policy and an
effective date. Changes that are started internally or externally call this plugin.
For more information, see the Integration Guide.

IPolicyPeriodPlugin
The postCreateNewBranchForChangeEditEffectiveDate method is called to handle a change to the effective date
of a job such as a policy change. In the default configuration, policy change is the only job that calls this method.

Policy change events

In PolicyCenter, events are changes (such as a new policy change) that might be of interest to an external system. In
the bind method of the [Link] class, you can generate the IssuePolicyChange event. In the
default configuration, this code is commented out. The code notifies an external system to issue a policy change.

See also
• Integration Guide

Configuring policy change 759

Guidewire PolicyCenter 9.0.9 Configuration Guide

760 chapter 60: Configuring policy change

chapter 61

Configuring reinstatement

This topic describes how to configure reinstatement jobs (reinstatement policy transactions).
Note: In PolicyCenter, the user interface uses the term policy transaction to refer to submissions,
policy changes, and other policy transactions. Policy transactions are implemented as jobs in the data
model, and referred to as jobs in PCF files, Gosu classes, and other configuration files. Therefore, the
configuration documentation refers to policy transactions as jobs.

See also
• Application Guide

Configuring reinstatement overview

Use Guidewire Studio to access the files and code to configure the reinstatement process to your business needs.
Key files include:
• Gosu job process class – [Link]. This class contains the code behind the reinstatement job.
You can view or edit this class in Studio by navigating to configuration→gsrc and selecting
[Link]. For more information, see “Reinstatement process Gosu class” on
page 761
• Gosu enhancement file – [Link]. This enhancement allows you to modify or add
additional functions and properties to the reinstatement job Gosu class. For example, this enhancement class has
just one function which is called when the reinstatement job finishes. This function restarts any withdrawn
renewals on the policy.
• Page configuration files (PCF files) such as [Link]. To view these PCF files, navigate in
Studio to configuration→config→Page Configuration→pcf→job→reinstatement.
• Typelists such as ReinstateCode. You can view this typelist by navigating in Studio to
configuration→config→Metadata→Typelist.
Note: Since the reinstatement process for any insurer can be configured based on business
requirements, all discussions apply only to the default application.
To learn more about how jobs work in Gosu and how to use workflows, see “Configuring jobs” on page 729.

Reinstatement process Gosu class

Gosu classes primarily control reinstatements. In Studio, navigate to configuration→gsrc to view the
[Link] Gosu class which contains most of the reinstatement code.
Configuring reinstatement 761
Guidewire PolicyCenter 9.0.9 Configuration Guide

The [Link] contains functions for reinstatement. The [Link] contains general
functions used by different types of jobs.
The [Link] class extends the JobProcess Gosu class. The JobProcess class contains
functions that allow you to get the job and the policy period. It cancels open activities on the reinstatement and auto
assigns the user role. It also checks to see if the job can be expired or withdrawn, and checks if the job can be started
as new.
This class identifies and raises underwriting issues with the policy, using underwriting rules to identify the types of
issues to raise.
Methods in [Link] start the job as a draft, then automatically assign the producer and
underwriter roles to the job.
Note: The reinstatement job has no workflows because it has no background processes. PolicyCenter
uses workflows only for background processes.

See also
• “Configuring underwriting authority” on page 583
• Application Guide

Modifying the Reinstatement Process Class

If you need to change or create new methods in that class, you can edit the class directly or create a subclass (such as
[Link]).
For more information about job classes and job subclasses, see “Gosu classes for jobs” on page 730.
If you create a subclass, you must modify the job process customization plugin. For more information, see the
Integration Guide.

Reinstatement integration
PolicyCenter integrates with many types of external systems through a diverse toolbox of services that can link
PolicyCenter with custom code and external systems. This topic describes web services and events that the
reinstatement job uses.

Reinstatement web services

The ReinstatementAPI is a web service to start a reinstatement from an external system.
The [Link] function can be invoked to begin a reinstatement job. It does not
attempt to automatically push the reinstatement job through to completion. The policyNumber and reinstateCode
arguments identify which policy is to be reinstated and the reason for the reinstatement. The function throws an
exception if the reinstatement cannot be started for any reason.

See also
• Integration Guide

Reinstatement plugins
The following plugins may be useful to integrate with reinstatement.

Name Description
IBillingPlugin If you need to integrate with an external billing system, use this plugin to notify an external billing
system about billing events.
MessageTransport Use this plugin to send a message to an external/remote system by using any transport protocol.

762 chapter 61: Configuring reinstatement

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Name Description
IEffectiveTimePlugin Determines the time of day (since midnight) for a job. Use to calculate the effective time.

IJobNumberGenPlugin Generates a new, unique job number. Use to generate reinstatement job numbers.
IPolicyPlugin Lets PolicyCenter know whether to start various jobs, based on dynamic calculations on the policy.
Use to determine when a reinstatement job can be started.

See also
• Integration Guide

Reinstatement events
PolicyCenter generates events for changes that might be of interest to an external system. You can also
programmatically generate an event. For example, in the [Link] class, the function
startReinstate generates an IssueReinstatement event.
The Reinstatement entity has the following events:
• ReinstatementAdded
• ReinstatementChanged
• ReinstatementRemoved
The PolicyPeriod entity has the following events pertaining to reinstatement:
• IssueReinstatement – a message that notifies an external system to issue a reinstatement for a particular policy
period.

See also
• Integration Guide

Configuring reinstatement 763

Guidewire PolicyCenter 9.0.9 Configuration Guide

764 chapter 61: Configuring reinstatement

chapter 62

Configuring rewrite

This topic describes how to configure rewrite jobs (rewrite policy transactions).
Note: In PolicyCenter, the user interface uses the term policy transaction to refer to submissions,
policy changes, and other policy transactions. Policy transactions are implemented as jobs in the data
model, and referred to as jobs in PCF files, Gosu classes, and other configuration files. Therefore, the
configuration documentation refers to policy transactions as jobs.

See also
• “Selecting the underwriting company through segmentation” on page 734
• Application Guide

Configuring rewrite overview

Use Studio to access the necessary files and code to configure the rewrite job (policy transaction) to your business
needs.
Key files include:
• Gosu job process class – [Link]. This class contains the code behind the rewrite job. You can
view or edit this class by navigating in Studio to configuration→gsrc, and selecting [Link].
For more information, see “Rewrite process Gosu class” on page 765.
• Page configuration files (PCF files) such as [Link]. To view these PCF files, navigate in Studio
to configuration→config→Page Configuration→pcf→job→rewrite.
• Typelists such as RewriteType. You can view this typelist by navigating in Studio to
configuration→config→Metadata→Typelist.
Note: Since the rewrite process for any insurer can be configured based on business requirements, all
discussions apply only to the default application.

See also
• “Configuring jobs” on page 729 to learn more about how jobs work in Gosu and how to use workflows

Rewrite process Gosu class

Gosu classes primarily control the rewrite process. In Studio, navigate to configuration→gsrc and open the
[Link] Gosu class which contains most of the rewrite code.
Configuring rewrite 765
Guidewire PolicyCenter 9.0.9 Configuration Guide

The [Link] class extends the JobProcess Gosu class. The JobProcess class contains functions that
allow you to get the job and the policy period. It cancels open activities on the rewrite and auto assigns the user role.
It also checks to see if the job can be expired, or withdrawn, and checks if the job can be started as new.
Functions in [Link] start the rewrite job, request a quote, and rewrite the policy period.
Note: The rewrite job has no workflows because it has no background processes. PolicyCenter uses
workflows only for background processes.

Modifying the Rewrite Process Gosu Class

If you need to change or create new methods in that class, you can edit the class directly or create a subclass (such as
[Link]).
For more information about job classes and job subclasses, see “Gosu classes for jobs” on page 730.
If you create a subclass, you must modify the job process customization plugin. For more information, see the
Integration Guide.

Rewrite integration
PolicyCenter integrates with many types of external systems through a diverse toolbox of services that can link
PolicyCenter with custom code and external systems. This topic describes events for the rewrite job (policy
transaction). The rewrite job has no web services.

Rewrite events
PolicyCenter generates events for changes in PolicyCenter that might be of interest to an external system. You can
also programmatically generate an event. For example, in the [Link] class, the rewrite function
generates an IssueRewrite event (by calling the startBinding function).
The Rewrite entity has the following events:
• RewriteAdded
• RewriteChanged
• RewriteRemoved
The PolicyPeriod entity has the following events pertaining to rewrite:
• IssueRewrite – A message that notifies an external system to issue a rewrite for a particular policy period.

See also
• Integration Guide

766 chapter 62: Configuring rewrite

chapter 63

Configuring rewrite new account

This topic describes how to configure rewrite new account jobs (rewrite new account policy transactions).
Note: In PolicyCenter, the user interface uses the term policy transaction to refer to submissions,
policy changes, and other policy transactions. Policy transactions are implemented as jobs in the data
model, and referred to as jobs in PCF files, Gosu classes, and other configuration files. Therefore, the
configuration documentation refers to policy transactions as jobs.

See also
• Application Guide

Configuring the rewrite new account job overview

This topic describes how to configure the rewrite new account job (policy transaction).

Rewrite new account job

The main PCF file for the rewrite new account is the RewriteNewAccountWizard.
The primary Gosu class for this job is [Link]. The main methods in this class are:
• start
• rewriteNewAccount
• finishRewriteNewAccount
If you need to change or add methods to the rewrite new account process, you can edit the job class directly or create
a subclass (such as [Link]).
For more information about job classes and job subclasses, see “Gosu classes for jobs” on page 730.
If you create a subclass, you must modify the job process customization plugin. For more information, see the
Integration Guide.

Copying contacts and locations in rewrite new account job

When a rewrite new account job starts, it copies contacts and locations from the source policy account to the target
account. For example, the source policy period references the driver, John Doe. The job checks for a corresponding
AccountContact and Driver for John Doe on the target account and creates these entities if they do not exist. In the
rewritten policy, the corresponding policy driver points to the copied account level driver.
Configuring rewrite new account 767
Guidewire PolicyCenter 9.0.9 Configuration Guide

Rewrite new account object model

This topic describes entities and fields related to the rewrite new account job (policy transaction).
Rewrite New Account Object Model

Job Policy
CreatesNewPolicy RewrittenToNewAccountDestination
IsNewTerm RewrittenToNewAccountSource Legend
A relates to B
A B
B relates to A

A B A has a B
* *
RewriteNewAccount PolicyPeriod A B A has 0 or more Bs
* A is a subtype of B
A B
A delegates to B
BasedOn

Rewrite New Account Entity

The RewriteNewAccount entity represents the rewrite new account job. This entity has a PolicyPeriod field which
returns the policy period associated with the job.
The PolicyPeriod entity associated with the RewriteNewAccount entity has a BasedOn field that returns the policy
period on which the source policy is based.

Policy Entity

The Policy entity has the following fields related to the rewrite new account job:

Field Description
RewrittenToNewAccountDestination If this policy was rewritten to a new account, returns the destination policy.

RewrittenToNewAccountSource If this policy was rewritten to a new account, returns the source policy.

Job Entity

In a rewrite new account job, the Job entity has the following values:

Field Description
CreatesNewPolicy Value is True if this job creates a new policy with a new policy number. This value is True for rewrite new
account jobs.
IsNewTerm Value is True if this job creates a new policy term. This value is True for rewrite new account jobs.

Rewrite new account history events

The rewrite new account job (policy transaction) creates the following history events:

History event Description

rewr_new_acct_created This event appears on the source policy term when the rewrite new account job starts.

rewr_new_acct_bound This event appears on the target policy term when the job is bound.

768 chapter 63: Configuring rewrite new account

chapter 64

Configuring premium audit

In the base configuration, PolicyCenter provides two types of premium audit jobs: final audits and premium reports.
Audits are included in the Workers’ Compensation and General Liability lines of business. You can configure final
audits and premium reports to meet your requirements. You can add and configure new audit types such as checking
audits. You can add audit to additional lines of business.
This topic describes how to configure premium audit jobs (premium audit policy transactions).
Note: In PolicyCenter, the user interface uses the term policy transaction to refer to submissions,
policy changes, and other policy transactions. Policy transactions are implemented as jobs in the data
model, and referred to as jobs in PCF files, Gosu classes, and other configuration files. Therefore, the
configuration documentation refers to policy transactions as jobs.

See also
• Application Guide

Configuring premium audit overview

Use Guidewire Studio to access files and code to configure the audit job (policy transaction) to your business needs.
Key files include:
• Gosu job process class: [Link]. This class contains the code behind premium audit jobs. You can
view or edit this class in Studio by navigating to configuration→gsrc and opening [Link]
class. For more information, see “Audit Gosu classes” on page 770.
• Gosu enhancement files:
◦ [Link] – This enhancement allows you to modify or add additional functions
and properties to the premium audit job Gosu class.
◦ [Link] – This enhancement assigns the premium auditor to the job if the
premium auditor was not already assigned. You can view or edit this class in Studio by navigating to
configuration→gsrc and opening [Link].
• Rule Sets – The Audit→Reporting Trend Analysis→Ratio Out of Range rule set checks to see if the reporting trend
analysis ratio is within an acceptable range. The default configuration has rules for premium reports. The
acceptable range is from 90% to 110%. If the ratio is outside the acceptable range and the number of reporting
days is greater than 60, the code creates a RatioOutOfRange activity and assigns it to an underwriter. For
information about reporting trend analysis, see the Application Guide.
• Page configuration files (PCF files) such as [Link]. To view these PCF files, navigate in Studio to
configuration→config→Page Configuration→pcf→job→audit.
Configuring premium audit 769
Guidewire PolicyCenter 9.0.9 Configuration Guide

• Typelists such as AuditMethod. Typelists are in the configuration→config→Metadata→Typelist folder in Studio.

IMPORTANT Since the audit process for any insurer can be configured based on business
requirements, all discussions apply to the default application only.

See also
• “Configuring jobs” on page 729 to learn more about how jobs work in Gosu and how to use workflows
• Product Model Guide

Audit Gosu classes

Gosu classes primarily control premium audits. The [Link] package contains most of the audit code.
• [Link] is the main class and contains methods for audit. The [Link] contains general
methods used by different types of jobs.
[Link] class extends the JobProcess Gosu class. The JobProcess class contains methods that allow
you to get the job and the policy period. It auto assigns the user role, and checks to see if the job can be expired,
or withdrawn, and checks if the job can be started as new.
Methods in [Link] start the job as a draft, and verify the conditions for which the audit can be edited.
For example, does the user have edit permissions? Is the job complete? A method checks to see if an audit
package can be created. The complete method moves a policy period into the AuditComplete status, marking
the audit as complete. From then on the policy period is read-only, and any new work on the audit must be done
by revising the audit. Lastly, since an audit can be waived through the waive method, it locks the audit and it too
cannot be edited.
• The [Link] file contains methods that check to see if the audit is revisable. An
audit is revisable if it is completed and was not waived, reversed, or already revised.
• The [Link] file contains methods for the policy period that are related to audit.
This enhancement contains methods to schedule audits and remove a final audit from a policy period.
This enhancement also contains a reverseFinalAudits method which reverses audits. This method makes a call
to the billing system to reverse charges related to the final audit. This method also sets the
[Link] to the current date. You can see which audits have been reversed by
examining the ReversalDate.
PolicyCenter indicates that a policy has been billed by making an integration call to the billing system and calling
the [Link] function. See “Premium audit integration” on page 771 for more information.
• The [Link] class contains methods for scheduling audits.
Note: The premium audit job has no workflows because it has no background processes. PolicyCenter
uses workflows only for background processes.

Modifying the audit process Gosu class

If you need to change or create new methods in the AuditProcess Gosu class, you can edit the class directly or
create a subclass (such as [Link]).
For more information about job classes and job subclasses, see “Configuring jobs” on page 729.
If you create a subclass, you must modify the job process customization plugin. For more information, see the
Integration Guide.

Modifying the audit scheduler Gosu class

If you define a new audit type that requires schedules, you must modify the AuditScheduler Gosu class.
If you define a new audit type that requires schedules, add code that schedules the audits for a policy period. The
scheduleAllAudits method creates schedules for the audit types in the base configuration. Define a method to
schedule your new audit type. Call your method from the scheduleAllAudits method.
770 chapter 64: Configuring premium audit
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Methods in the AuditScheduler class call the createAuditInformation method on the AuditSchedulePattern
interface. The createAuditInformation method creates an AuditInformation entity instance but does not return
a pointer to the instance. If you need to modify the AuditInformation entity instance, you can retrieve it by
creating a query. For example, you added properties to the AuditInformation entity definition, and need to set
these values in the entity instance. After you retrieve the instance, set values for the properties you added.
The AuditInformation entity has properties for information defined in the audit schedule. The properties include
values for the audit method, audit schedule type, start date, and due date, among others.

Premium audit integration

PolicyCenter integrates with many types of external systems through a diverse toolbox of services that can link
PolicyCenter with custom code and external systems. Your integration may need to consider integrating activities,
workflows, messages (notes or email) to these external systems. This topic describes web services and events for the
premium audit job (policy transaction).

Integration with BillingCenter

The base configuration of PolicyCenter contains an integration with Guidewire BillingCenter. For information on
activating, using, and configuring this integration, see the Application Guide.

Audit web services

There are no premium audit web services.

Audit plugins
The following plugins may be useful to integrate with premium audit.

Name Description
IAuditSchedulePatternSelectorPlugin In the base configuration, this plugin sets the default audit schedule for final au‐
dits. Cancellation final audits are scheduled by phone and expiration final audits
are scheduled physically.
If the audit method is dependent on the premium value, you can configure it in
this plugin.
IBillingSystemPlugin If you need to integrate with an external billing system, use this plugin to notify an
external billing system about billing events.

For further information, see the Integration Guide.

Audit events
PolicyCenter generates events for changes that might be of interest to an external system. You can also
programmatically generate an event.
There are no events for premium audit.

Defining audit schedules

PolicyCenter uses audit schedules to specify how to calculate start dates, due dates, and methods (physical,
voluntary, or by phone) of audit transactions on a policy. PolicyCenter calculates the start date and the due date
based on the period end date. The premium report schedule has other fields including frequency and default deposit.
Configuring premium audit 771
Guidewire PolicyCenter 9.0.9 Configuration Guide

In Product Designer, you can add audit schedules and modify properties of audit schedules. For example, in Product
Designer you can change the audit schedule’s method from voluntary to phone.

Final audit schedules

The default application comes with a variety of final audit schedules including schedules for cancellations audits and
expirations audits. You can view and modify these schedules in Product Designer by navigating to Audit Schedules.
In Product Designer, you can view Expiration Audit by Physical, which provides an example of a final audit schedule.
The audit is set to start 30 calendar days before the audit period end date. It is due 45 calendar days after audit
period end date. If either the due or start date falls on a non-business day, it is delayed until the next business day.
The default final audit schedules are:
• Cancellation Audit by Phone for all cancellation final audits
• Expiration Audit by Physical for all non-cancellation final audits
The IAuditSchedulePatternSelectorPlugin determines the default final audit schedule. You can add additional
audit schedules and modify the audit schedule pattern selector plugin code. For example, you can modify the plugin
to auto-assign the schedule based on criteria such as policy premium.

Premium report schedules

Premium report scheduled items may be configured to utilize policy months or calendar months. In the default
application, the premium report schedules are:
• Monthly Reports by calendar months, exclude last month
• Monthly Reports by policy month, exclude last month
• Quarterly Reports by calendar quarter for full policy term
• Quarterly Reports by calendar quarter, exclude last quarter
• Quarterly Reports by policy quarter, exclude last quarter
If you select policy months, the start and end day of the month is based on the policy’s effective date. The following
table shows reports for an audit schedule frequency of Monthly reports by policy months.

Policy effective date 3/28/09 Policy effective date 03/10/09

03/28/09 to 04/28/09 03/10/09 to 04/10/09
04/28/09 to 05/28/09 04/10/09 to 05/10/09
05/28/09 to 06/28/09 05/10/09 to 06/10/09
... ...

If you select calendar months, an additional audit schedule field comes into play. This audit schedule field is the
round to next month field. This field allows you to control for a first report that is very short. If the policy effective
date is after the round to date, then the first report covers the first short month and the second month. Subsequent
periods correspond to calendar months. The following table shows reports for an audit schedule of Monthly reports by
calendar months with round to next month on day 15.

Policy effective date 3/28/09 Policy effective date 03/10/09

03/28/09 to 05/01/09 03/10/09 to 04/01/09
05/01/09 to 06/01/09 04/01/09 to 05/01/09
06/01/09 to 07/01/09 05/01/09 to 06/01/09
... ...

In Product Designer, you can view and modify Monthly Reports by calendar month, excluding last month, which provides
an example of a premium report schedule. The schedule specifies that the audit method is voluntary and has a 10%
772 chapter 64: Configuring premium audit
 Guidewire PolicyCenter 9.0.9 Configuration Guide

deposit. In the schedule details, the minimum audit period length is set to 15 days. The last audit period is excluded.
In the period details, the audit is set to start five calendar days before the audit period end date. The audit is due 15
calendar days after the audit period end date.

Create audit schedule

About this task
You can create a new audit schedule in Product Designer.

Procedure
1. In Product Designer, navigate to Product Model→Audit Schedules.
2. Click Add.
3. Enter a Code, Name, select an Audit Type. The Audit Type drop-down list displays the audit types defined in
PolicyCenter.
4. If the audit schedule type can be either single or series, such as checking audit, then select a Schedule Type.
5. Click OK.
Product Designer displays the new audit schedule with properties initially based on properties specified in the
audit schedule properties files for this audit type. See “Audit schedule properties file” on page 775.
6. In the audit schedule, add and change properties such as a description, when to initiate the audit, and the type
of days.

Configuring audit types

The base configuration contains the following audit types:
• Final Audit – Configured in the Workers’ Compensation and General Liability lines of business
• Premium Report – Configured in the Workers’ Compensation line of business
• Checking Audit – Not configured in any line of business
In addition, you can define and configure your own audit types.
Most audit types require that schedules of those audits be created for policy periods. Each audit schedule is for a
particular audit type. The schedule properties are based on the audit schedule properties file for that audit type.
Using Final Audit as an example, the following illustration shows how audit schedules are linked to their properties
files. The audit schedule is based on the audit schedule properties file for audit schedules of that audit type.
Audit Schedule for Final Audit

Product Designer Studio

Audit Schedules configuration > config > resources > productmodel > auditschedules

Cancellation Audit by Phone [Link]

<SingleAuditSchedulePattern
Name: Cancellation Audit by Phone auditMethod = “Phone” Audit schedule pattern
Description: type = “FinalAudit”
Audit Method: Phone …
Audit Type: Final Audit >
...

[Link]
auditMethod = REQUIRED
…. Audit schedule properties

In an audit schedule properties file, you define properties of the audit schedule as well as basic properties of the
audit type. Basic properties of the audit type include the audit method. This file also defines the schedule type,
Configuring premium audit 773
Guidewire PolicyCenter 9.0.9 Configuration Guide

which specifies whether the audit has a single occurrence or occurs in a series. You can edit the properties file in
Studio. However, only Product Designer uses this file. PolicyCenter does not.
In Product Designer, you can add new audit schedules based on the audit types. When you save an audit schedule
and commit the changes, Product Designer writes the audit schedule to an audit schedule pattern XML file in
PolicyCenter.

Add new audit type

About this task
To add a new audit type to a line of business, you must do the following:

Procedure
1. Extend the audit schedule typelist to include the new audit type. This enables you to configure the new audit
type and define audit schedules based upon the new audit type in Product Designer. See “Extend audit
schedule type typelist” on page 774.
2. Add code to handle the new audit type in all lines of business for which this audit type applies. For guidance,
see:
• Product Model Guide
• “Configuring premium audit overview” on page 769
You may also need to add or modify PCF files and entities to configure the new audit type.
For audit types, such as Final Audit and Premium Reports, that require schedules, you must do the following
steps. In the base configuration, Retrospective Rating is an audit type that does not require schedules.
3. Add audit schedule properties files for the new audit type. Product Designer loads your new audit schedule
properties files when you log out, switch change lists, or restart Product Designer. See “Audit schedule
properties file” on page 775.
4. Define audit schedules in Product Designer for the new audit type. When you commit changes, Product
Designer updates the audit schedule pattern XML file. See “Audit schedule pattern” on page 777.

Extend audit schedule type typelist

About this task
If you add a new audit type, you must add the typecodes to the AuditScheduleType typelist. If the audit type
requires schedules, then you can make the audit type available to Product Designer. In Product Designer, you can
create audit schedules based on this audit type.

Procedure
1. In configuration→config→Extensions→Typelist, open [Link]. Or if the file does not exist,
create a new Typelist Extension extending AuditScheduleType.
2. Add a typecode for new audit type.
3. For code, enter the AuditType as specified in the name of audit schedule properties file. For example, enter
the code FinalAudit for [Link].
4. For name, enter the display name of the audit type.
5. If the audit type requires schedules, right-click the typefilter named ConfigurablePatterns and select Add
New→Include Into Filter. Select the typecode for the new audit type. Add the typefilter if it does not exist.
This is the same name as the typefilter on the base typelist.
6. Right-click the typefilter and select Add New→Include Into Filter. Select the typecode for the new audit type.
7. Click Next.
8. In the Select filter tab, select ConfigurablePatterns.
774 chapter 64: Configuring premium audit
 Guidewire PolicyCenter 9.0.9 Configuration Guide

9. Click Finish.

Audit schedule properties file

The audit schedule properties file defines which properties are required or optional for audit schedules of a
particular audit type. Each audit type that requires schedules has at least one audit schedule properties file.
The schedule type specifies whether t he schedule type is single or series. A single audit occurs once. A series audit
occurs one or more times. An audit type can have both single and series schedule types. In the base configuration,
Checking Audit is defined for both schedule types.
In Studio, create a new audit schedule properties file in
configuration→config→resources→productmodel→auditschedules. Only Product Designer uses this file. PolicyCenter
does not.
You can base this file on existing properties files in this directory. For example, [Link] is
the audit schedule properties file for a Final Audit audit type. Name the audit schedule properties file:
[Link]

Where:
• AuditType – The name of the audit type.
• scheduleType – The schedule type can be single or series. A single audit occurs once. A series audit occurs
one or more times.
For example, Final Audits are always single audits because they only occur once per policy term. Therefore, there is
only a [Link] file.
Premium Reports are generally series audits, because there is a series of them during a policy term. Therefore, there
is only a [Link] file. Some types of audits, for example, Checking Audits, may
happen both as single audits and as series audits. These audits require audit schedule properties files for single and
series.
In the audit schedule properties file, specify one of the following values for each property. The value has the
following effect when defining an audit schedule in Product Designer:
• REQUIRED – When defining an audit schedule of this type, the user must specify a value for this field.
• EDITABLE – The user can specify a value for this field. The field is not required.
• HIDDEN – This field is hidden.
In the properties file, specify values for the following properties for schedules for your new audit type. If you do not
specify a value, the value defaults to EDITABLE.

Properties Product Designer Description

label
auditMethod Audit Method A drop‐down list to select how to conduct the [Link] drop‐down
lists values are defined in AuditMethod typelist.
Schedule Details fields that only apply to series audit schedules

frequency Scheduled A drop‐down list to select how often audits occur. Values are defined in
the AuditFrequency typelist.
intervalComputationType Schedule Basis A drop‐down list to select the schedule basis. Values are defined in the
AuditIntervalComputeType typelist. In the base configuration, the
values are:
• Calendar Month
• Policy Month
calendarMonthRoundDate Round to Next A text box to enter which day rounds up to the next month.
Month on Day

minimumAuditPeriodLength Minimum Audit Peri- A text box to enter the minimum audit period.
od (Days)

Configuring premium audit 775

Guidewire PolicyCenter 9.0.9 Configuration Guide

Properties Product Designer Description

label
excludeLastAuditPeriod Exclude Last Audit A checkbox to select whether to exclude the last audit period when cre‐
Period ating a schedule of audits.
Schedule Details fields that only apply to single audit schedules

endDateDelayAmount Single Checking A text box to enter the number of days after the policy period start the
Ends After Policy single audit ends.
Period Start (days)

endDateDelayUnit Type of Days A drop‐down list to specify the type of days to use when calculating the
end date for the audit. Values are defined in the DateCalcUnit typelist.
In the base configuration, values are:
• Calendar Days
• Business Days
Audit Report Initiation fields that apply to both single and series audit schedules

initDelayDirection Audit Initiated A drop‐down list to specify whether the audit is initiated before or after
the audit period end date. Values are defined in
AuditReportDateDirection typelist. This typelist is final.

initDelayAmount Days Before Depending upon the Audit Initiated selection, a text box to enter the
Days After number of days, before or after, to adjust the audit initiation date from
the audit period end date.
initDelayUnit Type of Days A drop‐down list to specify the type of days. Values are defined in the
DateCalcUnit typelist.

initBusinessDayAdjustment If Initiated on a Non- A drop‐down list to specify how to adjust the calculated audit initiation
Business Day date if it occurs on a non‐business day. Values are defined in the
AuditBusinessDayAdjust typelist.

Audit Deadline fields that apply to both single and series audit schedules

dueDelayDirection Audit Due A drop‐down list to specify whether the audit is due before or after the
audit period end date. Values are defined in
AuditReportDateDirection typelist. This typelist is final.

dueDelayAmount Days Before Depending upon the Audit Due selection, a text box to enter the number
Days After of days, before or after, to adjust the audit due date.

dueDelayUnit Type of Days A drop‐down list to specify the type of days. Values are defined in the
DateCalcUnit typelist.

dueBusinessDayAdjustment If Due on a Non- A drop‐down list to specify how to adjust the audit due date if it occurs
Business Day on a non‐business day. Values are defined in the
AuditBusinessDayAdjust typelist.

Escalation fields that apply to both single and series audit schedules

numDaysAfterFirstEscalation Escalate Number of A text box to enter the number of days to wait before the first escala‐
Days after First tion.
Prompt

firstEscalationPrompt First Escalation A drop‐down list to specify what prompts the first escalation. Values
Prompt are defined in the EscalationPromptType typelist.
numDaysAfterSecondEscalation Escalate Number of A text box to enter the number of days to wait before the second esca‐
Days after Second lation.
Prompt

secondEscalationPrompt Second Escalation A drop‐down list to specify what prompts the second escalation. Values
Prompt are defined in the EscalationPromptType typelist.
Miscellaneous fields

776 chapter 64: Configuring premium audit

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Properties Product Designer Description

label
paymentPlanCode Payment Plan Code A text box to enter the payment plan code. For an example, see
[Link] and
[Link].

reportingDefaultDepositPct Reporting Default A text box to enter a default deposit percentage. For an example, see
Deposit % [Link] and
[Link].

In the base configuration, PolicyCenter does not use the escalation fields. You can write code to escalate audits when
they are not completed.
Product Designer loads your new audit schedule properties files when you log out, switch change lists, or restart
Product Designer.

Audit schedule pattern

After you add or modify the audit type, you can add audit schedules in Product Designer that use this audit type.
When you add an audit schedule and commit the change in Product Designer, an XML file representing the new
audit schedule appears in the PolicyCenter configuration resources. You can view the XML file in Studio by
navigating to configuration→config→resources→productmodel→auditschedules. For example, the
[Link] file is the audit schedule for the Cancellation Audit by Voluntary audit schedule.

Configuring premium audit 777

Guidewire PolicyCenter 9.0.9 Configuration Guide

778 chapter 64: Configuring premium audit

chapter 65

Configuring side‐by‐side quoting

This topic describes how to configure side-by-side quoting for jobs (policy transactions).
Note: In PolicyCenter, the user interface uses the term policy transaction to refer to submissions,
policy changes, and other policy transactions. Policy transactions are implemented as jobs in the data
model, and referred to as jobs in PCF files, Gosu classes, and other configuration files. Therefore, the
configuration documentation refers to policy transactions as jobs.

See also

• “Multiple revision jobs and the job selected branch property” on page 734
• Application Guide

Changing the maximum number of versions in side‐by‐side

quoting
In the default configuration, the maximum number of side-by-side quotes is four. You can change the maximum
number of side-by-side quotes for each job (policy transaction) type. In [Link], the configuration parameters
are:
• RenewalMaxSideBySideQuotes
• SubmissionMaxSideBySideQuotes
• PolicyChangeMaxSideBySideQuotes
On the Job entity, the derived property MaxNumberOfSideBySideQuotes returns the maximum number of side-by-
side quotes specified in [Link] for that job.

See also

• “Side-by-side quoting parameters” on page 91

Marking a job as side‐by‐side

Setting the SideBySide bit on the Job entity marks a job (policy transaction) as side-by-side.

Configuring side‐by‐side quoting 779

Guidewire PolicyCenter 9.0.9 Configuration Guide

Side‐by‐side quoting object model

This topic describes the object model for side-by-side quoting.

Job Entity
The Job entity has the following fields related to side-by-side quoting:

Field Description
SideBySide Specifies whether this job has side‐by‐side quoting.
SelectedVersion This foreign key points to the PolicyPeriod of the selected version.
MaxNumberOfSideBySideQuotes This derived property returns the maximum number of side‐by‐side quotes specified in
[Link] for the job type.

Base Data Entities

The [Link] interface provides methods which determine if two things are
logically equivalent. There are other interfaces which extend the LogicalMatcher interface, such as the
EffDatedLogicalMatcher interface. Entities which implement this interface use the isLogicalMatcherUntyped
method to determine whether the entities are equivalent. If this method returns true then the two entities are
logically equivalent in side-by-side periods.
If you add a new entity that you would like to be base data, add a matcher that compares two entities and determines
whether the entities are equivalent.
The [Link] is an example matcher for the PersonalVehicle entity. The entity
definition shows that the entity implements the LogicalMatcher interface. In Studio, press CTRL+SHIFT+N and enter
[Link]. Then double-click the search result to open the file in the editor. View the
implementsInterface row with the Primary Value equal to [Link]. This
interface is implemented by the [Link] class (Secondary Value). In general, the
matcher is in the same package as the entity for which it provides matching.

Configuring the side‐by‐side quoting screen

The PCF file for the Side-by-Side Quoting screen is [Link]. In Studio, press CTRL+SHIFT+N and enter
the filename. Then double-click the search result to open the file in the editor.
You can configure PolicyCenter to display base data fields on the Side-by-Side Quoting screen. For example, you can
add widgets for base data fields in the columns for each side-by-side version.

IMPORTANT Guidewire requires that base data entities or fields on the Side-by-Side Quoting screen not
be editable in more than one place on a given screen.

Placing an editable widget for a base data field in the columns replicated for each version is a violation of this
requirement. This requirement applies to fields that are implicitly base data, such as contact or location information
that can be synchronized.

Posting Changes to the server

For performance reasons, the Side-by-Side Quoting screen in the base configuration posts changes to the server only as
needed.
The default configuration follows these rules for posting changes to the server on the Side-by-Side Quoting screen:
• Quoted – If the period is in the quoted state, PolicyCenter posts when the user edits any field on that period. In
the Side-by-Side Quoting screen, PolicyCenter requires the post when you edit a quoted period because
780 chapter 65: Configuring side‐by‐side quoting
 Guidewire PolicyCenter 9.0.9 Configuration Guide

PolicyCenter must open that period for edit. (The user does not explicitly open the period for edit.) Opening the
period for edit invalidates the premiums, and moves the policy period from quoted to draft status.
• Not quoted – If the edited period is not in the quoted state,
◦ A change to a widget, such as a check box, that adds or removes a coverage triggers a post to the server. The
post ensures that PolicyCenter reevaluates the availability logic in the product model.
◦ An edit to a coverage term value does not trigger a post.
In personal auto, the one exception to this rule is the PALiability coverage and its coverage terms. The
PALiability coverage has dependencies with other coverages in the policy period, therefore a post is
necessary.
Regardless of the policy period status:
• Clicking Quote All or New Version triggers a post and a page refresh.
• Clicking Use Defaults for an offering triggers a post and a page refresh.

Disable post on enter

About this task
Most changes on the Side-by-Side screen post changes back to PolicyCenter. However, posting is not necessary for
certain types of changes. By default, post on change is not selected for PCF elements.
To programmatically determine whether to post on change:

Procedure
1. In Studio, open a PCF file, such as [Link].
2. Select a PCF element, such as the BooleanRadioInput.
3. In Properties, select the PostOnChange tab, then select Enable targeted Post On Change.
4. In the disablePostOnEnter property, enter code to set this property.
When enabled, PolicyCenter checks the value of disablePostOnEnter to determine whether to post changes.

Configuring initial behavior of the side‐by‐side quoting screen

In personal auto, when you view the Side-by-Side Quoting screen, PolicyCenter creates two additional periods for a
total of three side-by-side periods. The new periods are copies of the initial period. The
configureInitialPolicies method in [Link] initializes the two
new periods. You can modify the code in this class.
The configureInitialPolicies method checks to see if the initial period has an offering. If the initial period has
an offering, the side-by-side periods are the same as the initial period. If there is no offering, the method applies the
basic, standard, and premium offerings to each side-by-side version, respectively.
In policy periods that have the Standard Program offering, the configureInitialPolicies method also removes
PACollisionCov and PAComprehensiveCov on vehicles over 10 years old.

Copying base data for side‐by‐side quoting

Base data is data which appears to be common to all versions in a side-by-side job (policy transaction). When you
make a change to base data, PolicyCenter copies that change to the other side-by-side versions. When PolicyCenter
copies the change to the other versions, it creates, removes, and updates entities across all versions as necessary.
When PolicyCenter copies base data to the other side-by-side periods, PolicyCenter opens the target periods for edit
if the target periods are quoted. PolicyCenter moves the target periods from quoted to draft status and invalidates the
quote.
Configuring side‐by‐side quoting 781
Guidewire PolicyCenter 9.0.9 Configuration Guide

In the personal auto line of business, some examples of base data are:
• Policy location
• Driver information such as motor vehicle records
• Line modifiers such as a multi-policy discount

High‐level view of base data copy

Base data copy uses the following logic to traverse the policy period graph to:
• Exclude side-by-side entities and fields from base data copy
• Copy base data entities and fields
The following illustration is a flow diagram for base data copy. Base data copy uses this logic while traversing each
node of the policy graph.
Flow diagram for base data copy

Is field
Yes Skip field.
excluded?

No

Is field a
column or Yes Copy the field.
typekey?

Field is a reference to an No
entity. Look at the referenced
entity.

Is entity
Yes Skip field.
excluded?

No

Entity is base data.

Copy Use matchers to determine
Is entity
reference to No Yes whether to create or remove a
effdated?
entity. copy on other policy periods as
needed.

If the field is an array, one-to-one, foreign key, or edge foreign key, then base data copy checks to see if the entity
pointed to is effective dated. Revisioned entities implement the EffDated delegate. Base data copy skips arrays of
entities that are not effective dated because they are implicitly side-by-side data. Base data copy stops recursion on
an entity that is side-by-side.
For a complete list of excluded entities and fields, see “Excluding side-by-side data from base data” on page 784.

Gosu methods for base data copy

Base data copy is implemented by the SideBySideBaseDataCopy method in [Link]. When base data is
modified on an underlying PolicyPeriod, this method copies the change to the other side-by-side policy periods.
As necessary, this method creates and removes entities so that the base data appears to be shared among the versions
in the side-by-side job.
Note: In the policy graph, data that is not base data is referred to as side-by-side data. Unlike base
data, side-by-side data is not synchronized between the policy graphs.
The SideBySideBaseDataCopy class uses the MatchableTreeTraverser class to traverse the policy graph of the
source and destination periods, collecting information for use during base data copy. Base data copy starts at
PolicyPeriod then recursively traverses each link until reaching data excluded from base data.
In SideBySideBaseDataCopy, the main method for copying base data is the copySlice method. This method has
three phases.
782 chapter 65: Configuring side‐by‐side quoting
 Guidewire PolicyCenter 9.0.9 Configuration Guide

Phase 1: Build map of matchable keys and edge map

The copySlice method calls the MatchableTreeTraverser class to build a map of MatchableKey objects for each
node in the policy graph. The MatchableKey objects are used to determine if nodes from two different policy
periods are logically equivalent.
The copySlice method also calls the MatchableTreeTraverser class to build an edge map. The edge map contains
a set of node to node edges for each relationship between nodes in the policy graph.
The following illustration shows the node and edge maps for the policy graph of a source policy period.
Source policy period

Legend
Source policy graph Source node map Source edge map
MatchableKey
1
B A B C
1 2 3 A Policy graph node

B B D
C D 2 2 4

C C E
3 3 5
E A
D C A
4 3 1

E
5

The copySlice method calls MatchableTreeTraverser to build node and edge maps for each destination policy
period.
The following illustration shows the node and edge maps for the policy graph of a destination policy period.
Destination policy period

Legend
Destination policy graph Destination node map Destination edge map
MatchableKey
1
B B B C
2 2 3 A Policy graph node

C B D
C D 3 2 4

D C E
4 3 5
E F
E D F
5 4 6

F
6

Phase 2: Compare source and destination node maps

The copySlice method compares the source and destination node maps and creates or removes nodes from the
destination policy graph.
In the following illustration, MatchableKey 1 exists in the source but not the destination. Therefore, copySlice
creates a corresponding MatchableKey and a copy of the A node in the destination.
The MatchableKey 6 exists only in the destination node map. Therefore, copySlice removes the MatchableKey and
the node.

Configuring side‐by‐side quoting 783

Guidewire PolicyCenter 9.0.9 Configuration Guide

Destination policy period

Source node map Destination node map

Legend
Create node that is in source
A A1 MatchableKey
1 1 but not destination 1
A Policy graph node
B B
2 2

C C
3 3

D D
4 4

E E
5 5

F Remove node that is in destination

6 but not source

Using the edge map of the source, the new node is inserted into the policy graph of the destination.

Use edge map to place node in destination policy graph

Source edge map Destination policy graph Legend

MatchableKey
B C B 1
2 3
A Policy graph node
B D C
2 4 D

C E
3 5
E A F
C A
3 1

Phase 3: Update field values in destination

The copySlice method updates field values on the destination policy graph to match values on the source.

Excluding side‐by‐side data from base data

Side-by-side data are types and fields that PolicyCenter excludes from base data. Types include entities and
delegates. Excluding these entities and fields prevents PolicyCenter from copying base data in a way that would
cause inconsistencies in the policy data.
In PolicyCenter, the levels of excluded entities and fields are:
• “Side-by-side data that base data copy must exclude” on page 785 – These are not configurable.
• “Side-by-side data that base data copy can exclude” on page 785 – These are configurable.
• “Side-by-side data in personal auto excluded from base data copy” on page 787 – These are configurable.

784 chapter 65: Configuring side‐by‐side quoting

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Note: PolicyCenter also excludes data which is only accessible through excluded entities.

Side‐by‐side data that base data copy must exclude

Note: You cannot configure the side-by-side data that Guidewire excludes.
Guidewire excludes the following entities and fields from base data copy:

Exclude from base data Details

Non‐effective dated entities Exclude all entities that are not EffDated.
Autonumber fields Exclude all fields that point to AutoNumberSequence.
Costs and transactions Exclude entities and their subtypes that implement the following delegates because the rating
engine maintains them:
• Cost
• Transaction
Policy period Exclude the following fields on the PolicyPeriod entity and its subtypes:
• ActiveWorkflow
• BranchName
• BranchNumber
• FailedOOSEEvaluation
• FailedOOSEValidation
• Job
• Policy
• PolicyTerm
• PrimaryInsuredName (denorm)
• Status
• TermNumber
• ValidQuote
• Workflows
Archivable Exclude all fields on entities that implement the Archivable delegate.
Policy location Exclude the following field on PolicyLocation:
• LocationNum
Building Exclude the following field on Building:
• BuildingNum
Policy contact role Exclude the following fields on PolicyContactRole:
• ContactDenorm
• SeqNumber

Side‐by‐side data that base data copy can exclude

The data excluded from base data copy on all lines of business are defined in Gosu and can be configured.
The following table lists data on all lines of business that base data copy excludes in the default configuration.
Guidewire strongly suggests that your implementation also exclude these.

Configuring side‐by‐side quoting 785

Guidewire PolicyCenter 9.0.9 Configuration Guide

Exclude from Details

base data
Coverages Exclude entities and their subtypes that implement the following delegates because the Product Model and
Exclusions other availability logic determine whether to add or remove them:
Conditions • Coverage
• Exclusion
• PolicyCondition
Exclude the following entities and their subtypes:
• CoverageSymbol
• CoverageSymbolGroup
Exclude the following fields on entities that implement the Coverable delegate:
• InitialCoveragesCreated
• InitialExclusionsCreated
• InitialConditionsCreated
Forms Forms inference determines whether to add or remove forms based on the contents of the policy. Therefore,
exclude the following entities and their subtypes:
• Form
• FormAssociation
• FormEdgeTable
Reinsurance Reinsurance Management determines whether to add or remove reinsurance‐related entities and fields based
on the contents of the policy. Therefore, exclude the following entity and its subtypes:
• Reinsurable
Exclude the following field on PolicyPeriod:
• RIRiskVersionList
Underwriting Underwriting issues have complex logic that determines whether to add or remove issues. Underwriting issues
Issues also have an interaction with Policy. Therefore, exclude the following entity and its subtypes:
• UWIssue
The following fields are excluded on PolicyPeriod:
• QuoteHidden
• EditLocked
Grandfather‐ Exclude fields related to grandfathering on an entity that implements the following delegates:
ing • Coverage
• Exclusion
• Modifier
In the default configuration, the following field is related to grandfathering, and therefore excluded:
• ReferenceDateInternal
Some entities, such as PersonalAutoLine, implement the ReferenceDateInternal field directly rather than
through a delegate. Exclude these fields.
Billing Exclude billing and payment‐related fields because they are managed indirectly.
Therefore, exclude the following fields on PolicyPeriod:
• DepositCollected
• InvoiceStreamCode
• NewInvoiceStream
• ReportingPatternCode
• SingleCheckingPatternCode
• SeriesCheckingPatternCode
• OverrideBillingAllocation
• BillImmediatelyPercentage
• DepositOverridePct
• DepositAmount
• WaiveDepositChange

786 chapter 65: Configuring side‐by‐side quoting

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Exclude from Details

base data
• PaymentPlanID
• PaymentPlanName
• AltBillingAccountNumber
• AllocationOfRemainder
• RefuncCalcMethod
• BillingMethod
• MinimumPremium
• PaymentPlans
Exclude the following field on PolicyLine and its subtypes:
• MinumumPremium
Reporting Exclude the following reporting‐related denormalization fields on PolicyPeriod:
fields • TotalCostRPT
• TotalPremiumRPT
• TransactionCostRPT
• TransactionPremiumRPT
Additional Exclude the following fields on PolicyPeriod:
policy‐related • BaseState
fields • WrittenDate
Exclude the following field on PolicyLine:
• NumAddInsured

Side‐by‐side data in personal auto excluded from base data copy

The following are strongly-suggested excluded data in the personal auto line of business. In the default
configuration, PolicyCenter excludes these entities and fields.

Exclude from base Details

data
Grandfathering Exclude the following field on PersonalAutoLine and PersonalVehicle:
• ReferenceDateInternal
Quick quote Exclude the following field on PersonalVehicle and PolicyDriver:
• QuickQuoteNumber
Personal auto Exclude the following entities:
• PersonalVehicle
• PersonalAutoCov
Exclude the following field:
• [Link]
Two paths to entity Exclude the following entities because they have pointers to side‐by‐side entities, and there are poten‐
tially two paths to reach them:
• VehicleDriver
• PAVhcleAddlInterest
See “Exclude entities reachable through two paths” on page 788.

The side-by-side data are configured in the [Link] class.

Configuring side‐by‐side quoting 787

Guidewire PolicyCenter 9.0.9 Configuration Guide

Exclude entities reachable through two paths

Base data copy can produce incorrect results in the following situation:
• If an entity is not excluded, and
• That entity is reachable by foreign key or array through two paths, one of which is through an excluded entity
and the other is not.
Note: Guidewire recommends that you exclude an entity reachable through two paths if one of the
paths is through an excluded entity. Guidewire especially recommends that an entity reachable
through two paths be excluded if the foreign key is non-nullable.
In personal auto, VehicleDriver entity provides an example as shown in the following illustration of an incorrect
configuration.

Correct configuration: Entity reachable through two paths excluded

VehicleDriver
1
PersonalVehicle
* * PolicyDriver

2 Version #1 Version #2
PersonalVehicle PersonalVehicle
Ford Ford

VehicleDriver VehicleDriver
Vehicle=Ford Vehicle=Ford
PolicyDriver=Susan PolicyDriver=Susan
Legend

A * B
A has a one-to-many
relationship to B
PolicyDriver PolicyDriver A B A has a foreign key to B
Susan Susan A is excluded from base
A
data copy

1. The VehicleDriver entity can be reach through PolicyDriver and PersonalVehicle. However, only
PersonalVehicle is excluded from base data copy.
2. Initially, PersonalVehicle and VehicleDriver in Version #1 and Version #2 have the same values.
The following illustration shows changes that happen when the agent edits policy Version #2.

788 chapter 65: Configuring side‐by‐side quoting

 Guidewire PolicyCenter 9.0.9 Configuration Guide

Incorrect configuration: Entity reachable through two paths not excluded, continued

3 Version #1 Version #2

PersonalVehicle PersonalVehicle PersonalVehicle

Ford Ford Chevy

VehicleDriver VehicleDriver VehicleDriver

Vehicle=Ford Vehicle=Ford Vehicle=Chevy

PolicyDriver=Susan PolicyDriver=Susan PolicyDriver=Susan

PolicyDriver PolicyDriver

Susan Susan

Legend

A B A has a foreign key to B

A A is excluded from base

data copy

3. The agent edits Version #2 and makes the following changes:

• Removes the Ford and the VehicleDriver connecting Susan to the Ford.
• Adds a Chevy and a VehicleDriver connecting Susan to the Chevy.
The following illustration shows the problems that base data copy encounters.

Incorrect configuration: Entity reachable through two paths not excluded, continued

4 Version #1 Version #2

PersonalVehicle PersonalVehicle

Ford Chevy

VehicleDriver VehicleDriver

Vehicle=Ford Vehicle=Chevy
PolicyDriver=Susan PolicyDriver=Susan Legend

A B A has a foreign key to B

A A is excluded from base

PolicyDriver PolicyDriver
data copy
Susan Susan

4. When the agent saves the edits, PolicyCenter does the base data copy.
Removing the Ford and adding the Chevy is not a problem because PersonalVehicle is side-by-side data and does
not affect other versions. However, VehicleDriver is a base data entity and must be the same in all versions. In
Configuring side‐by‐side quoting 789
Guidewire PolicyCenter 9.0.9 Configuration Guide

Version #1, the Vehicle field points to the Ford. In Version #2, it points to the Chevy. Version #1 would contain bad
data if base data copies Vehicle=Chevy to Version #1.
The VehicleDriver entity is reachable through two paths. Therefore, Guidewire recommends making the
VehicleDriver entity side-by-side data by excluding it from base data copy, as shown in the following illustration.

Correct configuration: Entity reachable through two paths excluded

VehicleDriver
1
PersonalVehicle
* * PolicyDriver

2 Version #1 Version #2

PersonalVehicle PersonalVehicle PersonalVehicle

Ford Ford Chevy

VehicleDriver VehicleDriver VehicleDriver

Vehicle=Ford Vehicle=Ford Vehicle=Chevy
PolicyDriver=Susan PolicyDriver=Susan PolicyDriver=Susan

PolicyDriver PolicyDriver
Susan Susan

Legend

A * B
A has a one-to-many
relationship to B

A B A has a foreign key to B

A A is excluded from base

data copy

1. Base data copy excludes both the PersonalVehicle and VehicleDriver entities.
2. It does not matter that the PersonalVehicle and VehicleDriver differ between the versions because base
data copy excludes them.

Configuring data excluded from base data

To make data side-by-side data, you must exclude the field or type from base data. Fields include foreign keys, edge
foreign keys, arrays, and one-to-one relationships. Fields also include scalar values such as bit, integer, and text.
Types include entities and delegates. To exclude a field or type, add it to the
[Link] class:
• Add your new field to sideBySideProperties
• Add your new side-by-side type to sideBySideTypes

Configuring quote all to ignore validation warnings

In the default configuration, Quote All in the Side by Side Quoting screen produces quotes only if there are no validation
warnings. This behavior prevents PolicyCenter from generating invalid quotes. Guidewire expects that the default
implementation is suitable for most implementations.
790 chapter 65: Configuring side‐by‐side quoting
 Guidewire PolicyCenter 9.0.9 Configuration Guide

However, in some limited cases, your implementation may need to Quote All even though there are validation
warnings. To quote when there are validation warnings, set the SideBySideQuoteBlockedByWarnings parameter in
[Link] to false. The default value is true. If this parameter is not in [Link], you need to add it.
Changing this parameter can affect product configuration files and Gosu code. Some code may assume that side-by-
side quoting only occurs if there are no validation warnings. Test thoroughly to avoid problems.
In [Link], in the call to the requestQuote method has the SideBySide parameter as an
argument.

Configuring side‐by‐side quoting 791

Guidewire PolicyCenter 9.0.9 Configuration Guide

792 chapter 65: Configuring side‐by‐side quoting