Guidewire

ClaimCenter ™

Configuration Guide
Release 9.0.5
©2001-2018 Guidewire Software, Inc.
For information about Guidewire trademarks, visit http://guidewire.com/legal-notices.
Guidewire Proprietary & Confidential — DO NOT DISTRIBUTE

Product Name: Guidewire ClaimCenter

Product Release: 9.0.5
Document Name: Configuration Guide
Document Revision: 27-April-2018
 Configuration Guide 9.0.5

Contents

About ClaimCenter documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

Conventions in this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28

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

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

Working with configuration parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
Adding custom parameters to ClaimCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
Configuration parameter behaviors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
View configuration parameters on a running server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
Access configuration parameters in Gosu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
Adding custom MIME types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
Approval parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
BulkInvoiceApprovalPattern. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
PaymentApprovalPattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
RecoveryApprovalPattern. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
RecoveryReserveApprovalPattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
ReserveApprovalPattern. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
Archive parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
ArchiveEnabled. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
AssignClaimToRetriever . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
DaysClosedBeforeArchive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
DaysRetrievedBeforeArchive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
DomainGraphKnownUnreachableTables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
PolicySystemArchivingEnabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
RestorePattern. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
SnapshotEncryptionUpgradeChunkSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
Assignment parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
Contents 3
 Configuration Guide 9.0.5

AssignmentQueuesEnabled. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
WeightedAssignmentEnabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
WeightedAssignmentGlobalDefaultWeight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
Batch process parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
BatchProcessHistoryPurgeDaysOld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
Business calendar parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
BusinessDayDemarcation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
BusinessDayEnd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47
BusinessDayStart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
BusinessWeekEnd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
HolidayList (obsolete) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
IsFridayBusinessDay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
IsMondayBusinessDay. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
IsSaturdayBusinessDay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
IsSundayBusinessDay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
IsThursdayBusinessDay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
IsTuesdayBusinessDay. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
IsWednesdayBusinessDay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49
MaxAllowedDate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49
MinAllowedDate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49
Business rules parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49
BizRulesCacheStaleTimeMinutes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49
BizRulesEnabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50
BizRulesDeploymentEnabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50
BizRulesDeploymentId . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50
BizRulesImportBootstrapRules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50
BizRulesLeafSearchNumOfHops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50
OnlineJavadocPrefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
Cache parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
ActivityPatternCacheMaxDuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
ExchangeRatesCacheRefreshIntervalSecs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
GlobalCacheActiveTimeMinutes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
GlobalCacheDetailedStats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
GlobalCacheReapingTimeMinutes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
GlobalCacheSizeMegabytes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
GlobalCacheSizePercent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
GlobalCacheStaleTimeMinutes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
GlobalCacheStatsRetentionPeriodDays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
GlobalCacheStatsWindowMinutes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
GroupCacheRefreshIntervalSecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
ScriptParametersRefreshIntervalSecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
TreeViewRefresh. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
ZoneCacheRefreshIntervalSecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
Claim catastrophe parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
HeatMapCredential . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
HeatMapServiceTemplate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
MaxCatastropheClaimFinderSearchResults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
Claim health indicator and metric parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
ClaimHealthCalcMaxLossDateInYears . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
InitialReserveAllowedPeriod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
MaxClaimResultsPerClaimHealthCalcBatch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
Clustering parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
ClusteringEnabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
ClusterMemberPurgeDaysOld. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
ConfigVerificationEnabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55

4
 Configuration Guide 9.0.5

PDFMergeHandlerLicenseKey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
SerializationWhitelistEnabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
Database parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
DisableHashJoinForClaimSearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
DisableHashJoinForTeamGroupActivities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
DisableIndexFastFullScanForClaimSearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
DisableIndexFastFullScanForRecoverySearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
DisableIndexFastFullScanForTeamGroupActivities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
DisableSequenceUtil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
DisableSortMergeJoinForClaimSearch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
DisableSortMergeJoinForTeamGroupActivities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
DiscardQueryPlansDuringStatsUpdateBatch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
IdentifyQueryBuilderViaComments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
IdentifyORMLayerViaComments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58
MigrateToLargeIDsAndDatetime2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58
QueryRewriteForClaimSearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58
SetSemiJoinNestedLoopsForClaimSearch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
UseOracleHintsOnMessageQueries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
Data destruction parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
ArchiveReferenceTrackingEnabled Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
ContactDestructionRequestAgeForPurgingResults parameter . . . . . . . . . . . . . . . . . . . . . . . .59
PersonalDataDestructionEnabled parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
Deduction parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
BackupWithholdingTypeCode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
CalculateBackupWithholdingDeduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
StandardWithholdingRate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
Document creation and document management parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
DisplayDocumentEditUploadButtons. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
DocumentContentDispositionMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
DocumentTemplateDescriptorXSDLocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
FinalDocumentsNotEditable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
MaximumFileUploadCount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
MaximumFileUploadSize. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
MaximumTotalUploadSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
Environment parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
AddressDeletionDelay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
AddressVerificationFailureAsError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
AlwaysShowPhoneWidgetRegionCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62
CurrentEncryptionPlugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62
DeprecatedEventGeneration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62
EnableAddressVerification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62
EnableInternalDebugTools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
EntityValidationOrder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
KeyGeneratorRangeSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
MemoryUsageMonitorIntervalMins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
PublicIDPrefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
ResourcesMutable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64
RetainDebugInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64
StrictDataTypes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
TwoDigitYearThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
UnreachableCodeDetection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
UnrestrictedUserName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
UseOldStylePreUpdate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
WarnOnImplicitCoercion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
WebResourcesDir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66

Contents 5
 Configuration Guide 9.0.5

Financial parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66

AllowMultipleLineItems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
AllowMultiplePayments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
AllowNegativeManualChecks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
AllowNoPriorPaymentSupplement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67
AllowPaymentsExceedReservesLimits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67
CheckAuthorityLimits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67
CloseClaimAfterFinalPayment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67
CloseExposureAfterFinalPayment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67
EnableMulticurrencyReserving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67
Financials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67
PaymentLogThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68
PaymentRoundingMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68
ReserveRoundingMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68
SetReservesByTotalIncurred . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69
UseDeductibleHandling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69
UseRecoveryReserves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69
Geocoding parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69
UseGeocodingInPrimaryApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69
UseGeocodingInAddressBook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70
ProximitySearchOrdinalMaxDistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70
ProximityRadiusSearchDefaultMaxResultCount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70
UseMetricDistancesByDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70
Globalization parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70
DefaultApplicationLanguage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70
DefaultApplicationLocale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71
DefaultApplicationCurrency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71
DefaultRoundingMode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71
MulticurrencyDisplayMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72
DefaultCountryCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72
DefaultPhoneCountryCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72
DefaultNANPACountryCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72
AlwaysShowPhoneWidgetRegionCode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72
Integration parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
ContactAutoSyncBundleCommitSize. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
ContactAutoSyncWorkItemChunkSize. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
DefaultXmlExportIEncryptionId . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
EnableMetroIntegration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
InstantaneousContactAutoSync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74
ISOPropertiesFileName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74
KeepCompletedMessagesForDays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74
LockDuringDistributedMessageRequestHandling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74
LockPrimaryEntityDuringMessageHandling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74
MetroPropertiesFileName. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74
PluginStartupTimeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
PolicySystemURL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
Miscellaneous bulk invoice activity pattern parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
BulkInvoiceItemValidationFailedPattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
BulkInvoiceUnableToStopPattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
BulkInvoiceUnableToVoidPattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
Miscellaneous financial activity parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75
CheckDeniedPattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
CheckUnableToStopPattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
CheckUnableToVoidPattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
ClaimOrExposureUnableToClosePattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76

6
 Configuration Guide 9.0.5

LastPaymentReminderPattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
RecoveryDeniedPattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
Miscellaneous parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
ClaimLossDateDemarcation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
ConsistencyCheckerThreads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
EnableClaimNumberGeneration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
EnableClaimSnapshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
EnableStatCoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
MaintainPolicyValidationLevelOnPolicyChange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
MaxCachedClaimSnapshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
MaxStatCodesInDropdown. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
ProfilerDataPurgeDaysOld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
VendorNotificationAPIRetryTime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
TransactionIdPurgeDaysOld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
PDF print settings parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78
DefaultContentDispositionMode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78
PrintFontFamilyName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78
PrintFontSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78
PrintFOPUserConfigFile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78
PrintHeaderFontSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78
PrintLineHeight. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78
PrintListViewBlockSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
PrintListViewFontSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
PrintMarginBottom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
PrintMarginLeft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
PrintMarginRight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
PrintMarginTop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
PrintMaxPDFInputFileSize. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
PrintPageHeight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
PrintPageWidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
PrintPdfDefaultBaseFileExtension. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
PrintPdfMimeType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
Print settings parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
PrintCsvDefaultBaseFileExtension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
PrintCsvMimeType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
PrintDefaultBaseFileName . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
Scheduler and workflow parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
IdleClaimThresholdDays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
SchedulerEnabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81
SeparateIdleClaimExceptionMonitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81
WorkflowLogDebug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81
WorkflowLogPurgeDaysOld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81
WorkflowPurgeDaysOld. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81
WorkflowStatsIntervalMins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81
Search parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81
FreeTextSearchEnabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82
MaxActivitySearchResults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82
MaxBulkInvoiceSearchResults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82
MaxCheckSearchResults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82
MaxClaimSearchResults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82
MaxContactSearchResults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82
MaxContactDocumentSearchResults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82
MaxDocTemplateSearchResults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82
MaxDuplicateContactSearchResults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
MaxNoteSearchResults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83

Contents 7
 Configuration Guide 9.0.5

MaxPolicySearchResults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
MaxRecoverySearchResults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
Security parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
EnableDownlinePermissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
FailedAttemptsBeforeLockout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
LockoutPeriod. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
LoginRetryDelay. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84
MaxACLParameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84
MaxPasswordLength . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .84
MinPasswordLength . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
RestrictContactPotentialMatchToPermittedItems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
RestrictSearchesToPermittedItems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
SessionTimeoutSecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
UseACLPermissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
Segmentation parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
ClaimSegment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
ClaimStrategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86
ExposureSegment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86
ExposureStrategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86
Service request parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86
ServiceRequestAPIMaxDaysKeepActiveWithoutInvoice . . . . . . . . . . . . . . . . . . . . . . . . . . .86
ServiceRequestAPIMaxMessageResults. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86
ServiceRequestAPIMaxSearchResults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86
Statistics, team, and dashboard parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86
AddIndexHintForLossDate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
AgingStatsFirstDivision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
AgingStatsSecondDivision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
AgingStatsThirdDivision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
CalculateLitigatedClaimAgingStats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
DashboardIncurredLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
DashboardShowByCoverage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
DashboardShowByLineOrLoss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
DashboardWindowPeriod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .87
GroupSummaryShowUserGlobalWorkloadStats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88
UserStatisticsWindowSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88
User interface parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88
ActionsShortcut. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88
AutoCompleteLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88
HidePolicyObjectsWithNoCoveragesForLossTypes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88
HighlyLinkedContactThreshold . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
IgnorePolicyTotalPropertiesValue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
IgnorePolicyTotalVehiclesValue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
InputMaskPlaceholderCharacter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
ListViewPageSizeDefault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
MaxBrowserHistoryItems (obsolete) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
MaxChooseByCoverageMenuItems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
MaxChooseByCoverageTypeMenuItems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
MaxClaimantsInClaimListViews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
MaxTeamSummaryChartUserBars. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
QuickJumpShortcut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
RequestReopenExplanationForTypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
ShowCurrentPolicyNumberInSelectPolicyDialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
ShowFixedExposuresInLossDetails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
ShowNewExposureChooseByCoverageMenuForLossTypes . . . . . . . . . . . . . . . . . . . . . . . . .90
ShowNewExposureChooseByCoverageTypeMenuForLossTypes . . . . . . . . . . . . . . . . . . . . .91

8
 Configuration Guide 9.0.5

ShowNewExposureMenuForLossTypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91
UISkin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
WebUIAJAXTimeout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
Work queue parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
InstrumentedWorkerInfoPurgeDaysOld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
WorkItemCreationBatchSize. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
WorkItemPriorityMultiplierSecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
WorkItemRetryLimit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
WorkQueueHistoryMaxDownload. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
WorkQueueThreadPoolMaxSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
WorkQueueThreadPoolMinSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
WorkQueueThreadsKeepAliveTime. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .94

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

4 Working in Guidewire Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

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

5 Working with Guidewire Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Improving Studio performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Contents 9
 Configuration Guide 9.0.5

Set the maximum amount of memory available to Guidewire Studio . . . . . . . . . . . . . . . . . . 117

Set the amount of memory for project builds in Guidewire Studio . . . . . . . . . . . . . . . . . . . . 118
Resetting Guidewire Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Rebuild the Studio project files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Rebuild the Studio file index cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Setting font display options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

6 ClaimCenter Studio and Gosu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Gosu building blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Gosu case sensitivity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Working with Gosu in ClaimCenter Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Gosu packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Create a new package. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Gosu classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Create a new Gosu class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
ClaimCenter base configuration classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Class visibility in Studio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Preloading Gosu classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Gosu enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Create a new enhancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
XML and GX models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Define a GX model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Script parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Script parameters overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Script parameters as global variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Script parameter examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Working with script parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Referencing a script parameter in Gosu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Part 3
Guidewire Studio editors
7 Using the Studio editors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Editing in Guidewire Studio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Working in the Gosu editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

8 Using the plugins registry editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

What are plugins?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Plugin implementation classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
What is the plugins registry? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Startable plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Working with plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Create a plugins registry item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Add an implementation to a plugins registry item . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Set environment and server context for plugin implementations . . . . . . . . . . . . . . . . . . . . . 138
Customizing plugin functionality. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Working with plugin versions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

9 Working with web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Using the web service editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Defining a web service collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

10 Implementing QuickJump commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

What Is QuickJump?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Adding a QuickJump navigation command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

10
 Configuration Guide 9.0.5

Implementing QuickJumpCommandRef commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Implementing StaticNavigationCommandRef commands . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Implementing ContextualNavigationCommandRef commands . . . . . . . . . . . . . . . . . . . . . . 146
Checking permissions on QuickJump navigation commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

11 Using the entity names editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Entity names editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Variable table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
The Entity Path column . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
The Use Entity Name? column . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
The Sort columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Gosu text editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Including data from subentities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Entity name types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

12 Using the messaging editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

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

13 Using the display keys editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

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

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

15 The ClaimCenter data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

What is the data model? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
The data model in Guidewire application architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
The base data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Working with dot notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Overview of data entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Data entity metadata files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
The extensions properties file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Working with entity definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Search for an existing entity definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Create a new entity definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Extend an existing entity definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
ClaimCenter data entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Contents 11
 Configuration Guide 9.0.5

Data entities and the application database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

ClaimCenter database tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Data objects and scriptability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Base ClaimCenter data objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Delegate data objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Entity data objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Extension data objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Non-persistent entity data objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Subtype data objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
View entity data objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
View entity extension data objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Data object subelements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
<array> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
<column> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
<edgeForeignKey> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
<events>. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
<foreignkey> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
<fulldescription> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
<implementsEntity> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
<implementsInterface>. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
<index> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
<onetoone>. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
<remove-index> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
<tag> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
<typekey> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219

16 Working with associative arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

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

17 Modifying the base data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

Planning changes to the base data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Overview of data model extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Strategies for extending the base data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
What happens if you change the data model? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Naming restrictions for extensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Defining a new data entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Create a new entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Default properties on a new entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Extending a base configuration entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Create a new extension file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Working with attribute and element overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Overriding data type attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Overriding nested subelements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Extending the base data model: examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Creating a new delegate object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Extending a delegate object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
12
 Configuration Guide 9.0.5

Defining a subtype. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

Defining a reference entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Define an entity array. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Implementing a many-to-many relationship between entity types . . . . . . . . . . . . . . . . . . . . 251
Extending an existing view entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
Removing objects from the base configuration data model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Remove a base extension entity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Remove an extension to a base object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Implications of modifying the data model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Deploying data model changes to the application server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

18 Example: Creating assignable entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

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

19 Data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

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

Contents 13
 Configuration Guide 9.0.5

20 Field validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

Field validators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Field validator definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
<FieldValidators> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
<ValidatorDef> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Modifying field validators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Using <column-override> to modify field validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

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

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

22 The ClaimCenter archive domain graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
Claim purging and the archive domain graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Understanding ClaimCenter entity ownership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Foreign key ownership in the archive domain graph. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Inverse foreign key ownership in the archive domain graph . . . . . . . . . . . . . . . . . . . . . . . . 330
Ownership relationships in the ClaimCenter archive domain graph. . . . . . . . . . . . . . . . . . . . . . . 330
Entities in the archive domain graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Archive entities and the RootInfo delegate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Archive entities and the Extractable delegate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Archive entities and the OverlapTable delegate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
Data model changes that impact archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Working with shared entity data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
About cycles in the archive domain graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Circular foreign key references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Ownership cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Validation of the archive domain graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
14
 Configuration Guide 9.0.5

Graph validation errors that prevent the server from starting . . . . . . . . . . . . . . . . . . . . . . . . 337
Graph validation warnings that do not prevent the server from starting. . . . . . . . . . . . . . . . . 338
About archive domain graph errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Resolve archive graph errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Resolve archive graph warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Resolving issues with custom archive entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Defining a cross-domain tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
About archive graph error messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Graph validation errors generated during server startup . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Graph validation errors generated at run time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
About archiving and event messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Viewing the archive domain graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Generate the archive domain graph in PDF format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Generate the archive domain graph in PNG format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Using archive logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346

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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362

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

Page configuration files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Page configuration elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
What is a PCF element? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Contents 15
 Configuration Guide 9.0.5

Types of PCF elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364

Identifying PCF elements in the user interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365
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
Changing theme colors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Advanced theming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370

25 Data panels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

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

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

Location group overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
Define a location group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
Location groups as navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Location groups as tab menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Location groups as menu links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
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

Search overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Database search configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
ClaimCenter database search functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
Configuring database search criteria in XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Customizing a database search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Deploying customized database search files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Search criteria validation on server start-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Free-text search configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Overview of free-text search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
Free-text search system architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
Enabling free-text search in ClaimCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Enable free-text search in ClaimCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Configuring the Guidewire Solr Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Configuring free-text search for indexing and searching . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
Configuring the free-text batch load command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428

16
 Configuration Guide 9.0.5

Configuring the Search by Contact screen for free-text search. . . . . . . . . . . . . . . . . . . . . . . 428

Modifying free-text search for additional fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Localizing free-text search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433

29 Configuring special page functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435

Adding print capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Overview of print functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Types of printing configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
Working with a PrintOut page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Overriding the print settings in a file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
Troubleshooting print configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Linking to a specific page using an EntryPoint PCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Entry points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Create a Forwarding EntryPoint PCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
Linking to a specific page using an ExitPoint PCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Creating an ExitPoint PCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445

Part 6
Workflow, activity patterns, and email configuration
30 Using the workflow editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
Workflow in Guidewire ClaimCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
Workflow in Guidewire Studio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
Access the workflow editor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
Workflow editor window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
Workflow editor elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
Understanding workflow steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
Using the workflow right-click menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
Using search with workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454

31 Guidewire workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455

Understanding workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Workflow instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Work items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
Workflow process format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
Workflow step summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
Workflow Gosu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
Workflow versioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
Workflow localization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
Workflow structural elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
<Context> workflow element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
<Start> workflow element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
<Finish> workflow element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Common step elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Enter and exit scripts in workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Asserts in workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Events in workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Notifications in workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Branch IDs in workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
Basic workflow steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
AutoStep workflow step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463
MessageStep workflow step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
ActivityStep workflow step. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
ManualStep workflow step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
Outcome workflow step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468

Contents 17
 Configuration Guide 9.0.5

Step branches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468

Working with branch IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
GO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
TRIGGER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
TIMEOUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Creating new workflows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
Clone an existing workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
Extend an existing workflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
Extending a workflow: a simple example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
Instantiating a workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
A simple example of instantiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
The workflow engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Distributed execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Synchronicity, transactions, and errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
Workflow subflows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Workflow administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
Workflow debugging and logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
Process logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486

32 Defining activity patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487

What is an activity pattern? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
Pattern types and categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
Activity pattern types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
Categorizing activity patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
Using activity patterns in Gosu. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Calculating activity due dates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Target due dates (deadlines) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Escalation dates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
Defining the business calendar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
Base configuration activity patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
Activity pattern objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
Use activity patterns with eocuments and emails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Specifying document and email templates in CSV files . . . . . . . . . . . . . . . . . . . . . . . . . . . 493
Localizing activity patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493

33 Guidewire ClaimCenter and Email . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495

Configure email plugin parameters in Guidewire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
The email object model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
Email utility methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
Email transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
About email templates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
Create an email template file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
Create an email template descriptor file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
Localize an email template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
Sending emails from Gosu code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
Saving an email message as a document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 500
Creating an HTML email within code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 501

Part 7
Testing Gosu code
34 Testing and debugging your configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
Testing ClaimCenter with Guidewire Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
Running ClaimCenter without debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
Debugging ClaimCenter within Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512

18
 Configuration Guide 9.0.5

Debugging a ClaimCenter server that is running outside of Studio. . . . . . . . . . . . . . . . . . . . 512

The Studio debugger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
Setting breakpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
Set a breakpoint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
View a breakpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
Remove a breakpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
Stepping through code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
Viewing current values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
Viewing variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
Defining a watch list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
Resuming execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
Using the Gosu scratchpad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Run the Gosu scratchpad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Executing code in the Gosu scratchpad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Accessing application data in the Gosu scratchpad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Run scratchpad code in the application server debug process . . . . . . . . . . . . . . . . . . . . . . . 517
Understanding internally generated code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
Manually generate code for configuration resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
Enable or disable code generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
Change code generation for XML classes to generate source code . . . . . . . . . . . . . . . . . . . . 518
Change PCF code generation error behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
Suggestions for testing rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
Compiling and building the application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520

35 Using GUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521

The TestBase class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
Overriding TestBase methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522
Configuring the server environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
Server runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523
Configuring the test environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524
Set default configuration parameters for all tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524
Add a named set of configuration parameters for tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
View test configuration settings before launching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
Configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
Creating a GUnit test class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526
Server tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527
Using entity builders to create test data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529
Creating an entity builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529
Entity builder examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
Creating new builders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534

Part 8
Guidewire ClaimCenter configuration
36 Configuring policy behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
Understanding aggregate limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
Aggregate limit data model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543
Defining aggregate limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544
Aggregate limit configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
Storing aggregate limit data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550
Aggregate limit used recalculation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550
Advanced aggregate limit configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550
The AggregateLimitTransactionPlugin plugin implementation . . . . . . . . . . . . . . . . . . . . . . 551
Example – Configure a claim for aggregate limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552
Example – Configure aggregate limits for deductible recoveries . . . . . . . . . . . . . . . . . . . . . 553
Contents 19
 Configuration Guide 9.0.5

How to specify policy menu links. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554

How to define internal ClaimCenter policy fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554
How to create internal-only fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554

37 Configuring snapshot views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557

How ClaimCenter renders claim snapshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557
Understanding snapshot PCF interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557
Encrypting claim snapshot fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558
How to configure snapshot templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558
Snapshots and data model extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559

38 Configuring lines of business. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561

LOB typelists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
LOB Typelists and policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
LOB typelists and incidents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
Relationships among LOB typelists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
Edit a typecode with multiple parents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565
LOB typelist validations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565
Relationships between LOB typelists and other typelists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566
LOB typelists referenced by non-LOB typelists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566
LOB typelists that reference non-LOB typelists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567
Modal PCF files that use LOB typelists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567
Editing LOB typelists and typecodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568
LOB typelists editor tabs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568
LOB typelists editor right-click menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569
Editing an LOB typelist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569
Editing an LOB typecode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570
Adding a child LOB typecode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570
Add a non-LOB typecode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
Adding a parent to an LOB typecode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
Removing an LOB typecode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
Retiring an LOB typecode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
Removing an LOB typecode from its parent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 572
Exporting an LOB typecode or typelist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573
Localize an LOB typelist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573
Coverages and policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573
Personal auto coverages and the LOB typelists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573
Personal auto coverages in the base configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574
Add a new LossType typecode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576
Creating detail views and list views for a new loss type . . . . . . . . . . . . . . . . . . . . . . . . . . . 576
Adding a new ExposureType typecode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577
Creating detail views for a new exposure type. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 577

39 Configuring services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579

How to import and configure services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
Vendor service tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 579
Vendor service details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582
How to import a service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
How to edit a service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
How to localize services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584
How to configure the depth of the service hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
Service request data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
Lifecycle of a service request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591
Quote only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591
Quote and perform service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591
Service only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 592
20
 Configuration Guide 9.0.5

Unmanaged service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593

How to configure service requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594
How to create service requests dynamically . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594
How to manage changes to service requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595
How to configure service request metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596
Example - Creating a custom service request metric. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 596

40 Configuring business rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601

The business rules plugin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
What can you modify in the business rules plugin class? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
Working with the business rules plugin class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
Configuring methods and properties for business rule conditions. . . . . . . . . . . . . . . . . . . . . 602
Rule actions on custom entity extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
Triggering point mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
Custom rule utility functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603
Rule contexts and rule context definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604
Configuring applicability criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612
Add a new ClaimCenter applicability criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613

41 Configuring deductibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615

Deductible data model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 615
Typecodes for deductibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
Permissions for deductibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
Deductibles and checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
Transferring checks and deductibles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
Recoding payments and deductibles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 617
Deleting, voiding, and stopping checks and deductibles . . . . . . . . . . . . . . . . . . . . . . . . . . . 618
Denying or resubmitting checks and deductibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618
Applying deductibles on multicurrency checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618
Cleared or issued checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618
Cloning checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618
Deductibles and rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 618

42 Configuring weighted workload assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621

About weighted workload configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621
Enable weighted workload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622
Weighted workload permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622
Workload weight recalculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622
Weighted workload data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624
Weighted workload configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
Workload weight computation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
User assignment API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
Weighted workload assignment strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627
Custom configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628
Configuring the default weight in code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628
Creating custom workload strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628
Adding criteria to workload classifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629
Example - Add flag status to claim workload classification. . . . . . . . . . . . . . . . . . . . . . . . . 630
Adding workload classification conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 633
Example - Add a color condition to claim workload classification . . . . . . . . . . . . . . . . . . . . 633

43 Working with catastrophe bulk associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641

Catastrophe bulk association configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641
The GWCatastropheEnhancement class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641
Catastrophes data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642
Catastrophe configuration parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 642

Contents 21
 Configuration Guide 9.0.5

44 Configuring the catastrophe dashboard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643

Technical features of the catastrophe dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643
Heat map generation and components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643
Server, browser, and service interactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644
Principal heat map classes and files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645
Data sets and map data points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647
Data sets and caching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647
Use or add filters in a data set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
Configuring the catastrophe heat map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
Common configuration use cases for heat maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649
Advanced configuration topics for heat maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649

45 Configuring duplicate claim and check searches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653

Understanding the Gosu templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653
Duplicate claim search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654
Change search criteria for duplicate claim search. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654
Duplicate check search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655

46 Configuring claim health metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657

Adding a new tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657
Example - Adding a new tier to ClaimCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658
Adding a high-risk indicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660
Example – Add a high-risk indicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660
Adding a new claim metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663
Example – Add a new claim metric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663
How to configure days in metrics calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667

47 Configuring recently viewed claims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669

Add a loss date to the recently viewed claim list. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669

48 Configuring incidents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671

Implicit incidents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671
Explicit incidents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672
Quick claim configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 672
Injured contact role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
Contact role constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
The Incident data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
Incidents and the Claim Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
Incidents and the Exposure entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
The Incident entity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674
Incidents and the Coverage entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674
Entities and typelists related to incidents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674

49 Configuring special handling instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675

Creating service tiers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675
Special handling data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676
Add service tiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676
Configure email notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677
Configure claim headline comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 677
Configure activity patterns for special handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 678

50 Configuring roles and relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679

Adding contact roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
Example - Add a contact role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679
Policy contact roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680
About contact roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 680
Defining role constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681
22
 Configuration Guide 9.0.5

About contact role constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 681

About entity role constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682
How configuring roles impacts entity data and types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684
Generated role methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 684
Entity property for Exclusive or Exclusive & Required Roles . . . . . . . . . . . . . . . . . . . . . . . 685
Entity array key for required or ZeroToMore role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
Avoiding errors with contact properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686
Avoiding compilation errors with generated entity and role properties . . . . . . . . . . . . . . . . . 687
Add a new contact role: example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688
Relationships between contacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690
Adding a bidirectional contact relationship: example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690
Add new contact relationship to ClaimCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690
Test new contact relationship in ClaimCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 692
Add new contact relationship to ContactManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
Test new contact relationship in ContactManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694

51 Configuring multicurrency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697

How to configure multicurrency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697
Multicurrency in financial calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698
Multicurrency data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698
Foreign exchange adjustments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701
Foreign exchange transactions and calculated values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702
Foreign exchange adjustments on claims and payments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702
Applying foreign exchange adjustments multiple times . . . . . . . . . . . . . . . . . . . . . . . . . . . 703

52 Claim archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705

How ClaimCenter selects claims for archive eligibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 705
Restore archived claims using system tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706
Monitoring archiving activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707
Understanding errors in the archiving process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707
Logging archiving activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707
Archive configuration options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708
Archive configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708
Archive rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708
Default group claim archiving rule set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708
Archive events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709
Archiving and the SQL Server database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709
Understanding the archiving plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709

53 Configuring personal data destruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 711

Data destruction configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
Data destruction web service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 712
PersonalDataDestructionAPI web service methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713
Lifecycle of a personal data destruction request. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713
Personal data destruction request entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
Example of a request made with AddressBookUID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
Example of a request made with PublicID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
Typelists for status of personal destruction workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 715
Work queues used in personal data destruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716
PersonalDataDestructionController class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717
Data model configuration for data destruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718
DestructionRootPinnable delegate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718
Do Not Process flag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719
Display keys for data destruction messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719
Obfuscatable delegate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 719
Obfuscator interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720
Contents 23
 Configuration Guide 9.0.5

Marking entity fields for obfuscation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 720

ContactInfo support for personal data destruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 721
Entity domain graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
Identifying archived objects that affect destruction of data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
Data Protection Officer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723
Data Protection Officer permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723
Notifying the data protection officer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723
Data destruction purge configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724
Purging and the ClaimCenter entity domain graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724
Defining the destroyer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 724
PersonalDataPurge event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725
Specifying which objects in the graph can be destroyed . . . . . . . . . . . . . . . . . . . . . . . . . . . 726
Data obfuscation in ClaimCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727
Implementing the Obfuscatable delegate in an entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728
Implementing the Obfuscator interface in an entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728
Personal data obfuscator classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729

Part 9
Guidewire ClaimCenter financials
54 Configuring ClaimCenter financials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735
The financials data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735
Transactions and cost types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737
Financials-related typelists. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737
Financial transaction statuses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738
Financial configuration parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 739
Batch processes related to checks and payments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740
The financials escalation process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 740
The TAccounts Escalation process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741
The bulk invoice escalation process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 741
Scheduling the financials batch processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 742

55 ClaimCenter financial calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743

Financial calculation APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743
The FinancialsCalculations class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743
Understanding ClaimCenter financial calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 744
Using the predefined financial calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745
Using a FinancialsCalculator object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745
Obtaining calculated amounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 745
The FinancialsCalculationUtil class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746
Different ways to retrieve an amount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747
Forming composite custom expressions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747
Creating custom financial gosu classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748
Predefined financial calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749
Payment calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 749
Reserve calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 750
Recovery calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751
Floating financials calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 751
Predefined reinsurance calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753
Predefined reinsurance calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753
Predefined reinsurance reserves calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754
Predefined reinsurance recoveries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754
Retrieving transaction IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754
Financial calculations with a negative value. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755
Eroding and non-eroding payments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756
24
 Configuration Guide 9.0.5

Using floating financial calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756

Example – Using reserve lines in multiple currencies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756

56 Creating financial transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759

Setting reserves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759
Setting reserve values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 759
Creating reserve transactions directly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761
Creating checks and payments by using CheckCreator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 761
Creating recovery transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 763
Claim objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764
Exposure objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764
Creating recoveries directly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764
Creating recovery reserve transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765
Setting recovery reserve values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765
Creating recovery reserve transactions directly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766

57 Configuring ClaimCenter financial screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767

Configuring the financial summary screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767
The Financials Summary page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 767
Configuring the filter drop-down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 768
Defining the model used by a panel set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 769
Controlling the display of the financial model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 770
Configuring reserve behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772
Understanding how configuration impacts reserves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 772
Reserve permissions and authority limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 775
Set the number of reserve items to show. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 776
Configuring checks and payments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777
Understanding checks and payments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 777
Permissions and authority limits that apply to payments . . . . . . . . . . . . . . . . . . . . . . . . . . . 777
Editing checks in rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778
Configuring the check wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779
Configuring the check wizard recurrence settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 779
Configuring the check wizard’s default payment type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780
Configuring straight-through invoice processing (STIP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 780
Using the IInvoiceAutoProcessingPlugin plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 781
Disabling STIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 782
Configuring STIP – modifying limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 783
Configuring financial holds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 784
Modifying the automatic setting of coverage in question . . . . . . . . . . . . . . . . . . . . . . . . . . 784
Modifying the conditions for applying financial holds . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785
Modifying claimcost initial reserves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785
Configuring authority limits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 785
Add an authority limit type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786
Add an authority limit filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 787
Configuring bulk invoice payments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791
Overview of bulk invoices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 791
The bulk invoices data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 792
Configuring the bulk invoices feature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 793

Contents 25
Configuration Guide 9.0.5

26
 Configuration Guide 9.0.5

About ClaimCenter documentation

The following table lists the documents in ClaimCenter documentation:

Document Purpose
InsuranceSuite Guide If you are new to Guidewire InsuranceSuite applications, read the InsuranceSuite Guide for
information on the architecture of Guidewire InsuranceSuite and application integrations. The
intended readers are everyone who works with Guidewire applications.
Application Guide If you are new to ClaimCenter 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
intended readers are everyone who works with ClaimCenter.
Database Upgrade Guide Describes the overall ClaimCenter upgrade process, and describes how to upgrade your ClaimCenter
database from a previous major version. The intended readers are system administrators and
implementation engineers who must merge base application changes into existing ClaimCenter
application extensions and integrations.
Configuration Upgrade Guide Describes the overall ClaimCenter upgrade process, and describes how to upgrade your ClaimCenter
configuration from a previous major version. The intended readers are system administrators and
implementation engineers who must merge base application changes into existing ClaimCenter
application 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 ClaimCenter versions. Intended readers are business
users and system administrators who want an overview of new features and changes to features.
Consult the “Release Notes Archive” part of this document for changes in prior maintenance releases.
Installation Guide Describes how to install ClaimCenter. The intended readers are everyone who installs the application
for development or for production.
System Administration Guide Describes how to manage a ClaimCenter system. The intended readers are system administrators
responsible 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
interface (PCF) files. The intended readers are all IT staff and configuration engineers.
PCF Reference Guide Describes ClaimCenter PCF widgets and attributes. The intended readers are configuration engineers.
Data Dictionary Describes the ClaimCenter data model, including configuration extensions. The dictionary can be
generated at any time to reflect the current ClaimCenter configuration. The intended readers are
configuration 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 ClaimCenter configuration. The intended readers are
configuration engineers.
Globalization Guide Describes how to configure ClaimCenter for a global environment. Covers globalization topics such as
global regions, languages, date and number formats, names, currencies, addresses, and phone
numbers. The intended readers are configuration engineers who localize ClaimCenter.

About ClaimCenter documentation 27

 Configuration Guide 9.0.5

Document Purpose
Rules Guide Describes business rule methodology and the rule sets in ClaimCenter Studio. The intended readers
are business analysts who define business processes, as well as programmers who write business
rules in Gosu.
Contact Management Guide Describes how to configure Guidewire InsuranceSuite applications to integrate with ContactManager
and how to manage client and vendor contacts in a single system of record. The intended readers are
ClaimCenter 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 ClaimCenter with
external 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
plugin code in Gosu or Java.
Java API Reference Javadoc-style reference of ClaimCenter 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
language, including for rules and PCF configuration.
Gosu API Reference Javadoc-style reference of ClaimCenter Gosu classes and properties. The reference can be generated
at any time to reflect the current ClaimCenter 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.

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 ClaimCenter 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<someArray.length(), 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 http://server_name/index.html.
and URLs.

Support
For assistance, visit the Guidewire Community.
28 About ClaimCenter documentation
 Configuration Guide 9.0.5

Guidewire Customers
https://community.guidewire.com

Guidewire Partners
https://partner.guidewire.com

About ClaimCenter documentation 29

 Configuration Guide 9.0.5

30 About ClaimCenter documentation

part 1

ClaimCenter configuration basics

Configuration Guide 9.0.5
chapter 1

Overview of ClaimCenter
configuration

This topic provides some basic information, particularly about the Guidewire ClaimCenter 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 ClaimCenter 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.

Overview of ClaimCenter configuration 33

 Configuration Guide 9.0.5

Change or augment the ClaimCenter application

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

Modify the ClaimCenter interface

You can configure the text labels, colors, fonts, and images that comprise the visual appearance of the ClaimCenter
interface. You can also add new screens and modify the fields and behavior of existing screens.

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 claim adjusters.

Integrate with external systems

You can integrate ClaimCenter 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 methods that are reserved for Guidewire use only. Gosu code
written to configure ClaimCenter must never call an internal method for any reason. Future releases of ClaimCenter
can change or remove an internal method without notification.
The following packages contain Guidewire internal methods.
• All packages in com.guidewire.*
• Any package whose name or location includes the word internal
Gosu configuration code can safely call methods defined in any gw.* package (except for those packages whose
name or location includes the word internal).

How you configure ClaimCenter

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).
34 chapter 1 Overview of ClaimCenter configuration
 Configuration Guide 9.0.5

See also
• “Using the Studio editors” on page 133

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 35
• “The production environment” on page 35

The development environment

The development environment for ClaimCenter 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 Software Configuration 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
ClaimCenter. 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 ClaimCenter has the following characteristics:
• It runs as an application within an application server.
• It handles web clients, or SOAP message requests, for claim information or services.
• It generates the web pages for browser-based client access to ClaimCenter.

Types of application environments 35

 Configuration Guide 9.0.5

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 36
• “Deploying changes to the production server” on page 36

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 ClaimCenter 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 ClaimCenter 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 ClaimCenter 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:

ClaimCenter/webapps/cc

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.

36 chapter 1 Overview of ClaimCenter configuration

 Configuration Guide 9.0.5

4. Navigate to your development installation dist directory (for example, ClaimCenter/dist). The build script
places the new cc.war or cc.ear file in this directory.
5. Copy the newly created cc.war file to the production webapps folder (for Tomcat). If using WebSphere or
WebLogic, use the administrative console to deploy the cc.ear 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.

Next steps
See also
• If working in a clustered server environment, see the System Administration 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

ClaimCenter Administration→Utilities→Export Data Security Dictionary “Generating the security dictionary from ClaimCenter”
on page 38
Command prompt gwb genDataDictionary Security Dictionary “Generating the data and security dictionaries in HTML
Data Dictionary format” on page 37
“Generating the data and security dictionaries in XML
format” on page 38

See also
• To understand the Data Dictionary and the information it includes, see “Working with the Data Dictionary” on
page 165.
• 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 ClaimCenter Data Dictionary and ClaimCenter Security Dictionary in HTML format, run the
following command from the ClaimCenter directory:

gwb genDataDictionary

This command generates HTML files for the dictionaries in the following locations:

ClaimCenter/build/dictionary/data
ClaimCenter/build/dictionary/security

To view a dictionary, open its index.html file from the listed locations.

Regenerating the data and security dictionaries 37

 Configuration Guide 9.0.5

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
ClaimCenter directory:

gwb genDataDictionary -DoutputFormat=xml

This command generates the following XML and XSD files for the dictionaries:

ClaimCenter/build/dictionary/data/entityModel.xml
ClaimCenter/build/dictionary/data/entityModel.xsd

ClaimCenter/build/dictionary/security/securityDictionary.xml
ClaimCenter/build/dictionary/security/securityDictionary.xsd

The parameter that specifies the output format has two allowed values.

-DoutputFormat={html|xml}

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 ClaimCenter

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 ClaimCenter itself.
To generate the Security Dictionary from ClaimCenter, you must have administrative privileges and be able to
access the ClaimCenter 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

Next steps
See also
• Installation Guide

Aspects of regenerating the Security Dictionary

Guidewire ClaimCenter stores the role information used by the Security Dictionary in the base configuration in the
following file:

ClaimCenter/modules/configuration/config/import/gen/roleprivileges.csv

38 chapter 1 Overview of ClaimCenter configuration

 Configuration Guide 9.0.5

ClaimCenter does not write this file information to the database.

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

IMPORTANT It is possible for the Security Dictionary to become out of synchronization with the actual roles in
your database. Guidewire ClaimCenter bases the Security Dictionary on the file roleprivileges.csv only.

Managing configuration changes

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

Managing configuration changes 39

 Configuration Guide 9.0.5

40 chapter 1 Overview of ClaimCenter configuration

chapter 2

Application configuration parameters

This topic covers the ClaimCenter 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 config.xml. 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 config.xml file in the base configuration contains all available parameters. To set a parameter, edit the file,
locate the parameter, and change its value. ClaimCenter configuration parameters are case-insensitive. If a parameter
does not appear in the file, Guidewire ClaimCenter uses the default value, if the parameter has one.

Adding custom parameters to ClaimCenter

You cannot add new or additional configuration parameters to config.xml. If you want to add custom parameters to
your configuration of ClaimCenter, 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 128.

Configuration parameter behaviors

The configuration parameters in config.xml may implement the following behaviors:

Behavior Summary More information

Required You must supply a value. “Required” on page 42

Application configuration parameters 41

 Configuration Guide 9.0.5

Behavior Summary More information

Set for environment You can set a different value for different servers in the “Set for environment” on page 42
same environment.
Development The parameter is valid only on a development environment “Development environment only” on
environment only server. page 42
Dynamic You can change the parameter value on a running server. “Dynamic” on page 42
Permanent Once you start the server, you cannot change the “Permanent” on page 42
parameter value.
Semi-permanent Once you start the server, you can change the parameter “Semi-permanent” on page 43
value 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, ClaimCenter 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 ClaimCenter, 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.

42 chapter 2 Application configuration parameters

 Configuration Guide 9.0.5

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, ClaimCenter throws an error.

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 ClaimCenter server. To
change the values dynamically, you can create a management integration plugin.

Procedure
1. Open the Server Tools page of the ClaimCenter 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:

gw.api.system.CCConfigParameters
gw.api.system.PLConfigParameters

For example:

var businessDayEnd = gw.api.system.PLConfigParameters.BusinessDayEnd.Value

var forceUpgrade = gw.api.system.PLConfigParameters.ForceUpgrade.Value

Adding custom MIME types

About this task
Perform the following steps to add ClaimCenter 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 web.xml configuration file in a series of <mime-
mapping> tags. Verify that the needed MIME type exists in the appropriate file. If necessary, add it.

Configuration parameter behaviors 43

 Configuration Guide 9.0.5

2. Add the new MIME type to the ClaimCenter config.xml 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. ClaimCenter uses this
information to associate MIME types and file extensions. If retrieving a file extension from a MIME type,
ClaimCenter uses the first extension in the list. If retrieving a MIME type from a file extension,
ClaimCenter 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/cc/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 config.xml <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.

Approval parameters
Guidewire provides the following configuration parameters in the config.xml file related to approval activities.
For information on editing config.xml and setting configuration parameters, see “Working with configuration
parameters” on page 41.

BulkInvoiceApprovalPattern
Name of the activity pattern to use if creating bulk invoice approval activities.
Required: Yes

PaymentApprovalPattern
Name of an approval activity pattern to use if creating payment approval activities.
Required: Yes

RecoveryApprovalPattern
Name of the activity pattern to use if creating recovery approval activities.
Required: Yes

RecoveryReserveApprovalPattern
Name of the activity pattern to use if creating recovery reserve approval activities.
Required: Yes

ReserveApprovalPattern
Name of the approval activity pattern to use if creating reserve approval activities.
Required: Yes

Archive parameters
Guidewire provides the following configuration parameters in the config.xml file that relate to archiving.

44 chapter 2 Application configuration parameters

 Configuration Guide 9.0.5

IMPORTANT Guidewire strongly recommends that you contact Customer Support before you implement archiving.

See also
• “Working with configuration parameters” on page 41
• “Claim archiving” on page 705
• Application 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 ClaimCenter 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, ClaimCenter creates a non-unique index on the ArchivePartition column for Extractable
entities.
Furthermore, if the Extractable entity is Keyable, ClaimCenter creates a unique index on the ID and
ArchivePartition columns.
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

AssignClaimToRetriever
Specifies to whom ClaimCenter assigns a retrieved claim:
• true assigns the claim to the user who retrieved the claim.
• false assigns a retrieved claim to the original group and user who owned it.
If it is not possible to reassign the claim to the original user, ClaimCenter assigns the retrieved claim to the
supervisor of the group. If ClaimCenter cannot reassign the retrieved claim to the original group, ClaimCenter
assigns the claim to defaultowner.
Default: false

DaysClosedBeforeArchive
ClaimCenter bases archive eligibility on the entity.DateEligibleForArchive field. For an archivable entity to be
eligible for archiving, its DateEligibleForArchive property must be a non-null date and time that is not later than
the current system date and time. In general, ClaimCenter calculates the DateEligibleForArchive value using the
following formula:
DateEligibleForArchive = DaysClosedBeforeArchive (in days) + current system date
Default: 30

DaysRetrievedBeforeArchive

Archive parameters 45
 Configuration Guide 9.0.5

Used by the implementation of the IArchiveSource plugin in the base configuration to set the
DateEligibleForArchive field on Claim as it retrieves a claim from the archive store. ClaimCenter calculates the
DateEligibleForArchive value using the following formula:
DateEligibleForArchive = DaysRetrievedBeforeArchive (in days) + current system date
Default: 100

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

PolicySystemArchivingEnabled
It is possible to include archived policies in the ClaimCenter Policy Select search and the FNOL wizard Find Policy
search. However, the policy system must retrieve any archived policies before ClaimCenter can use them.
Configuration parameter PolicySystemArchivingEnabled controls whether you can include archived policies in
searches.
This configuration parameter has the following valid settings:

PolicySystemArchivingEnabled Meaning
true The policy search result from both FNOL and policy select excludes archived policies.
false If you also check Include Archived Policies in FNOL policy search or in the policy select screen,
ClaimCenter includes archived policies in the search result. ClaimCenter also does the
following:
• Sets the Address, City, State, and postal code fields to blank for archived policies
• Displays a Status column

Default: false

RestorePattern
Code of the activity pattern that ClaimCenter uses to create retrieval activities. Upon retrieving a claim, ClaimCenter
creates two activities:
• One activity for the retriever of the claim
• One activity for the assigned user of the claim, if different from the retriever
Default: restore

SnapshotEncryptionUpgradeChunkSize
Limits the number of claim snapshots that ClaimCenter upgrades during a change to the encryption plugin or during
a change to encrypted fields. Set this parameter to 0 to disable the limit.
Default: 50000

Assignment parameters
Guidewire provides the following configuration parameters in the config.xml file that relate to assignment.

46 chapter 2 Application configuration parameters

 Configuration Guide 9.0.5

For information on editing config.xml and setting configuration parameters, see “Working with configuration
parameters” on page 41.

AssignmentQueuesEnabled
Whether to display the ClaimCenter 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

WeightedAssignmentEnabled
Whether to enable assignment load balancing.
Default: false

WeightedAssignmentGlobalDefaultWeight
The global default weight of all assignable entities that do not match any classifications.
Default: 10
Minimum: 0

Batch process parameters

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

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

Business calendar parameters

Guidewire provides the following configuration parameters in the config.xml file that relate to defining a business
calendar.
For information on editing config.xml 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

Assignment parameters 47
 Configuration Guide 9.0.5

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 ClaimCenter to manage the
official designation of holidays. Guidewire retains this configuration parameter to facilitate upgrade from older
versions of ClaimCenter.

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.
48 chapter 2 Application configuration parameters
 Configuration Guide 9.0.5

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

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 config.xml file that relate to the business rules.
Business rules, which you manage through the ClaimCenterAdministration tab, are distinct from Gosu rules, which
you manage through Guidewire Studio.
For information on editing config.xml and setting configuration parameters, see “Working with configuration
parameters” on page 41.
See also
•
• Application Guide

BizRulesCacheStaleTimeMinutes
Time (in minutes) that ClaimCenter retains rule data in the RuleVersion cache before it considers cached items to
be stale and thus eligible for reaping.
ClaimCenter 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

Business calendar parameters 49

 Configuration Guide 9.0.5

BizRulesEnabled
Determines whether ClaimCenter enables the use of activity business rules. If set to true, ClaimCenter displays the
Business Rules screens in the Administration tab to users with the appropriate privileges.
Default: true

BizRulesDeploymentEnabled
Determines whether it is necessary to explicitly deploy a business rule before ClaimCenter 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, ClaimCenter evaluates all enabled and valid rules at runtime, including rules in the draft state.
ClaimCenter ignores this parameter if the value of parameter BizRulesEnabled is false.
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 a startup error and refuses to start.
ClaimCenter ignores this configuration parameter if the value of BizRulesDeploymentEnabled is false.
ClaimCenter 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.
It is possible to change the value of this parameter through a server restart. However, if you change the value of
BizRulesDeploymentId, ClaimCenter does not update already deployed rule versions.
Default: None
See also
• System Administration Guide

BizRulesImportBootstrapRules
Whether ClaimCenter 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.

50 chapter 2 Application configuration parameters

 Configuration Guide 9.0.5

A.B.c

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

office.ConferenceRooms[0].Table.PhoneNumber

Default: 3

OnlineJavadocPrefix
Prefix to a URL for Javadoc. Override the default URL to point a different Javadoc location, for example, to a local
Javadoc instance.

IMPORTANT Do not use file protocol to define this value due to JavaScript security issues.

Default: https://docs.oracle.com/javase/8/docs/api/

Cache parameters
Guidewire provides the following configuration parameters in the config.xml file that relate to the application
cache.
For information on editing config.xml and setting configuration parameters, see “Working with configuration
parameters” on page 41.
See also
• System Administration Guide

ActivityPatternCacheMaxDuration
Upper bound on how long caches of activity pattern entities are allowed to exist without refresh, measured in
seconds.
Default: 86400

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 ClaimCenter 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 ClaimCenter 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

Business rules parameters 51

 Configuration Guide 9.0.5

GlobalCacheDetailedStats
Configuration parameter GlobalCacheDetailedStats determines whether to collect detailed statistics for the global
cache. Detailed statistics are data that ClaimCenter collects to explain why items are evicted from the cache.
ClaimCenter 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 ClaimCenter Management Beans page to enable the collection of detailed statistics for the global
cache. If you disable the GlobalCacheDetailedStats parameter, ClaimCenter 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 ClaimCenter considers cached items to be eligible for reaping. You can
think of this as the period during which ClaimCenter 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 ClaimCenter 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

52 chapter 2 Application configuration parameters

 Configuration Guide 9.0.5

GlobalCacheStatsRetentionPeriodDays
Time period (in days), in addition to today, for how long ClaimCenter 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). ClaimCenter uses this parameter for the following purposes:
• To define the period of time to preserve the reason for which ClaimCenter evicts an item from the cache, after the
event occurred. If a cache miss occurs, ClaimCenter 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 ClaimCenter 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

Claim catastrophe parameters

Before you can use the Catastrophe Search page and its catastrophe heat map, you must enable the functionality. For
details, see the System Administration Guide.
Guidewire provides the following configuration parameters in the config.xml file that relate to catastrophe map.
Cache parameters 53
 Configuration Guide 9.0.5

For information on editing config.xml and setting configuration parameters, see “Working with configuration
parameters” on page 41.

HeatMapCredential
Set this configuration parameter to the value you obtained during the licensing process for the Bing Maps Ajax
Control.
Default: None

HeatMapServiceTemplate
Set to the fully qualified path to the class that manages the Bing map configuration.
Default: gw.api.heatmap.BingMap

MaxCatastropheClaimFinderSearchResults
Maximum number of claims that ClaimCenter relates to a single catastrophe in the CatClaimFinder batch process,
(used to find catastrophe-related claims). See the System Administration Guide for a discussion of ClaimCenter
batch processes.
Default: 1000

Claim health indicator and metric parameters

Guidewire provides the following configuration parameters in the config.xml file that relate to the claim metrics.
For information on editing config.xml and setting configuration parameters, see “Working with configuration
parameters” on page 41.

ClaimHealthCalcMaxLossDateInYears
Maximum number of years to look back to find claims on which to calculate metrics and indicators. This parameter
strictly limits the number of claims found for the ClaimHealthCalcuation batch process.
Default: 2

InitialReserveAllowedPeriod
Number of days that new initial reserves contribute to the initial reserve sum of the Percent * Reserve Change
Claim Metric calculation after ClaimCenter creates the first initial reserve. An initial reserve is a reserve that
ClaimCenter creates during creation of a claim or exposure. It is also the first set of reserves that ClaimCenter
creates on the claim or exposure if there are no previous reserves for those entities.
Default: 3

MaxClaimResultsPerClaimHealthCalcBatch
Maximum number of claims for each invocation of the ClaimHealthCalculation batch process to calculate metrics
and indicators. This parameter strictly limits the number of claims that can be processed at a single time. The
ClaimHealthCalculation batch process calculates the claim metrics and indicators for found claims.
Default: 1000

Clustering parameters
Guidewire provides the following configuration parameters in the config.xml file that relate to the application
clusters.

54 chapter 2 Application configuration parameters

 Configuration Guide 9.0.5

To improve performance and reliability, you can install multiple ClaimCenter servers in a configuration known as a
cluster. A cluster distributes client connections among multiple ClaimCenter servers, reducing the load on any one
server. If one server fails, the other servers transparently handle its traffic.
For information on editing config.xml 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 config.xml 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 64 to false provides the same Studio
read-only behavior.
Default: false
Set for Environment: Yes
See also
• “ResourcesMutable” on page 64

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

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 this 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

Clustering parameters 55
 Configuration Guide 9.0.5

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 ClaimCenter 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, ClaimCenter 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, ClaimCenter 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:
• serialization-whitelist.lst
• serialization-blacklist.lst
The Server Tools Serialization Info screen (under Info Pages) provides a means of monitoring the deserialization of Java
classes.
Default: false
See also
• System Administration Guide

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

DisableHashJoinForClaimSearch
Guidewire provides a workaround for query plan problems related to hash joins that occur if executing certain claim
searches on Oracle. This parameter controls part of the workaround. The parameter has no effect on databases other
than Oracle. See also DisableSortMergeJoinForTeamGroupActivities.
Default: true

DisableHashJoinForTeamGroupActivities
ClaimCenter works around hash join-related query plan problems while executing the team group activities page's
main query on Oracle. This parameter controls part of the work around and is true by default. This parameter has
no effect on databases other than Oracle.
Default: true

56 chapter 2 Application configuration parameters

 Configuration Guide 9.0.5

DisableIndexFastFullScanForClaimSearch
ClaimCenter works around some bad execution plans by disabling index fast full scan while executing certain claim
searches on Oracle. This parameter controls the work around and is true by default. If a future version of Oracle
fixes the defect, you can safely remove this parameter. The parameter affects the Oracle database only.
Default: true

DisableIndexFastFullScanForRecoverySearch
ClaimCenter works around some bad execution plans by disabling index fast full scan while executing certain
recovery searches on Oracle. This parameter controls the work around and is true by default. If a future version of
Oracle fixes the defect, you can safely remove this parameter. The parameter affects the Oracle database only.
Default: true

DisableIndexFastFullScanForTeamGroupActivities
ClaimCenter works around index fast full scan related query plan problems while executing the Team Group Activities
page's main query on Oracle. This parameter controls the work around and is true by default. If a future version of
Oracle fixes the defect, you can safely remove this parameter. The parameter has no effect on databases other than
Oracle.
Default: true

DisableSequenceUtil
Disables the sequence utility class gw.api.system.database.SequenceUtil. Use this to ensure that any sequences
in your code use some alternative mechanism for sequenced identifiers.
Default: false

DisableSortMergeJoinForClaimSearch
Guidewire provides a work-around for sort-merge join query plan problems that occur if executing certain claim
searches on Oracle. This parameter controls part of the work-around if DisableHashJoinForClaimSearch is also
set to true. The parameter has no effect on databases other than Oracle.
Default: true

DisableSortMergeJoinForTeamGroupActivities
ClaimCenter works around sort merge join query plan problems while executing the team group activities page's main
query on Oracle. This parameter controls part of the workaround if the value of DisableHashJoinForClaimSearch
is set to true. It is true by default. The 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:

Database parameters 57
 Configuration Guide 9.0.5

/* applicationName:ProfilerEntryPoint */

The applicationName component of the comment is ClaimCenter.

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: 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 ClaimCenter.

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

QueryRewriteForClaimSearch
Determines whether ClaimCenter rewrites queries using a materialized view or lets the Oracle optimizer make the
choice based on the cost calculation. The following list describes the valid values for this parameter.

Value Meaning
FORCE/STALE Oracle attempts to rewrite the query using an appropriate materialized view even if the optimizer cost
estimate is high. Oracle allows the rewrite even if the data in the materialized is not the same as in the base
tables.
FORCE/NOSTALE Oracle attempts to rewrite the query using an appropriate materialized view even if the optimizer cost
estimate is high. Oracle ignores the materialized view if the data in the view is not fresh.
COST/STALE If the Oracle cost-based optimizer evaluates the rewrite to be cheaper than other plans, it uses the
materialized view. If it is costlier to execute the rewritten path, then Oracle performs a join of the base
tables. The rewrite can happen even if the data in the view is stale.
COST/NOSTALE If the Oracle cost-based optimizer evaluates the rewrite to be cheaper than other plans, it uses the
materialized view. If it is costlier to execute the rewritten path, then Oracle performs a join of the base
tables. If the data in the view is not fresh, Oracle ignores the view and performs the join on the base tables.

58 chapter 2 Application configuration parameters

 Configuration Guide 9.0.5

Note: If you provide an invalid value, the server ignores it.

Default: None
See also
• Installation Guide
• System Administration Guide

SetSemiJoinNestedLoopsForClaimSearch
(Oracle only) ClaimCenter works around semi-join query plan problems by forcing nested loop semi-join queries
while executing certain claim searches on Oracle. This parameter controls part of the work-around, and has no effect
on databases other than Oracle.
Default: true

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

Data destruction parameters

Guidewire provides configuration parameters in the config.xml file that relate to destruction of data. In the base
configuration of GenericCenter, data destruction is not enabled. You must set configuration parameters to enable
data destruction.
See also
• “Data destruction configuration parameters” on page 712
• “Working with configuration parameters” on page 41.

ArchiveReferenceTrackingEnabled Parameter
When archiving is enabled, you must set this parameter to true to enable tracking of archived objects for personal
data destruction. This parameter must also be set to true before you run the ArchiveReferenceTrackingSync
batch process to build the table of objects that you have already archived.
In the base configuration, this parameter is false.

ContactDestructionRequestAgeForPurgingResults parameter
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
• “RemoveOldContactDestructionRequest work queue” on page 717

PersonalDataDestructionEnabled parameter
Set this parameter to true to enable destruction of personal data. In the base configuration, this parameter is false.

Deduction parameters
Guidewire provides the following configuration parameters in the config.xml file that relate to deductions.

Database parameters 59
 Configuration Guide 9.0.5

For information on editing config.xml and setting configuration parameters, see “Working with configuration
parameters” on page 41.

BackupWithholdingTypeCode
The typecode in the DeductionType typelist for backup withholding. The default is irs. You must define this
parameter for the backup withholding plugin to work. Also, this parameter must also correspond to a valid
DeductionType typecode.
Default: irs

CalculateBackupWithholdingDeduction
Whether ClaimCenter calculates backup withholding for applicable checks.
Default: true

StandardWithholdingRate
Standard backup withholding rate, as defined by the U.S. Internal Revenue Service, for use by the backup
withholding plugin. The number is a percentage. (For example, 28.0 means 28.0 percent.) The backup withholding
plugin does not work if you do not define this parameter.
Default: 28.0

Document creation and document management parameters

Guidewire provides configuration parameters in the config.xml file that relate to document creation and
management.
See also
• “Working with configuration parameters” on page 41
• Application Guide
• Guidewire Contact Management 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 ClaimCenter returns document content directly to the
browser. Supported settings are inline and attachment.
Default: inline

DocumentTemplateDescriptorXSDLocation
The path to the XSD file that ClaimCenter uses to validate document template descriptor XML files. Specify this
location relative to the following directory:

modules/configuration/config/resources/doctemplates

60 chapter 2 Application configuration parameters

 Configuration Guide 9.0.5

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: 25 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: 25 MB

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

AddressDeletionDelay
Sets the amount of time to wait (in minutes) before an AddressDeleteWorkQueue work item deletes an address
marked as potentially orphaned. During an entity bundle commit, it is possible for an address to become orphaned if
there is no longer an entity that points to the address.
ClaimCenter manages the AddressDeleteWorkQueue work queue internally. It is not possible to either schedule this
work queue or to run it from the ClaimCenter user interface.
Default: 1
See also
• System Administration Guide

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

Document creation and document management parameters 61

 Configuration Guide 9.0.5

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, ClaimCenter 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 ClaimCenter 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 135.
• Integration Guide

DeprecatedEventGeneration
Whether to use the now-deprecated event logic that had previously been available.
Default: false

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, ClaimCenter
shows a warning message if verification against zone data fails.
• If EnableAddressVerification is true and AddressVerificationFailureAsError is true, ClaimCenter
shows an error message if verification against zone data fails.
• If EnableAddressVerification is false, ClaimCenter does not verify the address based on zone data.
Default: false

62 chapter 2 Application configuration parameters

 Configuration Guide 9.0.5

See also
• “AddressVerificationFailureAsError” on page 61

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

EntityValidationOrder
Order in which to execute validation if validating multiple entities. ClaimCenter validates all other validatable
entities not specified in this list after all listed entities, in no particular order.
Note: Guidewire does not guarantee that ClaimCenter validates entities of a given type (such as the exposures on a
claim) in any deterministic order with respect to one another.
Default: Policy, Claim, Exposure, Matter, TransactionSet

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 ClaimCenter object such as a Claim, ClaimCenter assigns it a key, or unique public identifier.
To ensure that keys are unique, the server requests an available key from the ClaimCenter 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 ClaimCenter 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 config.xml.
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.
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

Environment parameters 63
 Configuration Guide 9.0.5

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 64.

Studio Read-only Mode

If you set the value of ResourcesMutable to false in config.xml 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 55

RetainDebugInfo
Whether the production server retains debugging information. This parameter facilitates debugging from Studio
without a type system refresh.
• If set to true, ClaimCenter 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

64 chapter 2 Application configuration parameters

 Configuration Guide 9.0.5

See also
• “ResourcesMutable” on page 64

StrictDataTypes
Controls whether ClaimCenter uses the pre-ClaimCenter 6.0 behavior for configuring data types, through the use of
the fieldvalidators.xml 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 useful for new ClaimCenter installations that want
to implement the new behavior.

StrictDataTypes = true
If you set the StrictDataTypes value to true, then ClaimCenter:
• Does not permit decimal values to exceed the scale required by the data type. The setter throws a
gw.datatype.DataTypeException 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 ClaimCenter user interface and in the field setter.
• Validates numeric range constraints in both the ClaimCenter user interface and in the field setter.

StrictDataTypes = false
If you set the StrictDataTypes value to false, then ClaimCenter:
• 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, ClaimCenter 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, ClaimCenter uses the su user as the user with unrestricted permissions to do anything in ClaimCenter.
To set the unrestricted user to a different user, set the value of the UnrestrictedUserName parameter to that user’s
login name.
Default: su

Environment parameters 65
 Configuration Guide 9.0.5

UseOldStylePreUpdate
Determines whether to apply the pre-update rule set prior to committing a bundle.
Default: true

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 config.xml file to help configure how ClaimCenter works with
monetary amounts.
For information on editing config.xml and setting configuration parameters, see “Working with configuration
parameters” on page 41.
See also
• “Configuring ClaimCenter financials” on page 735
• “ClaimCenter financial calculations” on page 743
• “Configuring multicurrency” on page 697
• Application Guide
• Globalization Guide

AllowMultipleLineItems
Whether to allow multiple line items in a transaction. See also UseDeductibleHandling.
Default: true

AllowMultiplePayments
Whether to allow a single check to reflect multiple payments.
Default: true

AllowNegativeManualChecks
Use to set the ability to create negative checks manually. The following values are valid:
• true – Allow user to create negative checks manually.
• false – Disable the ability to create negative checks manually.
The default ClaimCenter behavior is to not allow manual checks to be negative. If you need the ability to create
negative checks manually, then you must explicitly set this parameter to true.
Default: false

66 chapter 2 Application configuration parameters

 Configuration Guide 9.0.5

AllowNoPriorPaymentSupplement
Whether to allow a user to create supplemental payments on a closed claim or exposure with no prior payments.
Default: false

AllowPaymentsExceedReservesLimits
If true, a user can submit payments that exceed available reserves up to the amount limited by the
paymentsexceedreserves authority limits. Otherwise, ClaimCenter does not allow partial or final payments that
exceed reserves.
Default: false

CheckAuthorityLimits
Controls whether ClaimCenter checks authority during approval processing of a TransactionSet.
Default: true

CloseClaimAfterFinalPayment
If true, ClaimCenter attempts to automatically close a claim if a final payment closes the last open exposure.
Default: true

CloseExposureAfterFinalPayment
If true, ClaimCenter attempts to automatically close the exposure of a Final payment when that payment's Check is
escalated.
Default: true

EnableMulticurrencyReserving
Whether to enable multicurrency reserving support. Note that this parameter is not intended to be used by non-Gosu
classes, or to be accessed directly; use CCConfigUtil.EnableMulticurrencyReserving instead.
You must set this parameter to true if you set MulticurrencyDisplayMode to MULTIPLE.

IMPORTANT The EnableMultiCurrencyReserving parameter setting is semi-permanent. After you set

EnableMultiCurrencyReserving to true and then start the server, you cannot change the value again.

Default: false
Set for Environment: Yes

Financials
Specifies the level of financials functionality that is available in the application. Available options are view for read-
only values or entry to enable editing the financial values directly in ClaimCenter.
ClaimCenter supports the following values:

Value Description
entry financials entry
view financials view (read-only)

Default: entry

Financial parameters 67
 Configuration Guide 9.0.5

PaymentLogThreshold
ClaimCenter logs payments greater than this threshold. This integer value must be 0 or greater.
Default: 500
Dynamic: Yes

PaymentRoundingMode
Use to set the rounding mode for conversion of amounts among TransactionAmount, ClaimAmount, and
ReportingAmount columns on the TransactionLineItem entity for Payment transactions. The available choices are
a subset of those supported by java.math.RoundingMode, 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:

gw.api.util.CCCurrencyUtil.getRoundingMode(Payment)

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
See also
• Globalization Guide

ReserveRoundingMode
Use to set the rounding mode for conversion of amounts among TransactionAmount, ClaimAmount, and
ReportingAmount columns on the TransactionLineItem entity for Reserve transactions.
The available choices are a subset of those supported by java.math.RoundingMode, namely:
• UP
• DOWN
• CEILING
• FLOOR
• HALF_UP
• HALF_DOWN
• HALF_EVEN

68 chapter 2 Application configuration parameters

 Configuration Guide 9.0.5

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:

gw.api.util.CCCurrencyUtil.getRoundingMode(Reserve)

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
See also
• Globalization Guide

SetReservesByTotalIncurred
Specifies the way in which you modify reserves in the ClaimCenter interface.
• If set to true, the user can set the Total Incurred values
• If set to false, the user can set the Available Reserves values.
Default: false

UseDeductibleHandling
Whether to use deductible handling. If this value is true, then AllowMultipleLineItems must be true as well.
Default: true
See also
• Application Guide

UseRecoveryReserves
Whether to use recovery reserve transactions in financial calculations. If you set this parameter to false, and then
later set it back to true, consider creating offsetting recovery reserves for your existing recoveries. In addition,
changing the parameter from false to true generates database consistency check errors, which you may ignore.
Default: true

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

UseGeocodingInPrimaryApp
If true, ClaimCenter enables proximity search for users in the assignment user interface. ContactManager does not
respond to this parameter.
Default: false

Financial parameters 69
 Configuration Guide 9.0.5

UseGeocodingInAddressBook
Set to true if you have ClaimCenter integrated with ContactManager and ContactManager has geocoding enabled
for vendors. This setting enables vendor search in the ClaimCenter and ContactManager user interfaces.
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

IMPORTANT If the setting for this configuration parameter differs between ContactManager and ClaimCenter, it is
possible for the application to display distance-related messages incorrectly. Additionally, the search can return
results that are farther away than the distance specified.

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. This parameter does not have to match
the value of the corresponding parameter in the ContactManager config.xml file.
Default: 1000

UseMetricDistancesByDefault
If true, ClaimCenter uses kilometers and metric distances instead of miles and United States distances for driving
distance or directions. Set this parameter identically in both ClaimCenter and ContactManager.
Default: false

Globalization parameters
Guidewire provides the following configuration parameters in the config.xml file that relate to globalization.
For information on editing config.xml 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

70 chapter 2 Application configuration parameters

 Configuration Guide 9.0.5

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 ClaimCenter with a single currency. Guidewire
applications which share currency values must have the same DefaultApplicationCurrency setting in their
respective config.xml files. The default currency is sometimes known as the reporting currency.

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 money and currency amount calculations.
The available choices are a subset of those supported by java.math.RoundingMode, 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:

gw.api.util.CurrencyUtil.getRoundingMode()

Globalization parameters 71
 Configuration Guide 9.0.5

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
See also
• “PaymentRoundingMode” on page 68
• “ReserveRoundingMode” on page 68
• Globalization Guide

MulticurrencyDisplayMode
Determines whether ClaimCenter displays currency selectors for monetary values. The following are the allowed
values for MulticurrencyDisplayMode:
• SINGLE
• MULTIPLE
In the base configuration of ClaimCenter, 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

DefaultCountryCode
The default ISO country code that ClaimCenter uses if the country for an address is not set explicitly. ClaimCenter
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:

https://www.iso.org/obp/ui

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 nanpa.properties 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

72 chapter 2 Application configuration parameters

 Configuration Guide 9.0.5

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

ContactAutoSyncBundleCommitSize
If you integrate ClaimCenter with ContactManager, it is necessary to synchronize contacts stored by the two
Guidewire applications. Batch process ContactAutoSync controls this synchronization.
It is common to have a large number of local instances of each contact in Guidewire ClaimCenter, one for each
claim that uses that contact. To improve the performance of synchronizing the ClaimCenter contacts that match a
single AddressBookUID, the parameter ContactAutoSyncBundleCommitSize specifies the maximum number of
contacts in a single bundle commit.
Note: Parameter ContactAutoSyncBundleCommitSize is meaningful only if ClaimCenter is integrated with
ContactManager.
Default: 15
See also
• “ContactAutoSyncWorkItemChunkSize” on page 73
• Guidewire Contact Management Guide

ContactAutoSyncWorkItemChunkSize
If you integrate ClaimCenter with ContactManager, it is necessary to synchronize the contacts stored by the two
Guidewire applications. Batch process ContactAutoSync controls this synchronization.
It is common to have a large number of local instances of each contact in Guidewire ClaimCenter, one for each
claim that uses that contact. During contact synchronization between ClaimCenter and ContactManager,
ClaimCenter processes the table for highly linked contacts. If the number of contacts linked to a single
AddressBookUID is greater than the value of ContactAutoSyncWorkItemChunkSize, ClaimCenter divides these
contacts into smaller groups of contacts. This process is known as chunking. ClaimCenter then creates a work item
to process each chunk of contacts.
Note: Parameter ContactAutoSyncWorkItemChunkSize is meaningful only if ClaimCenter is integrated with
ContactManager.
Default: 400
See also
• “ContactAutoSyncBundleCommitSize” on page 73
• Guidewire Contact Management Guide

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

EnableMetroIntegration
Whether to enable Metropolitan Reporting Bureau integration. If true, there is a working integration that sends
messages from ClaimCenter to the Metropolitan Reporting Bureau service (requesting Metropolitan reports).
Default: false

Integration parameters 73
 Configuration Guide 9.0.5

Set for Environment: Yes

InstantaneousContactAutoSync
Whether to process contact automatic synchronization in ClaimCenter at the time of receiving the notification:
• If you set InstantaneousContactAutoSync to false, ClaimCenter synchronizes contacts only while running
the ContactAutoSync batch process.
• If you set InstantaneousContactAutoSync to true, the ContactAutoSync worker activates automatically as
ClaimCenter receives autosync events and immediately updates all ClaimCenter copies of a contact stored in
ContactManager.
Default: true
See also
• Guidewire Contact Management Guide

ISOPropertiesFileName
Name of the ISO properties file in the ClaimCenter/modules/configuration/config/iso configuration
directory.
Default: ISO.properties
Set for Environment: Yes

KeepCompletedMessagesForDays
Number of days after which ClaimCenter 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.
Default: true
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.

MetroPropertiesFileName
Name of the Metropolitan properties file in the ClaimCenter/modules/configuration/config/metro
configuration directory. ClaimCenter uses this files to set up fields in the XML messages sent to the Metropolitan
Reporting Bureau. See EnableMetroIntegration as well.
Default: Metro.properties
Set for Environment: Yes

74 chapter 2 Application configuration parameters

 Configuration Guide 9.0.5

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

PolicySystemURL
URL to use in ClaimCenter ExitPoint PCF pages that view items in the policy system.
• If integrating Guidewire ClaimCenter with Guidewire PolicyCenter, then set this parameter to the PolicyCenter
base URL (for example, http://server/pc). In this case, the exit points add the appropriate PolicyCenter entry
point.
• If integrating with a non-Guidewire policy 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 ClaimCenter hides the buttons in the interface
that take you to the exit points.
Default: Empty string
See also
• Integration Guide

Miscellaneous bulk invoice activity pattern parameters

Guidewire provides the following configuration parameters in the config.xml file that relate to bulk invoicing.
For information on editing config.xml and setting configuration parameters, see “Working with configuration
parameters” on page 41.

BulkInvoiceItemValidationFailedPattern
Name of the activity pattern to use in creating an activity to alert about a failure during processing of a bulk invoice
item.
Required: Yes

BulkInvoiceUnableToStopPattern
Name of the activity pattern to use if creating an activity to alert that ClaimCenter was unable to stop a bulk invoice.
More technically, it was not possible to update the status from Pending-stop or Stopped to Issued or Cleared.
Required: Yes

BulkInvoiceUnableToVoidPattern
Name of the activity pattern to use in creating an activity to alert that ClaimCenter was unable to void a bulk
invoice. More technically, it was not possible to update the status from Pending-void or Voided to Issued or
Cleared.
Required: Yes

Miscellaneous financial activity parameters

Guidewire provides the following configuration parameters in the config.xml file that relate to financial activity
patterns.

Integration parameters 75
 Configuration Guide 9.0.5

For information on editing config.xml and setting configuration parameters, see “Working with configuration
parameters” on page 41.

CheckDeniedPattern
Name of the activity pattern to use if creating an alert that a down-stream system has denied a check.
Required: Yes

CheckUnableToStopPattern
Name of the activity pattern to use if creating an alert that ClaimCenter cannot stop a check.
Required: Yes

CheckUnableToVoidPattern
Name of the activity pattern to use if creating an alert that ClaimCenter cannot void a check.
Required: Yes

ClaimOrExposureUnableToClosePattern
Name of the activity pattern to use if a claim or an exposure cannot be closed.
Required: Yes

LastPaymentReminderPattern
Name of the activity pattern to use if creating an alert to signal the approach of the last payment in a set of
recurrence checks.
Required: Yes

RecoveryDeniedPattern
Name of the activity pattern to use if creating an alert that a down-stream system has denied a recovery.
Required: Yes

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

ClaimLossDateDemarcation
Default time for a claim’s loss date when it is not specified in the FNOL. Set this to match the default time at which
the policy administration system sets the effective date of the policy.
Default: 12:00 AM
Set for Environment: Yes

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

76 chapter 2 Application configuration parameters

 Configuration Guide 9.0.5

EnableClaimNumberGeneration
Whether to enable automatic claim number generation (through an external plugin). If you enable claim number
generation, then you must also provide an external Claim Number Generator plugin. If enabled, claim number
generation must succeed in order for a claim to be added through either the New Claim wizard or the integration
tools. This does not affect claims added through staging tables.
Default: true

EnableClaimSnapshot
Whether to create snapshots for imported and created claims. The claim snapshot contains a version of the claim
data before any automated processing by ClaimCenter.
Default: true

EnableStatCoding
Whether to enable statistical coding support.
Default: true

MaintainPolicyValidationLevelOnPolicyChange
If true, any time that you change or refresh the policy for a claim, ClaimCenter validates the new policy at the level
of the old policy. If false, ClaimCenter validates the new policy at the newloss level. In either case, a validation
failure causes ClaimCenter to revert the policy refresh or change.
Default: true

MaxCachedClaimSnapshots
Limits the number of claim snapshots that ClaimCenter caches in memory. This integer value must be 0 or greater,
but less than ten (10).
Default: 3
Minimum: 0
Maximum: 10

MaxStatCodesInDropdown
Maximum number of statistics codes to show in the statistics code picker drop-down.
Default: 20

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

VendorNotificationAPIRetryTime
Amount of time (in seconds) to wait before attempting to retry a Vendor Notification Message that failed validation.
Default: 10
Set For Environment: Yes

TransactionIdPurgeDaysOld
Number of days to keep external transaction ID records before they can be deleted.
Miscellaneous parameters 77
 Configuration Guide 9.0.5

Default: 30

PDF print settings parameters

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

DefaultContentDispositionMode
The Content-Disposition header setting to use when ClaimCenter 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.
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:

http://xmlgraphics.apache.org/fop/

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\fop.xconf

For more information, refer to the following:

http://xmlgraphics.apache.org/fop/

Default: None

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

PrintLineHeight
Total size of a line of print text.

78 chapter 2 Application configuration parameters

 Configuration Guide 9.0.5

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.
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, ClaimCenter 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-negative A non-negative value limits the size of the XML input file to the set value (in megabytes). If a user attempts to
print a PDF file that is larger in size than this value, ClaimCenter generates an error.

Default: -1

PrintPageHeight
Total print height of page.
Default: 8.5in

PDF print settings parameters 79

 Configuration Guide 9.0.5

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

Print settings parameters

Guidewire provides the following configuration parameters in the config.xml file that relate to printing from
ClaimCenter.
For information on editing config.xml 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

Scheduler and workflow parameters

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

IdleClaimThresholdDays
ClaimCenter schedules claims that have not been touched (including edits or exception checks) for this many days
for exception detection. This integer value must be 0 or greater.
Default: 7
Dynamic: Yes

80 chapter 2 Application configuration parameters

 Configuration Guide 9.0.5

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

SeparateIdleClaimExceptionMonitor
If true, run exception monitoring rules for idle cases at a separate time.
Default: true

WorkflowLogDebug
Configuration parameter WorkflowLogDebug takes a Boolean value:
• If set to true, ClaimCenter outputs the ordinary verbose system workflow log messages from the Guidewire
server to the workflow log.
• If set to false, ClaimCenter 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 config.xml file that relate to searching.
For information on editing config.xml and setting configuration parameters, see “Working with configuration
parameters” on page 41.

Scheduler and workflow parameters 81

 Configuration Guide 9.0.5

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→Claims→Search by Contact screen, which uses free-text search.
Default: false
See also
• “Free-text search configuration parameters and files” on page 414

MaxActivitySearchResults
Maximum number of activities that ClaimCenter returns in a search. If the number to return is greater than this
value, ClaimCenter prompts the user to narrow the search parameters. This integer value must be 1 or greater.
Default: 300

MaxBulkInvoiceSearchResults
Maximum number of bulk invoices that ClaimCenter returns in a search. If the number to return is greater than this
value, ClaimCenter prompts the user to narrow the search parameters. This integer value must be 1 or greater.
Default: 300

MaxCheckSearchResults
Maximum number of checks that ClaimCenter returns in a search. If the number to return is greater than this value,
ClaimCenter prompts the user to narrow the search parameters. This integer value must be 1 or greater.
Default: 300

MaxClaimSearchResults
Maximum number of results that ClaimCenter returns for a claim search. This integer value must be 1 or greater. If
the number or results to return is greater than this value, ClaimCenter prompts the user to narrow the search
parameters.
Default: 300

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

MaxContactDocumentSearchResults
The maximum number of contact documents search results retrieved from ContactManager.
Default: 100

MaxDocTemplateSearchResults
Maximum number of document templates that ClaimCenter returns in a search. If the number to return is greater
than this value, then ClaimCenter prompts the user to narrow the search parameters. This integer value must be 1 or
greater.
Default: 50

82 chapter 2 Application configuration parameters

 Configuration Guide 9.0.5

MaxDuplicateContactSearchResults
Maximum number of duplicate results to return from a contact search. This integer value must be 0 or greater.
Default: 25

MaxNoteSearchResults
Maximum number of notes that ClaimCenter returns in a search. If the number to return is greater than this value,
ClaimCenter prompts the user to narrow the search parameters. This integer value must be 0 or greater. A value of 0
indicates that there is no limit on the search.
Default: 25

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

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

Security parameters
Guidewire provides the following configuration parameters in the config.xml file that relate to application security.
For information on editing config.xml 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

FailedAttemptsBeforeLockout
Number of failed attempts that ClaimCenter 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 ClaimCenter locks a user account. A value of -1 indicates that a system administrator must
manually unlock a locked account.
Default: -1

Search parameters 83
 Configuration Guide 9.0.5

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

MaxACLParameters
Maximum number of users and groups to directly include in search queries that check the claim access control list.
Beyond this maximum limit, ClaimCenter stores users and groups in database tables. You must then use an
additional join in the query to check the claim access control list.
Checking the claim access control list can involve a large number of groups and users. For example, if
EnableDownlinePermissions is true, someone who supervises many groups and users has access to control lists
that contain any of their supervisees. Including all these groups and users in the query can be done directly by
including them as parameters to the query. Or, you can store them in database tables and doing extra joins in the
query.
For small numbers of groups and users, direct parameters are the best choice. For large numbers, in the range of
thousands, the extra join can be better. This parameter, MaxACLParameters, determines the point at which the query
code switches from using direct parameters to using extra joins.
The MaxACLParameters can take the following values:
• A value of -1 or less – Instructs ClaimCenter to use the appropriate default for the current database. Thus,
ClaimCenter chooses the best value, as determined by Guidewire performance testing, for the current type of
database.
• A value of 0 – Instructs ClaimCenter to always use parameters, and to never use a join in a query. This works
even for very large numbers of groups and users, 3000 or more, on an Oracle database. However, it is not suitable
for the SQL Server database, which limits the total number of parameters to 2100.
• A value of +1 or greater – Instructs ClaimCenter to use that value as a threshold. If the number of groups and
users is less than the threshold, then a query uses parameters. If the number is larger the threshold, a query uses
database tables and extra joins. Guidewire strongly recommends that you do not use a positive value for the
Oracle database. This is because the Oracle database can cope with large numbers of parameters, but tends to
choose very bad query plans for the extra joins.
In summary, Guidewire recommends that most ClaimCenter installations use the default value of -1, which chooses
the best value for the current database type.

Database Notes
SQL Server For those ClaimCenter installations that use SQL Server as the database, Guidewire recommends the following:
• Do not set this value to 0.
• Do not set it to any value greater than approximately 2000 due to the risk of hitting the 2100 parameter limit.
Oracle For those ClaimCenter installations that use the Oracle database. Guidewire expressly recommends that you do
not use positive values due to the risk of bad query plans.

Default: -1

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

84 chapter 2 Application configuration parameters

 Configuration Guide 9.0.5

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 ClaimCenter does not
require a password. (Guidewire does not recommend this.)
Default: 8
Minimum: 0

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

RestrictSearchesToPermittedItems
Whether ClaimCenter 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 ClaimCenter 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

UseACLPermissions
Whether to use the ACL permission model.
• If false, the privilege that a user holds applies to every claim.
• If true, the ClaimAccess table controls claim access.
Default: true

Segmentation parameters
Guidewire provides the following configuration parameters in the config.xml file that relate to claim and exposure
segmentation.
For information on editing config.xml and setting configuration parameters, see “Working with configuration
parameters” on page 41.

ClaimSegment
Default value to set the Segment field to on a claim, if ClaimCenter cannot determine another segment.
Required: Yes

Security parameters 85
 Configuration Guide 9.0.5

ClaimStrategy
The default value to set the Strategy field to on a claim, if ClaimCenter cannot determine another strategy.
Required: Yes

ExposureSegment
Default value to set the Segment field to on an exposure, if ClaimCenter cannot determine another segment.
Required: Yes

ExposureStrategy
Default value to set the Strategy field on an exposure, if ClaimCenter cannot determine another strategy.
Required: Yes

Service request parameters

Guidewire provides the following configuration parameters in the config.xml file that relate to claim and exposure
segmentation.
For information on editing config.xml and setting configuration parameters, see “Working with configuration
parameters” on page 41.

ServiceRequestAPIMaxDaysKeepActiveWithoutInvoice
Maximum number of days that a service request will be considered active by the ServiceRequestAPI when it is
work complete but has no valid invoices.
Default: 90
Set For Environment: Yes

ServiceRequestAPIMaxMessageResults
Maximum number of service request messages returned through the ServiceRequestAPI web service.
Default: 50
Set For Environment: Yes

ServiceRequestAPIMaxSearchResults
Maximum number of service requests returned by a search performed through the ServiceRequestAPI web service.
Default: 250
Set For Environment: Yes

Statistics, team, and dashboard parameters

Guidewire provides the following configuration parameters in the config.xml file that relate to ClaimCenter
statistics, the Team tab, and the Dashboard.
For information on editing config.xml and setting configuration parameters, see “Working with configuration
parameters” on page 41.

86 chapter 2 Application configuration parameters

 Configuration Guide 9.0.5

AddIndexHintForLossDate
Applies only when running on an Oracle database. When true, improves the performance of a particular database
query that is executed on the Desktop Activities screen. This parameter enables a database hint on the index
Claim.claimu7u. Therefore, if you modify this index, then you may have better performance on the Desktop
Activities screen by setting this parameter to false, thereby disabling the hint.
Default: true

AgingStatsFirstDivision
Number of days to use in calculating the first claim aging bucket. This bucket includes claims between 0 and
AgingStatsFirstDivision days old. This integer value must be 0 or greater.
Default: 30

AgingStatsSecondDivision
Number of days to use in calculating the second claim aging bucket. This bucket includes claims between
AgingStatsFirstDivision + 1 and AgingStatsSecondDivision days old. This integer value must be 0 or
greater.
Default: 60

AgingStatsThirdDivision
Number of days to use in calculating the third claim aging bucket. This bucket includes claims between
AgingStatsSecondDivision + 1 and AgingStatsThirdDivision days old. The last bucket includes all claims
older than AgingStatsThirdDivision days. This integer value must be 0 or greater.
Default: 120

CalculateLitigatedClaimAgingStats
Whether to show the number of litigated claims on the Aging subtab of the Team tab.
Default: true

DashboardIncurredLimit
Total incurred amount above which ClaimCenter counts the claim as over-the-limit in executive dashboard
calculations.
Default: 1000000

DashboardShowByCoverage
Whether the Dashboard shows claim information subtotaled by coverage.
Default: true

DashboardShowByLineOrLoss
Whether the Dashboard shows claim information subtotaled by line of business or loss type.
Default: true

DashboardWindowPeriod
Number of days to use for executive dashboard calculations that depends on a specific time period.
Default: 30

Statistics, team, and dashboard parameters 87

 Configuration Guide 9.0.5

GroupSummaryShowUserGlobalWorkloadStats
Whether to show individual user global workload statistics along with the standard statistics in the Team Summary
page.
Default: true

UserStatisticsWindowSize
Time window for calculating user statistics. Set this value to the number of previous days to include in the
calculation. For example, set it to 10 to calculate statistics for the last 10 days, including today. You can also set this
parameter to one of the following special values:

Value Description
0 This week, defined as the start of the current business week up to and including today.
-1 This month, defined as the start of the current month up to and including today.

Default: 0

User interface parameters

Guidewire provides the following configuration parameters in t he config.xml file that relate to the ClaimCenter
interface.
For information on editing config.xml 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

HidePolicyObjectsWithNoCoveragesForLossTypes
It is possible to add a coverage at either the Policy level, or, directly on the covered item (a vehicle, for example).
This parameter applies to coverages applied at the Policy level, rather than those coverages applied to individual
items covered in the policy. It affects the individual coverage submenus in the ClaimCenter Actions→New
Exposure→Choose by Coverage submenu. To remove (hide) empty Vehicle and Property submenus for a specific loss
type, add that loss type to the list.
It is also possible to create this same application behavior by adding a typekey to a typefilter of the same name as
this configuration parameter on the LossType typelist. If you added to the typefilter to modify the behavior of the
New Exposure menu, you can implement this change during a rolling upgrade of the ClaimCenter cluster application
servers. Conversely, if you implement this behavior by modifying file config.xml, then you need to perform a full
database upgrade to implement your changes.
Default: None

88 chapter 2 Application configuration parameters

 Configuration Guide 9.0.5

HighlyLinkedContactThreshold
Use to improve application performance related to viewing a contact in the ClaimCenter Address Book tab or through
the Claim Summary page. Attempting to view a contact with a large number of links can create performance issues. If
a user is viewing a highly linked contact, then ClaimCenter issues a warning if the user clicks on a card that can
result in an expensive query. The user must click another button before viewing the contact’s related claims,
activities, exposures or matters as these views put a heavy load on the database. This parameter sets the threshold
value for the number of links to a contact that generates the warning.
Note: If you set the threshold value to 0, then ClaimCenter considers no contact to be highly linked.
Default: None

IgnorePolicyTotalPropertiesValue
If true, the policy properties screens suppress the message telling the user whether all of the properties that appear
on the policy have been downloaded to the ClaimCenter policy snapshot.
• Set this value to true if the policy adapter is not capable of returning a meaningful value for
Policy.TotalProperties.
• Set this value to false otherwise.
Default: false

IgnorePolicyTotalVehiclesValue
If true, the policy vehicles screens suppress the message telling the user whether all of the vehicles that appear on
the policy have been downloaded to the ClaimCenter policy snapshot.
• Set this value to true if the policy adapter is not capable of returning a meaningful value for
Policy.TotalVehicles.
• Set this value to false otherwise.
Default: false

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

ListViewPageSizeDefault
The default number of entries that ClaimCenter 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.

MaxChooseByCoverageMenuItems
Maximum number of vehicles or properties that ClaimCenter displays in the New Exposure→Choose by Coverage
menu. If the number to return exceeds this limit, ClaimCenter prompts the user to use the Coverage Type menu
instead. This integer value must be 1 or greater.
Default: 15

User interface parameters 89

 Configuration Guide 9.0.5

MaxChooseByCoverageTypeMenuItems
Maximum number of coverage types that ClaimCenter displays in the New Exposure→Choose by Coverage Type menu.
If the number to return exceeds this limit, ClaimCenter splits the coverage types into alphabetic submenus. This
integer value must be 1 or greater.
Default: 15

MaxClaimantsInClaimListViews
Maximum number of claimants to list for each claim in a list view. This integer value must be 0 or greater. If set to
0, ClaimCenter does not impose a limit.
Default: 0

MaxTeamSummaryChartUserBars
Maximum number of users to show in the chart on the Team Summary page. Set this parameter to 0 to remove the
chart entirely. Otherwise, the chart displays statistics for the top N users, and groups the others into a bar labeled All
Other Users. This integer value must be 0 or greater.
Default: 10

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

RequestReopenExplanationForTypes
The set of re-openable entities for which, if reopened, ClaimCenter displays a screen for the user to enter a reason
and note. Enter as a comma-separated list.
Default: Claim,Exposure,Matter

ShowCurrentPolicyNumberInSelectPolicyDialog
Whether to populate the select policy dialog with the policy number for the current policy for a claim.
Default: false

ShowFixedExposuresInLossDetails
Works with ShowNewExposureMenuForLossTypes.
• If true, claims that do not have the New Exposure menu have a fixed list of exposures that can be shown through
tabs on the Claim Loss page.
• If false, claims that do not have the New Exposure menu have a fixed list of exposures that can be shown through
separate top-level page links in the claim file.
Default: false

ShowNewExposureChooseByCoverageMenuForLossTypes
In the base application configuration, the ClaimCenter Actions→New Exposure menu contains two submenus, one of
which is the Choose By Coverage submenu. Use this parameter to specify for which loss types you can access the
Choose By Coverage submenu. Guidewire recommends that omit WC from the list of loss types.

90 chapter 2 Application configuration parameters

 Configuration Guide 9.0.5

In modifying this parameter:

• Deleting one of the default parameter values removes the Choose by Coverage submenu for that loss type.
• Adding a value to the default parameter values list adds a Choose by Coverage submenu for that loss type. Add
your new loss type typecode to the existing comma-separated list of values.
It is also possible to create this same application behavior by adding a typekey to a typefilter of the same name as
this configuration parameter on the LossType typelist. If you added to the typefilter to modify the behavior of the
New Exposure menu, you can implement this change during a rolling upgrade of the ClaimCenter cluster application
servers. Conversely, if you implement this behavior by modifying file config.xml, then you need to perform a full
database upgrade to implement your changes.

Important
If you add a new value to the list of loss types in this configuration parameter, then you must also add that value to
configuration parameter ShowNewExposureMenuForLossTypes.
This caveat applies also if you modify one of the typefilters on the LossType typelist.
Default: AUTO,PR,GL,TRAV

ShowNewExposureChooseByCoverageTypeMenuForLossTypes
In the base application configuration, the ClaimCenter Actions→New Exposure menu contains two submenus, one of
which is the Choose By Coverage Type submenu. Use this parameter to specify for which loss types you can access the
Choose By Coverage submenu.
In modifying this parameter:
• Deleting one of the default parameter values removes the Choose by Coverage Type submenu for that loss type.
• Adding a value to the default parameter values list adds a Choose by Coverage Type submenu for that loss type. Add
your new loss type typecode to the existing comma-separated list of values.
It is also possible to create this same application behavior by adding a typekey to a typefilter of the same name as
this configuration parameter on the LossType typelist. If you added to the typefilter to modify the behavior of the
New Exposure menu, you can implement this change during a rolling upgrade of the ClaimCenter cluster application
servers. Conversely, if you implement this behavior by modifying file config.xml, then you need to perform a full
database upgrade to implement your changes.

Important
If you add a new value to the list of loss types in this configuration parameter, then you must also add that value to
configuration parameter ShowNewExposureMenuForLossTypes.
This caveat applies also if you modify one of the typefilters on the LossType typelist.
Default: AUTO,PR,GL,TRAV

ShowNewExposureMenuForLossTypes
Use to specify the ClaimCenter Actions→New Exposure menu for a specific loss type. Essentially, this parameter
determines for which loss types it is possible to create a new exposure.
In modifying this parameter:
• Deleting one of the default parameter values removes the New Exposure menu for that loss type. Removing the New
Exposure menu for a loss type also hides the Exposures step in the New Claim wizard for that loss type.
• Adding a value to the default parameter values list adds a Choose by Coverage Type submenu for that loss type. Add
your new loss type typecode to the existing comma-separated list of values.
It is also possible to create this same application behavior by adding a typekey to a typefilter of the same name as
this configuration parameter on the LossType typelist. If you added to the typefilter to modify the behavior of the
New Exposure menu, you can implement this change during a rolling upgrade of the ClaimCenter cluster application

User interface parameters 91

 Configuration Guide 9.0.5

servers. Conversely, if you implement this behavior by modifying file config.xml, then you need to perform a full
database upgrade to implement your changes.

Important
If you add a new value to the list of loss types in ShowNewExposureMenuForLossTypes, you must also add that
value to one, or both, of the following configuration parameters:
• ShowNewExposureChooseByCoverageMenuForLossTypes
• ShowNewExposureChooseByCoverageTypeMenuForLossTypes
This requirement also applies if you modify one of the typefilters on the LossType typelist.
Default: AUTO,PR,GL,TRAV

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

WebUIAJAXTimeout
Number of seconds that the ClaimCenter web client waits after issuing a call to the ClaimCenter server. If the server
does not respond within this time, the web client assumes that the server is offline, terminates all connections, and
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 config.xml file that relate to the work queue.
For information on editing config.xml 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 days to retain instrumentation information for a worker instance before ClaimCenter 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,
ClaimCenter sets AvailableSince to the current time. Later, ClaimCenter 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, ClaimCenter sets AvailableSince according to
the following formula:

92 chapter 2 Application configuration parameters

 Configuration Guide 9.0.5

workItem.AvailableSince = CurrentTime – (workItem.Priority * 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, ClaimCenter reverts the status of the work item from checkedout to
available. At the same time, ClaimCenter resets AvailableSince according to the following formula:

workItem.AvailableSince = 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 ClaimCenter 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, ClaimCenter logs the error only if
the number of attempts exceeds the configured value of the WorkItemRetryLimit. Otherwise, ClaimCenter logs the
debug message instead.
The value for WorkItemRetryLimit applies to all work queues unless overridden in work-queue.xmlby
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 93. All threads that are not core threads are additional on-demand
threads. ClaimCenter 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

Work queue parameters 93

 Configuration Guide 9.0.5

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
Configuration Guide 9.0.5
chapter 3

Getting started

This topic describes Guidewire Studio, which is the ClaimCenter administration tool for creating and managing
ClaimCenter resources. (Studio resources include Gosu rules, classes, enhancements, script parameters, and the
ClaimCenter 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 (Software Configuration Management)
system

What Is Guidewire Studio?

Guidewire Studio is the IDE (integrated development environment) for creating and managing ClaimCenter
application resources. These resources include Gosu rules, classes, enhancements and plugins, and all configuration
files used by ClaimCenter 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 ClaimCenter data entities, business objects, and data types
• Manage plugins and message destinations
• Configure database connections

Getting started 97
 Configuration Guide 9.0.5

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 ClaimCenter. 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
propagate into production. You must specifically build a .war or .ear 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 ClaimCenter
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 ClaimCenter application server. You use the QuickStart test server and test database for
testing only as ClaimCenter controls them internally. You can use either the bundled QuickStart development server
bundled with Guidewire ClaimCenter 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 or .ear file and
manually move it to the production server. The system does not do this for you.

98 chapter 3 Getting started

 Configuration Guide 9.0.5

Local (Development) Environment Production

Application Server

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

Configuration
Files
Database
Local
Configuration WAR / EAR
Files

SCM
System

ClaimCenter 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 ClaimCenter to the configuration resources edited by
Guidewire Studio. This requires additional configuration, described for each application server type in the
Installation Guide.
For information on starting and testing the QuickStart server from within Studio, see “Testing ClaimCenter with
Guidewire Studio” on page 511.

Connecting the development server to a database

ClaimCenter 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 mode The database does not persist data to the hard drive and it effectively drops the database each time you
restart the server. Guidewire does not recommend this configuration.

You set configuration parameters for the QuickStart database associated with the development server in database-
config.xml. For example:

Working with the QuickStart development server 99

 Configuration Guide 9.0.5

<!-- H2 (meant for development/quickstart use only!) -->

<database
name="ClaimCenterDatabase"
dbtype="h2">
<dbcp-connection-pool
jdbc-url="jdbc:h2:file:/tmp/guidewire/cc"/>
<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-urlattribute value specifies an actual file location. For example:

jdbc-url="jdbc:h2:file:/tmp/guidewire/cc"

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

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 ClaimCenter 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/cc).
The server must be stopped when you delete the directory.

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 ClaimCenter 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

100 chapter 3 Getting started

 Configuration Guide 9.0.5

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.

ClaimCenter configuration files

WARNING Do not attempt to modify any files other than those in the ClaimCenter/modules/configuration
directory. Any attempt to modify files outside of this directory can cause damage to the ClaimCenter
application and prevent it from starting thereafter.

Installing Guidewire ClaimCenter 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 gwcc 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 releases. For the
updated commands, see the Installation Guide.
build The output of build commands such as exploded .war and .ear files and the data and security dictionaries. This
directory is not present when you first install ClaimCenter. The directory is created when you run one of the
build commands.
dist Guidewire application .ear, .war, and .jar files are built in this directory. The directory is created when you run
one of the build commands to generate .war or .ear files.
doc HTML and PDFs of ClaimCenter documentation.
gradle Support files for Gradle, the project build tool.
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 ClaimCenter.
logs Application log files.
modules Subdirectories including configuration resources for each application component.
repository Necessary ClaimCenter files.

solr Installation and support files for the Solr free text search platform. See “Free-text search configuration” on page
411.
studio Application files for Guidewire Studio.
ThemeApp Files defining the user interface styling for ClaimCenter.
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 ClaimCenter 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, ClaimCenter does not start. In this case, overwrite any changes to all modules
except for the configuration directory and try again.

ClaimCenter configuration files 101

 Configuration Guide 9.0.5

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 ClaimCenter. In this environment, you can find all
of the files needed to configure ClaimCenter in two directories:
• The main directory of the configuration environment. In the default ClaimCenter installation, the location of this
directory is ClaimCenter/modules/configuration.
• ClaimCenter/modules/configuration/config contains the application server configuration files.
The installation process also installs a set of system administration tools in ClaimCenter/admin/bin.
ClaimCenter runs within a J2EE server container. To deploy ClaimCenter, 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 ClaimCenter (deployed as the cc.war
application) running on a Tomcat J2EE server on Windows, the deployment directory might be C:\Tomcat\webapps
\cc.

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 102
• “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
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 ClaimCenter installation directory, create a text file named studio.ultimate 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 idea.properties file. In
Guidewire Studio, you cannot edit idea.properties directly. Instead, do the following:

Procedure
1. Edit the file ClaimCenter/modules/script/gw-build.gradle.

102 chapter 3 Getting started

 Configuration Guide 9.0.5

2. Locate the studio section:

studio {
...
}

3. Within this section, set any properties that are valid in the idea.properties 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["idea.cycle.buffer.size"] = "disabled"

Note: Do not modify other sections of the gw-build.gradle file.

4. Restart Studio.

Studio and the DCEVM

The ClaimCenter 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"

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.

Studio and the DCEVM 103

 Configuration Guide 9.0.5

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.

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.

104 chapter 3 Getting started

 Configuration Guide 9.0.5

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:
https://studio-release.guidewire.com/releases/

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.
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 106.
2. Place the Studio update files in the shared location in your update site. You must include both the latest
studio-*.zip file, and also the metadata.txt file
3. In Studio, click File→Settings.
4. In the Settings dialog, in the navigation list, click Guidewire Studio.
5. In the Update section, set the Update Site URL text box to the URL of your update site.
6. Repeat from step 3 for each instance of Studio that updates from your update site.

Updating Guidewire Studio 105

 Configuration Guide 9.0.5

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 106
• “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, on the same page where your Guidewire application download is
available.
2. Click the link to the Studio Update page.
3. Download the following files:
• The studio-*.zip file with the highest release number.
• If you are setting up an internal site for Studio updates, also download the file metadata.txt.
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 ClaimCenter/studio.
2. Copy the studio-*.zip file with the highest release number.

Next steps
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 ClaimCenter/studio/plugins.

106 chapter 3 Getting started

 Configuration Guide 9.0.5

2. Delete the following directories:

• gosucheckstyle
• ij-gosu
• ij-studio
• inspections
3. Extract the studio-*.zip Studio update file into the ClaimCenter/studio/plugins directory.

Next steps
See also
• “Updating Studio manually” on page 106.

Updating Studio manually 107

 Configuration Guide 9.0.5

108 chapter 3 Getting started

chapter 4

Working in Guidewire Studio

This topic discusses a number of common tasks related to working in Guidewire Studio.

Entering valid code

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

Dot completion Opens a context-sensitive pop-up window that contains all the subobjects and methods that are valid for this
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 110 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 ClaimCenter 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 PCF types. Studio filters the list as you type to include only those choices
that match what you have typed thus far.

Working in Guidewire Studio 109

 Configuration Guide 9.0.5

Accessing reference information

ClaimCenter provides reference information that you can review. This includes:

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 a PCF reference (official name, Guidewire ClaimCenter 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 ClaimCenter/modules/pcf.html.

Accessing the Gosu Reference Guide

You can view the in the Guidewire ClaimCenter 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:

https://www.jetbrains.com/idea/help/keyboard-shortcuts-by-category.html

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.

110 chapter 4 Working in Guidewire Studio

 Configuration Guide 9.0.5

Keystroke Name Description

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.

Saving your work

ClaimCenter 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” using the File menu.

Command Description

File→Save All Writes any unsaved changes to your local fie or SCM 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 Object.equals method that the equality operator, ==, can replace

Saving your work 111

 Configuration Guide 9.0.5

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".

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 ClaimCenter 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 112
• “Verifying configuration resources” on page 111
• “Setting options for Gosu command prompt compilation” on page 112

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
112 chapter 4 Working in Guidewire Studio
 Configuration Guide 9.0.5

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 build.gradle file in the ClaimCenter
configuration folder. You add the configuration options and values at the top of the file, similar to the following
lines:

// Add custom project specific configuration here if needed

tasks.compileGosu.gosuOptions.failOnError = false

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

Configuration option Default value Description

tasks.compileGosu.gosuOptions.checkedArithmeti false Supports enabling checked arithmetic, which
c generates Gosu exceptions for nu.meric overflow
errors
tasks.compileGosu.gosuOptions.failOnError true Supports terminating a compilation task if the
number of errors exceeds the value that maxErrs
specifies.
tasks.compileGosu.gosuOptions.maxErrs 100 Specifies the permitted number of compilation
errors after which the compilation task fails if failO
nError 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.
tasks.compileGosu.gosuOptions.maxWarns Integer.max Specifies the permitted number of compilation
Int warnings after which the compilation task fails if war
nings 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 compilation warnings, the
reported number of warnings can be more than one
greater than this option value.
tasks.compileGosu.gosuOptions.verbose false Specifies whether to print a message to the log for
every file that the task compiles.
tasks.compileGosu.options.warnings false Supports terminating a compilation task if the
number of warnings exceeds the value that maxWarn
s 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 build.gradle file.

tasks.compileGosu.gosuOptions.checkedArithmetic = 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 build.gradle file.

tasks.compileGosu.gosuOptions.failOnError = false

Compiling configuration resources 113

 Configuration Guide 9.0.5

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.

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

ptions.failOnError = false' was specified.

• Add the following lines to the top of the build.gradle file.

tasks.compileGosu.gosuOptions.failOnError = true
tasks.compileGosu.gosuOptions.maxErrs = 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 build.gradle file.

tasks.compileGosu.options.warnings = true
tasks.compileGosu.gosuOptions.maxWarns = 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 build.gradle file.

tasks.compileGosu.gosuOptions.verbose = 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

\PolicyPeriodSearchCriteria.gs
gosuc: about to compile file: C:\Guidewire\PolicyCenter\modules\configuration\gsrc\gw\policy
\PolicyPeriodSideBySideEnhancement.gsx

114 chapter 4 Working in Guidewire Studio

 Configuration Guide 9.0.5

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

Compiling configuration resources 115

 Configuration Guide 9.0.5

116 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 117
• “Set the amount of memory for project builds in Guidewire Studio” on page 118

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 ClaimCenter/modules/script/gw-build.gradle.
2. Locate the studio section:

studio {
...
}

3. Within this section, set the following properties:

ideaProperties["tasks.studio.maxHeapSize"] = "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
tasks.pluginStudio.maxHeapSize.

Working with Guidewire Studio 117

 Configuration Guide 9.0.5

4. Restart Studio.

Next steps
See also
• “Setting IntelliJ IDEA properties in Studio” on page 102
•

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 118
• “Rebuild the Studio file index cache” on page 118

Rebuild the Studio project files

Procedure
1. At a command prompt, change to the ClaimCenter 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.

118 chapter 5 Working with Guidewire Studio

 Configuration Guide 9.0.5

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

Setting font display options 119

 Configuration Guide 9.0.5

120 chapter 5 Working with Guidewire Studio

chapter 6

ClaimCenter Studio and Gosu

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

Gosu building blocks

Guidewire provides a number of building blocks to assist you in implementing, configuring, and testing your
business logic in ClaimCenter. 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 ClaimCenter base configuration classes see, “ClaimCenter base configuration classes” on
page 123.
• For information on the @export annotation and how it affects a class in Studio, see “Class visibility in Studio” on
page 125.
• For general information on Gosu enhancements, see the Gosu Reference Guide.
• For information on using Gosu business rules within Guidewire ClaimCenter, see the Rules Guide.
• For information on script parameters and how to use them in Gosu code, see “Script parameters” on page 128.

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.

ClaimCenter Studio and Gosu 121

 Configuration Guide 9.0.5

To assist you, Studio highlights issues with case sensitivity.

The following table lists conventions for capitalization of various Gosu language elements:

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 com.mycompany.*

Working with Gosu in ClaimCenter 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 123

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

Gosu packages
Guidewire ClaimCenter 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.

122 chapter 6 ClaimCenter Studio and Gosu

 Configuration Guide 9.0.5

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 ClaimCenter to add properties and methods, and you can write your own Gosu
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 MyPackage.MyClass()

var name = myClassInstance.getName()

Studio stores enhancement files in the gsrc folder in the resources tree. Gosu class files end in .gs.
See also
• “ClaimCenter base configuration classes” on page 123
• “Class visibility in Studio” on page 125
• “Preloading Gosu classes” on page 126
• 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.

ClaimCenter 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
• libraries
• util
• wsi
• xsd
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:

com.guidewire.pl.quickjump.BaseCommand

For a discussion of the QuickJump functionality, see “Implementing QuickJump commands” on page 143.
Gosu classes 123
 Configuration Guide 9.0.5

The gw package
In the base ClaimCenter 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:
• gw.api.*
• gw.plugin

gw.api.*
There are actually two gw.api 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 can not only
access these classes but also modify them to suit your business needs.
You access both the same way, by entering gw.api 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 gw.api. 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.

gw.plugin
If you create a new Gosu plugin, place your plugin class in the gw.plugin package.
See also
• For information on how to use Studio to work with plugins, see “Using the plugins registry editor” on page 135.
• For information on various types of plugins and how to implement plugins, see the Integration Guide.

The libraries package

The libraries package contains a number of pre-built functions. To access these functions, enter the full package path
(for example):

libraries.Activityassignment.getUserRoleGroupTypeBasedonActivityPattern( activitypattern )

Or, place a uses statement at the top of your Gosu file, which allows you to enter the library name only (for
example):

uses libraries.Activityassignment
...
Activityassignment.getUserRoleGroupTypeBasedonActivityPattern( activitypattern )

The util package

The util package contains a number of pre-built classes that provide additional functionality for ClaimCenter
Financials.

124 chapter 6 ClaimCenter Studio and Gosu

 Configuration Guide 9.0.5

See also
• “ClaimCenter financial calculations” on page 743
• “Configuring ClaimCenter financials” on page 735
• “Configuring ClaimCenter financial screens” on page 767

The wsi package

ClaimCenter 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 141
• Integration Guide

The xsd package

As its name suggests, ClaimCenter stores XSDs in this folder. ClaimCenter uses these XSDs for a variety of
functions, for example:
• accord.xsd – Used by ClaimCenter FNOL Mapper that maps FNOL data in the form of XML to the
ClaimCenter Claim (and other) entity.
• iso.xsd – Used by ClaimCenter to generate types for ISO integration.

Class visibility in Studio

For a Guidewire-provided Gosu class to be directly visible Studio, Guidewire must mark that class with the @export
annotation. Thus, it is possible to view a class file in the application file structure, but to not be able to view or
access the file in the Studio Gosu editor. This is because the class file is missing the @export annotation.
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, 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/pc700/ccintegration/ccentitie

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

gw.webservice.pc.ccintegration.v2.ccentities

You then have this class extend CCPCSearchCriteria, for example:

package gw.webservice.pc.ccintegration.v2.ccentities

uses java.util.Date
uses gw.api.web.product.ProducerCodePickerUtil
uses gw.api.web.producer.ProducerUtil

class MyClass extends CCPCSearchCriteria {

var _accountNumber : String as AccountNumber
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

ClaimCenter base configuration classes 125

 Configuration Guide 9.0.5

construct() { }

override function extractInternalCriteria() : PolicySearchCriteria {

var criteria = new PolicySearchCriteria()
criteria.SearchObjectType = SearchObjectType.TC_POLICY
...
}
}

Preloading Gosu classes

ClaimCenter 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 preload.txt file in Other Resources to which you can add the following:

Static method invocations Static method invocations dictate some kind of action and have the following syntax:
type#method
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 gw.api.startup.PreloadActi
ons class. For example, to cause all Gosu types to be loaded from disk, use the following:
gw.api.startup.PreloadActions#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 – ClaimCenter loads the associated Java class file.
• Gosu – ClaimCenter 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 Server.Preload, 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 ClaimCenter 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 preload.txt file.

Result
The next time that you start the application server, ClaimCenter compiles those types on startup.

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.

126 chapter 6 ClaimCenter Studio and Gosu

 Configuration Guide 9.0.5

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.

Next steps
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, ClaimCenter
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.

Gosu enhancements 127

 Configuration Guide 9.0.5

See also
• Gosu Reference Guide

Script parameters
Script parameters are Studio-defined resources 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

ClaimCenter uses the ScriptParameters.xml 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→ScriptParameters.xml. At the time of creation, Studio adds new script parameters to
the ScriptParameters.xml configuration file. After creation, you manage the values of script parameters through
the ClaimCenter user interface, not through Studio.
On server startup, ClaimCenter compares the list of script parameters that currently reside in the database to those in
the ScriptParameters file. During the comparison, ClaimCenter does one of the following:
• New script parameters – ClaimCenter adds to the database new script parameters in the XML file that are not in
the database. ClaimCenter propagates the initial values as set in the XML file to the database.
• Existing script parameters – ClaimCenter ignores existing script parameters in the XML file that already are in
the database. ClaimCenter 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 ClaimCenter 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, ClaimCenter 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 ClaimCenter 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 ClaimCenter 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 a claim has been idle for over 180 days. If
you included the value “180” in all of the rules, you would have to modify the rules if you decided to change the
value to 120. Instead, define a script parameter, set its value to 180, and then use this parameter in the rules. To
change the claim exception behavior, you need change only the parameter and the Studio rules automatically use the
new value.

128 chapter 6 ClaimCenter Studio and Gosu

 Configuration Guide 9.0.5

More complex examples include:

• Setting a default age for claimants – This is useful for cases in which the computation of the reserve requires
an age and none is available at the time the exposure is set up.
• Setting the threshold number of days for various claim actions – This includes inactive claims in which the
number of inactive days before taking action varies by the coverage. After the date threshold passes, the Rule
engine can generate an activity.
• Setting the date for certain global reserve actions to occur – Suppose that an actuary modifies the values in
the reserve tables due to loss history, or to correct errors, or in response to legislation. In this case, it is possible
that you want to update the reserve amounts of all open exposures. To accomplish this, you can implement
several exception rules that only fire if the appropriate script parameter date is less than or equal to the current
date.

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 ClaimCenter 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 ClaimCenter 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 scriptparameters.xml 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, ClaimCenter 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 ClaimCenter 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 ScriptParameters.xml.
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.

Script parameters 129

 Configuration Guide 9.0.5

For example, for a script parameter of type varchar, use code similar to the following:

public static property get MyNewScriptParameter(): String {

return ScriptParameters.getParameterValue("MyNewScriptParameter") as String;
}

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 ScriptParameters.xml.
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 ScriptParameters.paramname.
For example, the following Gosu code determines if more than 180 days have elapsed from the filing of the claim:

gw.api.util.DateUtil.daysSince( Claim.ReportedDate ) > 180

You can, instead, create a script parameter named maxDate and rewrite the line as follows:

gw.api.util.DateUtil.daysSince(Claim.ReportedDate) > ScriptParameters.maxDate

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 ClaimCenter
interface.

130 chapter 6 ClaimCenter Studio and Gosu

part 3

Guidewire Studio editors

Configuration Guide 9.0.5
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 ClaimCenter 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 159
Entity Names Represent an entity name as a text string suitable for “Using the entity names editor” on page 149
viewing in the ClaimCenter interface.
Gosu Create and manage Gosu code used in classes, tests, “Working in the Gosu editor” on page 134
enhancements, and interfaces.
LOB (Lines of Define the six special typelists that define the - “Configuring lines of business” on page 561
Business) ClaimCenter Lines of Business (LOBs).
Messaging Work with messaging plugins. “Using the messaging editor” on page 155
Page Configuration Graphically define and edit page configuration (PCF) “Using the PCF editor” on page 349
(PCF) files, used to render the ClaimCenter Web interface.
Plugins Graphically define, edit and manage Java and Gosu “Using the plugins registry editor” on page
plugins. 135
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 451

Using the Studio editors 133

 Configuration Guide 9.0.5

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

134 chapter 7 Using the Studio editors

chapter 8

Using the plugins registry editor

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

What are plugins?

ClaimCenter plugins are mini-programs (Gosu or Java classes) that ClaimCenter invokes to perform an action or
calculate a result.
• An example of a plugin that calculates a result is a claim number generation plugin, which ClaimCenter invokes
to generate a new claim 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 ClaimCenter
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.

Using the plugins registry editor 135

 Configuration Guide 9.0.5

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, ClaimCenter
uses the plugin name as the interface name.
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 ClaimCenter 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. To rename the plugin implementation, right-
click it in the Project window hierarchy, and then click Refactor→Rename.
Gosu Implementations
If you select Add Gosu Plugin, you see the following:
136 chapter 8 Using the plugins registry editor
 Configuration Guide 9.0.5

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:
gw.plugin.package.impl
You must enter the fully-qualified path to the Gosu implementation class. For example, use gw.plugin.email.i
mpl.EmailMessageTransportPlugin for the Gosu EmailMessageTransport plugin.
See the Integration Guide for more information.

Java Implementations
If you select Add Java Plugin, you see the following:

Java Class Type the fully qualified path to the Java class that implements this plugin. This is the dot separated package
path to the class. Place all custom (non-Guidewire) Java plugin classes in the following directory:
ClaimCenter/modules/configuration/plugins/

Plugin (Optional) Type the name of the base plugin directory for the Java class. This is a folder (directory) in the mod
Directory ules/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.

3. After creating the plugin, you can add parameters to it. To do so, click Add Parameter , and then enter the
parameter name and value.
If you have already set the environment or server property at the global level, then those values override any
that you set in this location. For any property that you set in this location to have an effect, that property must
be set to the Default (null) at the global level for this plugin. For more information on setting environment
or server properties, see “Set environment and server context for plugin implementations” on page 138.

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.

Add an implementation to a plugins registry item 137

 Configuration Guide 9.0.5

Set environment and server context for plugin implementations

Within the Plugins Registry editor, you can set the plugin deployment environment (the Environment property) and
the server ID (the Server property).
• Use Environment to set the deployment environment in which this plugin is active. For example, you may have
multiple deployment environments (a test environment and a development environment) and you want this
plugin to be active in only one of these environments.
• Use Server to set a specific server ID. For example, if running ClaimCenter in a clustered environment, you may
want this plugin to be active only on a certain machine within the cluster.
These are global properties for this plugin. You can set either of these two properties on individual plugin properties.
But, if set in this location, these override the individual settings.
See also
• Integration Guide
• System Administration Guide

Customizing plugin functionality

If you want to modify the behavior of a plugin, then 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-digit abbreviation followed by the application
version number with no periods. For ClaimCenter 8.0.0, for example, the package includes cc800.
For example, in the Guidewire PolicyCenter application, the plugin implementation that connects PolicyCenter 8.0.0
to BillingCenter 8.0.0 is at the fully qualified path:

gw.plugin.billing.bc800.BCBillingSystemPlugin

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:

138 chapter 8 Using the plugins registry editor

 Configuration Guide 9.0.5

Application Abbreviation
ClaimCenter cc

PolicyCenter pc

ContactManager ab
BillingCenter bc

Working with plugin versions 139

 Configuration Guide 9.0.5

140 chapter 8 Using the plugins registry editor

chapter 9

Working with web services

ClaimCenter 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

ClaimCenter provides a fully WS-I compliant web services layer for both server publishing and client consuming
web service APIs.
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 area Description

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.

Working with web services 141

 Configuration Guide 9.0.5

Editor area Description

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
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 Shows the WSDL and XSD files for the web services.
Resources 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 ClaimCenter 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.

142 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 ClaimCenter 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 ClaimCenter. (Therefore, to remove the QuickJump box from the ClaimCenter interface, remove all commands
from the QuickJump configuration editor.)
You set the keyboard shortcut that activates the QuickJump box in config.xml. 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

QuickJumpCommandRef Commands that navigate to a page that accepts one or more static (with respect to the
command being defined) user-entered parameters. See “Implementing
QuickJumpCommandRef commands” on page 144 for details.
StaticNavigationCommandRef Commands that navigate to a page without accepting user-entered parameters. See
“Implementing StaticNavigationCommandRef commands” on page 146.
ContextualNavigationCommandRef Commands that navigate to a page that takes a single parameter, with the parameter
determined based on the user's current location. See “Implementing
ContextualNavigationCommandRef commands” on page 146.

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. ClaimCenter 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 143
 Configuration Guide 9.0.5

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 contain a space.
• ContextualNavigationCommandRef
Command Class • QuickJumpCommandRef Class that specifies how to implement the command. This
class must be a subclass of QuickJumpCommand. Guidewire
intentionally makes the base QuickJumpCommand class
package local. To implement, override one of the subclasses
described in “Implementing QuickJumpCommandRef
commands” on page 144.
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 appropriate for the command—either StaticNavigati
onCommand or ContextualNavigationCommand—and enter
the other required information in the appropriate columns.
Command Target • StaticNavigationCommandRef Target page ID.
• ContextualNavigationCommandRef
Command Arguments • StaticNavigationCommandRef Comma-separated list of parameters used in the case in
which 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 144
ParameterizedNavigationCommand “Implementing QuickJumpCommandRef commands” on page 144

ContextualNavigationCommand “Implementing QuickJumpCommandRef commands” on page 144

EntityViewCommand “Implementing QuickJumpCommandRef commands” on page 144

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

144 chapter 10 Implementing QuickJump commands

 Configuration Guide 9.0.5

number of extraneous classes needed. See “Implementing StaticNavigationCommandRef commands” on page 146
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.
ClaimCenter displays the command in the QuickJump box as part of the auto-complete list (before the user has
entered the entire command). Therefore, ClaimCenter 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, 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, however, that you use the ContextualNavigationCommandRef command type instead of
subclassing ContextualNavigationCommand. See “Implementing ContextualNavigationCommandRef commands”
on page 146 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 144.
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”).

Adding a QuickJump navigation command 145

 Configuration Guide 9.0.5

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
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.
ClaimCenter 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 Claim that takes a claim number and navigates to a Claim. Also, suppose that there is a
ContextualNavigationCommand called Contacts whose context type is Claim. In this case, the user can type Claim
35-402398 Contacts to invoke the Contacts command on the specified Claim.
See also
• “Implementing QuickJumpCommandRef commands” on page 144

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 ClaimCenter would have checked the
Note.create 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, ClaimCenter performs standard

146 chapter 10 Implementing QuickJump commands

 Configuration Guide 9.0.5

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, ClaimCenter cannot determine automatically whether to display the
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.)

Checking permissions on QuickJump navigation commands 147

 Configuration Guide 9.0.5

148 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 Studio Entity
Names editor.

Entity names editor

It is possible to define an entity name as a text string, which you can then use in the ClaimCenter 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.
ClaimCenter 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.
ClaimCenter uses these entity name definitions in generating database queries that return the limited information
needed to construct the display name string. This ensures that ClaimCenter 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.

Using the entity names editor 149

 Configuration Guide 9.0.5

For example, the Contact entity name defines the following variables:

Notice that this defines LastName as Person.LastName and Name as Company.Name, 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 Entity.property that the variable represents.

Sort Path The values that ClaimCenter uses in a sort.

Sort Order The order in which ClaimCenter 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 ClaimCenter labels
that entity column (field) as virtual in the ClaimCenter Data Dictionary.
Thus:
• You cannot use ClaimContactRole fields in the Entity Path, such as Exposure.Incident.Injured. 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
Exposure.ClaimantDenorm or Claim.InsuredDenorm. 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 ClaimCenter 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
150 chapter 11 Using the entity names editor
 Configuration Guide 9.0.5

an Entity Path of Exposure.ClaimantDenorm. 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
String variable called claimant. ClaimCenter 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 ClaimCenter 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 ClaimCenter uses in a sort

Sort Order Defines the order in which ClaimCenter sorts the Sort Path values

Therefore, if ClaimCenter 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 ClaimCenter 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 && Person.Type.isAssignableFrom(Type.forName("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.

The Use Entity Name? column 151

 Configuration Guide 9.0.5

<Cell id="Name" value="contact.DisplayName" ... />

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
Exposure.ClaimantDenorm.
To illustrate:

Name Entity Path Use Entity Name?

claimantDisplayName Exposure.ClaimantDenorm true

incidentDisplayName Exposure.Incident 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 Exposure.ClaimantDenorm.FirstName false

claimantLastName Exposure.ClaimantDenorm.LastName false

severity Exposure.Incident.Severity false

incidentDesc Exposure.Incident.Description 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, ClaimCenter 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 ClaimCenter 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 Claim.InsuredDenorm.)
• 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

152 chapter 11 Using the entity names editor

 Configuration Guide 9.0.5

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.

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:

entity.DisplayName

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. ClaimCenter 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.

Entity name types 153

 Configuration Guide 9.0.5

154 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 ClaimCenter 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 messaging-config.xml file.

Using the messaging editor 155

 Configuration Guide 9.0.5

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 ClaimCenter base configuration. You see it listed
as Default in the Messaging Config drop-down list.

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 ClaimCenter 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 .
ClaimCenter 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 135. 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.

156 chapter 12 Using the messaging editor

 Configuration Guide 9.0.5

Name Required.The name to use for this messaging destination.

Transport Required.The name of the MessageTransport plugin implementation that knows how to send messages for
Plugin this messaging destination. A destination must define a message transport plugin that sends a Message
object 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.

Next steps
If the Disabled checkbox 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, ClaimCenter 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 messageContext.destID.

Messaging editor 157

 Configuration Guide 9.0.5

158 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.
ClaimCenter 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 ClaimCenter uses additional display_languageCode.properties
files, one for each language that you install. For more information, see the Globalization Guide.
ClaimCenter 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 properties
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 Navigate to the display key that you want to modify, and then modify the string in the editor as
existing display key 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 Highlight the display key that you want to delete, and then press Delete.
key

Using the display keys editor 159

 Configuration Guide 9.0.5

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 Java.util.Properties.load 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).

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.
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 = DisplayKey.get("SendFailed")

Retrieving the value of a display key

Some display keys contain a placeholder argument or parameter, designated by {}. ClaimCenter replaces each of
these parameters with actual values at run time. For example, in the display key properties file, you see the
following:

Java.Activities.Error.CannotPerformAction = You do not have permission to perform actions on the

following activities\: {0}.

Thus, at run time, ClaimCenter 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:

160 chapter 13 Using the display keys editor

 Configuration Guide 9.0.5

Java.Admin.User.InvalidGroupAdd = The group {0} cannot be added for the user {1}
as they do not belong to the same organization.

Method DisplayKey.get
Use the DisplayKey.get method to return the value of the display key. Use the following syntax:

DisplayKey.get(display_key_name)

For example:

DisplayKey.get("Java.Admin.User.DuplicateRoleError")

returns:

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.

DisplayKey.get(display_key_name, arg1)

For example, the display key properties file defines the following display key with placeholder {0}:

Java.UserDetail.Delete.IsSupervisorError = Cannot delete user because they are supervisor of the

following groups\: {0}.

Suppose that you have the following display key Gosu code:

DisplayKey.get("Java.UserDetail.Delete.IsSupervisorError", 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:

DisplayKey.get(display_key_name, arg1, arg2, ...)

Note: Make sure to include the following line in any Gosu code that calls the DisplayKey.get method:

uses gw.api.locale.DisplayKey

Retrieving the value of a display key 161

 Configuration Guide 9.0.5

162 chapter 13 Using the display keys editor

part 4

Data model configuration

Configuration Guide 9.0.5
chapter 14

Working with the Data Dictionary

Guidewire provides the Data Dictionary to help you understand the ClaimCenter 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 165
“What can you view in the Data Dictionary?” on page 166
“Using the Data Dictionary” on page 167

What is the Data Dictionary?

The ClaimCenter Data Dictionary documents all the entities and typelists in your ClaimCenter installation. Provided
that you regenerate it following any customizations to the data model, the dictionary documents both the base
ClaimCenter 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 ClaimCenter. 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 ClaimCenter Data Dictionary, run the following command from the ClaimCenter directory:

gwb genDataDictionary

ClaimCenter stores the current version of the Data Dictionary in the following directory:

ClaimCenter/build/dictionary/data/

To view the Data Dictionary, open the following file:

ClaimCenter/build/dictionary/data/index.html

Working with the Data Dictionary 165

 Configuration Guide 9.0.5

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.
See also
• “Regenerating the data and security dictionaries” on page 37

Related concepts
“Regenerating the data and security dictionaries” on page 37

What can you view in the Data Dictionary?

Note: If you use a third-party tool to edit ClaimCenter 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 ClaimCenter/build/dictionary/data/index.html), 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 ClaimCenter application and the columns,
typekeys, arrays and foreign keys associated with each entity. See “Using the Data Dictionary” on page 167.
• Use the database view to view all persistent, non-virtual entities associated with the ClaimCenter application and
the persistent columns, typekeys, arrays and foreign keys associated with each persistent entity. See “Using the
Data Dictionary” on page 167.
• 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 ClaimCenter application and the typecodes
associated with each typelist. See “Using the Data Dictionary” on page 167.

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 ClaimCenter 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.

166 chapter 14 Working with the Data Dictionary

 Configuration Guide 9.0.5

• 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 167

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, ClaimCenter displays a left-side pane listing entities in ClaimCenter.
Then, on the right-side, ClaimCenter displays a pane that shows the details of the selected item in the left-side pane.
If you click on the Typelists view, ClaimCenter displays a left-side pane listing all of the typelists in ClaimCenter.
Then, on the right-side, ClaimCenter 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 167
“Object attributes” on page 168
“Entity subtypes” on page 169
“Data field types” on page 169
“Virtual properties on data entities” on page 170
“What is a typelist?” on page 304
“What can you view in the Data Dictionary?” on page 166

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
following 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
definition 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
extension entity in the extensions folder.

Using the Data Dictionary 167

 Configuration Guide 9.0.5

Color Meaning
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 ClaimCenter 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 data objects” on page 185.

Object attributes
An object in the ClaimCenter 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
Transaction entity has the attributes Abstract, Editable, Extendable, Keyed, Loadable, Sourceable, Supertype, 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, but does not make sense 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, it tracks who created it and the time, and who
last edited it and the time.
Extendable It is possible to extend the entity with additional custom fields added to it.
Final It is not possible to subtype this entity. You can, however, extend it 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. ClaimCenter 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 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
application 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. ClaimCenter deletes the
entity after the operation is complete.
Versionable The entity has a version number that increases every time the entity changes. The ClaimCenter 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 ClaimCenter 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 Transaction
entity has a property named Claim. The attributes of this property are export as id, exportable, loadable, non-null, and
writable.
The following list describes the possible attributes:

168 chapter 14 Working with the Data Dictionary

 Configuration Guide 9.0.5

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 Obsolete. The property is available to the SOAP APIs.
export as id Obsolete. The property causes the system to create an appropriate identifier for the referenced
entity. For example, the exported identifier will be ClaimIdentifier if the property points to the
claim table.
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 .
non-null The property cannot contain null values.
overwritten on load The property contains an overwrittenInStagingTable attribute with a value of true.
ClaimCenter 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 180 and 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, ClaimCenter
initiates validation on the property. See “<array>” on page 200, “<foreignkey>” on page 211,
and “<onetoone>” on page 216 for more information about the effects of the triggersValidat
ion attribute when arrays, foreign keys, and one-to-one entities change.

unique index The property participates in one or more unique indexes.

virtual property ClaimCenter 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.

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 ClaimCenter 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.
ClaimCenter 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.
ClaimCenter also looks at the subtype as it decides which fields to show in the ClaimCenter 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:

Using the Data Dictionary 169

 Configuration Guide 9.0.5

Type Description
array Represents a one-to-many relationship, for example, contact to addresses. There is no actual column in the
database table that maps to the array. ClaimCenter stores this information 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.
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 Indicates a derived property. ClaimCenter does not store virtual properties in the ClaimCenter physical
property database.

Virtual properties on data entities

The Data Dictionary lists certain entity properties as virtual. ClaimCenter does not store virtual properties in the
ClaimCenter 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 AccountContactRoleStubypes field:

Derived property returning gw.api.database.IQueryResult (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

Claim.BenefitsDecisionReason is a virtual property that pulls its value from the cc_claimtext table, which
stores ClaimText.ClaimTextType = 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

Claim.claimant is a virtual property that retrieves the Contact associated with the Claim with the
ClaimContactRole of claimant. It returns a Person value.

Virtual property based on a typelist

Contact.PrimaryPhoneValue is a virtual property that calculates its return value based on the value from
Contact.PrimaryPhone. It retrieves the telephone number stored in the field represented by that typekey. This can
be one of the following:
• Contact.HomePhone
• Contact.WorkPhone
• Person.CellPhone
It returns a phone value.

170 chapter 14 Working with the Data Dictionary

chapter 15

The ClaimCenter data model

The in ClaimCenter data model comprises the persistent data objects, called entities, that ClaimCenter manages in
the application database.

Related concepts
“What is the data model?” on page 171
“Overview of data entities” on page 173
“Base ClaimCenter data objects” on page 181

Related references
“Data object subelements” on page 199

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

The ClaimCenter data model 171

 Configuration Guide 9.0.5

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

The data model in Guidewire application architecture

Guidewire applications employ a metadata approach to data objects. ClaimCenter 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 ClaimCenter data model specifies the entities, fields, and other definitions that comprise a default installation of
ClaimCenter.
For example, the ClaimCenter data model defines a Claim entity and several fields on it, such as ClaimNumber,
LossDate, and Description.
You can change the ClaimCenter data model to accommodate your business needs. Make your changes to the data
model by modifying existing XML files and adding new ones. ClaimCenter stores your files that change the data
model in the following application directory:
ClaimCenter/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 ClaimCenter installation comprises the ClaimCenter model and any data model extensions that you make.

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

Working with dot notation

Many places within ClaimCenter require knowledge of fields within the application data model, especially while
you configure ClaimCenter. For example, code in a business rule, class or enhancement may need to check the
owner of an assignable object. Or, code may need to check the date and time of object creation. ClaimCenter
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 rules on a claim for example, the claim is
the root object, and you can access anything that relates to this claim. On the other hand, if you run an assignment
rule for an activity, the activity is the root object. In this case, you have access to fields that relate to the activity,
including the claim associated with the activity.
Guidewire applications use dot notation for relative references. For example, assume that your code has Claim as
the root object. For a simple reference to a field on the claim such as LossDate, use:

claim.LossDate

172 chapter 15 The ClaimCenter data model

 Configuration Guide 9.0.5

However, suppose that you want to reference a field on an entity that relates to the claim, such as the policy
expiration date. You must first describe the path from the claim to the policy, then describe the path from the policy
to the expiration date of the policy:

claim.Policy.ExpirationDate

Overview of data entities

Data entities are the high-level business objects used by ClaimCenter, such as a Claim, Exposure, or Policy. An
entity serves as the root object for data views, rules, Gosu classes, and most other data-related areas of ClaimCenter.
Guidewire defines a set of data objects in the base ClaimCenter 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 ClaimCenter 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. See .

Related concepts
“The ClaimCenter 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 ClaimCenter/modules/
configuration/config/metadata directory) by editing them directly. You can view these files in read-only
mode in Studio in the configuration →config→Metadata folder.

To better understand the syntax of entity metadata, it is sometimes helpful to look at the ClaimCenter data model
and its metadata definition files. ClaimCenter 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 Purpose Contains More information

.dti Data Type Info A single data type definition. “Data types” on page
281
.eti Entity Type Information A single Guidewire or custom entity declaration. The “Base ClaimCenter data
name of the file corresponds to the name of the entity objects” on page 181
being declared.
.eix Entity Internal eXtension A single Guidewire entity extension. The name of the file Internal defintion; see .e
corresponds to the name of the Guidewire entity being tx
extended.
.etx Entity Type eXtension A single Guidewire or custom entity extension. The name “Extension data objects”
of the file corresponds to the name of the entity being on page 190
extended. “View entity extension
data objects” on page
198

Overview of data entities 173

 Configuration Guide 9.0.5

File type Purpose Contains More information

.tti Typelist Type Info A single Guidewire or custom typelist declaration. The “Working with typelists”
name of the file corresponds to the name of the typelist on page 303
being declared.
.tix Typelist Internal eXtension A single Guidewire typelist extension. The name of the “Working with typelists”
file corresponds to the name of the Guidewire typelist on page 303
being extended.
.ttx Typelist Type eXtension A single Guidewire or custom typelist extension. The “Working with typelists”
name of the file corresponds to the name of the typelist on page 303
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 modifiable

.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 ClaimCenter 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 ClaimCenter data model includes the following metadata definition files that collectively define
the Address entity type.

File version Metadata location File purpose

Address.eti configuration→config→Metadata→Entity Entity definition

Address.eix configuration→config→Metadata→Entity Extension to the entity definition

At runtime, ClaimCenter 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 ClaimCenter data
model. ClaimCenter considers the base definitions in configuration→config→Metadata first, and then applies the

174 chapter 15 The ClaimCenter data model

 Configuration Guide 9.0.5

definitions in the Extensions folder to them. This lets you create an entity extension that overrides any Guidewire
entity extensions.

Example of Activity metadata and extension files

The ClaimCenter data model includes the following metadata definition files that collectively define the
ClaimCenter Activity entity.

File Location Purpose

Activity.eti configuration→config→Metadata→Entity Entity definition, not modifiable.

Activity.eix configuration→config→Metadata→Entity Entity extension, not modifiable.

To extend the ClaimCenter Activity entity, create the following extension file through Guidewire Studio.

File Location Purpose

Activity.etx 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, ClaimCenter 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, ClaimCenter upgrades the
database.
Sometimes you want to force ClaimCenter to upgrade the database without making changes to your custom data
model extensions. The configuration→config→Extensions folder in Studio contains an extensions.properties 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 ClaimCenter. It controls whether ClaimCenter performs a database
upgrade on server startup.
Whenever ClaimCenter upgrades the database, ClaimCenter stores the value of the version property in the
database. The next time the application server starts up, ClaimCenter compares the value of the property in the
database to the value in the extensions.properties file. If the value in the database is lower than the value in the
file, ClaimCenter performs a database upgrade. If the value in the database is higher, the upgrade fails.

WARNING In a production environment, Guidewire 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 extensions.properties file in a development environment is optional.

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.

Data entity metadata files 175

 Configuration Guide 9.0.5

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.

176 chapter 15 The ClaimCenter data model

 Configuration Guide 9.0.5

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.

ClaimCenter data entities

ClaimCenter uses XML metadata files to define all data entities in the data model. The datamodel.xsd 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 datamodel.xsd. You can invalidate your ClaimCenter installation and
prevent it from starting thereafter.

File datamodel.xsd 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 ClaimCenter entity definition files must correspond to the definitions in datamodel.xsd.
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 Activity.eti file:

<?xml version="1.0"?>
<entity xmlns="http://guidewire.com/datamodel"
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, ClaimCenter loads the XML definitions of the data entities into the application
database.

Data entities and the application database

ClaimCenter defines each data entity as a root XML element in the file that bears its name. For example,
ClaimCenter defines the Activity data entity in Activity.eti:

<entity xmlns="http://guidewire.com/datamodel"
entity="Activity"
...
type="retireable">
...
</entity>

Overview of data entities 177

 Configuration Guide 9.0.5

Notice that for the base configuration Activty object, ClaimCenter sets the type attribute to retireable. The type
attribute that determines how ClaimCenter manages the data entity in the ClaimCenter database. For example:
• If a data entity has a type value of versionable, ClaimCenter 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, ClaimCenter stores instances of the entity in the database
forever. However, you can retire, or hide, specific instances so that ClaimCenter does not display them in the
interface.

IMPORTANT For each data entity in the ClaimCenter data model and for each entity type that you declare,
ClaimCenter 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. ClaimCenter automatically stores the version
use number of an editable entity. In addition to the standard versionable attributes of version and ID,
an editable entity has the following additional attributes:
• CreateUser and CreateTime
• UpdateUser and UpdateTime
joinarray Internal A joinarray entity works in a similar manner to a versionable entity. Guidewire recommends
use only that you do not use this entity type. Use versionable instead.
keyable Internal A keyable entity that has an ID, but it is not editable. It is possible to delete entities of this type
use only from the database. Guidewire recommends that you do not use this entity type; use versionabl
e instead.

nonkeyable Internal Do not use.

use only
retireable General The retireable entity is an extension of the editable entity, and is the most common type of
use entity. Most, but not all, base entities are of this type.
After ClaimCenter adds an instance of a retireable data entity to the database, ClaimCenter
never deletes the instance. Instead, ClaimCenter retires the instance. For example, if you select a
retireable instance in a list view and then click Delete, ClaimCenter preserves the instance in the
database. However, ClaimCenter inserts an integer in the Retired column for the row that
represents the instance. Any non-zero value in the Retired column indicates that ClaimCenter
considers the instance retired.
ClaimCenter 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 ClaimCenter creates for editable entities, with the addition of
Retired property.
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 determine the
retireability of an entity.

178 chapter 15 The ClaimCenter data model

 Configuration Guide 9.0.5

Type attribute Usage Description

versionable General An entity that has a version and ID. Entities of this type can detect concurrent updates. In general
use practice, Guidewire recommends that you use this entity type instead of keyable. Versionable
extends keyable.
It is possible to delete entities of this type from the database.

ClaimCenter database tables

For every entity type in the data model, ClaimCenter creates a table in the application database. For example,
ClaimCenter creates a Claim table to store information about the Claim object.
In the application database, you can you identify an entity or extension table by the following prefix:

cc_ Entity table – one for each entity in the base configuration
ccx_ 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 “Non-persistent entity data objects” on page 191 for more information.
Besides entity tables, ClaimCenter creates the following types of tables in the database:

Table type More information

shadow tables “Shadow tables” on page 179
staging tables “Staging tables” on page 180
temporary tables “Temporary (temp) tables” on page 180

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:

cct_ Entity shadow table

cctt_ 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 server.running.tests 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, ClaimCenter drops the database, recreates it, and then creates the shadow tables. ClaimCenter
creates shadow tables only in an empty database.

Overview of data entities 179

 Configuration Guide 9.0.5

Staging tables
ClaimCenter 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:
• ClaimCenter replaces foreign keys by PublicID objects of type String.
• ClaimCenter 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 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 ccst_.

Temporary (temp) tables

ClaimCenter 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. ClaimCenter uses temporary tables as
work tables during installation or upgrade only. ClaimCenter 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 ClaimCenter defaults to a scriptability of all.

180 chapter 15 The ClaimCenter data model

 Configuration Guide 9.0.5

IMPORTANT There are subtle differences in how ClaimCenter treats entities and fields marked as doesNotExist
and hidden. However, these differences relate to internal ClaimCenter 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
ClaimCenter does not generate constructors for the entity. In essence, you cannot create a new instance of the entity
in Gosu. Within the ClaimCenter 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 ClaimCenter 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

Base ClaimCenter data objects

All ClaimCenter objects exist as one of the base data objects or as a subtype of a base object. The following table
lists the data objects that Guidewire defines in the base ClaimCenter configuration.

Data object Extension Folder More information

<delegate> .eti metadata, extensions “Delegate data objects” on page 182

<entity> .eti metadata, extensions “Entity data objects” on page 185

<extension> .etx extensions “Extension data objects” on page 190

<nonPersistentEntity> .eti metadata, extensions “Non-persistent entity data objects” on page 191

<subtype> .eti metadata, extensions “Subtype data objects” on page 193

<viewEntity> .eti metadata “View entity data objects” on page 195

<viewEntityExtension> .etx extensions “View entity extension data objects” on page 198

Data objects and scriptability 181

 Configuration Guide 9.0.5

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 data objects” on page 182

Related references
“Entity data objects” on page 185
“Extension data objects” on page 190
“Non-persistent entity data objects” on page 191
“Subtype data objects” on page 193
“View entity data objects” on page 195
“View entity extension data objects” on page 198

Delegate data objects

A delegate data object is a reusable entity that contains an interface and a default implementation of that interface. A
delegate may also add its own columns to the tables of data objects that implement the delegate. This type of
delegation enables a data object to implement an interface while delegating the implementation to the delegate.
You often use a delegate so 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 delegate data object in data model metadata files as the <delegate> XML root element. You can
extend existing delegates that are marked as extendable, and you can create your own delegates.
ClaimCenter stores all database columns on the delegate entity on the parent entity.

Implementing delegate objects

To implement most delegate objects, 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 213
• “Creating a new delegate object” on page 243.
• For a discussion of working with delegates in Gosu classes, see the Gosu Reference Guide.

182 chapter 15 The ClaimCenter data model

 Configuration Guide 9.0.5

Delegate objects 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
These are special delegates that ClaimCenter 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:

<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. ClaimCenter 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.

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, editab
le extends versionable, and versionable extends keyable. An entity can
implement the delegate if the implementor is the specified type or one that extends

Delegate data objects 183

 Configuration Guide 9.0.5

<delegate> attribute Description Default

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 180 for information. None

Subelements of <delegate>
The <delegate> element contains the following subelements.

<delegate> subelement Description

column See “<column>” on page 202.

datetimeordering Internal.
dbcheckbuilder Internal.
foreignkey See “<foreignkey>” on page 211.
fulldescription See “<fulldescription>” on page 213.
implementsEntity See “<implementsEntity>” on page 213.
implementsInterface See “<implementsInterface>” on page 214.
index See “<index>” 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 Cu
rrency typelist.

typekey See “<typekey>” on page 219.

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
ClaimCenter 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. ClaimCenter 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

184 chapter 15 The ClaimCenter data model

 Configuration Guide 9.0.5

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 ClaimCenter classes defined in Java, you cannot override these class methods on its Gosu subtypes. You can,
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 data objects

An entity data object is the standard persistent data object that defines many—if not most—of the ClaimCenter
entities. Guidewire defines this object in the data model metadata files as the <entity> XML root element.

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 runtime. Instead, you false
must declare a subtype entity with abstract=false, which you can instantiate. Any
of the generated code is abstract.
admin Determines whether you can reference the entity from staging tables: false
• 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 cc
st_y specify a valid entry in cc_x, the main table.

cacheable Internal. If set to false, then Guidewire prohibits entities of this type and all its true
subtypes from existing in the global cache.
consistentChildren Internal. If set to true, then ClaimCenter generates a consistency check and a loader false
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 name. You can access None
this name using the following:
entity.DisplayName

Base ClaimCenter data objects 185

 Configuration Guide 9.0.5

<entity> attribute Description Default

If you do not specify a value for the DisplayName attribute, then the entity.Displa
yName method returns the value of the entity attribute, instead. If you subtype an
entity that has a specified display name, then the entity.DisplayName method
returns the name of the subtype key.
edgeTable For the purposes of archiving, whether the entity has the semantics of an edge false
table.
entity Required. The name of the entity. You use this name to access the entity in data None
views, rules, and other areas within ClaimCenter.
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 define subtypes using this true
entity as the supertype.
IMPORTANT If you define this incorrectly, ClaimCenter generates an error message
upon resource verification and the application server refuses to start. ClaimCenter
generates this verification error:
• If you attempt to subtype an entity that is marked as final that exists in the met
adata folder in Studio.
• If you attempt to subtype an entity that is marked as final that exists in the ext
ensions folder in Studio.

generateInternallyIfAbsent Internal. Do not use. false

ignoreForEvents The ignoreForEvents attribute indicates whether other entities pass over the false
instant entity when determining the origin of an event. If the value of ignoreForEve
nts is true, ClaimCenter 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 generate events when you create, modify, or
delete it. Thus, it makes no sense for ClaimCenter to examine either that entity or
entities that reference it when the product searches for the source of an event.
Nonetheless, even if an entity generates no events, whenever you modify it,
ClaimCenter still examines that entity and all entity instances that reference it. The
scope of this examination encompasses the non-event-generating entity as well as
arrays, foreign keys, and edge foreign keys that reference it. If ClaimCenter finds an
entity instance that both generates events and references the modified, non-event-
generating entity, the product generates a Changed event for that entity instance.
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 generation altogether if you set the ignoreForEve
nts attribute to true on the non-event-generating entity. In this case, ClaimCenter
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 instances both that reference the
entity and that you want ClaimCenter 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 entity, ClaimCenter does
not ignore the entity altogether. When you modify the entity, event-generating
entity instances that reference the entity and on which the ignoreForEvents
attribute is false still generate events. Instead, ClaimCenter ignores only the
referencing entity instance on which you set the ignoreForEvents attribute to tr
ue.

186 chapter 15 The ClaimCenter data model

 Configuration Guide 9.0.5

<entity> attribute Description Default

Thus, if you want no events triggered at all when you modify a non-event-
generating entity, set the ignoreForEvents attribute 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, ClaimCenter adds a lock column (lockingcolumn) to the false
table for this entity. ClaimCenter 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 ordering
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 auto-populates the false
staging table during import.
IMPORTANT If set to true, do not attempt to populate the table yourself, because
the loader import process overwrites this table.
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 -1
entities 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 None
import as administrative data and then never touch again.
You can add a read-only entity only to a bundle that has the allowReadOnlyBeanCha
nges() 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 administrative 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 180. None
subpackage Subpackage to which the class corresponding to this entity belongs. None
table Required. The name of the database table in which ClaimCenter stores the data for None
this entity. ClaimCenter automatically prefixes table names with cc_ for base
entities and ccx_ for extension entities.
Guidewire recommends the following table naming conventions:
• 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 ClaimCenter automatically prefixes extension table names with ccx_, 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 maximum allowable length of
the table name:
• loadable="true" — maximum of 25 characters
• loadable="false" — maximum of 26 characters

Base ClaimCenter data objects 187

 Configuration Guide 9.0.5

<entity> attribute Description Default

temporary Internal. If true, then this table is a temporary table that ClaimCenter uses only false
during installation or upgrade.
ClaimCenter deletes all temporary tables after it completes the installation or the
upgrade.
type Required. See “Overview of data entities” on page 173 for a discussion of data entity None
types.
typelistTableName If you create a non-final entity, then ClaimCenter automatically creates a typelist to None
keep 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 ClaimCenter uses the
name of the entity as the table name for the subtype typelist.
However, ClaimCenter places a restriction of 25 characters on the length of the
database 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.
validateOnCommit Internal. Do not use. If true, ClaimCenter validates this entity during a commit of a true
bundle that contains this entity.

IMPORTANT Do not modify internal entity attributes. This instruction applies even in the case of custom entities.

Subelements of <entity>
The <entity> element contains the following subelements.

<entity> subelement Description

array See “<array>” on page 200.
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 213.
implementsEntity See “<implementsEntity>” on page 213.
implementsInterface See “<implementsInterface>” on page 214.
index See “<index>” on page 215.
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 216.
remove-index See “<remove-index>” on page 218.

188 chapter 15 The ClaimCenter data model

 Configuration Guide 9.0.5

<entity> subelement Description

searchColumn See “Entity data objects” on page 185
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 performance critical searches.
tableAugmenter Internal.
typekey See “<typekey>” on page 219.
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.

<searchColum Description Default

n> attribute

columnName Name to use for the database column corresponding to this property. If you do not None
specify a value, then ClaimCenter uses the name value instead.
The columnName attribute must be no more than 30 characters in length. It allows 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.
deprecated If true, then ClaimCenter 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.
For more information, see “Data object subelements” on page 199.
desc Description of the intended purpose of this column. None
name Required. Name of the column on the table and the field on the entity. The name value None
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 contain an underscore.
sourceColumn Required. Name of the column on the source entity, whose value this column copies. The None
sourceColumn must not name a localized column.

sourceForeignKey Required. Name of a foreign key field on this entity, which refers to the source entity for None
this search denormalization column. The sourceForeignKey must not be importable
against existing objects.

Base ClaimCenter data objects 189

 Configuration Guide 9.0.5

<searchColum Description Default

n> attribute

sourceSubtype Optional name of the particular subtype on which the source column is defined. If not None
specified, then ClaimCenter assumes that the source column to exist on the entity
referred to by the source object. However, you must specify this value if the sourceColum
n 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. ClaimCenter 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 data objects

An extension data object is the standard data object that you use to extend an already existing data object or entity.
Guidewire defines this object in the data model metadata files as the <extension> XML root element.
See also
• For information on how to extend the base data objects, see “Modifying the base data model” on page 233.

Attributes of <extension>
The <extension> element contains the following attributes.

<extension> attribute Description Default

entityName Required. This value must match the file name of the entity that it extends. None
ClaimCenter generates an error at resource verification if the value set that you set for
the entityName attribute for an extension does not match the file name.

Subelements of <extension>
The <extension> element contains the following subelements.

190 chapter 15 The ClaimCenter data model

 Configuration Guide 9.0.5

<extension> subelement Description

array See “<array>” on page 200.
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
239 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 239 for details.
description A description of the purpose and use of the entity.
edgeForeignKey See “<edgeForeignKey>” on page 207.
edgeForeignKey-override Use to override certain very specific attributes of a base data object.

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>
element definition on a base data object. See “Working with attribute and element overrides” on
page 239 for details.
implementsEntity See “<implementsEntity>” on page 213.
implementsInterface See “<implementsInterface>” on page 214.
index See “<index>” on page 215.
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 216.

onetoone-override Use to override, or flip, the value of the triggersValidation attribute of an <ontoone> element
definition on a base data object. See “Working with attribute and element overrides” on page
239 for details.
remove-index See “<remove-index>” on page 218.
searchColumn See “Entity data objects” on page 185
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
performance critical searches.
typekey See “<typekey>” on page 219.
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 239 for details.

Non-persistent entity data objects

A non-persistent entity data object defines a temporary entity that ClaimCenter creates and uses only during the time
that the ClaimCenter server is running. When the server shuts down, ClaimCenter discards the entity data. It is not
possible to commit a non-persistent entity object to the database.
Guidewire defines this object in the data model metadata files as the <nonPersistentEntity> XML root element.

Base ClaimCenter data objects 191

 Configuration Guide 9.0.5

Note: You cannot extend 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. Passing a non-persistent
entity to a PCF page, for example, is generally a bad idea because it generally does not work in the manner that you
expect.
A non-persistent entity 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 from one
context to another, the entity 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 moves around. Entity serialization is also less efficient and less
controllable than using a custom class that contains only the data that it really needs.
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 and 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, for example, as a nonnegativeinteger column, specify a data type through the
use of annotations. Then add the wanted data type behavior to properties on Gosu classes. For information on
how to associates data types with object properties using the annotation syntax, see “Defining a data type for a
property” on page 283.

Attributes of <nonPersistentEntity>
The <nonPersistentEntity> element contains the following attributes.

<nonPersistentEntit Description Default

y> attribute

abstract If true, you cannot an create 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:
entity.DisplayName
If you do not specify a value for the DisplayName attribute, then the entity.Displ
ayName method returns the value of the entity attribute, instead. If you subtype an
entity that has a specified display name, then the entity.DisplayName 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 ClaimCenter.
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 -1
entities participating in a subtype hierarchy, which can be either the <subtype>
entities or the root <entity>.

192 chapter 15 The ClaimCenter data model

 Configuration Guide 9.0.5

<nonPersistentEntit Description Default

y> attribute

typelistTableName If you create a non-final entity, then ClaimCenter automatically creates a typelist to None
keep 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 ClaimCenter uses the
name of the entity as the table name for the subtype typelist.
However, ClaimCenter places a restriction of 25 characters on the length of the
database 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> subelement Description

array See “<array>” on page 200.
column See “<column>” on page 202.
edgeForeignKey See “<edgeForeignKey>” on page 207.
foreignkey See “<foreignkey>” on page 211.
fulldescription See “<fulldescription>” on page 213.
implementsEntity See “<implementsEntity>” on page 213.
implementsInterface See “<implementsInterface>” on page 214.
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 216.
typekey See “<typekey>” on page 219.

Subtype data objects

A subtype defines an entity that is a subtype of another entity. The subtype entity has all of the fields and elements
of its supertype and it can also have additional ones. Guidewire defines this object in the data model metadata files
as the <subtype> XML root element.
ClaimCenter does not associate a separate database table with a subtype. Instead, ClaimCenter 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, ClaimCenter stores all fields of a subtype in the database as nullable columns
—even the ones defined as non-nullable. However, if you define a field as non-nullable, then the ClaimCenter
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. ClaimCenter automatically
creates a Subtype field for non-final entities.

Attributes of <subtype>
The <subtype> element contains the following attributes:

Base ClaimCenter data objects 193

 Configuration Guide 9.0.5

<subtype> attribute Description Default

abstract If true, you cannot an create instance of the entity type at runtime. Instead, you must false
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 subtype. None
displayName Optional. Occasionally in the ClaimCenter interface, you want to display the subtype None
name 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:
entity.DisplayName
If you do not specify a value for the displayName attribute, then ClaimCenter displays
the name of the entity. The entity name is often not user-friendly. For a description of
the displayName attribute, see “Entity data objects” on page 185.
entity Required.
final If true, you cannot subtype the entity. If false, you can define subtypes using this entity false
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 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 None
import as administrative data and then never touch again.
You can add a read-only entity only to a bundle that has the allowReadOnlyBeanChange
s() 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 administrative 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 180 for information. None
supertype Required.

Subelements of <subtype>
The <subtype> element contains the following subelements.

<subtype> subelement Description

array See “<array>” on page 200.
checkconstraint Internal.
column See “<column>” on page 202.
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 213.

194 chapter 15 The ClaimCenter data model

 Configuration Guide 9.0.5

<subtype> subelement Description

implementsEntity See “<implementsEntity>” on page 213.
implementsInterface See “<implementsInterface>” on page 214.
index See “<index>” on page 215.
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 216.
searchColumn See “Entity data objects” on page 185
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 performance critical searches.
tableAugmenter Internal.
typekey See “<typekey>” on page 219.
validatetypekeyinset Internal.
validatetypekeynotinset Internal.

Subtypes and typelists

After you define a new subtype, ClaimCenter automatically adds that entity type to the associated entity typelist.
This is true, even if ClaimCenter 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="http://guidewire.com/datamodel" 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. ClaimCenter
automatically adds the new InspectorExt type to the Contact typelist. This is true, even though ClaimCenter
marks the Contact typelist as final.
To see this change:
• In the ClaimCenter Data Dictionary, you must restart the application server.
• In the Contact typelist in Studio, you must restart Studio.
See also
• “Defining a subtype” on page 248

View entity data objects

A view entity 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.

Subtype data objects 195

 Configuration Guide 9.0.5

For example, from the ActivityView, you can specify a column with a Claim.ClaimNumber value. The Activity
entity is the primary entity of the ActivityView. The Activity entity has a corresponding view entity called
ActivityView.
Unlike a standard entity, a view entity does not have an underlying database table. ClaimCenter 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 ClaimCenter 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 ClaimCenter 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. See “Extending an existing view entity with a
currency column” on page 252 for details.
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> attribute Description Default

abstract If true, you cannot an create instance of the entity type at runtime. Instead, you must false
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 this None
name using the following:
viewEntity.DisplayName
If you do not specify a value for the DisplayName attribute, then the entity.DisplayN
ame method returns the value of the entity attribute, instead. If you subtype an entity
that has a specified display name, then the entity.DisplayName method returns the
name of the subtype key.
entity Required. Name of this viewEntity object. None
exportable Unused.
extendable If true, it is possible to extend this entity. true

final If true, the entity definition is final and you cannot define any subtypes for it. If false, true
then 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 false
appears in a data distribution report.
primaryEntity Required. The primary entity type for this viewEntity object. The primary entity must None
be keyable. See “Data entities and the application database” on page 177 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

196 chapter 15 The ClaimCenter data model

 Configuration Guide 9.0.5

<viewEntity> attribute Description Default

supertypeEntity Optional. The name of supertype of this entity. None
typelistTableName If you create a non-final entity, then ClaimCenter automatically creates a typelist to None
keep 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 ClaimCenter uses the name
of the entity as the table name for the subtype typelist.
However, ClaimCenter places a restriction of 25 characters on the length of the
database table 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> subelement Description

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 214.
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
ClaimCenter 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 ClaimCenter 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:

<viewEntityName name="RelActAssignedUserName" path="RelatedActivity.AssignedUser"/>

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="LineItems.Amount" function="SUM"/>

Base ClaimCenter data objects 197

 Configuration Guide 9.0.5

The expression for this column can take multiple column values ${column_num} passed from the ClaimCenter
interface. For example, a valid expression is: ${1} - ${2} with ${1} the first column and ${2} 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, ClaimCenter applies an SQL group automatically.

View entity extension data objects

You use the view entity extension entity to extend the definition of a “View entity data objects” on page 195 entity.
Guidewire defines this object in the data model metadata files as the <viewEntityExtension> XML root element.

Attributes of <viewEntityExtension>
The <viewEntityExtension> element contains the following attributes:

<viewEntityExtensio Description Default

n> attribute

entityName Required. This value must match the file name of the viewEntityExtension None
that it extends.
ClaimCenter 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> subelement Description

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.
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 cu
rrencyProperty specified in the original column definition on the viewEntity entity.
See “Extending an existing view entity” on page 252 for an example of this.
viewEntityLink Uses to access another entity through a foreign key. Typically, you use this value
within the ClaimCenter 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
ClaimCenter interface.

198 chapter 15 The ClaimCenter data model

 Configuration Guide 9.0.5

<viewEntityExtension> subelement Description

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 object 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>
• <dbcheckbuilder>
• <jointableconsistencycheck>
• <tableAugmenter>
• <validatetypekeyinset>
• <validatetypekeynotinset>

Data object subelements 199

 Configuration Guide 9.0.5

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 Claim
entity includes an array of Document entities.

Attributes of <array>
The <array> element contains the following attributes:

<array> attribute Description Default

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. None
However, you do not need to define a value if the array entity has exactly one foreign key
back to this entity.
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 true, then if you delete the array container, then ClaimCenter deletes (or retires) the false
array elements also.
deprecated If true, then ClaimCenter 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.

200 chapter 15 The ClaimCenter data model

 Configuration Guide 9.0.5

<array> attribute Description Default

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 180 for information. all

ignoreForEvents Determines whether ClaimCenter generates an event if a user modifies the <array> false
element in any way. Such modifications include adding an entity to, changing an entity in,
and removing an entity from the <array> element. If the ignoreForEvents attribute is set
to true, ClaimCenter will not generate an event.
For more information, see
ignoreForEvents
.
name Required. The name of the property corresponding to this array None
owner If true, then this entity owns the objects in the array. This has the following behavior: false
• 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 isFie
ldChanged returns false if a child element of the array has changed. In either case, isF
ieldChanged returns true if any child elements are added to or removed from the array,
regardless of the value of the owner attribute.
• If true, then if you delete the owning object, then ClaimCenter deletes (or retires) the
array items, as well. In this case, ClaimCenter deletes the array items notwithstanding a
value of false for the cascadeDelete attribute.
• If true, then if you update the contents of the array, then ClaimCenter 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 ca
scadeDelete and triggersValidation attributes.

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 180 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 ClaimCenter 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 ClaimCenter attempts to commit

Data object subelements 201

 Configuration Guide 9.0.5

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 ClaimCenter 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, ClaimCenter invokes the IPreUpdateHandler
plugin on the commit bundle instead. Then, ClaimCenter executes the logic defined in the plugin on the commit
bundle.
• If the parent entity has validation rules, but no preupdate rules, then ClaimCenter 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, ClaimCenter does nothing.
2. In the case of UseOldStylePreUpdate=false, ClaimCenter calls the IPreUpdateHandler plugin on the
commit bundle.
• In any case, any ClaimCenter processing of the commit bundle excludes the Closed and Reopened
validation rules.

Subelements of <array>
The <array> element contains the following subelements:

<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 227 for more information.
fulldescription See “<fulldescription>” on page 213.
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 225 for more information.
tag See “<tag>” on page 218.

<column>
The <column> element defines a single-value field in the entity.

202 chapter 15 The ClaimCenter data model

 Configuration Guide 9.0.5

Note: For a discussion of <column-override>, see “Working with attribute and element overrides” on page 239
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 column. None
This attribute is applicable only for integer columns, and only for implementations
where ClaimCenter 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 aut
oincrement column per table.

columnName Optional. If specified, ClaimCenter uses this value as the column name of the None
corresponding database column. If you do not specify a columnName value, then
ClaimCenter 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
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.
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.
createhistogram Whether to create a histogram on the column during an update to the database false
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_to
ols command.
See also
• “Working with attribute and element overrides” on page 239
• System Administration Guide
default Default value given to the field during new entity creation. None
deprecated If true, then ClaimCenter marks the item as deprecated in the Data Dictionary and false
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 object subelements” on page 199.
desc A description of the purpose and use of the field. None
exportable Unused.
getterScriptability See “Data objects and scriptability” on page 180 for information. all

ignoreforevents If you change (or add, or remove) an entity X that does not generate events, then false
ClaimCenter searches for all event-generating entity instances that specify X. If
ClaimCenter finds any of these event-generating entity instances, it generates Chan
ged events for those entity instances.
To determine what entities reference a non-event-generating entity, ClaimCenter
examines the foreign keys and arrays that point to the entity. However, if you set i
gnoreForEvents to true on an entity that references the non-event-generating

Data object subelements 203

 Configuration Guide 9.0.5

<column> attribute Description Default

entity, then ClaimCenter 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 can contain a true
column mapping to the field.
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. The name of the column on the table and the field, or property, on the None
entity. ClaimCenter uses this value as the column name unless you specify a colum
nName attribute. Use this name to access the column in data views, rules, and other
areas within ClaimCenter.
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-populates the false
staging table during import.
IMPORTANT If set to true, do not attempt to populate the table yourself as the
loader import process overwrites this table.
required Whether the column is required to be non-null upon initial construction of false
instances of the entity. See the Gosu Reference Guide.
scalable Whether this value scales as the effective and expired dates change. This attribute false
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 180 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 152
• Globalization Guide
type Required. Data type of the column, or field. In the base configuration, Guidewire None
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.

204 chapter 15 The ClaimCenter data model

 Configuration Guide 9.0.5

<column> attribute Description Default

Each metadata definition also defines the value type for that data type. The value
type determines how ClaimCenter treats that value in memory.
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 java.lang.Boolean. Similarly, the data type varchar
has a value type of java.lang.String.
The datetime data type is a special case. ClaimCenter persists this data type in the
application database using the database data type TIMESTAMP. This corresponds to
the value type java.util.Date. In other words:
• ClaimCenter represents a column whose type is datetime in memory as
instances of java.util.Date.
• ClaimCenter stores this type of value in the database as TIMESTAMP.
See also
• “Data types” on page 281
• “Customizing base configuration data types” on page 285
• “Define a new data type” on page 289

Subelements of <column>
The <column> element contains the following subelements:

<column> subelement Description Default

columnParam See <columnParam> subelement. None
fulldescription See “<fulldescription>” on page 213. None
localization See “<localization> subelement” on page 207. None
tag See “<tag>” on page 218. 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 mediumtext.dti. 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 Account.eti in PolicyCenter, illustrates how to use this subelement to define certain
column parameters.

<?xml version="1.0"?>
<entity xmlns="http://guidewire.com/datamodel"
desc="An account is ..."
entity="Account"
...
table="account"
type="retireable">

<column> 205
 Configuration Guide 9.0.5

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

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.
currencyProperty Name of a property on the owning entity that returns the currency for this column.
encryption Whether ClaimCenter 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 ClaimCenter 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
currency amount column.
size Integer size value for columns of type TEXT and VARCHAR. This parameter specifies the
maximum number of characters, not bytes, that the column can hold.
WARNING The database upgrade utility automatically detects definitions that lengthen or
shorten a column. For shortened columns, the utility assumes that you wrote a version check or
otherwise 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 ClaimCenter automatically removes leading and
trailing white space from the data value.
validator The name of a ValidatorDef in fieldvalidators.xml. See “<ValidatorDef>” on page 297.

206 chapter 15 The ClaimCenter data model

 Configuration Guide 9.0.5

See also
• See “Overriding data type attributes” on page 240 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.

Attributes of <localization>
The <localization> element contains the following attributes:

<localization> attribute Description Default

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 is marked as OverlapTable for archiving. false
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 ClaimCenter data model does not permit circular foreign keys reference, because ClaimCenter 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 ClaimCenter 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 ClaimCenter 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, ClaimCenter 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
ClaimCenter 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.

<column> 207
 Configuration Guide 9.0.5

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.
In ClaimCenter, 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, ClaimCenter 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, ClaimCenter 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 ClaimCenter follows the ForeignEntityID on the row.

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 ClaimCenter 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 ClaimCenter 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 ClaimCenter 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 ClaimCenter from determining a safe order for committing the entity instances in a circular
reference to the database.
Use an edge foreign key instead of 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 ClaimCenter data model

 Configuration Guide 9.0.5

<edgeForeignKey> attribute Description Default

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 mainte
nance_tools command.
See also
• “Working with attribute and element overrides” on page 239
• System Administration Guide
deprecated If true, then ClaimCenter marks the item as deprecated in the Data Dictionary false
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 object subelements” on page 199.
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 one, then None
ClaimCenter creates one automatically using the edgeTableName with the first
letter capitalized.
edgeTableName Required. The name of the edge, or join array, table to create. None
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 180 for information. all

ignoreforevents If you change (or add, or remove) an entity X that does not generate events, false
then ClaimCenter searches for all event-generating entity instances that
specify X. If ClaimCenter finds any of these event-generating entity instances,
it generates Changed events for those entity instances.
To determine what entities reference a non-event-generating entity,
ClaimCenter examines the foreign keys and arrays that point to the entity.
However, if you set ignoreForEvents to true on an entity that references the
non-event-generating entity, then ClaimCenter 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.
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 ClaimCenter 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

<edgeForeignKey> 209
 Configuration Guide 9.0.5

<edgeForeignKey> attribute Description Default

nullok Whether the column can contain null values. This value is meaningless for ed true
geForeignKey objects.

overlapTable Whether the edge entity is marked OverlapTable for archiving. false

overwrittenInStagingTable Internal. If true and the edge table 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 yourself, as
the loader import process overwrites this table.
setterScriptability See “Data objects and scriptability” on page 180 for information. all

soapnullok Unused.

Subelements of <edgeForeignKey>
<edgeForeignKey> subelement Attributes Description
fulldescription None See “<fulldescription>” on page 213.
tag None See “<tag>” on page 218.

<events>
If the <events> element appears within an entity, it indicates that the entity raises events. Usually, the code indicates
the standard events (add, change, and remove) by default. If the <events> element does not appear in an entity, that
entity does not raise any events. You cannot modify the set of the events associated with a base entity through
extension. However, you can add additional events to a base entity through extension, even if that entity already
contains a set of predefined 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: ClaimCenter 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> subelement Description

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 attributes are self-explanatory. The <event> element requires each one.

210 chapter 15 The ClaimCenter data model

 Configuration Guide 9.0.5

<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, ClaimCenter uses this value as the column name of the None
corresponding database column. If you do not specify a columnName value,
then ClaimCenter 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 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
column name. For example, for a foreign key with name Claim, set the column
Name to ClaimID.
Guidewire does not require that you use an ID suffix on names of foreign key
columns. However, Guidewire strongly recommends that you adopt this
practice to help you analyze the database and identify foreign keys.
IMPORTANT All column names on a table must be unique in that table.
Otherwise, 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 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 mainte
nance_tools command.
See also
• “Working with attribute and element overrides” on page 239
• System Administration Guide
deprecated If true, then ClaimCenter marks the item as deprecated in the Data Dictionary false
and places a Deprecated annotation on it in the Guidewire Studio API
Reference.
If you deprecate an item, use the description to explain why.

Data object subelements 211

 Configuration Guide 9.0.5

<foreignkey> attribute Description Default

For more information, see “Data object subelements” on page 199.
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
object.
exportable Unused.
exportasid Unused.
fkentity Required. The entity to which this foreign key refers. None
getterScriptability See “Data objects and scriptability” on page 180 for information. all

ignoreforevents If you change (or add, or remove) an entity X that does not generate events, false
then ClaimCenter searches for all event-generating entity instances that
specify X. If ClaimCenter finds any of these event-generating entity instances,
it generates Changed events for those entity instances.
To determine what entities reference a non-event-generating entity,
ClaimCenter examines the foreign keys and arrays that point to the entity.
However, if you set ignoreForEvents to true on an entity that references the
non-event-generating entity, then ClaimCenter 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.
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 false
foreign 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 true
contain 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
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
because 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.

212 chapter 15 The ClaimCenter data model

 Configuration Guide 9.0.5

<foreignkey> attribute Description Default

setterScriptability See “Data objects and scriptability” on page 180 for information. all

soapnullok Unused.
triggersValidation Whether changes to the entity referred to by this foreign key trigger false
validation.

Subelements of <foreignkey>
The <foreignkey> element contains the following subelements.

<foreignkey> subelement Attributes Description

fulldescription None See “<fulldescription>” on page 213.
tag None See “<tag>” on page 218.

<fulldescription>
ClaimCenter 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 213 subelement. ClaimCenter 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="gw.api.domain.financials.CostAdapter">
...
</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="gw.lob.ba.financials.BACostAdapter" />
...
</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:

Data object subelements 213

 Configuration Guide 9.0.5

Delegate / Adapter Relationship Example

Cost CostAdapter
Delegate Interface

BACost BACostAdapter
Delegate Entity Interface
Implementor / Implementor
Indirect Interface
Implementor

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 ClaimCenter 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="gw.lob.ba.financials.BACostMethods"

214 chapter 15 The ClaimCenter data model

 Configuration Guide 9.0.5

impl="gw.lob.ba.financials.BACostMethodsImpl"/>
</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 = cost.Coverage
var state = cost.State
var vehicle = cost.Vehicle

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.

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 ClaimCenter to create an index on the physical database table. This index is in
addition to those indexes that ClaimCenter 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, ClaimCenter frequently searches non-retired claims for one with a particular claim number. Therefore,
the Claim entity defines an index containing both the Retired and ClaimNumber fields. However, another common
search uses just ClaimNumber. Since that field is already part of another index, a separate index containing only
ClaimNumber 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, ClaimCenter 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.

Data object subelements 215

 Configuration Guide 9.0.5

<index> attribute Description Default

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
subtype 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, ClaimCenter 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

verifyInLoader If true, then ClaimCenter 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> subelement Description Default

forceindex Use to force ClaimCenter 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 indexes as being redundant. In some cases, ClaimCenter 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> None
elements to 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, foreignke
y, 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.

216 chapter 15 The ClaimCenter data model

 Configuration Guide 9.0.5

Note: ClaimCenter 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 ClaimCenter deletes the entity to which the <onetoone> element points if false
you delete this entity.
deprecated If true, then ClaimCenter 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.
For more information, see “Data object subelements” on page 199.
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 180 for information. all

ignoreForEvents If the ignoreForEvents attribute is false, ClaimCenter regards the <onetoone> element false
as being present when generating events. In this case, the product does not generate
events for the entity to which the fkentity attribute points.
If the ignoreForEvents attribute is true, ClaimCenter ignores the presence of the <oneto
one> element when generating events. This behavior results in ClaimCenter generating
events for the entity to which the fkentity attribute points.

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 <entit
y> and <array> elements. Although they share the same name, the two ignoreForEven
ts 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 ClaimCenter deletes the linked object as well.
• If you update the object pointed to by the <onetoone> element, then ClaimCenter
considers the owning object updated as well.
setterScriptability See “Data objects and scriptability” on page 180 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 213. None
tag See “<tag>” on page 218. None

Data object subelements 217

 Configuration Guide 9.0.5

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

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. This allows you to define your own metadata to add to the data
model.

218 chapter 15 The ClaimCenter data model

 Configuration Guide 9.0.5

The file ClaimCenter/modules/configuration/config/metadata/tags.lst specifies the list of valid tags that

you can use. To add a new tag, edit this file, and then add the tag name on a new line.
At most one of each tag can exist on a field at one time. Extensions can add, but not override, tags on existing fields.
To retrieve this data at run time, use the DatamodelTags property on IEntityPropertyInfo, the metadata object for
entity properties. For example:

// On the entity info metadata, get the metadata for the properties on this entity.
// This type is an iterator of objects of type IEntityPropertyInfo.
var props = User.Type.EntityProperties

// Get the property info object by its name.

var theProp = props.toList().firstWhere( \ propertyInfo -> propertyInfo.ColumnName == "Language")

// Get the data model tags, which has the type java.util.Map
var myTags = theProp.DatamodelTags

// Get a specific tag

var theTag = myTags["NameOfTag"]

Attributes of <tag>
The <tag> element contains the following attributes.

<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 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, ClaimCenter uses this value as the column name of the None
corresponding database column. If you do not specify a columnName value, then
ClaimCenter 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
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.
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.
createhistogram Whether to create a histogram on the column during an update to the database false
statistics.

Data object subelements 219

 Configuration Guide 9.0.5

<typekey> attribute Description Default

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_tool
s command.
See also
• “Working with attribute and element overrides” on page 239
• System Administration Guide
default The default value given to the field during new entity creation. None
deprecated If true, then ClaimCenter 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 object subelements” on page 199.
desc A description of the purpose and use of the field. None
exportable Unused.
getterScriptability See “Data objects and scriptability” on page 180 for information. None
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 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 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 180 for information. None
soapnullok Unused.
typefilter The name of a filter associated with the typelist. See “Static filters” on page 314 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> subelement Description Default

keyfilters Defines one or more <keyfilter> elements. There can be at most one <keyfilters> None
element in an entity. See “Dynamic filters” on page 319 for additional information.
fulldescription See “<fulldescription>” on page 213. None

220 chapter 15 The ClaimCenter data model

 Configuration Guide 9.0.5

<typekey> subelement Description Default

tag See “<tag>” on page 218. None

Subelements of <keyfilters>
The <keyfilters> element contains the following subelements.

<keyfilters> subelement Description Default

<keyfilter> Specifies a keyfilter to use to filter the typelist. This element requires the <name> None
attribute. 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.

Data object subelements 221

 Configuration Guide 9.0.5

222 chapter 15 The ClaimCenter 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 223
“Subtype mapping associative arrays” on page 225
“Typelist mapping associative arrays” on page 227

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.
ClaimCenter 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

Working with associative arrays 223

 Configuration Guide 9.0.5

State typekey index Maps to...

Capital[State.TC_AZ] Phoenix

Capital[State.TC_AR] Little Rock

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 ClaimCenter 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 225
Typelist mapping Typelist Typekey field on the entity “Typelist mapping associative arrays” on page 227

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→Claim.eti), you see
the following XML (simplified for clarity):

<entity xmlns="http://guidewire.com/datamodel"
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>

224 chapter 16 Working with associative arrays

 Configuration Guide 9.0.5

See also
• “Subtype mapping associative arrays” on page 225.
• “Typelist mapping associative arrays” on page 227.

Scriptability and associative arrays

It is possible to set the following attributes on each <link-association> and <array-association> element:
• hasGetter
• hasSetter
For example:

<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, ClaimCenter defaults to hasGetter="true".
See also
• “Data objects and scriptability” on page 180.

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 = gw.transaction.Transaction.getCurrent()

gw.transaction.Transaction.runWithNewBundle(\ 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 ClaimCenter 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.
To determine the complete list of subtypes on an object, consult the ClaimCenter 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 using subtype mapping

To retrieve an array value through subtype mapping, use the following syntax:

base-entity.subtype-map.property

Overview of associative arrays 225

 Configuration Guide 9.0.5

Each field has the following meanings:

Field Description
base-entity The base object on which the associative array exists, for example, 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
contains the following properties (among others):
• ClaimMetricCategory
• DispalyTargetValue
• DisplayValue

Note: To see a list of subtypes for any given object, consult the ClaimCenter Data Dictionary. To determine the
list of fields (properties) on an object, again consult the Data Dictionary.

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.

uses gw.transaction.Transaction
uses gw.api.database.Query

var clm = gw.api.database.Query.make(Claim).compare("ClaimNumber", Equals,

"235-53-365870").select().getAtMostOneRow()

print("AllEscalatedActivitiesClaimMetric\tClaim Metric Category = "

+ clm.AllEscalatedActivitiesClaimMetric.ClaimMetricCategory.DisplayName)
print("AllEscalatedActivitiesClaimMetric\tDisplay Value = "
+ clm.AllEscalatedActivitiesClaimMetric.DisplayValue)
print("AllEscalatedActivitiesClaimMetric\tReach Yellow Time = "
+ clm.AllEscalatedActivitiesClaimMetric.ReachYellowTime)

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 gw.api.database.Query
uses gw.transaction.Transaction

var todaysDate = java.util.Date.CurrentDate

var clm = gw.api.database.Query.make(Claim).compare(Claim#ClaimNumber, Equals,
"235-53-365870").select().AtMostOneRow

226 chapter 16 Working with associative arrays

 Configuration Guide 9.0.5

//Query result is read-only, need to get current bundle and add object to bundle
Transaction.runWithNewBundle(\bundle -> {
if (clm != null) {
clm = bundle.add(clm)
}
}, "su")

print("AllEscalatedActivitiesClaimMetric\tReach Yellow Time = "

+ clm.AllEscalatedActivitiesClaimMetric.ReachYellowTime)
clm.AllEscalatedActivitiesClaimMetric.ReachYellowTime = todaysDate

print("\nAfter modifying the ReachYellowTime value...\n")

print("AllEscalatedActivitiesClaimMetric\tReach Yellow Time = "
+ clm.AllEscalatedActivitiesClaimMetric.ReachYellowTime)

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

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="http://guidewire.com/datamodel"
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
Typelist mapping associative arrays 227
 Configuration Guide 9.0.5

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="http://guidewire.com/datamodel"
...
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.

Working with array values using typelist mapping

To retrieve an array value through typelist mapping, use the following syntax:

entity.typecode.property

Each field has the following meaning:

Field Description
entity The object on which the associative array exists, for example, 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 C
laimMetricCategory typelist).

property A field or property on the array object. For example, the ClaimMetric object contains the following properties
(among others):
• ReachRedTime
• ReachYellowTime
• Skipped

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 gw.api.database.Query
uses gw.transaction.Transaction

var clm = Query.make(Claim).compare(Claim#ClaimNumber, Equals, "235-53-365870").select().AtMostOneRow

for (time in clm.OverallClaimMetrics) {
print(time.Subtype.DisplayName + ": ReachYellowTime = " + time.ReachYellowTime)
}

228 chapter 16 Working with associative arrays

 Configuration Guide 9.0.5

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 gw.api.database.Query
uses gw.transaction.Transaction

var clm = gw.api.database.Query.make(Claim).compare(Claim#ClaimNumber, Equals,

"235-53-365870").select().AtMostOneRow
var thisReserveLine = clm.ReserveLines.first()

print(thisReserveLine)
print(thisReserveLine.cashout.CreateTime)

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. As 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 gw.transaction.Transaction
uses gw.api.database.Query

var todaysDate = java.util.Date.CurrentDate

var thisClaim = Query.make(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

Transaction.runWithNewBundle(\bundle -> {
if (thisClaim != null) {
thisClaim = bundle.add(thisClaim)
}
}, "su")

//Print out the current values for the ClaimMetric.ReachYellowTime field on each subtype
for (color in thisClaim.OverallClaimMetrics) {
print("Subtype - " + color.Subtype.DisplayName + ": ReachYellowColor = " + color.ReachYellowTime)
}

print("\nAfter modifying the values...\n")

//Modify the ClaimMetric.ReachYellowColor value and print out the new values
for (color in thisClaim.OverallClaimMetrics) {

Typelist mapping associative arrays 229

 Configuration Guide 9.0.5

color.ReachYellowTime = todaysDate
print("Subtype - " + color.Subtype.DisplayName + ": ReachYellowColor = " + color.ReachYellowTime)
}

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

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.

230 chapter 16 Working with associative arrays

 Configuration Guide 9.0.5

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.

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.
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 225
• “Typelist mapping associative arrays” on page 227

Working with array values using constant mapping

To retrieve a member of the Role array, use the following syntax:

base-entity.defined-property

Each field has the following meanings:

Field Description
base-entity The base object on which the associative array exists, for example, 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> attributes Description Default

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 constant map on the same field. In this case, you need to use the propertyPrefi
x 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.

Constant mapping associative arrays 231

 Configuration Guide 9.0.5

<constant-map> subelements Description

property Key-value pair in the map.

232 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 233
“Defining a new data entity” on page 236
“Extending a base configuration entity” on page 238
“Working with attribute and element overrides” on page 239
“Extending the base data model: examples” on page 242
“Removing objects from the base configuration data model” on page 253
“Deploying data model changes to the application server” on page 257

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 ClaimCenter releases to modify the base
definitions without affecting your extensions, thus preserving an upgrade path.

Modifying the base data model 233

 Configuration Guide 9.0.5

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 object subelements” on page 199.
• Create a new entity with custom fields using any of the entity types listed in “Base ClaimCenter data objects” on
page 181.
• 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.
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 169 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.

234 chapter 17 Modifying the base data model

 Configuration Guide 9.0.5

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 177 for more information on these data types.
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 249
• “The archive domain graph and reference data” on page 327

What happens if you change the data model?

During server start up, ClaimCenter analyzes the metadata for changes since the last build. If you have made
extensions, the application merges this into the working ClaimCenter data model, which is the composite of the base
entities and your extensions.
After merging the base data model with any extensions, ClaimCenter compares the startup layout to the physical
schema in the current database. (Each ClaimCenter 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, ClaimCenter refuses to start until the two are synchronized.

WARNING Do not directly modify the physical database that ClaimCenter uses. Only make changes to the
ClaimCenter 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
• ClaimCenter data model

Planning changes to the base data model 235

 Configuration Guide 9.0.5

• Field encryption
• Typelists
In addition to these generic changes, the following specific localization changes trigger a database upgrade:
• In file localization.xml, 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 collations.xml, any change to the source definition of the DBJavaClass definition forces a database
upgrade at application server startup.

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

ClaimCenter 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.

236 chapter 17 Modifying the base data model

 Configuration Guide 9.0.5

Data entity More information

<delegate> “Delegate data objects” on page 182
<entity> “Entity data objects” on page 185
<extension> “Extension data objects” on page 190
<nonPersistentEntity> “Non-persistent entity data objects” on page 191

<subtype> “Subtype data objects” on page 193

<viewEntity> “View entity data objects” on page 195
<viewEntityExtension> “View entity extension data objects” on page 198

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
object subelements” on page 199.
5. Deploy your changes to the application server. You must redeploy the application after you make any change
to the Guidewire ClaimCenter data model. See “Deploying data model changes to the application server” on
page 257 for details.

Default properties on a new entity

The following table contains the entity properties that ClaimCenter 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 and retireable entity
types.
CreateUser User who created the object. This property is only applicable
for editable and retireable entity types.
LoadCommandID Identifier for the command that loaded the object through the
staging tables. This property is included for entities where the
loadable attribute has a value of true.

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

Defining a new data entity 237

 Configuration Guide 9.0.5

Property Description
property has a zero value. The Retired property is only
applicable for 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 retireable entity types.
UpdateTime Timestamp when the object was last updated. This property is
only applicable for editable and retireable entity types.
UpdateUser User who last updated the object. This property is only
applicable for editable and retireable entity types.

Note: New entities have constant properties that the ClaimCenter 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 .

Extending a base configuration entity

You define all of your entity-type extensions in files that end with the .etx extension. You do this through
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 simply
overwrite a Guidewire extension with your own extension without understanding the full implications of the
change.

ClaimCenter extensions allow you to add new fields to the base data entities. You can add custom fields to
extendable entities only. Not all entities are extendable, but most of the important business entities such as Claim,
User, Contact, and others are extendable. (You can determine if an entity is extendable 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, then edit that file to extend the entity.
• If an extension file for the entity does not exist, then create the new extension file and populate it accordingly.
Do not attempt to create multiple extension files for the same entity. You can reference a given existing entity in
only one extension (.etx or .ttx) file. If you attempt to extend (or define) the same entity in multiple files, then the
ClaimCenter application server generates an error at application start up. In all cases, Studio refuses to create entity
or extension files with the same duplicate name.

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.

238 chapter 17 Modifying the base data model

 Configuration Guide 9.0.5

Procedure
1. In the Studio Project tool window, navigate to configuration→config→Metadata→Entity, and then locate the entity
that you want to extend.
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 ClaimCenter data model. See
“Deploying data model changes to the application server” on page 257 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
type

<edgeForeignKey-override> desc
extractable

Working with attribute and element overrides 239

 Configuration Guide 9.0.5

Override element Attributes or elements that you can override

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>

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
java.lang.String, the data type in the attribute override value must also have the java.lang.String value type.
While longtext would be an acceptable data type, BigDecimal would not.

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 Contact.eti):

<column createhistogram="true"
desc="Tax ID for the contact (SSN or EIN)."
name="TaxID"
type="ssn"/>

To encrypt the contents of this column (a reasonable course of action), create a Contact extension (Contact.etx)
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>

240 chapter 17 Modifying the base data model

 Configuration Guide 9.0.5

See also
• See <columnParam> subelement 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 ClaimCenter 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 Account.eti.

<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 Account.etx file.
a. Find the Account.eti 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 Account.etx file and places it in the configuration→config→Extensions→Entity folder.
2. Populate Account.etx with the following:

<?xml version="1.0"?>
<extension xmlns="http://guidewire.com/datamodel" entityName="Account">
<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.

Overriding data type attributes 241

 Configuration Guide 9.0.5

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: examples

As described in “Defining a new data entity” on page 236, you can define entirely new custom entities that become
part of the ClaimCenter 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. ClaimCenter makes no distinction between the usage of base
entities and custom entities.
This topic describes the following:
• “Creating a new delegate object” on page 243
• “Extending a delegate object” on page 245
• “Defining a subtype” on page 248
• “Defining a reference entity” on page 249
• “Define an entity array” on page 250
• “Extending an existing view entity” on page 252

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

242 chapter 17 Modifying the base data model

 Configuration Guide 9.0.5

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 ClaimCenter. 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.

Related concepts
“Creating a new delegate object” on page 243
“Extending a delegate object” on page 245
“Defining a subtype” on page 248
“Defining a reference entity” on page 249
“Implementing a many-to-many relationship between entity types” on page 251
“Extending an existing view entity” on page 252

Related tasks
“Define an entity array” on page 250

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 Delegate Define the delegate entity using the <delegate> element. “Step 1: Create the delegate object”
Object on page 243
Step 2: Define the Delegate Create a Gosu enhancement to provide any functionality “Step 2: Define the delegate
Functionality that you want to expose on your delegate. functionality” on page 244
Step 3: Add the Delegate to Use the <implementsEntity> element to associate the “Step 3: Add the delegate to the
the Parent Entity delegate with the parent entity. parent entity” on page 244
Step 4: Deploy your Data Deploy your data model changes. You may need to “Step 4: Deploy your data model
Model Changes regenerate any Java API file or web service WSDL files changes” on page 245
after data 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
object subelements” on page 199.

Extending the base data model: examples 243

 Configuration Guide 9.0.5

Next steps
After completing this task, complete “Step 2: Define the delegate functionality” on page 244.

Step 2: Define the delegate functionality

Before you begin

Before beginning this task, complete “Step 1: Create the delegate object” on page 243.

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 In the base configuration, Guidewire provides a Java class implementation for each delegate to provide
implementation the 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 enhancement You must implement the delegate functionality through a Gosu enhancement that defines any
implementation functionality associated with the fields on the delegate. By providing the name of the delegate entity to
the enhancement as you create it, you inform Studio that you are adding functionality for that particular
delegate. Studio automatically 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 MyDelgateEnhancement.
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 244.

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 244.

244 chapter 17 Modifying the base data model

 Configuration Guide 9.0.5

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 .
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 245.

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 244.

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 257 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 data objects” on page 182 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 ClaimCenter:
• <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 ClaimCenter, you can extend the following base configuration delegates:
• CopyOnWriteMetricLimitDelegate
• DecimalMetricDelegate
• DecimalMetricLimitDelegate
• EFTDataDelegate
Creating a new delegate object 245
 Configuration Guide 9.0.5

• ISOMatchReport
• ISOReportable
• IntegerMetricDelegate
• IntegerMetricLimitDelegate
• MetricLimitTimeDelegate
• MoneyMetricDelegate
• MoneyMetricLimitDelegate
• PercentMetricDelegate
• PercentMetricLimitDelegate
• TimeBasedMetricDelegate
• TripAccommodationDelegate
• TripExpenseCancellationDelegate
• TripExpenseDelegate
• TripSegmentDelegate
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>. ClaimCenter 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 243.

EFT delegate example

To illustrate, in the base ClaimCenter configuration, ClaimCenter provides a delegate named EFTDataDelegate to
use with Electronic Funds Transfer (EFT) data.
ClaimCenter defines the following EFTDataDelegate-related files in the base ClaimCenter configuration:

File Location Description

EFTDataDelegate.eti metadata/cc Defines delegate EFTDataDelegate.

EFTDataDelegate.etx extensions Extends EFTDataDelegate and adds additional fields and behaviors.
EFTData.eti metadata/cc Defines an EFTData object that implements EFTDataDelegate.

Check.eti metadata/cc Creates the Check object, which implements EFTDataDelegate.

Contact.etx extensions Extends the Contact entity and adds an array of EFTData objects.

246 chapter 17 Modifying the base data model

 Configuration Guide 9.0.5

The following topics describe these files.

The EFT data delegate

Guidewire defines the EFTDataDelegate in file EFTDataDelegate.eti. It looks similar to the following.

<delegate
xmlns="http://guidewire.com/datamodel"
extendable="true"
javaClass="com.guidewire.cc.domain.contact.EFTDataDelegate"
name="EFTDataDelegate">
<fulldescription>
<![CDATA[Delegate used by Contact and Check to store Electronic funds transfer data]]>
</fulldescription>
</delegate>

Notice that, in this case, Java class com.guidewire.cc.domain.contact.EFTDataDelegate implements the plugin
functionality. In actual practice, if you define your own delegate, you need to implement the delegate functionality
in Gosu code.
Also, notice that this delegate is extendable.

The EFT data delegate extension

Guidewire extends the definition of the EFTDataDelegate entity in file EFTDataDelegate.etx.

<extension
xmlns="http://guidewire.com/datamodel"
entityName="EFTDataDelegate">
<column
desc="The name on the account"
name="AccountName"
type="varchar">
<columnParam name="size" value="100"/>
</column>
<column
desc="The name of the bank"
name="BankName"
type="varchar">
<columnParam name="size" value="100"/>
</column>
<typekey
desc="The type of bank accout e.g. checking, savings etc"
name="BankAccountType"
typelist="BankAccountType"/>
<column
desc="The bank account number"
name="BankAccountNumber"
type="varchar">
<columnParam name="size" value="20"/>
<columnParam name="encryption" value="true"/>
</column>
<column
desc="The routing number is a nine digit bank code used in the United States"
name="BankRoutingNumber"
type="positiveinteger"/>
<column
desc="Indicates if this is the primary EFT record for the contact"
name="IsPrimary"
type="bit"/>
</extension>

Notice that the delegate extension adds a number of fields to the delegate that are accessible to any entity that
implements this delegate, for example, AccountName and BankAccountType, among others.

EFTData implements EFTDataDelegate

In the base ClaimCenter configuration, the EFTData entity implements the EFTDataDelegate delegate. The
following abbreviated code illustrates this.

Extending a delegate object 247

 Configuration Guide 9.0.5

<!-- Entity implementing the delegate -->

<entity name="EFTData">
<implementsEntity name=" EFTDataDelegate "/>
<foreignkey columnName="Contact"/>
</entity>

Check implements EFTDataDelegate

In the base ClaimCenter configuration, the Check entity implements EFTDataDelegate directly, in a one-to-one
relationship. The following abbreviated code illustrates this.

<!-- 1:1 relatioship -->

<extension entityName="Check">
<implementsEntity name=" EFTDataDelegate "/>
</extension>

Contact contain array of EFTData objects

In the base ClaimCenter configuration, the Contact entity adds an array of EFTData objects. This is a one-to-many
relationship. The following abbreviated code illustrates this.

<!-- 1:m relationship -->

<extension entityName="Contact">
<array arrayentity="EFTData" />
</extension>

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.
ClaimCenter 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. ClaimCenter 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 ClaimCenter bases the subtype entity). For a description of required and
optional attributes, see “Subtype data objects” on page 193.
Within the <subtype> definition, you must define its fields and other elements. For a description of the elements
you can include, see “Data object subelements” on page 199.

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.

248 chapter 17 Modifying the base data model

 Configuration Guide 9.0.5

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. ClaimCenter
automatically adds the new Inspector_Ext type to the Contact typelist. This is true, even though ClaimCenter
marks the Contact typelist as final.
To see this change:
• To see this change in the ClaimCenter 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 ClaimCenter 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 ClaimCenter 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>

Extending the base data model: examples 249

 Configuration Guide 9.0.5

See also
•

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 Contact.ContactAddresses field, which is an array of
ContactAddresses entities for each Contact data object.
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 ClaimCenter 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. ClaimCenter 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 173
defining a new entity “Defining a new data entity” on page 236
defining an array field “<array>” on page 200
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 Claim 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>

250 chapter 17 Modifying the base data model

 Configuration Guide 9.0.5

To make this example useful, suppose that you now add this array field to the Claim entity. It is possible that a
Claim 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 Claim extension file already exists, use CTRL-N to search for Claim.etx.
• 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 Claim.etx.

<extension entityName="Claim" ...>

...
<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 Claim:

<entity entity="ExampleRetireableArrayEntityExt" table="exampleretarray" ... >

...
<foreignkey name="ClaimID" fkentity="Claim" desc="FK back to Claim" exportable="false"/>
</entity>

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 Claim and Contact entity
types.
• It first creates a versionable entity, ClaimContact, by setting the type attribute to retireable.
• It then defines foreign keys to Claim and Contact.
• Finally, it adds indexes to these foreign keys.
The code looks similar to the following:

<entity xmlns="http://guidewire.com/datamodel"
entity="ClaimContact"
table="claimcontact"
type="retireable"
desc="Join entity modeling many-to-many relationship between Claim and Contact entities">
<foreignkey columnName="ClaimID"
fkentity="Claim"
name="Claim"
nullok="false"/>
<foreignkey columnName="ContactID"
fkentity="Contact"
name="Contact"
nullok="false"/>
<index name="claimcontacts" unique="true">
<indexcol keyposition="1" name="ClaimID"/>
<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:
Extending the base data model: examples 251
 Configuration Guide 9.0.5

<extension xmlns="http://guidewire.com/datamodel" entityName="Claim">

<array arrayentity="ClaimContact"
desc="All the ClaimContact entities related to Claim."
name="ClaimContacts"/>
</extension>

This provides an array of ClaimContact entities on Claim.

Extending an existing view entity

Guidewire uses viewEntity entities to improve performance for list view pages in rendering the ClaimCenter
interface. (See “View entity data objects” 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 Activity.etx to determine if one exists. (Use Ctrl+N to open the
search dialog.)
Add the following to Activity.etx:

<extension entityName="Activity">
...
<column type="bit"
name="validExt"
default="true"
nullok="true"
desc="Sample bit extension, with a default value."/>
...
</extension>

Next, search for ActivityDesktopView.etx. Suppose that you do not find this file, but you see that
ActivityDesktopView.eti exists. As this is part of the base configuration, you cannot modify this declaration file.
However, find the highlighted file in Studio and select New→Entity Extension from the right-click submenu. This
opens a mostly blank file.
Enter the following in ActivityDesktopView.etx:

<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 currency column

If you create or extend a view entity that references a column that is of type="currencyamount", you must handle
the view entity extension in a particular manner. If the view entity extension references a currencyamount column,
then you also need to define the currencyProperty that the original column definition specifies on the view entity
as well.
Suppose, for example, that in ClaimCenter, you extend the PriorClaimView view entity by adding an
OpenReserves field that has a path reference to ClaimRpt.OpenReserves:

<viewEntityColumn name="OpenReserves" path="ClaimRpt.OpenReserves"/>

Looking at the definition of ClaimRpt, you see the following:

252 chapter 17 Modifying the base data model

 Configuration Guide 9.0.5

<column default="0" desc="The open reserves." name="OpenReserves" nullok="false" type="currencyamount">

<columnParam name="currencyProperty" value="ClaimCurrency"/>
</column>

Notice that ClaimRpt.OpenReserves is of type="currencyamount". Thus, if you extend PriorClaimView with

this field as indicated, you also need to add the following to PriorClaimView.etx:

<viewEntityTypekey name="ClaimCurrency" path="Currency"/>

By defining a ClaimCurrency column on the view entity, the view entity loads the claim currency as a part of the
view entity. This makes the claim currency available to the currencyamount column and ClaimCenter avoids
loading the whole entity while dereferencing Claim.Currency.
The complete extension of the PriorClaimView view entity for this example is as follows:

<viewEntityExtension entityName="PriorClaimView">
<viewEntityColumn name="OpenReserves" path="ClaimRpt.OpenReserves"/>
<viewEntityTypekey name="ClaimCurrency" path="Currency"/>
</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:

Object to remove Location File More information

Base configuration entity extensions .eti “Remove a base extension entity” on page 254

Base configuration extension extensions .etx “Remove an extension to a base object” on page 254

Guidewire recommends that you review the material in “Implications of modifying the data model” on page 255
before you remove an object from the data model.

IMPORTANT ClaimCenter 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
ClaimCenter 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 255

Related tasks
“Remove a base extension entity” on page 254
“Remove an extension to a base object” on page 254

Removing objects from the base configuration data model 253

 Configuration Guide 9.0.5

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.
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="http://guidewire.com/datamodel" 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.

254 chapter 17 Modifying the base data model

 Configuration Guide 9.0.5

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 Contact.etx 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="http://guidewire.com/datamodel" 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 ClaimCenter 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.
This topic covers the following:
• “Does removing an extension make sense?” on page 255
• “Writing SQL for extension removal” on page 256
• “Strategies for handling extension removal” on page 256
• “Troubleshooting modifications to the data model” on page 257

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, ClaimCenter checks for configuration changes, such as modified extensions, that require a
database upgrade. Until the database reflects the underlying configuration, ClaimCenter refuses to start.

Removing objects from the base configuration data model 255

 Configuration Guide 9.0.5

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. ClaimCenter 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.

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

Suppose that you have a development environment with multiple developers all using the same database instance.
Before modifying the data model, first you need to communicate with your team to make them aware of what you
plan to do. A good way to communicate your intentions is to provide the team with the SQL you intend to execute
along with a list of impacted references files. After communicating with your team, follow a process similar to the
following if removing a data object:
1. Remove the extension entity or entity extension using the methods outlined in the following sections:
• “Remove a base extension entity” on page 254
• “Remove an extension to a base object” on page 254
2. Remove any references to the object in other parts of your configuration. If you do not remove these
references, ClaimCenter displays error messages during server start-up.
3. Check in your changes.
256 chapter 17 Modifying the base data model
 Configuration Guide 9.0.5

4. Open an SQL command line appropriate to your server. For example, if you use Microsoft SQL Server, then
open a query through the SQL Enterprise Manager.
5. Run your SQL statement to remove your extension.
6. Regenerate the toolkit.
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:

ccx_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.
If necessary (and it is almost always necessary if you change the data model), ClaimCenter 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), ClaimCenter runs the database
upgrade tool during application start up.

Implications of modifying the data model 257

 Configuration Guide 9.0.5

258 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 259
• “Step 2: Create assignment class NewAssignableMethodsImpl” on page 261
• “Step 3: Test assignment of your extension entity instance” on page 263

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.

Example: Creating assignable entities 259

 Configuration Guide 9.0.5

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.
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 ke
y.

implementsEntity name CCAssignable

implementsInterface iface gw.api.assignment.CCAssignableMethods

impl gw.assignment.NewAssignableMethodsImpl

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

260 chapter 18 Example: Creating assignable entities

 Configuration Guide 9.0.5

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 261
• “Step 3: Test assignment of your extension entity instance” on page 263
See also
• For information on how to extend the data model, see “Modifying the base data model” on page 233.
• For information on the data model in general, see “The ClaimCenter data model” on page 171.

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 259

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 gw.assignment 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 gw.api.assignment.CCAssignableMethods.
• Extend the abstract superclass gw.api.assignment.CCAssignableMethodsBaseImpl.
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 {

Creating an assignable extension entity type 261

 Configuration Guide 9.0.5

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
gw.api.assignment.CCAssignableMethodsBaseImpl 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 super.Owner as UserAssignableEntity_Ext
}

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
gw.pl.persistence.core.Key.

Result
Your new class looks like the following code.

package gw.assignment

uses gw.api.assignment.CCAssignableMethods
uses gw.api.assignment.CCAssignableMethodsBaseImpl
uses gw.entity.ILinkPropertyInfo
uses gw.pl.persistence.core.Key

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 super.Owner as UserAssignableEntity_Ext
}

override function shouldCascadeAssignment(parent : Assignable, defaultOwnerUserId : Key,

defaultGroupId : Key) : boolean {

262 chapter 18 Example: Creating assignable entities

 Configuration Guide 9.0.5

return false
}
}

Next steps
• “Step 3: Test assignment of your extension entity instance” on page 263

Step 3: Test assignment of your extension entity instance

Before you begin
• “Step 1: Create extension entity type UserAssignableEntity_Ext” on page 259
• “Step 2: Subclass class AssignmentType” on page 266

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.

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 gw.api.database.Query
uses gw.api.database.Relop
uses gw.transaction.Transaction

var _users = Query.make(User).join(User#Credential).compare(Credential#UserName, Equals, "aapplegate")

var _usr = _users.select().AtMostOneRow
var _group = _usr.GroupUsers[0].Group
Transaction.runWithNewBundle(\bundle -> {
var newExtEntity = new UserAssignableEntity_Ext()
// Assign the entity to the specified user and group
print(newExtEntity.assign(_group, _usr) + "\t\t\tThe assign method succeeded. Thus, it returns true.")
print(newExtEntity.AssignedUser + "\tThe user that is assigned the newExtEntity (UserAssignableEntity_Ext) ob
ject.")
print(newExtEntity.AssignedGroup + "\tThe group that is assigned the newExtEntity (UserAssignableEntity_Ext) o
bject.")
}, "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.

Creating an assignable extension entity type 263

 Configuration Guide 9.0.5

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 259 describe how to create this entity.
This example requires the following steps:
• “Step 1: Extend the AssignmentState entity types” on page 264
• “Step 2: Subclass class AssignmentType” on page 266
• “Step 3: Create class UserAssignableEntityExtEnhancement” on page 268
• “Step 4: Test round-robin assignment” on page 269

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 259

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 DynamicAssignmentState.etx 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 DynamicAssignmentState.etx appears in the list, double-click that file.

264 chapter 18 Example: Creating assignable entities

 Configuration Guide 9.0.5

c. If DynamicAssignmentState.etx 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

nullok true

columnName LastTCAGrpId

3. Add fields to the file GroupAssignmentState.etx. If this file does not exist, you need to create it. Follow the
instructions in In Guidewire Studio, open DynamicAssignmentState.etx for editing or create a new entity
extension. to search for GroupAssignmentState.etx.
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

Making your extension entity type eligible for round-robin assignment 265
 Configuration Guide 9.0.5

Element type Attribute Value

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 GroupUserAssignmentState.etx. If this file does not exist, you need to create it.
Follow the instructions in In Guidewire Studio, open DynamicAssignmentState.etx for editing or create a
new entity extension. to search for GroupUserAssignmentState.etx.
6. In the entity editor, add the following items to the GroupUserAssignmentState extension.

Element type Attribute Value

column name TEAELoad

type integer

nullok true

column name TCALoad

type integer

nullok true

Next steps
• “Step 2: Subclass class AssignmentType” on page 266
• “Step 3: Create class UserAssignableEntityExtEnhancement” on page 268
• “Step 4: Test round-robin assignment” on page 269

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 264

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.

266 chapter 18 Example: Creating assignable entities

 Configuration Guide 9.0.5

Procedure
1. Create a new class file in the package gw.assignment 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 gw.assignment

uses gw.api.assignment.AssignmentType
uses gw.entity.IEntityType
uses gw.pl.persistence.core.Key

class UserAssignableEntityExtAssignmentType extends AssignmentType {

construct() {}

override function getLastAssignedUser(groupState : GroupAssignmentState) : Key {

return groupState.LastTEAEUser.ID
}

override function getLastAssignedUser(dynamicState : DynamicAssignmentState) : Key {

return dynamicState.LastTEAEUser.ID
}

override function setLastAssignedUser(groupState : GroupAssignmentState, user : Key) {

groupState.LastTEAEUser = groupState.Bundle.loadBean(user) as User
}

override function setLastAssignedUser(dynamicState : DynamicAssignmentState, user : Key) {

dynamicState.LastTEAEUser = dynamicState.Bundle.loadBean(user) as User
}

override function getUserLoad(groupUserState : GroupUserAssignmentState) : int {

return groupUserState.TEAELoad
}

override function setUserLoad(groupUserState : GroupUserAssignmentState, load : int) {

groupUserState.TEAELoad = load
}

override function getLastAssignedGroup(groupState : GroupAssignmentState) : Key {

return groupState.LastTEAEGrp.ID
}

override function getLastAssignedGroup(dynamicState : DynamicAssignmentState) : Key {

return dynamicState.LastTEAEGrp.ID
}

override function setLastAssignedGroup(groupState : GroupAssignmentState, group : Key) {

groupState.LastTEAEGrp = groupState.Bundle.loadBean(group) as Group
}

override function setLastAssignedGroup(dynamicState : DynamicAssignmentState, group : Key) {

dynamicState.LastTEAEGrp = dynamicState.Bundle.loadBean(group) as Group
}

override function getGroupLoad(groupState : GroupAssignmentState) : int {

return groupState.TEAELoad
}

override function setGroupLoad(groupState : GroupAssignmentState, load : int) {

groupState.TEAELoad = load
}

Making your extension entity type eligible for round-robin assignment 267
 Configuration Guide 9.0.5

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 268
• “Step 4: Test round-robin assignment” on page 269

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 264
• “Step 2: Subclass class AssignmentType” on page 266

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.
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 gw.assignment

uses gw.api.assignment.AssignmentType

enhancement UserAssignableEntityExtEnhancement : UserAssignableEntity_Ext {

static property get ASSIGNMENT_TYPE() : AssignmentType {
return new UserAssignableEntityExtAssignmentType()
}
}

268 chapter 18 Example: Creating assignable entities

 Configuration Guide 9.0.5

Next steps
• “Step 4: Test round-robin assignment” on page 269

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 264
• “Step 2: Subclass class AssignmentType” on page 266
• “Step 3: Create class UserAssignableEntityExtEnhancement” on page 268

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 gw.api.database.Query
uses gw.api.database.Relop
uses gw.transaction.Transaction

var _users = Query.make(User).join(User#Credential).compare(Credential#UserName, Equals, "aapplegate")

var _usr = _users.select().AtMostOneRow
var _group = _usr.GroupUsers[0].Group
Transaction.runWithNewBundle(\bundle -> {
for (i in 1..3) {
print("Pass " + i + ":")
var newExtEntity = new UserAssignableEntity_Ext()
// Assign the entity to the specified user and group
print(newExtEntity.assign(_group, _usr) + "\t\t\tThe assign method succeeded. Thus, it returns true.")
print(newExtEntity.AssignedUser + "\tThe user that is assigned the newExtEntity (UserAssignableEntity_Ext)
object.")
print(newExtEntity.AssignedGroup + "\tThe group that is assigned the newExtEntity (UserAssignableEntity_Ext)
object.")
var assignedToUser = newExtEntity.assignUserByRoundRobin(false, _group)
print("\t" + assignedToUser + "\t\t\tThe assignUserByRoundRobin method succeeded. Thus, it returns true.")
print("\t" + newExtEntity.AssignedUser + "\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:

Making your extension entity type eligible for round-robin assignment 269
 Configuration Guide 9.0.5

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 270
• “Step 2: Add foreign keys to assignable entity types” on page 271
• “Step 3: Create new assignment type for extension entity type TestClaimAssignable_Ext” on page 272
• “Step 4: Create enhancement class TestClaimAssignableExtEnhancement” on page 274
• “Step 5: Create delegate class TestClaimAssignableMethodsImpl” on page 274
• “Step 6: Add the necessary permission for the extension entity type” on page 276
• “Step 7: Test assignment of the assignable entity type” on page 278

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 264

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

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.

270 chapter 18 Example: Creating assignable entities

 Configuration Guide 9.0.5

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 ke
y, together with the CCAssignableMethods delegate in TestClaimAssignable
MethodsImpl, 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 gw.api.assignment.CCAssignableMethods

impl gw.assignment.TestClaimAssignableMethodsImpl

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 271
• “Step 3: Create new assignment type for extension entity type TestClaimAssignable_Ext” on page 272
• “Step 4: Create enhancement class TestClaimAssignableExtEnhancement” on page 274
• “Step 5: Create delegate class TestClaimAssignableMethodsImpl” on page 274
• “Step 6: Add the necessary permission for the extension entity type” on page 276
• “Step 7: Test assignment of the assignable entity type” on page 278

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.

Creating an assignable extension entity type that uses foreign keys 271
 Configuration Guide 9.0.5

Before you begin

• “Step 1: Create extension entity type TestClaimAssignable_Ext” on page 270

Procedure
1. In Guidewire Studio, open Claim.etx 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 Claim.etx 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 Activity.etx. If this file does not exist, you need to create it. Follow the instructions in
In Guidewire Studio, open Claim.etx for editing or create a new entity extension. to search for
Activity.etx.
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 272
• “Step 4: Create enhancement class TestClaimAssignableExtEnhancement” on page 274
• “Step 5: Create delegate class TestClaimAssignableMethodsImpl” on page 274
• “Step 6: Add the necessary permission for the extension entity type” on page 276
• “Step 7: Test assignment of the assignable entity type” on page 278

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.

Before you begin

• “Step 1: Create extension entity type TestClaimAssignable_Ext” on page 270
• “Step 2: Add foreign keys to assignable entity types” on page 271

Procedure
1. Create a new class file in the package gw.assignment and name it
TestClaimAssignableExtAssignmentType.
a. In Studio, navigate to configuration→gsrc→gw→assignment.
b. Right-click assignment and select New→Gosu Class.
272 chapter 18 Example: Creating assignable entities
 Configuration Guide 9.0.5

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 gw.assignment

uses gw.api.assignment.AssignmentType
uses gw.entity.IEntityType
uses gw.pl.persistence.core.Key

class TestClaimAssignableExtAssignmentType extends AssignmentType {

construct() { }

override function getLastAssignedUser(groupState : GroupAssignmentState) : Key {

return groupState.LastTCAUser.ID
}

override function getLastAssignedUser(dynamicState : DynamicAssignmentState) : Key {

return dynamicState.LastTCAUser.ID
}

override function setLastAssignedUser(groupState : GroupAssignmentState, user : Key) {

groupState.LastTCAUser = groupState.Bundle.loadBean(user) as User
}

override function setLastAssignedUser(dynamicState : DynamicAssignmentState, user : Key) {

dynamicState.LastTCAUser = dynamicState.Bundle.loadBean(user) as User
}

override function getUserLoad(groupUserState : GroupUserAssignmentState) : int {

return groupUserState.TCALoad
}

override function setUserLoad(groupUserState : GroupUserAssignmentState, load : int) {

groupUserState.TCALoad = load
}

override function getLastAssignedGroup(groupState : GroupAssignmentState) : Key {

return groupState.LastTCAGrp.ID
}

override function getLastAssignedGroup(dynamicState : DynamicAssignmentState) : Key {

return dynamicState.LastTCAGrp.ID
}

override function setLastAssignedGroup(groupState : GroupAssignmentState, group : Key) {

groupState.LastTCAGrp = groupState.Bundle.loadBean(group) as Group
}

override function setLastAssignedGroup(dynamicState : DynamicAssignmentState, group : Key) {

dynamicState.LastTCAGrp = dynamicState.Bundle.loadBean(group) as Group
}

override function getGroupLoad(groupState : GroupAssignmentState) : int {

return groupState.TCALoad
}

override function setGroupLoad(groupState : GroupAssignmentState, load : int) {

groupState.TCALoad = load
}

protected override property get AssignableClass() : IEntityType {

return TestClaimAssignable_Ext

Creating an assignable extension entity type that uses foreign keys 273
 Configuration Guide 9.0.5

}
}

Next steps
• “Step 4: Create enhancement class TestClaimAssignableExtEnhancement” on page 274
• “Step 5: Create delegate class TestClaimAssignableMethodsImpl” on page 274
• “Step 6: Add the necessary permission for the extension entity type” on page 276
• “Step 7: Test assignment of the assignable entity type” on page 278

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 270
• “Step 2: Add foreign keys to assignable entity types” on page 271
• “Step 3: Create new assignment type for extension entity type TestClaimAssignable_Ext” on page 272

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 gw.assignment

uses gw.api.assignment.AssignmentType

enhancement TestClaimAssignableExtEnhancement : TestClaimAssignable_Ext {

static property get ASSIGNMENT_TYPE() : AssignmentType {
return new TestClaimAssignableExtAssignmentType()
}
}

Next steps
• “Step 5: Create delegate class TestClaimAssignableMethodsImpl” on page 274
• “Step 6: Add the necessary permission for the extension entity type” on page 276
• “Step 7: Test assignment of the assignable entity type” on page 278

Step 5: Create delegate class TestClaimAssignableMethodsImpl

Any new assignable entity type must implement the CCAssignableMethods interface.

274 chapter 18 Example: Creating assignable entities

 Configuration Guide 9.0.5

Before you begin

• “Step 1: Create extension entity type TestClaimAssignable_Ext” on page 270
• “Step 2: Add foreign keys to assignable entity types” on page 271
• “Step 3: Create new assignment type for extension entity type TestClaimAssignable_Ext” on page 272
• “Step 4: Create enhancement class TestClaimAssignableExtEnhancement” on page 274

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 gw.assignment 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 gw.assignment

uses gw.api.assignment.CCAssignableMethods
uses gw.api.assignment.CCAssignableMethodsBaseImpl
uses gw.entity.ILinkPropertyInfo
uses gw.pl.persistence.core.Key

/**
* 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 Activity.Type.TypeInfo.getProperty("TestClaimAssignable") as ILinkPropertyInfo
}

override property get Owner() : TestClaimAssignable_Ext {

return super.Owner as TestClaimAssignable_Ext
}

override property get OwningClaim() : Claim {

Creating an assignable extension entity type that uses foreign keys 275
 Configuration Guide 9.0.5

return Owner.Claim
}

override function pushAssignmentPopup(assignables : List<CCAssignableMethods>) {

// Needed for user interface
AssignmentPopupUtil.pushAssignTestClaimAssignables(assignables.whereTypeIs(TestClaimAssignable_Ext).toTypedA
rray())
}

override property get ChildrenForCascadeAssignment() : List<CCAssignableMethods> {

return null
}

override function createAssignmentHistoryEvent(assignable : Assignable) : History {

var result = super.createAssignmentHistoryEvent(assignable)
result.Description = "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 AssignmentPopupUtil.pushAssignTestClaimAssignables. You need to provide at least a skeleton body
of this method. The next step resolves this issue.
3. Open gw.assignment.AssignmentPopupUtil 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 276
• “Step 7: Test assignment of the assignable entity type” on page 278

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 270
• “Step 2: Add foreign keys to assignable entity types” on page 271
• “Step 3: Create new assignment type for extension entity type TestClaimAssignable_Ext” on page 272
• “Step 4: Create enhancement class TestClaimAssignableExtEnhancement” on page 274
• “Step 5: Create delegate class TestClaimAssignableMethodsImpl” on page 274

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 ClaimCenter can ensure that only authorized users assign
TestClaimAssignable_Ext instances.
• Define a permission of permKey="own" in security-config.xml.
• Add this permission to the SystemPermissionType typelist.
• Assign this permission to a user role.

276 chapter 18 Example: Creating assignable entities

 Configuration Guide 9.0.5

• 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:

com.guidewire.pl.system.exception.InsufficientPermissionException: No user defined

at com.guidewire.pl.system.security.PermCheck.setAndCheckAssign(PermCheck.java:81)
at com.guidewire.pl.domain.assignment.impl.AssignableImpl.assign(AssignableImpl.java:236)
...

Procedure
1. Navigate to configuration→config→Security.
2. In this folder, double-click security-config.xml.
The file security-config.xml 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 SystemPermissionType.ttx 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 DynamicAssignmentState.etx 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 ClaimCenter, 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 ClaimCenter, using an administrative account.

Creating an assignable extension entity type that uses foreign keys 277
 Configuration Guide 9.0.5

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.
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 278

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 270
• “Step 2: Add foreign keys to assignable entity types” on page 271
• “Step 3: Create new assignment type for extension entity type TestClaimAssignable_Ext” on page 272
• “Step 4: Create enhancement class TestClaimAssignableExtEnhancement” on page 274
• “Step 5: Create delegate class TestClaimAssignableMethodsImpl” on page 274
• “Step 6: Add the necessary permission for the extension entity type” on page 276

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. Users.each(\name -> print( "\t" + name. User. DisplayName))

var _claim = gw.api.database.Query. make(Claim).compare(Claim# ClaimNumber, Equals,

"235-53-365870").select(). AtMostOneRow
print( "Claim number = " + _claim. ClaimNumber)
Transaction.runWithNewBundle(\bundle -> {
for (i in 1.. 5) {
var testAssignable = new TestClaimAssignable_Ext()
testAssignable = bundle.add(testAssignable)
testAssignable.Claim = _claim
testAssignable.assign(_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 (testAssignable.assignUserByRoundRobin( false, _group) != true) {

print("Cannot perform round-robin assignment.")
break
}
print("\tFor assignUserByRoundRobin, AssignedUser = " +
testAssignable.AssignedUser)
}
}, "su")

278 chapter 18 Example: Creating assignable entities

 Configuration Guide 9.0.5

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
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

Creating an assignable extension entity type that uses foreign keys 279
 Configuration Guide 9.0.5

280 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 281
“The data types configuration file” on page 284
“Customizing base configuration data types” on page 285
“Working with the medium text data type (Oracle)” on page 287
“Working with the VARCHAR data type (SQL Server)” on page 288
“The data type API” on page 288
“Defining a new tax identification number data type” on page 290

Related tasks
“Define a new data type” on page 289

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.

Data types 281

 Configuration Guide 9.0.5

Axis Description
Persistence A data type can specify how ClaimCenter 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 ClaimCenter interface treats a value. For example, a String data type can
specify an input mask to use in assisting the user with data entry.

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 java.util.Date. Thus, you see the following XML code in the
datetime.dti file.

<DataTypeDef xmlns="http://guidewire.com/datatype"
type="com.guidewire.pl.metadata.datatype2.impl.DateTimeDataTypeDef"
valueType="java.util.Date">
...

In a similar manner, the decimal data type has an associated type of java.math.BigDecimal.

<DataTypeDef xmlns="http://guidewire.com/datatype"
type="com.guidewire.pl.metadata.datatype2.impl.DecimalDataTypeDef"
valueType="java.math.BigDecimal">
...

Working with data types

In working with data types, you can do the following:

Operation Description
Customize an Modify the data type definition in file datatypes.xml, which you access through Studio. You can modify
existing data type only a select subset of the base configuration data types.
See “Customizing base configuration data types” on page 285.
Create a new Create a .dti definition file and place it in modules→configuration→config→datatypes. You also need to
data type create Gosu code to manage the data type.
See “Define a new data type” on page 289.
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="Claim">
<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.
282 chapter 19 Data types
 Configuration Guide 9.0.5

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

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:

gw.datatype.annotation.DataType

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.

Using data types 283

 Configuration Guide 9.0.5

Note: Guidewire ClaimCenter does not enforce this restriction at compile time. (However, ClaimCenter 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 datatypes.xml file, you must increment the version number in
extensions.properties.

ClaimCenter lets you modify certain attributes on a subset of the base configuration data types by using the
datatypes.xml configuration file. You can access this file in Studio from configuration→config→fieldvalidators. You
can modify the values of certain attributes in this file to customize how these data types work in ClaimCenter.
This datatypes.xml file contains the following elements:

XML element Description

<DataTypes> Top XML element for the datatypes.xml file.
<...DataType> Subelement that defines a specific customizable data type (for example, PhoneDataType, YearDataType, Mon
eyDataType) and assigns one or more default values to each one.

WARNING Modify the datatypes.xml file with caution. If you modify the file incorrectly, you can invalidate
your ClaimCenter installation.

<...DataType>
The <...DataType> element is the basic element of the datatypes.xml 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 datatypes.xml 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 285.
appscale Optional attribute for use with money data types.
For more information, see “The Money data type” on page 287.

284 chapter 19 Data types

 Configuration Guide 9.0.5

Deploying modifications to the data types configuration file

If you change the datatypes.xml file, then you need to deploy those changes to the application server. Most
modifications to the datatypes.xml file take effect the next time the server reboots.
• ClaimCenter reloads the validator attribute for data type definitions upon server reboot. This is so that you can
rebind different validators to data types.
• ClaimCenter does not reload other data type attributes such as length, precision, and scale. This is because
ClaimCenter applies these attributes only during the initial server boot. (It uses them during table creation in the
database.) ClaimCenter ignores any changes to these attributes unless something triggers a database upgrade. For
example, if you modify a base entity, then ClaimCenter 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 ClaimCenter database for the first time.
• Make modifications to the data types before performing a database upgrade that creates a new extension column.
ClaimCenter 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
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 datatypes.xml. To see exactly what you can customize
for each data type, see “List of customizable data types” on page 286. 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 295.
• For information on how to localize field validation, see the Globalization Guide.

Related concepts
“Field validation” on page 295

Related references
“List of customizable data types” on page 286

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.
The data types configuration file 285
 Configuration Guide 9.0.5

There are special requirements for these attributes in working with monetary amounts. For more information, see the
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 datatypes.xml) binds to the Phone validator by its
validator attribute. This matches the name attribute of a <ValidatorDef> definition in file fieldvalidators.xml.

//File datatypes.xml
<DataTypes xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="../../../../platform/pl/xsd/datatypes.xsd">
...
<PhoneDataType length="30" validator="Phone"/>
...
</DataTypes>

//File fieldvalidators.xml
<FieldValidators>
...
<ValidatorDef description="Validator.Phone" input-mask="###-###-#### x####" name="Phone"
value="[0-9]{3}-[0-9]{3}-[0-9]{4}( x[0-9]{0,4})?"/>
...
</FieldValidators>

List of customizable data types

The following table summarizes the list of the data types that you can customize. ClaimCenter defines these data
types in datatypes.xml. If a data type does not exist in datatypes.xml, then you cannot customize its attributes.
ClaimCenter 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

286 chapter 19 Data types

 Configuration Guide 9.0.5

Guidewire data type Built on Customizable attributes

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

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 currencyamount column type in metadata definition
files.
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. ForUTF8, the ratio is at most three-to-one, so you can always safely store up to 4000 / 3 = 1333
characters in a single column.

List of customizable data types 287

 Configuration Guide 9.0.5

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.

The data type API

The classes in gw.datatype 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:

gw.datatype.DataTypes.get(gw.lang.reflect.IAnnotatedFeatureInfo)

For example:

var property = Claim.Type.TypeInfo.getProperty("ClaimNumber")

var claimNumberDataType = DataTypes.get(property)

The gw.datatype.DataTypes.get(gw.lang.reflect.IAnnotatedFeatureInfo) 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 gw.datatype.DataTypes. 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:

288 chapter 19 Data types

 Configuration Guide 9.0.5

var varcharDataType = DataTypes.varchar(10)

var encryptedVarcharDataType = DataTypes.varchar(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 = DataTypes.get("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 = Claim.Type.TypeInfo.getProperty("ClaimNumber")
var claimNumberDataType = DataTypes.get(claimNumberProperty)
var maxLength = claimNumberDataType.asConstrainedDataType().getLength(claim, claimNumberProperty)

It may seem odd that the getLength(java.lang.Object, gw.lang.reflect.IPropertyInfo) 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 gw.datatype.IConstrainedDataType and gw.datatype.IPresentableDataType 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 ClaimCenter. 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 age.dti.

The data type API 289

 Configuration Guide 9.0.5

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 gw.datatype.def.IDataTypeDef 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:
• gw.datatype.handler.IDataTypeConstraintsHandler
• gw.datatype.handler.IDataTypePersistenceHandler
• gw.datatype.handler.IDataTypePresentationHandler
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:

gw.datatypes.impl.*

Result
After you create the data type, you will want to use the data type in some useful way.
For example, you can create an entity property that uses that data type and then expose that property as a field within
ClaimCenter.

Next steps
For a discussion of constraints, persistence, and presentation as it relates to data types, see “Overview of data types”
on page 281.

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 290
• “Step 2: Implement the IDataTypeDef Interface” on page 291
• “Step 3: Implement the data type aspect handlers” on page 293

Step 1: Register the data type

About this task
To register a new data type, create a file named XXX.dti, with XXX as the name of the new data type. In this case,
create a file named TaxID.dti. To do this:

290 chapter 19 Data types

 Configuration Guide 9.0.5

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 TaxID.dti 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="http://guidewire.com/datatype" type="gw.newdatatypes.TaxIDDataTypeDef"
valueType="java.lang.String">
<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="java.lang.String"/>
</DataTypeDef>

The root element of TaxID.dti is <DataTypeDef> and the namespace is http://guidewire.com/datatype.

This example defines the following:

data type name TaxID

value type String

parameter contactType

implementation type gw.newdatatypes.TaxIDDataTypeDef

Next steps
After completing this task, complete “Step 2: Implement the IDataTypeDef Interface” on page 291.
See also
• For details on the attributes and elements relevant to the data type definition, see “The ClaimCenter data model”
on page 171.

Step 2: Implement the IDataTypeDef Interface

Before you begin
Before beginning this task, complete “Step 1: Register the data type” on page 290.

About this task

The implementation class that you create to handle the TaxID data type must do the following:
• It must implement the gw.datatype.def.IDataTypeDef 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:
• gw.datatype.handler.IDataTypeConstraintsHandler
• gw.datatype.handler.IDataTypePersistenceHandler
• gw.datatype.handler.IDataTypePresentationHandler
Class TaxIDDataTypeDef

Defining a new tax identification number data type 291

 Configuration Guide 9.0.5

For our example data type, the gw.newdatatypes.TaxIDDataTypeDef class looks similar to the following. To create
this file, first create the package, then the class file, in the Studio Classes folder.

package gw.newdatatypes

uses gw.datatype.def.IDataTypeDef
uses gw.datatype.handler.IDataTypeConstraintsHandler
uses gw.datatype.handler.IDataTypePresentationHandler
uses gw.datatype.handler.IDataTypePersistenceHandler
uses gw.lang.reflect.IPropertyInfo
uses gw.datatype.handler.IDataTypeValueHandler
uses gw.datatype.def.IDataTypeDefValidationErrors
uses gw.datatype.impl.VarcharPersistenceHandler
uses gw.datatype.impl.SimpleValueHandler

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 typekey.Country.
var countryProp = prop.OwnersType.TypeInfo.getProperty(CountryProperty)

if (countryProp == null) {

errors.addError("Property \"" + CountryProperty + "\" does not exist on type " +

prop.OwnersType)

} else if (not typekey.Country.Type.isAssignableFrom(countryProp.Type)) {

errors.addError("Property " + countryProp + " does not resolve to a " + typekey.Country)

}
}
}

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 293.

292 chapter 19 Data types

 Configuration Guide 9.0.5

Step 3: Implement the data type aspect handlers

Before you begin
Before beginning this task, complete “Step 2: Implement the IDataTypeDef Interface” on page 291.

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:

gw.datatype.IConstrainedDataType

However, if you define a new data type, you must implement the following:

gw.datatype.handler.IDataTypeConstraintsHandler

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 gw.newdatatypes

uses gw.datatype.handler.IStringConstraintsHandler
uses gw.lang.reflect.IPropertyInfo
uses java.lang.Iterable
uses java.lang.Integer
uses java.lang.CharSequence
uses gw.datatype.DataTypeException

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 java.lang.String)
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) {

Defining a new tax identification number data type 293

 Configuration Guide 9.0.5

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 value.matches(pattern)) {
throw new DataTypeException("${value} does not match required pattern ${pattern}", prop,
"Validation.TaxID", { value })
}
}
}

Class TaxIDPresentationHandler
This class looks similar to the following:

package gw.newdatatypes

uses gw.lang.reflect.IPropertyInfo
uses gw.datatype.handler.IStringPresentationHandler

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

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.

294 chapter 19 Data types

chapter 20

Field validation

This topic describes field validators in the ClaimCenter data model and how you can extend them.
See also
• Globalization Guide

Related concepts
“Field validators” on page 295
“Field validator definitions” on page 296
“Modifying field validators” on page 299

Field validators
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 ClaimCenter 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.

Field validation 295

 Configuration Guide 9.0.5

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 ClaimCenter applies the field validator uniformly to that data element in whatever code
utilizes the delegate.

Field validator definitions

ClaimCenter stores field validator definitions in the fieldvalidators.xml file, located in Guidewire Studio under
configuration→config→fieldvalidators. The fieldvalidators.xml file contains a list of validator specifications for
individual fields in ClaimCenter. The fieldvalidators.xml file contains the following sections:

XML element Description More information

<FieldValidators> Top XML element for the fieldvalidators.xml file. “<FieldValidators>” on page 297
<ValidatorDef> Subelement that defines all of the validators. Each validator must “<ValidatorDef>” on page 297
have a unique name by which you can reference it.

Using the fieldvalidators.xml file, you can do the following:

• You can modify existing validators. For example, it is common for each installation site to represent claim
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 fieldvalidators.xml file:

<FieldValidators>
<ValidatorDef name="Email"
description="Validator.Email"
input-mask=""
value=".+@.+"/>
<ValidatorDef name="SSN"
description="Validator.SSN"
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. ClaimCenter persists this
value to the database, including any defined delimiters or characters other than the # character.
input-mask An input-mask, which is optional, assists the user in entering valid data. ClaimCenter displays the input mask
when 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, ClaimCenter uses the regular expression to validate the field data as it sets the field on
the object.

296 chapter 20 Field validation

 Configuration Guide 9.0.5

See also
• Globalization Guide

Related references
“<FieldValidators>” on page 297
“<ValidatorDef>” on page 297

<FieldValidators>
The <FieldValidators> element is the root element in the fieldvalidators.xml 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 297
• “floor, ceiling” on page 297
• “input-mask” on page 298
• “name” on page 298
• “placeholder-char” on page 298
• “validation-level” on page 298
• “validation-type” on page 298
• “value” on page 298
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. ClaimCenter 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="Validator.Money"
input-mask="" name="Money"
ceiling="9999999999999999.99"
floor="-9999999999999999.99"
value=".*"/>

Field validator definitions 297

 Configuration Guide 9.0.5

input-mask
The input-mask attribute is optional. It specifies a visual indication of the characters that the user can enter.
ClaimCenter 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. ClaimCenter 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.
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 gw.api.validation.PhoneValidator for an example. Ensure that any
Gosu validators that you define are low-latency for performance reasons.
regex (default) The value of the <ValidatorDef> defines a regular expression that ClaimCenter uses to validate data
entered 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.
ClaimCenter 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.

298 chapter 20 Field validation

 Configuration Guide 9.0.5

ClaimCenter uses the Java regex package described in the following location for regular expression parsing:

https://docs.oracle.com/javase/8/docs/api/java/util/regex/package-summary.html

The following list describes some of the more useful items:

() Parentheses define the order in which ClaimCenter 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 3
xx. ([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).
. 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 fieldvalidtors.xml 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 fieldvalidtors.xml file located in the root of the
fieldvalidators folder.
• You define national field validators in fieldvalidtors.xml 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="Validator.Example"
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 fieldvaldators.xml file replaces the base validator. -->

Modifying field validators 299

 Configuration Guide 9.0.5

<ValidatorDef name="ClaimNumber" value="[0-9]{3}-[0-9]{5}" description="Validator.ClaimNumber"

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 (Person.DateOfBirth). To create this validator,
you need to perform the following steps in Studio.

Procedure
1. Create a Person.etx file if one does not exist and add the following to it.

<extension entityName="Person">
<column-override name="DateOfBirth">
<columnParam name="validator" value="DateOfBirth"/>
</column-override>
</extension>

2. Add a validation definition for the DateOfBirth validator to fieldvalidators.xml.

For example:

<ValidatorDef description="Validator.DateOfBirth" ... name="DateOfBirth" .../>

In this case, you can potentially create different DateOfBirth validators in different country-specific
fieldvalidators files.

300 chapter 20 Field validation

 Configuration Guide 9.0.5

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
ClaimCenter 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.

Using <column-override> to modify field validation 301

 Configuration Guide 9.0.5

302 chapter 20 Field validation

chapter 21

Working with typelists

Within Guidewire ClaimCenter, 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 ClaimCenter 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 304
“Terms related to typelists” on page 304
“Typelists and typecodes” on page 305
“Typelist definition files” on page 305
“Different kinds of typelists” on page 305
“Working with typelists in Studio” on page 307
“Typekey fields” on page 310
“Removing or retiring a typekey” on page 313
“Typelist filters” on page 314
“Static filters” on page 314
“Dynamic filters” on page 319
“Typecode references in Gosu” on page 322
“Mapping typecodes to external system codes” on page 322

Working with typelists 303

 Configuration Guide 9.0.5

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 ClaimCenter data model.

Guidewire ClaimCenter 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
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 ClaimCenter interface, it is usually a typelist.
For example, the ClaimCenter Loss Details page that you access as you enter claim information contains several
different typelists. One of these is the Loss Cause typelist that provides the available values from which you can
choose as you enter claim information.
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:
• Contact.Country uses a simple list.
• Check.Status uses a list with a simple static filter, since only a subset of all transaction statuses make sense in
this context.
• Claim.LossCause uses a list filtered by LossType (that is, choices for this loss cause depend on the value of the
loss 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 claim in ClaimCenter 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 ClaimCenter. 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 ClaimCenter.
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 305
“Typelists and typecodes” on page 305
“Static filters” on page 314
“Dynamic filters” on page 319
“Typekey fields” on page 310

304 chapter 21 Working with typelists

 Configuration Guide 9.0.5

Typelists and typecodes

Within Guidewire ClaimCenter, 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.

Internal typecodes
Some typelists contain required internal typecodes that ClaimCenter references directly. Therefore, they must exist.
Studio displays internal typecodes in gray, non-editable cells. This makes it impossible for you to edit or delete an
internal typecode.

Localized typecodes
It is possible to localize 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 322
• Integration Guide

Typelist definition files

Similar to entity definitions, Guidewire ClaimCenter stores typelist definitions in XML files. There are three types
of typelist files:

File type Contains...

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.
ttx A single typelist extension. This can be a Guidewire-exposed base application extension or a custom typelist
extension that you create.
tix A single typelist extension for use by Guidewire only. These are generally Guidewire internal extensions to base
application 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 173

Different kinds of typelists

ClaimCenter organizes typelists into the following categories:

Category Description More information

Internal Typelists that Guidewire controls, as ClaimCenter requires these typelists for proper “Internal typelists”
application operation. ClaimCenter depends on these lists for internal application logic. on page 306
Guidewire designates internal typelists as final (meaning non-extendable). Thus, Guidewire
restricts your ability to modify them.

Typelists and typecodes 305

 Configuration Guide 9.0.5

Category Description More information

You can, however, override the following attribute values on these types of typelists:
• name
• description
• priority
• retired
Extendable Typelists that you can customize. These typelists come with a set of example typecodes, but “Extendable
it is possible to modify these typecodes and to add your own typecodes. In some cases, typelists” on page
these extendable typelists have internal typecode values that must exist for ClaimCenter to 306
function properly. You cannot remove the internal typecodes, but you can modify any of the
example typecodes.
ClaimCenter 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, for example, to work with a new custom field. “Custom typelists”
These typelists are not part of the Guidewire base configuration. Studio automatically makes on page 307
all custom typelists non-final (meaning extendable).

Internal typelists
A few of the typelists in the application are internal. Guidewire controls these typelists as ClaimCenter 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
ClaimCenter implements specific behavior for known activity types.
Studio disables your ability to add additional typecodes to internal typelists.
The following are examples of internal typelists that you cannot change:
• ActivityStatus
• AggregateLimitType
• AssignmentStatus
• Coverage

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. You can, however, 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 desired data. You
cannot change the typecode itself, 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. ClaimCenter includes default typelists with sample
typecodes in them. You can customize these typelists for your business needs by adding additional typecodes, if you
want.
306 chapter 21 Working with typelists
 Configuration Guide 9.0.5

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 238.
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.
ClaimCenter limits the number of characters in a typecode to 50 or less.

Working with typelists in Studio

You create, manage and modify typelists within ClaimCenter using Guidewire Studio:
• To work with an existing extendable typelist, expand the Typelist folder in the Project tools window and open the
typelist from the list of existing typelists. This opens 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, it is possible to
create filters for the typelist that modify its behavior within Guidewire ClaimCenter.

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.
For example, any modifications that you make to the PolicyType typelist can potentially affect the InsuranceLine
and CoverageType typelists that the PolicyType 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

ClaimCenter 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 a _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.

Different kinds of typelists 307

 Configuration Guide 9.0.5

The Table Name field

By default, Guidewire uses cctl_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 cctl_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 ClaimCenter 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 cctl_typelist-name

Table name Typelists editor 25 characters cctl_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.
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. ClaimCenter 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 ClaimCenter
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:

308 chapter 21 Working with typelists

 Configuration Guide 9.0.5

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.

To create a new typecode

You must open or create a non-internal typelist extension or a custom typelist in order 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 173 and “Different kinds of typelists” on page 305 for more information.
Once you have a non-internal typelist extension or custom typelist open, refer to the Typelist editor. In the Typelist
editor, click Add .
With the new typecode selected, you can set the following:

Field Description
code A unique ID for internal Guidewire use. Enter a string containing only letters, digits, or the following characters:
• a dot (.)
• a colon (:)
Do not include white space or use a hyphen (-).
Use this code to map to your legacy systems for import and export of ClaimCenter data. The code must be
unique within the list. ClaimCenter limits the number of characters in a typecode to 50 or less.
See also “Mapping typecodes to external system codes” on page 322.

The typelist editor 309

 Configuration Guide 9.0.5

Field Description
name The text that is visible within ClaimCenter in the drop-down lists within the application. You can uses white space
and longer descriptions. However, limit the number of characters to an amount that does not cause the drop-
down list to be 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. ClaimCenter displays the
text in this field in the ClaimCenter 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 this to sort the
codes within the drop-down list and to sort a list of activities, for example, by priority. If you omit this value,
ClaimCenter sorts the list alphabetically by name. If desired, you can specify priorities for some typecodes but
not others. This causes ClaimCenter to order the prioritized ones at the top of the list with the unprioritized ones
alphabetized afterwards.
retired A Boolean flag that indicates that a typecode is no longer in use. It is still a valid value, but not offered as a
choice in the drop-down list as a new value. ClaimCenter does not make changes to any existing objects that
reference this typecode. If you do not enter a value, ClaimCenter assumes the value is false (the default value).

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 maximum number of typecodes in a typelist to 255 items. Any
number larger than that can cause performance issues. If you need more than 255 typecodes, then use a lookup
(reference) table and a query to generate the typelist. In any case, Guidewire does not support the use of more than
8192 typecodes on a typelist.

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 a excellent way to identify any flaws with your new or modified typelist.
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 305
• “Mapping typecodes to external system codes” on page 322
• Integration Guide

Typekey fields
A typekey field is an entity field that ClaimCenter 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 ClaimCenter 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.
310 chapter 21 Working with typelists
 Configuration Guide 9.0.5

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
ClaimCenter.
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.
For example, in the base configuration, Guidewire declares a number of <typekey> elements on the Activity entity
(Activity.eti), 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"/>

Typekey fields 311

 Configuration Guide 9.0.5

...
</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 219.
• For information on how to create data model entities, see “The ClaimCenter data model” on page 171.
• For information on how to modify existing data model entities, see “Modifying the base data model” on page
233.

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 ClaimCenter, 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 ClaimCenter to render a Priority field on the screen, it must exist in the PCF
file that ClaimCenter uses to render the screen.
Thus, the ClaimCenter NewActivityDV PCF file contains a Priority field with a value of Activity.Priority.

After completing this step, complete “Step 4: Update the data model” on page 313.

312 chapter 21 Working with typelists

 Configuration Guide 9.0.5

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 ClaimCenter 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 ClaimCenter
interface. Restarting the application server forces ClaimCenter 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 ClaimCenter 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.
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. ClaimCenter 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
About this task
Suppose that you delete the email_sent typekey from the base configuration DocumentType typelist. If you remove
this typekey, then you must also update all others part of the application and disallow 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
CreateEmailSent.gosu.htm.descriptor file references email_sent.

Procedure
1. Navigate to the typelist that contains the typekey that you want to retire.
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 the application files to find all references to the deleted
typekey.
b. Open these files in Studio and modify as necessary.

Example: Typekey field 313

 Configuration Guide 9.0.5

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
313 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 ClaimCenter filters the typelist values so that they do not all appear in the
drop-down list (typelist) in the ClaimCenter 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 page
• Include certain specific typecodes on the typelist only. 314
• Include certain specific categories of typecodes on the typelist.
• Exclude certain specific typecodes from the full list of the typecodes on the typelist.
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 319
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.
You define a static filter at the level of the typelist. You do this through the Studio Typelist editor, 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="http://guidewire.com/typelists" 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>

314 chapter 21 Working with typelists

 Configuration Guide 9.0.5

Notice that the XML 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 is static (fixed) filter.
See also
• For information on the <typefilter> element, see “<typekey>” on page 219
• “Create a static filter” on page 315

Create a static filter

Procedure
1. Define the typecodes for this typelist in the Studio Typelist editor. See “Working with typelists in Studio” on
page 307 for details.

2. In the selector next to Add , click typefilter.

3. Set the following information for your static filter:

Attribute Description
name The name of the filter. ClaimCenter uses this value to determine if a field uses this filter.
desc Description of the context for which to use this typefilter.
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 ClaimCenter to use values set in the various subpanes to modify the typelist
view in the application.

4. 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 “Creating a static filter using
category within the filtered typelist view. categories” on page 316
“Creating a static filter using Specify one or more typecodes to include “Creating a static filter using includes”
includes” on page 317 within the filtered typelist view. on page 317
“Creating a static filter using Specify one or more typecodes to exclude from “Creating a static filter using excludes”
excludes” on page 318 the full list of typecodes for this typelist. on page 318

5. 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="YesNoO

nly"
typelist="YesNo"/>

6. (Optional) Regenerate the Data Dictionary and verify that there are no validation errors.
Static filters 315
 Configuration Guide 9.0.5

7. Stop and restart the application server to update the data model.

Next steps
See also
• “Typekey fields” on page 310

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
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:

316 chapter 21 Working with typelists

 Configuration Guide 9.0.5

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.
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 ClaimCenter user interface.
• Reference the typelist in the PCF file in which you want to display the typelist.
See “Typekey fields” on page 310 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 •
Static filters 317
 Configuration Guide 9.0.5

ZoneType typecode Associated typelist Associated typecode Include in filter

postalcode Country AU
CA
DE
province Country CA •
state Country AU
DE
US
zip Country US

To create an include filter

1. Open the typelist that you want to filter in the 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.

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 •
318 chapter 21 Working with typelists
 Configuration Guide 9.0.5

ZoneType typecode Associated typelist Associated typecode Include in filter

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

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. You do this through the Studio Typelist editor, by defining a filter
for a particular typecode. To create this filter, 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:

Dynamic filters 319

 Configuration Guide 9.0.5

Filter type Use to More information

Category Associate one or more typecodes on a parent typelist with one or more “Dynamic filters” on page 319
typecodes on a child typelist.
Category list Associate all of the typecodes on a parent typelist with one or more typecodes “Dynamic filters” on page 319
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 ClaimCenter field value in the PCF file” on page 321
• “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 ClaimCenter, a user with administrative privileges can define a new
activity pattern (Administration→Business Settings→Activity Patterns→AddActivity Pattern). Within the New Activity Pattern
screen, you see the following drop-down lists:
• Type
• Category
ClaimCenter automatically sets the default value of Type to General. (You cannot edit this field as the editable
attribute of this field is set to false in the base configuration.) This value determines the available choices that you
see in the Category drop-down list. For example:
• Correspondence
• File Review
• General
• Interview
• ...
The ActivityCategory typelist is the typelist that controls what you see in the Category field in ClaimCenter. 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, ClaimCenter filters each individual typecode in this typelist so that it is available for selection only if you first
select the associated typelist and typecode.

320 chapter 21 Working with typelists

 Configuration Guide 9.0.5

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 correspondence
typecode, you see that ClaimCenter 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 ClaimCenter 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.

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 219.
After completing this task, complete “Step 3: Set the ClaimCenter field value in the PCF file” on page 321.

Step 3: Set the ClaimCenter field value in the PCF file

Before beginning this task, complete “Step 2: Declare the category filter on an entity” on page 321.

Creating a dynamic filter 321

 Configuration Guide 9.0.5

After you declare these two typelists on the ActivityCategory entity, you need to link the typelists to the
appropriate fields on the ClaimCenter Add Activity Pattern screen. To access an entity typelist, you need to use the
entity.Typelist syntax. For example, to access the ActivityCategory typelist on the ActivityPattern entity,
use ActivityPattern.Category 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 ClaimCenter field value in the PCF file” on page 321.
Guidewire recommends that you regenerate the ClaimCenter 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 ClaimCenter
interface. Restarting the application server forces ClaimCenter 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.

typekey.TypeList.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.

typekey.STATE.TC_CA

You must prefix the code in the object path expressions for typecodes with TC_.
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.

Mapping typecodes to external system codes

Your ClaimCenter application can share or exchange data with one or more external applications. If you use this
functionality, Guidewire recommends that you configure the ClaimCenter 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 ClaimCenter typecode, but the external
applications do not match. Alternatively, suppose that you extend your typecode schema in ClaimCenter. This can
possibly cause a situation in which three different codes in ClaimCenter represent a single (less granular) code in the
other application.
To handle these more complex cases, edit the file typecodemapping.xml in the
configuration→config→typelists.mapping 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 typecodemapping.xml file:

<?xml version="1.0"?>
<typecodemapping>
<namespacelist>
<namespace name="accounting" />
</namespacelist>

322 chapter 21 Working with typelists

 Configuration Guide 9.0.5

<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 ClaimCenter typecode.
namespace The namespace to which ClaimCenter maps the typecode

alias The code in the external application.

In the previous example, the PR ClaimCenter code maps to an external application named accounting. You can
create multiple mapping entries for the same ClaimCenter typecode or the same name space. For example, the
following specifies a mapping between multiple ClaimCenter codes and a single external code:

<typelist name="BoatType">
<mapping typecode="AI" namespace="accounting" alias="boat" />
<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”.

Mapping typecodes to external system codes 323

 Configuration Guide 9.0.5

324 chapter 21 Working with typelists

chapter 22

The ClaimCenter archive domain graph

The archive domain graph defines the cluster of entity types that ClaimCenter treats as a single aggregate for
purposes of archiving data.

IMPORTANT Guidewire strongly recommends that you contact Customer Support before implementing archiving.

See also
• Application Guide

Related concepts
“Understanding ClaimCenter entity ownership” on page 328
“Ownership relationships in the ClaimCenter archive domain graph” on page 330
“Entities in the archive domain graph” on page 332
“Data model changes that impact archiving” on page 335
“Working with shared entity data” on page 336
“About cycles in the archive domain graph” on page 336
“Validation of the archive domain graph” on page 337
“About archive domain graph errors” on page 339
“About archive graph error messages” on page 343
“About archiving and event messages” on page 345
“Viewing the archive domain graph” on page 345
“Using archive logging” on page 346

Related references
“Overview of the archive domain graph” on page 326

The ClaimCenter archive domain graph 325

 Configuration Guide 9.0.5

Overview of the archive domain graph

The archive domain graph defines the cluster of related entity instances that ClaimCenter 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
ClaimCenter, the root entity type of the archive domain graph is Claim.
Boundary The boundary of the archive domain graph defines which entity types terminate the traversal of owner
relationships from the root and thus prescribe the extent of entities within the graph. In ClaimCenter, the boundary
includes the major entities that relate to the Claim entity type, such as Exposure, Coverage,and Matter, among
others.

In ClaimCenter, for an entity type to be in the archive domain graph:

• The entity must implement the Extractable delegate.
• The entity must have a foreign key relationship to an entity in the archive domain graph.
The set of all entities that implement the Extractable delegate becomes the archive domain graph.
The root of the ClaimCenter archive domain graph is the Claim entity. During the archive process, ClaimCenter
leaves a stub of the claim behind in the database. This stub provides minimal summary information about the
archived claim sufficient to retrieve the claim, if requested. The stub entity type is ClaimInfo, which implements
the RootInfo delegate. ClaimInfo has a foreign key to Claim and Claim has a one-to-one (<onetoone>)
relationship with ClaimInfo.

See also
• “Delegate data objects” on page 182
• “Entity data objects” on page 185
• “<foreignkey>” on page 211
• “<onetoone>” on page 216
• “Entities in the archive domain graph” on page 332

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 ClaimCenter data model itself also is a directed acyclic graph based on foreign key relationships between entity
types.

326 chapter 22 The ClaimCenter archive domain graph

 Configuration Guide 9.0.5

IMPORTANT Guidewire expressly prohibits bidirectional relationships between ClaimCenter entity types. This
prohibition ensures that ClaimCenter can commit related entity instances in a transactional bundle in a safe order
without exceptions or deadlocks.

See also
• “Validation of the archive domain graph” on page 337
• “About cycles in the archive domain graph” on page 336

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 Claim. There are
two ways to think of the archive domain graph:
• The entity graph defines the archive root entity and the specific ClaimCenter 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. ClaimCenter
builds this graph a single time at server startup and thereafter uses the graph to create individual instances of
the archive domain graph.
The ClaimCenter 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.
ClaimCenter 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 ClaimCenter 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 ClaimCenter 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, ClaimCenter 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
ClaimCenter 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 ClaimCenter archives an instance of entity A (and its link to an entity instance of B) at some
point in time. A ClaimCenter user then deletes that particular instance of B, which remove it from the ClaimCenter
database. At some later time, ClaimCenter attempts to retrieve the archived instance of entity A. However, as entity
B no longer exists in the database, ClaimCenter 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, ClaimCenter generates a fatal validation error at server startup.

Overview of the archive domain graph 327

 Configuration Guide 9.0.5

See also
• “Defining a reference entity” on page 249
• “Graph validation errors that prevent the server from starting” on page 337

Claim purging and the archive domain graph

While the archive domain graph is central to the process of archiving, ClaimCenter uses the domain graph for the
following purposes, as well:
• Claim Purge command line tool
• Claim purges called during a cancel of the New Claim wizard
Purging a claim permanently removes the claim from the database. If ClaimCenter archiving is in use, purging a
claim permanently removes the claim from the archive as well. It is not possible to ever again find the claim by
searching. It is also not possible to restore a purged claim. Purging removes all traces of the claim from the database
and the archive.

Table cc_purgedrootinfo
Whenever ClaimCenter purges a claim, it deletes the Claim domain graph instance for that claim, including the
ClaimInfo object that is the root of the domain graph instance. However, to track which claims it purged,
ClaimCenter creates a PurgedRootInfo entity at the same time it purges a claim to record the ClaimInfo public ID
of the purged claim. ClaimCenter then stores each PurgedRootInfo instance as a row in table cc_purgedrootinfo.
ClaimCenter does not automatically delete these entities from the table. If you have a high purge volume, Guidewire
recommends that you create a batch process to delete old, unwanted PurgedRootInfo instances from this table.
See also
• System Administration Guide

Understanding ClaimCenter 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.
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="http://guidewire.com/datamodel" 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.

328 chapter 22 The ClaimCenter archive domain graph

 Configuration Guide 9.0.5

Ownership Description
Entity ownership A child entity (B) has a foreign key to its parent entity (A). The foreign key definition includes setting
attribute archivingOwner to target, which indicates that A (the target) owns B (the source). If this
attribute is missing from the foreign key definition, ClaimCenter assumes a value of target, the default.
For example, in the base ClaimCenter configuration, entity Matter has a foreign key relationship with the C
laim entity.

Inverse ownership A child entity (B) has a foreign key to its parent entity (A). However, the foreign key definition sets attribute
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 ClaimCenter configuration, entity Claim has an inverse foreign key relationship
with the ClaimWorkComp entity.
IMPORTANT Guidewire discourages the use of inverse ownership relationships. The ClaimCenter data
model supports inverse ownership relationships for the rare case in which upgrading the database is
unduly cumbersome or time consuming. As a general rule, do not use this type of relationship.

See also
• “<edgeForeignKey>” on page 207
• “<foreignkey>” on page 211
• “Foreign key ownership in the archive domain graph” on page 329
• “Inverse foreign key ownership in the archive domain graph” on page 330
• “Working with shared entity data” on page 336

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 ClaimCenter configuration, Matter has a foreign key to Claim. The following Matter
metadata definition shows this relationship.

<entity xmlns="http://guidewire.com/datamodel"
desc="The set of data organized around a single lawsuit or potential lawsuit."
entity="Matter" ... >
...
<foreignkey columnName="ClaimID"
desc="The claim associated with this legal matter."
exportable="false"
fkentity="Claim"
name="Claim"
nullok="false"/>
...
</entity>

As the code does not provide a value for the archivingOwner attribute, ClaimCenter uses its default value, which is
target. Thus, the owner of the Matter entity is the Claim entity.
Understanding ClaimCenter entity ownership 329
 Configuration Guide 9.0.5

See also
• “Understanding ClaimCenter entity ownership” on page 328
• “Inverse foreign key ownership in the archive domain graph” on page 330

Inverse foreign key ownership in the archive domain graph

IMPORTANT Guidewire discourages the use of inverse ownership relationships. The ClaimCenter 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 ClaimCenter configuration, Claim and ClaimWorkComp have an ownership relationship,
with a foreign key from Claim to ClaimWorkComp. The following Claim metadata definition shows this relationship.

<entity xmlns="http://guidewire.com/datamodel" desc="Insurance claim" entity="Claim" ... >

...
<foreignkey archivingOwner="source"
columnName="ClaimWorkCompID"
desc="Claim's worker's compensation data"
fkentity="ClaimWorkComp"
name="ClaimWorkComp"
nullok="true"
triggersValidation="true"/>
...
</entity>

The archivingOwner attribute of source on the ClaimWorkCompID foreign key indicates an inverse ownership
relationship. Thus, the Claim entity is the owner of the ClaimWorkComp entity.
See also
• “Understanding ClaimCenter entity ownership” on page 328
• “Inverse foreign key ownership in the archive domain graph” on page 330
• “About cycles in the archive domain graph” on page 336

Ownership relationships in the ClaimCenter archive domain graph

The following graphic illustrates the relationships between a subset of the entity types in the ClaimCenter data
model. The graphic contains entities in the archive domain graph, in reference data, and in overlap tables. The
ClaimInfo entity is outside the archive domain graph as it does not implement Extractable delegate. Instead, it
implements the RootInfo delegate only.

330 chapter 22 The ClaimCenter archive domain graph

 Configuration Guide 9.0.5

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 solid arrow between Note and Activity indicates that
Note has a foreign key to the Activity and that an activity can own (have) a note.
• A solid arrow line with a multi-line tail indicates the two graph entities are related in the data model by a foreign
key and an array. The tail of the arrow indicates the entity on which the data model declares the foreign key. The
head of the arrow indicates the entity on which the data model declares the array. For example, the arrow
between Activity and Claim indicates that Activity has a foreign key to Claim and that a claim can own
(have) an array of activities.
• A dashed arrow line indicates the two graph entities are related in the data model by a single reverse foreign key.
The tail of the arrow indicates the entity on which the data model declares the foreign key. But, in this case, the
entity at the tail of the arrow is also the owning entity. For example, the arrow between Claim and Policy
indicates that Claim has a foreign key to Policy and that a claim can own (have) a policy. Guidewire indicates
this type of relationship by setting the archivingOwner="source" in the foreign key metadata definition.

Relationship between domain graph, overlap tables, and reference data

ClaimInfo

Domain graph

Exposure

Note Activity
Claim

archivingOwner=source
ClaimContact
Policy

Overlap tables
archivingOwner=source

Contact ContactAddress

Legend

Reference A B B has an A
data
A B B has an array of A

Catastrophe A B A has a B

In the archive domain graph:

• The ClaimInfo entity—and only that entity—implements the RootInfo delegate.
• ClaimInfo has a foreign key to Claim, the root entity, and Claim has a one-to-one (<onetoone>) relationship
with ClaimInfo.
• All entities in the archive domain graph, including the root entity, implement the Extractable delegate either
directly or through an entity subtype.
• All overlap entities implement the Extractable and the OverlapTable delegates. Entity types that implement
the OverlapTable delegate can exist as part of the archive domain graph and as reference data outside the graph.
Ownership relationships in the ClaimCenter archive domain graph 331
 Configuration Guide 9.0.5

Individual rows in an overlap table can exist only as part of the archive domain graph or as reference data, but
not both.
• The Claim entity has a foreign key link to the Catastrophe entity. However, ClaimCenter does not archive
catastrophe data as the Catastrophe entity is reference data, which is not part of the archive domain graph nor
overlap data.
• The Claim entity has an indirect reference to the Contact entity through the ClaimContact entity. ClaimCenter
archives instances of the Contact entities linked to the archived Claim entity as these entity instances are also
part of the archive domain graph.
• Entity types that do not implement either the Extractable or OverlapTable delegate are reference data.
ClaimCenter does not archive reference data.

See also
• “<implementsEntity>” on page 213
• “Delegate data objects” on page 182
• “The archive domain graph and reference data” on page 327

Entities in the archive domain graph

For ClaimCenter 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 ClaimCenter 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
You cannot change this designation. For ClaimCenter, the RootInfo entity is the RootInfo
ClaimInfo. delegate” on page
333
Archive domain All archive domain entities, including the root entity, must implement the Ex “Archive entities and
entities tractable delegate. The set of all entities that implement the Extractable the Extractable
delegate comprise the archive domain graph. delegate” on page
333
Overlap table entities Overlap tables are tables in which individual table rows can exist either in the “Archive entities and
archive domain graph or as part of reference data, but not both. The the OverlapTable
database table itself exists in the archive domain graph and as reference delegate” on page
data. All overlap table entities, and only overlap table entities, must 334
implement the OverlapTable delegate.
In ClaimCenter, Address and Contact entities, among others, implement the
OverlapTable delegate.

332 chapter 22 The ClaimCenter archive domain graph

 Configuration Guide 9.0.5

Entity type Delegate Implementation For more information

The primary use for these types of entities is for Guidewire code. The use of
overlap tables by non-Guidewire code is not common.

See also
• “Delegate data objects” on page 182
• “The archive domain graph and reference data” on page 327
• “Ownership relationships in the ClaimCenter archive domain graph” on page 330

Archive entities and the RootInfo delegate

Whenever ClaimCenter archives an instance of the archive domain graph, it leaves a stub entity instance in the
ClaimCenter database that provides the following:
• Sufficient information for a minimal search on archived claims
• Sufficient information to retrieve the data
The root of the archive domain graph must implement the RootInfo delegate. No other entity type can implement
the RootInfo delegate.
In ClaimCenter, the root information entity type is the ClaimInfo entity, a stub entity that represents an archived
Claim entity. Although the Claim entity is the root entity of the archive domain graph, it does not implement the
RootInfo delegate. You cannot change which entity type implements the RootInfo delegate. It must always be
ClaimInfo.
The following sample code shows the metadata definition of the ClaimInfo entity implementing the RootInfo
delegate.

<entity xmlns="http://guidewire.com/datamodel"
consistentchildren="false"
desc="Claim Information"
entity="ClaimInfo"
exportable="true"
extendable="true"
lockable="false"
platform="false"
table="claiminfo"
type="retireable">
...
<implementsEntity name="RootInfo"/>
...
</entity>

The ClaimInfo metadata defines minimal, summary information about an archived claim. For example, the entity
contains the claim number and loss location. ClaimCenter uses this information during claim search to find archived
claims.

IMPORTANT Because ClaimCenter does not archive the ClaimInfo table, the table grows regardless of archiving.
Therefore, Guidewire recommends against extending the ClaimInfo 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 ClaimCenter uses during the archive process.

Entities in the archive domain graph 333

 Configuration Guide 9.0.5

Specifying the Extractable delegate on entities

The following metadata definition of the Claim entity type implements the Extractable delegate, which makes
Claim part of the archive domain graph.

<entity xmlns="http://guidewire.com/datamodel"
consistentchildren="true"
desc="Insurance claim"
entity="Claim"
exportable="true"
lockable="true"
table="claim"
type="retireable">
...
<implementsEntity name="Extractable"/>
...
</entity>

Specifying the Extractable attribute on edge foreign keys

In Guidewire ClaimCenter, 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 ClaimCenter 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="http://guidewire.com/datamodel"
consistentchildren="true"
desc="Insurance claim"
entity="Claim"
exportable="true"
lockable="true"
table="claim"
type="retireable">
...
<edgeForeignKey desc="Workers' Comp only. Details about the claimant's employment."
edgeTableName="claimempdata"
extractable="true"
fkentity="EmploymentData"
loadable="true"
name="EmploymentData"
nullok="true"/>
...
</entity>

See also
• “<edgeForeignKey>” on page 207

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.

334 chapter 22 The ClaimCenter archive domain graph

 Configuration Guide 9.0.5

See also
• “The archive domain graph and reference data” on page 327

Specifying the OverlapTable delegate on entities

In ClaimCenter, the Address table is an overlap table. The Address table itself exists in both the archive domain
graph and as reference data. The following metadata definition of a data model extension to the Address entity type
illustrates how to implement the OverlapTable delegate.

<internalExtension xmlns="http://guidewire.com/datamodel"
entityName="Address">
...
<implementsEntity name="Extractable"/>
<implementsEntity name="OverlapTable"/>
...
</internalExtension>

Specifying the OverlapTable attribute on edge foreign keys

In the base configuration, ClaimCenter 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.

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 ClaimCenter 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 type to no longer exist as part of the graph. This can happen, for example, if the entity type
was some part of reference data that was shared by multiple claims, but is now removed from the archive domain
graph.
Suppose, for example, that you remove an entity type from the ClaimCenter 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 ClaimCenter archived the entity instance already, before you removed it from the graph.
Then, at a later time, someone or ClaimCenter 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.

Archive entities and the OverlapTable delegate 335

 Configuration Guide 9.0.5

2. If found, call the gw.api.archiving.upgrade.IArchivedEntity method to create a new IArchivedEntity

that is a referenced entity. The referenced entity must exist in the database.You 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

ClaimCenter 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 claims and their individual
instances of the archive domain graph.
For example, you cannot have two separate claim instances that own the same Event instance. If you want to share
an entity, such as an Event, across multiple claims, extend the Claim entity type and add a foreign key to the shared
entity table.
If you share an entity type across multiple claims, 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 claims 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 ClaimCenter 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.
See also
• “Foreign key ownership in the archive domain graph” on page 329
• “Inverse foreign key ownership in the archive domain graph” on page 330
• “Circular foreign key references” on page 336
• “Ownership cycles” on page 337

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 ClaimCenter 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, ClaimCenter 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, ClaimCenter can safely commit entity A first,
then new entity B, and finally the hidden edge foreign key entity.

336 chapter 22 The ClaimCenter archive domain graph

 Configuration Guide 9.0.5

See also
• “<edgeForeignKey>” on page 207

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 ClaimCenter 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.
In ClaimCenter, tests of the archive domain graph verify that the current data model can support archiving claims
and purging them from the archive.
ClaimCenter 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.

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.

See also
• “About archive domain graph errors” on page 339
• “Resolve archive graph errors” on page 339
• “Resolve archive graph warnings” on page 340
• “Resolving issues with custom archive entities” on page 341
• “About archive graph error messages” on page 343

Graph validation errors that prevent the server from starting

The following list describes validation tests that ClaimCenter performs on the archive domain graph during startup.

Test Description
Domain graph not Verifies that all tables in the archive domain graph are reachable through the root entities.
partitioned
Edge tables in domain Verifies that if edgeTable is set on an entity in the archive domain graph, it must have all of the
graph have required following:
foreign keys • An owned foreign key back to one of its parents
• An unowned foreign key to that same parent.
No cycles in domain Looks for circular references in the archive domain graph. Circular references in the graph cause
graph issues for the archive process.

About cycles in the archive domain graph 337

 Configuration Guide 9.0.5

Test Description
The archive domain graph cannot have any cycle in its is owned by relationships. Thus, the following
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 archive
domain graph” on page 345 for information on how to view the graph in a graphical format.
Domain graph entities Ensures that all entities inside the archive domain graph implement the Extractable delegate.
implement Extractabl ClaimCenter uses the following column on Extractable during the archive process:
e • ArchivePartition
This test also verifies that no entities outside the archive domain graph implement the Extractable
delegate.
Overlap tables Verifies that all overlap tables implement the OverlapTable delegate. An overlap table contains
implement OverlapTab rows that can exist either in the archive domain graph or as part of reference data, but not both.
le 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 to
keyable reference the entity by ID.
Reference entities Verifies that all reference entities in the archive domain graph are retireable. See “The archive
retireable 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 that are outside of the archive domain graph.
graph are outside the ClaimCenter has several built-in exceptions to the rule that foreign keys from entities outside the
domain graph archive domain graph not reference entities inside the archive domain graph. For these entities, this
test verifies that the outside entity is indeed outside the archive 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 ClaimCenter server.
See also
• “Resolve archive graph errors” on page 339
• “Resolving issues with custom archive entities” on page 341

Graph validation warnings that do not prevent the server from starting
The following list describes validation tests that ClaimCenter performs on the archive domain graph during startup.

Test Description
Archive domain graph entities All foreign keys from entities in the archive domain graph must reference other entities in
refer only to administrative data the domain graph only. Otherwise, foreign key violations can occur as ClaimCenter
and domain entities traverses the domain graph during the archiving processes.
Nothing outside the archive There must not be foreign keys from entities outside the archive domain graph to entities
domain graph points to the inside the archive domain graph.
graph
Null links cannot make a node ClaimCenter constructs the archive domain graph by looking at foreign keys. If enough links
unreachable are 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.

338 chapter 22 The ClaimCenter archive domain graph

 Configuration Guide 9.0.5

None of these issues prevent the ClaimCenter server from starting. ClaimCenter 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.
See also
• “DomainGraphKnownUnreachableTables” on page 46
• “Resolve archive graph warnings” on page 340
• “Resolving issues with custom archive entities” on page 341
• System Administration Guide

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 ClaimCenter 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. ClaimCenter logs the error but does not continue the
startup process.
• Validation graph warnings generate log entries but ClaimCenter continues to start.
See also
• “Validation of the archive domain graph” on page 337
• “Resolve archive graph errors” on page 339
• “Resolve archive graph warnings” on page 340
• “Resolving issues with custom archive entities” on page 341
• “About archive graph error messages” on page 343
• “Viewing the archive domain graph” on page 345
• “Using archive logging” on page 346

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 logging.properties. 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 config.xml.
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. ClaimCenter 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.

About archive domain graph errors 339

 Configuration Guide 9.0.5

5. Within ClaimCenter, navigate to Server Tools→Info Pages→Domain Graph Info.

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 construction.log that details how ClaimCenter constructed the graph.
• A domain.dot file that provides a representation of the archive domain graph in DOT format.
7. Using these tools, work through the reported warnings until ClaimCenter reports no more issues.

8. Enable archiving by setting configuration parameter ArchiveEnabled to true in file config.xml.

Result
It is now possible to start the application server with a fully valid archive domain graph.

Next steps
See also
• “Resolve archive graph warnings” on page 340
• “Resolving issues with custom archive entities” on page 341
• “Viewing the archive domain graph” on page 345
• System Administration Guide

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 ClaimCenter 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
ClaimCenter.
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.

Next steps
See also
• “Resolve archive graph errors” on page 339
• “Resolving issues with custom archive entities” on page 341
• System Administration Guide

340 chapter 22 The ClaimCenter archive domain graph

 Configuration Guide 9.0.5

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 ClaimCenter 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.
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 does Ensure that all custom archive entities implement the Extrac • “Archive entities and the
not implement table delegate. Also, ensure that any custom entity type you OverlapTable delegate” on
correct delegate create that can be both inside and outside the archive domain page 334
graph implements the OverlapTable delegate. • “Archive entities and the
Extractable delegate” on
page 333
• “Archive entity incorrect in
graph” on page 343
• “Overlap data entity not
handled properly” on page
344
b Foreign key Reverse the link ownership direction on one of the foreign • “Understanding ClaimCenter
ownership keys that cause the ownership cycle error. To change a link entity ownership” on page
relationships cause direction, use the archivingOwner attribute on a foreign key. 328
cycle in graph

About archive domain graph errors 341

 Configuration Guide 9.0.5

Graph Issue Resolution More information

c Foreign key link Set the archivingOwner attribute on the foreign key to sourc • “Archive entity incorrect in
from outside graph e. This prevents ClaimCenter from attempting to archive the graph” on page 343
to archive root in linked entity during an archive operation.
graph
d Foreign key link Do the following: • “<tag>” on page 218
from outside graph • Set the archivingOwner attribute on the foreign key to no • “Defining a cross-domain
points to non-root ne. tag” on page 342
archive entity in
• Add a CrossDomainPlublicID tag to the foreign key that
graph
specifies an alternate column to hold the PublicID of the
entity instance
The CrossDomainPlublicID tag forces the creation of an
additional column on the entity to store the publicID of the
target archive entity. ClaimCenter requires this ID in order to
re-establish the foreign key link upon retrieval of the Claim
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.
See also
• “Validation of the archive domain graph” on page 337
• “Resolve archive graph errors” on page 339
• “Resolve archive graph warnings” on page 340
• “Defining a cross-domain tag” on page 342
• “About archive graph error messages” on page 343
• “Viewing the archive domain graph” on page 345
• “Using archive logging” on page 346
• Integration Guide

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="http://guidewire.com/datamodel" 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>

342 chapter 22 The ClaimCenter archive domain graph

 Configuration Guide 9.0.5

See also
• “<tag>” on page 218
• “Understanding ClaimCenter entity ownership” on page 328

About archive graph error messages

If ClaimCenter 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.
See also
• “Validation of the archive domain graph” on page 337
• “Resolve archive graph errors” on page 339
• “Resolve archive graph warnings” on page 340
• “Resolving issues with custom archive entities” on page 341

Graph validation errors generated during server startup

If ClaimCenter 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.

gw.pl.exception.GWConfigurationException: Archiving graph validation failed. Error details:

The graph construction algorithm determined that the following are in the Claim graph.
[...]

To correct this:
1. To include the entity in Claim graph, please change them to implement Extractable.
OR
2. To avoid including it in Claim graph, foreignkey must point out of the Claim
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.
See also
• “Archive entities and the Extractable delegate” on page 333
• “Understanding ClaimCenter entity ownership” on page 328
• “Defining a cross-domain tag” on page 342

About archive graph error messages 343

 Configuration Guide 9.0.5

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.

gw.pl.exception.GWConfigurationException: 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.

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: entity.CustomEntity2.CustomOverlapTable.
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.
See also
• “Archive entities and the OverlapTable delegate” on page 334

Graph validation errors generated at run time

If ClaimCenter 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 ClaimCenter is unable store an
archive entity instance in the archive store.

Failed to archive claim: 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 Claim 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 342.

344 chapter 22 The ClaimCenter archive domain graph

 Configuration Guide 9.0.5

See also
• “The archive domain graph and reference data” on page 327

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.
For example, during the archiving process, ClaimCenter calls both internal method updateInfoOnArchive and
IArchiveSource method updateInfoOnStore. It is possible for either of these methods to update Recovery or
Payment objects in the archive bundle during the method call. If custom code creates event messages for any update
event for these objects, the archive process fails.
During the archive process and within the archive bundle, ClaimCenter 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 342
• 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
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 ClaimCenter 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.
dot.exe -Tpdf -opdf-file.pdf 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.

About archiving and event messages 345

 Configuration Guide 9.0.5

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 ClaimCenter 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.
dot.exe -Tpng -opng-file.png 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 ClaimCenter installation during the development
and testing phases of archive implementation. If you enable archive logging, ClaimCenter 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 ClaimCenter Server Tools Set Logging Level
screen that is available to system administrators. Restarting the application server resets any logging level set
through this screen.
See also
• “Viewing the archive domain graph” on page 345
• System Administration Guide

346 chapter 22 The ClaimCenter archive domain graph

part 5

User interface configuration

Configuration Guide 9.0.5
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 ClaimCenter uses page configuration format (PCF) files to render the ClaimCenter 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

 Configuration Guide 9.0.5

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 ClaimCenter 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
ClaimCenter.

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

 Configuration Guide 9.0.5

Next steps
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 a shared section because it is possible to share the element (or file) between multiple top-level
elements. ClaimCenter 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, ClaimCenter 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

Creating a new PCF file 351

 Configuration Guide 9.0.5

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.
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:
• ExposureDetailDV.Baggage
• ExposureDetailDV.Bodilyinjurydamage
• ExposureDetailDV.Content
• ExposureDetailDV.Employerliability
• ...
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 selectedAddress.CountryCode 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

 Configuration Guide 9.0.5

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
ExposureDetailDV.BusinessPropertydamage. To do this:

Procedure
1. Select the file that you intend to use as the template. For this example, select ExposureDetailDV.Baggage.
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
ExposureDetailDV.BusinessPropertydamage
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

ClaimCenter 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
AddressBookAdditionalInfoInputSet.PersonVendor with multiple modes:
• PersonVendor
• Attorney
• Doctor
To see this, open AddressBookAdditionalInfoInputSet.PersonVendor 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.

Working with shared or included files 353

 Configuration Guide 9.0.5

Menu command Use to... See

Change element Substitute a different element for the selected element. The dialog “Changing the type of an element”
type... contains a list of element types that you can substitute for the on page 358
selected element within the constraints of the PCF schema.
Edit comment... Attach a comment to any element on the canvas. “Adding a comment to an element”
on page 359
Delete comment Remove a comment from an element. “Adding a comment to an element”
on page 359
Disable element Disable an element by commenting out the widget. This prevents “Adding a comment to an element”
ClaimCenter from rendering the widget in the interface. on page 359
Enable element Enable a previously disabled element. This action removes the “Adding a comment to an element”
surrounding comment tags from the element. on page 359
Link widgets Link widgets on a parent page that spans multiple child PCF files. You “Linking widgets” on page 362
use this particularly for explicit iterator references.
Show included Toggle the visibility of child files embedded in a parent PCF file. If you “Page canvas overview” on page
sections disable the representation of the included files, Studio displays the 349
text of the reference expression instead.
Find by ID Find an element by its ID. The dialog contains a filter text field and a “Find a PCF element on the canvas”
list of all elements on the canvas that have their id attribute set: on page 360
Show element View the XML code for an element. Studio displays the XML code in a “View the source of a PCF element”
source pop-up window. 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

 Configuration Guide 9.0.5

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.

Structure tab 355

 Configuration Guide 9.0.5

If the child list represents a single child type, Studio adds a new child element. Studio selects the newly added child
automatically. 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.

Additional Description
tabs
Axes If an element can have DomainAxis and RangeAxis children, Studio displays the Axes properties tab. This tab
contains a child list of the DomainAxis and RangeAxis children for the selected element. If you select a RangeAx
is, 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 Points If an element can have LocationEntryPoint children, Studio displays the Entry Points properties tab. This tab
contains 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 Options If an element can have ToolbarFilterOption and ToolbarFilterOptionGroup children, Studio displays the
Filter Options properties tab. This tab contains a child list of the ToolbarFilterOption and ToolbarFilterOptio
nGroup children for the selected element.

Next If an element can have NextCondition children, Studio displays the Next Conditions properties tab. This tab
Conditions contains 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
checkbox for Enable client reflection, which indicates whether that element has a Reflect child. If you enable
client reflection, the Reflection tab also contains a properties list for the Reflect element and a child list for its R
eflectCondition children.

Required If an elements can have Require children, Studio displays the Required Variables properties tab. This tab contains
Variables a 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 Flags If an element can have ToolbarFlag children, Studio displays the Toolbar Flags properties tab. This tab contains a
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

 Configuration Guide 9.0.5

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.
ClaimCenter 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.

PCF elements 357

 Configuration Guide 9.0.5

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.

358 chapter 23 Using the PCF editor

 Configuration Guide 9.0.5

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.
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 ClaimCenter 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 ClaimCenter from rendering the
widget. In this case, however, the XML file retains the widget. It still exists server-side at run time, although

Working with elements 359

 Configuration Guide 9.0.5

ClaimCenter 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),
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.
360 chapter 23 Using the PCF editor
 Configuration Guide 9.0.5

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.

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.

Working with elements 361

 Configuration Guide 9.0.5

Linking widgets
A common feature in PCF pages is a ListView element controlled by a RowEditor iterator. ClaimCenter 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.
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
ClaimCenter user interface.

Page configuration files

The pages in the ClaimCenter user interface are defined by XML files stored within each installed instance of the
application. To configure your ClaimCenter 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 ClaimCenter/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 365

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 ClaimCenter interface, as
well as many things that you cannot see. For example, PCF elements include:
• Editors
• List views
• Detail views
• Buttons
• Popups
Introduction to page configuration 363
 Configuration Guide 9.0.5

• Other ClaimCenter interface elements

• Non-visible objects that support the ClaimCenter 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 ClaimCenter/modules/
pcf.html in your installation.
Every page in ClaimCenter uses multiple PCF elements. You define these elements separately, but ClaimCenter
renders then together during page construction. For example, consider the tab bar available on most ClaimCenter
pages:

Using Ctrl+Shift+W, you can discover that these elements are defined in the PCF file TabBar.pcf. In Guidewire
Studio, you can open TabBar.pcf 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 ClaimCenter 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:
Locations

Location
Page Wizard Worksheet Popup Forward
Group

Screen Screen Screen Screen

Screen
Screen

You can define the following types of locations:

364 chapter 24 Introduction to page configuration

 Configuration Guide 9.0.5

Location Description
Page A location with exactly one screen. The majority of locations defined in ClaimCenter 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
ClaimCenter.
Worksheet A page that can be shown in the workspace, the bottom pane of the web interface. The main advantage of
worksheets 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,
ClaimCenter 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
group of related pages. ClaimCenter can automatically display the appropriate menus and other interface elements
that allow users to navigate among these pages.

Widgets
A widget is an element that ClaimCenter can render into HTML. ClaimCenter 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 ClaimCenter 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:

Screen

Widget
Widget
Widget

Widget

Widget Widget

Identifying PCF elements in the user interface

To modify a particular page in ClaimCenter, 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:

Types of PCF elements 365

 Configuration Guide 9.0.5

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.
ClaimCenter 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 366
• “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 ClaimCenter 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:

366 chapter 24 Introduction to page configuration

 Configuration Guide 9.0.5

With this information, you can see the following:

• The location is a page named ClaimSummary, defined in the ClaimSummary.pcf file on line 10.
• The page contains a screen named ClaimSummaryScreen, defined in the ClaimSummary.pcf 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 ClaimCenter 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:

Identifying PCF elements in the user interface 367

 Configuration Guide 9.0.5

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 ClaimCenter 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 368

Browse the PCF hierarchy

About this task

You can browse the PCF elements under the Page Configuration folder in Guidewire Studio:

These elements are arranged in a folder hierarchy that is related to how they appear in the ClaimCenter 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, ClaimCenter displays a list of possible elements that match the ID you are entering.

368 chapter 24 Introduction to page configuration

 Configuration Guide 9.0.5

After you see the one you want, click on it and ClaimCenter 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.

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.

Getting started configuring pages 369

 Configuration Guide 9.0.5

Modifying style and theme elements

Changing or adding images
About this task
Images used in the application reside in ClaimCenter/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 ClaimCenter/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 370. However, you can change the theme colors of your application
by following these steps.
For more information about SASS, visit http://sass-lang.com.

Procedure
1. Open ClaimCenter/ThemeApp/packages/theme-9/sass/var/Component.scss in a text editor. This is
where all of the ClaimCenter 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.

Advanced theming
ClaimCenter 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 ClaimCenter/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.

370 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
ClaimCenter 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 371 – A series of widgets laid out in one or more columns.
• “List view panel” on page 376 – 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 371

 Configuration Guide 9.0.5

You can do the following:

• “Define a detail view” on page 372
• “Add columns to a detail view” on page 373
• “Format a detail view” on page 374

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:

372 chapter 25 Data panels

 Configuration Guide 9.0.5

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:

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:

Detail view panel 373

 Configuration Guide 9.0.5

ClaimCenter automatically places a vertical divider between the columns.

The full definition of the previous example produces the following two-column detail view:

Format a detail view

About this task
You can add the following formatting options to a detail view:
• “Label” on page 375
• “Input divider” on page 375
These are illustrated in the following diagram:

374 chapter 25 Data panels

 Configuration Guide 9.0.5

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:

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:

Format a detail view 375

 Configuration Guide 9.0.5

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:

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:

376 chapter 25 Data panels

 Configuration Guide 9.0.5

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:

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 ClaimCenter. 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 378.
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 377
• “Inline” on page 378

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:

Define a list view 377

 Configuration Guide 9.0.5

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:

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:

378 chapter 25 Data panels

 Configuration Guide 9.0.5

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 380.
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.
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
Claim.Activities. 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:

List view panel 379

 Configuration Guide 9.0.5

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 field An array field on an entity type is identified in the Data Dictionary as an array key. For example, the Officials
field on a Claim is an array key. Thus, you can define a list view based on Claim.Officials. 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 methods that return array data for use in a list view. The method must return either a Gosu array or a Java
list (java.util.list).
Query A query processor field on an entity type is identified in the Data Dictionary as a derived property returning gw.a
processor pi.database.IQueryBeanResult. It represents an internally-defined query, and usually provides a more
field convenient and efficient way to retrieve data. For example, the Claim.ViewableNotes 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 Claim.Notes array field, which loads both viewable and non-viewable notes and filtering the
non-viewable ones out later.
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
instances of an entity type. For example, the Activities page of the Desktop uses a list view based on the finder
method Activity.finder.getActivityDesktopViewsAssignedToCurrentUser.
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 Only the data on the first page shown is fetched and
rendering the list view. loaded.
Paging The full set of data is reloaded each time you move The query is re-run. Data is loaded only for the page that
to a different page within the list view. is viewable.
Sorting The full set of data is reloaded each time the list The query is re-run and sorted in the database.
view is sorted. Therefore, you can sort only on columns that exist in the
physical database, and not (for example) on virtual

380 chapter 25 Data panels

 Configuration Guide 9.0.5

Behavior Array-backed list view Query-backed list view

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.
view is filtered. Therefore, you can filter only on columns that exist in
the physical database, 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 for Short lists Long lists
Additional Do not use a query-backed editable list view in a wizard.
notes

List view panel 381

 Configuration Guide 9.0.5

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. ClaimCenter 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

 Configuration Guide 9.0.5

A location group must contain one or more references to another location. Any time that you navigate to the location
group, ClaimCenter 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:

384 chapter 26 Location groups

 Configuration Guide 9.0.5

Location groups as navigation

Depending on how a location group is used, ClaimCenter displays menus and other screen elements for navigating
to the locations within that group. Any time that you navigate to a location group, ClaimCenter 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 385
• “Location groups as menu links” on page 386
• “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:

This tab is defined in the element named TabBar (under the util folder):

This tab is defined with its action attribute set to Desktop.go(). 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:

Location groups as navigation 385

 Configuration Guide 9.0.5

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 ClaimCenter interface. As an
example, consider the Search page in ClaimCenter, shown in the following diagram:

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:

386 chapter 26 Location groups

 Configuration Guide 9.0.5

This is a location group defined in ClaimLossDetailsGroup as follows:

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 as navigation 387

 Configuration Guide 9.0.5

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
ClaimCenter 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.

Navigation 389
 Configuration Guide 9.0.5

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.

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
ClaimCenter 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 ClaimCenter 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, ClaimCenter 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

 Configuration Guide 9.0.5

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 Desktop.go().

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.

Tabs 391
 Configuration Guide 9.0.5

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, ClaimCenter 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: Search.Go().
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, ClaimCenter does not automatically add any other items to it.

392 chapter 27 Navigation

chapter 28

Configuring search functionality

ClaimCenter 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 ClaimCenter functionality in Gosu classes and modifying the ClaimCenter interface through page configuration
files.
You can customize only search functionality associated with the Search tab (and documents). You cannot customize
specialized searches for users and groups, for example.

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.

Search overview
ClaimCenter provides two types of search:
• Database search – Searches the relational database for claims, contacts, activities, checks, recoveries, and bulk
invoices by using the Structured Query Language (SQL). You access these searches from the Search tab.
ClaimCenter also includes database search from screens besides those accessed through the Search tab. For
example, you can do a database search for policies from the New Claim screen.
• Free-text search – Searches an external full-text database for claims by claim contact using the APIs of an
external full-text search engine. You access free-text search from the Search→Claims→Search by Contact screen.
Database search is fully enabled by default. Users can choose to include archived claims with each database search
request.
Free-text search is available as an option that you must enable and configure. Free-text search is available only for
searching for claims by claim contact. Free-text search results never include archived claims.

Configuring search functionality 393

 Configuration Guide 9.0.5

IMPORTANT The ClaimCenter base configuration does not allow free-text search of entity types other than claim
contacts. Guidewire will support customers in their development of additional search types.

ClaimCenter Search Architecture

Relational database

Simple and advanced

claim search
(database search)

ClaimCenter application

Claim updates

Real-time index Batch-load index

documents documents
Claim search by contact

Claim search by contact

(free-text search)

Full-text database

Free-text search involves two sets of data flows in which a user selects and reviews claims as well as updates them.
In the claim review data flows, the user searches, selects, and reviews claims with the ClaimCenter user interface.
Searching claims entails sending queries to and receiving claim results from a full-text search engine. Selecting and
reviewing claims entails requesting and receiving claims from a relational database:

Claim Review - ClaimCenter Free-Text Search Data Flows

2. ClaimCenter
1. User searches ClaimCenter Full-text search
application sends query
claims with basic or application engine
to full-text search engine.
free-text search.
3. Full-text search engine
returns query results to
ClaimCenter application.
4. User selects and
reviews claim from
query results. 5. Relational database
sends selected claim to
ClaimCenter application.
Relational
database

394 chapter 28 Configuring search functionality

 Configuration Guide 9.0.5

In the claim update data flow, the user updates claims or claim-associated contact information with the ClaimCenter
user interface. Updating claims and claim-associated contact information entails sending updates to a relational
database as well as sending an index document with the updates to a full-text search engine:

Claim Update - ClaimCenter Free-Text Search Data Flow

Relational
database
1. User updates claim or ClaimCenter 2. ClaimCenter application
contact information of a application sends update to relational
person associated with a database.
claim.

3. ClaimCenter application
sends index document
with updates to full-text
search engine.
Full-text search
engine

If you enable free-text search, the Search→Claims menu displays three options:
• Simple Search, Advanced Search – Displays fields on which to search for claims using database search.
• Search by Contact – Displays fields on which to search for claims using claim contacts and free-text search.
If you disable free-text search, the Search→Claims menu displays only the Simple and Advanced options.
Reasons that users choose a particular search screen include:
• Users want to search for claims by claim contact with commonly used criteria and receive results quickly, which
the Search by Contact screen provides.
• Users want to search claims with highly targeted criteria, which requires the Simple Search screen.
• Users want to search claims with partial names, phonetic names, or sounds-like names, which the Search by
Contact screen provides.
• Users want to search archived claims, which requires the Advanced Search screen.
An administrator hides the Search by Contact search screen while the free-text batch load command runs, but users
still can search claims with the Simple and Advanced options.

Search overview 395

 Configuration Guide 9.0.5

ClaimCenter Search Architecture (During Batch Load Process)

Relational database
Simple and advanced
claim search
(database search)

ClaimCenter application

Claim updates

Real-time index Batch-load index

documents documents
Claim search by contact

Claim search by contact

(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 411

Database search configuration

This section describes how to configure database search.

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.

ClaimCenter database search functionality

To search for a specific entity, select the Search tab from the ClaimCenter interface. In the base configuration, you
can search for the following:
• Claims
• Activities
• Checks
• Recoveries
• Bulk Invoices
During a search, ClaimCenter uses only those fields on the form for which you enter data. For example, if you
search for a Claimant and enter a Last Name but not a Policy Number, ClaimCenter omits Policy Number from the search.
396 chapter 28 Configuring search functionality
 Configuration Guide 9.0.5

For each search, the ClaimCenter user interface requires specific fields but others are optional. You can add, modify
or remove optional fields to the PCF file that provides the user interface. You cannot add required fields. Also, do
not modify or remove required fields specified in the ClaimCenter base search configuration.
The PCF files that define a particular search page reflect this division. You can find the search pages in Studio under
Page Configuration→pcf→search. Each search detail view references two subviews, each contained within their own
PCF. For example, ActivitySearchDV defines the detail view and includes the following two subviews:
• ActivitySearchRequiredInputSet
• ActivitySearchOptionalInputSet
During a search, the Guidewire application uses a search criteria object. Every field on the Search page maps to an
attribute on the relevant search criteria entity. For example, in the Activity search screen, the value that you set in the
Assigned To User field maps to ActivitySearchCriteria.AssignedToUser in the
ActivitySearchRequiredInputSet PCF file.
Note: Search criteria entities are virtual entities. A virtual entity has no underlying table in the ClaimCenter
database, and does not persist beyond the session in which you use it.
In most cases, each attribute on the search criteria entity maps to one attribute on the key entity. For drop-down
widgets, however, the search criteria object contains an attribute that points to an array, which can map to multiple
attributes on the key entity. The search-config.xml file maps search criteria to the target entities.
The fields in a search form correspond to entity attributes in the data model. You can customize the search process to
search by an attribute on the key entity or any of its related objects. For example, to use the Activity search screen
again, the value that you set in the Assigned To User field maps to ActivitySearchCriteria.AssignedToUser. The
search-config.xml file maps this attribute to Activity.AssignedUser.

Configuring database search criteria in XML

You use the search-config.xml file to define a mapping between the key data entities and the search criteria
entities. The entries in the file have the following basic structure:

<CriteriaDef entity="name" targetEntity="name">

<Criterion property="attributename" targetProperty="attributename" matchType="type"/>

<CriterionChoice property="name" init="value_or_expression">

<Option label="name" targetProperty="attributename"/>
<Option label="name" targetProperty="attributename"/>
...
</CriterionChoice/>

<ArrayCriterion property="attributename" targetProperty="attributename"

arrayMemberProperty="attributename"/>

</CriteriaDef>

You can map a single search criteria entity to more than one target entity.
For example, the ClaimSearchCriteria object has a <CriteriaDef> element associated with all of the following
entities:
• Claim
• ClaimInfo
• ClaimRpt
The ClaimRpt table contains denormalized claim financials information. By mapping to this table, ClaimCenter
increases search performance for financial related claim searches. An example of this type of search is searching for
a claim with a specific open reserve amount. By mapping to ClaimRpt, ClaimCenter avoids calculating financial
values within the search query itself.

Database search configuration 397

 Configuration Guide 9.0.5

Some search requirements are more complex than a simple one-to-one mapping. For example, the ClaimCenter
Search Claims page contains a Search For Date field. Properties such as Search for Date complicate search configuration
because a single column in the search criteria can match against one of several columns in the target. To handle
these cases, you use the <CriterionChoice> element, a subelement of the <CriteriaDef> element. A
<CriterionChoice> parameter matches an attribute on the search criteria entity against any one of a number of
target attributes.
Do not add new <CriteriaDef> elements into search-config.xml. 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 ClaimCenter installation.

WARNING Guidewire strongly recommends you do not remove <CriteriaDef> elements that exist in the base
configuration.

See also
• “The <CriteriaDef> element” on page 398
• “Free-text search configuration” on page 411
• Guidewire Contact Management Guide

Search criteria XML elements

The following table describes the XML elements in the search-config.xml file.

Element name Subelement Description More information

SearchConfig CriteriaDef Root element in search-config.xml.
CriteriaDef Criterion Specifies the mapping from a search criteria entity to “The <CriteriaDef> element”
CriterionChoice the target entity on which to search. on page 398
ArrayCriterion WARNING Do not add or remove CriteriaDef elements
in search-config.xml. Modify only the contents of
existing CriteriaDef elements.
Criterion Specifies how ClaimCenter matches a column (field) on “The <Criterion>
the search criteria to the query against the target entity. subelement” on page 399
Use this element to perform simple matching only.
Simple matches are criteria that match values in a single
column of the same type in the target entity.
CriterionChoice Option Defines specialized properties in the search criteria that “The <CriterionChoice>
can match multiple target fields. subelement” on page 400
Option Describes a single choice within a criterion choice. “The <Option> subelement”
on page 403
ArrayCriterion Specifies that the search query uses a simple join against “The <ArrayCriterion>
an array entity. subelement” on page 403

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.

398 chapter 28 Configuring search functionality

 Configuration Guide 9.0.5

<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 subelements.

<CriteriaDef> subelement Description More information

Criterion Performs simple, one-to-one mapping between a “The <Criterion> subelement” on page
criteria entity attribute and a target entity attribute. 399
CriterionChoice Matches an attribute on the search criteria entity “The <CriterionChoice> subelement” on
against any one of a number of target attributes. page 400
ArrayCriterion Creates a simple join against an array entity. “The <ArrayCriterion> subelement” on
page 403

The following table lists each search criteria object specified in search-config.xml and its corresponding entity
objects in ClaimCenter.

Search criteria object Entity

ActivitySearchCriteria Activity

Address Address

BulkInvoiceSearchCriteria BulkInvoice

CCNameCriteria ClaimContact
Company
Contact
ContactInfo
Person

ClaimInfoCriteria ClaimInfo

ClaimSearchCriteria Claim
ClaimInfo
ClaimRpt

DocumentSearchCriteria Document

PaymentSearchCriteria Check
CheckRpt

RecoverySearchCriteria Recovery

UserSearchCriteria Attribute
AttributeUser
AuthorityLimitProfile
User

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.

Configuring database search criteria in XML 399

 Configuration Guide 9.0.5

<Criterion property="attributename"
targetProperty="attributename"
forceEqMatchType="booleanproperty"
matchType="type"/>

These attributes have the following definitions.

<Criterion> attribute Required Description

property • The name attribute on the criteria entity. ClaimCenter 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 Criter
ion 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
criteria 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 performance,
second only to the contains match type. Use startsWith with
caution.

The <CriterionChoice> subelement

A <CriterionChoice> element matches a property on the search criteria entity against any one of a set of properties
on the target entity.
A <CriterionChoice> element uses the following syntax.

400 chapter 28 Configuring search functionality

 Configuration Guide 9.0.5

<CriterionChoice property="attributeName" init="valueOrExpression">

...
</CriterionChoice>

These attributes have the following definitions.

<CriterionChoice> attribute Required Description

property • One of the following:
• ArchiveDateCriterionChoice – Use to specify the options available to
restrict a date search on an archived object.
• DateCriterionChoice – Use to specify the options available to restrict a date
search.
• FinancialCriterion – Use to specify the options available to restrict a
financial field search.
init Gosu statement list that DateCriterionChoice and ArchiveDateCriterionChoic
e use to initialize the criterion choice.

A <CriterionChoice> element can have the following subelement.

<CriterionChoice> subelement Description

Option Describes a single choice within a criterion choice.

The ArchiveDateCriterionChoice and DateCriterionChoice property attribute values

You use the ArchiveDateCriterionChoice and DateCriterionChoice property values on a <CriterionChoice>
element as part of a larger search criteria <CriteriaDef> element. The use of the ArchiveDateCriterionChoice
value encapsulates the information entered by the user to restrict the search of archived objects to a particular date
range. The use of the DateCriterionChoice value encapsulates the information entered by the user to restrict the
search of unarchived objects to a particular date range.
The following example from the ClaimCenter ClaimSearchCriteria <CriteriaDef> element configured on the
Claim entity illustrates the use of this attribute.

<CriteriaDef entity="ClaimSearchCriteria" targetEntity="Claim">

...
<CiterionChoice property="DateCriterionChoice"
init="DateCriterionChoice.SearchType = &quot;claim&quot;;
DateCriterionChoice.DateSearchType = &quot;fromlist&quot;;
DateCriterionChoice.DateRangeChoice = &quot;n365&quot;;
DateCriterionChoice.ChosenOption = &quot;Java.Criterion.Option.Claim.LossDate&quot;">
<Option label="Java.Criterion.Option.Claim.LossDate" targetProperty="LossDate"/>
<Option label="Java.Criterion.Option.Claim.ReportedDate" targetProperty="ReportedDate"/>
<Option label="Java.Criterion.Option.Claim.CloseDate" targetProperty="CloseDate"/>
<Option label="Java.Criterion.Option.Claim.CreateDate" targetProperty="CreateTime"/>
</CriterionChoice>
...
</CriteriaDef>

The init attribute on the <DateCriterionChoice> element specifies how to restrict the date field. The user can
restrict the date range either through a typelist of preset ranges, such as the next 30 days, or through a specific start
and end date. The init attribute sets the following values.

Value Required Description

SearchType • A value from the SearchObjectType typelist. This value determines the entity on which to
search.

The <CriterionChoice> subelement 401

 Configuration Guide 9.0.5

Value Required Description

DateSearchType • A value from the DateSearchType typelist. In the base configuration, the possible values are:
• enteredrange
• fromlist
ClaimCenter renders a widget for DateCriterionChoice that you can use to enter a date range
either from a predefined list (fromlist) or by manually entering a range (enteredrange). This
value determines which method is the default choice in the widget.
DateRangeChoice • A value from the DateRangeChoiceType typelist. This value determines the default date range.
ClaimCenter filters the available ranges by the DateSearchType field. You use this only if DateSe
archType is set to fromlist.

ChosenOption The default date on which to search:

• If you use this field, set it to one of the option labels contained in this CriterionChoice
element.
• If you do not set this option, then this value defaults to <none selected>.

This <CriterionChoice> definition sets the available <Option> elements on which to search. In this case:
• Loss date
• Reported date
• Close date
• Create time
The following limitations apply:
• You cannot specify a match type for criterion choice entities because their matching algorithm is built into the
entity.
• Guidewire initializes <DateCriterionChoice> properties for the major searches in the base configuration
search-config.xml file. This configuration limits searches by date to improve performance on large databases,
in which searching a very large number of claims or activities (or both) can be resource intensive. Typically,
users do not expect their searches to be date limited. However, these limitations are necessary for acceptable
performance.
The use of the ArchiveDateCriterionChoice value has the same requirements and limitations as the
DateCriterionChoice value.

The FinancialCriterion property attribute value

You use the <FinancialCriterion> element as part of a larger search criteria <CriteriaDef> element. The
<FinancialCriterion> element encapsulates the information entered by the user to restrict the search to entities
with a money field within a given range.
For example, in ClaimCenter, the claim search page uses a <FinancialCriterion> element with multiple options.

<CriteriaDef entity="ClaimSearchCriteria" targetEntity="ClaimRpt">

<CriterionChoice property="FinancialCriterion">
<Option label="Java.Criterion.Option.Claim.OpenReserves" targetProperty="OpenReserves"/>
<Option label="Java.Criterion.Option.Claim.RemainingReserves" targetProperty="RemainingReserves"/>
<Option label="Java.Criterion.Option.Claim.TotalPayments" targetProperty="TotalPayments"/>
<Option label="Java.Criterion.Option.Claim.FuturePayments" targetProperty="FuturePayments"/>
<Option label="Java.Criterion.Option.Claim.TotalIncurredGross"/>
<Option label="Java.Criterion.Option.Claim.TotalIncurredNet"/>
</CriterionChoice>
</CriteriaDef>

The ClaimCenter payment search page uses a single option.

402 chapter 28 Configuring search functionality

 Configuration Guide 9.0.5

<CriterionChoice property="FinancialCriterion">
<Option label="Java.Criterion.Option.Payment.GrossAmount" targetProperty="GrossAmount"/>
</CriterionChoice>

The <Option> subelement

You can specify zero or more <Option> subelements on a <CriterionChoice> element. If you specify a single
Option, ClaimCenter limits the choice to that single option for the criterion.
The <Option> subelement contains the following attributes.

<Option> attribute Required Description

label • Display key that indicates the choice. ClaimCenter uses this text to display the option to the
user in a select control.
targetProperty Target column against which ClaimCenter matches the user-input value. Do not use a virtual
property on an entity as the target column.
WARNING The targetProperty attribute is optional, but Guidewire requires you to specify
this attribute if you add a new <Option> element. Omitting this attribute on a new option can
cause ClaimCenter to operate incorrectly.

The <ArrayCriterion> subelement

An <ArrayCriterion> element instructs ClaimCenter to add a simple join against an array entity to the search
query. You add the <ArrayCriterion> subelement to a <CriteriaDef> element. An <ArrayCriterion>
subelement uses the following syntax.

<CriteriaDef>
<ArrayCriterion property="someName" targetProperty="someTargetProperty"
arrayMemberProperty="someArrayMember"/>
...
</CriteriaDef>

The following table describes the attributes of the <ArrayCriterion> element.

<ArrayCriterion> attribute Required Description

property • The name attribute given for the column (field) on the search criteria entity. The
search uses this value to fetch the user-entered input value on the criteria entity.
targetProperty • The name attribute of the array on the target entity.

arrayMemberProperty • The name attribute of a column (field) in the array member type. For example, if targ
etProperty refers to an array of entity type X instances, then arrayMemberProperty
is a column (field) on instances of entity type X.

The <CriterionChoice> subelement 403

 Configuration Guide 9.0.5

The following limitations and requirements apply to array criteria:

• Array criteria support equality matching only. You cannot specify a matchType attribute on array criteria.
• The array property on the target entity must not allow duplicate values because a single target entity instance
would appear multiple times in the search results.
• You must define two compound unique indexes on the array table. These indexes enforce the restriction against
duplicate values in the array on the target entity, and they help improve search performance.
◦ One index first specifies the foreign key column to the target entity that contains the array. The index then
specifies the array member property, which is the column in the array table that provides values for the array on
the target entity. This index enforces uniqueness of array values on the target entity.
◦ The other index specifies the same columns in reverse order. This index helps improve search performance.
The following example demonstrates the indexes required on an array entity type that provides values for an
array on the Claim entity type.

<foreignkey name="ClaimID" fkentity="Claim" nullok="false" exportable="false"

desc="Related claim."/>
...
<column name="ExampleCode" type="shorttext"/>
...
<index name="ind1" unique="true">
<indexcol name="ClaimID" keyposition="1"/>
<indexcol name="ExampleCode" keyposition="2"/>
</index>
<index name="ind2" unique="true">
<indexcol name="ExampleCode" keyposition="1"/>
<indexcol name="ClaimID" keyposition="2"/>
</index>

See also
• “Add an optional array search field” on page 407

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.

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.

404 chapter 28 Configuring search functionality

 Configuration Guide 9.0.5

WARNING For performance reasons, Guidewire expressly prohibits the addition of new required fields or
changing the match type of existing required fields in the ClaimCenter search screens.

Customizing a database search

You can customize search in several ways. For example, you can modify the existing optional search criteria or you
can add your own new, optional search criteria. However, you cannot add new, required search criteria or modify
existing required search criteria.
Note: Do not change the match type of optional search criteria that the base configuration provides in search-
config.xml, because ClaimCenter ignores these changes.

Working with optional search criteria

To add an entirely new optional search criterion, you must do the following:
• To use a new field as a searchable column, add an extension field to a base configuration entity or one of its
related entities.
• Add an extension field to the search criteria entity.
• Add a Criterion, CriterionChoice or ArrayCriterionChoice element to file search-config.xml.
• Configure the new widget in the search PCF file.
See also
• “Extending a base configuration entity” on page 238
• “The <Criterion> subelement” on page 399
• “The <CriterionChoice> subelement” on page 400
• “The <ArrayCriterion> subelement” on page 403
• “Using the PCF editor” on page 349

Add an optional search field

About this task

In this example, you add an extension field on the Claim entity called PercentComplete. You can use this field to
search on claims that are 90% complete.

Procedure
1. Add an extension field named PercentComplete to the Claim entity:
a. In the Studio Project window, navigate to configuration→config→Extensions→Entity.
b. Double-click Claim.etx to open the entity extension if it exists, or right-click Entity to create a new entity
extension of the Claim entity.
c. In the Field drop-down, select column. If column is selected already, click Add .
A new row appears at the bottom of the list on the left, with column as the Element value.
d. In the list on the right, set the following attribute values.

name PercentComplete

type percentagedec

null ok true

desc Percentage of claim that is complete

2. Add a field named PercentComplete as an extension to the ClaimSearchCriteria entity:

Database search configuration 405

 Configuration Guide 9.0.5

a. In the Project window, navigate to configuration→config→Extensions→Entity.

b. Double-click ClaimSearchCriteria.etx to open the entity extension if it exists, or right-click Entity to
create a new entity extension of the ClaimSearchCriteria entity.
c. In the Field drop-down, select column. If column is selected already, click Add .
A new row appears at the bottom of the list on the left, with column as the Element value.
d. In the list on the right, set the following attribute values.

name PercentComplete

type percentagedec

null ok true

desc Percentage of claim that is complete

3. Add a <Criterion> element to the search-config.xml file for the extension field PercentComplete.
a. In the Project window, navigate to configuration→config→search, and then double-click search-
config.xml to open the file.
b. In the XML editor, locate the <CriteriaDef> element for the ClaimSearchCriteria with Claim as the
target entity, and then add a <Criterion> for the PercentComplete field.

<CriteriaDef entity="ClaimSearchCriteria" targetEntity="Claim">

<Criterion property="ClaimNumber" matchType="eq"/>
<Criterion property="AssignedToUser" targetProperty="AssignedUser" matchType="eq"/>
...
<!-- Example extension -->
<Criterion property="PercentComplete" matchType="ge"/>
</CriteriaDef>

Guidewire recommends that appropriate indexes be in place whenever you change search criteria. For
example, if PercentComplete is the most restrictive equality condition in your search implementation,
consider adding an index with this PercentComplete as the leading key column.
c. Within file search-config.xml, increment the file version number before you save the file.

<?xml version="1.0" encoding="UTF-8"?>

<SearchConfig xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="search-config.xsd"
version="1">
...

Guidewire recommends that you increment the version number whenever you modify the search-
config.xml file, although doing so is not a technical requirement.
4. Add a display key for the PercentComplete fields:
a. In the Project window, navigate to configuration→config→Localizations.
b. Double-click display_en_US.properties to open the file.
c. Find the group of display keys that begin with JSP.ClaimSearch.Claims, and then add the following
line.

JSP.ClaimSearch.Claims.PercentComplete = Percent Complete

The Display Keys editor displays the new line in gray lettering to indicate that the display key is an
unused property.
d. Repeat the preceding steps for each additional language that you support in your installation of
ClaimCenter. For _en_US, substitute the Java locale code of each additional language, and provide an
appropriate localization of “Percent complete”.

406 chapter 28 Configuring search functionality

 Configuration Guide 9.0.5

5. Add an editable field labeled Percent Complete to the configuration of the claim search page:
a. In the Project window, navigate to configuration→config→Page Configuration→pcf→search→claims, and then
double-click ClaimSearchOptionalInputSet.pcf to open the file.
b. From the Toolbox tab, search for Basic Inputs. Then, drag the generic Input widget type onto the page
canvas.
For example, place the new Input widget in the Optional parameters section, directly under the Claim Status
field.
c. In the Properties tab at the bottom of the screen, set the following values.

editable true

id Completion

label displaykey.JSP.ClaimSearch.Claims.PercentComplete

required false

value ClaimSearchCriteria.PercentComplete

6. Restart Guidewire Studio.

7. Regenerate the application SOAP and Java APIs and the Data Dictionary:
a. Open a command window and navigate to the application directory.
b. Type the following commands:

gwb genJavaApi
gwb genDataDictionary

8. Restart the application server.

9. Log in to Guidewire ClaimCenter and navigate to the Search Claims→Advanced Search page. Verify that your
optional claim search field exists.

Result
The claim search page contains your new field as a searchable option. Separately, you must provide a way to assign
the percentage complete on claims. For example, you might provide a new field on one of the claim screens.

Next steps
See also
• Installation Guide

Add an optional array search field

About this task

In this example, you create an entity type named ClaimCode for codes that you want to assign to claims. Then, you
add an array field on the Claim entity type called ClaimCodes so that users can classify claims by one or more codes
of the ClaimCode entity type. You can use this array field to search for claims that have a specific code.

Procedure
1. Create an entity type named ClaimCode to use as an array field on the Claim entity type:
a. In the Project window, navigate to configuration→config→Extensions→Entity.
b. Right-click Entity, and then select New→Entity.
c. In the Entity dialog, enter the following information.

Customizing a database search 407

 Configuration Guide 9.0.5

Field Value or action

Entity ClaimCode

Entity Type Select entity.

Desc Code associated with a claim.

Table claimcode

Type Select retireable.

Extendable Select the check box.

Exportable Select the check box.

Final Clear the check box.

d. Click OK.
The new file ClaimCode.eti opens.
e. Add the following elements, with the specified attribute values.

Element Attribute Value or action

implementsEntitiy name Extractable

column name Code

type varchar

desc Claim code

columnParam name size

value 30

foreignkey name ClaimID

fkentity Claim

nullok false

desc Related claim

exportable Clear the check box

index name ind1

indexcol name ClaimID

position 1

indexcol name Code

position 2

index name ind2

indexcol name Code

position 1

indexcol name ClaimID

position 2

2. Add an array field named ClaimCodes to the Claim entity:

a. In the Project window, navigate to configuration→config→Extensions→Entity.
b. Double-click Claim.etx to open the entity extension if it exists, or right-click Entity to create a new entity
extension of the Claim entity.

408 chapter 28 Configuring search functionality

 Configuration Guide 9.0.5

c. In the Field drop-down list, select array. If array is selected already, click Add .
A new row appears at the bottom of the list on the left, with array as the Element value.
d. In the list on the right, set the following attribute values.

name ClaimCodes

arrayentity ClaimCode

desc Set of claim codes associated with this claim

owner true

3. Add a field named ClaimCode as an extension to the ClaimSearchCriteria entity:

a. In the Project window, navigate to configuration→config→Extensions→Entity.
b. Double-click ClaimSearchCriteria.etx to open the entity extension if it exists, or right-click Entity to
create a new entity extension of the ClaimSearchCriteria entity.
c. In the Field drop-down, select column. If column is selected already, click Add .
A new row appears at the bottom of the list on the left, with column as the Element value.
d. In the list on the right, set the following attribute values.

name ClaimCode

type varchar

desc Claim code

e. In the Field drop-down, select columnParam. If columnParam is selected already, click Add .
A new row appears at the bottom of the list on the left, with columnParam as the Element value.
f. In the list on the right, set the following attribute values.

name size

value 30

4. Add an <ArrayCriterion> element to the search-config.xml file for the extension field ClaimCode.
a. In the Project window, navigate to configuration→config→search, and then double-click search-
config.xml to open the file.
b. In the XML editor, locate the <CriteriaDef> element for the ClaimSearchCriteria with Claim as the
target entity, and then add a <ArrayCriterion> element for the ClaimCode field.

<CriteriaDef entity="ClaimSearchCriteria" targetEntity="Claim">

<Criterion property="ClaimNumber" matchType="eq"/>
<Criterion property="AssignedToUser" targetProperty="AssignedUser" matchType="eq"/>
...
<!-- Example extension -->
<ArrayCriterion property="ClaimCode" targetProperty="ClaimCodes" arrayMemberProperty="Code"/>
</CriteriaDef>

c. Within file search-config.xml, increment the file version number before you save the file.

<?xml version="1.0" encoding="UTF-8"?>

<SearchConfig xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="search-config.xsd"
version="1">
...

Guidewire recommends that you increment the version number whenever you modify the search-
config.xml file, although doing so is not a technical requirement.
5. Add a display key for the ClaimCode field label:
Customizing a database search 409
 Configuration Guide 9.0.5

a. In the Project window, navigate to configuration→config→Localizations.

b. Double-click display_en_US.properties to open the file.
c. Find the group of display keys that begin with JSP.ClaimSearch.Claims, and then add the following
line.

JSP.ClaimSearch.Claims.ClaimCode = Claim Code

The editor displays the new line in gray lettering to indicate that the display key is an unused property.
d. Repeat the preceding steps for each additional language that you support in your installation of
ClaimCenter. For _en_US, substitute the Java locale code of each additional language, and provide an
appropriate localization of “Claim Code”.
6. Add an editable field labeled Claim Code to the configuration of the claim search page:
a. In the Project window, navigate to configuration→config→Page Configuration→pcf→search→claims, and then
double-click ClaimSearchOptionalInputSet.pcf to open the file.
b. From the Toolbox tab, search for Basic Inputs, and then drag the generic Input widget type onto the page
canvas.
For example, place the new Input widget in the Optional parameters section, directly under the Claim Status
field.
c. In the Properties tab at the bottom of the screen, set the following values.

editable true

id ClaimCode

label displaykey.JSP.ClaimSearch.Claims.ClaimCode

required false

value ClaimSearchCriteria.ClaimCode

7. Restart Guidewire Studio.

8. Regenerate the application SOAP and Java APIs and the Data Dictionary:
a. Open a command window and navigate to the application directory.
b. Type the following commands:

gwb genJavaApi
gwb genDataDictionary

9. Restart the application server.

10. Log in to ClaimCenter and navigate to the Search Claims→Advanced Search page. Verify that your optional
search field exists.

Result
The search page now contains a field on which you can search by claim codes. Separately, you must provide a way
to assign codes to a claim. For example, in ClaimCenter, you can provide a new field on one of the claim screens.

410 chapter 28 Configuring search functionality

 Configuration Guide 9.0.5

Next steps
See also
• Installation Guide

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 ClaimCenter 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.)
• All CriterionChoice property attributes specify foreign key links to entities that implement the
SearchCriterionChoice interface.
• All CriterionChoice init property attributes execute without errors against a newly created criterion choice
entity of the appropriate type.
• All Option label attributes reference valid display keys.
• All ArrayCriterion arrayMemberProperty attributes reference searchable properties on the array member
entity.
See also
• “The <CriteriaDef> element” on page 398
• “The <Criterion> subelement” on page 399
• “The <CriterionChoice> subelement” on page 400
• “The <Option> subelement” on page 403
• “The <ArrayCriterion> subelement” on page 403

Free-text search configuration

This topic describes how to enable and configure free-text search for ClaimCenter.
See also
• Installation Guide
• Integration Guide

Database search configuration 411

 Configuration Guide 9.0.5

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 ClaimCenter.
• Embedded – Supported only in development environments, the Guidewire Solr Extension runs automatically as
part of ClaimCenter in the application server instance that runs ClaimCenter, 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 ClaimCenter application.
• The Guidewire Solr Extension, a modified version of the Apache Solr full-text search engine.
• The Guidewire free-text batch load command.
• The Solr Data Import batch process that you run from the Batch Process page on the Internal Tools tab in the
ClaimCenter application. The Solr Data Import batch process is an alternative to running the free-text batch load
command. You must use the Solr Data Import batch process instead of the batch load command whenever you
configure free-text search for embedded operation.
• Internal sort routine, a limited option in the ClaimCenter application to assist the batch load process. Internal sort
is a substitute for the Solr Data Import sort routine. The internal sort routine sorts data sets with fewer than
10,000 claim-claim contact pairs locally and without distributed processing. Internal sort is for development and
testing platforms only. Guidewire does not support its use on production-level platforms.
The components of the free-text search feature depend on configuration parameters and configuration files in two
primary locations: the ClaimCenter 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 ClaimCenter. While guidance
and caveats come later, the following four options are possible regardless of whether ClaimCenter 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 ClaimCenter. 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 ClaimCenter runs in
a clustered configuration or in an unclustered configuration.
In the development environment alone, Guidewire Solr Extension and ClaimCenter 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 ClaimCenter. Guidewire also recommends that larger customers running either
Guidewire Solr Extension or ClaimCenter 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.

412 chapter 28 Configuring search functionality

 Configuration Guide 9.0.5

Free-text search system architecture in a production environment

The following diagram illustrates the system architecture for free-text search if you run ClaimCenter 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.

ClaimCenter Free-Text Search Production Environment and Development Environment

System Architecture in External Operation

application server database server

Guidewire ClaimCenter
database engine

Free-text search

application server

ISolrSearchPlugin
Guidewire Solr Extension
ISolrMessageTransportPlugin

Free-text batch load command

Guidewire ClaimCenter home directory Guidewire Solr home directory

config.xml cc/cc-gwsolr.xml
claimcontact-search-config.xml cc/solr/solr.xml
solrsearch-config.xml cc/solr/claimcontact_active/conf
schema.xml
solrconfig.xml
used by the free-text batch load command
Legend
Running software batchload.sh|batchload.bat
Configuration files data-congif.xml
batchload-config.xml
Host computer

SQL-based data exchange

Text-based data exchange

Note: Guidewire supports running the separate application server instances for ClaimCenter 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 ClaimCenter in a
development environment. In a development environment, you may configure free-text search for either external
operation or embedded operation.

Free-text search system architecture 413

 Configuration Guide 9.0.5

ClaimCenter Free-Text Search Development Environment System Architecture in Embedded Operation

database server

database engine

application server

Guidewire ClaimCenter

Free-text search

Server Tools > Batch Process Info >

Solr Data Import

Guidewire Solr Extension

ISolrSearchPlugin

ISolrMessageTransportPlugin

Guidewire PolcyCenter home directory Guidewire Solr home directory

config.xml cc/cc-gwsolr.xml
claimcontact-search-config.xml cc/solr/solr.xml
solrsearch-config.xml cc/solr/claimcontact_active/conf
schema.xml
solrconfig.xml

Legend
Running software

Configuration files

Host computer

SQL-based data exchange

Text-based data exchange

With embedded operation, the Solr Data Import batch process on the Batch Process page of the Internal Tools tab is
available as the 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 ClaimCenter home directory and a separate Guidewire Solr home directory.

414 chapter 28 Configuring search functionality

 Configuration Guide 9.0.5

Configuration parameters and files for free-text search in ClaimCenter

The following parameters and files enable and configure free-text search in ClaimCenter:
• FreeTextSearchEnabled – Defined as a configuration parameter in config.xml, enables certain back-end
components of free-text search to fully operate. The default value is false.
• claimcontact-search-config.xml – Provides detailed configuration of the fields that free-text search extracts
from the ClaimCenter database and sends to the full-text search database for indexing and searching.
• solrserver-config.xml – Configures how ClaimCenter 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 81
• “Configuring the Guidewire Solr Extension” on page 416

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 ClaimCenter
sends for indexing and how the Guidewire Solr Extension responds to search requests from ClaimCenter.
• cc-gwsolr.xml – Defines the Guidewire Solr home directory for the Guidewire Solr Extension.
• solr.xml – Defines the location in the Guidewire Solr home directory of the core for each searchable entity type
in the Guidewire Solr Extension.
• schema.xml – Defines fields of data as known in the Guidewire Solr Extension.
See also
• “Configuring the Guidewire Solr Extension” on page 416
• “Configuring free-text search for indexing and searching” on page 428

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
ClaimCenter database through native SQL commands and loads the extracted data into the Guidewire Solr
Extension.
• data-config.xml – 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 search.xml.
• batchload-config.xml – 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.
• batchload.sh/batchload.bat – Runs the free-text batch load command. The file sets the following
environment variables:
◦ APP_PREFIX – The designation for ClaimCenter 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 ClaimCenter
files
◦ CONFIGFILE – The batchload-config.xml file to use
See also
• “Configuring the free-text batch load command” on page 428

Enabling free-text search in ClaimCenter

Full-text search is disabled in the base configuration of ClaimCenter. 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
Free-text search configuration parameters and files 415
 Configuration Guide 9.0.5

embedded operation. After you complete the setup of free-text search, you enable free-text search in ClaimCenter
with:
• SolrDestFilter rules in the EventFired rule set
• The free-text search plugins ISolrMessageTransportPlugin and ISolrSearchPlugin
• The free-text message destination SolrMessageTransport.ClaimContact.Name
None of the preceding free-text resources in ClaimCenter 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 ClaimCenter off and on temporarily.

Enable free-text search in ClaimCenter

Before you begin
Follow the instructions for setting up free-text search:
• Installation Guide

Procedure
1. Start ClaimCenter 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 EventFired.grs in the Rules editor, and then ensure that the SolrDestFilter
rules are enabled.
3. Enable free-text search:
a. In the Project window, navigate to configuration→config.
b. Double-click config.xml to open it in the XML editor, and then set FreeTextSearchEnabled to true.
4. Start the ClaimCenter 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.

***** CCSolrMessageTransportPlugin 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 cc

Next steps
See also
• Installation Guide
• Integration Guide

Configuring the Guidewire Solr Extension

You configure the Guidewire Solr Extension separately from configuring your ClaimCenter instance.

416 chapter 28 Configuring search functionality

 Configuration Guide 9.0.5

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:
• cc-gwsolr.xml – Defines the Guidewire Solr home directory for the Guidewire Solr Extension.
• solr.xml – Defines global properties and configuration settings for the Guidewire Solr Extension.
• solrserver-config.xml – Configures how ClaimCenter 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 ClaimCenter 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 cc-gwsolr.zip 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 cc-
gwsolr.zip file.
See also
• Installation Guide

Configuring connections with the Guidewire Solr Extension

You configure instances of the Guidewire Solr Extension and how ClaimCenter connects with them in the
solrserver-config.xml file. Two XML elements help in this type of configuration: the <document> element and
the <solrserver> element.

The <document> element

In solrserver-config.xml, for each type of index document, such as claim contact data, a <document> element
associates that data type with an instance of the Guidewire Solr Extension. For example:

<document name="claimcontact" servername="my_solr_instance"/>

The servername attribute specifies a <solrserver> element defined elsewhere in the solrserver-config.xml
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 solrserver-config.xml, for each instance of the Guidewire Solr Extension, a <solrserver> element defines
its type of operation and how ClaimCenter connects with it.

<solrserver name="name" type={"embedded"|"http"|"cloud"} [env="env-variable-value"]>

Configuring the Guidewire Solr Extension 417

 Configuration Guide 9.0.5

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 ClaimCenter.
• http – The Guidewire Solr Extension operates externally from ClaimCenter, as a single server.
• cloud – The Guidewire Solr Extension operates externally from ClaimCenter, 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 solrserver-config.xml, 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 solrserver-config.xml to reference the <solrserver> element for the
instance that you want to use.
However, switching between server instances by editing solrserver-config.xml 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 solrserver-config.xml file contains the following document
definitions.

<document name="claimcontact" archive="true" servername="embedded"/>

<document name="claimcontact" archive="true" servername="localhttp" env="local"/>

In the preceding example, ClaimCenter runs with the embedded server by default. ClaimCenter does so for two
reasons. The first reason is because ClaimCenter 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 ClaimCenter with the external server hosted locally instead, start ClaimCenter with the Java VM
environment variable -Dgw.cc.env=local. In this case, ClaimCenter looks for the <document> element with the
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 solrserver-config.xml
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"]>

ClaimCenter supports the embedded type only in development environments. ClaimCenter 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 ClaimCenter application, not as an
application in a different application server instance. Therefore, embedded server definitions do not specify HTTP
connection information. ClaimCenter supports embedded operation only in development environments.

418 chapter 28 Configuring search functionality

 Configuration Guide 9.0.5

The following example in solrserver-config.xml 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="claimcontact" archive="false" servername="embeddedSolr"/>

The name attribute lets you bind document types, such as claim contacts, to a server that has cores for them. A
<document> element may reference a <solrserver> element of type embedded only if you run the ClaimCenter
application in development mode. Otherwise, ClaimCenter 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 cc-gwsolr.zip file as solrroot. In a typical development environment, the home
directory is on the same host as the one that hosts your ClaimCenter application. Free-text search creates the
directory specified by solrroot during server startup if the directory does not exist and extracts the files from cc-
gwsolr.zip 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/ClaimCenter/solr/pc-gwsolr.zip"/>
</solrserver>
...
<document name="claimcontact" archive="false" servername="embeddedSolr"/>

For embedded operation on Tomcat, you must include the gwsolrzip parameter to specify the absolute path to the
cc-gwsolr.zip file in your ClaimCenter home directory.
See also
• “Configuring the Guidewire Solr Extension for provisioning” on page 421

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 ClaimCenter. Therefore, external server definitions must specify HTTP
connection information.
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 solrserver-config.xml 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="claimcontact" archive="false" servername="localhost"/>

The name attribute of the <solrserver> element lets you bind a document type, such as claim contact, 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 ClaimCenter application. If you run the Guidewire Solr Extension on the same machine that runs ClaimCenter,
specify localhost for the host parameter. Otherwise, specify the host name for the remote host.

Configuring the Guidewire Solr Extension for embedded or external operation 419
 Configuration Guide 9.0.5

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 ClaimCenter
waits for the Guidewire Solr Extension to respond to a connection request. The readtimeout parameter specifies
how long ClaimCenter 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 422

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.

420 chapter 28 Configuring search functionality

 Configuration Guide 9.0.5

Setting the logging level to WARN or ERROR requires modifying the logging.properties file. You can access this
file at the following location in Guidewire Studio:
configuration→config →logging
In the logging.properties file, set log4j.category.org.apache.solr either to WARN or ERROR. Ensure that one
of the following lines is present in the file:

log4j.category.org.apache.solr=WARN

log4j.category.org.apache.solr=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:
•
•
•

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
solrserver-config.xml 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 ClaimCenter/gwsolr/cc-
gwsolr.zip to the solrroot directory every time you start the ClaimCenter 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 ClaimCenter
application.

Example Provisioning Configuration

The following example in solrserver-config.xml 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 418

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 cc-gwsolr.zip file. You must do so after modifying files in ClaimCenter Studio but before restarting
the ClaimCenter application.

Configuring the Guidewire Solr Extension 421

 Configuration Guide 9.0.5

Procedure
1. Start ClaimCenter Studio.
2. In the Project window, navigate to configuration→config→solr.
3. Double-click solrserver-config.xml 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 ClaimCenter 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 cc-gwsolr.zip file in PolicyCenter/solr.

8. Start the ClaimCenter application.
Free-text search deploys the contents of cc-gwsolr.zip to the directory specified by solrroot. Files already
in solrroot are overwritten by new files from cc-gwsolr.zip.

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 ClaimCenter does not include the ZooKeeper software.
Configuration for high availability requires you to modify the following files:
• solrserver-config.xml – ClaimCenter file that configures ClaimCenter to connect with SolrCloud servers in a
ZooKeeper ensemble
• zoo.cfg – 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 ClaimCenter 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 ClaimCenter, use cc 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 cc.
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 solrserver-config.xml shows a typical configuration of a server with high availability.
422 chapter 28 Configuring search functionality
 Configuration Guide 9.0.5

<solrserver name="cloud" type="cloud">

<param name="zkhosts" value="gwsolr1,gwsolr2,gwsolr3/cc"/>
</solrserver>

Configure solrserver-config.xml for high availability

Procedure
1. Start ClaimCenter Studio.
2. In the Project window, navigate to configuration→config→solr.
3. Double-click solrserver-config.xml 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 cc as the value of chroot.
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/cc"/>
</solrserver>

Next steps
You must now perform the following tasks:
• “Install ZooKeeper” on page 423
• “Configuring zoo.cfg ” on page 424

Install ZooKeeper

Before you begin

You must perform the following task before you install ZooKeeper:
• “Configure solrserver-config.xml for high availability” on page 423

Procedure
1. Download version 3.4.6 from the Apache ZooKeeper web site.
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
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

Configuring the Guidewire Solr Extension for high availability 423

 Configuration Guide 9.0.5

Next steps
You must now perform the following task:
• “Configuring zoo.cfg ” on page 424

Configuring zoo.cfg
In zoo.cfg, you configure a single ZooKeeper member server. Each ZooKeeper member within an ensemble has its
own copy of zoo.cfg. The zoo.cfg file configures a ZooKeeper server with its client port. ClaimCenter 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 zoo.cfg 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 ClaimCenter and Guidewire Solr
Extension servers. The value for clientPort must match the port specified for the server in the zkhosts
parameter of solrserver-config.xml. The port defaults to 2181 in both zoo.cfg and solrserver-
config.xml.
• 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 zoo.cfg 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 ClaimCenter 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 zoo.cfg 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.

424 chapter 28 Configuring search functionality

 Configuration Guide 9.0.5

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 zoo.cfg.
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
zoo.cfg.
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:

https://archive.apache.org/dist/lucene/solr/ref-guide/apache-solr-ref-guide-4.10.pdf
https://zookeeper.apache.org/doc/r3.1.2/zookeeperAdmin.html

Communicating with Guidewire Solr Extension in high availability

The following diagram illustrates the communicative arrangement of a ClaimCentercluster, 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:

ClaimCenter Cluster Zookeeper Ensemble

CC 1 ZK 1 TCP:
2888,
TCP: 2181 3888

CC 1 CC 1 ZK 2 ZK 3

SolrCloud Server Cluster

TCP: 2181
HTTP(S): 8983
HTTP(S):
Solr 1 8983 Solr 4

Solr 2 Solr 3

Configuring the Guidewire Solr Extension for secure transport (HTTPS)

You can configure ClaimCenter and the Guidewire Solr Extension to use the Hypertext Transfer Protocol Secure
(HTTPS) communication protocol to exchange data. By default, ClaimCenter 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 the Guidewire Solr Extension for high availability 425
 Configuration Guide 9.0.5

authenticating the ClaimCenter 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 ClaimCenter 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 ClaimCenter 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 ClaimCenter and a single instance of the Guidewire Solr Extension to use secure transport, set the
securetransport parameter in solrserver-config.xml 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>

ClaimCenter inserts a host property in solr.xml, in the following format, whenever you run the gwb packageSolr
command:

<str name="host">${serverHost:127.0.0.1}</str>

Note: If you modify solr.xml manually for any reason, ClaimCenter no longer inserts a host property when you
run the gwb packageSolr command.
The base configuration of ClaimCenter does not include solr.xml. To create a solr.xml file to edit in Studio or to
retain changes that you make to solr.xml in GWSOLR_HOME/cc/solr, copy the file in GWSOLR_HOME/cc/solr. In
ClaimCenter Studio, navigate in the Project window to configuration→config→solr, and then, from the menu, click
Edit→Paste.
ClaimCenter uses host number 127.0.0.1 by default for locally hosted instances of the Guidewire Solr Extension.
For remotely hosted instances, override the value in the JVM where ClaimCenter runs using the serverHost system
property. For example, if your application server is Tomcat, create or edit the shell script setenv.sh or, on
Windows, the batch file setenv.bat 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 solr.xml. Change the port definition in solr.xml 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 cc-solr.zip file to deploy to the Guidewire Solr home directory.

Cloud configuration for secure transport (HTTPS)

To configure ClaimCenter 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 solrserver-config.xml.

426 chapter 28 Configuring search functionality

 Configuration Guide 9.0.5

Instead, ClaimCenter provides Guidewire versions of the ZooKeeper command line interface, shell script
(gwzkcli.sh) and batch file (gwzkcli.bat). These command files are located in the following deployment
directory:

/opt/gwsolr/cc/scripts

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 /cc/clusterprops.json {"urlScheme":"https"}

• On Windows

gwzkcli -zkhost localhost:2181 -cmd put /cc/clusterprops.json {\"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 /cc

gwzkcli -zkhost localhost:2181 -cmd put /cc/clusterprops.json {\"urlScheme\":\"https\"}
gwzkcli -Dbootstrap_conf=true

Public key certificates

You must configure the application servers in which ClaimCenter and the Guidewire Solr Extension run with public
key certificates. The HTTPS protocol uses these certificates to authenticate the ClaimCenter and the Guidewire Solr
Extension instances when they open connections with each other. The application servers for each instance of
ClaimCenter 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 (batchload.sh) or
batch file (batchload.bat) for the batch load command.

-Djavax.net.ssl.trustStore=pathToTrustStore -Djavax.net.ssl.trustStorePassword=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 the Guidewire Solr Extension for secure transport (HTTPS) 427
 Configuration Guide 9.0.5

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 claim contacts.
• schema.xml – Defines search fields as known in the Guidewire Solr Extension
• claimcontact-search-config.xml – Defines the mapping between ClaimCenter fields and full-text search
fields and configures how the full-text fields are indexed and searched
• data-config.xml – 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 claim contact 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.
See also
• “Modifying free-text search for additional fields” on page 429
• 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/cc/solr/claimcontact_active/conf

The following files configure the free-text batch load command:

• batchload.sh/batchload.bat – Specifies the batch load configuration file to use for your database brand.
• batchload-config.xml – 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 ClaimCenter database.

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.

See also
• Installation Guide

Configuring the Search by Contact screen for free-text search

The following table provides implementation details for each field on the Search→Claims→Search by Contact screen.
The columns contain the following information:
• Field – The field on the Search by Contact screen.
• Entity – The entity type of the object that corresponds to this field.
• Search type – Exact or inexact depending upon the search type.
Use the following information to configure the Search by Contact screen for free-text search.

Field Entity Search type

Role ClaimSearchCriteria.FreeTextNameSearchType Exact

428 chapter 28 Configuring search functionality

 Configuration Guide 9.0.5

Field Entity Search type

Name ClaimSearchCriteria.NameCriteria.Name Inexact
Phone ClaimSearchCriteria.NameCriteria.Phone Exact
Address ClaimSearchCriteria.AddressCriteria.AddressLine1 Inexact
City ClaimSearchCriteria.AddressCriteria.City Inexact
State ClaimSearchCriteria.AddressCriteria.State Exact
Used to filter search results.
Postal Code ClaimSearchCriteria.AddressCriteria.PostalCode Exact
Used to filter search results.
Date Multiple Date objects, depending on user selection. Exact
Used to filter search results.

Note: ClaimSearchCriteria is used to map input fields on the search screen, and FreeTextClaimSearchResults
is used to map the results received from Solr.

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 ClaimCenter. 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
ClaimCenter displays the first page of results.
For advanced claim contact search, modify the SolrClaimContactSearchPanelSet page configuration file. View
and edit the file in the Project window in Studio by navigating to Page Configuration (PCF)
→search→SolrClaimContactSearchPanelSet.
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.

Configuring the Search by Contact screen for free-text search 429

 Configuration Guide 9.0.5

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 ClaimCenter:

Configuration file Description

claimcontact-search-config.xml Defines the mapping between ClaimCenter fields and Guidewire Solr Extension
fields, and configures how the Guidewire Solr Extension indexes and searches its
index documents.
ClaimCenter/modules/configuration/config/search/claimcontact‑search‑con
fig.xml

CCSolrSearchPlugin.gs The implementation class for the free-text plugin ISolrSearchPlugin. This plugin
sends search criteria to the Guidewire Solr Extension and receives the search results.
ClaimCenter/modules/gsrc/gw/solr/CCSolrSearchPlugin.gs

CCSolrMessageTransportPlugin 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 ClaimCenter database.
EventFired.grs (SolrDestFilter rule) Rules file containing a top level rule that defines which entities and which events on
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 file Description More information

schema.xml Defines the document schema structure http://wiki.apache.org/solr/SchemaXml
for the Guidewire Solr Extension. https://archive.apache.org/dist/lucene/solr/
Provides general configuration for how ref-guide/apache-solr-ref-guide-4.10.pdf
Guidewire Solr Extension uses a
document, the index definition for a
document, and the analyzers available
for index assignment or usage.
/opt/gwsolr/cc/solr/claimcontact_active/conf/schema.xml

data-config.xml Defines where to locate and how to http://wiki.apache.org/solr/DataImportHandler#Configu

interpret data from the batch load ration_in_data-config.xml-1
command. Set to read-only mode at
start-up.
/opt/gwsolr/cc/solr/claimcontact_active/conf/data‑config.xml

The following table lists the configuration files for the free-text batch load command.

Configuration file Description

batchload.bat|batchload.sh Represents the batch load command.

/opt/gwsolr/cc/solr/claimcontact_active/conf/batchload.sh

430 chapter 28 Configuring search functionality

 Configuration Guide 9.0.5

Configuration file Description

batchload-config.xml Contains database connection information and brand-specific native SQL for selecting data
from the ClaimCenter relational database.
/opt/gwsolr/cc/solr/claimcontact_active/conf/batchload-config.xml

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 ClaimCenter base configuration does not support free-text search of entity types other than claim
contacts. 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/cc/solr/claimcontact_active/conf/schema.xml

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.

Defining a new free-text field in ClaimCenter

Use the following file to define a new free-text field in ClaimCenter.

ClaimCenter/modules/configuration/config/search/claimcontact-search-config.xml

Access the file in the Project window in Studio by navigating to configuration→config→search claimcontact-
search-config.xml. ClaimCenter defines the format of this file.

Modifying free-text search for additional fields 431

 Configuration Guide 9.0.5

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 claimcontact-search-config.xml, 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="root.ClaimContactAddress.PostalCode"/>
</IndexField>

The definition specifies that values of postalCode fields in the index documents sent to the full-text engine come
from addresses on claim contacts, 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="root.PostalCodeCriteria"/>
<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.

Defining a new free-text field in the batch load command

To load data from an existing ClaimCenter database, the new free-text field must be listed in the batchload-
config.xml files and the data-config.xml file. You decide whether to include or exclude the field from the digest
that prevents duplicate index entries.

432 chapter 28 Configuring search functionality

 Configuration Guide 9.0.5

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
...
addr.PostalCode
...
FROM cc_contact co
INNER JOIN cc_claimcontact cc
ON cc.contactid = co.id
INNER JOIN cc_claim cl
ON cc.ClaimID = cl.ID
LEFT OUTER JOIN cc_address a
ON co.PrimaryAddressID = a.id
...

The query is processed into an XML document that will be loaded into SQL. Batch loading of XML into Solr is
described in http://wiki.apache.org/solr/DataImportHandler#Configuration_in_data-config.xml-1.
The processed field names are all in upper case, and the structure of the XML document is:

<CONTAINER_ELEM>
<CLAIMCONTACT>
<!-- data for one claim contact -->
</CLAIMCONTACT>
</CONTAINER_ELEM>

To include the postalCode in the index, put an entry in data-config.xml that looks like the following XML code:

<field column="postalCode" xpath="/CONTAINER_ELEM/CLAIMCONTACT/POSTALCODE"/>

Within the row for one claim contact, 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.

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:

http://wiki.apache.org/solr/LanguageAnalysis

Free-text search configuration 433

 Configuration Guide 9.0.5

434 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 ClaimCenter interface. This section explains the print capabilities and
how to use them.

Overview of print functionality

You can use the ClaimCenter print functionality to print the data visible on a ClaimCenter screen. You can control
both the output format and which screen objects are printed. Most commonly, pages print as PDF. ClaimCenter 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.
From ClaimCenter, you can print:
• The entire organization tree
• Object lists such as the Activities list on the Desktop
• Object details such as detailed information about a contact
ClaimCenter also provides a “print claim file” feature. You use this feature to print, with a single action, all of the
information for a claim or to choose which parts of the file to print. You can configure this functionality to suit your
company’s requirements. See “Working with a PrintOut page” on page 437 for details.
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 config.xml control the default print settings globally. For information
on configuration parameters, see “Application configuration parameters” on page 41.

Configuring special page functions 435

 Configuration Guide 9.0.5

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.
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: http://www.w3.org/TR/REC-CSS2.

Security related to printing

The system permission lvprint allows a user to print the information that appears in a list view. The system
permission clmprint allows a user to print a claim.

Gosu classes for printing

The Gosu package gw.api.print 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 ClaimCenter:
• Location printing that prints the current page in PDF
• List view printing that prints a list in PDF or CSV format
• Customizable printing that provides a list of print options

Location printing
Adding the ability to print the current location in PDF format is straightforward to configure. You add a
PrintToolbarButton element to a Screen element. For example, the following lines in the DashboardClaimCount
PCF file create a Print button in the toolbar:

<Page
canVisit="perm.User.viewedbclaimcounts"
id="DashboardClaimCount"
title="DisplayKey.get(&quot;Java.Dashboard.Title&quot;, DisplayKey.get(&quot;Java.Dashboard.ClaimCount.Title&quot;))
">

436 chapter 29 Configuring special page functions

 Configuration Guide 9.0.5

<LocationEntryPoint
signature="DashboardClaimCount(GroupInfo : web.dashboard.DashboardTreeGroupInfo)"/>
...
<Screen
id="DashboardClaimCountScreen">
<Toolbar>
<PrintToolbarButton
available="perm.User.printlistviews"
id="PrintButton"
label="DisplayKey.get(&quot;Button.Print&quot;)"/>
<ToolbarDivider/>
...
</Screen>
</Page>

Clicking this button causes the current location, DashboardClaimCount, to print. You can also refer to another
location in the print bar by providing a locationRef.

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=gw.api.print.ListViewPrintOptionPopupAction.printListViewWithOptions(&quot;MyListView&quot;)"
id="PrintButton"
label="DisplayKey.get(&quot;Java.ListView.Print&quot;)"/>

Customizable printing
Customizable printing uses a print options page to control exactly what ClaimCenter prints. This PCF page contains
a PrintOut element that is comparable to a Screen element. Using a PrintOut page, you can:
• Print an entire page or select parts of a page to print.
• Print a list view or a list view and its item details.
• Apply a filter to a list view before printing it.
ClaimCenter uses customizable printing to print the claim file.
You can only print a list view’s items in detail using customizable print. Not all list views are eligible for printing
details. Only list views that are screen panels are eligible for detail printing—for example a CardPanel element or
the ListViewPanel in Claim Workplan. You cannot print the detail for lists embedded in detail views.

Working with a PrintOut page

IMPORTANT This section explains the configuration of the ClaimPrintOut PCF page. Guidewire recommends
that you refrain from creating your own PrintOut pages. Instead, Guidewire recommends that you modify the
existing ClaimPrintOut PCF page, limiting yourself to adding support for your subtypes and extensions.

A PrintOut page is always interactive. The page displays one or more groups of radio buttons and check boxes that
control what ClaimCenter actually prints. To use a PrintOut page, you define print elements in a single PCF file.
For organizational purposes, the file name usually contains the word print or is stored in a print directory.
ClaimCenter contains a single PrintOut page, ClaimPrintOut.pcf.
To call this PrintOut file, you trigger an action from a menu item or button that calls the page:

<MenuItem
action="ClaimPrintout.push(Claim)"

Types of printing configuration 437

 Configuration Guide 9.0.5

id="ClaimMenuActions_Print"
label="DisplayKey.get(&quot;Java.ClaimMenu.PrintClaim&quot;)"/>

The page takes the current claim as a variable and offers various options to print the claim.

PrintOut attributes and subelements

A PrintOut page has the following attributes and subelements. Required elements and attributes appear in bold.

<PrintOut canVisit="expression" desc="string" id="string" parent="string" title="string">

<LocationEntryPoint signature="string"/>
<Variable initialValue="expression" name="string" recalculateOnRefresh="boolean" type="string"/>
<PrintOutButton action="string" desc="string" hideIfEditable="boolean" hideIfReadOnly="boolean"
id="string" label="expression" shortcut="string"/>
<NonDownloadPrintOutButton action="string" desc="string" hideIfEditable="boolean"
hideIfReadOnly="boolean" id="string" label="expression" shortcut="string"/>
<Verbatim desc="string" hideIfEditable="boolean" hideIfReadOnly="boolean" id="string" label="string"
labelStyleClass="string" visible="expression" warning="boolean" />
<PrintGroup customizable="boolean" id="string" label="string" printable="expression">
<PrintSection id="string" label="string" printable="expression">
<PrintOption id="string" label="string" printable="expression">
<PrintOptionLocation filter="expression" listViewRef="string" locationRef="string"
printable="string">
<PrintDetail locationRef="string" symbolName="string" symbolTpye="string"/>
</PrintOptionLocation>
</PrintOption>
<PrintOptionGroup id="string" printable="expression" typelist="string">
<PrintOptionLocation filter="expression" listViewRef="string" locationRef="string"
printable="string">
<PrintDetail locationRef="string" symbolName="string" symbolTpye="string"/>
</PrintOptionLocation>
</PrintOptionGroup>
</PrintSection>
</PrintGroup>
<PrintLocation id="string" label="expression" printable="expression">
<PrintLocationDetail baseLocation="string" filter="expression" listViewRef="string"
locationRef="string" printable="expression" symbolName="string" symbolTpye="string"/>
<PrintLocationDetail />
</PrintLocation>
<Code/>
</PrintOut>

Each PrintOut page must contain at least one of either PrintGroup or PrintLocation. A PrintOut page can
contain both PrintGroup or PrintLocation elements. The following PrintOut configuration subelements are
specific to customizable printing:

Element Description
PrintDetail Instructions on how to print elements if you elect to print details.
PrintGroup Defines a set of pages to print. This element contains one or more PrintSection elements.
ClaimCenter represents each PrintSection element in the interface with a radio button. You can
customize a PrintGroup. See “Customizable printing” on page 437 for more information on using a
customizable group.
PrintLocation Specifies a specific location to print. This element takes one or more PrintLocationDetail elements.
PrintLocationDetail Instructions on how to print elements if you elect to print details. ClaimCenter represents each print
element in the interface with a radio button.
PrintOption A set of locations that are printed together. Each PrintOption contains one more PrintOptionLocat
ion subelements.

PrintOptionLocation Specifies a page (location) to print any time that you select a PrintGroup. This element can contain
one PrintDetail.
PrintOutButton Adds a button to a PrintOut page. This element triggers printing if you select print options, or if you
cancel and close the page.

438 chapter 29 Configuring special page functions

 Configuration Guide 9.0.5

Element Description
PrintSection Represents a print selection on a PrintOut page. Each PrintSection must contain one or more Prin
tOption elements.

With the exception of the PrintDetail element, all of the PrintOut subelements specify a printable attribute.
This attribute takes a boolean expression that determines if the print option is visible. If the expression evaluates to
true, the option appears.

Printing all claim pages with and without detail

The All pages excluding details option is represented in the file by a single PrintGroup element. A PrintGroup defines
a set of pages to print. Each set is contained in a PrintSection element. The individual pages appear as
PrintOptionLocation elements within a PrintOption. The following section illustrates the definition for the claim
workplan pages:

<PrintGroup id="AllClaimPagesWithoutDetails"
label="DisplayKey.get(&quot;Java.PrintClaimOptionsForm.Label.AllClaimPagesWithoutDetails&quot;)">
...
<PrintSection
id="Workplan1Section"
label="DisplayKey.get(&quot;Java.PrintClaimOptionsForm.Label.Workplan&quot;)"
printable="perm.System.viewworkplan">
<PrintOption
id="WorkplanSummaryOption"
label="DisplayKey.get(&quot;Java.PrintClaimOptionsForm.Options.Workplan.Summary&quot;)">
<PrintOptionLocation locationRef="ClaimWorkplan(Claim)"/>
</PrintOption>
</PrintSection>
...
</PrintGroup>

The All Pages including details and FNOL snapshot option is defined in a second PrintGroup that allows you to print the
details of each page. This is accomplished through the addition of the optional PrintDetail element.

<PrintSection
id="Workplan2Section"
label="DisplayKey.get(&quot;Java.PrintClaimOptionsForm.Label.Workplan&quot;)"
printable="perm.System.viewworkplan">
<PrintOption
id="WorkplanDetailsOption"
label="DisplayKey.get(&quot;Java.PrintClaimOptionsForm.Options.Workplan.Details&quot;)">
<PrintOptionLocation
locationRef="ClaimWorkplan(Claim)">
<PrintDetail
locationRef="ActivityDetailPrint(Activity)"
symbolName="Activity"
symbolType="Activity"/>
</PrintOptionLocation>
</PrintOption>
</PrintSection>

You can configure only one list view to print for each screen. The locationRef attribute specifies a page that takes
the specified symbolName and symbolType and processes them for printing. The page in this case is the pcf/
shared/printing/ActivityDetailPrint.pcf page. This page takes the ClaimPrintOut.pcf as a parent.
The file that defines the action list view determines what you specify for the symbolName and symbolType attributes.
In this case, that file is the pcf/claim/workplan/WorkplanLV.pcf. This file populates itself from an array of
Activity elements:

<ListViewPanel id="WorkplanLV">
...
<Require name="ActivityList" type="gw.api.database.IQueryBeanResult&lt;Activity&gt;"/>
...
<RowIterator
editable="false"

Working with a PrintOut page 439

 Configuration Guide 9.0.5

elementName="Activity"
hasCheckBoxes="true"
value="ActivityList"
valueType="gw.api.database.IQueryBeanResult&lt;entity.Activity&gt;">
...

This page requires an Activity type and elements of this type are named Activity. In the print out page, the
symbolType originates from the valueType value in the list view and the symbolName from the elementName value.

Printing the current page with and without detail

To print the current page, the page on which a user initiated the print action, you use PrintLocation elements. To
print the entire page without details, you supply a single PrintLocation:

<PrintLocation
id="CurrentClaimFilePagePrint"
label="DisplayKey.get(&quot;Java.PrintClaimOptionsForm.Label.ThisPageWithoutDetails&quot;)"/>

To print the detail on a page, you need to account for the details on each possible page—based on the location of the
print action. In the case of a claim, the action appears in the side menu and so can appear from any page in the claim.
For example:

<PrintLocation
id="CurrentClaimFilePagePrintWithDetails"
label="DisplayKey.get(&quot;Java.PrintClaimOptionsForm.Label.ThisPageWithDetails&quot;)">

<PrintLocationDetail
baseLocation="ClaimWorkplan"
locationRef="ActivityDetailPrint(Activity)"
symbolName="Activity"
symbolType="Activity"/>

<PrintLocationDetail
baseLocation="ClaimAssociations"
locationRef="ClaimAssociationDetail(Claim, ClaimAssociation)"
symbolName="ClaimAssociation"
symbolType="ClaimAssociation"/>
...
<PrintLocationDetail
baseLocation="ClaimMatters"
locationRef="MatterDetailPage(Claim, Matter)"
symbolName="Matter"
symbolType="Matter"/>
</PrintLocation

The specification of the locationRef, symbolName, and symbolType all use the same principles as the
PrintDetail element.

Configuring a customizable PrintGroup

A customizable PrintGroup appears as regular radio buttons. If a user selects the button, ClaimCenter displays a list
of checkbox and drop-down options. PrintSection subelements appear as check boxes. PrintOption subelements
display as accompanying drop-down menus. For example, the following

<PrintGroup id="Custom" label="DisplayKey.get(&quot;Java.Printout.Custom&quot;)" customizable="true">

...
<PrintSection id="WorkplanSection"
label="DisplayKey.get(&quot;Java.PrintClaimOptionsForm.Label.Workplan&quot;)"
printable="perm.System.viewworkplan">
<PrintOption id="WorkplanSummaryOption"
label="DisplayKey.get(&quot;Java.PrintClaimOptionsForm.Options.Workplan.Summary&quot;)">
<PrintOptionLocation locationRef="ClaimWorkplan(Claim)"/>
</PrintOption>
<PrintOption id="WorkplanDetailsOption"
label="DisplayKey.get(&quot;Java.PrintClaimOptionsForm.Options.Workplan.Details&quot;)">
<PrintOptionLocation locationRef="ClaimWorkplan(Claim)">
<PrintDetail
locationRef="ActivityDetailPrint(Activity)"

440 chapter 29 Configuring special page functions

 Configuration Guide 9.0.5

symbolName="Activity"
symbolType="Activity"/>
</PrintOptionLocation>
</PrintOption>
</PrintSection>
...
</PrintGroup>

This group gives you the option to print each section of the claim file either with details or without.

Filtering a list view

You can apply a filter to a list view to control what is or is not printed out. To define a filter, you specify a filter
attribute on whichever of the PrintOptionLocation or the PrintLocationDetail element applies. The following
example illustrates the use of a filter:

<PrintSection
id="History3Section"
label="DisplayKey.get(&quot;Java.PrintClaimOptionsForm.Label.History&quot;)"
printable="perm.System.viewclaimhistory">
<PrintOption
id="HistoryAllOption"
label="DisplayKey.get(&quot;Java.ListView.Filter.All&quot;)">
<PrintOptionLocation
filter="gw.api.util.CoreFilters.ALL"
listViewRef="HistoryLV"
locationRef="ClaimHistory(Claim)"/>
</PrintOption>
<PrintOptionGroup
id="HistoryOption"
typelist="HistoryType">
<PrintOptionLocation
filter="new gw.api.filters.TypeKeyFilter(VALUE,
History#Type.PropertyInfo as gw.entity.ITypekeyPropertyInfo)"
listViewRef="HistoryLV"
locationRef="ClaimHistory(Claim)"/>
</PrintOptionGroup>
</PrintSection>

The print section has two filters, both applied to the HistoryLV.pcf list view. Configure your list view to use any
valid and relevant list view filter. For example, use an exposure filter, rather than an activity filter, on an exposure
list.

Overriding the print settings in a file

Within an individual PCF file, you can override any of the global print settings that you set globally in the
config.xml file. You use the Gosu class, gw.api.print.PrintSettings, to perform the override. The following
example shows how to override the global font size in a dialog:

<Page
canEdit="false"
canVisit="Claim.ExposureListChangeable and perm.Claim.view(Claim) and perm.System.viewexposures
and (Claim.State != ClaimState.TC_DRAFT)">
id="ClaimExposures"
title="DisplayKey.get(&quot;Web.Claim.ClaimExposures&quot;)"
...
<Variable name="PrintTargetLV" initialValue="&quot;ExposuresLV&quot;" type="java.lang.String"/>
<Variable name="PrintSettings" type="gw.api.print.PrintSettings"
initialValue="createPrintSettings()"/>
<Variable name="PrintClaimNumber" type="String"
initialValue="DisplayKey.get(&quot;Web.PrintOut.ClaimNumber&quot;, Claim.ClaimNumber)"/>
...
<Toolbar>
....
<ToolbarButton label="DisplayKey.get(&quot;Java.ListView.Print&quot;)" id="ClaimExposures_Print"
shortcut="N"
available="perm.User.printlistviews and perm.Claim.print(Claim)"
action="gw.api.print.ListViewPrintOptionPopupAction.printListViewWithOptions(PrintTargetLV,
PrintSettings)"/>
...

Working with a PrintOut page 441

 Configuration Guide 9.0.5

<Code>
function createPrintSettings() : gw.api.print.PrintSettings {
var newPrintSettings = new gw.api.print.PrintSettings();
var claimNumberLabel = DisplayKey.get("Web.PrintOut.ClaimNumber", Claim.ClaimNumber);
newPrintSettings.setHeaderLabel(claimNumberLabel);
newPrintSEttings.setFontSize("12px");
return newPrintSettings;
}
</Code>
</Page>

These print settings apply only if you print the page by itself—the Print button action sets them before printing. If
you print this page as part of a claim file, the settings do not apply.

Troubleshooting print configurations

If you run into problems with the display of a printed page, for example elements overlap, you can try the following:
• Adjust the print widths of the columns using the Gosu class, PrintSettings.
• Hide unwanted columns and print only the necessary columns. Unlike a screen, the printed page is limited by the
available width.
• Change the font size of the printed page using the Gosu class, PrintSettings, in a list view.

Linking to a specific page using an EntryPoint PCF

It is possible to connect directly to ClaimCenter using a URL that leads to a specific ClaimCenter page. You can
define your own links or entry points. Thus, if the ClaimCenter server receives a connect request from an external
source and the request has both the correct format and parameters, ClaimCenter serves the requested page.
In the base configuration, ClaimCenter 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.

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 ClaimCenter server receives a connection request with a specific entry point, ClaimCenter
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.

442 chapter 29 Configuring special page functions

 Configuration Guide 9.0.5

The EntryPoint PCF contains the following parameters:

authenticationRe Specifies that ClaimCenter must authenticate the user before the user can access the URL. If true,
quired ClaimCenter requires that the user already be authenticated to enter. If the user is not already logged in,
ClaimCenter 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 ClaimCenter can not 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 ClaimCenter 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,
ClaimCenter, as the URI.
For example, if the URI is XXX, then it is possible to enter the application at http://myserver/myapp/XX
X.do.

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 444 for a definition of a forward.

Each EntryPoint PCF can contain one or more EntryPointParameter subelements that specifies additional
functionality.

Linking to a specific page using an EntryPoint PCF 443

 Configuration Guide 9.0.5

The EntryPointParameter subelement has the following attributes:

conversionExpression Gosu expression that ClaimCenter uses to convert a URL parameter to the value passed to the
location parameter.
desc Currently, does nothing.
locationParam Required. The name of the LocationParameter on the EntryPoint target location that this
parameter sets.
optional Specifies whether the parameter is optional. If set to true, ClaimCenter does not require this
parameter.
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:
http://myserver/myapp/Activity.do?Activity=3

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 location.You 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.

444 chapter 29 Configuring special page functions

 Configuration Guide 9.0.5

For an example of how to define a forward, see ClaimForward in ClaimCenter Studio at pcf→claim→ClaimForward.

Linking to a specific page using an ExitPoint PCF

It is possible to create a link from a ClaimCenter 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 ClaimCenter
screen.
In the base configuration, ClaimCenter 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
ClaimCenter 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
ClaimCenter. 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 AnyURL.pcf 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.

Linking to a specific page using an ExitPoint PCF 445

 Configuration Guide 9.0.5

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 ClaimCenter. 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 446.

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 445.

About this task

After you create the ExitPoint PCF, you need to link its functionality to a ClaimCenter 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 Button.Activity.DynamicURL 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 — Button.Activity.DynamicURL
• 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 "http://www.guidewire.com" }

446 chapter 29 Configuring special page functions

 Configuration Guide 9.0.5

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.
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 – AnyURL.push(constructMyURL())
• id – DynamicURL
• label – displaykey.Button.Activity.DynamicURL

Next steps
After completing this task, complete “Step 3: Test your work” on page 447.

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 446.

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 ClaimCenter 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 ClaimCenter data model, which would require a server restart.
2. Log into ClaimCenter 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. ClaimCenter presents a success message after it
reloads the PCF files from the local file system.
5. Log into ClaimCenter 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 ClaimCenter 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, ClaimCenter loads the Guidewire Internet home page into the
popup window.

Creating an ExitPoint PCF 447

 Configuration Guide 9.0.5

448 chapter 29 Configuring special page functions

part 6

Workflow, activity patterns, and email

configuration
Configuration Guide 9.0.5
chapter 30

Using the workflow editor

This topic covers basic information about the workflow editor in Guidewire Studio.

Workflow in Guidewire ClaimCenter

Guidewire ClaimCenter uses workflow primarily to support MetroReport integration. Guidewire defines and stores
each base configuration workflow process as a separate file in the following directory:

ClaimCenter/modules/cc/config/workflow

Each file name corresponds to the workflow process that it defines (for example, MetroReport.1.xml). 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:

ClaimCenter/modules/configuration/config/workflow

See also
• “Guidewire workflow” on page 455.

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 451

 Configuration Guide 9.0.5

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
representation to visualize the workflow. You also use it to edit the defining values for each step and
branch.
4 Property view Studio displays detailed properties for the selected step or branch, much of which you can modify.

For example, in the ClaimCenter base configuration, Guidewire defines a MetroReportWorkflow 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 Editor Description More information

<Context> Every workflow begins with a <Context> block. You use it to conveniently “<Context> workflow
define symbols that apply to the workflow. element” on page 461

452 chapter 30 Using the workflow editor

 Configuration Guide 9.0.5

Element Editor Description More information

<Start> Defines the step on which the workflow starts. It optionally contains Gosu “<Start> workflow
blocks to set up the workflow or its business data. It runs before any other element” on page 461
workflow step.
AutoStep Defines a workflow step that finishes immediately, without waiting for time “AutoStep workflow
to pass or for an external trigger to activate it. step” on page 463
MessageStep Supports messaging-based integrations. It automatically generates and “MessageStep workflow
sends a single integration message and then stops the workflow until the step” on page 464
message completes. (Typically, this is through receipt of an ack return
message.) After the message completes, the workflow resumes
automatically.
ActivityStep An ActivityStep is similar an AutoStep, except that it can use any of the “ActivityStep workflow
branch types, such as a TRIGGER or a TIMEOUT, to move to the next step. step” on page 465
However, before an ActivityStep branches to the next step, it waits for
one or more activities to complete.
ManualStep Defines a workflow step that waits for someone—or some thing—to invoke “ManualStep workflow
an external trigger or for some period of time to pass. step” on page 466
GO Indicates a branch or transition to another workflow step. It occurs only “GO” on page 469
within 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 page 470
within a ManualStep workflow step. Branching occurs only upon manual
invocation from outside the workflow.
TIMEOUT Indicates a branch or transition to another workflow element. It occurs only “TIMEOUT” on page
within a ManualStep workflow step. Branching to another workflow step 472
occurs only after a specific time interval has passed.
Outcome Indicates a possible outcome for the workflow. This step is special. It “Outcome workflow
indicates that it is a last step, out of which no branch leaves. step” on page 468
<Finish> (Optional) Defines a Gosu script to run at the completion of the workflow to “<Finish> workflow
perform any last clean up after the workflow reaches an outcome. It runs element” on page 461
after all other workflow steps.

Understanding workflow steps

Each workflow step represents a location in the workflow. It does not have a business meaning outside of the
workflow. Therefore, it is permissible to use whatever IDs you want and arrange them however it is most convenient
for you. (Beware, however, of infinite cycles between steps. ClaimCenter 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 460.

Type Workflow contains Icon Step Description

AutoStep Zero, one, or more Step that ClaimCenter guarantees to finish immediately. See “AutoStep
workflow step” on page 463.

Understanding workflow steps 453

 Configuration Guide 9.0.5

Type Workflow contains Icon Step Description

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 466.

ActivityStep Zero, one, or more Step that waits for one or more activities to complete before
continuing. See “ActivityStep workflow step” on page 465.

MessageStep Zero, one, or more Special-purpose step designed to support messaging-based

integrations. See “MessageStep workflow step” on page 464.

Outcome One or more Special final step that has no branches leading out of it. See “Outcome
workflow step” on page 468.

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 workflow step name Select Rename from the right-click menu. This opens the Rename StepID dialog in which
you can enter the new step name.
To change a workflow step type Select Change Step Type from the right-click menu, then the type of workflow step from
the submenu. This action opens a dialog in which you set the new workflow step type
parameters.
To move a workflow step up or down Select Move Up (Move Down) from the right-click menu. The editor only presents valid
choices for 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 designate 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.

454 chapter 30 Using the workflow editor

chapter 31

Guidewire workflow

This topic covers ClaimCenter 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 A specific running instance of a particular business process. Guidewire persists a workflow instance
instance 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
ClaimCenter saves a workflow instance as a row in the database marking the existence of a single running business
flow. ClaimCenter creates a workflow instance in response to a specific need to perform a task or function, usually
asynchronously. For example, in the base configuration, ClaimCenter provides a ready-to-use integration to the
Metropolitan Reporting Bureau (www.metroreporting.com) that it bases on workflow. You use this workflow as an
aid in obtaining police reports of accidents.
The newly created instance takes the form of a database entity called Workflow. Because ClaimCenter creates the
Workflow entity in a bundle with other changes to its associated business data, ClaimCenter does nothing with the
workflow until it commits the workflow. ClaimCenter does not send messages to any external application unless the
surrounding bundle commits successfully.

Guidewire workflow 455

 Configuration Guide 9.0.5

Note: For more information on the Workflow entity, consult the ClaimCenter 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.
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 ClaimCenterAdministration 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.

456 chapter 31 Guidewire workflow

 Configuration Guide 9.0.5

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 – ClaimCenter retries a Failed work item up to the maximum retry limit.
• Checkedout – ClaimCenter processes a Checkedout work item in a specific worker's queue after the work item
reaches the head of that queue.
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 451

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 Exactly one Structural. Element for defining symbols used in the workflow. Generally, you
element” on page 461 define a symbol to use as convenience in defining objects in the workflow path.
For example, you can define a symbol such that inserting “claim” actually
inserts “Workflow.Claim”.
“<Start> workflow element” Exactly one Structural. Element defining on which step the Workflow element starts. It can
on page 461 optionally contain Gosu code to set up the workflow or its business data.
“AutoStep workflow step” on Zero, one, or A step is one stage that the Workflow instance can be in at a time. There can be
page 463 more zero, one, or more of any of these steps, in any order.
“ActivityStep workflow step” Each of these steps in turn can contain one or more of the following:
on page 465 • Any number of Assert code blocks for ensuring the conditions in the step
“ManualStep workflow step” are met.
on page 466 • An Enter block with Gosu code to execute on entering the step.
“MessageStep workflow step” • Any number of Event objects that generate on entering the step.
on page 464
• Any number of Notification objects that generate on entering the step.
• An Exit block with Gosu code to execute on leaving a step.

Understanding workflow 457

 Configuration Guide 9.0.5

Step Script Description

contains
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
ClaimCenter 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” on One or more A specialized step that indicates a last step out of which no branch leaves.
page 468
“<Finish> workflow element” Zero or one Structural. An optional code block that contains Gosu code to perform any last
on page 461 cleanup after the workflow reaches an Outcome.

See also
• “Using the workflow editor” on page 451

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 Workflow.Bundle 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 ClaimCenter 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.

458 chapter 31 Guidewire workflow

 Configuration Guide 9.0.5

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 ManualExecutionWF.2.xml means workflow
type ManualExecution, version 2. As ClaimCenter 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 477.
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. ClaimCenter 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, ClaimCenter 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. ClaimCenter 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.

Workflow versioning 459

 Configuration Guide 9.0.5

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, ClaimCenter 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.
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 460
• 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.

Next steps
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 461

<Finish> “<Finish> workflow element” on page 461

<Start> “<Start> workflow element” on page 461

460 chapter 31 Guidewire workflow

 Configuration Guide 9.0.5

<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 Workflow.User.
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 claim actually inserts Workflow.Claim.

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.

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 461
• “Asserts in workflows” on page 462
• “Events in workflows” on page 462
• “Notifications in workflows” on page 462
• “Branch IDs in workflows” on page 463
The ClaimCenterAdministration 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.)

Workflow structural elements 461

 Configuration Guide 9.0.5

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 " + Workflow.DisplayName + "started at " + Workflow.enteredStep

print(msg)

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, ClaimCenter 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
Workflow.currentAction == “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
461
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 ClaimCenter sends out, but which does not block the workflow from continuing. ClaimCenter 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 465 for more information on activity generation.

462 chapter 31 Guidewire workflow

 Configuration Guide 9.0.5

Name Name of the activity.

Pattern Activity pattern code. This must be a valid activity pattern as defined through Guidewire ClaimCenter.

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:

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 463
MessageStep “MessageStep workflow step” on page 464
ActivityStep “ActivityStep workflow step” on page 465
ManualStep “ManualStep workflow step” on page 466
Outcome “Outcome workflow step” on page 468

AutoStep workflow step

An AutoStep is a step that ClaimCenter 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 469 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.

Common step elements 463

 Configuration Guide 9.0.5

Create an auto workflow step

Procedure
1. Right-click in the workflow workspace, and then clickNew AutoStep.
2. Enter the following fields:

Field Description
Step ID ID of the step to create.

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 461 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 Workflow.Message. 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), ClaimCenter stores an optional response string
(supplied with the ack) on the message in the Response field. ClaimCenter 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:

464 chapter 31 Guidewire workflow

 Configuration Guide 9.0.5

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

Next steps
See also
• “Common step elements” on page 461

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. ClaimCenter 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

Basic workflow steps 465

 Configuration Guide 9.0.5

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 ClaimCenter marks all the activities as completed, skipped or canceled, the ActivityStep uses one or more
“GO” on page 469 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 ClaimCenter
marks the Activity as completed or canceled.

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 ClaimCenter.

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
ClaimCenter. 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
example, the following initialization Gosu code creates an activity and assigns it SomeUser in SomeGroup.
Workflow.initActivity(Activity)
Activity.autoAssign(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.

466 chapter 31 Guidewire workflow

 Configuration Guide 9.0.5

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 472 for more discussion on these two values.)

Time Delta The amount of time to wait or pause before continuing. Enter an integer number with its units (3600s, for
example).
Time A fixed point in time, as defined by a Gosu expression that resolves to a date. You can use the Gosu code to define
Absolute the date, as in the following:
PolicyPeriod.Cancellation.CancelProcessDate
Or, you can use Gosu to calculate the point in time, as in the following:
PolicyPeriod.PeriodStart.addDays(-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 Absolute Specifies a fixed point in time. For example, the following sets the point to continue to after the policy Can
celProcessDate:
PolicyPeriod.Cancellation.CancelProcessDate

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.

ManualStep workflow step 467

 Configuration Guide 9.0.5

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.
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 ClaimCenter 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 469 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.

468 chapter 31 Guidewire workflow

 Configuration Guide 9.0.5

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.

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 nextS
tep 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.

Step branches 469

 Configuration Guide 9.0.5

Field Description
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.
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, ClaimCenter 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 ClaimCenter 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.

470 chapter 31 Guidewire workflow

 Configuration Guide 9.0.5

Invoking a trigger
How does one actually invoke a TRIGGER? Almost anything can do so, from Gosu rules and classes to the
ClaimCenter interface. Typically, in ClaimCenter, 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 480 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 ClaimCenter Data Dictionary entry on Workflow.)
ClaimCenter 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.

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.)

Step branches 471

 Configuration Guide 9.0.5

PolicyPeriod.CancellationProcess.canRescind().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 ClaimCenter 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

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,
java.util.Date.CurrentDate + 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.

472 chapter 31 Guidewire workflow

 Configuration Guide 9.0.5

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:

Action Description
Clone an Existing Creates an exact copy of an existing workflow type, with the same name but with an incremented
Workflow version 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.

Creating new workflows 473

 Configuration Guide 9.0.5

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.
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 NewWorkflow.eti 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.

474 chapter 31 Guidewire workflow

 Configuration Guide 9.0.5

Extending a workflow: a simple example

This simple examples illustrates the following steps:
• “Step 1: Extend an existing workflow object” on page 475
• “Step 2: Create a new workflow process” on page 475
• “Step 3: Populate Your workflow with steps and branches” on page 475

Step 1: Extend an existing workflow object

To extend an existing workflow object, review the steps outlined in “Extend an existing workflow” on page 473. 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 ExampleWorkflow.eti 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 475.

Step 2: Create a new workflow process

Before beginning this task, complete “Step 1: Extend an existing workflow object” on page 475.
Next, you need to create a new workflow process from your new ExampleWorkflow type.

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 475.

Step 3: Populate Your workflow with steps and branches

Before beginning this task, complete “Step 2: Create a new workflow process” on page 475.
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 469 branch from Step1 to Step4
The example workflow looks similar to the following:

Creating new workflows 475

 Configuration Guide 9.0.5

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
469 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.
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.
476 chapter 31 Guidewire workflow
 Configuration Guide 9.0.5

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()

workflow.start()

Starting a workflow
There are multiple workflow start methods. The following list describes them.

start() Starts the workflow.

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 458

Logging workflow actions

There are several different Gosu statements that you can use to view workflow-related information.

gw.api.util.Logger.logInfo Statement written to the application server log

Workflow.log Statements viewable in the ClaimCenterWorkflow console

Instantiating a workflow 477

 Configuration Guide 9.0.5

See Also
•

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 ClaimCenterWorkflow 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 HelloWorld1.eti 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.

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.

478 chapter 31 Guidewire workflow

 Configuration Guide 9.0.5

Notice that it has a claim symbol set in “<Context> workflow element” on page 461.
1. For Step1, add the following to the Enter block for that step:

gw.api.util.Logger.logInfo( "HelloWorld1 step 1, step called ClaimNumber " + claim.ClaimNumber)

Workflow.log( "HelloWorld Step 1", "HelloWorld1 step 1 entered: Claim Number " + claim.ClaimNumber )

2. For Step2, add the following to the Enter block for that step:

gw.api.util.Logger.logInfo( "HelloWorld1 step 2, step called ClaimNumber " + claim.ClaimNumber)

Workflow.log( "HelloWorld Step 2", "HelloWorld1 step 2 entered: Claim Number " + claim.ClaimNumber )

3. Create a simple Claim Pre-Update rule similar to the following:

• The rule condition specifies that ClaimCenter 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 ClaimCenter instantiates HelloWorld1 and logs the information.
Rule Conditions:

claim.PermissionRequired=="fraudriskclaim"

Rule Actions:

gw.api.util.Logger.logInfo( "Entering Pre-Update" )

var hw_wf = claim.Workflows.firstWhere( \ c -> c.Subtype == "HelloWorld1"

&& (c as entity.HelloWorld1).State !="completed"
&& (c as entity.HelloWorld1).Claim.ClaimNumber==claim.ClaimNumber)

if (hw_wf == null) {
gw.api.util.Logger.logInfo( "## Studio instantiating HelloWorld1 and starting it!" )
var workflow = new entity.HelloWorld1()
workflow.Claim = claim
workflow.start()
}

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.

Instantiating a workflow 479

 Configuration Guide 9.0.5

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
ClaimCenter 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. ClaimCenter 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 AbstractWorkflow.startAsynchronously 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 AbstractWorkflow.resume, typically initiated by an administrator using the workflow management
tool
After the workflow advances as far as it can, ClaimCenter deletes the work item and execution stops until there is
another work item.

Synchronicity, transactions, and errors

To understand how error handling works in the internal Workflow engine, you must know whether the workflow is
running synchronously or asynchronously.

480 chapter 31 Guidewire workflow

 Configuration Guide 9.0.5

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 477. To review, these 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:
• It can encounter an activity step (ActivityStep Workflow Step). This can result in the creation of one or more
activities, causing the workflow to pause until the closure of all the activities.
• It can encounter a communication step (MessageStep Workflow Step). This can result in a message being sent
to another system, causing the workflow to wait until receiving a response.
• It can encounter a step that stipulates a timeout (ManualStep Workflow Step). This causes the workflow to wait
for the timeout to complete.
• It can encounter a step that requires a trigger (ManualStep Workflow Step). This causes the workflow to wait
until someone (or something) activates the trigger.
• And, of course, 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, it continues after the closure of the last activity.
• If waiting for an acknowledgement of a message, it continues after receiving the appropriate response.
• If waiting on a timeout, it 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. This can happen either from the ClaimCenter interface (a user clicking a button) or from
Gosu. In either case, this is done 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. It 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):

policyPeriod.ActiveWorkflow.invokeTrigger( trigger, false )

The trigger parameter defines the TRIGGER to use. This must be a valid trigger defined in the
WorkflowTriggerKey typelist.
The synchronous value in this method has the following meanings:

The workflow engine 481

 Configuration Guide 9.0.5

true (Default) Instructs the workflow to immediately execute in the current transaction and to block the calling code until
the workflow encounters a new stopping point.
false Instructs the workflow to run in the background, with the calling code continuing to execute. The workflow 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).
Thus, if both of 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 ClaimCenter 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. If working with an external system, you need to one of the following:
• You need to design the services in the external system, or,
• You need to 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 as it 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, ClaimCenter rolls back all workflow steps (along with everything else in the bundle). The error cascades
all the way up to the calling code (the code that started the workflow or invoked the trigger on the workflow).
• If you start the workflow or invoke the trigger from the ClaimCenter interface, ClaimCenter 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), ClaimCenter logs
the exception and rolls back the bundle, in a similar manner to the synchronous case.

482 chapter 31 Guidewire workflow

 Configuration Guide 9.0.5

Execution type Application behavior

ClaimCenter then handles workflow retries in the standard way through the worker. ClaimCenter 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, ClaimCenter 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 ClaimCenter. 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, typically:
• entering the step
• following the branch
• or, 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 right back
into Error state again. This is only after the work item performs its specified number of retries, however.

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 ClaimCenter 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:

Workflow.createSubFlow(workflow)
Workflow.createSubFlow(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 Workflow.caller. (If internal code, and not some other workflow, calls a
macro workflow, this field is null.)
Each workflow also has a subFlows 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:

Workflow.SubFlows

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

Synchronicity, transactions, and errors 483

 Configuration Guide 9.0.5

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
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 ClaimCenterAdministration→Workflows page
• Through the command line, such as running a batch process to purge the workflow logs
• Through class gw.webservice.workflow.IWorkflowAPI, which the command line uses
The most likely need for using the ClaimCenterAdministration 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 ClaimCenter
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, ClaimCenter 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 time Select and enter a time to force the workflow to wait until either that amount of time has expired or the
(secs) currently 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, ClaimCenter presents a list of
available triggers from which to choose, if any are available on this workflow.

484 chapter 31 Guidewire workflow

 Configuration Guide 9.0.5

Command Description
Suspend Select to suspend any active workflows that are currently selected in the previous screen. After you execute
this command, ClaimCenter suspends the selected workflows. This action is appropriate for all workflow and
steps. However, ClaimCenter executes this command only against active workflows.
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 branch Select to choose a workflow timeout branch. After selecting this command, ClaimCenter presents a list of
timeout 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

ClaimCenter 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 Use to view information on the last run-time of a writer, and to see the schedule for its next run-time. From
Info 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.

See also
• Application Guide

Workflow debugging and logging

Debugging a workflow is a more challenging task than debugging the standard ClaimCenter 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 ClaimCenter. (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 ClaimCenter 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:

Workflow.log(summary, description)

Workflow debugging and logging 485

 Configuration Guide 9.0.5

The method returns the log entry (WorkflowLogEntry) that you can use for additional processing:

var workflowLog = Workflow.log("short description", "stack trace ...")

var summary = workflowLog.summary

Process logging
The following logging categories can be useful:

Category Use for

WorkQueue A category for general logging from the work queue.
WorkQueue.Instrumented Capturing of runner state for a specific execution of the runner.

WorkQueue.Item Logging (by workers) of each work item executed at the “info” level.
WorkQueue.Runner Logging runners.

To write every message logged by every workflow, set the logging level of the workflow logger category to DEBUG
(using logging.properties). The directive in the logging.properties file is:

log4j.category.Server.workflow=DEBUG

486 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 ClaimCenter creates activities. Activity patterns describe the
kinds of activities that people perform while handling claims within an organization. For example, obtaining a
statement from a witness 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 claim, ClaimCenter 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 claims business processes from the
Administration tab in ClaimCenter. It is possible to create activities from activity patterns in different ways:
• You can manually create activities in ClaimCenter.
• A business rule or some other Gosu code create activities as part of generating workplans or while responding to
escalations, claim exceptions, or other events.
• ClaimCenter 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 the Claim or
Exposure page.

Defining activity patterns 487

 Configuration Guide 9.0.5

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 ClaimCenter assigns an activity. Instead, activity assignment methods in
the assignment rules or in Gosu expressions control how ClaimCenter assigns an activity. Using the pattern name,
the assignment methods determine to whom to assign the activity.

Pattern types and categories

ClaimCenter 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 ClaimCenter 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 through the ClaimCenter interface. It is not possible, for example, to create a custom
Approval activity pattern through the ClaimCenter Activity Patterns screen.
Guidewire defines a number of internal activity pattern types in the base configuration. All pattern types other than
General are internal. Only internal ClaimCenter 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
ClaimCenter interface. You use them only within Gosu and ClaimCenter 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
ClaimCenterNew Activity menu. The activity pattern categories appear only within the ClaimCenter 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 ClaimCenter interface.
ClaimCenter displays the activity categories in the New Activity Pattern editor screen.

488 chapter 32 Defining activity patterns

 Configuration Guide 9.0.5

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.

Entity.ActivityPattern.Code == "activity_pattern_code"

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 ClaimCenter calculates the due date for an activity. ClaimCenter can calculate a target due date in
hours or days. ClaimCenter 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. For
example, suppose that you want to schedule a vehicle inspection to be done within five days of the (company
service-level target). You specify this using the Target days or Target hours value.
• What is the starting point? What point in time does ClaimCenter use as the start point in calculating the target
date? For example, is the goal to perform a vehicle inspection within 5 days of the loss date or the claim’s first
notice? You specify this using the Target start point field.
• What days to count? ClaimCenter can count calendar days or only business days. You specify this with the Include
these days field.
ClaimCenter 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. ClaimCenter 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, ClaimCenter uses 0 for both. A
target date is optional for activities. For example, suppose that there is no reason to set an target date for adjuster
self-reminders.
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.

Using activity patterns in Gosu 489

 Configuration Guide 9.0.5

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.) ClaimCenter 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, ClaimCenter 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.
ClaimCenter 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,
ClaimCenter 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.

Defining the business calendar

Due dates within ClaimCenter depend on an understanding of the business calendar as defined by your company.
For example, if something is due in five business days, exactly which days does this include? Does your company
operate seven days a week or do you consider only Monday through Friday to be business days? Which days are
company holidays? Another key concept in the business calendar is understanding how your company defines the
point at which a week begins or ends. Is Friday the last day of the week or is Sunday?
You manage the business calendar through the Administration→Holidays screen within ClaimCenter.
See also
• Application Guide

Base configuration activity patterns

ClaimCenter uses file activity-patterns.csv to load the base activity pattern definitions upon initial server
startup after installation. You access file activity-patterns.csv in Guidewire Studio in the following location:
configuration→config→import→gen

IMPORTANT Do not remove any internal (non-General type) activity patterns or change their type, category, or
code values. Internal ClaimCenter 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 Description

interface
field
ActivityClass Class Indicates whether the activity is a task or an event. A task has a due date. An event
does not.

490 chapter 32 Defining activity patterns

 Configuration Guide 9.0.5

Property User Description

interface
field
AutomatedOnly Automated only A Boolean value that defines whether only automated additions (by business rules) to
the workplan use the activity pattern.
• If true, the activity pattern does not appear as a choice in ClaimCenter 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 ClaimCenter interface.
Category Category The category for grouping ActivityPatterns in the ClaimCenter interface.
ClaimLossType Claim loss type Describes the claim type for which the activity pattern is relevant. Valid options include
the following:
• auto — Auto
• property — Property
• gl — General Liability
• wc — Workers’ Comp
If not specified, the activity pattern is available for all types of claims.
ClosedCaimAvlble Available for A Boolean value that defines whether you can add the activity to a closed claims—
closed claim meaning it is possible to perform the activity on a closed claim. If you do not specify a
value, ClaimCenter uses a default of true.
Code Code Any unique text with no spaces. Maximum length is 60 characters. This property is
required. The Code property is used to identify the activity pattern when accessing the
pattern in rules or Gosu code. You can see this value only through the Administration tab.
Command Not Do not use. For Guidewire use only.
Applicable
Data-Set Not The value of the highest-numbered data set of which the imported object is a part.
Applicable ClaimCenter 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 Template Email template to display if you choose this activity. Enter the email template file name.
EntityId Not Required. The unique public ID of the activity pattern.
Applicable
EscalationDays Escalation days The number of days from the escalationstartpt to set the Escalation Date for an
activity.
EscalationHours Escalation The number of hours from the escalationstartpt to set the Escalation Date for an
hours activity.
EscalationInclDays Include these Specifies which days to include. You can set this businessdays or elapsed.
days

EscalationStartPt Escalation start The initial date used to calculate the target date. If you specify escalationdays or esca
point lationhours, you need to specify this parameter. Otherwise, this parameter is
optional.
You can set this field to the following values:
• activitycreation — The activity’s creation date.
• claimnotice — The FNOL date which is the claim’s “reported date.”
• lossdate — The date the accident or injury occurred)

Activity pattern objects 491

 Configuration Guide 9.0.5

Property User Description

interface
field
ExternallyOwned Externally A Boolean value indicating whether an external organization or user can own the
owned activity or not.
Importance Calendar Specifies the default level of importance at which the activity appears on a calendar.
Importance You can set this value to the following values:
• top
• high
• medium
• notoncalendar
• low
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 unnecessary work. This value is optional. If you do not specify a value, the
application uses a default of true.
Priority Priority Used to sort more important activities to the top of a list of work. This property is
required. 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.
For example, a recurring 30 day diary activity instructs the adjuster to check the claim
every 30 days.
ShortSubject Short Subject A brief description of the activity used on small areas of the ClaimCenter interface such
as a calendar event entry. Maximum length of 10 characters.
Subject Subject A short text description of the activity that ClaimCenter shows in activity lists. This
property 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 Include these This field answers the “what days to count” part of calculating the target date. Your
days options are the following:
• elapsed—count all Calendar days
• businessdays—count all Business days 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.
You can set this property to the following values:
• activitycreation — The activity’s creation date.
• claimnotice — The FNOL date which is the claim’s “reported date.”
• lossdate — The date the accident or injury occurred.
Type Type This specifies what activity type to create.
Note It is only possible to create a custom activity pattern of type General. Guidewire
reserves all other activity pattern types for internal use. See “Pattern types and
categories” on page 488 for more information.

492 chapter 32 Defining activity patterns

 Configuration Guide 9.0.5

Use activity patterns with eocuments and emails

About this task
It is possible to attach a specific document or email template to a specific activity pattern. Then, as ClaimCenter
displays an activity based on this activity pattern, it 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 ClaimCenter under an administrative account and access the following screen:
Administration→Activity Patterns
2. Open the activity pattern edit screen by either creating a new activity pattern or selecting an activity pattern to
update.

Create new → Click Add Activity Pattern

Update existing → Select an activity pattern and click Edit

3. Use the search icon next to the Document Template or Email Template field to open a search window.
4. 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, ClaimCenter does the following:

Specifying document and email templates in CSV files

You can also specify the document or email template in file activity-patterns.csv. 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 490 for details of working with the activity-patterns.csv file.

Localizing activity patterns

ClaimCenter 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 ClaimCenter interface—if you configure ClaimCenter for
multiple locales:
• Description
• Subject
If you configure ClaimCenter 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.

Use activity patterns with eocuments and emails 493

 Configuration Guide 9.0.5

494 chapter 32 Defining activity patterns

chapter 33

Guidewire ClaimCenter and Email

Guidewire includes support for sending emails from ClaimCenter. Sending an email is one of several possible
actions to take, for example, if a user escalates an activity or notes a claim exception.
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
ClaimCenter 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 ClaimCenter PCF screens.

ClaimCenter email support

ClaimCenter 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 ClaimCenter 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 ClaimCenter Message Queues
screen, available to administrators, provides information on the various message destinations, including the Email
message destination.

Guidewire ClaimCenter and Email 495

 Configuration Guide 9.0.5

Default email plugin implementation

Guidewire provides a default email message plugin named emailMessageTransport. To set ClaimCenter for email
notifications, configure the plugin parameters in Guidewire Studio.

Configure email plugin parameters in Guidewire

Configure the parameters that affect the email plugin in the Studio Plugin Editor.

Procedure
1. In the ClaimCenter Studio Project window, expand configuration→config→Plugins→registry.
2. Double-click emailMessageTransport to open it.
3. If the Disabled check box is checked, clear the check box to enable the plugin.
4. Enter appropriate values for the following parameters:
• defaultSenderAddress
• defaultSenderName
• smtpHost
• smtpPort
5. Save your changes.
6. Restart the ClaimCenter server.

The email object model

Guidewire ClaimCenter uses the following two classes to define email messages:
• gw.api.email.Email
• gw.api.email.EmailContact
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.

gw.api.email.Email
The Emailclass contains the following fields, most of which are self-explanatory:

Field Description
Subject Subject of the email
Body Content of the email
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

gw.api.email.EmailContact
The EmailContact class contains the following fields:

496 chapter 33 Guidewire ClaimCenter and Email

 Configuration Guide 9.0.5

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
gw.api.email.EmailUtil class for generating and sending emails from Gosu, for example:

gw.api.email.EmailUtil.sendEmailWithBody( KeyableBean entity, Email email )

gw.api.email.EmailUtil.sendEmailWithBody( KeyableBean entity,

Contact to,
Contact from,
String subject,
String body )

gw.api.email.EmailUtil.sendEmailWithBody( 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 claim, exposure, or activity. ClaimCenter uses this
parameter only while processing the email for transmission. See “Email transmission” on page 498.

Emails that use an Email object

One variation of the sendEmailWithBody method requires that you create a gw.api.email.Email entity, and then
define its properties to build the Email entity. For example:

...
var testEmail : gw.api.email.Email
testEmail.Body = "This is a test."
testEmail.Subject = "Test"
...
gw.api.email.EmailUtil.sendEmailWithBody( thisClaim, testEmail )

You can also attach multiple To, CC, and BCC addresses to the email.

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 claim rule, to send an email from an
insurance company employee to the insured, do the following:
• Set the to parameter to Claim.insured.
• Set from to Claim.AssignedUser.Contact.
The following Gosu example generates an email from the current assigned user to that user’s supervisor:

gw.api.email.EmailUtil.sendEmailWithBody(thisClaim, thisClaim.AssignedGroup.Supervisor.Contact,
thisClaim.AssignedUser.Contact, "A claim got a ClaimValid event", "This is the text." )

Email utility methods 497

 Configuration Guide 9.0.5

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:

gw.api.email.EmailUtil.sendEmailWithBody( Entity, toName, toEmail, fromName, fromEmail, subject, body)

Email transmission
Guidewire ClaimCenter, from the user's perspective, sends emails asynchronously by using the ClaimCenter
Messaging subsystem. If there is a method call for one of the EmailUtil.sendEmail methods, ClaimCenter 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, ClaimCenter adds the Message entity to the entity transaction bundle.
ClaimCenter persists the Message entity any time that it creates the bundle.
• If the entity parameter is null, ClaimCenter persists the Message entity immediately.
ClaimCenter 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. You cannot,
however, 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 .gosu.descriptor,
• 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:

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

498 chapter 33 Guidewire ClaimCenter and Email

 Configuration Guide 9.0.5

For example, EmailReceived.gosu.descriptor 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="EmailReceived.gosu"
/>
</serialization>

The EmailReceived.gosu.descriptor file pairs with the actual template file (EmailReceived.gosu):
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 ClaimCenter 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 .gosu.html 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 <%= activity.AssignedUser %> at <%= activity.AssignedUser.Contact.WorkPhone %>

in regards to <%= activity.Subject %>

Thank you for your patience while we resolve this issue.

Sincerely,

Create an email template descriptor file

Procedure
1. In the ClaimCenter Studio Project window, expand configuration→config→resources.
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 .gosu.descriptor Select Text from the list of file types to associate with the .g
osu.descriptor extension, if necessary.

HTML New→HTML File .gosu.html.descriptor Set the HTML version to use in the HTML File dialog.

About email templates 499

 Configuration Guide 9.0.5

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="TestEmail.gosu" />
</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 ClaimCenter, 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 gw.api.email.EmailUtil.sendEmailWithBody 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.

Saving an email message as a document

ClaimCenter does not store email objects created through the “The email object model” on page 496 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 gw.api.email.EmailUtil.sendEmailWithBody 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.

500 chapter 33 Guidewire ClaimCenter and Email

 Configuration Guide 9.0.5

2. Send the email by calling one of the sendEmailWithBody methods.

3. If ClaimCenter 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 CreateEmailScreen.pcf 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 CreateEmailScreen.pcf 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 ClaimCenter 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.

EmailEnhancement.gsx
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 gw.api.email

uses gw.api.util.DisplayableException
uses gw.document.TemplatePluginUtils
uses gw.plugin.email.IEmailTemplateDescriptor
uses java.io.StringReader
uses java.util.Map
uses java.util.HashSet
uses gw.api.util.LocaleUtil
uses gw.api.system.PLLoggerCategory

enhancement EmailEnhancement : gw.api.email.Email {

// 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

Creating an HTML email within code 501

 Configuration Guide 9.0.5

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>) {

this.Html = template.Html
try {
var locale = template.Locale
if (locale == null) {
locale = LocaleUtil.getDefaultLocale()
}
TemplatePluginUtils.resolveTemplates( locale,
{new StringReader(template.Subject), new StringReader(template.Body)},
// 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 beans.entrySet()) {
var bean = entry.getValue()
iScriptHost.putSymbol(entry.Key, typeof(bean) as String, bean)
seen.add(entry.Key.toLowerCase())
}
// now load (or copy from other possible symbol names) the symbols that could be expected
// cc: claim, ...
// pc: policy, account, policyperiod, job, ...
if (not seen.contains( "activity" )) {
iScriptHost.putSymbol( "activity", Activity as String, null )
}
if (not seen.contains( "user" )) {
iScriptHost.putSymbol( "user", User as String, User.util.CurrentUser )
}
},
// process the result of the template expansion
\ results -> {
this.Subject = results[0]
this.Body = results[1]
} )
} catch (e : Throwable) {
PLLoggerCategory.MESSAGING_EMAIL.info("On ${template.getName()}", e)
throw new DisplayableException("On ${template.getName()} caught ", e);
}
}
}

CreateEmailScreen.pcf
The following example code adds additional functionality to the base configuration ClaimCenter
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
EmailEnhancement.gsx.
Note: This example uses display keys that do not exist in the base configuration. You must add the missing display
keys to display.properties in order to see the correct labels.

<?xml version="1.0"?>
<PCF
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="../../../../../../pcf.xsd">

502 chapter 33 Guidewire ClaimCenter and Email

 Configuration Guide 9.0.5

<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="gw.api.util.LocaleUtil.getDefaultLanguageType()"
name="language"
type="LanguageType"/>
<Variable
initialValue="initializeSymbolTable()"
name="symbolTable"
type="java.util.Map&lt;String,Object&gt;"/>
<Variable
initialValue="new String()"
name="content"
type="String"/>
<Variable
initialValue="emailTemplateName == null ? null : fetchTemplate()"
name="template"
type="gw.plugin.email.IEmailTemplateDescriptor"/>
<Variable
initialValue="initNewEmail()"
name="NewEmail"
type="gw.api.email.Email"/>
<Toolbar>
<ToolbarButton
action="sendEmailToRecipients(NewEmail)"
available="true"
id="ToolbarButton0"
label="DisplayKey.get(&quot;Web.Activity.Email.SendEmail&quot;)"
visible="true"/>
<ToolbarButton
action="CurrentLocation.cancel()"
available="true"
id="ToolbarButton1"
label="DisplayKey.get(&quot;Web.Activity.Email.Cancel&quot;)"
visible="true"/>
<ToolbarDivider/>
<PickerToolbarButton
action="PickEmailTemplatePopup.push(createSearchCriteria())"
id="EmailWorksheet_UseTemplateButton"
label="DisplayKey.get(&quot;Web.Activity.Email.UseTemplate&quot;)"
onPick="template = PickedValue;
language = gw.api.util.LocaleUtil.toLanguageType(PickedValue.Locale);
executeTemplate(NewEmail)"
shortcut="P"
visible="noDefaultTemplate"/>
</Toolbar>

Creating an HTML email within code 503

 Configuration Guide 9.0.5

<AlertBar
id="NoDefaultTemplate"
label="DisplayKey.get(&quot;Web.Email.Template.NotFound&quot;, emailTemplateName)"
showConfirmMessage="false"
visible="emailTemplateName != null and noDefaultTemplate"/>
<DetailViewPanel>
<InputColumn>
<TypeKeyInput
editable="true"
id="Language"
label="DisplayKey.get(&quot;Web.EmailTemplateSearch.Language&quot;)"
required="true"
value="language"
valueType="typekey.LanguageType"
visible="LanguageType.getTypeKeys( false ).Count &gt; 1 and emailTemplateName != null">
<PostOnChange
onChange="template = fetchTemplate(); executeTemplate(NewEmail)"/>
</TypeKeyInput>
<ListViewInput
editable="true"
id="ToRecipientLVInput"
label="DisplayKey.get(&quot;Web.Activity.Email.ToRecipients&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 gw.api.email.EmailContact();
NewEmail.addToRecipient(newEmailContact); return newEmailContact;"
toRemove="NewEmail.removeToRecipient( ToRecipient )"
validationLabel="DisplayKey.get(&quot;Web.Activity.Email.ToRecipients&quot;)"
value="NewEmail.ToRecipients?.toTypedArray()"
valueType="gw.api.email.EmailContact[]">
<Row
editable="true">
<TextCell
editable="true"
id="ToName"
label="DisplayKey.get(&quot;Web.Activity.Email.Name&quot;)"
maxChars="60"
numCols="15"
value="ToRecipient.Name"/>
<TextCell
editable="true"
id="ToEmail"
label="DisplayKey.get(&quot;Web.Activity.Email.EmailAddress&quot;)"
numCols="15"
requestValidationExpression="VALUE == null ?
DisplayKey.get(&quot;Web.Activity.Email
.Error.AddressForToRecipientRequried&quot;) : null"
required="true"
value="ToRecipient.EmailAddress"/>
</Row>
</RowIterator>
</ListViewPanel>
</ListViewInput>
<ButtonInput
action="showCC = true"
id="ShowCCRecipients"
labelAbove="true"
value="DisplayKey.get(&quot;Web.Activity.Email.AddCCRecipients&quot;)"
visible="!showCC"/>
<ListViewInput
editable="true"

504 chapter 33 Guidewire ClaimCenter and Email

 Configuration Guide 9.0.5

id="CcRecipientLVInput"
label="DisplayKey.get(&quot;Web.Activity.Email.CCRecipients&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 gw.api.email.EmailContact();
NewEmail.addCcRecipient(newEmailContact); return newEmailContact;"
toRemove="NewEmail.removeCcRecipient( CcRecipient )"
value="NewEmail.CcRecipients?.toTypedArray()"
valueType="gw.api.email.EmailContact[]">
<Row
editable="true">
<TextCell
editable="true"
id="CcName"
label="DisplayKey.get(&quot;Web.Activity.Email.Name&quot;)"
numCols="15"
value="CcRecipient.Name"/>
<TextCell
editable="true"
id="CcEmail"
label="DisplayKey.get(&quot;Web.Activity.Email.EmailAddress&quot;)"
numCols="15"
required="true"
value="CcRecipient.EmailAddress"/>
</Row>
</RowIterator>
</ListViewPanel>
</ListViewInput>
<ButtonInput
action="showBCC = true"
id="ShowBCCRecipients"
labelAbove="true"
value="DisplayKey.get(&quot;Web.Activity.Email.AddBCCRecipients&quot;)"
visible="!showBCC"/>
<ListViewInput
editable="true"
id="BccRecipientLVInput"
label="DisplayKey.get(&quot;Web.Activity.Email.BCCRecipients&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 gw.api.email.EmailContact();
NewEmail.addBccRecipient(newEmailContact); return newEmailContact;"
toRemove="NewEmail.removeBccRecipient( BccRecipient )"
value="NewEmail.BccRecipients?.toTypedArray()"
valueType="gw.api.email.EmailContact[]">
<Row
editable="true">
<TextCell
editable="true"
id="BccName"
label="DisplayKey.get(&quot;Web.Activity.Email.Name&quot;)"

Creating an HTML email within code 505

 Configuration Guide 9.0.5

numCols="15"
value="BccRecipient.Name"/>
<TextCell
editable="true"
id="BccEmail"
label="DisplayKey.get(&quot;Web.Activity.Email.EmailAddress&quot;)"
numCols="15"
required="true"
value="BccRecipient.EmailAddress"/>
</Row>
</RowIterator>
</ListViewPanel>
</ListViewInput>
<InputDivider/>
<CheckBoxInput
editable="true"
id="SaveAsDocument"
value="saveAsDocument"
valueLabel="DisplayKey.get(&quot;Web.Activity.Email.SaveAsDocument&quot;)"/>
</InputColumn>
<InputColumn>
<TextInput
editable="true"
id="SenderName"
label="DisplayKey.get(&quot;Web.Activity.Email.SenderName&quot;)"
value="NewEmail.Sender.Name"/>
<TextInput
editable="true"
id="SenderEmail"
label="DisplayKey.get(&quot;Web.Activity.Email.SenderEmail&quot;)"
value="NewEmail.Sender.EmailAddress"/>
<TextInput
editable="true"
id="Subject"
label="DisplayKey.get(&quot;Web.Activity.Email.Subject&quot;)"
requestValidationExpression="VALUE == null ?
DisplayKey.get(&quot;Web.Activity.Email.Error.SubjectRequired&quot;) : null"
required="true"
value="NewEmail.Subject"/>
<TextAreaInput
editable="true"
id="Content"
label="template.ContentPrompt"
numCols="60"
numRows="10"
required="false"
value="content"
visible="template.Html">
<PostOnChange
onChange="executeTemplate(NewEmail)"/>
</TextAreaInput>
<TextAreaInput
editable="true"
id="Body"
label="DisplayKey.get(&quot;Web.Activity.Email.Body&quot;)"
numCols="60"
numRows="10"
requestValidationExpression="VALUE == null ?
DisplayKey.get(&quot;Web.Activity.Email.Error.BodyRequired&quot;) : null"
required="true"
value="NewEmail.Body"
visible="!template.Html"/>
<ListViewInput
editable="true"
id="AttachedDocuments"
label="DisplayKey.get(&quot;Web.Activity.Email.AttachedDocuments&quot;)">
<Toolbar>
<PickerToolbarButton
action="PickExistingDocumentPopup.push(docContainer)"
id="AddDocumentButton"
label="DisplayKey.get(&quot;Web.Activity.Email.AddDocument&quot;)"
onPick="NewEmail.addDocument(PickedValue)"
shortcut="A"
visible="true"/>
<IteratorButtons
addVisible="false"
iterator="AttachedDocumentsLV"/>
</Toolbar>
<ListViewPanel

506 chapter 33 Guidewire ClaimCenter and Email

 Configuration Guide 9.0.5

editable="true"
id="AttachedDocumentsLV">
<RowIterator
editable="true"
elementName="AttachedDocument"
toRemove="NewEmail.removeDocument( AttachedDocument )"
value="NewEmail.Documents?.toTypedArray()"
valueType="entity.Document[]">
<Row>
<TextCell
editable="true"
id="Document"
label="DisplayKey.get(&quot;Web.Activity.Email.DocumentName&quot;)"
value="AttachedDocument.Name"/>
</Row>
</RowIterator>
</ListViewPanel>
</ListViewInput>
</InputColumn>
</DetailViewPanel>
<TemplatePanel>
<TemplatePanelContents><![CDATA[
<% if (template != null && template.Html) printContent(NewEmail.Body, false) %>]]>
</TemplatePanelContents>
</TemplatePanel>
<Code><![CDATA[function initializeSymbolTable() : java.util.Map<String,Object> {
return { "activity" -> srcBean }
}

function createSearchCriteria() : gw.api.email.EmailTemplateSearchCriteria {

var rtn = new gw.api.email.EmailTemplateSearchCriteria()
rtn.Language = language
rtn.AvailableSymbols = symbolTable.Keys?.toTypedArray()
return rtn
}

function initNewEmail() : gw.api.email.Email {

var rtn = new gw.api.email.Email()
if (documentsToSend != null) {
for (document in documentsToSend) {
rtn.addDocument( document )
}
}
if (template != null) {
executeTemplate(rtn)
}
return rtn
}

function fetchTemplate() : gw.plugin.email.IEmailTemplateDescriptor {

template = gw.plugin.Plugins.get(gw.plugin.email.IEmailTemplateSource)
.getEmailTemplate(gw.api.util.LocaleUtil.toLanguage(language), emailTemplateName);
if (template == null) {
noDefaultTemplate = true
throw new gw.api.util.DisplayableException(DisplayKey
.get("Web.Activity.EmailTemplate.Language", emailTemplateName, language))
}
return template
}

function executeTemplate( email : gw.api.email.Email) {

email.useEmailTemplate(template, { "activity" -> srcBean, "content" -> content })
}

function sendEmailToRecipients(emailToSend : gw.api.email.Email) {

var warnings = gw.api.email.EmailUtil.emailContentsValid(emailToSend)
if (warnings.length > 0) {
throw new gw.api.util.DisplayableException(warnings)
}
if (saveAsDocument) {
var templatePlugin = gw.plugin.Plugins.get(gw.plugin.document.IDocumentTemplateSource)
var emailSentDocTemplate = templatePlugin
.getDocumentTemplate("EmailSent.gosu.htm", gw.api.util.LocaleUtil.getDefaultLocale())
if (emailSentDocTemplate == null) {
throw new gw.api.util.DisplayableException("Could not save email as a document
because the \"EmailSent.gosu.htm\" does not exist!")
} else {
documentToSave = documentToSave != null ? documentToSave : new Document()
documentToSave.Name = emailToSend.Subject

Creating an HTML email within code 507

 Configuration Guide 9.0.5

documentToSave.MimeType = emailSentDocTemplate.MimeType
documentToSave.Type = typekey.DocumentType.get(emailSentDocTemplate.TemplateType)
documentToSave.Section = typekey.DocumentSection
.get(emailSentDocTemplate.getMetadataPropertyValue( "section" ) as String)
documentToSave.SecurityType = typekey.DocumentSecurityType
.get(emailSentDocTemplate.DefaultSecurityType)
documentToSave.Status = TC_FINAL
var recpName = emailToSend.ToRecipients.first().Name
documentToSave.Recipient = recpName == null ? emailToSend.ToRecipients.first().EmailAddress : recpName
documentToSave.Activity = docContainer
documentToSave.DateCreated = gw.api.util.DateUtil.currentDate()
documentToSave.Author = User.util.CurrentUser.DisplayName
documentToSave.Inbound = false

var paramMap = new java.util.HashMap()

paramMap.put("User", User.util.CurrentUser)
paramMap.put("Email", emailToSend)
paramMap.put("DateSent", gw.api.util.DateUtil.currentDate())
gw.document.DocumentProduction
.createAndStoreDocumentSynchronously(emailSentDocTemplate, paramMap, documentToSave);
}
} else if (documentToSave != null) {
documentToSave.remove();
}
gw.api.email.EmailUtil.sendEmailWithBody(srcBean, emailToSend);
// it didn't throw so reset email activity.EmailTemplate so that other templates can be used
if (emailTemplateName != null and srcBean typeis Activity) {
if (srcBean.EmailTemplate == emailTemplateName) {
srcBean.EmailTemplate = null
}
}
CurrentLocation.commit();
}]]></Code>
</Screen>
</PCF>

508 chapter 33 Guidewire ClaimCenter and Email

part 7

Testing Gosu code

Configuration Guide 9.0.5
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 ClaimCenter with Guidewire Studio

After you make configuration changes to ClaimCenter, 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 ClaimCenter without debugging” on page 511
• “Debugging ClaimCenter within Studio” on page 512
• “Debugging a ClaimCenter server that is running outside of Studio” on page 512

Running ClaimCenter without debugging

About this task
If you do not plan to use debugging features, then you can run ClaimCenter directly from within Studio to quickly
test your configuration changes. Running ClaimCenter 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 ClaimCenter server starts, and debug messages appear in the Run tool window in Studio.

Testing and debugging your configuration 511

 Configuration Guide 9.0.5

Debugging ClaimCenter within Studio

About this task
You can run ClaimCenter 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 ClaimCenter server starts, and debug messages appear in the Debug tool window in Studio.

Next steps
See also
• “The Studio debugger” on page 514

Debugging a ClaimCenter server that is running outside of Studio

Instead of running ClaimCenter within the Studio debugger, you can have the debugger connect to a ClaimCenter
server that is running outside of Studio. The debugger can connect to a ClaimCenter 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:

Connection type Description See

shared memory Connects Studio to a server running on the same “Debugging a ClaimCenter server using a shared
computer; faster than a socket connection. memory connection” on page 512
socket Allows Studio to connect to a server running on a “Debugging a ClaimCenter server using a socket
remote computer; slower than a shared memory connection” on page 513
connection.

Debugging a ClaimCenter server using a shared memory connection

About this task

Use a shared memory connection to connect Studio to a ClaimCenter 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 ClaimCenter 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.

512 chapter 34 Testing and debugging your configuration

 Configuration Guide 9.0.5

d. Next to Transport, click Shared memory.

e. Next to Debugger mode, click Attach.
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 ClaimCenter 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 ClaimCenter server, and debug messages appear in the Debug tool window in Studio.

Debugging a ClaimCenter server using a socket connection

About this task

Use a socket connection to connect Studio to a ClaimCenter server running either on the same computer or a remote
computer. If running on the same computer, however, 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 ClaimCenter 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 ClaimCenter 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 ClaimCenter 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.

Debugging a ClaimCenter server that is running outside of Studio 513

 Configuration Guide 9.0.5

Result
The debugger connects to the ClaimCenter server, and debug messages appear in the Debug tool window in Studio.

Debugging a ClaimCenter server in suspended mode

About this task

When you start a ClaimCenter 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 ClaimCenter 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 ClaimCenter 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 ClaimCenter 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
ClaimCenter 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:
514 chapter 34 Testing and debugging your configuration
 Configuration Guide 9.0.5

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.

Setting breakpoints 515

 Configuration Guide 9.0.5

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 Activity.AssignedUser 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 Resume normal execution, but pause again at the next breakpoint, if any. To continue debugging, click
debugging Resume Execution without having Mute Breakpoints set.

516 chapter 34 Testing and debugging your configuration

 Configuration Guide 9.0.5

Using the Gosu scratchpad

Use the Gosu scratchpad to execute Gosu programs and evaluate Gosu expressions. Instead of needing to perform
ClaimCenter 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 ClaimCenter 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 group.Members) {
print(member.User.Contact.LastName)
}

To access application data in the Gosu scratchpad, run the ClaimCenter 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 ClaimCenter server in debug mode, see “Testing ClaimCenter with Guidewire Studio” on page 511.
See also
• “Run scratchpad code in the application server debug process” on page 517.

Run scratchpad code in the application server debug process

Procedure

Type your code, and then click Run in Debug Process .

Using the Gosu scratchpad 517

 Configuration Guide 9.0.5

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.

518 chapter 34 Testing and debugging your configuration

 Configuration Guide 9.0.5

Procedure
1. In Guidewire Studio, in the Project tool window, navigate to configuration→res, and then to the file
gwxmlmodule.xml.
2. Double-click the file gwxmlmodule.xml to edit it.
3. Edit the desired <module> element, and set the attribute generate-xml-sources to true.
For example:

<module xmlns="http://guidewire.com/xml/module" 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
ClaimCenter 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:

gw.api.util.Logger.logDebug
gw.api.util.Logger.logError
gw.api.util.Logger.logInfo
gw.api.util.Logger.logTrace

These all log messages as specified by the ClaimCenter logging settings.

Understanding internally generated code 519

 Configuration Guide 9.0.5

Compiling and building the application

ClaimCenter 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.

520 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 511 for details.)
Note: Guidewire does not recommend or support the use of classes that extend
gw.api.databuilder.DataBuilder or classes that reside in the gw.api.databuilder.* 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.

Using GUnit 521

 Configuration Guide 9.0.5

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.
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() {

super.beforeClass() // 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() {

super.beforeClass() // must call super method!

_testHelper = new ThirdPartyClass()

...
}
...
}

522 chapter 35 Using GUnit

 Configuration Guide 9.0.5

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 529 for details on how to create test data.
• See “Creating and testing a builder for a custom entity” on page 537 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:

Annotation type Description More information

Server Runtime This annotation indicates that this test interacts with the server. “Server runtime” on page 523
Server Environment These can provide additional test functionality. Use then to “Server environment” on page 523
replace or modify the default behavior of the system being tested.

To use an annotation, either enter the full path:

@gw.testharness.ServerTest

Or, you can add a uses statement at the beginning of the file, for example:

uses gw.testharness
...
@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.
ClaimCenter 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 gw.testharness.TestBase to the class definition. All GUnit tests that you create must extend this class.
(See the “The TestBase class” on page 521 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.

Configuring the server environment 523

 Configuration Guide 9.0.5

Annotation (@gw.testharness.*) Description

@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 desired, 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 server. If you do so, you may lose test functionality that is only
available in development mode (for example, access to the system clock).
You can check the server mode in Gosu, using the following:
gw.api.system.server.ServerModeUtil.isDev()

@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):
• Runlevel.NONE - Use if you do not want any dependencies at all.
• Runlevel.SHUTDOWN - 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.)
• Runlevel.MULTIUSER - 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.

524 chapter 35 Using GUnit

 Configuration Guide 9.0.5

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.

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 525
• “Test Kind” on page 526
• “VM options” on page 526
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 526 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.

Configuring the test environment 525

 Configuration Guide 9.0.5

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

uses gw.testharness.TestBase
@gw.testharness.ServerTest
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 Tests.AllMyTests.MyTest. You
must place your test classes in the modules/configuration/gtest folder.You 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.

526 chapter 35 Using GUnit

 Configuration Guide 9.0.5

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 523 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
• 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

Creating a GUnit test class 527

 Configuration Guide 9.0.5

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.
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 MyTest.gs, Studio populates the file with the following Gosu:

package demo

@gw.testharness.ServerTest
class MyTest extends gw.testharness.TestBase {
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.

528 chapter 35 Using GUnit

 Configuration Guide 9.0.5

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 524.

Using entity builders to create test data

Note: Guidewire does not recommend or support the use of classes that extend
gw.api.databuilder.DataBuilder or classes that reside in the gw.api.databuilder.* 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 ClaimCenter base configuration provides builders for the base entities (such as ClaimBuilder,
for example). 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 bundle.commit 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 gw.api.databuilder.DataBuilder. To view a list of valid builder types
in Guidewire ClaimCenter, use the Studio code completion feature. Type gw.api.databuilder. in the Gosu editor
and Studio displays the list of available builders.

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 gw.api.databuilder.AccountBuilder

@gw.testharness.ServerTest
class MyTest extends TestBase {

construct(testname : String) {
super(testname)
}
...
function testSomething() {
//perform some test
var account = new AccountBuilder().create()
}
...
}

Creating an entity builder

To create a new entity builder of a particular type, use the following syntax:

new TypeOfBuilder()

Using entity builders to create test data 529

 Configuration Guide 9.0.5

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 Indicates
word
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 DataBuilder.with(...) 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.

var address = new AddressBuilder()

.withAddressLine1( streetNumber + " Main St." )
...
.create()

Builder create methods

The DataBuilder class provides the following create methods:

builderObject.create( bundle )
builderObject.create()
builderObject.createAndCommit()

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.

530 chapter 35 Using GUnit

 Configuration Guide 9.0.5

Method Description
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 ClaimCenter
interface portion of a test. For example:

var address = new AddressBuilder()

.withCity( "Springfield" )
.asHomeAddress()
.create()

new PersonBuilder()
.withFirstName("Sean")
.withLastName("Daniels")
.withPrimaryAddress(address)
.create()

address.Bundle.commit()

In this example, Address and Person share a bundle, so committing address.Bundle 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 gw.transaction.Transaction

function myTest() {
var person : Person

Transaction.runWithNewBundle( \ bundle -> {

person = new PersonBuilder()
.withFirstName( "John" )
.withLastName( "Doe" )
.withPrimaryAddress( new AddressBuilder()
.withCity( "Springfield" )
.asHomeAddress() )
.create( bundle )
} )

assertEquals( "Doe", person.LastName )

Creating an entity builder 531

 Configuration Guide 9.0.5

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 Transaction.runWithNewBundle 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 bundle.commit 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 532
• “Nesting builders” on page 532
• “Overriding default builder properties” on page 532

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 gw.api.databuilder.ClaimBuilder

var activity1 : Activity

var activity2 : Activity

gw.transaction.Transaction.runWithNewBundle( \ bundle -> {

var activityBuilder = new gw.api.databuilder.ActivityBuilder()
.onClaim(new ClaimBuilder().uiReadyAuto().create(bundle) )
.withType( "general" )
.withPriority( "high" )
activity1 = activityBuilder.withSubject( "this is test activity one" ).create( bundle )
activity2 = activityBuilder.withSubject( "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:

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
Transaction.runWithNewBundle( \ bundle -> {
account = new AccountBuilder().create(bundle)

532 chapter 35 Using GUnit

 Configuration Guide 9.0.5

})
}

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 gw.api.builder.AccountBuilder
uses gw.api.builder.CompanyBuilder

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 gw.api.builder.AccountBuilder
uses gw.api.builder.CompanyBuilder
uses gw.api.builder.AddressBuilder
uses gw.api.databuilder.OfficialIDBuilder

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 gw.api.builder.AccountBuilder
uses gw.api.databuilder.OfficialIDBuilder
uses gw.api.builder.AddressBuilder
uses gw.api.builder.CompanyBuilder

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")

Entity builder examples 533

 Configuration Guide 9.0.5

.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 ClaimCenter 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 534
• “Extending the DataBuilder class” on page 535
• “Creating and testing a builder for a custom entity” on page 537

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 gw.api.databuilder.PersonBuilder

class MyPersonBuilder extends PersonBuilder {

construct() {
super( true )
}

function withAltPhone( testname : String ) : MyPersonBuilder {

set(Person#AltPhone, testname)
return this
}

The PersonBuilder class has two constructors. This code sample uses the one that takes a Boolean that means
create this class withDefaultOfficialID.

534 chapter 35 Using GUnit

 Configuration Guide 9.0.5

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 (gw.api.databuilder.DataBuilder), place your newly created
builder class in the gw.api.databuilder 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
529):

Initial Indicates
word
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 DataBuilder.set and DataBuilder.addArrayElement.
You can provide property values as any of the following:
• Simple values.
• Beans to be used as subobjects.
• Other builders, which ClaimCenter uses to create subobjects if it calls your builder's create method.
• Instances of gw.api.databuilder.ValueGenerator, which can, for example, generate a different value (to
satisfy uniqueness constraints) for each instance constructed.
DataBuilder.set and DataBuilder.addArrayElement optionally accept an integer order argument that
determines how ClaimCenter configures that property on the target object. (ClaimCenter 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. ClaimCenter 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.

Creating new builders 535

 Configuration Guide 9.0.5

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 gw.api.databuilder package also includes gw.api.databuilder.ValueGenerator. 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:
• gw.api.databuilder.SequentialIntegerGenerator
• gw.api.databuilder.SequentialStringGenerator
• gw.api.databuilder.SequentialTypeKeyGenerator

Custom builder populators

Ideally, all building can be done through simple property setters, using the DataBuilder.set or
DataBuilder.addArrayElements 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
gw.api.databuilder.populator.BeanPopulator and pass it to DataBuilder.addPopulator. 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[] ) {

e.customGroupSet( 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[] ) {

e.customGroupSet( vals[0] as Group )
}
} )

return this

536 chapter 35 Using GUnit

 Configuration Guide 9.0.5

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
ClaimCenter 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:

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 ExtCredential.eti “Creating and testing a builder
extend the User entity to include it. User.etx for a custom entity” on page
537
2. Create an ExtCrendentialBuilder by extending the Da ExtCredentialBuilder.gs “Creating and testing a builder
taBuilder class and adding withXXX methods to it. for a custom entity” on page
537
3. Create a test class to exercise and test your new builder. ExtCredentialBuilderTest.gs “Creating and testing a builder
for a custom entity” on page
537

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 ExtCredential.eti, accessible through Guidewire Studio).
• Modify the array entity definition to include a foreign key to User (in ExtCredential.eti).
• Add an array field to the User entity (in User.etx).

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 ExtCredential.eti and
enter the following:

<?xml version="1.0"?>
<entity xmlns="http://guidewire.com/datamodel" 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>

Creating new builders 537

 Configuration Guide 9.0.5

3. Modify the User entity. Find User.etx (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"/>

Next steps
See also
• For information on extending the Guidewire ClaimCenter base configuration entities, see “Extending a base
configuration entity” on page 238.
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.
For example:

package AllMyClasses

uses gw.api.databuilder.DataBuilder

class ExtCredentialBuilder extends DataBuilder<ExtCredential, ExtCredentialBuilder > {

construct() {
super(ExtCredential)
}

function withType ( type: typekey.ExtSystemType ) : ExtCredentialBuilder {

set(ExtCredential.TypeInfo.getProperty( "ExtSystem" ), type)
return this
}

function withUserName( somename : String ) : ExtCredentialBuilder {

set(ExtCredential.TypeInfo.getProperty( "UserName" ), somename)
return this
}

function withPassword( password : String ) : ExtCredentialBuilder {

set(ExtCredential.TypeInfo.getProperty( "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 535 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 AllMyClasses.ExtCredentialBuilder
uses gw.transaction.Transaction

@gw.testharness.ServerTest
class ExtCredentialBuilderTest extends gw.testharness.TestBase {

538 chapter 35 Using GUnit

 Configuration Guide 9.0.5

static var credential : ExtCredential

construct() {

function beforeClass () {
Transaction.runWithNewBundle( \ bundle -> {
credential = new ExtCredentialBuilder()
.withType( "SystemOne" )
.withUserName( "Peter Rabbit" )
.withPassword( "carrots" )
.create( bundle )
}
)
}

function testUsername() {
assertEquals("User names do not match.", credential.UserName, "Peter Rabbit")
}

function testPassword() {
assertEquals("Passwords do not match.", credential.Password, "carrots")
}

Notice the following about this code sample:

• It includes the uses statements for both ExtCredentialBuilder and gw.transaction.Transaction.
• 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:

Creating new builders 539

 Configuration Guide 9.0.5

540 chapter 35 Using GUnit

part 8

Guidewire ClaimCenter configuration

Configuration Guide 9.0.5
chapter 36

Configuring policy behavior

There are several aspects of policy behavior that you can configure in ClaimCenter.

Understanding aggregate limits

An aggregate limit is the maximum amount that an insurer is required to pay on a policy or coverage for a given
period of time. An aggregate limit effectively caps the insurer’s total liability for the specified time period.
The management tasks associated with aggregate limits include:
• Defining calculation criteria, including cost types and cost categories, which count towards a limit
• Specifying the financial transactions that count towards a limit
• Configuring policy period definitions
• Manually recalculating how much of your aggregate limits have been used using ClaimCenter batch processes
Note: If you want to use ClaimCenter to track and display aggregate limits, add the Aggregate Limits menu link to
the relevant policy types.
At the highest level, an aggregate limit can apply to a policy or an account. A limit that applies to a single policy
establishes a maximum total liability for all of the claims made against that policy. A limit that applies to an account
establishes a maximum liability for all claims made against all the policies belonging to the account. The cap applies
regardless of the number of claims made against the relevant policies or the number and variety of exposures
represented in the claims.
See also
• “How to specify policy menu links” on page 554
• Application Guide

Aggregate limit data model

The following graphic depicts a simplified view of how the AggregateLimit entity is related to other entities.

Configuring policy behavior 543

 Configuration Guide 9.0.5

Aggregate Limit Data Model

AggregateLimit CoverageLineMatchDataInfo Policy

PolicyPeriodID ClaimInfoID

PolicyPeriod PeriodPolicy ClaimInfo Claim

PolicyPeriodType PolicyPeriodID ClaimID
ClaimInfoID

CoverageLine Legend

PolicyPeriodID
A B A has a B

Claim Graph
PolicyPeriod and AggregateLimit and associated entities are cross-claim entities, which encompass multiple
claims. They are not archivable and stay behind in the production database. Each Claim has one Policy object
which holds policy data from the policy administration system and belongs to the claim. The Policy belongs to the
claim graph and is archived with it. The ClaimInfo entity is not archived and is the connecting point between the
admin/cross-claim data and the claim graph. Therefore, each PeriodPolicy (a join entity) points to its
PolicyPeriod and to a ClaimInfo to indicate that the Claim/Policy is in the PolicyPeriod.

Policy retrieval and aggregate limits

During the policy retrieval process, the Claim has not yet been associated with the PolicyPeriod. When the policy
plugin returns policy data, the Policy is associated with the Claim and the PolicyPeriod. However, you do not
have access to the Claim at this point.
As a result, you cannot add aggregate limits when using the policy search plugin. You can create limits later by
either adding them to the claim from the user interface or using ClaimPostsetup rules.
See also
• For more information on the policy search plugin, see the Integration Guide.

Defining aggregate limits

You can define aggregate limits in the Aggregate Limits menu link of a claim’s Policy screen.

544 chapter 36 Configuring policy behavior

 Configuration Guide 9.0.5

The AggregateLimit entity has the following key properties:

Entity property Description

LimitAmount The amount of the aggregate limit in the claim currency of claims in the policy period.
ValueType Aggregate limit type – Limit or deductible.
AggLimitCalcCriteria The calculation criteria, a cost type and cost category combination, to be specified for the aggregate
limit. This property maps to the LimitUsedDef element definition in the aggregate limits
configuration file, aggregatelimitused-config.xml.
PolicyPeriod The policy period to which the aggregate limit belongs.
CoverageLines Coverage lines that reference this aggregate limit. An aggregate limit can have multiple coverage
lines or none at all.

Aggregate limit configuration

In Guidewire Studio, navigate to configuration →config→aggregatelimit to view and edit the following configuration
files:
• aggregatelimitused-config.xml – Use this file to define what counts towards calculating an aggregate limit.
• policyperiod-config.xml – Use this file to define the policy period to associate with the aggregate limit.
These configuration options are described in more detail in the sections that follow.

How to define what counts towards an aggregate limit

ClaimCenter reports the Realized amount, the amount of an aggregate limit that has been eroded. In order to calculate
this accurately, for each policy type that uses the aggregate limit, you must specify the following in the
aggregatelimitused-config.xml file:
• The calculation type, calctype, defines the transaction types to count towards the limit.
• The calculation criteria, AggLimitCalcCriteriaDefinition, defines the possible options for cost types and cost
categories to include or exclude in the limit.
The file consists of a main AggregateLimitUsedConfig element and one or more
AggLimitCalcCriteriaDefinition and LimitUsedDef subelements.

Aggregate Limit Calculation Criteria Definition

The AggLimitCalcCriteriaDefinition element defines the combinations of cost types and cost categories that
will be available as options when creating an aggregate limit. You can create custom calculation criteria to exclude
different cost types and categories, based on your business requirements.
The AggLimitCalcCriteriaDefinition element has the following format:

<AggLimitCalcCriteriaDefinition code="calc_criteria">
<ExclusionCriteria excludeCostType="cost_type" excludeCostCategory="cost_category"/>
</AggLimitCalcCriteriaDefinition>

Each AggLimitCalcCriteriaDefinition can have zero or more ExclusionCriteria subelements. This

subelement, if included, must have a excludeCostType attribute specified. It may have an excludeCostCategory
attribute. The excludeCostType and excludeCostCategory attributes enable you to specify cost types and cost
categories for transactions to exclude in an aggregate limit calculation. The costtype and costCategory typelist
define the possible types for excludeCostType and excludeCostCategory.
The code value must correspond to a typekey value in the AggLimitCalcCriteria typelist. You must define the
calculation criteria in the typelist for it to appear in ClaimCenter when creating an aggregate limit.

Defining aggregate limits 545

 Configuration Guide 9.0.5

The following conditions apply when defining aggregate limit calculation criteria:
• At least one AggLimitCalcCriteria definition is mandatory. In the base configuration,
AggLimitCalcCriteria.tti contains all, which cannot be removed, but can be retired.
• You can have only one AggLimitCalcCriteriaDefinition entry marked as default. This covers cases where a
policy type is not listed in any LimitUsedDef section.
• If AggLimitCalculationCriteriaDefinition uses a code that is not defined in the AggLimitCalcCriteria
typelist, even if retired, the application server will fail to start and indicate the error in the configuration. This
definition cannot be applied to any new aggregate limits, but existing ones will continue to work.
Note: The aggregate limits batch process needs access to the calculation criteria definition from the
aggregatelimitused-config.xml file to recalculate the limit used, even if the typecode is retired.
• If an active code in the AggLimitCalcCriteria typelist is not defined by any AggLimitCalculationCriteria
element, the server will fail to start.

Aggregate Limit Used Definition

The LimitUsedDef element defines the calculation type and default calculation criteria that count towards the limits
of particular policies. You can create multiple LimitUsedDef elements to associate different policy types with
different calculation type and calculation criteria. You must specify at least one.
The LimitUsedDef element definition has the following format:

<LimitUsedDef calctype="calc_type" aggLimitCalculationCriteriaDefault="calc_criteria">

<AggLimitPolicyType code="policy_type"/>
</LimitUsedDef>

Every LimitUsedDef element contains one subelement, AggLimitPolicyType, and two attributes, calctype and
aggLimitCalculationCriteriaDefault.
• The AggLimitPolicyType subelement specifies the policy types that share the same limit definition. You must
list at least one policy for a definition. The code attribute defines the policy type. The PolicyType typelist
defines the list of possible types. A policy type can only be included in one LimitUsedDef element.
• The calctype attribute defines the financial calculation to apply while determining the realized amount of an
aggregate limit. The calctype can be one of the following:

Type Description
TotalIncurredGross The sum of total reserves plus non-eroding payments.
TotalIncurredNet The sum of total reserves plus non-eroding payments minus recoveries.
TotalPayments The sum of all submitted payments and awaiting-submission payments
whose scheduled send date is either before or on the current date.
TotalIncurredNetMinus The sum of total reserves excluding recovery reserves that are still open.
OpenRecoveryReserves

TotalPaymentsPlus TotalPayments plus payments on future-dated checks.

FuturePayments

TotalIncurredNetPlus TotalIncurredNet plus non-eroding payments on future-dated checks.

FutureNonEroding
Payments

TotalIncurredNetMinusOpenRecoveryReserves TotalIncurredNetMinusOpenRecoveryReserves plus non-eroding

PlusFutureNonEroding payments on future-dated checks.
Payments

TotalIncurredGross TotalIncurredGross plus non-eroding payments on future-dated checks.

PlusFutureNonEroding

546 chapter 36 Configuring policy behavior

 Configuration Guide 9.0.5

Type Description
Payments

• The aggLimitCalculationCriteriaDefault attribute defines the default calculation criteria to be used towards
this limit. The value of this attribute must match the code of one of the previously defined
AggLimitCalcCriteriaDefinition subelements.
• The AggLimitCalcTypeDefault element defines the default calculation type to use if a policy type is not listed
in the LimitUsedDef element. The calculation type determines the transaction subtypes to apply towards the
limit used in the aggregate limit. In the case of account-level aggregate limits, the calculation type is the system
default.

Aggregate Limit Configuration: Example

In the following example, the LimitUsedDef element defines the costs for commercial and personal automobile
policies. Three custom calculation criteria are defined, all (default), costTypesExcludingLegalExpenses, and
costTypesExcludingExpenses.

<AggregateLimitUsedConfig
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="aggregatelimitused-config.xsd">

<AggLimitCalcCriteriaDefinition code="all" default="true"/>

<AggLimitCalcCriteriaDefinition code="costTypesExcludingExpenses">
<ExclusionCriteria excludeCostType="unspecified"/>
<ExclusionCriteria excludeCostType="dccexpense"/>
<ExclusionCriteria excludeCostType="aoexpense"/>
</AggLimitCalcCriteriaDefinition>

<AggLimitCalcCriteriaDefinition code="costTypesExcludingLegalExpenses">
<ExclusionCriteria excludeCostType="unspecified" excludeCostCategory="legal"/>
<ExclusionCriteria excludeCostType="aoexpense" excludeCostCategory="legal"/>
<ExclusionCriteria excludeCostType="dccexpense" excludeCostCategory="legal"/>
</AggLimitCalcCriteriaDefinition>

<AggLimitCalcTypeDefault defaultCalctype="TotalIncurredNet"/>

<LimitUsedDef
calctype="TotalIncurredNet"
aggLimitCalculationCriteriaDefault="costTypesExcludingExpenses">
<AggLimitPolicyType code="PersonalAuto"/>
<AggLimitPolicyType code="BusinessAuto"/>
</LimitUsedDef>

</AggregateLimitUsedConfig>

For the policy types included in the LimitUsedDef subelement, the total incurred net value of financial transactions
is used in the aggregate limit calculation. The calculation criteria for aggregate limits defined for these policy types
will default to the corresponding value in the typelist for costTypesExcludingExpenses. You can still choose to
change the calculation criteria while creating the aggregate limit.

Aggregate limit configuration 547

 Configuration Guide 9.0.5

From this, ClaimCenter calculates an aggregate limit’s used amount as follows:

• For each transaction that belongs to the policy period attributed to the limit, ClaimCenter determines its claim's
policy type.
• If the configuration file does not list the policy type, then the transaction does not contribute to the limit used
calculation.If the configuration file does list the policy type, ClaimCenter determines whether the LimitUsedDef
to which the policy type belongs lists the transaction's cost type in aggLimitCalculationCriteriaDefault.
◦ If LimitUsedDef does not list the cost type, then it does not contribute to the limit used calculation.
◦ If LimitUsedDef does list the cost type, then ClaimCenter retrieves the calculation type associated with cost
type.
Then, ClaimCenter determines whether that the transaction applies to the aggregate limit (and how to calculate the
transaction). It then calculates the amount and applies it to the limit used for that aggregate limit.

IMPORTANT Changing the aggregatelimitused-config.xml file can have multiple implications. You might
have to run the aggregate limits batch process again, depending on the type of change.

See Also
• System Administration Guide

Configuring policy periods

A policy period identifies the policy or policies that count towards an aggregate limit. The policy period does this by
defining the following:
• The effective time period for the aggregate limit
• The set of policy data fields that must be identical for the policy to count towards an aggregate limit
In ClaimCenter, policy periods are created as needed for aggregate limits, based on the definitions in the
policyperiod-config.xml file. The definitions in this file function as the blueprint for your policy periods. A
policy period definition, PolicyPeriodDef, is a configuration object that determines the form and functionality of
one or more policy periods.
ClaimCenter bases aggregate limits on policy periods. A specific and unique policy period identifies the claims that
count towards an aggregate limit. When a policy is created, ClaimCenter searches for an existing policy period that
matches the properties of the policy. If there is no existing policy period that matches the policy, ClaimCenter uses
the appropriate policy period definition as a template to create the necessary policy period.

WARNING After you create a policy period definition and ClaimCenter begins to use it, do not attempt to
change it. Guidewire does not support updating policy periods to reflect a new policyperiod-config.xml
definition.

The syntax of a policy period definition is as follows:

<PolicyPeriodDef type="type">
<PolicyTypeConfig code="policy_type"/>
...
<PolicyField fieldName="fieldName"/>
...
</PolicyPeriodDef>

This definitions uses the following elements:

• The PolicyPeriodDef element defines an individual policy period. Within this element, you must specify at
least one PolicyTypeConfig element and one PolicyField element.

548 chapter 36 Configuring policy behavior

 Configuration Guide 9.0.5

Note: If you do not define at least one PolicyPeriodDef, you effectively disable aggregate limits in your
installation.
• The type parameter takes one of two values: policy or account.
• The PolicyTypeConfig element specifies the policy type to which the definition applies. This is a code from the
PolicyType typelist. PolicyPeriodDef must include a PolicyTypeConfig element for each policy type that
you want to include in the definition. The PolicyField element specifies a policy data field to include in the
period definition. There are five allowable fields, all of which are also fields of the PolicyPeriod entity.
◦ AccountNumber – Used with policy period definitions of type “account.” A case-sensitive text field in a
policy’s definition identifies the name or number of the account to which the policy belongs.
◦ PolicyNumber – The alphanumeric value that ClaimCenter uses to identify a policy.
◦ EffectiveDate – The date on which an individual policy goes into effect.
◦ ExpirationDate – The date on which an individual policy goes out of effect.
◦ PolicySuffix – The unique, alphanumerical value that you append to a policy number to differentiate
between effective years for a policy, also called Mod or Module. Typically, you use this only for policy
◦ periods of type policy.
The PolicySuffix field acts as an implicit time period. It identifies both an effective date and an expiration
date. By including the suffix, you ensure that claims made in different years are not mistakenly aggregated into
the same limit.

Policy-based Period Definition: Example

The following PolicyPeriodDef example ensures that all claims made against a specific automobile policy count
against aggregate limits defined for that policy period or policy term.

<PolicyPeriodDef type="policy">
<PolicyTypeConfig code="PersonalAuto"/>
<PolicyTypeConfig code="BusinessAuto"/>

<PolicyField fieldName="PolicyNumber"/>
<PolicyField fieldName="PolicySuffix"/>
</PolicyPeriodDef>

This definition specifies that a single aggregate limit applies for all policies that meet the following criteria:
• All are either of type personal auto or commercial auto and
• All have the same policy number and
• All have the same policy suffix

Account-based Period Definition: Example

The following PolicyPeriodDef example ensures all policies belonging to the same account count towards
aggregate limits.

<PolicyPeriodDef type="account">
<PolicyTypeConfig code="GeneralLiability"/>
<PolicyTypeConfig code="CommercialProperty"/>
<PolicyTypeConfig code="InlandMarine"/>
<PolicyTypeConfig code="Homeowners"/>

<PolicyField fieldName="AccountNumber"/>
<PolicyField fieldName="EffectiveDate"/>
<PolicyField fieldName="ExpirationDate"/>

</PolicyPeriodDef>

Aggregate limit configuration 549

 Configuration Guide 9.0.5

This definition specifies that the policies included in the limit meet the all of the following criteria:
• All are of type general liability, commercial property, inland marine, or homeowners LOB
• All have the same AccountNumber value
• All have the same effective date
• All have the same expiration date

Storing aggregate limit data

ClaimCenter uses the entity, ClaimAggregateLimitRpt, to store the amount used for each claim that contributes to
an aggregate limit. If the aggregate limit uses a coverage line, it is stored in ClaimAggregateLimitRpt along with
the corresponding contribution amount.
The ClaimAggregateLimitRpt entity is associated with a PolicyPeriod, ClaimInfo, and optionally, a
CoverageLine object. Consequently, the limit used amounts stored in this entity are updated dynamically based on
ClaimCenter changes. Some examples are when a claim moves from one policy period to another, when the loss
date or reported date changes, or when transaction information is updated.
This entity is not in the claim graph, and this enables ClaimCenter to use and edit aggregate limit data even when
one or more of the contributing claims are archived.

Aggregate limit used recalculation

Any time you make relevant changes to claim data, ClaimCenter automatically recalculates how much of an
aggregate limit is used. As a general rule, you do not need to manually recalculate the realized portion of your limits.
However, if it becomes necessary for you to perform a manual recalculation, you can do so.
If any of the database consistency checks related to aggregate limits fail, you need to instruct ClaimCenter to
recalculate the aggregate limit values. You also need to instruct ClaimCenter to repopulate the database tables. The
following commands are used to recalculate aggregate limits:
• To rebuild aggregate limits marked as invalid in the database:

maintenance_tools -rebuildagglimits

This command finds all policy periods with at least one invalid aggregate limit and rebuilds all limits within that
period.
• To rebuild aggregate limits for a single claim or one or more comma-separated claims:

maintenance_tools -rebuildagglimits -claims <claimnumbers>

• To rebuild aggregate limits for a single policy or one or more comma-separated policies:

maintenance_tools -rebuildagglimits -policies <policynumbers>

• To rebuild all aggregate limits in the system:

See also
• For information on the aggregate limits batch processes, see the System Administration Guide.

Advanced aggregate limit configuration

Aggregate limits can be configured using the definitions in the configuration file, aggregatelimitused-
config.xml, in conjunction with any user-defined selections of coverage types, subtypes, and covered items in the
user interface. In addition, ClaimCenter also allows you to extend the configuration file using the
AggregateLimitTransactionPlugin. It provides additional flexibility for those who wish to include custom Gosu
code to specify transaction or claim eligibility for an aggregate limit.

550 chapter 36 Configuring policy behavior

 Configuration Guide 9.0.5

This topic describes the AggregateLimitTransactionPlugin and illustrates its use with some configuration
examples.

The AggregateLimitTransactionPlugin plugin implementation

The AggregateLimitTransactionPlugin implementation determines the eligibility of a transaction to an aggregate
limit. You can create your own custom plugin implementation, which delegates to the base implementation, as
needed.

IMPORTANT Deploying a new implementation of the AggregateLimitTransactionPlugin might potentially

impact many aggregate limits. After any such changes, you are responsible for updating all limits. Even a forced
rebuilding of all limits cannot accurately recalculate values for aggregate limits that reference archived claims.

The AggregateLimitTransactionPlugin plugin has two responsibilities:

• Given a transaction and an aggregate limit, determine whether the transaction applies toward the limit.
• Determine if a change to a transaction or related entity might alter the applicability of a transaction to some limit.
When transaction-related information changes, ClaimCenter needs to know if any aggregate limits must be
recalculated. ClaimCenter has built-in checks for known changes that trigger recalculation, such as changing the
amount of a transaction, or adding a new coverage line to an aggregate limit. However, if custom logic has been
added to determine applicability, then a completely different type of change may need to trigger recalculation.
The AggregateLimitTransactionPlugin enables customers to communicate the entity types that can possibly
trigger a change in applicability and whether a change to one of those entities impacts applicability.
The plugin uses the standard aggregate limit method, configurationAppliesTo(transaction), which returns a
boolean value, to evaluate transactions. In the base configuration, this method simply refers to
aggregatelimitused-config.xml and determines whether the transaction applies to the aggregate limit. You can
include additional custom logic to extend the configuration defined in aggregatelimitused-config.xml by using
the methods detailed next.
To determine if a change to the transaction or a related entity impacts the applicability of the transaction to the
aggregate limit, the following two methods are used:
• claimWithChangedTransactionApplicability – This method examines the given modified entity to determine
if the change impacts the eligibility of associated transactions to a specific aggregate limit. If the modification
impacts transactions contributing towards the aggregate limit calculation, the method returns the corresponding
claim. ClaimCenter then recalculates the aggregate limit.
This check is for non-standard changes that might impact aggregate limit calculation. ClaimCenter already
checks a predefined set of fields, such as a transaction’s amount, that might trigger recalculation. The purpose of
this method is to define checks for customizations and extensions to the base configuration.
This method will only be called for a modified entity whose type is included in
typesWhichAffectApplicability.
• typesWhichAffectApplicability – This method specifies the modified entity types that are called by
claimWithChangedTransactionApplicability. In the base configuration, this method returns a set of entities
of the type Transaction.
See also
• “Aggregate limit used recalculation” on page 550
• “What are plugins?” on page 135
•

Advanced aggregate limit configuration 551

 Configuration Guide 9.0.5

Example – Configure a claim for aggregate limits

About this task
This examples extends the base configuration AggregateLimitTransactionPlugin plugin implementation to
exclude or include a claim from being applied towards aggregate limits. It preserves the configuration checks
included in aggregatelimitused-config.xml and adds an additional check for a custom, claim-level flag that
turns aggregate limit eligibility on or off for the claim.

Procedure
1. If necessary, start Guidewire Studio.
At a command prompt, navigate to the ClaimCenter directory and enter:

gwb studio

2. Navigate to configuration→config→Extensions→Entity and open Claim.etx.

3. Click the plus icon ( ), and select column from the drop-down choice list.
4. Enter the following values:

Name Value
name AggregateLimitsApply

type bit

desc Flag that indicates if this claim applies towards aggregate limits.

5. Compile and save your changes.

6. Add a custom Gosu plugin implementation, as follows:

/**
* Implementation that uses a custom AggregateLimitsApply field to turn aggregate limits
on/off per claim.
*/
class ExampleAggregateLimitPlugin implements IAggregateLimitTransactionPlugin
{

var _delegate = new AggregateLimitTransactionPluginImpl()

override function aggregateLimitApplies(limit: AggregateLimit, transaction: Transaction) : boolean

{
// Verifies the transaction against the configuration and also checks the AggregateLimitsApply
field.
return _delegate.aggregateLimitApplies(limit, transaction)
and transaction.Claim.AggregateLimitsApply
}

override function typesWhichAffectApplicability() : Set<IEntityType>

{
// Adds Claim to the set of types which can affect applicability.
return _delegate.typesWhichAffectApplicability().union({Claim})
}

override function claimWithChangedTransactionApplicability(modifiedEntity: KeyableBean) : Claim

{
// Check base configuration and then, also check if the AggregateLimitsApply field has changed.
var affectedClaim = _delegate.claimWithChangedTransactionApplicability(modifiedEntity)
if (affectedClaim == null)
{
if (modifiedEntity typeis Claim and modifiedEntity.isFieldChanged(Claim#AggregateLimitsApply))
{
affectedClaim = modifiedEntity
}
}
return affectedClaim

552 chapter 36 Configuring policy behavior

 Configuration Guide 9.0.5

}
}

7. Save your changes.

Example – Configure aggregate limits for deductible recoveries

About this task
This examples extends the base configuration AggregateLimitTransactionPlugin plugin implementation to only
include deductible recoveries. If the limit type is deductible, only recoveries with the category, deductible, contribute
to the aggregate limit. For all other aggregate limits, whose limit type is limit, the base configuration
implementation will be in effect.

Procedure
1. If necessary, start Guidewire Studio.
At a command prompt, navigate to the ClaimCenter directory and enter:

gwb studio

2. Override the plugin implementation, as follows:

class ExampleAggregateDeductiblePlugin implements IAggregateLimitTransactionPlugin

{

static final var WITH_LIMITS = RecoveryCategory.TC_DEDUCTIBLE

static final var deductibleType = AggregateType.TC_DEDUCTIBLE
var _delegate = new AggregateLimitTransactionPluginImpl()

override function aggregateLimitApplies(limit: AggregateLimit, transaction: Transaction) : boolean

{

if (limit.ValueType != deductibleType)
return _delegate.aggregateLimitApplies(limit, transaction)
else
return _delegate.aggregateLimitApplies(limit, transaction)
and transaction.RecoveryCategory == WITH_LIMITS

override function typesWhichAffectApplicability() : Set<IEntityType>

{
return _delegate.typesWhichAffectApplicability().union({Recovery})
}

override function claimWithChangedTransactionApplicability(modifiedEntity: KeyableBean) :Claim

{
var affectedClaim = _delegate.claimWithChangedTransactionApplicability(modifiedEntity)
if (affectedClaim == null)
{
if (modifiedEntity typeis Recovery and recoveryCategoryChangedToOrFromNoLimits
(modifiedEntity))
{
affectedClaim = modifiedEntity.Claim
}
}
return affectedClaim
}

private function recoveryCategoryChangedToOrFromNoLimits(recovery: Recovery): boolean

{
return recovery.RecoveryCategory== WITH_LIMITS
or recovery.getOriginalValue(entity.Recovery#RecoveryCategory) == WITH_LIMITS
}
}

3. Save your changes.

Advanced aggregate limit configuration 553

 Configuration Guide 9.0.5

How to specify policy menu links

You can customize the menu links that appear on the Policy menu of a claim file. For example, an automobile policy
can include a menu link with a list of vehicles and a property policy can include a link with a list of locations.
The Policy page always contains the General menu link, and you can add one or more other options. The PolicyTab
typelist defines available menu links that you can add.
You can specify the menu links in the PolicyType typelist in Guidewire Studio. To define a policy type, use the
category tab to add a typelist and typecode from the PolicyTab typelist.
In addition, if the menu link you want to add is Aggregate Limits, you must add the policy type to the following two
configuration files:
• aggregatelimitused-config.xml
• policyperiod-config.xml
See also
For more information on the configuration files, see:
• “Aggregate limit configuration” on page 545
• “Configuring policy periods” on page 548

How to define internal ClaimCenter policy fields

Typically, applications external to ClaimCenter store the primary policy data. Thus, ClaimCenter imports policy
snapshots for use with claims. Depending on the status of the policy within ClaimCenter, it can be classified as
verified or unverified.
• A verified policy in ClaimCenter reflects the policy from the external application. You cannot modify it in -
ClaimCenter.
• An unverified policy does not necessarily reflect the external application.
You can use the status of a policy to in your configuration of the application. For example, you might configure
validation rules so that you can only make payments on a claim that has verified policies associated with it.
In reality, it is often useful to have a hybrid policy structure. With a hybrid structure, you can maintain a connection
to an external application with a verified policy and add additional policy data fields for use in ClaimCenter. You
add these data fields as internal-only fields to a policy, and ClaimCenter manages these internally. It does not change
or delete them if you refresh the policy snapshot from the external application or even if you change to a different
policy. You can also edit internal fields without causing the policy to become unverified.

How to create internal-only fields

While the base configuration does not contain internal-only fields, you can define them in the Policy entity file
extension (Policy.etx) and modify the targeted PCF files in Guidewire Studio. The ClaimPolicyGeneral.pcf file
contains multiple Edit buttons, each one providing a different level of control over editing policies.
You can edit:
• An unverified policy
• A verified policy without internal-only fields
• Internal-only fields on the policy if the user does not have permission to edit a verified policy
• Optionally edit the entire policy or its internal-only fields if the policy has such fields and the user has the
permissions to edit them

554 chapter 36 Configuring policy behavior

 Configuration Guide 9.0.5

Example – Add a custom column on a policy

About this task

This example explains how to add a custom column on an auto policy.

Procedure
1. Right-click the Policy.eti file and select New→Entity Extension to create Policy.etx.
2. Internal-only fields can be regular columns, foreign keys, or arrays.
Use the <internalonlyfields> element to list the fields that are internal to ClaimCenter, and use the
<internalfield> element to identify a particular field. You can list multiple <internalfield> elements,
with each specifying one field.
Define your internal-only field in that file, for example:

<extension xmlns="http://guidewire.com/datamodel" entityName="Policy">

<column name="CustomColumn" type="varchar">
<columnParam name="size" value="30"/>
</column>
<internalonlyfields>
<internalfield name="CustomColumn" />
</internalonlyfields>
</extension>

3. Save your work.

4. Open the PolicyGeneralPanelSet_Auto.pcf file and add a new field that is internal-only.
In the Basic properties tab, ensure that editable is set to true and assign a unique label and value.
This example uses the label Internal Notes with a value of Policy.Notes and the id is CustomColumn.
5. Since required is set to true in Basic properties, and this is not necessary, remove it.
6. Save your work in Studio and restart the application server.
7. Open an auto claim in ClaimCenter and navigate to the Policy menu on the left pane. Select it to view the
Policy:General screen.
8. If you select Edit, you can either modify the entire policy or ClaimCenter-only fields. Select the latter.
9. Edit the field you created and save your changes.

Result
In the Policy:General screen, notice that under the Other section, the Verified Policy field is still set to Yes.

How to create internal-only fields 555

 Configuration Guide 9.0.5

556 chapter 36 Configuring policy behavior

chapter 37

Configuring snapshot views

This topic explains how to configure snapshot views for use with your claims.

How ClaimCenter renders claim snapshots

A first notice of loss (FNOL) snapshot is a persistent copy of a claim and the graph of entities it references. An
FNOL snapshot records the data provided to an insurer at the time of the insured’s first notification of loss.
ClaimCenter creates an FNOL snapshot as you create a claim by using the New Claim wizard or as you import a claim
into ClaimCenter from an external FNOL application.
Note: ClaimCenter takes FNOL snapshots by default. You can prevent ClaimCenter from creating FNOL
snapshots by setting the config.xml parameter EnableClaimSnapshot to false.
An FNOL snapshot retains the claim data in its original form regardless of subsequent changes to the claim record.
The FNOL snapshot contains the FNOL data as it existed at the moment the claim was created. You can view the
FNOL snapshot for a claim by opening the claim and clicking FNOL Snapshot in the Sidebar.
ClaimCenter stores a snapshot in the ClaimSnapshot entity instance associated with a claim. The application stores
the snapshot data as an XML document in the ClaimData property of the ClaimSnapshot instance. The claim
snapshot also tracks the ClaimCenter version used to capture the snapshot data.
If ClaimCenter renders an FNOL snapshot, it renders the snapshot data in a format similar to that of the Loss Details
screen. Because it is possible that, between versions of ClaimCenter, the default fields that accompany claims
change, the ClaimData object can capture different data between releases. To support differing data, ClaimCenter
contains version-specific PCF files to render the FNOL snapshot. You can access these files in Studio by navigating
in the Project window to configuration→config→Page Configuration→pcf→claim→snapshot.

Understanding snapshot PCF interaction

The configuration→config→Page Configuration→pcf→claim→snapshot folder contains at its top level a number of modal
PCF files. For these modal files, ClaimCenter retrieves a version-specific PCF file from the underlying
subdirectories based on the original version of the snapshot. For example, if you select FNOL Snapshot in
ClaimCenter, ClaimCenter opens the modal ClaimSnapshotLossDetails file. This PCF file declares the variable
Snapshot, which has as its initial value gw.api.snapshot.ClaimSnapshotUtil.getSnapshot(Claim), the
snapshot corresponding to the Claim variable.

Configuring snapshot views 557

 Configuration Guide 9.0.5

ClaimCenter uses a method to retrieve the Version value from the snapshot data. The mode attribute of the
ScreenRef element uses the Version to locate the appropriate PCF file. The current release uses the PCF files in the
default folder, for example ClaimSnapshotLossDetailsScreen.default.pcf. For previous releases, you see
release-specific matches for this modal call:
• ClaimSnapshotLossDetailsScreen.300.pcf
• ClaimSnapshotLossDetailsScreen.310.pcf
• …
• ClaimSnapshotLossDetailsScreen.800.pcf
For example, if you request snapshots created with ClaimCenter 8.0, the application renders the loss details by using
the 800→ClaimSnapshotLossDetailsScreen.800 file.
The PCF file takes as arguments the Claim and the Snapshot. The code declares the Snapshot variable as
dynamic.Dynamic. ClaimCenter uses this variable to build and display a snapshot object by examining the XML in
the ClaimData property on the ClaimSnapshot object.
The properties of the claim snapshot are also dynamic. To access the properties of the dynamic snapshot, you use the
snapshot API provided by util.Snapshot. For example, to get the type of a contact for the claim, use code similar
to the following line.

util.Snapshot.getEntityType(myContact)

See also
• Gosu Reference Guide

Encrypting claim snapshot fields

ClaimCenter provides field-level encryption on sensitive data, such as tax IDs. Those fields are also encrypted on
claim snapshots.
There are two configurable components to this process:
• Your algorithm called by the IEncryption plugin – In this case, you must provide an algorithm in a plugin
class implementation.
• The Encryption Upgrade work queue – You can configure this work queue to run at a different time. You can
also determine the number of snapshots that are upgraded at one time.
If you use claim snapshots and you decide to change your encryption algorithm, the Encryption Upgrade work
queue updates those encrypted fields by using the most current encryption algorithm.
See also
• To understand how the Encryption Upgrade work queue functions, see the System Administration Guide.

How to configure snapshot templates

ClaimCenter bases the FNOL snapshot pages that it provides on the ClaimCenter default elements. For example, the
ClaimSnapshotLossDetailsScreen.default.pcf file renders the same basic Loss Details page as
ClaimLossDetail.pcf.
Note: If you extend the basic loss detail files for any release, you also need to update any corresponding claim
snapshot files. In a similar manner, if you add new exposure fields in a release, then you also need to update the
corresponding exposure snapshot files.
Configuring snapshot files can involve:
• Editing snapshot PCF files to change the values that appear in a rendered page.

558 chapter 37 Configuring snapshot views

 Configuration Guide 9.0.5

This FNOL snapshot configuration task is the most common one. Typically, data rendered in a snapshot page
must be the same data and be presented in the same way as data in the corresponding data view. You add entity
listings to or remove them from files as needed.
• Adding a new page or panel view.
This situation usually arises if you have added one or more custom pages. If you add a custom page, you also
need to modify the appropriate pages to reference your new page.

IMPORTANT Use source control or a backup to save original versions of the ClaimCenter default snapshot
templates before you modify them.

Snapshots and data model extensions

Snapshot PCF files do not access the ClaimCenter database. Instead, ClaimCenter extracts the snapshot data from
the ClaimData text property on the ClaimSnapshot object. This column contains an XML description of the FNOL
on the claim. This implementation has implications for data model extensions and changes:
• If you extend or change the ClaimCenter data model before the application captures an FNOL snapshot,
ClaimCenter captures your extension in the snapshot if there is actually data to capture.
• Pre-existing snapshot data does not capture any data model extensions or changes that you make.
Note: If a particular snapshot does not contain the data your page references, then ClaimCenter displays the FNOL
snapshot fields as empty.

How to configure snapshot templates 559

 Configuration Guide 9.0.5

560 chapter 37 Configuring snapshot views

chapter 38

Configuring lines of business

A line of business (LOB) is a business unit that is independent of other business units in a company. ClaimCenter
enables you to model the responsibilities of each business unit of an insurance carrier. When you model the business
structure, you also configure ClaimCenter screens and methods of handling claims for each part of your business.
You model your business structure by configuring the relationships between a set of typelists:
• LossType and LOBCode – Model which business units cover each kind of loss.
• LOBCode and PolicyType – Model the kinds of policies written by each business unit.
• PolicyType and CoverageType – Model the types of coverages that policies can contain.
• CoverageType and CoverageSubtype and ExposureType – Model the kinds of exposures that are compatible
with coverages.
In the base configuration, the LOB typelists contain values for the following lines of business:
• Businessowners Line
• Commercial Auto Line
• Commercial Property Line, which includes Commercial Package and Commercial Property policy types
• General Liability Line
• Homeowners Line
• Inland Marine Line
• Other Liability Line, which includes Farmowners and Professional Liability policy types
• Personal Auto Line
• Personal Umbrella Line
• Travel
• Workers’ Compensation Line
You can define new lines of business by adding to LOBCode and the other LOB typelists.

Configuring lines of business 561

 Configuration Guide 9.0.5

LOB typelists
ClaimCenter uses a set of typelists, the line of business typelists, to configure the screens you see when entering a
new claim and working with existing ones. You can see these typelists in ClaimCenter Studio by navigating in the
Project window to configuration→config →Extensions →Typelist.
Because the typelists have a hierarchical relationship, the Line of Business tab of the Typelists editor displays the
values of the typelists as a tree. For example, with the LossType typelist open in the editor, the Line of Business tab
displays a number of LOBCode children for each LossType typecode. Each LOBCode child has PolicyType children,
and so on.
In the base configuration, ClaimCenter provides the following LOB typelists, listed in hierarchical order:
• LossType.ttx – A category of activity that is an industry standard for insurance activity, such as Auto, Liability,
Property, or Workers’ Compensation. Selecting a loss type is one of the early steps in defining a claim. It is a way
of grouping your lines of business together.
A LossType typecode does not have a parent, but it can have multiple children that are LOBCode typecodes. The
relationship of LossType to LOBCode is one to many.
• LOBCode.ttx – A type of work handled by one business unit of an insurance company. In many cases, a claim's
LOBCode is uniquely determined by the combination of its LossType and PolicyType. If it is not, the LOBCode
can be selected in the Loss Details screen of the New Claim wizard and the claim. More than one LOB can handle
the same type of loss. For example, both personal and commercial auto LOBs sell policies covering losses from
vehicles, the Auto loss type.
An LOBCode typecode can have multiple children from the PolicyType typelist, but only one parent, a LossType
typecode. The relationship of LOBCode to LossType to is many-to-one.
• PolicyType.ttx – A product—policy—sold by an LOB unit. A policy pays damages for certain defined loss
events. One business unit can sell many types of policies. A given policy can be sold by many LOBs, so
PolicyType and LOBCode have a many-to-many relationship in the data model.
• CoverageType.ttx – A subdivision of a policy that deals with one kind of loss covered by the policy. For
example, a personal injury protection (PIP) policy could have medical, lost wages, and death coverages, so you
can associate many coverages with a specific policy. These coverages define the product that is sold. Also, a
particular type of coverage can be allowed for many policies. Thus, PolicyType and CoverageType are related
in a many-to-many relationship.
• CoverageSubtype.ttx – Specifies an ExposureType that is compatible with a CoverageType. An
ExposureType is a set of information collected in the ClaimCenter user interface when creating a exposure. A
CoverageSubtype typecode acts like a join between CoverageType and ExposureType. When the ClaimCenter
user selects a CoverageSubtype as part of creating an exposure, they are really setting the ExposureType. The
CoverageSubtype the user selects becomes a property of the Exposure and not the Coverage.
This typelist effectively relates each CoverageType to one or more ExposureType typecodes. CoverageSubtype
has many-to-one relationships to both CoverageType and ExposureType, so it effectively creates a many-to-
many relationship between CoverageType and ExposureType. By convention, if a CoverageType is compatible
only with one ExposureType, then the CoverageSubtype linking them is named after the CoverageType.
Otherwise, its name is a concatenation of the CoverageType and a string indicating the ExposureType.
• ExposureType.ttx – ExposureType controls the mode of the screen used to create, display, or edit an exposure.
This use of modes enables a relatively small number of user interface elements to be shared by exposures with a
much larger number of possible coverage subtypes. In a claim, exposures relate coverages to claimants, and an
exposure is a unique combination of a coverage and a claimant. For example, an auto accident claim would
typically have an exposure for the owner of each vehicle damaged, as well as one for each person injured. An
ExposureType cannot have any children. It has a one-to-many relationship with its parent typelist,
CoverageSubtype.

562 chapter 38 Configuring lines of business

 Configuration Guide 9.0.5

See also
• “Relationships among LOB typelists” on page 563

LOB Typelists and policies

Information about the LossType, LOBCode, PolicyType, CoverageType, and CoverageSubtype is ultimately
determined by the policy administration system, such as Guidewire PolicyCenter. ClaimCenter maintains local
information about the structure of a policy, but this information maps to equivalent information in the policy
administration system. When ClaimCenter retrieves a policy from the policy administration system, ClaimCenter
uses its local information to interpret and store the policy information.
Information about ExposureType is unique to ClaimCenter. ExposureType is a mechanism used to streamline the
gathering of information about a loss. Therefore, there is no analog to exposure type in the policy administration
system.

LOB typelists and incidents

While not technically part of the LOB model, the Incident typelist, which represents subclasses of the Incident
entity, also relates to the LOB typelists. Every non-final entity type automatically has a corresponding typelist with
the same name whose values represent each of the subclasses of the entity. For entity.Incident, there is
typekey.Incident, which has typecodes like TripIncident, InjuryIncident, and so on.
There is a many-to-one relationship between ExposureType and the Incident typelist. Every instance of Exposure
refers to an instance of Incident, and this relationship determines the specific type of incident that it is, based on
the exposure's ExposureType. There are differences between this relationship and the others in the core LOB model:
• The categories representing this relationship are unidirectional, going only from ExposureType to Incident.
• Incident types do not appear as children of ExposureTypes in the LOB editor. They are non-LOB typecodes
edited by using the Other Categories folders in the LOB editor.
See also
• “Relationships between LOB typelists and other typelists” on page 566
• “Add a non-LOB typecode” on page 571

Relationships among LOB typelists

LOB typelists are related to each other and refer to each other by using two-way category references. A typelist
category is a reference from one typecode to another typecode, usually in a different typelist. Categories allow the
typecodes in the referring typelist to be categorized into groups identified by the typecodes in the referred-to
typelist. The relationship between a parent and child LOB typecode is represented by a category on the parent
referring to the child and another on the child referring to the parent.
Studio represents the parent-child relationship directly in the LOB tab of the Typelists editor. In the tree under a
typecode, you can see Parents and Children nodes for each typecode that has them.
The LOB hierarchy is not a strict hierarchy. Some relationships in the structure are many-to-many, so some
typecodes can have multiple parents. For example, typecodes in PolicyType and CoverageType can have multiple
parents. In contrast, typecodes in CoverageSubtype and LOBCode can have only one parent. Additionally, LossType
has no parents, and ExposureType has no children.
To view and edit these two-way relationships, adding a child to or removing a child from its parent, use the LOB tab
of the Typelists editor. The LOB tab manages parent and child relationships among LOB typelists by changing both
adjacent typelists.

LOB Typelists and Relationships

The following table lists the LOB typelists and their parent-child relationships.

LOB typelists 563

 Configuration Guide 9.0.5

Typelist Parent Child

LossType - LOBCode

LOBCode LossType PolicyType

PolicyType LOBCode CoverageType

CoverageType PolicyType CoverageSubtype

CoverageSubtype CoverageType ExposureType

ExposureType CoverageSubtype -

The following diagram shows the relationships between the LOB typelists:

ClaimCenter LOB Typelist Relationships

«typelist»
LossType

*
«typelist»
LOBCode
*

*
«typelist»
PolicyType
*

*
«typelist»
CoverageType

*
«typelist»
CoverageSubtype Legend
* A B
Bidirectional:
* * Many to Many
One to Many (A to B)
A B
«typelist» * Many to One (B to A)

ExposureType A B
Bidirectional:
One to One (B to A)

564 chapter 38 Configuring lines of business

 Configuration Guide 9.0.5

Edit a typecode with multiple parents

About this task
If a typecode has multiple parents, it is listed in the Typelists editor tree in the Children folder for each parent. Each of
these elements represents the same typecode. Therefore, editing the typecode in one place affects all appearances of
it.
For example:

Procedure
1. Open the LOBCode typelist in the typelist editor and click the LOB tab.
2. Right-click Commercial Auto Line and chose Add new→PolicyType.
3. For Code enter additionalpip. For Name enter Additional PIP. For Description enter Additional PIP.
4. Right-click the Personal Auto Line LOB code and chose Add new→PolicyType.
5. In the Add PolicyType dialog, click the Select typecode tab and choose the PolicyType you created previously,
additionalpip. This typecode now becomes a child of both Commercial Auto Line and Personal Auto Line.
6. Navigate to Personal Auto Line→Children→Additional PIP.
7. Right-click Additional PIP and choose Add new→CoverageType.
8. In the Add PolicyType dialog, click the Select typecode tab and choose any CoverageType.
9. Navigate to Commercial Auto Line→Children→Additional PIP→Children. You can see that the CoverageType you
added under Personal Auto Line appears there as well. Because the two Additional PIP nodes represent the
same PolicyType typecode, their properties, including their set of parents and children, are always identical.

Next steps
See also
• “LOB typelist validations” on page 565
• “Editing LOB typelists and typecodes” on page 568

LOB typelist validations

ClaimCenter performs a set of validations on LOB typelists on startup, especially with respect to mutual
dependencies and the ways in which they relate to one another. The LOB typelist categories define these
relationships.
Note: Relationships between the typelist pairs must be bidirectional. For example, LossType.AUTO is linked to
LOBCode.PersonalAutoLine, then LOBCode.PersonalAutoLine must be linked to LossType.AUTO.
The following validations are currently executed in the base configuration:
• Every LossType must be linked to at least one LOBCode, and an LOBCode must be linked to exactly one
LossType.
• Every LOBCode must be linked to at least one PolicyType.
• Exactly one CoverageType must be linked to a CoverageSubtype.
• A CoverageSubtype must be linked to exactly one ExposureType.
• Every ExposureType must be linked to exactly one Incident.

Relationships among LOB typelists 565

 Configuration Guide 9.0.5

See also
• “LOB typelists” on page 562

Relationships between LOB typelists and other typelists

An LOB typecode can be referenced through typelist categories by a typecode from a non-LOB typelist, and it can
reference a typecode in a non-LOB typelist. Outside the LOB structure, Studio does not maintain referential
integrity.
If you modify one of the LOB typelists in the Typelists editor, you might also need to modify other non-LOB
typelists or PCF files that reference your modified typelist. The LOB tab of the Typelists editor does not edit non-
LOB typelists associated with these six typelists. It also does not edit Gosu code or PCF files that reference these six
typelists. If you make changes to an LOB typelist that affect related typelists, Gosu code, and PCF files, you must
update these related files, or you can cause errors.
See also
• “LOB typelists” on page 562

LOB typelists referenced by non-LOB typelists

The following typelists are examples of LOB typelists that are referenced by—have incoming categories for—non-
LOB typelists. You can see the incoming categories for each typecode of the current typelist by clicking the
Incoming Categories tab and clicking the typecode. Under it, you see the list of all typelists that reference the
typecode, including the LOB typelists.

LOB typelist Incoming categories from non-LOB typelists

CoverageSubtype LossPartyType

CoverageType CostCategory
CovTermPattern
LineCategory

PolicyType ClaimTier
ExposureTier
InsuranceLine

LossType ClaimantType
ClaimSegment
LossCause
MetroReportType
OfficialType
PriContributingFactors
QuickClaimDefault
ResolutionType
SeverityType

566 chapter 38 Configuring lines of business

 Configuration Guide 9.0.5

Cascading non-LOB typelist references

Non-LOB typelists can reference the non-LOB typelists that reference LOB typelists. These cascading references
can involve more than one level of non-LOB typelists. For example:
• LossType is referenced by PriContributingFactors, which is referenced by SecContributingFactors, which
is referenced by ResContributingFactors.
• LossType is referenced by LossCause, which is referenced by AccidentType.
• PolicyType is referenced by InsuranceLine, which is referenced by both InsuranceSubline and
MajorPerils.
• CoverageSubtype is referenced by LossPartyType, which is referenced by VehicleType.
• CoverageSubtype is referenced by CostCategory, which is referenced by LineCategory.
In these cases, a change to one LOB typelist could require changes to a non-LOB typelist, which in turn requires
changes to another non-LOB typelist.

LOB typelists that reference non-LOB typelists

The following typelists are examples of LOB typelists that reference—have outgoing categories for—non-LOB
typelists:

LOB typelist Outgoing categories to non- LOB typelists

CoverageSubtype SourceSystem

ExposureType Incident

LOBCode SourceSystem

PolicyType InternalPolicyType
PolicyTab
SourceSystem

On the LOB tab, you can see the non-LOB typelists that each typecode references by selecting the typecode and then
opening its Other Categories folder.
See also
• “LOB typelists and incidents” on page 563

Modal PCF files that use LOB typelists

A number of modal PCF files use the LossType and ExposureType typelists. In these PCF files, the detail or list
view that displays is based on the LossType or ExposureType typecode. For example:

Typelist PCF
LossType ClaimEvaluationDetailsDV
ClaimPolicyGeneral
FNOLWizard_AssignSaveScreen
FNOLWizard_BasicInfoScreen
FNOLWizard_NewLossDetailsScreen
FNOLWizard_ServicesScreen
LossDetailsDV
NewClaimLossDetailsDV
NewClaimPolicyGeneralPanelSet
PolicyGeneralPanelSet

LOB typelists referenced by non-LOB typelists 567

 Configuration Guide 9.0.5

Typelist PCF
QuickClaimDV

ExposureType NewClaimExposureDV
ExposureDetailDV
NewExposureDV

Editing LOB typelists and typecodes

To work with lines of business, you navigate in the Project window to configuration→config →Extensions →Typelist and
double-click one of the following typelists:
• LossType.ttx
• LOBCode.ttx
• PolicyType.ttx
• CoverageType.ttx
• CoverageSubtype.ttx
• ExposureType.ttx
You can also search for and open typelists by pressing Ctrl+Shift+N, typing the name of the typelist, and double-
clicking the .ttx version of the typelist in the search results.
Double-clicking an LOB typelist opens the Typelists editor and automatically selects the LOB tab for the tree on the
left side of the editor. This tab of the editor is where you do most of your work on LOB typelists. To work in this
editor, you can click a typecode or typelist node to edit its properties. You can also right-click a node to do things
like adding new typecodes and children of typecodes.
Because the LOB tab shows the current typelist’s typecodes and all the LOB descendants, you can perform most LOB
operations by editing the top-level LOB typelist, LossType. You can view the entire LOB structure by expanding
successive folders of children.
See also
• “LOB typelists” on page 562

LOB typelists editor tabs

When you open an LOB typelist, the tree list has the following tabs at the bottom that show different types of
information and support editing in different ways:
• LOB – A navigable tree of LOB typecodes that shows the relationships to typecodes in the other LOB typelists
and maintains those relationships. This tab shows LOB typecodes with their typelist names, like LOBCode,
PolicyType, and CoverageType. When you select a typecode, its Parents and Children folders show the
hierarchical relationships to typecodes from the LOB typelists. The Other Categories folder shows outgoing
typecode references from this typecode to typecodes in non-LOB typelists.
Note: Use the LOB tab when working with LOB typelists. This tab updates parent and child typecodes as
necessary when you edit existing typecodes.
• Typelist – The current typelist simply as a tree list of the typecodes in the current typelist, along with any other
elements present in the typelist XML files.
• Incoming Categories – Typecodes that reference typecodes in this typelist. This tab is useful for identifying typelists
that refer to typecodes in the current typelist. It includes both LOB and non-LOB typelists.
• Outgoing Categories – Typecodes that are referenced from this typelist. This information is also available under the
LOB and Typelist tabs. However, this view is organized by the typecodes that are being referred to, rather than
by the typecodes in this typelist. This tab is useful for identifying typelists that a typecode references. It includes
both LOB and non-LOB typelists.

568 chapter 38 Configuring lines of business

 Configuration Guide 9.0.5

Note: If you select the LOB tab and navigate to a typecode’s Other Categories folder, you see all the non-LOB
typelists that the typecode references. Because this folder shows only non-LOB outgoing typelist references, it
can be more useful than the Outgoing Categories tab. That tab shows all typelist references, including LOB
typelist references.
• XML – The typelist as XML. This view is read-only.
See also
• “Relationships between LOB typelists and other typelists” on page 566

LOB typelists editor right-click menu

Right-clicking a node in the tree list of the Typelists editor opens a drop-down menu of editing commands specific
to the node. For example, you can right-click an LOBCode typecode and do things like adding a new PolicyType
child or removing the selected typecode from its parent. Or, in that same typelist, you can right-click the root node
of the tree, which represents the typelist itself, and add a new LOBCode typecode to the typelist.
The right-click menu provides the following commands:
• Add new – Add a new typecode, category, or category list.
◦ LOB-typelist-name – Add a typecode of the typelist LOB-typelist-name. You see this command only if you
can add a child to the selected node. The editor displays the appropriate typelist for the node you right-click.
For example, if you are editing the CoverageType typelist and you click the top node in the tree,
CoverageType, you can add a CoverageType typecode to this typelist. In the same tree, if you select any
CoverageType typecode, such as Baggage, you can add a CoverageSubtype typecode as a child.
◦ Category – Add a category to refer to a typecode that is not an LOB typelist child or parent of this typecode.
This command is useful for adding a reference to a non-LOB typelist.
◦ Categorylist – This command associates this typecode with all the typecodes in the specified typelist. It does not
affect the LOB relationships.
• Duplicate – Create a copy of the selected typecode. The copy has a number appended to its code and name that
distinguishes it from the original. This command is not available for the root node, which represents the typelist
itself.
• Remove – This command can cause errors for object that reference the typecode. Guidewire recommends that
instead of removing a typecode, you change its retired property to true. This command is not available for the
root node, which represents the typelist itself.
• Remove from parent – Remove the typecode from its parent. You must be editing the parent typelist or another
typelist higher in the LOB hierarchy, and then navigate from the parent to the child to see this menu command.
• Cut, Copy, Paste – You do not typically use these commands when working with LOB typelists.
• Export Branch – Exports the tree to a CSV file or an HTML file. The currently selected node is the root of the
exported LOB hierarchy tree.
See also
• Category lists in “Dynamic filters” on page 319
• “Adding a child LOB typecode” on page 570
• “Removing an LOB typecode” on page 571
• “Exporting an LOB typecode or typelist” on page 573

Editing an LOB typelist

The top level LOB typelist is LossType.ttx. You can open this typelist to get a top-down view of all the associated
LOB typelists. Typically, you open the typelist you want to work with. For example, if you want to remove a
coverage type from one of its parent policy types, you could open CoverageType.ttx to make the change.
If you want to edit properties of the typelist itself, open that typelist and click the root node, which represents the
typelist. The only practical edit you can make to the properties is to change the desc property.
Editing LOB typelists and typecodes 569
 Configuration Guide 9.0.5

If you right-click the root node, which represents the typelist itself, you can click Add new to add new typecodes to
the typelist.
See also
• For information on opening an LOB typelist for editing, see “Editing LOB typelists and typecodes” on page 568
• “LOB typelists editor right-click menu” on page 569
• “Adding a child LOB typecode” on page 570

Editing an LOB typecode

To edit typecodes of an LOB typelist, open the typelist in the editor and click the LOB tab. You can navigate up and
down the tree in the LOB tab, editing parents and children of the current typecode. Your changes affect all the related
LOB typelists. You can select a typecode and edit its properties, or you can right-click a typecode and add a new
child, a new category, or a new category list.
If you select a typecode in the tree, you see the properties of the typecode on the right, and you can edit them. For
example, you can edit a typecode’s code, name, desc, priority, and retired fields.
• If you edit the name property, Studio updates the typecode name in the tree.
• If you edit the code property, Studio updates any related typecodes in LOB typelists, such as parent and children
typecodes. However, you must manually update any non-LOB typecodes that reference this one or that this one
references.
• If you select retired, the typecode is no longer available in the user interface, nor is it available to new instances of
objects in the ClaimCenter server. However, existing objects, such as existing claims, that already reference the
typecode can continue to do so. Setting this property is almost always preferable to removing the typecode.
See also
• “Editing LOB typelists and typecodes” on page 568

Adding a child LOB typecode

Use the Add new right-click menu command to add a new child typecode to a typecode in a typelist. You can also use
Add new to add a category or category list and to add a typecode to a typelist. This menu command is available for a
typecode only if you can add additional children to it. For example, the parent-child relationship for some typelists is
one-to-one, and if there is already a child, you cannot add another. For ExposureType, no children are supported.
Clicking Add new enables you to add the child typecode appropriate for the selected typecode, such as adding a child
LOBCode to LossType or adding a child CoverageType to PolicyType. For example, if you right-click one of the
LossType typecodes, such as Auto, clicking Add new LOBCode enables you to add a child LOBCode typecode. This
command opens a dialog that you use to select an existing typecode from a typelist or enter values for a new
typecode. In the dialog, click either the New typecode tab to add a new typecode or the Select typecode tab to add an
existing typecode.
If there are existing child elements in the child typelist, the Select typecode tab is available in the dialog. If there are
no more existing child typecodes, the Select typecode tab is disabled. In this case, you must use the New typecode tab to
define a new typecode.
When you add a new child, the editor creates a new typecode in the typelist in the next level down, and it sets up the
parent-child relationship. A new typecode cannot have the same code as an existing typecode in the same typelist.
Studio checks for this condition and prevents you from performing this action in the editor.

570 chapter 38 Configuring lines of business

 Configuration Guide 9.0.5

IMPORTANT As you add LOB typecodes, pay close attention to any errors you might receive. For example, if you
add a new LOBCode typecode to the LOBCode typelist, you see an error saying that the typecode must have at least
one category from typelist PolicyType. If you ignore this error, the ClaimCenter server will not start until you
correct it.

See also
• “Relationships among LOB typelists” on page 563
• “LOB typelists editor right-click menu” on page 569
• “Editing an LOB typelist” on page 569
• “Add a non-LOB typecode” on page 571

Add a non-LOB typecode

About this task
An LOB typecode can reference a typecode in a non-LOB typelist. To add a reference to a non-LOB typecode:

Procedure
1. Open an LOB typelist for editing.
2. Right-click the typecode to which you want to add the reference and choose Add new→Category.
The editor opens the typecode’s Other Categories folder and adds a new node to it named <empty>. You also see
an error. The error will go away after you enter the code and typelist of the new typecode.
3. Click the new <empty> node so you can edit its properties.
4. Enter the typelist and the typecode’s code for the non-LOB typelist. If you begin typing a name in the typelist
field, the list changes to narrow your choices. If you first select the typelist name from the list of typelists, you
can then use the code drop-down list to select the code.
When you set the properties for the non-LOB typelist, the Typelists editor changes the name of the node and
the errors go away.

Next steps
See also
• “Relationships between LOB typelists and other typelists” on page 566
• “Editing LOB typelists and typecodes” on page 568

Adding a parent to an LOB typecode

You can add a parent to an LOB typecode that supports one or more parents by opening the parent typelist and
adding the typecode as a child.
See also
• “Adding a child LOB typecode” on page 570.

Removing an LOB typecode

While the Remove command is available for typecodes in a typelist, Guidewire recommends that you not remove a
typecode. Existing objects that reference the typecode, such as claims, can become invalid as a result. Additionally,
removing a typecode can make typecodes it references into orphans if those typecodes have no other parents.
A circumstance in which you can safely remove a typecode is during development of new typecodes that have not
gone into production. Even in that case, you must clean up all references to the typecode in other typelists, PCF
files, and Gosu code.

Editing LOB typelists and typecodes 571

 Configuration Guide 9.0.5

Instead of removing a typecode, you can retire it or remove it from its parent.
See also
• “Retiring an LOB typecode” on page 572
• “Removing an LOB typecode from its parent” on page 572

Retiring an LOB typecode

If you no longer want to use a typecode, set its retired property to true. When you retire a typecode, it is no
longer used by any PCF files or Gosu code that reference it. Retiring a typecode is the preferred way to cleanly
remove entire policy types, coverages, coverage subtypes, and so on.
See also
• “Editing an LOB typelist” on page 569

Removing an LOB typecode from its parent

You can remove a child LOB typecode from its parent typelist. You typically do so because you want to remove the
functionality the typecode represents from that particular parent typelist. Typically, both the child and the parent
would have multiple children. Removing the typecode from its parent does not remove the typecode itself—it just
removes the reference to the child from the parent.
Note: If you want to actually remove a typecode, retire it.
Use the right-click menu command Remove typecode from parent to remove a typecode from its parent. To see this
menu command, you must first be editing a typelist that is higher in the LOB hierarchy than the typecode you want
to remove from its parent. With the parent typelist or higher level typelist open in the editor, navigate from the
parent LOB typecode to the child typecode. Then, right-click the child typecode.

Remove a typecode from its parent

About this task

Consider this example. You want to remove Arkansas personal injury protection coverage from your business auto
policy type, but not from your personal auto policy type.
Note: This example removes a typecode from one of two parents. For a typecode with only one parent, such as
Bobtail Liability, removing it from its parent would orphan the typecode, leaving it without a parent in the
CoverageType typelist.
You remove the CoverageType typecode PIP - Arkansas, code PAPIP_AR, from its parent PolicyType typecode
Commercial Auto, code BusinessAuto,as follows:

Procedure
1. Navigate to configuration→config→Extensions→Typelist and double-click PolicyType.ttx.
2. In the Typelists editor, navigate to Commercial Auto→Children→PIP - Arkansas.
3. Right-click PIP - Arkansas, and then, in the drop-down menu, click Remove typecode from parent.

Result
The coverage is removed from Business Auto, but remains a coverage for Personal Auto. The coverage type
therefore still has a parent. It also continues to be a typecode in the CoverageType typelist.

572 chapter 38 Configuring lines of business

 Configuration Guide 9.0.5

Next steps
See also
• “Relationships among LOB typelists” on page 563
• “Retiring an LOB typecode” on page 572

Exporting an LOB typecode or typelist

You can right-click a node of an LOB typelist and choose Export Branch to export the current typecode or typelist and
the entire LOB tree below it to a file. You can select whether to export the selected LOB typecode hierarchy as
HTML or as CSV. These two commands, available at all levels, export the tree either to an HTML file or to a CSV
file. Studio exports the tree in a tabular format. You can print the tree or work with it as a spreadsheet, as follows:
• To print the tree, export it to HTML and use a web browser to print it out.
• To use the tree in a spreadsheet editor like Microsoft Excel, export it to CSV.

Localize an LOB typelist

About this task
To see the US English localized LOB typecodes

Procedure
1. Navigate to configuration→config→Localizations→en_US.
2. Double-click typelist.properties.

Next steps
See also
• Globalization Guide

Coverages and policies

After you obtain a policy snapshot or refresh, ClaimCenter transfers coverages from the policy. However, coverages
in a policy are typically more detailed than is needed in ClaimCenter. For example, a policy holder can have several
coverages that apply to property damage. In the base configuration, the snapshot contains only one of these
coverages. However, you can configure it to match your business requirements.
Also, the actual aggregate limit for a coverage can be lower than the policy’s total aggregate limit. Only the
coverage limit of the coverage used applies to the aggregate limit.
The coverages used are typecodes in LOB typelists.

Personal auto coverages and the LOB typelists

This topic uses as an example one set of coverage types in the base configuration. For this example, open the
LossType typelist in the LOB tab of the Typelists editor, click the Auto loss type and then click Children. You can see
elements of the Personal Auto Line line of business when you expand it and its child, the Personal Auto policy type.
The following figure shows the values you see in the first line of the table of coverages.

Editing LOB typelists and typecodes 573

 Configuration Guide 9.0.5

Personal auto coverages in the base configuration

The following table shows the CoverageType, CoverageSubtype, and ExposureType typecodes associated with the
Personal Auto policy type in the ClaimCenter base configuration:

Coverage type Coverage subtype (Children) Exposure type (Children)

Collision (PACollisionCov) Collision (PACollisionCov) Vehicle (VehicleDamage)
Collision - Limited Coverage (PACollision_M Collision - Limited Coverage (PACollision_MA_MI Vehicle (VehicleDamage)
A_MI_Limited) _Limited)

Comprehensive Comprehensive Vehicle (VehicleDamage)

(PAComprehensiveCov) (PAComprehensiveCov)
Death and Disability Benefit Death and Disability Benefit Bodily Injury
(PADeathDisabilityCov) (PADeathDisabilityCov) (BodilyInjuryDamage)
Electronic Equipment Electronic Equipment Vehicle (VehicleDamage)
(PAExcessElectronicsCov) (PAExcessElectronicsCov)
Liability - Bodily Injury and Property Damage Liability - Bodily Injury Bodily Injury
(PALiabilityCov) (PALiabilityCov_bi) (BodilyInjuryDamage)
Liability - PropertyDamage Property
(PALiabilityCov_pd) (PropertyDamage)
Liability - Vehicle Damage Vehicle (VehicleDamage)
(PALiabilityCov_vd)
Medical Payments (PAMedPayCov) Medical Payments (PAMedPayCov) Med Pay (MedPay)
Mexico Coverage - Limited Mexico Cov - BI Bodily Injury
(PALimitedMexicoCov) (PAMexicoCovBI) (BodilyInjuryDamage)
Mexico Cov - Gen. Damages General
(PAMexicoCovGEN) (GeneralDamage)

574 chapter 38 Configuring lines of business

 Configuration Guide 9.0.5

Coverage type Coverage subtype (Children) Exposure type (Children)

Mexico Cov - PD Property
(PAMexicoCovPD) (PropertyDamage)
Mexico Cov - Vehicle Damage Vehicle (VehicleDamage)
(PAMexicoCovVEH)
PIP - Arkansas (PAPIP_AR) PIP - Arkansas (PAPIP_AR) PIP (PIPDamages)
PIP - Delaware (PAPIP_DE) PIP - Delaware (PAPIP_DE) PIP (PIPDamages)
PIP - District of Columbia (PAPIP_DC) PIP - District of Columbia (PAPIP_DC) PIP (PIPDamages)
PIP - Florida (PAPIP_FL) PIP - Florida (PAPIP_FL) PIP (PIPDamages)
PIP - Hawaii (PAPIP_HI) PIP - Hawaii (PAPIP_HI) PIP (PIPDamages)
PIP - Kansas (PAPIP_KS) PIP - Kansas (PAPIP_KS) PIP (PIPDamages)
PIP - Kentucky (PAPIP_KY) PIP - Kentucky (PAPIP_KY) PIP (PIPDamages)
PIP - Maryland (PAPIP_MD) PIP - Maryland (PAPIP_MD) PIP (PIPDamages)
PIP - Massachusetts (PAPIP_MA) PIP - Massachusetts (PAPIP_MA) PIP (PIPDamages)
PIP - Michigan (PAPIP_MI) PIP - Michigan (PAPIP_MI) PIP (PIPDamages)
PIP - Minnesota (PAPIP_MN) PIP - Minnesota (PAPIP_MN) PIP (PIPDamages)
PIP - New Jersey (PAPIP_NJ) PIP - New Jersey (PAPIP_NJ) PIP (PIPDamages)
PIP - New York (PAPIP_NY) PIP - New York (PAPIP_NY) PIP (PIPDamages)
PIP - North Dakota (PAPIP_ND) PIP - North Dakota (PAPIP_ND) PIP (PIPDamages)
PIP - Oregon (PAPIP_OR) PIP - Oregon (PAPIP_OR) PIP (PIPDamages)
PIP - Pennsylvania (PAPIP_PA) PIP - Pennsylvania (PAPIP_PA) PIP (PIPDamages)
PIP - Texas (PAPIP_TX) PIP - Texas (PAPIP_TX) PIP (PIPDamages)
PIP - Utah (PAPIP_UT) PIP - Utah (PAPIP_UT) PIP (PIPDamages)
PIP - Washington (PAPIP_WA) PIP - Washington (PAPIP_WA) PIP (PIPDamages)
Property Protection Insurance Property Protection Insurance Property
(PAPropProtectionCov) (PAPropProtectionCov) (PropertyDamage)
Rental Car Loss of Use Rental Car Loss of Use (PALossOfUseCov) Loss Of Use
(PALossOfUseCov) (LossOfUseDamage)
Rental Reimbursement (PARentalCov) Rental Reimbursement (PARentalCov) Vehicle (VehicleDamage)
Tape / Disc Media Tape / Disc Media (PATapeDiscMediaCov) Personal Property
(PATapeDiscMediaCov) (PersonalPropertyDamage)
Towing and Labor (PATowingLaborCov) Towing and Labor (PATowingLaborCov) Towing and Labor
(TowOnly)
Underinsured Motorist - Underinsured Motorist - Bodily Injury Bodily Injury
Bodily Injury (PAUIMBICov) (PAUIMBICov) (BodilyInjuryDamage)
Underinsured Motorist - Underinsured Motorist - VehicleDamage Vehicle (VehicleDamage)
Property Damage (PAUIMPDCov) (PAUIMPDCov)
Uninsured Motorist - Uninsured Motorist - Bodily Injury Bodily Injury
Bodily Injury (PAUMBICov) (PAUMBICov) (BodilyInjuryDamage)
Uninsured Motorist - Uninsured Motorist - Vehicle (VehicleDamage)

Coverages and policies 575

 Configuration Guide 9.0.5

Coverage type Coverage subtype (Children) Exposure type (Children)

Property Damage (PAUMPDCov) Property Damage (PAUMPDCov)

Add a new LossType typecode

About this task
For each new loss type typecode that you define, you must also do the following tasks in the order shown:

Procedure
1. Add the typecode to LossType typelist.
2. Add an LOBCode child typecode to the new typecode.
3. Update non-LOB typelists that reference LossType typecodes. These typelists include ClaimantType and
LossCause.
4. Create the supporting detail and list views in the ClaimCenter interface.

Next steps
See also
• “LOB typelists referenced by non-LOB typelists” on page 566
• “Editing an LOB typelist” on page 569
• “Adding a child LOB typecode” on page 570

Creating detail views and list views for a new loss type
You define both the detail views and panel sets in individual PCF files. Claim-related and policy-related screens in
ClaimCenter can then reference these files. The PCF files that you need to add are modal. With modal PCF files, the
screen file that references these pages calls the appropriate detail or list view based on the LossType typecode.
It is important that your PCF files follow a naming convention that includes the loss type code in the file name. Use
the following naming convention, replacing Code with the actual typecode:

FileName.Code

You must capitalize the first character of the included typecode. For example, a typecode of Cargo would have the
following corresponding file name:

NewClaimWizardLossDetailsDV.Cargo

Create claim-related PCF files for a new loss type

About this task

For each typecode that you add, create the following claim-related files.

Procedure
1. In the Project window, navigate to configuration→config→Page Configuration→pcf→claim.
2. Open the folder for each file in the following table to add the new file.

Claim folder File Supports

lossdetails LossDetailsDV.Code Editing existing claims

576 chapter 38 Configuring lines of business

 Configuration Guide 9.0.5

Claim folder File Supports

FNOL NewClaimLossDetailsDV.Code New Claim wizard
NewClaimPolicyGeneralPanelSet.Code
QuickClaimDV.Code

planofaction ClaimEvaluationDetailsDV.Code Creating and editing claim evaluations

policy PolicyGeneralPanelSet.Code Policy edits and searches
PolicySummaryGeneralDV.Code

snapshot → default or ClaimSnapshotGeneralversionDV.Code Claim snapshots

snapshot version ClaimSnapshotGeneralversionPanelSet.Code

3. Replace Code with the name of your typecode.

4. Add the new snapshot file to the folder, default. To support previous releases, add new snapshot files to the
version folder specific to the release.

Next steps
See also
• “Relationships among LOB typelists” on page 563
• “Relationships between LOB typelists and other typelists” on page 566
• “Editing LOB typelists and typecodes” on page 568

Adding a new ExposureType typecode

About this task
For each new exposure type that you define, you must do the following tasks in the order shown:

Procedure
1. Add the new typecode to the ExposureType typelist.
2. Add a parent CoverageSubtype to the new ExposureType typecode.
3. Create the supporting detail views in the ClaimCenter interface.

Next steps
See also
• “Editing an LOB typelist” on page 569
• “Adding a child LOB typecode” on page 570

Creating detail views for a new exposure type

You define the detail views in individual PCF files. Claim-related and exposure-related screens in ClaimCenter can
then reference these files. The PCF files that you need to add are modal. With modal PCF files, the screen file that
references these pages calls the appropriate detail view based on the ExposureType typecode.
It is important that your PCF files follow a naming convention that includes the exposure typecode in the file name.
Use the following naming convention, replacing Code with the actual typecode:

FileName.Code

You must capitalize the first character of the included typecode. For example, a typecode of CargoDamage would
have a corresponding file named:

Adding a new ExposureType typecode 577

 Configuration Guide 9.0.5

ExposureDetailDV.Cargodamage

Creating claim-related PCF files for a new exposure type

About this task

For each typecode that you add, create the following claim-related and exposure-related files.

Procedure
1. In the Project window, navigate to configuration→config→Page Configuration→pcf→claim.
2. Open the folder for each file in the following table to add the new file.

Claim folder File Supports

exposures ExposureDetailDV.Code Editing existing exposures
FNOL NewClaimExposureDV.Code New Claim wizard
newexposure NewExposureDV.Code New Exposure wizard
snapshot → default or ClaimSnapshotExposureversionDV.Code Claim snapshots
snapshot → version

3. Replace Code with the name of your typecode.

4. Add the new snapshot file to the folder, default. To support previous releases, add new snapshot files to the
version folder specific to the release.

Next steps
See also
• “LOB typelists” on page 562
• “Relationships among LOB typelists” on page 563
• “Relationships between LOB typelists and other typelists” on page 566
• “Editing LOB typelists and typecodes” on page 568

578 chapter 38 Configuring lines of business

chapter 39

Configuring services

The Services feature in ClaimCenter enables the creation, submission, and management of service requests in
collaboration with selected vendors. ClaimCenter uses a contact management system like ContactManager to access
and select vendors specializing in specific services and a vendor portal like the Guidewire Vendor Portal to
communicate with vendors.
Note: In this topic and included examples, Guidewire ContactManager is used as the default contact management
system, and the Guidewire Vendor Portal is used as the default vendor communication portal. If you use non-
standard components to manage contacts and vendors, please ensure they are integrated appropriately with
Guidewire ClaimCenter before proceeding with adding and managing services.
See also
• Application Guide
• Guidewire Contact Management Guide

How to import and configure services

A service is any action that can be requested from a third-party vendor or internal provider. A service request
summarizes the instruction sent to the vendor detailing the service to be performed. Each service request is
associated with one claim.
ClaimCenter presents vendor information in the form of a vendor directory, from which you can make a selection
based on the type of service required. The services vendor directory is organized in a tree structure, in which folder
nodes represent service categories and leaf nodes represent specialized services. The services performed by a
specialist vendor can be configured in Guidewire Contact Manager.
Note: Guidewire recommends that you install Guidewire Contact Manager and integrate it with Guidewire
ClaimCenter before importing services information.

Vendor service tree

You define vendor services in the vendorservicetree.xml data file and then import this file to create a vendor
service tree in both ClaimCenter and Contact Manager. You must integrate these two applications and maintain

Configuring services 579

 Configuration Guide 9.0.5

identical service trees in both applications. Use the data import feature in both ClaimCenter and Contact Manager to
load the same, customized service tree XML file.
The following diagram shows the structure of the vendor service tree:

Service
Category
Service
Subcategory
Service

Service

Service

Service

At the topmost level of the tree, the folder nodes represent either service categories or services. Under service
categories, you can define service subcategories or services. The leaf nodes of the tree represent the specialized
services grouped into each category.
The format of the vendorservicetree.xml file needs to conform to a corresponding structure. The following
example file defines Auto and Property categories, along with subcategories and services.

<?xml version="1.0"?>
<import>
<SpecialistService public-id="svc:aut">
<Active>true</Active>
<Code>auto</Code>
<Description>Auto</Description>
<Description_L10N_ARRAY/>
<Name>Auto</Name>
<Name_L10N_ARRAY/>
<Parent/>
</SpecialistService>
<SpecialistService public-id="svc:aut_ins">
<Active>true</Active>
<Code>autoinsprepair</Code>
<Description>Auto - Inspection / Repair</Description>
<Description_L10N_ARRAY/>
<Name>Inspection / Repair</Name>
<Name_L10N_ARRAY/>
<Parent public-id="svc:aut"/>
</SpecialistService>
<SpecialistService public-id="svc:aut_ins_aud">
<Active>true</Active>
<Code>autoinsprepairaudio</Code>
<Description>Auto - Inspection / Repair - Audio equipment</Description>
<Description_L10N_ARRAY/>
<Name>Audio equipment</Name>
<Name_L10N_ARRAY/>
<Parent public-id="svc:aut_ins"/>
</SpecialistService>
<SpecialistService public-id="svc:aut_ins_bod">
<Active>true</Active>
<Code>autoinsprepairbody</Code>
<Description>Auto - Inspection / Repair - Auto body</Description>
<Description_L10N_ARRAY/>
<Name>Auto body</Name>
<Name_L10N_ARRAY/>
<Parent public-id="svc:aut_ins"/>
</SpecialistService>

580 chapter 39 Configuring services

 Configuration Guide 9.0.5

<SpecialistService public-id="svc:pro">
<Active>true</Active>
<Code>prop</Code>
<Description>Property</Description>
<Description_L10N_ARRAY/>
<Name>Property</Name>
<Name_L10N_ARRAY/>
<Parent/>
</SpecialistService>
<SpecialistService public-id="svc:pro_ins">
<Active>true</Active>
<Code>propinspect</Code>
<Description>Property - Inspection</Description>
<Description_L10N_ARRAY/>
<Name>Inspection</Name>
<Name_L10N_ARRAY/>
<Parent public-id="svc:pro"/>
</SpecialistService>
<SpecialistService public-id="svc:pro_ins_ind">
<Active>true</Active>
<Code>propinspectindependent</Code>
<Description>Property - Inspection - Independent appraisal</Description>
<Description_L10N_ARRAY/>
<Name>Independent appraisal</Name>
<Name_L10N_ARRAY/>
<Parent public-id="svc:pro_ins"/>
</SpecialistService>
<SpecialistService public-id="svc:pro_con">
<Active>true</Active>
<Code>propconstrserv</Code>
<Description>Property - Construction services</Description>
<Description_L10N_ARRAY/>
<Name>Construction services</Name>
<Name_L10N_ARRAY/>
<Parent public-id="svc:pro"/>
</SpecialistService>
<SpecialistService public-id="svc:pro_con_gen">
<Active>true</Active>
<Code>propconstrservgencontractor</Code>
<Description>Property - Construction services - General contractor</Description>
<Description_L10N_ARRAY/>
<Name>General contractor</Name>
<Name_L10N_ARRAY/>
<Parent public-id="svc:pro_con"/>
</SpecialistService>
<SpecialistService public-id="svc:pro_con_car">
<Active>true</Active>
<Code>propconstrservcarpentry</Code>
<Description>Property - Construction services - Carpentry</Description>
<Description_L10N_ARRAY/>
<Name>Carpentry</Name>
<Name_L10N_ARRAY/>
<Parent public-id="svc:pro_con"/>
</SpecialistService>
</import>

In this example, Auto is defined as a service category, Inspection/Repair is a subcategory, and Autobody a service type.
The services that can be performed by a vendor are configured in Guidewire ContactManager.
This vendor service tree example defines the following services:

Category Subcategory Service Type

Auto Inspection/Repair Audio equipment
Auto body
Property Inspection Independent appraisal
Construction General contractor
services
Carpentry

How to import and configure services 581

 Configuration Guide 9.0.5

Using this structure, you can customize the vendor service hierarchy as needed, based on your business needs. When
customizing the service tree, note the following:
• In the base configuration, services are organized into categories, subcategories, and service types in the user
interface. You can alter the names used in the application screens as well as the depth of the tree, which only has
three levels in the base configuration.
Note: If you change the depth of the vendor services tree, you must do so for both ClaimCenter and
ContactManager. Additionally, you must update PCF files in both applications to show additional columns to
match any new levels you add to the hierarchy.
• A leaf node can appear anywhere in the tree hierarchy, but each leaf node can have only one parent node. If a leaf
node must be associated with more than one parent node, duplicate it so that it has, at most, one parent in each
occurrence.
• The Code values in the vendor service tree used by the base ClaimCenter configuration are referenced in the
following class:
gw.vendormanagement.SpecialistServiceCodeConstants
Note: When you configure the vendor service tree, ensure that all Code values referenced from constants in this
class are present in your tree. If you remove constants from this class, search for and clean up references to those
constants from the base configuration to avoid compilation errors. As a best practice, if Gosu code or PCF files in
your configuration reference particular services in your tree, add and use the appropriate constants in this class.
See also
• “How to configure the depth of the service hierarchy” on page 586

Vendor service details

In addition to the vendor service tree XML file, you need a second data file, vendorservicedetails.xml, for
ClaimCenter. The vendor service details file associates each service with a compatible incident type and service
request type.
Unlike vendorservicetree.xml, the service details XML file is imported only into ClaimCenter. It contains
instances of entities that exist only in ClaimCenter, not ContactManager.
The vendorservicedetails.xml file must conform to a format like the example below:

<?xml version="1.0"?>
<import>
<SpecialistServiceCompatibleServiceRequestKind public-id="cc:23">
<Kind>quoteonly</Kind>
<Service public-id="svc:pro_ins_ind"/>
</SpecialistServiceCompatibleServiceRequestKind>
<SpecialistServiceCompatibleServiceRequestKind public-id="cc:29">
<Kind>quoteandservice</Kind>
<Service public-id="svc:aut_ins_bod"/>
</SpecialistServiceCompatibleServiceRequestKind>
<SpecialistServiceCompatibleServiceRequestKind public-id="cc:30">
<Kind>quoteonly</Kind>
<Service public-id="svc:aut_ins_bod"/>
</SpecialistServiceCompatibleServiceRequestKind>
<SpecialistServiceCompatibleServiceRequestKind public-id="cc:31">
<Kind>unmanaged</Kind>
<Service public-id="svc:aut_ins_bod"/>
</SpecialistServiceCompatibleServiceRequestKind>
<SpecialistServiceCompatibleServiceRequestKind public-id="cc:36">
<Kind>quoteandservice</Kind>
<Service public-id="svc:aut_ins_aud"/>
</SpecialistServiceCompatibleServiceRequestKind>
<SpecialistServiceCompatibleServiceRequestKind public-id="cc:37">
<Kind>quoteonly</Kind>
<Service public-id="svc:aut_ins_aud"/>
</SpecialistServiceCompatibleServiceRequestKind>
<SpecialistServiceCompatibleServiceRequestKind public-id="cc:75">
<Kind>quoteandservice</Kind>
<Service public-id="svc:pro_con_gen"/>
</SpecialistServiceCompatibleServiceRequestKind>
<SpecialistServiceCompatibleServiceRequestKind public-id="cc:76">

582 chapter 39 Configuring services

 Configuration Guide 9.0.5

<Kind>quoteonly</Kind>
<Service public-id="svc:pro_con_gen"/>
</SpecialistServiceCompatibleServiceRequestKind>
<SpecialistServiceCompatibleServiceRequestKind public-id="cc:77">
<Kind>quoteandservice</Kind>
<Service public-id="svc:pro_con_car"/>
</SpecialistServiceCompatibleServiceRequestKind>
<SpecialistServiceCompatibleServiceRequestKind public-id="cc:78">
<Kind>quoteonly</Kind>
<Service public-id="svc:pro_con_car"/>
</SpecialistServiceCompatibleServiceRequestKind>
<SpecialistServiceCompatibleIncidentType public-id="cc:1">
<IncidentType>Incident</IncidentType>
<Service public-id="svc:aut"/>
</SpecialistServiceCompatibleIncidentType>
<SpecialistServiceCompatibleIncidentType public-id="cc:2">
<IncidentType>Incident</IncidentType>
<Service public-id="svc:pro"/>
</SpecialistServiceCompatibleIncidentType>
<SpecialistServiceCompatibleIncidentType public-id="cc:8">
<IncidentType>MobilePropertyIncident</IncidentType>
<Service public-id="svc:aut"/>
</SpecialistServiceCompatibleIncidentType>
<SpecialistServiceCompatibleIncidentType public-id="cc:10">
<IncidentType>VehicleIncident</IncidentType>
<Service public-id="svc:aut"/>
</SpecialistServiceCompatibleIncidentType>
<SpecialistServiceCompatibleIncidentType public-id="cc:12">
<IncidentType>FixedPropertyIncident</IncidentType>
<Service public-id="svc:pro"/>
</SpecialistServiceCompatibleIncidentType>
<SpecialistServiceCompatibleIncidentType public-id="cc:15">
<IncidentType>PropertyIncident</IncidentType>
<Service public-id="svc:aut"/>
</SpecialistServiceCompatibleIncidentType>
<SpecialistServiceCompatibleIncidentType public-id="cc:16">
<IncidentType>PropertyIncident</IncidentType>
<Service public-id="svc:pro"/>
</SpecialistServiceCompatibleIncidentType>
<SpecialistServiceCompatibleIncidentType public-id="cc:20">
<IncidentType>OtherStructureIncident</IncidentType>
<Service public-id="svc:pro"/>
</SpecialistServiceCompatibleIncidentType>
<SpecialistServiceCompatibleIncidentType public-id="cc:23">
<IncidentType>DwellingIncident</IncidentType>
<Service public-id="svc:pro"/>
</SpecialistServiceCompatibleIncidentType>
</import>

The Service public-id value in this file must be set to the SpecialistService public-id from the vendor
service tree file. For example, an InjuryIncident type can be mapped to an Auto service and a quoteandservice
request type.
When customizing the vendorservicedetails, the following constraints apply:
• Every root SpecialistService (a service without a parent) must have at least one linked compatible incident
type.
• Every leaf SpecialistService (a service without any children) must have at least one linked compatible
ServiceRequestKind.

How to import a service

You import services into ClaimCenter by using two predefined XML files:
• Vendor Service Tree (vendorservicetree.xml) – Lists the services by category. This file is used by both
ClaimCenter and ContactManager.
• Vendor Service Details (vendorservicedetails.xml) – Associates services with incidents and service request
types. This data file is only used in ClaimCenter.
In the base configuration, Guidewire provides samples of these files in the config/sampledata directory.

How to import and configure services 583

 Configuration Guide 9.0.5

Add a service

Before you begin

IMPORTANT Use must use the same vendorservicetree.xml file for both ClaimCenter and ContactManager, to
ensure that both applications have identical vendor service directories.

About this task

Use the following steps to add services:

Procedure
1. Customize the sample XML files to tailor them to your business requirements.
2. Import the vendorservicetree.xml file into ClaimCenter and ContactManager by using the Administration tab.
3. Import the vendorservicedetails.xml file only into ClaimCenter by using the Administration tab.
4. After data load completes, run the database consistency checks.

Next steps
See also
• Guidewire Contact Management Guide
• Installation Guide
• System Administration Guide

How to edit a service

After the Services XML data is imported into the Guidewire applications, you cannot edit it by using the application
user interface. Instead, edit the corresponding XML file, as needed, and import it back into ClaimCenter and
ContactManager.
Note: It is recommended that you always choose to overwrite changes during import, so the service tree in your
database exactly matches the imported XML file.

How to delete a service

You cannot delete a service from the vendor service tree, after it is created in the XML file. However, you can mark
a service as inactive and import the tree back into the applications. The service is then no longer available in the
application user interface.
In the following example, the Auto - Adjudicate claim service is disabled.

<SpecialistService public-id="svc:aut_adj">
<Active>false</Active>
<Code>autoadjudicate</Code>
<Description>Auto - Adjudicate claim</Description>
<Description_L10N_ARRAY/>
<Name>Adjudicate claim</Name>
<Name_L10N_ARRAY/>
<Parent public-id="svc:aut"/>
</SpecialistService>

How to localize services

You can extend the SpecialistService entity with localization elements, depending on the user’s preferred
language needs.

584 chapter 39 Configuring services

 Configuration Guide 9.0.5

How to specify localized languages for a SpecialistService instance

You can use <Description_L10N_ARRAY> elements with a SpecialistService entity if you require that the service
have a different name or description depending on the user's preferred language.
Note: You do not provide a language for the <Code> element because it is used only in code and is not visible to
the user.
The following XML definition for the Auto category provides Spanish and German alternatives for the Name and
Description fields, which appear by default in United States English.

<SpecialistService public-id="auto_svc:1">
<Code>auto</Code>
<Description>Auto</Description>
<Description_L10N_ARRAY>
<SpecialistService_Description_L10N public-id="svc_trans:1">
<Language>es_ES</Language>
<Owner public-id="auto_svc:1"/>
<Value>Automotor</Value>
</SpecialistService_Description_L10N>
<SpecialistService_Description_L10N public-id="svc_trans:2">
<Language>de_DE</Language>
<Owner public-id="auto_svc:1"/>
<Value>Kraftfahrt</Value>
</SpecialistService_Description_L10N>
</Description_L10N_ARRAY>
<Name>Auto</Name>
<Name_L10N_ARRAY>
<SpecialistService_Name_L10N public-id="svc_trans:1">
<Language>es_ES</Language>
<Owner public-id="auto_svc:1" />
<Value>Automotor</Value>
</SpecialistService_Name_L10N>
<SpecialistService_Name_L10N public-id="svc_trans:2">
<Language>de_DE</Language>
<Owner public-id="auto_svc:1" />
<Value>Kraftfahrt</Value>
</SpecialistService_Name_L10N>
</Name_L10N_ARRAY>
</SpecialistService>

When the application opens, all display fields are in English. If the user chooses German as the language, the display
switches to German.
The three types of entities with public IDs that are defined in the example are SpecialistService,
SpecialistService_Description_L10N, and SpecialistService_Name_L10N. Each instance of each type of
entity must have a public-id value that is unique for that entity in the entire file. If any public ID matches that of
the corresponding entity type that is already in the database, the entity in the database is overwritten by the values in
the file.
More specifically:
• Each SpecialistService must have a public ID that is unique for all SpecialistService definitions.
• The example defines only two arrays of translated values, Description_L10N_ARRAY and Name_L10N_ARRAY.
However, in a real specialist service definition, there would be multiple L10N array definitions, a
Description_L10N_ARRAY and Name_L10N_ARRAY for each service. Inside these array definitions:
◦ Each SpecialistService_Description_L10N definition must have a public ID that is unique for all
SpecialistService_Description_L10N definitions across the entire file.
◦ Each SpecialistService_Name_L10N definition must have a public ID that is unique for all
SpecialistService_Name_L10N definitions across the entire file.
Additionally, in its Owner element, each L10N entity must refer to the public ID of the SpecialistService entity
containing it, which is the entity that the L10N entity translates. In the previous example, the Owner element of each
L10N entity is set to auto_svc:1, which is the public-id of the Auto SpecialistService entity.

How to localize services 585

 Configuration Guide 9.0.5

See also
• Globalization Guide

How to configure the depth of the service hierarchy

In the base configurations of ClaimCenter and ContactManager, the service hierarchy has up to three levels, called
Category, Subcategory, and Service Type in application screens. These levels result from the way services are
declared in vendorservicetree.xml. The names used for these levels are not part of the vendorservicetree.xml
definition, but are defined as columns in the PCF files that display the tree of services.
You can define additional levels of services in vendorservicetree.xml. For any services that you add to
ClaimCenter, you must also configure the kind of services you add in vendorservicedetails.xml.
If you add a level, you must also configure an additional column for each level in the PCF files used in ClaimCenter
and ContactManager to display the service hierarchy. This topic describes how to add one additional level to the
service hierarchy, a Service Subtype. This change requires that you configure both ClaimCenter and
ContactManager.
In the following examples, two service subtype definitions are added to the service type Audio equipment:
• Audio equipment - new
• Audio equipment - used.
The result is a fourth level to the service tree. The following table represents the new hierarchy:

Category Subcategory Service Type Service Subtype

Auto Inspection/Repair Audio equipment Audio equipment - new
Audio equipment - used

ClaimCenter is to display the two new services as Quote and Perform Service types supporting the complete service
request lifecycle—obtain quotes, request service, and make payments. Therefore they are defined in
vendorservicedetails.xml as <Kind>quoteandservice</Kind>.
Additionally, you must add a column for the new service subtype to two PCF files in ClaimCenter and one PCF file
in ContactManager.
See also
• For the sample vendor service tree extended in this topic, see “Vendor service tree” on page 579.
• For the sample vendor service details extended in this topic, see “Vendor service details” on page 582.

Add a service subtype to ClaimCenter

Procedure
1. In ClaimCenter Studio, navigate in the Project window to configuration→config→sampledata, and then double-
click vendorservicetree.xml to open it in the editor.
2. Add the two new service definitions after the definition for the service named Audio equipment:

...
<SpecialistService public-id="svc:aut_ins_aud">
<Active>true</Active>
<Code>autoinsprepairaudio</Code>
<Description>Auto - Inspection / Repair - Audio equipment</Description>
<Description_L10N_ARRAY/>
<Name>Audio equipment</Name>
<Name_L10N_ARRAY/>
<Parent public-id="svc:aut_ins"/>
</SpecialistService>
<SpecialistService public-id="svc:aut_ins_aud_n">
<Active>true</Active>
<Code>autoinsprepairaudionew</Code>

586 chapter 39 Configuring services

 Configuration Guide 9.0.5

<Description>Auto - Inspection / Repair - Audio equipment - Purchase new

</Description>
<Description_L10N_ARRAY/>
<Name>Audio equipment - new</Name>
<Name_L10N_ARRAY/>
<Parent public-id="svc:aut_ins_aud"/>
</SpecialistService>
<SpecialistService public-id="svc:aut_ins_aud_u">
<Active>true</Active>
<Code>autoinsprepairaudioused</Code>
<Description>Auto - Inspection / Repair - Audio equipment - Replace used
</Description>
<Description_L10N_ARRAY/>
<Name>Audio equipment - used</Name>
<Name_L10N_ARRAY/>
<Parent public-id="svc:aut_ins_aud"/>
</SpecialistService>
...

3. Navigate in the Project window to configuration→config→sampledata, and then double-click

vendorservicedetails.xml to open it in the editor.
4. Add the following quote and service entries for the new services:

...
<SpecialistServiceCompatibleServiceRequestKind public-id="cc:81">
<Kind>quoteandservice</Kind>
<Service public-id="svc:aut_ins_aud_n"/>
</SpecialistServiceCompatibleServiceRequestKind>
<SpecialistServiceCompatibleServiceRequestKind public-id="cc:82">
<Kind>quoteandservice</Kind>
<Service public-id="svc:aut_ins_aud_u"/>
</SpecialistServiceCompatibleServiceRequestKind>
...

Note: Each public-id value must be unique. If you have previously added other entries to this file, you
might have to use different values for public-id than the ones used in the sample code.
5. Import vendorservicetree.xml and vendorservicedetails.xml into ClaimCenter by logging in and then
navigating to Administration→Utilities→Import.
6. In ClaimCenter Studio, in the Project window, navigate to configuration→config→Page
Configuration→pcf→claim→servicerequests and double-click InstructionServicesLV_default to open it in
the editor.
7. In the RowIterator widget named InstructionServicesIterator, add a new column to display the
additional level in the service tree:
a. Copy the cell under the label Service Type, which has the value
instructionService.getEditHelper(2).Value.
b. Paste this cell to the right of the Service Type column.
This new cell will become the Service Subtype column. The error indicators will go away when you make
the next changes.
c. Click the new cell and change the id property to:

InstructionServiceType3

d. Change the value property to:

instructionService.getEditHelper(3).Value

e. In that same cell, select the value of label property, which is a display key.
f. Right-click and choose GoTo→Declaration.
In the base configuration, the display.properties file in Localizations en_US opens and has a tab named
Localizations.

How to configure the depth of the service hierarchy 587

 Configuration Guide 9.0.5

g. Add the following new display key to the file that opens:

Web.ServiceRequest.ServiceToPerform.ServiceSubType_Ext = Service Subtype

h. In the InstructionServicesLV_default PCF file, in the new cell, enter this new display key as the
value for the label property:

displaykey.Web.ServiceRequest.ServiceToPerform.ServiceSubType_Ext

8. In Guidewire Studio, in the Project window, navigate to configuration→config→Page

Configuration→pcf→addressbook and double-click AddressBookSearchDV to open it in the editor.
9. Scroll down to the ListViewInput named Services.
10. In the RowIterator widget named InstructionServicesIterator, add a new column to display the
additional level in the service tree, as follows:
a. Copy the cell under the label Service Type, which shows the value service.getEditHelper(2).Value.
b. Paste this cell to the right of the Service Type column.
This new cell will become the Service Subtype column. The error indicators goes away after you make the
next changes.
c. Click the new cell to select it, and then change the id property to:

ServiceType3

d. Change the value property to:

service.getEditHelper(3).Value

e. In that same cell, change the value of label property to the following display key:

displaykey.Web.ServiceRequest.ServiceToPerform.ServiceSubType_Ext

11. Restart ClaimCenter so that it will pick up these changes.

Add a service subtype to ContactManager

About this task

IMPORTANT This series of steps changes the Audioequipment service from a service type into an intermediate node
in the tree, a parent node of the Service Subtype node. If you previously assigned the Audioequipment service to any
contacts, importing vendorservicetree.xml will cause errors that you need to correct.

Procedure
1. Log in to ContactManager and navigate to Administration→Utilities→Import.
2. Import the copy of vendorservicetree.xml that you modified in the previous series of steps.
3. In ContactManager Studio, in the Project window, navigate to
configuration→config→Page→Configuration→pcf→contacts. Then double-click VendorServicesLV to open it in
the editor.
4. In the RowIterator widget, add a new column to display the additional level in the service tree, as follows:
a. Copy the cell under the label Service Type, which has the value serviceRow.getServiceNamePart(2).
b. Paste this cell to the right of the Service Type column.
This new cell will become the Service Subtype column. The error indicators will go away when you make
the next changes.

588 chapter 39 Configuring services

 Configuration Guide 9.0.5

c. Click the new cell to select it, and then change the id property to:

ServiceNameCell3

d. Change the value property to:

serviceRow.getServiceNamePart(3)

e. In that same cell, select the value of label property, which is a display key.
f. Right-click and choose GoTo→Declaration.
In the base configuration of ContactManager, the display.properties file in Localizations en_US opens
with a tab named Localizations.
g. Add the following new display key to the file that opens:

Web.ContactDetail.Services.ServiceSubtype_Ext = Service Subtype

h. In the PCF file, click the new cell, and then enter this new display key as the value for the label property,
as follows:

displaykey.Web.ContactDetail.Services.ServiceSubtype_Ext

5. Restart ContactManager so it will pick up these changes.

Next steps
See also
• Guidewire Contact Management Guide

Service request data model

The following object model diagram describes key entities relating to ServiceRequest. For complete information,
see the Data Dictionary.

Service request data model 589

 Configuration Guide 9.0.5

Service Request Data Model

DocumentLinks
ServiceRequestMetric Exposure Claim
0..*
ServiceRequest
ServiceRequestChange ServiceRequestDocumentLink
0..*
1 1 ServiceRequest ServiceRequest
Service Request Sequence Document
Metrics Timestamp VisibleToSpecialist
ServiceRequestMessage History Description DateSpecialistNotified
Initiator StatementDocumentLinks
SentFromPortal Messages 1..*
RelatedStatement 0..* 0..*
0..*
1 1 0..* 0..* 1 1 0..*
Service Request
Document
ServiceRequest Document Links
<<join>>
LatestQuote
Related
Quotes 1
ServiceRequestInstruction Statement
DocumentLinks
Document
Services InstructionHistory/ ServiceRequestNumber
1..* Instruction 1 Specialist ServiceRequestDocumentLinks
ServiceRequest
InstructionText Progress 0..1 0..*
CustomerContact QuoteStatus ServiceRequestStatement
ServiceAddress InstructionHistory
Notes ServiceRequest ServiceRequest
1 Activities StatementDocumentLinks StatementLineItem
Service
1 0..*
ReferenceNumber
<<join>> Activity 0..* 0..1 OriginatingServiceRequest Description
Invoices ApprovalDate Category
1..*
Kind ApprovedBy Amount
SpecialistService 0..1 Messages StatementCreationTime
ReferenceNumber DeclinedReason
Name
Description
History Check
0..*
Code 0..* 1 1 ServiceRequestInvoice
Note
CompatibleIncidentTypes
CompatibleKinds Quotes/
LatestQuote
0..1
1 ServiceRequestInvoice
ServiceRequestQuote
Contact Status Check
Legend
<<vendor>> ExpectedDaysToPerform PaidBy
A
0..n
B A has 0 or more Bs 0..* Service Check
PaymentDate
A B A is a subtype of B 0..*
Invoices 0..*

The following table describes the key entities.

Entity Description
ServiceRequest The core service request entity.
ServiceRequestInstruction All instructions that have been created for this service request, including those that are no
longer active. The ServiceRequest entity points to the latest instruction.
ServiceRequestStatement An estimation, such as a quote or invoice, received from a vendor.
ServiceRequestQuote Quotes received from a vendor for the service request. The ServiceRequest entity points to
the latest version of the quote. ServiceRequest has an array of quotes only to keep a record
of past quotes. ServiceRequest.LatestQuote is the only one considered to be in effect at a
given time. This means the current quote is always expected to cover all the activity included
in the service request.
ServiceRequestInvoice Invoices associated with the service request.
ServiceRequestDocumentLink Associates the service request to a document.

ServiceRequestChange All changes that have been applied to this service request. These make up its history.
SpecialistService A node, signifying a service type, in the vendor service tree.
ServiceRequestMetric Metrics related to the service request.
ServiceRequestMessage Messages for the service request.

590 chapter 39 Configuring services

 Configuration Guide 9.0.5

Lifecycle of a service request

Service requests can follow different paths in their progress to completion, based on the applicable state handler.
State handlers are subclasses of ServiceRequestStateHandler, and they define the state transitions allowed for a
service request. The state handler that applies to a ServiceRequest can be obtained by calling the method,
ServiceRequest.createStateHandler. In the base configuration, this method is implemented as a simple mapping
between request types, modeled with ServiceRequest.Kind, and state handler implementation classes. Each state
handler defines a set of operations and the availability and meanings of those operations. Because there is at most
one active quote on a ServiceRequest, the quote status is stored on the ServiceRequest itself. The quote status,
along with ServiceRequest.Progress, largely determine the state of a service request in its lifecycle.
The following state diagrams illustrate the lifecycle of the four basic service request types.

Quote only
The following diagram displays the various stages in the lifecycle of a quote-only service request.

Quote

(Adjuster)
No Quote
Create service request
Draft

(Adjuster)
Submit request
No Quote Waiting for Quote
(Vendor)
Decline work
Declined Requested

(Vendor)
Waiting for Quote Accept work
(Vendor)
Cancel work
In Progress (Vendor)
Add quote

(Adjuster) (Vendor)
Request requote Add quote
(Vendor) Legend

Revise quote Service Request State

Quoted
Quote Status
Work Complete
Action

Note: The service request state names are derived from the ServiceRequestProgress typelist.

Quote and perform service

The following diagram displays the various stages in the lifecycle of a quote and perform service request.

Lifecycle of a service request 591

 Configuration Guide 9.0.5

Quote and Perform Service

Legend
(Adjuster) Service Request State
No Quote
Create Service Request
Draft Quote Status

Action

No Quote Waiting for Quote (Adjuster)

(Vendor) Submit request (Vendor)
Decline work Add quote
Declined Requested

(Vendor)
Waiting for Quote/ Accept work
Approved Waiting for Approval
(Vendor)
(Vendor) Add quote
Cancel work
In Progress Vendor Waiting
(Adjuster)
Approve quote

(Adjuster)
Approved (Vendor) Request requote
(Vendor) (Adjuster)
Revise quote
Finish the work Waiting for Approval/
Approve invoice
Vendor Waiting Approved
Approved

Work Complete Work Complete

(Vendor) (Adjuster)
(Vendor) Pause work Add invoice Pay invoice

(Vendor) Resume work

Waiting for the Vendor

The VendorWaiting state is used to signify a period of inactivity on the part of the vendor, while some action or
response is awaited. It corresponds to the specialistwaiting typekey in the ServiceRequestProgress typelist.
The VendorWaiting state is typically used in two scenarios:
• If the vendor has submitted a quote and is waiting for approval to begin work on the service request. The
ServiceRequestQuoteStatus in this case is usually waitingforapproval.
• If the vendor has begun work on the service request and is awaiting a part or some response from the insured to
proceed. This state can be applied to both quote-only and quote-and-service request types. The
ServiceRequestQuoteStatus in this case is usually approved.

Service only
The following diagram displays the various stages in the lifecycle of a service-only request.

592 chapter 39 Configuring services

 Configuration Guide 9.0.5

Service Only

(Adjuster)
Create service request
Draft

(Adjuster)
Submit request
(Vendor)
Decline work
Declined Requested

(Vendor)
Agree to perform service
(Vendor)
Cancel work
In Progress Vendor Waiting
(Vendor)
Resume work

(Vendor) (Adjuster)
Finish the work Approve invoice

Legend

Service Request State Work Complete Work Complete

(Vendor) (Adjuster)
Add invoice Pay invoice
Action

Unmanaged service
Unmanaged services are specialized service request types created only as part of the Auto First and Final wizard.
This service request type does not have associated quotes, and you can directly proceed to add invoices and make
payments once the wizard is complete.
The following diagram illustrates the lifecycle of an unmanaged service request.

Lifecycle of a service request 593

 Configuration Guide 9.0.5

Unmanaged Service

(Adjuster)
Create Service Request

Work Complete

(Vendor)
Add invoice

Waiting for Approval/

Approved (Adjuster)
Approve invoice
Work Complete

(Adjuster)
Pay invoice
Legend

Service Request State

Invoice Status

Action

How to configure service requests

There are multiple ways in which you can configure service requests.

How to create service requests dynamically

You can create a new service request in multiple ways in ClaimCenter screens:
• In the New Claim wizard, as part of the FNOL process.
• Using the Actions menu.
You can also generate a service request dynamically in Gosu for predetermined incidents. This can be done using,
for example, the ClaimCenter rule set or the ServiceRequestAPI.

Example – Create a service request in a Gosu rule

About this task

In the following example, you create a new ClaimPostSetup rule, which will generate service requests for certain
predetermined incidents on newly created claims. In this case, only Vehicle Incidents on Auto claims qualify.

Procedure
1. Start Guidewire Studio.
2. Navigate to configuration→config→Rule Sets→Postsetup→ClaimPostsetup.
3. Right-click ClaimPost-setup and click NewRule.

594 chapter 39 Configuring services

 Configuration Guide 9.0.5

4. In the Rulename field, enter a name for the new rule, such as CPS02000 - Add Service Request for Vehicle
Incident.
5. Add the following rule:

CONDITION(claim : entity.Claim):
return claim.LossType == TC_AUTO
and claim.VehicleIncidentsOnly.HasElements

ACTION(claim : entity.Claim, actions : gw.rules.Action):

// Create a new service request for a newly submitted auto claim with one or more vehicle incidents.
for (incident in claim.VehicleIncidentsOnly) {
var serviceRequest = incident.Claim.newServiceRequest(incident.Claim.maincontact, incident)
serviceRequest.Instruction.addServiceFoundByCode(SpecialistServiceCodeConstants.AUTOBODYREPAIR)
serviceRequest.Kind = ServiceRequestKind.TC_QUOTEANDSERVICE
// Specify the vendor. In practice, this contact would be retrieved from the address book.
serviceRequest.Specialist = new CompanyVendorBuilder().withCompanyName("Anya’s Auto Repair").create()
serviceRequest.finishSetup()
}

6. Save your changes.

7. Start the application server.
8. Log in to ClaimCenter and create a new Personal Auto claim with one or more vehicle incidents.

Result
Whenever you click Submit to submit the claim, ClaimCenter now shows the corresponding service requests
automatically, as seen in the example below.

Next steps
See also
• Application Guide

How to manage changes to service requests

When a service request is modified, the ServiceRequest.recordChange method is used to record and manage the
change in the service request history. This method creates an instance of the ServiceRequestChange entity, which
represents a change to a service request. For a given ServiceRequest, instances of this entity are ordered by their
Sequence value. The ServiceRequestChange entity preserves the history of changes to a service request.
Subsequently, metrics are calculated based on this history.

How to configure service requests 595

 Configuration Guide 9.0.5

In the base configuration, two versions of the recordChange method are included, as follows:
• public ServiceRequestChange recordChange(String description, ServiceRequestOperation
operation, ServiceRequestStatement statement, Contact initiator)
• public void recordChange(ServiceRequestChange newChange)
Only the first version, which returns a ServiceRequestChange object, is used in the base configuration. This
version of the method takes a description of the change, an optional reference to a ServiceRequestStatement, and
a Contact, typically the initiator of the change. It then creates a ServiceRequestChange object, capturing changes
to some ServiceRequest fields automatically.
The value for a ServiceRequest field is captured and stored on ServiceRequestChange. The following conditions
must be met in the data model:
• The ServiceRequestChange entity contains fields with the same names as the ServiceRequest entity, but with
additional prefixes (New_) or suffixes (_Chg).
• A New_ field is nullable and has the same type as the corresponding ServiceRequest field.
• A _Chg field is not nullable and is of the type, bit.
The first version of recordChange determines whether the value of the field on ServiceRequest has changed since
the last time recordChange was called. It determines this by stepping backwards through ServiceRequestChange
objects using the Sequence field to determine order. It then stores the result, true if the value has changed, false
otherwise, in the _Chg field on the new ServiceRequestChange object it creates. If the value has changed, it then
stores the new value of the field in the New_ field.or otherwise leaves it as null.
The second version of recordChange, which is not used in the base configuration, does not perform the automatic
populating of fields based on the ServiceRequest state. Instead, it expects the caller to create and populate the
ServiceReqeustChange object as desired.

How to configure service request metrics

ClaimCenter provides various measurements on the status and timeliness of service requests in the Metrics section of
the Services screen.
In the base configuration, the following service request metrics are available:
• Response Time
• Quote Timeliness
• Service Timeliness
• Invoice Variance vs. Quote
• Number of Delays
• Cycle Time
Service request metrics are modeled after claim health metrics, and you can configure ClaimCenter to track
additional, custom metrics.
See Also
• “Configuring claim health metrics” on page 657
• Application Guide

Example - Creating a custom service request metric

You can create a new service request metric by creating a subtype of an existing metric and adding implementation
code. If you add a new subtype, the platform layer automatically adds a new member to the associated typelist. For
example, if you add a new subtype of MoneyServiceRequestMetric, the system adds a new member to the
ServiceRequestMetric typelist. Adding a new subtype is the only way of adding new members to this typelist.
In this example, a custom service request metric, TestMoneyServiceRequestMetric, is created to handle financial
metrics related to service requests.

596 chapter 39 Configuring services

 Configuration Guide 9.0.5

Step 1. Create a subtype for the new metric

Before you begin

Before proceeding, review the information in “Example - Creating a custom service request metric” on page 596.

About this task

The first step in creating a custom service request metric is to extend the ServiceRequestMetric entity. Typically,
one of the supplied subtypes of this class, IntegerServiceRequestMetric, DecimalServiceRequestMetric,
MoneyServiceRequestMetric, or TimeBasedServiceRequestMetric, can be extended, based on the metric type.
In this example, as a financial measurement is being tracked, the MoneyServiceRequestMetric entity to used to
create a new subtype.

Procedure
1. If necessary, start Guidewire Studio.
At a command prompt, navigate to the ClaimCenter directory and enter:

gwb studio

2. Navigate to configuration→config→Extensions→Entity.
3. Right-click and select New→Entity. Enter the following values:

Name Value
Entity TestMoneySRMetric

Entity Type subtype

Desc Custom money metric for service requests.

Supertype MoneyServiceRequestMetric

Final No

4. The TestMoneySRMetric entity editor is now shown. Click the plus icon ( ), and select implementsInterface
from the drop-down choice list.
Enter the following values:

Name Value
iface gw.api.metric.MetricMethods

impl gw.vendormanagement.metric.TestMoneyService RequestMetricMethodsImpl

<?xml version="1.0"?>
<subtype
xmlns="http://guidewire.com/datamodel"
desc="Custom money metric for service requests."
entity="TestMoneySRMetric"
supertype="MoneyServiceRequestMetric">
<implementsInterface
iface="gw.api.metric.MetricMethods"
impl="gw.vendormanagement.metric.TestMoneyServiceRequestMetricMethodsImpl"/>
</subtype>

The Xml tab now displays the following code:

ClaimCenter automatically adds the new money metric subtype to the ServiceRequestMetric typelist.
The TestMoneyServiceRequestMetricMethodsImpl class does not exist yet. It is possible to see a
corresponding error in Guidewire Studio. The next step creates this class.
Example - Creating a custom service request metric 597
 Configuration Guide 9.0.5

Next steps
Continue to “Step 2. Add the new metric to the implementation classes” on page 598.

Step 2. Add the new metric to the implementation classes

Before you begin

Before proceeding, complete procedure “Step 1. Create a subtype for the new metric ” on page 597.

Procedure
1. Navigate to configuration→config→gsrc→gw→vendormanagement→metric, right-click and select
New→GosuClass.
2. Enter the following values:

Name Value
Name TestMoneyServiceRequestMetricMethodsImpl
Kind Class

Click OK.
3. Edit the new class, TestMoneyServiceRequestMetricMethodsImpl.gs, that extends the
MoneyServiceRequestMetricMethodsImpl class, for example.

package gw.vendormanagement.metric

uses gw.api.vendormanagement.metric.MoneyServiceRequestMetricMethodsImpl
uses gw.api.metric.MetricUpdateHelper
uses java.util.Date

class TestMoneyServiceRequestMetricMethodsImpl extends MoneyServiceRequestMetricMethodsImpl

{
construct(moneyServiceRequestMetric : MoneyServiceRequestMetric)
{
super(moneyServiceRequestMetric)
}

override property get Metric() : MoneyServiceRequestMetric

{
return super.Metric
}

override function updateMetricValue(helper : MetricUpdateHelper) : Date

{
Metric.MoneyValue = 34.34
return null
}
}

4. Save your changes.

Next steps
Continue to “Step 3. Test the changes” on page 598.

Step 3. Test the changes

Before you begin

Before proceeding, complete procedure “Step 2. Add the new metric to the implementation classes” on page 598.

598 chapter 39 Configuring services

 Configuration Guide 9.0.5

Procedure
1. Shut down ClaimCenter if it is running, and then restart it.
2. Log into ClaimCenter as a user with the appropriate permissions to view and edit claims.
For example, log in as user aapplegate with password gw.
3. Open an existing claim with service requests.
4. Select Services from the sidebar.

Result
The new metric, TestMoneyServiceRequestMetric, is now visible in the Metrics section of the Services screen.

How to configure service request metric limits

Service request metrics are similar to claim health metrics with one difference – ClaimCenter provides the
IServiceRequestMetricLimitFinderPlugin to allow for additional flexibility when configuring metric limits. In
the base configuration, IServiceRequestMetricLimitFinderPlugin retrieves service request metric limits, like
other health metrics, from the ClaimCenter database. You can configure this plugin to compute limits based on claim
and service request properties or to extract limit values from a contract system.
Unlike claim or exposure metrics, the IServiceRequestMetricLimitFinderPlugin extracts much of the
functionality for finding and matching limits out into a separate class.
The plugin interface provides two methods:
• findLimitValues – Searches for the limit object matching the metric and service request passed in and performs
calculations to return a set of target limit values. If there are multiple service requests, there may be multiple
limits matched to the metric. In this case, the most lenient limit is returned.
In the base configuration, the following fields are used to match service requests to limits:
◦ ServiceCategory
◦ SpecialistService
◦ ServiceRequestTier
◦ ServiceRequestMetric
◦ PolicyServiceTier
◦ limitValuesOutOfDate – Examines potentially changeable fields on the limit object and returns true if the
limit values that were matched before are now out of date. Examples of limit objects are
ServiceRequestTier, Currency, or PolicyServiceTier.

Import service request metric limits

About this task

Plugin implementation IServiceRequestMetricLimitFinderPlugin provides service request metric limits. In the
base configuration, the plugin implementation class is ServiceRequestMetricLimitFinderImpl, which returns
limits from the ServiceRequestMetricLimit table. If you use this plugin implementation, you need to populate
this table, which you can accomplis by using the import functionality in the ClaimCenter Administration menu.
Guidewire includes sample limits data in file servicerequestmetriclimits.xml, which illustrates the format for
this file.
Use the steps below to configure your service request metric limits with a modified version of this file:

Procedure
1. If necessary, start Guidewire Studio.
At a command prompt, navigate to the ClaimCenter directory and enter:

Example - Creating a custom service request metric 599

 Configuration Guide 9.0.5

gwb studio

2. Navigate to configuration→config→sampledata.
3. Copy servicerequestmetriclimits.xml to your local repository and modify it as needed.
The following excerpt is an example of the limits data included in the base configuration of ClaimCenter.

<?xml version="1.0"?>
<import xmlns="http://guidewire.com/cc/exim/import" version="p5.55.a10.159.174">
<ServiceRequestMetricLimit public-id="cc:1">
<Currency/>
<CustomerServiceTier/>
<DecimalRedValue>16.0000</DecimalRedValue>
<DecimalTargetValue>8.0000</DecimalTargetValue>
<DecimalYellowValue>8.0000</DecimalYellowValue>
<LimitType>nooffset</LimitType>
<MetricUnit>hours</MetricUnit>
<ServiceCategory public-id="svc:aut"/>
<ServiceRequestMetricType>
SpecialistInitialResponseTimeServiceRequestMetric
</ServiceRequestMetricType>
<ServiceRequestTier/>
<SpecialistService/>
</ServiceRequestMetricLimit>
<ServiceRequestMetricLimit public-id="cc:2">
<Currency/>
<CustomerServiceTier>platinum</CustomerServiceTier>
<DecimalRedValue>8.0000</DecimalRedValue>
<DecimalTargetValue>4.0000</DecimalTargetValue>
<DecimalYellowValue>4.0000</DecimalYellowValue>
<LimitType>nooffset</LimitType>
<MetricUnit>hours</MetricUnit>
<ServiceCategory public-id="svc:aut"/>
<ServiceRequestMetricType>
SpecialistInitialResponseTimeServiceRequestMetric
</ServiceRequestMetricType>
<ServiceRequestTier/>
<SpecialistService/>
</ServiceRequestMetricLimit>
<ServiceRequestMetricLimit public-id="cc:3">
<Currency/>
<CustomerServiceTier/>
<DecimalRedValue>5.0000</DecimalRedValue>
<DecimalTargetValue>2.0000</DecimalTargetValue>
<DecimalYellowValue>2.0000</DecimalYellowValue>
<LimitType>nooffset</LimitType>
<MetricUnit>days</MetricUnit>
<ServiceCategory public-id="svc:pro"/>
<ServiceRequestMetricType>
SpecialistInitialResponseTimeServiceRequestMetric
</ServiceRequestMetricType>
<ServiceRequestTier/>
<SpecialistService/>
</ServiceRequestMetricLimit>

4. Import the updated servicerequestmetriclimits.xml file into ClaimCenter by clicking the Administration
tab and navigating to Utilities→Import Data.

Next steps
After you import the service request limit XML data into the application, you cannot edit it by using the application
user interface. Instead, edit the corresponding XML file, as needed, and import it back into ClaimCenter.
See also
• Guidewire Contact Management Guide
• Installation Guide
• Application Guide

600 chapter 39 Configuring services

chapter 40

Configuring business rules

This topic discusses how to implement the ClaimCenter business rule plugin.

The business rules plugin

Guidewire provides a business rules plugin, the ICCBizRulesPlugin plugin, that you configure to manage certain
business rule functionality. In the base configuration, Gosu class CCBizRulesPlugin provides the default
implementation for this plugin. CCBizRulesPlugin implements the ICCBizRulesPlugin interface.
By modifying the default ICCBizRulesPlugin plugin implementation, you can do the following:
• Create new rule contexts and rule triggers
• Modify the set of methods and entity properties that are visible through autocompletion 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
• Create rule activities and history events on custom entities, as well as add new command parameters to the rule
action and enhance the rule action logic

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 CCBizRulesPlugin
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, ClaimCenter 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
configuration, ClaimCenter 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.

Configuring business rules 601

 Configuration Guide 9.0.5

Object Function
Note: Array properties such as claim.Activities, do not allow de-referencing. For example,
ClaimCenter does not allow claim.Activities[0]. However, ClaimCenter does permit array
properties such as claim.Activities.Count.
RuleActionExtensions Provides a mechanism to set extension fields on entities that ClaimCenter creates through rule
actions. ClaimCenter sets the entity fields after it completes performing all core rule actions. It is
not possible to modify the default core rule actions.
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
configuration, ClaimCenter 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 CCBizRulesPlugin 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 IBizRulesPlugin class, Guidewire does not blacklist
any entity methods. To blacklist an entity method, use a similar procedure as that used to whitelist properties.

private var _blackListedMethods: HashSet<IMethodReference>

…
_blackListedMethods = new HashSet<IMethodReference>()
setBlackListedMethodsOnClaim()
…
private function setBlackListedMethodsOnClaim() {
_blackListedMethods.add(Claim#…)
…
}

Blacklisting an entity property in the rule condition builder

To blacklist an entity property is to make that entity property unavailable for use in the Rule Condition builder in the
business rules editor. In the base configuration implementation of the IBizRulesPlugin class, Guidewire blacklists
a number of properties on the Claim and Exposure entities as not permitted.
To see the complete list of forbidden entity properties in the base configuration, see the following functions in Gosu
class CCBizRulesPlugin:
• private function setBlackListedPropertiesOnClaim()
• private function setBlackListedPropertiesOnExposure()
It is possible to modify each of these functions and add properties to, or delete properties from, the list of blacklisted
properties. To add a property, use one of the existing properties as a template. The following code illustrates a
blacklisted property definition.

602 chapter 40 Configuring business rules

 Configuration Guide 9.0.5

_blackListedProperties.add(Claim#Access)

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 IBizRulesPlugin class, Guidewire whitelists a
number of methods on the Claim, Address, and Payment entities as specifically permitted.
To see the complete list of permitted entity methods in the base configuration, see the following functions in Gosu
class CCBizRulesPlugin:
• private function setWhiteListedPropertiesOnClaim()
• private function setWhiteListedPropertiesOnAddress()
• private function setWhiteListedPropertiesOnPayment()
It is possible to modify each of these functions and add methods to, or delete methods from, the list of whitelisted
methods. To add a method, use one of the existing methods as a template. The following code illustrates a
whitelisted method definition.

_whiteListedMethods.put(Address#isChanged(),"Method to test if a field has changed")

Rule actions on custom entity extensions

It is not possible to modify the default rule actions of the base configuration activity business rules. It is possible to
create activities on custom entities that you create. You can also add new command parameters to the rule action and
enhance the rule action execution logic.
In the default implementation of the CCBizRulesPlugin class, Guidewire provides several examples that you can
use as templates in working with this functionality. See the following property definition for details.

override property get RuleActionExtensions(): Map<RuleActionKey, RuleActionExtension> { … }

Triggering point mapping

It is not possible to add, delete, or modify the default activity rule triggering points that exist in the default
implementation of CCBizRulesPlugin class. In the base configuration, Guidewire provides the following trigger
point mapping.

private var _triggeringPoints: Map<TriggeringPointKey, IRuleContextDefinition[]>

…
_triggeringPoints = Maps.newHashMap<TriggeringPointKey, IRuleContextDefinition[]>()
_triggeringPoints.put(TriggeringPointKey.TC_CREATION,{claimCD,exposureCD,expoIterCD}.toTypedArray())
_triggeringPoints.put(TriggeringPointKey.TC_UPDATE,
{claimCD,exposureCD,expoIterCD,checksetIterCD,recoverysetIterCD,reservesetIterCD,
recoveryreservesetIterCD,subroIterCD}.toTypedArray())
_triggeringPoints.put(TriggeringPointKey.TC_EXCEPTION, {claimCD,expoIterCD}.toTypedArray())

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 example, for a custom function to return the current date.
To access a custom function in the expression builder, use the following syntax, with xxxx being the name of the
custom method:

Util.xxxx()

Gosu class ActivityRulesUtility, in package gw.bizrules, defines the available custom functions. In the base
configuration, this class contains such functions as currentDate and getSIActivityThreshold.
Configuring methods and properties for business rule conditions 603
 Configuration Guide 9.0.5

To add new functions to this class, use the existing functions as examples of how to define a new function.
The following example illustrates how to add a new function to convert currencies from within the business Rules
screen.
In ActivityRulesUtility:

public function getMarketExchangeRate(fromCurrency : Currency, toCurrency : Currency): BigDecimal

{
return CurrencyUtil.getMarketExchangeRate(fromCurrency, toCurrency);
}

In the Rule Condition builder in the Business Rules editor:

claim.Checks Contains a check where check.GrossAmount.Amount > 10000 *

(Util.getMarketExchangeRate(typekey.Currency.TC_JPY, typekey.Currency.TC_USD))

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 ClaimCenter uses the rule context definition to define the symbol table that provides the list of symbols
definition available in the business rules editor while creating or editing a rule during rule development.
Context ClaimCenter 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.

ClaimCenter business rule context definition

Guidewire uses public class RuleContextDefinitionBuilder to define a business rule context. ClaimCenter
initializes each rule context and adds context symbols in the ClaimCenter ICCBizRulesPlugin implementation. The
implementation class for this plugin is CCBizRulesPlugin. For example, class CCBizRulesPlugin defines an
exposureCD context definition with several context symbols:

var exposureCD = new RuleContextDefinitionBuilder()

.withRuleContextDefinitionKey(RuleContextDefinitionKey.TC_EXPOSURE)
.withSymbol(ActivityRulesContextParameterName.exposure.Name, Exposure)
.withSymbol(ActivityRulesContextParameterName.claim.Name, Claim)
.withSymbol(ActivityRulesContextParameterName.Util.Name, ActivityRulesUtility)
.build()

To add a new rule context definition, follow the steps outlined in “Add new matter context definition to an activity
rule” on page 604.

Add new matter context definition to an activity rule

Use this procedure to add a new matter context definition to an activity rule.

Procedure
1. Open ClaimCenter Studio.
2. Add the following typecode to the RuleContextDefinitionKey typelist extension. If this typelist extension
does not exist, create it.

Code Matter

Name Matter

604 chapter 40 Configuring business rules

 Configuration Guide 9.0.5

3. In the Studio Project window, navigate to gsrc→gw→bizrules and create a package under bizrules to hold your
work.
4. Add a new enum parameter name class for matter in your work package. Name it
ActivityRulesContextParameterNameExtension and populate it with the following text.

package ...

enum ActivityRulesContextParameterNameExtension {
matter
}

5. Enhance the AbstractCommandParemeterSet class (in the gw.bizrules.ruleaction.config package) to

create a new Matter variable. Name the new class AbstractCommandParameterSetEnhancement, place it in
your working package, and populate it with the following text.

package ...

uses gw.bizrules.ruleaction.config.AbstractCommandParameterSet

enhancement AbstractCommandParameterSetEnhancement : AbstractCommandParameterSet {

property get Matter() : Matter {

return this._extensionParameters.get( "MATTER") as Matter
}

property set Matter(matter : Matter) {

this._extensionParameters.put( "MATTER",matter)
}
}

6. Enhance the BaseCommandParameterConfig class to create a new Matter command parameter. Name the
enhancement BaseCommandParameterConfigEnhancement and populate it with the following text.

package ...

uses gw.bizrules.ruleaction.config.AbstractCommandParameterSet
uses gw.bizrules.ruleaction.config.BaseCommandParameterConfig
uses gw.bizrules.ruleaction.config.CCCommandParameterDefinition
uses gw.bizrules.ruleaction.config.CCCommandParameterUIConfigBuilder

enhancement BaseCommandParameterConfigEnhancement : BaseCommandParameterConfig {

property get MATTER() : CCCommandParameterDefinition {
return new CCCommandParameterDefinition() {
:Name = "Matter",
:Property = AbstractCommandParameterSet#Matter,
:UIConfig = new CCCommandParameterUIConfigBuilder()
.withContextParameterPassThrough(ActivityRulesContextParameterNameExtension.matter.Name)
.build()
}
}
}

7. Create a new MatterTriggeringPoint class to manage the new Matter context.

Open one or two classes with names similar to the class that you want to create and review their contents. For
example, review class ClaimMatteringPoint. Populate your new class with content similar to the following.

package ...

uses gw.bizrules.context.ActivityRulesContextParameterName
uses gw.bizrules.context.ClaimApplicabilityCriteriaPredicate
uses gw.bizrules.context.RuleContextBuilder
uses gw.bizrules.IRuleContext
uses gw.bizrules.ITriggeringPoint
uses gw.plugin.bizrules.ICCBizRulesPlugin
uses gw.plugin.Plugins

uses java.util. function.Predicate

class MatterTriggeringPoint implements ITriggeringPoint {

Rule contexts and rule context definitions 605

 Configuration Guide 9.0.5

private var _key : TriggeringPointKey

private var _applicabilityCriteria : ClaimApplicabilityCriteriaPredicate

/**
* Context Objects
*/
private var _claim : Claim
private var _matter : Matter

construct(key : TriggeringPointKey, matter : Matter) {

_key = key;
_claim = matter.Claim;
_matter = matter;
_applicabilityCriteria = new ClaimApplicabilityCriteriaPredicate(_claim)
}

override property get Key(): TriggeringPointKey {

return _key
}

private static final var SUPPORTED_CONTEXTS = {

RuleContextDefinitionKey.TC_MATTER
}.toSet().freeze()

override function supportedContexts(): Set<RuleContextDefinitionKey> {

return SUPPORTED_CONTEXTS
}

override function generateContexts(contextDefinitionKey: RuleContextDefinitionKey): List<IRuleContext> {

switch(contextDefinitionKey) {

// Claim Context contains the symbol "matter"

case RuleContextDefinitionKey.TC_MATTER:
return { new RuleContextBuilder()
.forContextDefinitionKey(contextDefinitionKey)
.withSymbol(ActivityRulesContextParameterName.claim. Name, _claim)
.withSymbol(ActivityRulesContextParameterNameExtension.matter. Name, _matter)
.withSymbol(ActivityRulesContextParameterName.Util. Name,
Plugins.get(ICCBizRulesPlugin). BizRulesUtility)
.build()}
default:
throw new IllegalArgumentException( "Unsupported context: " + contextDefinitionKey)
}
}

override property get RuleApplicabilityPredicate(): Predicate<RuleVersion> {

return _applicabilityCriteria
}
}

In your implementation of a TriggeringPoint class, you control the number and type of symbols to add.
With that said, Guidewire recommends (but does not require) that you always include a Claim symbol in your
list of context symbols. Remember that whatever context symbols you add to your TriggeringPoint class
you must also add to the list of context definitions in class CCBizRulesPlugin.
8. Create a Gosu Matter Preupdate rule to trigger execution of the MatterTriggeringPoint class.
As ClaimCenter triggers all business rules off of Gosu rules, you need to add a Gosu rule that references your
MatterTriggeringPoint class. Updating a matter in ClaimCenter triggers the Matter Preupdate rule, which
then passes the specific matter for update to class MatterTriggeringPoint.

USES:
uses gw.bizrules.context.MatterTriggeringPoint

CONDITION: (matter : entity.Matter):

return true

ACTION (matter : entity.Matter, actions : gw.rules.Action):

gw.bizrules.BizRulesExecutor.getInstance()
.trigger(new MatterTriggeringPoint(TriggeringPointKey.TC_UPDATE, matter))

END

606 chapter 40 Configuring business rules

 Configuration Guide 9.0.5

9. Add entries for the matter-related display keys that you need to the display.properties file appropriate for
your locale.

Web.ActivityRules.Action.GenerateActivity.Assignee.MatterCreator = Matter Creator

Web.ActivityRules.Action.GenerateActivity.Assignee.MatterOwner = Matter Owner
Web.ActivityRules.Action.GenerateActivity.Restriction.Matter = No duplicate Activity on Matter
Web.ActivityRules.Action.RelatedTo.Matter = Matter

10. Create a new MatterOwnerActivityAssigneeLoader class.

Open one or two classes with names similar to the class that you want to create and review their contents. For
example, open class ExposureOwnerActivityAssigneeLoader and review its contents. Populate your new
class with content similar to the following.

package ...

uses com.google.common.base.Preconditions
uses gw.api.locale.DisplayKey
uses gw.bizrules.ruleaction.behavioralcommandparam.assignee.ActivityAssignee
uses gw.bizrules.ruleaction.behavioralcommandparam.assignee.BaseActivityAssigneeLoader
uses gw.bizrules.ruleaction.behavioralcommandparam.assignee.UserBasedActivityAssignee
uses gw.bizrules.ruleaction.generateactivity.config.GenerateActivityCommandParameterSet

/**
* Behavioral Command Parameter Value loads a UserBasedActivityAssignee to assign
* the activity to the matter owner
*/
class MatterOwnerActivityAssigneeLoader extends BaseActivityAssigneeLoader {

/**
* Name of the Behavioral Command Parameter Value
*/
public final static var NAME : String = "Matter_Owner"

/**
* Singleton Instance
*/
public static var INSTANCE : MatterOwnerActivityAssigneeLoader =
new MatterOwnerActivityAssigneeLoader()

public construct() {
_name = NAME
_uidisplay = DisplayKey.get( "Web.ActivityRules.Action.GenerateActivity.Assignee.MatterOwner")
_directlyAssignable = true
_additionalInfoMode = null
}

override public function loadActivityAssignee(params : GenerateActivityCommandParameterSet) :

List<ActivityAssignee> {
Preconditions.checkArgument(params.Matter != null,
"Cannot create Matter Owner assignee for parameter set with null Matter")
return {new UserBasedActivityAssignee(params.Matter.AssignedUser)}
}
}

11. Create a new MatterCreatorActivityAssigneeLoader class.

Open one or two classes with names similar to the class that you want to create and review their contents. For
example, open class ExposureCreaterActivityAssigneeLoader and review its contents. Populate your new
class with content similar to the following.

package ...

uses com.google.common.base.Preconditions
uses gw.api.locale.DisplayKey
uses gw.bizrules.ruleaction.behavioralcommandparam.assignee.ActivityAssignee
uses gw.bizrules.ruleaction.behavioralcommandparam.assignee.BaseActivityAssigneeLoader
uses gw.bizrules.ruleaction.behavioralcommandparam.assignee.UserBasedActivityAssignee
uses gw.bizrules.ruleaction.generateactivity.config.GenerateActivityCommandParameterSet

/**
* Behavioral Command Parameter Value loads a UserBasedActivityAssignee to assign
* the activity to the matter creator

Rule contexts and rule context definitions 607

 Configuration Guide 9.0.5

*/
class MatterCreatorActivityAssigneeLoader extends BaseActivityAssigneeLoader {

/**
* Name of the Behavioral Command Parameter Value
*/
public final static var NAME : String = "Matter_Creator"

/**
* Singleton Instance
*/
public static var INSTANCE : MatterCreatorActivityAssigneeLoader =
new MatterCreatorActivityAssigneeLoader()

public construct() {
_name = NAME
_uidisplay = DisplayKey.get( "Web.ActivityRules.Action.GenerateActivity.Assignee.MatterCreator")
_directlyAssignable = true
_additionalInfoMode = null
}

override public function loadActivityAssignee(params : GenerateActivityCommandParameterSet) :

List<ActivityAssignee> {
Preconditions.checkArgument(params.Matter != null,
"Cannot create Matter Assignee for parameter set without Matter")
return { new UserBasedActivityAssignee(params.Matter.getCreateUser() ) }
}
}

12. Create a new DuplicateMatterActivityRestriction class similar to

DuplicateClaimActivityRestriction.
For example, create something similar to the following class.

package ...

uses gw.api.locale.DisplayKey
uses gw.bizrules.ruleaction.behavioralcommandparam.activityrestriction.BaseActivityRestriction
uses gw.bizrules.ruleaction.behavioralcommandparam.assignee.ActivityAssignee
uses gw.bizrules.ruleaction.generateactivity.config.GenerateActivityCommandParameterSet
uses entity.Activity

/**
* Behavioral Command Parameter Value describes the ActivityRestriction where no duplicate activity
* should be generated for matter
*/
class DuplicateMatterActivityRestriction extends BaseActivityRestriction {

/**
* Name of the Behavioral Command Parameter Value
*/
public final static var NAME : String = "Duplicate_Activity_Matter"

/**
* Singleton Instance
*/
public static var INSTANCE : DuplicateMatterActivityRestriction =
new DuplicateMatterActivityRestriction()

construct() {
_name = NAME
_uidisplay = DisplayKey.get( "Web.ActivityRules.Action.GenerateActivity.Restriction.Matter")
}

override public function checkIfActivityRestricted(acts : Activity[],

params : GenerateActivityCommandParameterSet,
assignee : ActivityAssignee) : boolean {
return acts.hasMatch(\ act -> act.ActivityPattern.Code == params.Pattern)
}
}

13. Add an entry for the new matter context to class ActivityAssigneeDefaultValueHandler (in package
gw.bizrules.ruleaction.defaultvaluehandler).
a. Find the if statement in the class that starts with the following text:

608 chapter 40 Configuring business rules

 Configuration Guide 9.0.5

if ( ruleContextKey == RuleContextDefinitionKey.TC_EXPOSURE...

b. Add a new else if statement at the end of the if statement for the new matter context definition that is
similar to the existing context definitions.
For example, add the following to the end of the if statement:

else if (ruleContextKey == RuleContextDefinitionKey.TC_MATTER){

assignees.add(MatterCreatorActivityAssigneeLoader.INSTANCE)
}

14. Add an entry for the new matter context to class ActivityRestrictionDefaultValueHandler (in package
gw.bizrules.ruleaction.defaultvaluehandler).
a. Find the if statement in the class that starts with the following text:

if (ruleContextKey == RuleContextDefinitionKey.TC_EXPOSURE

b. Add the following line to towards the end of the if statement, directly above the null statement.

|| ruleContextKey == RuleContextDefinitionKey.TC_MATTER

c. Search for the restrictList code and add the following restriction in an appropriate place:

restrictsList.add(DuplicateMatterActivityRestriction.INSTANCE)

15. Add an entry for the new matter context to class RelatedToDefaultValueHandler (in package
gw.bizrules.ruleaction.defaultvaluehandler).
a. Find the last line of the code that defines the _defaultRelatedToMap parameter (before the closing curly
brace) and add a comma at the end of the line.
b. Add a RuleContextDefinitionKey similar to the others for the new Matter context directly under that
line.
For example:

RuleContextDefinitionKey.TC_MATTER->MatterRelatedTo.INSTANCE

16. Add a new method for the new matter context parameter to the ActivityRuleCommandDefinitionBuilder
class.
For example, add something similar to the following text to this class.

function withMatterContextParameter() : B {
addToMap( Config.MATTER, ExpressionFragmentBuilders.forCodeExpression("matter") )
return this as B
}

17. Create a new MatterRelatedTo class that is similar to the ClaimRelatedTo class.
For example, create something similar to the following class.

package ...

uses gw.api.locale.DisplayKey
uses gw.bizrules.ruleaction.behavioralcommandparam.relatedto.BaseActivityRulesRelatedTo
uses gw.bizrules.ruleaction.config.AbstractCommandParameterSet
uses gw.bizrules.ruleaction.generatehistoryevent.config.GenerateHistoryEventCommandParameterSet
uses gw.pl.persistence.core.Bean

/**
* Behavioral Command Parameter Value describes the ActivityRulesRelatedTo where the activity
* is related to Matter
*/
class MatterRelatedTo extends BaseActivityRulesRelatedTo {

Rule contexts and rule context definitions 609

 Configuration Guide 9.0.5

/**
* Name of the Behavioral Command Parameter Value
*/
public final static var NAME : String = "Matter"

/**
* Singleton Instance
*/
public static var INSTANCE : MatterRelatedTo = new MatterRelatedTo()

construct() {
_name = NAME
_uidisplay = DisplayKey.get( "Web.ActivityRules.Action.RelatedTo.Matter")
}

override function getRelatedToBean(paramSet: AbstractCommandParameterSet) : Bean {

if(paramSet.Matter == null) {
throw new IllegalStateException("Expected RelatedTo parameter for MatterRelatedTo was null.")
}
return paramSet.Matter
}

override function createHistory(paramSet : GenerateHistoryEventCommandParameterSet) : History {

if(paramSet.Matter == null) {
throw new IllegalStateException("Expected RelatedTo parameter for MatterRelatedTo was null.")
}
var history : History
if (paramSet.Type != null) {
if (paramSet.Type typeis HistoryType) {
history = paramSet.Claim.createHistoryEvent(paramSet.Type, paramSet.Description)
} else if (paramSet.Type typeis CustomHistoryType) {
history = paramSet.Claim.createCustomHistoryEvent(paramSet.Type, paramSet.Description)
}
} else {
throw new IllegalStateException("Neither Type or CustomType were set
on GenerateHistoryEventCommandParameterSet, unable to make history")
}
return history
}
}

18. Open class CCBizRulesPlugin (in package gw.bizrules) and add entries for the new matter context and the
supporting classes that you created.
a. Find the list of context definition variables and add the Matter context to the end of the list.
For example:

var matterCD = new RuleContextDefinitionBuilder()

.withRuleContextDefinitionKey(RuleContextDefinitionKey.TC_MATTER)
.withSymbol(ActivityRulesContextParameterNameExtension.matter.Name, Matter)
.withSymbol(ActivityRulesContextParameterName.claim.Name, Claim)
.withSymbol(ActivityRulesContextParameterName.Util.Name, ActivityRulesUtility)
.build()

b. Find the line that starts with _triggeringPoints.put(TriggeringPointKey.TC_UPDATE and add

matterCD to the end of the list of contexts.
For example, add something similar to the folllowing to this class.

_triggeringPoints.put(TriggeringPointKey.TC_UPDATE, {claimCD,exposureCD,expoIterCD,checksetIterCD,
recoverysetIterCD,reservesetIterCD,recoveryreservesetIterCD,subroIterCD,matterCD}
.toTypedArray())

c. Search for the line that begins with override property get
BehavioralCommandParameterExtensions() and enter your class names as the comments indicate.
For example, enter something similar to the following in this class.

override property get BehavioralCommandParameterExtensions() :

Map<Class, BehavioralCommandParameterExtension> {
return {

ActivityAssigneeLoader->new BehavioralCommandParameterExtension<ActivityAssigneeLoader>() {

610 chapter 40 Configuring business rules

 Configuration Guide 9.0.5

override function registerBehavioralCommandParameterValues(list:

List<ActivityAssigneeLoader>) {
// Add any new ActivityAssigneeLoaders to this list to be registered
// in class ActivityAssigneeLoaderFactory
list.add(MatterCreatorActivityAssigneeLoader.INSTANCE)
}
},

ActivityRulesRelatedTo->new BehavioralCommandParameterExtension<ActivityRulesRelatedTo>() {
override function registerBehavioralCommandParameterValues(list: List<ActivityRulesRelatedTo>) {
// Add any new ActivityRulesRelatedTos to this list to be registered
// in class ActivityRulesRelatedToFactory
list.add(MatterRelatedTo.INSTANCE)
}
},

ActivityRestriction->new BehavioralCommandParameterExtension<ActivityRestriction>() {
override function registerBehavioralCommandParameterValues(list: List<ActivityRestriction>) {
// Add any new ActivityRestrictions to this list to be registered
// in class ActivityRestrictionFactory
list.add(DuplicateMatterActivityRestriction.INSTANCE)
}
}
}
}

19. Regenerate and recompile the Java class that backs the RuleContextDefinitionKey typelist.
a. Save all your work.
b. Select Generate Metadata Classes from the Studio Codegen menu.
This action regenerates class RuleContextDefinitionKey.java, adding the new matter typekey to the
class.
c. Select Make Project from the Studio Build menu.
This action recompiles the newly regenerated RuleContextDefinitionKey class. This action is necessary
in order for the Gosu compiler to see the new typekey as it recompiles class CCBizRulesPlugin and other
classes.
20. If using an application server other than the default Quickstart server, create and deploy a WAR or EAR file as
necessary.
21. To test your work, create a new Activity business rule in ClaimCenter and verify that you can see and chose
the matter context.

Working with TriggeringPoint classes

If you create a new rule context, you do not necessarily need to create a new TriggeringPoint implementation,
unless the new context has data that is unique and that does not exist in the current rule contexts. For example, if

Rule contexts and rule context definitions 611

 Configuration Guide 9.0.5

your new context still uses Claim as the initial data when business rules are triggered, then you need only to update
the existing ClaimTriggeringPoint implementation:
• Add your new context to the list of existing supported contexts (in static variable SUPPORTED_CONTEXTS).
• Add your new context as a new case statement in method generateContexts.
However, if you are adding a new rule context that is not a base configuration context, then you need to do the
following:
• Create a new TriggeringPoint implementation for that object type.
• Add a Gosu rule to trigger business rules execution using your new TriggeringPoint class. (As ClaimCenter
triggers the business rules off of Gosu rules, you need to add a Gosu rule for that purpose.)

Configuring applicability criteria

ClaimCenter 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, ClaimCenter defines the following types of applicability criteria in the ActivityRule
entity metadata definition:

Applicability criteria Array name Array entity

Loss type LossTypes AppCritLossType

Policy type PolicyTypes AppCritPolicyType

Jurisdiction Jurisdictions AppCritJurisdiction

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.

Single-value The business rule data model stores single applicability values as a property on the ActivityRule entity type. To
rule criteria use a single-value criterion, add properties for single values to the ActivityRule 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 to
rule criteria the ActivityRule entity type. These linked entities need to implement the RuleVersionDependent interface.
Implementing this interface ensures that ClaimCenter imports and exports these entity properties as part of the
rule.

Filtering single- and multi-value applicability criteria

Guidewire provides internal Java class ClaimApplicabilityCriteriaPredicate 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 ClaimApplicabilityCriteriaPredicate class to
determine how to filter rules for execution whenever application logic triggers the business rules framework.

612 chapter 40 Configuring business rules

 Configuration Guide 9.0.5

See also
• Application Guide

Add a new ClaimCenter applicability criterion

About this task
Adding a new applicability criterion to the set of availability criteria available in the ClaimCenter 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:
• AppCritLineLossType
• AppCritPolicyType
• AppCritJurisdiction
Use the same naming conventions as the existing examples.
2. Add the applicability criterion to the ActivityRule 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 ClaimApplicabilityCriteriaPredicate 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 ActivityRulePanelSet 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 ActivityRules so that the list view shows a column for the new applicability
criterion.
7. (Optional) Update Gosu class ActivityRuleFilterCriteria and the associated
ActivityRuleFilterCriteriaDV PCF to improve the search filtering view on the Activity Rules screen.
You access the search functionality of the ActivityRuleFilterCriteriaDV PCF pane by clicking Show Filters
on the Activity Rules screen.

Configuring applicability criteria 613

 Configuration Guide 9.0.5

614 chapter 40 Configuring business rules

chapter 41

Configuring deductibles

This topic explains how deductibles are structured, and how they interact with checks.
See also
• Application Guide

Deductible data model

In this data model diagram, the main entity is Deductible. Every Deductible is associated with a Coverage, and
by default gets its initial amount from the Coverage's deductible amount, the Coverage.Deductible field, which is
of type money.

Configuring deductibles 615

 Configuration Guide 9.0.5

Entities Relating to Deductible

Deductible
Amount
Paid Coverage
Waived 0..1 1
Overridden Deductible
EditReason
Coverage
Claim
Currency
1
Exposure
Coverage

0..n
TransactionLineItem
TransactionAmount
ReservingAmount Payment
ClaimAmount Exposure
ReportingAmount Check
Transaction
Deductible

Legend

A B A relates to B and
0..n vice-versa
A B A has a one-to-many
relationship with B
A B A is a subtype of B

The Deductible entity has the following fields:

Field Description
Amount The amount that this deductible represents. This amount is specified in the claim currency.
Paid Specifies whether this deductible has already been paid. This is initially false, and is set to true when a payment
is created and a deductible applied to it.
Waived Specifies whether this deductible has been waived. This value, initially false, can be set to true on the Exposure
Edit page if the deductible has not been paid yet. If set to true, the check wizard does not allow this deductible
to be applied to payments. In the database, however, a value of true indicates that the amount has been
modified.
Overridden Specifies whether this deductible has been overridden and is initially set to false. If set to true, the amount
field can be modified in the user interface.
EditReason Specifies the reason why this deductible was waived or overridden.

Coverage Foreign key link to the coverage for which this deductible was calculated. This field is nullable in the database to
support policy-level deductibles, but the base configuration does not support a null coverage field.
Claim Foreign key link to the claim for this deductible.
Currency Specifies the deductible’s coverage’s currency.

There is a one-to-at-most-one relationship from Coverage to Deductible, and a method on Coverage to access the
Deductible pointing to it, if any. TransactionLineItem has a foreign key to Deductible. A deductible can be paid
over any number of TransactionLineItems, although in the base configuration, ClaimCenter supports only paying
a deductible over one TransactionLineItem.

616 chapter 41 Configuring deductibles

 Configuration Guide 9.0.5

Typecodes for deductibles

There are two typecodes that relate to deductibles, both from the LineCategory typelist:
• Deductible – Indicates that a TransactionLineItem is a deductible line item. In other words, it is the
TransactionLineItem to which a paid deductible is linked.
• Former Deductible – Indicates that a TransactionLineItem was originally a deductible line item, but is one no
longer. Former deductibles can result from a recoded payment, a transferred or deleted check, or an onset
payment whose deductible could not be applied to it.
Both typecodes are valid for any Exposure, CostType, or CostCategory because a deductible can be applied to a
payment of any reserve line. However, they are not valid for any Matter. Wherever LineCategory is editable in the
user interface, such as in Step 2 of the Check wizard, the deductible typecodes are filtered out of the list of available
options. This filtering prevents the user from selecting either typecode for normal, non-deductible line items.
Anywhere in the user interface where LineCategory typecodes display, if a line item has a category of Deductible
or Former Deductible, you cannot edit the line category and the amount.

Permissions for deductibles

The permission EditDeductible allows the user to edit, waive, or override the deductible on a claim file.

Deductibles and checks

This topic describes how deductibles affect the following types of checks:
• “Transferring checks and deductibles” on page 617
• “Recoding payments and deductibles” on page 617
• “Deleting, voiding, and stopping checks and deductibles” on page 618
• “Denying or resubmitting checks and deductibles” on page 618
• “Applying deductibles on multicurrency checks” on page 618
• “Cleared or issued checks” on page 618
• “Cloning checks” on page 618

Transferring checks and deductibles

When transferring a check, any deductible line items on the original and offset payments become Former
Deductible, and linked deductibles are unlinked. These actions are performed in the doTransfer method in
CheckTransfer.pcf. The doTransfer method calls OldCheck.unlinkDeductibles after the target check has been
created, but before calling the gw.api.financials.CheckUtil.transferCheck method.
For the onset payment, if the target exposure has a valid deductible, then the target exposure's deductible is applied
to the onset payment. If it has not been paid or waived, and the amount and the claim currency are equal, then the
deductible amount can be applied to the payment. Otherwise, no deductible is applied, and the onset payment's
deductible line item instead becomes Former Deductible. These actions are performed in the doTransfer method in
CheckTransfer.pcf. The doTransfer method calls NewCheck.linkDeductibles before calling
gw.api.financials.CheckUtil.transferCheck.
If a check is transferred to a claim with a claim currency that is different from the original claim's currency, then the
deductible is not applied on the target claim. Two deductible amounts in different currencies cannot be directly
compared to see if they have the same amount.

Recoding payments and deductibles

When recoding a payment, any deductible line items on the original and offset payments become Former
Deductible, and linked deductibles are unlinked. These actions are performed in the doRecode method in
Typecodes for deductibles 617
 Configuration Guide 9.0.5

RecodePayment.pcf. The doRecode method calls OriginalPayment.unlinkDeductible after the onset payment
has been created, but before calling gw.api.financials.FinancialsUtil.recodePayment.
For the onset payment, if the target exposure has a valid deductible, the target exposure's deductible is applied to the
onset payment. Otherwise, no deductible is applied, and the onset payment's deductible line item instead become
Former Deductible. These actions are performed in the doRecode method in RecodePayment.pcf. The doRecode
method calls FirstOnsetPayment.linkDeductible before calling
gw.api.financials.FinancialsUtil.recodePayment.
See also
• “Transferring checks and deductibles” on page 617

Deleting, voiding, and stopping checks and deductibles

Deleting, voiding, or stopping a check converts all the check’s deductible line items to have the line category Former
Deductible. This action is not exposed in the user interface in a deleted check. The linked deductibles are unlinked
and unpaid by calling the Check.unlinkDeductibles method before calling the methods Check.delete,
Check.void, or Check.stop.

Denying or resubmitting checks and deductibles

Denying a check converts all its deductible line items to have the line category Former Deductible, and the linked
deductibles are unlinked. If you resubmit the check, ClaimCenter attempts to relink all the deductible line items to
their prospective deductibles, provided that they are still valid. During relinking, ClaimCenter does not waive or pay
the deductible line items. Additionally, the relinked deductible line items have the same amount as the
corresponding line items. Line items whose prospective deductibles are no longer valid remain unlinked.

Applying deductibles on multicurrency checks

Deductible amounts are specified in the claim currency, the currency of the claim on which the deductible's coverage
exists. You can apply a deductible in the check wizard. If you do, then the deductible line item that is being added
has an amount whose claim amount is fixed to be the negative amount of the deductible amount. Contrary to normal,
non-deductible line items, if the currency or exchange rate on the check is changed, the deductible line item’s
transaction amount is recalculated. The recalculation is based on the new exchange rate. However, its claim amount
remains fixed.
Usually, the claim amount of a transaction line item matches the amount of its linked deductible. However, the
amounts might not match if a foreign exchange adjustment is applied to a payment. In this instance, the deductible
line item's claim amount can deviate slightly from its deductible amount due to rounding errors.

Cleared or issued checks

Clearing or issuing a check does not have any impact on the deductible or former deductible line items.

Cloning checks
Cloning checks does not affect deductibles because cloning does not copy the deductible or former deductible line
items. For example, the CloneCheckWizard.pcf file calls
gw.api.financials.NormalCreateCheckWizardInfo.setupCheckWizardInfo in the first step. The
setupCheckWizardInfo method does not copy deductions, offset payments, or recoded payments. ClaimCenter
alerts you to this behavior when it occurs.

Deductibles and rules

Rules determine when claim deductibles are created. They create the deductible entity if it has not yet been created.
They also determine if the exposure’s coverage is updated. The configurable rules are in the Preupdate rule set
category.
618 chapter 41 Configuring deductibles
 Configuration Guide 9.0.5

Pre-update rule set Rule

ExposurePreupdate • Update Deductible On Updated Exposure Coverage
• Update Deductible On Updated Coverage Deductible
TransactionSetPreupdate • Unlink Deductible After Check Denial

See the Rules Guide for more information on the pre-update rules.

Deductibles and rules 619

 Configuration Guide 9.0.5

620 chapter 41 Configuring deductibles

chapter 42

Configuring weighted workload

assignment

The weighted workload feature enables the efficient balancing of assignable objects, such as claims or exposures,
across users and user groups. Weighted workload balancing happens, for the most part, in the background and uses
configurable elements such as conditions and calculated weights to estimate the amount of effort required.
A workload-aware assignable has the appropriate infrastructure and configuration to interact with weighted
workload assignment.
This topic describes the configuration of weighted workload balancing and includes:
See also
• Application Guide

About weighted workload configuration parameters

Weighted workload assignment includes two configuration parameters in file config.xml:
• WeightedAssignmentEnabled
• WeightedAssignmentGlobalDefaultWeight

WeightedAssignmentEnabled
Guidewire does not enable weighted workload balancing in the base configuration. The configuration parameter,
WeightedAssignmentEnabled, enables or disables weighted workload assignment in ClaimCenter.
Setting WeightedAssignmentEnabled to false disables automatic calculation and updating of the weights of all
assignable objects and the calculation of total workloads for users.

WeightedAssignmentGlobalDefaultWeight
Configuration parameter WeightedAssignmentGlobalDefaultWeight defines the default weight for all workload-
enabled, assignable objects. In the base configuration, Guidewire sets this value to 10 and applies it to all open

Configuring weighted workload assignment 621

 Configuration Guide 9.0.5

claims and exposures that do not match any existing workload classifications. This value must be a non-negative
integer. You can also alter the default weight of specific sets of assignable objects.

IMPORTANT Default workload weight changes have system-wide impact and must be made infrequently. If you
change this value, you need to run the UserWorkloadUpdate worker queue to recalculate stored entity workload
weights.

See also
• “Configuring the default weight in code” on page 628
• System Administration Guide

Enable weighted workload

About this task
Guidewire disables weighted workload balancing in the base configuration.

Procedure
1. Start Guidewire Studio:
a. Open a command prompt and navigate to the ClaimCenter installation directory.
b. Enter the following command:

gwb studio

2. In the Studio Project window, navigate to the following location and double-click config.xml to open it:
configuration→config
3. Find configuration parameter WeightedAssignmentEnabled and set its value to true.
4. Save your changes.

Weighted workload permissions

Distinct permissions exist for both viewing and editing weighted workload information.
These are as follows:

Permission Code Description

wwlcview View workload classifications.
wwlcmanage Modify workload classifications.
wwlview View supplemental weights on weighted workload entities.
wwlmanage Modify supplemental weights on weighted workload entities.

In the base configuration, adjusters and claim supervisors do not have these permissions. The Super User has all
permissions, and the Manager role is given permissions to view and edit supplemental weights only.

Workload weight recalculation

ClaimCenter calculates the workload weight of an assignable object based on the state of the object and its
relationship with predefined, active workload classifications. See the Application Guide for more information.

622 chapter 42 Configuring weighted workload assignment

 Configuration Guide 9.0.5

Assignable weights are recalculated only if significant changes occur that might affect the workload. These events
also trigger user workload recalculation.
These events include:
• Creation of an assignable object, such as new claim creation through the FNOL wizard.
• Reassignment.
• State changes, such as the closing or reopening of a claim.
• Modification of attributes that affect workload.
Whenever one of these events occurs, it triggers immediate recalculation of the assignable object's weight.
ClaimCenter then stores this weight on the assignable's WorkloadWeight attribute.
The following section details the attribute changes that trigger recalculation.

Claim
The following fields, if modified, trigger workload recalculation on Claim objects:
• LOBCode
• LossCause
• Segment
• SupplementalWorkloadWeight
Adding or deleting exposures from a claim triggers recalculation of workload weights. In addition, the following
fields, if modified on associated exposures of a Claim, trigger recalculation on that claim:
• PrimaryCoverage
• CoverageSubtype
• LossParty
The following fields, if modified on the associated policy of a Claim, also trigger recalculation on that claim:
• PolicyType
• CustomerServiceTier

Exposure
The following fields, if modified, trigger workload recalculation on Exposure objects:
• Segment
• PrimaryCoverage
• CoverageSubtype
• LossParty
• SupplementalWorkloadWeight

Workload weight recalculation 623

 Configuration Guide 9.0.5

The following fields, if modified on the parent claim of an exposure, triggers recalculation on that Exposure:
• LOBCode
• LossCause
The following fields, if modified on the associated policy of the parent claim of an Exposure, triggers recalculation
on that Exposure:
• PolicyType
The following fields, if modified on an associated incident of an exposure, triggers recalculation on that Exposure:
• Severity

Closing Claims and Exposures

Whenever a claim or an exposure is closed, ClaimCenter retains the last calculated workload weight value for the
claim or exposure. The user’s adjusted weight is then recalculated to exclude the closed claim or exposure.
If the claim or exposure is reopened subsequently, the weighted workload value is recalculated. See “Workload
weight computation” on page 625.

Weighted workload data model

The following object model diagram describes key entities relating to weighted workload assignment. For complete
information, see the Data Dictionary.

Weighted Workload

WorkloadClassification <<delegate>>
ClaimLOBCode WorkloadDelegate
ClaimPolicyType 1
SupplementalWorkloadWeight
ClaimLossType
WorkloadWeight
Conditions
WorkloadUpdated
Priority
Weight

Claim Exposure
ClaimWorkload ExposureWorkload
Classification Classification
AssignableType
AssignableType

*
GroupUser
ClassificationCondition AssignmentWeightedWorkload
Group
Subtype User
WorkloadClassification
1
Legend

A relates to B
A B
B relates to A 1

A B A has 0 or more Bs ConditionFilter GroupUserWorkload

* A is a subtype of B
Condition
A B A delegates to B Workload
A is enhanced by B Subtype WorkloadUpdated

The following table describes the key entities.

624 chapter 42 Configuring weighted workload assignment

 Configuration Guide 9.0.5

Entity Description
WorkloadClassification Entity that defines the workload classification, which defines the administrative processing of
workload weights.
WorkloadDelegate Delegate containing common fields used by workload-aware entities, including Claim and Exposu
re. These fields track the primary and supplemental workload weights and updates to the
workload.
ClaimWorkload Claim workload classification.
Classification

ExposureWorkload Exposure workload classification.

Classification

Classification Filtering condition for workload classifications.

Condition

ConditionFilter Type of filter associated with the workload classification condition. Subtypes include CustomerSer
viceTierConditionFilter, ExposureConditionFilter, IncidentSeverityConditionFilter, J
urisdictionConditionFilter, LossCauseConditionFilter, and SegmentConditionFilter.

GroupUser Links users to groups.

GroupUserWorkload Tracks the amount of workload assigned to a group user.

Weighted workload configuration

Guidewire does not enable weighted workload assignment in the base configuration. To enable it, you need to set the
value of WeightedAssignmentEnabled in file config.xml to true.
In addition to weighted workload configuration parameters, weighted workload configuration is comprised of the
following two components:
• Weight Computation – If weighted workload is enabled in configuration, corresponding Preupdate rules are
triggered for the assignable entity to compute the workload weight.
• User Assignment API – If weighted workload parameters and default assignment rules are enabled in
configuration, user assignment is implemented using the default workload assignment strategy.
The following topics describe these components in further detail.
See also
• “Enable weighted workload” on page 622

Workload weight computation

The first step in using weighted workload assignment is to enable this feature in configuration. See “About weighted
workload configuration parameters” on page 621.
Once weighted workload is enabled, associated Preupdate rules for Workload Assignment Balancing are
activated. Any time relevant changes occur to workload-aware assignable objects, these rules are triggered to
calculate the workload weight. Some events that activate these rules include the creation of a new claim or exposure,
reassigning of a claim or exposure, and so on.
Guidewire includes the following sample rules in the base configuration:
• “ClaimPreupdate rules” on page 626
• “ExposurePreupdate rules” on page 626
• “Global workload assignment rules” on page 626

Weighted workload configuration 625

 Configuration Guide 9.0.5

ClaimPreupdate rules
Rule Description
CPU30000 – Workload Assignment Balancing This parent rule and its child rules are activated only if weighted workload
assignment is enabled in configuration.
Checks gw.api.system.CCConfigParameters.WeightedAssignmentEnabled.V
alue.

CPU30100 – Claim Closed Updates the weighted workload value whenever a claim is closed.
CPU30200 – Claim Reassignment Updates the weighted workload value whenever the assigned user on a claim
changes.
CPU30300 – Claim Reopened Updates the weighted workload value whenever a claim status changes from
“closed” to “open.”
CPU30400 – New Claim Calculates the weighted workload value on a new claim.
CPU30500 – Claim Workload Affected Updates the weighted workload value whenever a claim field that impacts
workload is altered. See “Workload weight recalculation” on page 622.

ExposurePreupdate rules
Use these rules to manage weighted workload assignment whenever specific changes take place in the assignable
object, in this case, the exposure.

Rule Description
EPU10000 – Workload Assignment Balancing This parent rule and its child rules are activated only if weighted workload
assignment is enabled in configuration.
Checks gw.api.system.CCConfigParameters.WeightedAssignmentEnabled.V
alue.

EPU10100 – Exposure Closed Updates the weighted workload value whenever an exposure is closed.
EPU10200 – Exposure Reassignment Updates the weighted workload value whenever the assigned user on an
exposure changes.
EPU10300 – Exposure Reopened Updates the weighted workload value whenever the status of an exposure
changes from “closed” to “open.”
EPU10400 – New Exposure Calculates the weighted workload value on a new exposure.
EPU10500 – Exposure Workload Affected Updates the weighted workload value whenever a field on the exposure that
impacts workload is altered. See “Workload weight recalculation” on page
622.

Global workload assignment rules

In order to use weighted workload assignment, you need to implement global assignment rules that utilize the
Weighted Workload API commands.
In the base configuration, Guidewire provides a set of sample global assignment rules that use workload-aware
assignment methods. By default, Guidewire disables these rules in the base configuration. Enable these rules or
create your own to activate weighted workload assignment.

User assignment API

In the base configuration, ClaimCenter provides sample rules for user assignment within a group. The user
assignment API uses the default workload assignment strategy. You can customize both the methods and the
assignment strategies used, as needed. See “Weighted workload assignment strategies” on page 627.

626 chapter 42 Configuring weighted workload assignment

 Configuration Guide 9.0.5

Guidewire provides the following default rules in the base configuration:

• “Default group claim assignment rules” on page 627
• “Default group exposure assignment rules” on page 627

Default group claim assignment rules

Rule Set Rule Description
DefaultGroupClaimAssignmentRules DGC00500 – Balanced workl This rule is activated only if weighted workload assignment is
oad within group enabled in configuration.
Assigns the claim to the most suitable user, that is, the user
with the appropriate status, membership, and the lowest
workload. Uses the default assignment strategy, GroupUserWo
rkloadAssignmentStrategy.

Default group exposure assignment rules

Rule Set Rule Description
DefaultGroupExposureAssignmentRules DGC00500 – Balanced work This rule is activated only if weighted workload assignment
load within group is enabled in configuration.
Assigns the exposure to the most suitable user, that is, the
user with the appropriate status, membership, and the
lowest workload. Uses the default assignment strategy, Grou
pUserWorkloadAssignmentStrategy.

Weighted workload assignment strategies

Weighted workload assignment defines and uses dynamic assignment strategies to process and make decisions on
how workload-enabled assignable objects must be assigned. Assignment strategies include support for workload-
based and load factor-based assignment. Assignment strategies are located in
gw.assignment.workload.strategies.
In the base configuration, ClaimCenter contains four default assignment strategies for specific use with weighted
workload:
• GroupUserWorkloadAssignmentStrategy
• GroupUserByAttributeWorkloadAssignmentStrategy
• UserWorkloadAssignmentStrategy
• UserByAttributeWorkloadAssignmentStrategy
These four assignment strategies provide basic weighted workload assignment support, and you can choose to use or
modify to fit your own requirements. Alternately, you can use these as a reference if you decide to implement you
own strategies. These strategies fully support subgroup recursion.

GroupUserWorkloadAssignmentStrategy (Default)
GroupUserWorkloadAssignmentStrategy chooses from among a set of candidate GroupUser objects the group
user who has the lowest workload weight and is the winner of ties, if any. In the base configuration, this is the
default strategy used by the sample weighted workload assignment methods provided.

GroupUserByAttributeWorkloadAssignmentStrategy
GroupUserByAttributeWorkloadAssignmentStrategy is functionally identical to
GroupUserWorkloadAssignmentStrategy, but allows the caller to specify user attribute criteria to filter down the
list of candidate users before the decision-making process begins.

User assignment API 627

 Configuration Guide 9.0.5

UserWorkloadAssignmentStrategy
UserWorkloadAssignmentStrategy chooses from among a set of candidates the group user who has the least
weight and who is the winner of ties, if any. This selection is based on the absolute weight of the group user rather
than the group weight. See the Application Guide.
Unlike GroupUserWorkloadAssignmentStrategy, the user's calculated weight across the entire system is taken into
account rather than just within a particular group.

UserByAttributeWorkloadAssignmentStrategy
UserByAttributeWorkloadAssignmentStrategy is functionally identical to UserWorkloadAssignmentStrategy,
but allows the caller to specify user attribute criteria to filter down the list of candidate users before the decision-
making process begins.

Custom configuration
You can customize multiple components in the weighted workload assignment API. This topic includes examples on
configuring the default weight, weighted workload strategies, and classifications.

Configuring the default weight in code

The default weight is the workload weight assigned to assignable objects that do not match any existing weighted
workload classification. This default value can be defined globally in the configuration parameter,
WeightedAssignmentGlobalDefaultWeight, or in configuration code, as described in this topic. See “About
weighted workload configuration parameters” on page 621 for details on setting the global default weight.
You can specify the default weight for a class of workload weight-aware assignable objects. First, you need to
change the WorkloadProxy descendant class for the assignable class to override the global default weight property.

How to set the default weight

For example, to set the default weight of all claims to 15, modify the gw.assignment.workload.proxy.
ClaimWorkloadProxy class, as follows:

public class ClaimWorkloadProxy extends AbstractWorkloadProxy {

...
final public override property get DefaultWeight() : int {
return 15
}

...
}

The global default weight property defined in config.xml is retrieved and stored in the AbstractWorkloadProxy
class. Now, this value is overridden and the default workload weight for all claims without any matching workload
classification is set to 15.
Note: The value for the default workload weight must be a constant, non-negative integer.

Creating custom workload strategies

The determination of candidate assignees by weighted workload assignment is made by dynamic assignment
strategies that leverage the computed weights of assignable entities. In the base configuration, four basic assignment
strategies are included as examples. See “Weighted workload assignment strategies” on page 627.
You can create your custom weighted workload assignment strategy. It is recommended that your custom
assignment strategy class extend the gw.api.assignment.workload.strategies.
AbstractWorkloadAssignmentStrategy class. This is the base class specifically designed for workload strategy
customization.

628 chapter 42 Configuring weighted workload assignment

 Configuration Guide 9.0.5

Example - Creating a CustomWorkloadAssignmentStrategy

About this task

Consider a ClaimCenter user who is a member of several groups. You can create a custom weighted workload
assignment strategy that uses both the user’s group-level and system-level workload values.

Procedure
1. Create a custom assignment strategy class, for example:

public class CustomWorkloadAssignmentStrategy extends AbstractWorkloadAssignmentStrategy

{

protected override function fetchWorkload(groupUser : GroupUser) : int

{
// The weighted workload of the user is now user's workload for the group they are
// currently in + half their overall total system workload
return groupUser.AssignmentWeightedWorkload + (groupUser.User.TotalWorkload / 2)
}

2. Override the workload assignment method.

After you create the custom weighted workload strategy, you need to configure ClaimCenter to use the
strategy. You can do this in several different ways:
• Override the assignment method in the corresponding WorkloadDelegate entity. For example, override the
assignUserByWorkload() in ClaimWeightedWorkloadMethodsImpl, as follows:

public override function assignUserByWorkload(includeSubgroups:boolean, withinGroup:Group): boolean

{
var result : boolean
result = Owner.assignUserDynamically(new CustomWorkloadAssignmentStrategy(), withinGroup,
includeSubgroups)
return result
}

• Alternately, you can incorporate the new assignment strategy in a default group assignment rule for the
assignable entity. See “Workload weight computation” on page 625. The following example modifies the
default group claim assignment rule for weighted workload, DGC00500:

...
static function doAction(claim : entity.Claim, actions : gw.rules.Action) {

/*start00rule*/
...

var assignmentSuccess = claim.assignUserDynamically(new CustomWorkloadAssignmentStrategy(),

withinGroup, includeSubgroups)

...
}
}

Adding criteria to workload classifications

Weighted workload classifications specify criteria used to classify incoming assignable objects during assignment.
You can add and delete workload classifications using the Administration menu. See the Application Guide.
You can also customize workload classifications by adding additional criteria, which can be set up to either match or
not match the assignable object’s attributes.

Creating custom workload strategies 629

 Configuration Guide 9.0.5

In the base configuration, the following basic criteria are included in workload classifications:
• Claim Loss Type
• Claim Line of Business
• Claim Policy Type
In the base implementation, simple criteria mostly look at intrinsic attributes on the Assignable entity itself using
only equivalence. However, criteria are not restricted to these. Attributes for criteria can also be on subentities
pointed to by foreign keys, and criteria can include equivalence checks, range checks, or any other SQL expression
for an attribute. Note that the complexity of the criteria will affect scalability and performance.

Example - Add flag status to claim workload classification

It is possible to add your own custom criteria for workload classification.
This example includes the following steps:
• “Step 1. Add the new classification criterion” on page 630
• “Step 2. Add the new criterion to the implementation classes” on page 631
• “Step 3. Modify the ClaimCenter user interface” on page 632
• “Step 4. Test the new classification criteria” on page 632

Step 1. Add the new classification criterion

Before you begin

Before starting this procedure, review “Example - Add flag status to claim workload classification” on page 630.

About this task

This step adds the new criterion, ClaimFlagged, to the ClaimWorkloadClassification entity.

Procedure
1. If necessary, start Guidewire Studio.
At a command prompt, navigate to the ClaimCenter directory and enter:

gwb studio

2. Navigate to configuration→config→Extensions→Entity and open ClaimWorkloadClassification.eti.

3. Click the plus icon ( ), and select typekey from the drop-down choice list.
4. Enter the following values:

Name Value
name ClaimFlagged

typelist FlaggedType

nullok true

desc Flag status of the Claim.

Next steps
After completing this procedure, proceed to “Step 2. Add the new criterion to the implementation classes” on page
631.

630 chapter 42 Configuring weighted workload assignment

 Configuration Guide 9.0.5

Step 2. Add the new criterion to the implementation classes

Before you begin

Before proceeding, ensure that you complete “Step 1. Add the new classification criterion” on page 630.

Procedure
1. Add checks for the flag attribute in ClaimWorkloadClassificationMethodImpl, which is the
implementation of the WorkloadClassificationMethods delegate for the Claim entity.
a. In Studio, navigate to configuration→config→gsrc→gw→assignment→workload→classifications and open
ClaimWorkloadClassificationMethodsImpl.
b. Modify the isMatch and buildQuery methods in this file to include the new flag status criterion, for
example.

public override function isMatch(entity: Bean): boolean

{
...

// Check if the claim’s Flagged setting matches the predefined workload classification.
if (claim.Flagged != (WorkloadClassification as ClaimWorkloadClassification).ClaimFlagged)
{
return false
}
...
}

protected override function buildQuery(query: Query)

{
...
// Claim Flagged matches
query.compare(Claim#Flagged, Equals, (WorkloadClassification as ClaimWorkloadClassification).
ClaimFlagged)
...
}

2. Override ClaimWeightedWorkloadMethodsImpl, which is the implementation of WeightedWorkloadMethods

for the Claim entity.
a. In Studio, navigate to configuration→config→gsrc→gw→assignment→workload→entity and open
ClaimWeightedWorkloadMethodsImpl.
b. Add the new classification criterion to the isWorkloadAffected method, which is used to check if the
stored workload needs to be recalculated.

public class ClaimWeightedWorkloadMethodsImpl extends

AbstractWeightedWorkloadMethodsBaseImpl<Claim>
{
...
public override function isWorkloadAffected() : boolean
{
...
// Add new field to check if the Claim Flagged field has been changed
if (Owner.isFieldChanged(Claim#Flagged))
{
return true
}
...
}
}

Next steps
After completing this procedure, proceed to “Step 3. Modify the ClaimCenter user interface” on page 632.

Example - Add flag status to claim workload classification 631

 Configuration Guide 9.0.5

Step 3. Modify the ClaimCenter user interface

Before you begin

Before proceeding, ensure that you complete “Step 2. Add the new criterion to the implementation classes” on page
631.

About this task

This procedure modifies the ClaimCenter user interface to add a field for the claim’s flag status.

Procedure
1. In Studio, navigate to configuration→config→Page Configuration→pcf→admin→workload, and open
WorkloadClassificationDV.ClaimWorkloadClassification.pcf.
2. Double-click the WorkloadClassificationCommonInputSet to open it for editing.
3. Add a new Input widget below the AllClaimPolicyType widget, and enter the following properties (create
new display keys, where required):

Name Value
editable false

id AllClaimFlagStatus

label displaykey.Web.Admin.Workload.WorkloadClassification.ClaimFlagStatus

required true

value (assignmentClassification as ClaimWorkloadClassification).ClaimFlagged

4. Add a new Input widget below the ClaimPolicyType widget, and enter the following properties:

Name Value
editable true

id ClaimFlagStatus

label displaykey.Web.Admin.Workload.WorkloadClassification.ClaimFlagStatus

required true

value (assignmentClassification as ClaimWorkloadClassification).ClaimFlagged

Next steps
After completing this procedure, proceed to “Step 4. Test the new classification criteria” on page 632.

Step 4. Test the new classification criteria

Before you begin

Before proceeding, ensure that you complete “Step 3. Modify the ClaimCenter user interface” on page 632.

Procedure
1. Shut down ClaimCenter if it is running, and then restart it.
2. Log into ClaimCenter as a user with the appropriate permissions to view and edit classifications.
For example, log in as user su with password gw.
3. Navigate to Administration→Business→Settings→WeightedWorkload.
4. Select an active classification from the list.

632 chapter 42 Configuring weighted workload assignment

 Configuration Guide 9.0.5

The ClaimFlagStatus field is now shows in the Criteria section of the screen.
5. Click Edit.
The ClaimFlagStatus field is now editable.
6. Select a value from the drop-down list and click Update.
ClaimCenter displays a message informing you that you need to run the batch process to update existing, open
claims and exposures.
7. Click OK.

Result
The ClaimFlagStatus field now displays the value selected in Step 5.

Adding workload classification conditions

ClaimCenter provides the ability to create or customize non-restrictive criteria, also called conditions in the data
model, in classifications. Classification conditions can be restricted to specific condition filters. For example, the
ServiceTiers condition can be configured to filter by Gold customers only.
Assignable entities are only considered matches if they meet any of the condition filters defined on a classification.

IMPORTANT Custom conditions cannot be used with existing weighted workload classifications, if any. They can
only be applied to new classifications. See the Application Guide.

In the base configuration, ClaimCenter includes the following conditions:

• Exposures
• Claim Segments
• Claim Loss Causes
• Service Tiers

Example - Add a color condition to claim workload classification

This example creates a new weighted workload classification condition for the assignable entity, Claim. Assume that
a custom typelist, Color, contains such values as green, blue, and red.
The goal is create a new condition for claim classifications based on the color field.
This example includes the following steps:
• “Step 1. Add the new classification condition” on page 633
• “Step 2. Add the new condition filter” on page 634
• “Step 3. Add the new condition to the implementation classes” on page 635
• “Step 4. Modify the ClaimCenter user interface” on page 637
• “Step 5. Test the new workload classification condition” on page 639

Step 1. Add the new classification condition

Before you begin

Before proceeding, review “Example - Add a color condition to claim workload classification” on page 633.

About this task

This procedure create a new entity subtype of ClassificationCondition for the new condition. A weighted
workload classification can have one and only one instance of any ClassificationCondition.

Custom configuration 633

 Configuration Guide 9.0.5

Procedure
1. If necessary, start Guidewire Studio.
At a command prompt, navigate to the ClaimCenter directory and enter:

gwb studio

2. Navigate to configuration→config→Extensions→Entity and select New→Entity.

3. Create ColorCondition.eti, using the following metadata:

<?xml version="1.0"?>
<subtype xmlns="http://guidewire.com/datamodel"
desc="Color Classification Condition"
entity="ColorCondition"
final="false"
priority="1"
supertype="ClassificationCondition">
<implementsInterface
iface="gw.api.assignment.workload.classifications.conditions.ConditionMethods"
impl="gw.assignment.workload.classifications.conditions.ColorConditionMethodsImpl"/>
</subtype>

Note: The new subtype, ColorCondition, must implement the ConditionMethods interface in order to
work with the weighted workload system.
4. Add the new condition subtype to the ClassificationCondition typelist:
a. Navigate to configuration→config→Extensions→Typelist and open ClassificationCondition.ttx.
b. Click the plus icon ( ), and select typecode from the drop-down choice list.
c. Enter the following values:

Name Value
code ColorCondition

name Color Classification Condition

desc Classification condition filter by claim color

priority 1

retired false

Next steps
After completing this procedure, proceed to “Step 2. Add the new condition filter” on page 634.

Step 2. Add the new condition filter

Before you begin

Before proceeding, ensure that you complete “Step 1. Add the new classification condition” on page 633.

About this task

This procedure create a new entity subtype of ConditionFilter, which defines the filters that restrict the condition,
if selected. If a classification condition has a single condition filter, the condition is satisfied if the assignable's
properties match the criteria of the condition filter. If a classification condition has multiple condition filters, the
condition is considered satisfied if an assignable's properties match any of the condition filters.

Procedure
1. Navigate to configuration→config→Extensions→Entity and select New→Entity.

634 chapter 42 Configuring weighted workload assignment

 Configuration Guide 9.0.5

2. Create ColorConditionFilter.eti, using the following metadata:

<subtype xmlns="http://guidewire.com/datamodel"
desc="Classification condition filter by Color"
entity="ColorConditionFilter"
final="false" priority="1"
supertype="ConditionFilter">
<typekey
desc="Classification condition filter by Color"
name="Color"
nullok="false"
typelist="Color"/>

<index name="clr_cond_index_1"
desc="Prevents duplicate condition filters"
unique="true">
<indexcol name="ClassificationConditionID" keyposition="1"/>
<indexcol name="Color" keyposition="2" />
</index>
</subtype>

3. Add an array of the new filter subtype, ColorConditionFilter, to the new condition subtype,
ColorCondition, created in the previous step. The array’s values map to the filtered values for this custom
condition.

<array
arrayentity="ColorConditionFilter"
name="ConditionFilters"
cascadeDelete="true"
</array>

Next steps
After completing this procedure, proceed to “Step 3. Add the new condition to the implementation classes” on page
635.

Step 3. Add the new condition to the implementation classes

Before you begin

Before proceeding, ensure that you complete “Step 2. Add the new condition filter” on page 634.

About this task

This procedure creates a new class, ColorConditionMethodsImpl, that extends the
AbstractConditionMethodsImpl class.

Procedure
1. In ClaimCenter Studio, create a new class file in a logical place in your code structure. If necessary, first create
a package to hold your class file.
2. Enter the following class definition.

public class ColorConditionMethodsImpl extends AbstractConditionMethodsImpl

{

// Because of delegation, this MUST always be present.

public construct(filterSet : ColorCondition)
{
super(filterSet)
}

public override function filterQuery(query : Query)

{
var ColorCondition = (Condition as ColorCondition)

// This classification condition only works with claim classifications.

Example - Add a color condition to claim workload classification 635

 Configuration Guide 9.0.5

if (not (ColorCondition.WorkloadClassification typeis ClaimWorkloadClassification))

{
return
}

// Filter by specific claim loss causes, if requested.

if (not Condition.IncludeAll and ColorCondition.ConditionFilters.HasElements)
{
var Colors = ColorCondition.ConditionFilters.map(\ cause -> cause.Color)
query.and(\ andExp ->
{
query.compareIn("Color", Colors)
})
}
}

public override function isMatch(entity : Bean) : boolean

{
switch(typeof entity)
{
// If this entity is a Claim, then check if the claim's color matches the color specified by the
// condition filter.
case Claim:
return matchesColor(entity.Color)

// This is not a Claim, do nothing.

default:

// Ignore as if it didn't exist.

return true
}
}

public override property get HasFilters() : boolean

{
return not (Condition as ColorCondition).ConditionFilters.IsEmpty
}

public override function clearFilters()

{
var cond = (Condition as ColorCondition)
for (filter in cond.ConditionFilters)
{
cond.removeFromConditionFilters(filter)
}
}

private function matchesColor(Color : Color) : boolean

{
var result = false

// If "Include All" is not selected, go through all the condition filters attached to this
// classification condition. If any match, the condition is satisfied.
if (not Condition.IncludeAll)
{
var filterSet = (Condition as ColorCondition)
if (not filterSet.ConditionFilters.IsEmpty)
{
result = filterSet.ConditionFilters.hasMatch(\ lcf ->lcf.Color == Color)
}
}

// If "Include All" is selected, there is always a match.

else
{
result = true
}
return result
}

Next steps
After completing this procedure, proceed to “Step 4. Modify the ClaimCenter user interface” on page 637.

636 chapter 42 Configuring weighted workload assignment

 Configuration Guide 9.0.5

Step 4. Modify the ClaimCenter user interface

Before you begin

Before proceeding, ensure that you complete “Step 3. Add the new condition to the implementation classes” on page
635.

About this task

This procedure modifies the ClaimCenter user interface to add a field for the claim’s color status.

Procedure
1. In Studio, navigate to configuration→config→Page Configuration→pcf→admin→workload, and open
WorkloadClassificationDV.ClaimWorkloadClassification.pcf.
2. Add a new BooleanRadioInput widget and enter the following properties (create new display keys, where
required):

Name Value
editable true

falseLabel displaykey.Web.Admin.Workload.WorkloadClassification.RestrictedTo

id AllColors

label displaykey.Web.Admin.Workload.WorkloadClassification.AllColors

required true
trueLabel displaykey.Web.Admin.Workload.WorkloadClassification.All
value classification.ColorCondition.IncludeAll

3. Navigate to configuration→config→Page→Configuration→pcf→admin→workload→conditions.
4. Right-click and select NewPCFFile.
5. In the Filename field, enter ColorConditions. In the Filetype menu, select List View.
6. Add the following properties for ColorConditionsLV:

Name Value
Properties Tab
id ColorConditions

Required Variables Tab

name classification
type WorkloadClassification
Exposes Tab
valueType ColorConditionFilter
widget ColorConditionsLV

7. Add a RowIterator with the following properties:

Name Value
editable true

elementName color
toAdd classification.ColorCondition.addToConditionFilters(color)

Example - Add a color condition to claim workload classification 637

 Configuration Guide 9.0.5

Name Value
toRemove classification.ColorCondition.removeFromConditionFilters(color)
value classification.ColorCondition.ConditionFilters
canPick true
hideCheckBoxesIfReadOnly true

8. Add a Row widget. Add a RangeCell widget inside with the following properties:

Name Value
editable true

id ColorConditionFilter
label displaykey.Web.Admin.Workload.WorkloadClassification.ColorConditionFilter.Color
required true
value color.Color
valueRange typekey.Color.getTypeKeys(false)

9. Open WorkloadClassificationDV.ClaimWorkloadClassification.pcf. Under the AllColors widget

added in Step 2, add a ListViewInput widget and define the properties below.

Name Value
def ColorConditionsLV

id ColorConditions
labelAbove true

editable not classification.ColorCondition.IncludeAll

visible not classification.ColorCondition.IncludeAll

10. Add a Toolbar widget inside the ColorConditions widget created in Step 8. Add an IteratorButtons
widget inside the toolbar with the following properties:

Name Value
iterator ColorConditions.ColorConditionsLV

showAddConfirmMessage true
showRemoveConfirmMessage true

11. Navigate to configuration→config→Page→Configuration→pcf→admin→workload and open

NewWorkloadClassificationPopup.pcf
12. Select the Code tab and add the new condition:

switch(entityType)
{
case ClaimWorkloadClassification:
...
result.addToConditions(new ColorCondition())
...
}

13. Save your changes.

Next steps
After completing this procedure, proceed to “Step 5. Test the new workload classification condition” on page 639.
638 chapter 42 Configuring weighted workload assignment
 Configuration Guide 9.0.5

Step 5. Test the new workload classification condition

Procedure
1. Shut down ClaimCenter if it is running, and then restart it.
2. Log in to ClaimCenter as a user with the appropriate permissions to view and edit classifications.
For example, log in as user su with password gw.
3. Navigate to Administration→Business→Settings→WeightedWorkload.
4. Click AddClassification→AddClaimClassification to create a new classification.
5. Enter General information and required criteria. (See the Application Guide.)
The Colors field is now shows in the Criteria section of the screen.
6. Click Restricttoanyofthefollowing:, then select Add and choose a color from the drop-down menu.
7. Click Update, then OK.
8. Create a new claim with the requisite color selection.
9. Verify that ClaimCenter assigned the correct weight and classification to the claim.

Example - Add a color condition to claim workload classification 639

 Configuration Guide 9.0.5

640 chapter 42 Configuring weighted workload assignment

chapter 43

Working with catastrophe bulk

associations

This topic explains how to configure Catastrophe Bulk Associations batch job, which is a Gosu batch process.
See also
• Application Guide

Catastrophe bulk association configuration

You can optionally configure the Catastrophe Bulk Associations batch job.
The two files you need are:
• GWCatastropheEnhancement.gsx
• CatastropheClaimFinderBatch.gs
You first need to define your new method in the GWCatastropheEnhancement.gsx file and second, point to it from
the CatastropheClaimFinderBatch.gs file. The files are located in Studio.
Navigate to:
• configuration→Classes→gw→util→CatastropheClaimFinderBatch
• configuration→Classes→gw→entity→GWCatastropheEnhancement
The batch job, CatastropheClaimFinderBatch, for catastrophe bulk association is a subtype of
BatchProcessBase. It finds the claims that have been defined by the GWCatastropheEnhancement class and creates
a review for catastrophe activity (activity pattern code name catastrophe_review) if one does not already exist.
Note: In the base configuration, the batch process defines the areas by zones.

The GWCatastropheEnhancement class

This configurable entity finds all claims that might be a match to the defined catastrophe.

Working with catastrophe bulk associations 641

 Configuration Guide 9.0.5

It checks to see if the claim matches certain criteria. A match occurs if:
• The claim has not already been associated with a catastrophe
• The claim's loss date falls within the catastrophe's valid dates
• The catastrophe’s perils list the claim’s loss type and loss cause
• The claim does not have the catastrophe_review activity pattern with a skipped or complete status
The method findClaimsByCatastropheZone finds claims by zones. You can define the zone criteria. Examples
might be defined as: United States states, regions (southern California, Northern California), territories (western
territories such as California, Nevada, Oregon, and Washington).
Lastly, it returns all claims that match that criteria.

Catastrophes data model

ClaimCenter uses the following entities and typelists to add catastrophes to the database:

Entity or Typelist Description

Catastrophe The main entity contains all the information for each catastrophe. It uses these two array
CatastrophePeril (virtual array) entities to store each catastrophe’s perils and the states in which it is valid.
CatastropheZone (virtual array)

CatastropheType (typelist) Whether the catastrophe came from ISO data (iso) or was manually entered (internal).

Catastrophe configuration parameter

The MaxCatastropheClaimFinderSearchResults parameter has a default of 1000. It limits the number of claims
that can be found to match the criteria. For example, if there are 5000 claims that match, then the
CatastropheClaimFinder batch process gets the claims that match the criteria. It creates a Review for Catastrophe
activity for the first 1000. The next 1000 are processed during the next scheduled batch process and this process
continues until there are no more claims that meet the criteria.

642 chapter 43 Working with catastrophe bulk associations

chapter 44

Configuring the catastrophe

dashboard

This topic describes how to configure the Catastrophe Dashboard. This dashboard shows a map of policies and
claims for a catastrophe area and provides various kinds of information on claims and policies related to the
catastrophe. For information on the dashboard itself, including information on how to open it and use it, see the
Application Guide.
See also
• For information about catastrophes in general, see the Application Guide.
• For information on getting the Catastrophe Dashboard, including geocoding, up and running, see the System
Administration Guide.

Technical features of the catastrophe dashboard

This topic describes the technical features, including classes, PCF files, and web services, used to generate the
Catastrophe Dashboard.

Heat map generation and components

The browser generates the heat map graphic by combining map images from a map service with an overlay image
generated by the Guidewire server. The overlay image shows the map data points in color. The base configuration
can use the Bing Maps service. Map images and the overlay are organized into 256 x 256 pixel tiles.
Following is an example showing, left to right, the map tile, the overlay tile, and the combined image. By default,
the overlay image has a semitransparent background and is opaque where there is color. The default background
color is white and 30% opaque, which makes the map colors slightly washed out and makes the overlay colors stand
out better.

Configuring the catastrophe dashboard 643

 Configuration Guide 9.0.5

The components used to generate the heat map are:

• Map service – An external service that provides the map control and map images, such as Bing Maps.
• Geocoding service – An external service that provides the latitude and longitude for map points from the street
address. Geocoding is done separately through a batch process, which saves latitude and longitude information
with each geocoded address.
• Image generation code – Code that generates overlay tiles, responds to browser requests, and maintains graphic
state information.
• Data definition code – Code that defines data sets, queries, and the data associated with latitude and longitude
pairs.
For large amounts of data, there is a caching mechanism that reduces the amount of memory used and the load on
the database. Caching provides an in-memory buffer for the data set, one copy per cluster member, which is
shared between all users. Without caching, each user has an independent, in-memory buffer.
• HeatMapLegend.gs – Generates the image for the map legend.
• Map template – The map template, such as BingMap.gs, used to generate HTML and JavaScript sent to the
browser.

Server, browser, and service interactions

The following figure shows the interactions between the Guidewire server, the browser, and the external geocoding
and map services. The geocoding operation runs separately from catastrophe mapping.

644 chapter 44 Configuring the catastrophe dashboard

 Configuration Guide 9.0.5

Guidewire Server

Geocoding plugin and Street Addresses

batch process Geocoding Service
Latitude and Longitude

Stores results in database

Catastrophe Mapping Map

HTML and Control
JavaScript Map Service
Queries database for for web page Browser
each data set Map
Tile requests requests Microsoft Bing Maps
Map
Overlay tiles
Expanded tiles
Generates HTML and map template
JavaScript Updates to
zoom, center

Updated
Generates map legend selection
Selection
message

Locations need to be geocoded before they can be shown on the map. A geocoding service provides the latitude and
longitude from the street address, which are saved in the database. In ClaimCenter, a claim preupdate rule, CPU19000
- Geocode Catastrophe Claims, schedules geocoding if needed for a claim that is associated with a catastrophe.
Whenever the user requests a page containing a heat map, the following steps take place to show the web page:
1. For data sets that use caching, the first reference by any user loads the in-memory cache. Subsequent users
reuse the cache entry, one per cluster member. For data sets that do not use caching, the server queries the
database and puts the result into a map point buffer specific to that heat map. The buffer can be retained for
the life of the session.
2. The server substitutes values into the map template associated with BingMap.gs, such as the center point of
the map.
3. The server generates map legend images.
4. The server sends the browser the HTML for the screen. The map itself is in an <iframe>, which refers to the
substituted map template. The map template in turn refers to the map control on the map service website.
5. After the map control is loaded, it requests map and overlay tiles based on the size of the map in the browser,
the center point, and the zoom settings. HeatMapGenerator creates overlay tiles on demand from the map
point data in the buffer.
If the user pans or zooms in the map, the map control requests and displays the appropriate map and overlay tiles.
The map template sends the new zoom level and center point to the server immediately, preserving this state
information if the user navigates away from the map and later returns.
Whenever the user selects an area on the map by dragging a rectangle, the map template sends the coordinates of the
rectangle to the server immediately. HeatMapGenerator returns the SelectionMessage property, which the map
template displays in the screen in the PCF Input widget with the ID property equal to
HeatMapGenerator.SelectionMessageID. If HeatMapGenerator.RefreshUponSelection is true, the page is
refreshed to update the PCF file elements.

Principal heat map classes and files

You can see documentation for the methods and fields in ClaimCenter Studio by opening the classes they are in.
Alternatively, you can access the Gosu API documentation as described at the Gosu Reference Guide.

Technical features of the catastrophe dashboard 645

 Configuration Guide 9.0.5

Classes and template files not specific to the catastrophe heat map
The following classes and template files are available both in ClaimCenter and in PolicyCenter unless designated
ClaimCenter only.
• HeatMapGenerator.gs – Base class for defining a heat map. The fully qualified name is
gw.api.heatmap.HeatMapGenerator.
• HeatMapDataSet.java – Abstract class defining a data set, its query, and caching. The fully qualified name is
gw.api.heatmap.HeatMapDataSet.
• LatLong.java – Base class that holds the latitude and longitude for a map point. The fully qualified name is
gw.api.heatmap.LatLong.
• HeatMapCacheBase.java – Abstract base class to define a cache for a single data set (ClaimCenter only). The
fully qualified name is gw.api.heatmap.HeatMapCacheBase.
• HeatMapCacheEntry.java – Interface for a cache entry that has status information and blocking and non-
blocking load methods (ClaimCenter only). The fully qualified name is gw.api.heatmap.HeatMapCacheEntry.
• HeatMapCachePlugin.gs – Plugin class implementation that initializes caches (ClaimCenter only). The fully
qualified name is gw.api.heatmap.impl.HeatMapCachePlugin.
• BingMap.gs – Provides settings to use with Bing Maps. The fully qualified name is gw.api.heatmap.BingMap.
• HeatMapHTML.gst – HTML template for the map control and legend. The fully qualified name is
gw.api.heatmap.HeatMapHTML.
• BingMapJavaScript.gst – JavaScript template for passing parameters to BingMap.js. The fully qualified name
is gw.api.heatmap.BingMapJavaScript.
• BingMap.js – JavaScript code for the heat map. In ClaimCenter Studio, navigate in the Project window to
configuration→deploy→resources→javascript→heatmap and double-click BingMap.js to open it.
• HeatMapLegend.gs – Generates a map legend. The fully qualified name is gw.api.heatmap.HeatMapLegend.
• HeatMapColorMap.java – Interface or mapping from the count or value for a pixel to a color for a single data
set. Holds the legend labels. The fully qualified name is gw.api.heatmap.HeatMapColorMap.
• RangeColorMap.java – Color map that assigns a range of values to a color. For example 1-1000 is the first
color. The fully qualified name is gw.api.heatmap.RangeColorMap.

Classes and other files specific to the catastrophe heat map

The following classes, PCF file, and template file are available only in ClaimCenter. The classes are all in the
package gw.api.heatmap. You can navigate to these files in ClaimCenter studio by pressing Ctrl+N and entering
the file name without the extension. Alternatively, for the class and template files, you can navigate in the Project
window to configuration→gsrc and then to gw.api.heatmap.
• CatastropheSearchScreen.pcf – The Catastrophe Search screen. To edit this file, in ClaimCenter Studio,
navigate in the Project window to configuration→config→Page
Configuration→pcf→search→claims→CatastropheSearchScreen.
• CatastropheSearchCriteria.gs – GUI logic for the Catastrophe Search screen.
• CatastropheHeatMapViews.gs – Defines map views shown in the Catastrophe Search screen.
• CatastropheHeatMap.gs – This subclass of HeatMapGenerator is the main class that uses the various classes of
the map control. This class renders the map and provides the legend icons and tooltips.
• CatastropheClaimDataSet.gs – Subclass of HeatMapDataSet that provides claim data for the catastrophe heat
map. Uses CatastropheClaimHeatMapCache to share the buffer among all users.
• CatastropheClaimLatLong.gs – Subclass of LatLong representing a single claim on the heat map.
• CatastropheClaimHeatMapCache.gs – Subclass of HeatMapCacheBase that caches claim information
associated with a catastrophe for the catastrophe heat map.

646 chapter 44 Configuring the catastrophe dashboard

 Configuration Guide 9.0.5

• CatastrophePolicyLocationDataSet.gs – Subclass of HeatMapDataSet that provides policy location data for

the catastrophe heat map. Uses CatastrophePolicyLocationHeatMapCache to share the buffer among all users.
• CatastrophePolicyLocationLatLong.gs – Subclass of LatLong representing a single policy location on the
heat map.
• CatastrophePolicyLocationHeatMapCache.gs – Subclass of HeatMapCacheBase that caches policy location
information associated with a catastrophe for the catastrophe heat map.
• CatastropheHeatMapHTML.gst – HTML template that replaces HeatMapHTML.gst to provide support for two
legend icons.

Data sets and map data points

Heat map data is organized into one or more data sets, which represent points on the map with LatLong objects. The
base LatLong class has only the latitude and longitude. Generally, you need to subclass LatLong for each data set to
include additional data for filtering. For example, CatastropheClaimLatLong.gs includes the database ID of the
claim it represents, total incurred amount, and values used for filtering the claims that are shown on the map.
Heat map data points are stored in an in-memory buffer that improves performance for displaying the map. Since the
buffer can use a significant amount of memory, the best practice is to keep LatLong objects as small as possible. For
example, each CatastropheClaimLatLong object might be around 100 bytes, so 50,000 of these objects will use 5
megabytes.
Be sure to use database keys such as the claim ID to refer to entities rather than including the entities directly in
LatLong. Referring to a large object like a claim or a policy directly in a LatLong will increase memory usage for
the map and make the map point query take longer. Fields that are used only in tooltips or in the claim and policy
location tables do not need to be part of the LatLong object. The heat map code does separate queries by using the
claim ID or policy location ID to get this data.
To link data sets to your heat map, set HeatMapGenerator.DataSets to the list of data sets. Each active data set
uses 256 KB of temporary memory per user while generating overlay tiles.

Data sets and caching

Buffering for each data set can be done either with a simple per-user buffer or with a somewhat more complex per-
cluster member buffer that runs faster and uses less memory. The catastrophe heat map uses the per-cluster member
technique. A non-clustered server will use a single buffer for the data set.

Use per-user buffering

About this task

To use a per-user buffer for a data set:

Procedure
1. Put the database query in the mapPointQuery method in your subclass of HeatMapDataSet.
2. Do not override getMapPoints.
3. Optionally, set HeatMapGenerator.MapPointsTimeout, which has a default of 60 minutes, declared as
3,600,000 milliseconds. The buffer is released whenever the user logs out or whenever the buffer has not been
used for the specified interval. The heat map does a new query the next time the buffer is needed.

Use per-cluster member buffering

About this task

To use a per-cluster member buffer for a data set:

Technical features of the catastrophe dashboard 647

 Configuration Guide 9.0.5

Procedure
1. Use code similar to CatastropheClaimDataSet.gs and CatstropheClaimHeatMapCache.gs.
2. In the data set class, a subclass of HeatMapDataSet.java, do the following:
• Define the query in a static method in the data set, such as in the method findClaimsForCatastrophe.
• Define mapPointQuery to get the value for the cache entry.
• Define getMapPoints to refer to mapPointQuery.
• Do not set MapPoints in your code.
3. In the cache class, a subclass of HeatMapCacheBase.java, do the following:
• Set the timeout interval for the cache in the constructor call to super. The query is repeated after this
interval. If the cache value is not fetched for two intervals, the buffer is released.
• Define a load method that calls the query method in the data set class.
• Define createAndPreload to create the cache and optionally preload.
Preloading executes the query and loads the buffer whenever the server comes up. Otherwise, the first user to
reference the cache entry triggers the query, which might cause a long wait. Note that HeatMapCacheEntry
has status information and both blocking and non-blocking load methods.
4. In HeatMapCachePlugin.gs, add a line to the createCaches method that calls createAndPreload in the
cache class.

Use or add filters in a data set

About this task
The catastrophe heat map provides filters that enable the user to dynamically control the data that is included in the
map. The filters include the claim status, reported date, and assigned to group. For quicker updates whenever the
user changes the filter, the catastrophe heat map does the filtering from the map buffer contents rather than making
them part of the database query. Using the map buffer contents avoids having to do a new query for each filter
change. This approach is essential if using a per-cluster member buffer because all users on the cluster member
share the same buffer but can have different filter settings.

Procedure
1. Add the values needed for filtering to your LatLong subclass. To keep memory use down and make the filter
condition evaluate quickly, you can precompute complex filter conditions and reduce them to simple variables
saved in the LatLong subclass.
2. Add the necessary data to the query for your data set.
3. Define a filter method in the data set class. Because the filter is evaluated very frequently, make the function
as simple and quick as possible. Avoid lengthy loops and database queries.

Configuring the catastrophe heat map

The following configuration parameters are included in config.xml for the claim catastrophe heat map.
• HeatMapServiceTemplate – Select the map service to use with your heat maps, such as Bing Maps. Use the
fully qualified name of the associated Gosu template. For example, gw.api.heatmap.BingMap.
• HeatMapCredential – Specify the credential associated with heat maps. This is passed to the map service, such
as Bing Maps, and used in the HeatMapServiceTemplate.
• HeatMapPolicyLocationDemo – Enable the display of policy locations in the catastrophe heat map and the Policy
Locations tab in the Administration > Catastrophes screen. In the base configuration of ClaimCenter, this value is set
to false.

648 chapter 44 Configuring the catastrophe dashboard

 Configuration Guide 9.0.5

• CatastropheClaimHeatMapCacheRefreshSecs – Specify the interval at which the catastrophe heat map will
refresh claim information from the database. A smaller interval will provide more up-to-date information, but
will impact performance.
• CatastrophePolicyLocationHeatMapCacheRefreshSecs – Specify the interval at which the catastrophe heat
map will refresh policy location information from the database. A smaller interval will provide more timely
policy data, but will impact performance.

Common configuration use cases for heat maps

The following table lists typical configurations for heat maps and describes the configuration points for each one.

Configuration How to do it
Add a map view. In CatastropheHeatMapViews.gs:
1. Define a new instance of CatastropheHeatMapView similar to ClaimCountsView.
2. Add the view name to AvailableViews. If the view shows claims or policies or both, add the view
name to ClaimViews or PolicyLocationViews or both.
Show additional Modify the query in CatastropheSearchCriteria.performHeatMapPolicyLocationSearch and Policy
data in the policy LocationSearchResultsLV.pcf.
location table.
Modify tooltips. Modify the code in getToolTip in CatastropheHeatMap.gs. The tooltip is represented as an HTML
fragment.
Modify the The heat map shows the selection message whenever the user set the selection rectangle on the map,
selection message. such as, "56 claims and 112 policy locations selected".
The selection message varies depending on the map view. See the code for each map view in Selection
Message in CatastropheHeatMapViews.gs.

Change heat map In CatastropheHeatMapViews.gs, pass the heat map colors to the constructor for RangeColorMap,
colors and legend which initializes the labels appropriately. You can change the labels after calling the constructor, as is
labels. done for policyColorMap. Each data set is associated with one color map.
Show amounts on In the data set class, define a getWeight method that returns the amount. The amount must be an int
the map rather and be greater than or equal to zero. To show a marker on the map for a zero value, subclass RangeColor
than counts. Map and override getColorForValue as is done in AmountColorMap in CatastropheHeatMapViews.gs.

Set the map size. You can change the height by changing the setSize call in the constructor for CatastropheHeatMap.gs.
The HTML code specifies using all the available width. To use a specified width instead, change Catastro
pheHeatMapHTML.gst, replacing occurrences of the string "width:100%" in two places with "width:${ r
equestedWidth }px".

Other Refer to the Gosu API documentation for the relevant classes, as described at the Gosu Reference Guide.
configurations.

Advanced configuration topics for heat maps

The configuration techniques for heat maps described in this topic are advanced and are not a typical part of
configuration.

Extend Bing Map capabilities

About this task

You extend BingMap.js without modifying the JavaScript file itself. Extensions might use additional Microsoft
Bing capabilities such as showing push-pin markers or displaying a mini-map within the main map.

Configuring the catastrophe heat map 649

 Configuration Guide 9.0.5

Procedure
1. Create a new JavaScript file in the same directory as BingMap.js. You can subclass HeatMap and override
methods by following JavaScript conventions. Structure your file by using code similar to the following:

function MyExtension() { }
MyExtension.prototype = new HeatMap();
MyExtension.prototype.superclass = HeatMap;
MyExtension.prototype.constructor = MyExtension;

// put your code here, such as:

MyExtension.prototype.MyFunction() {
// your code here
};

heatMap = newMyExtension();

2. Subclass BingMap.gs and override javaScriptFileNames to include your JavaScript file after the
BingMap.js file.
3. Change the HeatMapServiceTemplate parameter in config.xml to use the fully-qualified subclass name.

Bing maps limitations

The Bing Maps control puts the International Date Line only at the left or right edge of the map. The date line
cannot be in the middle. This requirement has two effects:
• If the set of map points spans the date line, the points will be split up in an inconvenient or even misleading way.
• On large scale maps, the requested center point, such as from computing a bounding box for the map points,
might not appear in the center of the map.
Like most map services, Bing Maps is limited to showing points with latitudes between roughly -86 to +86 degrees,
which provides a square map of the world. The map projection from the sphere of the earth onto a plane puts the
north and south poles at infinity, which is impractical to display.

Working with a map service other than bing maps

You might be able to work with other mapping services by replacing BingMap.gs, BingMap.js, and
BingMapJavaScript.gst.
HeatMapGenerator by default uses map tiles that are 256 x 256 pixels in size. It accepts overlay tile requests that
use Bing-style or Google-style tile identifiers. Your code replacing BingMap.gs would need to return one of these
types of tile identifiers. The tile parameter in the HTTP request identifies which tile to return, as shown in the
following table:

Map Service Example General Form

Bing 0321.png [0-3]+\.png
Google tile_9_21_35.png tile_([0-9]+)_([0-9]+)_([0-9]+)\.png

Bing uses quad tree-based keys. At the lowest zoom level, the entire world, the map is divided into four tiles, each
identified by a single-digit number, 0..3. At the next zoom level, each tile is subdivided into four subtiles, identified
as 00, 01, 02, 03, 10, 11, 12, 13, and so on. See http://msdn.microsoft.com/en-us/library/bb259689.aspx for
a full description.
The numbers in the Google identifier are the zoom level, the x coordinate, and the y coordinate. See the following
web pages for a full description:
• https://developers.google.com/maps/documentation/javascript/maptypes#TileCoordinates
• https://developers.google.com/maps/documentation/javascript/maptypes
You might find it helpful to use Firefox and the Firebug debugger to develop the interface to a new map service.
Firebug can display all messages sent to and from the browser.

650 chapter 44 Configuring the catastrophe dashboard

 Configuration Guide 9.0.5

See also
• https://developer.mozilla.org/en-US/docs/Tools
• https://developers.google.com/web/tools/chrome-devtools/

Ajax-style extensions to the heat map

By overriding HeatMapGenerator.handleRequest and modifying or extending BingMap.js, you can add
additional Ajax-style interactions between the browser and the server to the heat map. See the handleRequest
method in CatastropheHeatMap.gs for an example. Be sure to include a call to super.handleRequest. The Gosu
API documentation has information on HeatMapGeneratorBase.handleRequest.
To send UTF-8 encoded text, use code like the following:

servletResponse.setHeader("Content-Type", "text/plain")
// use StreamUtil.toBytes() to handle UTF-8 characters correctly
servletResponse.getOutputStream().write(StreamUtil.toBytes(TextMessage))

See also
• Gosu Reference Guide

Advanced configuration topics for heat maps 651

 Configuration Guide 9.0.5

652 chapter 44 Configuring the catastrophe dashboard

chapter 45

Configuring duplicate claim and check

searches

You can configure Gosu templates to modify the search criteria for duplicate claims and checks. ClaimCenter checks
if there are any matching claims or checks to avoid duplication.

Understanding the Gosu templates

You can modify the search criteria for duplicate claims and duplicate checks in the Gosu templates in Studio.
Navigate to configuration→gsrc and then to gw.duplicatesearch. The folder contains the following templates:

Gosu template Description

DuplicateCheckSearchTemplate.gst Duplicate Check search

DuplicateClaimSearchTemplate.gst Duplicate Claim search

DuplicateCheckSearchTemplate Parameters
DuplicateCheckSearchTemplate takes three parameters:
• A DuplicateSearchHelper object, which provides utility methods for SQL construction.
• The Check to search for duplicates.
• A checkBeingCloned parameter. If the check is a clone of an existing check, this parameter contains the existing
check. The search avoids returning the existing check or any of its recurrences as a duplicate. Otherwise,
checkBeingCloned is null.

Configuring duplicate claim and check searches 653

 Configuration Guide 9.0.5

The DuplicateClaimSearchTemplate takes just two parameters:

• A DuplicateSearchHelper, which provides utility methods for SQL construction.
• The Claim to search for duplicates.

Use of Gosu in DuplicateCheckSearchTemplate

The following table describes how the template uses Gosu.

Area Gosu
Comments /*
This is a comment
that spans multiple lines.
*/
and
// This is a single-line comment.

Initializing a var myVar = 123

variable
Modifying a myVar = "new Value"
variable
Conditional The condition has to be a Boolean or the template does not compile. It is possible for a Boolean to be nu
expressions ll, in which case it is treated as false.

If conditional block if (myCondition) {

...
}

If-else conditional if (myCondition) {

block ...
}
else {
...
}

Duplicate claim search

In the base configuration, the Gosu template creates the SQL query for finding duplicate claims. If it finds any that
match the query, the user interface displays a list of claim IDs that match the claim that is being created. Displaying
this list enables the user to cancel the claim, if needed. If there are no matches, the user does not see any messages.
The query considers the claim to be a duplicate if one of the following conditions is satisfied.
• The claim has the same policy and has a loss date that is within plus or minus 3 days of the claim's loss date, or
• The claim's insured has the same name and the loss date is within plus or minus 3 days of the claim's loss date. If
there is no name, then the query searches for the company name.

Change search criteria for duplicate claim search

About this task
You can modify DuplicateClaimSearchTemplate or add any Gosu code to extend or modify the duplicate claim
search criteria. For example, you can change the length of time that the system checks for a duplicate claim.

654 chapter 45 Configuring duplicate claim and check searches

 Configuration Guide 9.0.5

Procedure
1. In class DuplicateClaimSearchTemplate, find the following functions:

function genClaimLossDateThreeDaysPriorParameter() : String {

return helper.makeParam("Claim.LossDate", claim.LossDate.addDays(-3))
}

and

function genClaimLossDateThreeDaysAfterParameter() : String {

return helper.makeParam("Claim.LossDate", claim.LossDate.addDays(3))
}

2. Change the numeric parameter for addDays, save your work, and restart the application server.

Duplicate check search

The Gosu template DuplicateCheckSearchTemplate, which is used to create the SQL query for finding duplicate
checks, verifies that the check has not already been created. If it finds any duplication, the user interface displays a
list of check IDs that match the check. Otherwise, the user does not see a message.
In the base configuration, the SQL query looks for checks written to the same person for the same amount on the
claim.
Check B is considered to be a duplicate of check A if:
• Check A and check B have the same PayTo field or check B has a payee with the same TaxID as one of the
payees on check A.
• Check A and check B are on the same claim.
• Check A and check B have the same gross amount.
• Check A and check B have the same currency.
• The service periods ServicePdStart to ServicePdEnd for check A and check B either overlap or are
incomplete. In the latter case, one or both fields are null.
• If Check A is created as a clone of another check, Check B must not be one of the following:
◦ The check from which A is being cloned
◦ Any of the check’s recurrences
See the code using checkBeingCloned.
If there are multiple payees, then the query looks at all contacts (through claim contact) that have the checkpayee
role, id=10011. The query next searches on the contact tax ID list passed in to the template.
Note: In a similar manner to DuplicateClaimSearchTemplate, you can customize
DuplicateCheckSearchTemplate to extend or modify the search criteria. See “Change search criteria for
duplicate claim search” on page 654 for details.

Duplicate check search 655

 Configuration Guide 9.0.5

656 chapter 45 Configuring duplicate claim and check searches

chapter 46

Configuring claim health metrics

This topic describes how to configure Claim Health Metrics. You can add a new tier, a high-risk indicator, or a new
claim metric. You can also add a new tier for additional granularity, like exposure tiers, which are more granular
than claim tiers. You can create a high-risk indicator for anything that is important to your business. For example,
you might add a high-risk indicator for property damage over a certain amount or perhaps a missed doctor’s
appointment for the workers compensation policy type. You might also create a new metric to measure time to get
an estimate completed for the personal auto policy type.
See Also
• the Application Guide to learn about this feature.
• the Application Guide to learn how to administer claim health metrics.

Adding a new tier

ClaimCenter calculates tiers as part of the claim health update process, which updates high-risk indicators, sets tiers,
and updates metrics. This process happens after ClaimCenter executes the pre-update rules.
In the base configuration, ClaimCenter logic assigns tier values based on various factors, including:
• Where in the line of business hierarchy the claim or exposure falls
• Incident subtype
• Complexity of entity
• Severity of incident
• Is the claim in litigation
• Is a vehicle a total loss
• Was there a fatality

Configuring claim health metrics 657

 Configuration Guide 9.0.5

The ClaimTier and ExposureTier Typelists

ClaimCenter defines tiers in the following typelists:
• ClaimTier
• ExposureTier
Within Studio, the ClaimTier and ExposureTier typelists define the tiers. ClaimCenter associates each tier with a
policy type (PolicyTypes) through the typecode category (Categories).
The following graphic illustrates these concepts. Notice that the ClaimTier typelist associates the claim tier value of
LowSeverity with the personal auto policy type (as well as with others.)

Gosu Logic that Implements Tiers

After you create a new tier in Studio, you must add Gosu logic to set your new tier on claims and exposures.
ClaimCenter calls the following enhancement methods to update the claim and exposure tiers:
• setClaimTier
• setExposureTier
You must alter these enhancement methods to set your new tier if the conditions are right. It is not possible to assign
new tiers without editing GWClaimTierEnhancement or GWExposureTierEnhancement.

Example - Adding a new tier to ClaimCenter

To add a new tier, create the tier first in Studio. Then, define its associated limit values in the ClaimCenter
Administration tab user interface. Finally, implement tier with Gosu logic.
Perform the following steps to add a new tier:
1. “Step 1 – Associate a new tier value to a typelist in Studio” on page 659
2. “Step 2 – Define target values for the new tier in ClaimCenter” on page 659
3. “Step 3 – Edit the tier enhancement Gosu code in Studio” on page 659

658 chapter 46 Configuring claim health metrics

 Configuration Guide 9.0.5

Step 1 – Associate a new tier value to a typelist in Studio

Before you begin

Before starting this procedure, review “Step 1 – Associate a new tier value to a typelist in Studio” on page 659.

Procedure
1. Navigate in the Studio Project window to configuration→config→Extensions→Typelist.
2. Select either the ClaimTier. or the ExposureTier typelist extension, depending on your purpose. Double-click your
choice to open it in the typelist editor.
3. In the typelist editor, create a new tier value typecode and associate it with policy types by adding categories
from the PolicyType typelist to the new typecode.
4. Save your work and exit Studio.

Next steps
After you complete this procedure, continue to “Step 2 – Define target values for the new tier in ClaimCenter” on
page 659.

Step 2 – Define target values for the new tier in ClaimCenter

Before you begin

Before starting this procedure, complete “Step 1 – Associate a new tier value to a typelist in Studio” on page 659.

About this task

Repeat this process for each metric and each policy type for which you want to set metric limits.

Procedure
1. Open ClaimCenter and log in as a user who is an administrator.
2. In the Administration tab, navigate to Business Settings→Metrics and Thresholds in the left Sidebar.
3. Choose the policy type for the metric limit you want to set.
4. Click Edit and select the new tier from the drop-down list for the metric whose limit you are setting.
5. Enter the target values for the new tier on that metric and policy type.
6. Click Update.

Next steps
After you complete this procedure, continue to “Step 3 – Edit the tier enhancement Gosu code in Studio” on page
659.

Step 3 – Edit the tier enhancement Gosu code in Studio

Before you begin

Before starting this procedure, complete “Step 2 – Define target values for the new tier in ClaimCenter” on page
659.

About this task

In Studio, edit the Gosu code to add logic to assign new tier values to claims or exposures.

Procedure
1. Navigate in Studio to configuration→gsrc, and then to gw→entity.
Example - Adding a new tier to ClaimCenter 659
 Configuration Guide 9.0.5

2. Open either the GWClaimTierEnhancement or GWExposureTierEnhancement enhancement file.

3. Edit the enhancement file to add logic for assigning new tier values.
It is possible for your logic to make decisions based on values from any of the following typelists:
• PolicyType
• CoverageType
• CoverageSubType
• ExposureType

Adding a high-risk indicator

It is possible to create a new high-risk indicator. The general steps are that you must create the icon, create a subtype
of ClaimIndicator, and add the implementation code.

IMPORTANT Guidewire strongly recommends limiting the number of indicators used for any one line of business.
Overuse of indicators lessens the overall impact to end users. Additionally, Guidewire designed the Claim Summary
screen with the expectation that few, if any, claims will have more than four or five indicators. If the number of
indicators per claim exceeds this expectation, Guidewire recommends that you revisit the Claim Summary screen
design and determine if it needs to be modified. Otherwise, important claim information can appear farther down
the screen, necessitating additional scrolling.

Note: Each time you create a new subtype, you must modify the PCF files to show the new indicator in the info bar
and on the Claim Status screen. If the indicator implements the standard On property and has an icon, it can also
appear on the Claim Summary screen. That screen relies on the generic indicator interface and can show the indicator
automatically, whenever it is on.

Example – Add a high-risk indicator

In general, the steps in creating a new high-risk indicator include the following:
• Creating the high-risk indicator icon
• Creating a subtype of ClaimIndicator
• Adding implementation code that uses the new indicator
Perform the following steps to add a new high-risk indicator:
1. “Step 1 – Create the high-risk icon” on page 660
2. “Step 2 – Add a new ClaimIndicator subtype in Studio” on page 661

Step 1 – Create the high-risk icon

Before you begin

Before starting this procedure, review “Example – Add a high-risk indicator” on page 660.

About this task

The first step in creating a new high-risk indicator is to create the screen icon.

Procedure
1. Create the icon image by using a third-party graphics program.
2. Manually copy the image file into the following location in the ClaimCenter installation directory:

modules/configuration/webresources/themes/shared/resources/images/app

660 chapter 46 Configuring claim health metrics

 Configuration Guide 9.0.5

3. If the ClaimCenter server is running, stop it.

4. Open a command prompt in the ClaimCenter installation directory.
5. Run the following command:

gwb compile

6. Restart the server.

Next steps
After completing this procedure, continue to “Step 2 – Add a new ClaimIndicator subtype in Studio” on page 661.

Step 2 – Add a new ClaimIndicator subtype in Studio

Before you begin

Before starting this procedure, complete “Step 1 – Create the high-risk icon” on page 660.

About this task

This procedure extends the ClaimCenter data model by adding a new subtype of the entity ClaimIndicator.

Procedure
1. In the Studio Project window, navigate to configuration→config→Extensions→Typelist and double-click
ClaimIndicator.ttx to view the existing typecodes.
In the base configuration, they are:
• ClaimIndicator
• LitigationClaimIndicator
• FatalityClaimIndicator
• LargeLossClaimIndicator
• CoverageInQuestionClaimIndicator
• SIUClaimIndicator
• FlagClaimIndicator
• SubrogationClaimIndicator
You can add your custom subtype to this typelist.
2. Define a new entity subtype. The supertype you choose depends on the type of indicator that you want.
a. Navigate to configuration→config→Extensions and right-click Entity.
b. Click New→Entity.
c. Enter the name ExampleClaimIndicator and click OK.
d. In the text tab, enter the following entity definition:

<?xml version="1.0"?>
<subtype xmlns="http://guidewire.com/datamodel" desc="Litigation"
entity="ExampleClaimIndicator" final="false" priority="1"
supertype="ClaimIndicator">
<implementsInterface
iface="gw.api.claim.indicator.ClaimIndicatorMethods"
impl="gw.claim.indicator.ExampleClaimIndicatorMethodsImpl"/>
</subtype>

The iface attribute defines the interface that the subtype implements. The implementsInterface
element must be present, and the impl class must be your own implementation class. Use the package
gw.claim.indicator and your new SubtypeNameMethodsImpl class, which you define later.
Example – Add a high-risk indicator 661
 Configuration Guide 9.0.5

3. Stop and restart Studio to automatically create a typecode for the new subtype to the ClaimIndicator typelist.
You configure the secondary attributes of the typecode– Name, Description, and Priority.
For example, navigate to configuration→config→Extensions→Typelist and open ClaimIndicator.ttx, and then
click the new typecode to edit it.

Code Name Description Priority Retired

ExampleClaimIndicator Example Example Claim Indicator 4 false

This step enables you to set up a possibly localized name and priority for the indicator. The Name attribute is
the name you want to show in the user interface for this type of indicator. The Priority determines the order in
which the indicators appear on the screen.
4. Implement your new SubtypeNameMethodsImpl class. Your class can implement the
ClaimIndicatorMethods interface. If, instead, you extend the ClaimIndicatorMethodsImpl class, you get
the following conveniences:
• Automatic handling of the icon. You need to specify only the string name of your indicator icon when you
call the constructor of ClaimIndicatorMethodsImpl.
• The method setOn(newValue: boolean), which you can use to set the IsOn flag and the WhenOn field of the
indicator.
Following is an example of an implementation:

package gw.claim.indicator
uses gw.api.claim.indicator.ClaimIndicatorMethodsImpl
class ExampleClaimIndicatorMethodsImpl extends ClaimIndicatorMethodsImpl {
/**
* Constructor, called when an indicator is created or read from the database
*/
construct(inIndicator : ExampleClaimIndicator) {
super(inIndicator, "indicator_icon_litigation.gif") // Passes in name of indicator icon
}
/**
* Update, sets the indicator on if the the claim litigation status is "litigated"
* or "complete"
*/
override function update() {
var status = Indicator.Claim.LitigationStatus
setOn(status == "litigated" or status == "complete")
// Calls setOn to set both IsOn and WhenOn fields
}
/**
* Text label, returns the description of the current claim litigation status
*/
override property get Text() : String {
return Indicator.Claim.LitigationStatus.Description
}
/**
* Hover text returns the names of any open matters,
* or a special label if there are none.
*/
override property get HoverText() : String {
var openMatters = Indicator.Claim.Matters.where(
\ m -> not m.Closed).orderBy(\ m -> m.CreateTime)
return openMatters.Count > 0
? openMatters.map(\ m ->
m.Name).join(displaykey.Web.LitigationClaimIndicator.MatterNameSeparator)
: Indicator.Claim.LitigationStatus.DisplayName
}
}

5. After implementing the class required by your claim indicator entity, you can regenerate the data dictionary to
ensure that the new entity has the correct definition.
At a command prompt, navigate to ClaimCenter and enter:

gwb genDataDict

662 chapter 46 Configuring claim health metrics

 Configuration Guide 9.0.5

6. Add a new info bar element to the ClaimInfoBar PCF file. You must add the element explicitly, even though
the required element is standard.
For example, for a new indicator type called ExampleClaimIndicator:
a. Navigate to configuration→config→Page Configuration→pcf→claim→ClaimInfoBar.
b. Drag an InfoBarElement from the Toolbar on the right and drop it on the InfoBar. If you see a message asking
if you want to edit the file, click Yes.
c. Click the new InfoBarElement and set the following properties:

Property Value
id ExampleClaimIndicator

icon Claim.ExampleClaimIndicator.Icon

tooltip Claim.ExampleClaimIndicator.HoverText

visible Claim.ExampleClaimIndicator.IsOn

7. Add a new modal input set called ClaimIndicatorInputSet.ExampleClaimIndicator.pcf.

The Claim Status screen uses this input set to display the details of your indicator. This screen iterates through
all indicators on the claim and displays an input set for each indicator. It handles the indicator as a require
argument to the input set. You can put whatever you want in the input set. It is helpful to follow a style similar
to that of the input sets for the existing indicators, which tend to be fairly small. If you make your input set too
large, it can drastically change the layout of the Claim Status screen.
ClaimCenter displays the indicator input sets by subtype order. An indicator with subtype set to priority 1
appears before an indicator with subtype set to priority 3.
For example:
a. Navigate to configuration→config→Page Configuration→pcf→claim→summary→indicator
b. ClaimIndicatorInputSet.LitigationClaimIndicator.
c. Right-click ClaimIndicatorInputSet.LitigationClaimIndicator and click Copy.
d. Right-click the indicator folder and click Paste.
e. Name the new PCF file ClaimIndicatorInputSet.ExampleClaimIndicator.pcf.
f. Click ClaimIndicatorInputSet.ExampleClaimIndicator to open it in the editor.
You now have a new input set with a set of widgets. You can modify this input set to meet your needs.

Adding a new claim metric

It is possible to create a new claim metric. The general steps are to create a subtype of an existing metric and then
add the implementation code.

IMPORTANT If you retire a metric limit by using Gosu or the database without replacing it with a new limit, new
claims will continue to use the retired metric limit.

Example – Add a new claim metric

Perform the following steps to add a new claim metric:
1. “Step 1 – Add a new claim metric in Guidewire Studio” on page 664
2. “Step 2 – Extend the TimeBasedMetric class” on page 665
3. “Step 3 - Update claim metric rule” on page 666
4. “Step 5 – Run claim health batch processing” on page 667

Adding a new claim metric 663

 Configuration Guide 9.0.5

Step 1 – Add a new claim metric in Guidewire Studio

Before you begin

Before starting this procedure, review “Example – Add a new claim metric” on page 663

About this task

This procedure extends the ClaimCenter data model by adding a new subtype of the entity ClaimMetric. One way
to add a subtype is to extend one of the pre-supplied claim metric classes.

Procedure
1. In the Studio Project window, navigate to configuration→config→Metadata→entity and review the following claim
metric entities:
• DecimalClaimMetric.eti
• IntegerClaimMetric.eti
• MoneyClaimMetric.eti
• PercentClaimMetric.eti
• TimeBasedClaimMetric.eti
Your selection depends on the type of quantity the metric is tracking.
Note: You can add a direct implementation of ClaimMetric rather than subtyping one of the pre-supplied
claim metric classes. Doing so is appropriate if the value of the metric does not fall into any of the pre-
supplied types—integer, decimal, percent, money, or time based. It is also possible to add arbitrary new data
fields to your subtype if your metric needs them.
2. Create a new metric based on TimeBasedMetric as follows:
a. In Studio, navigate to configuration→config→Extensions, right-click Entity, and select New→File.
b. Enter the file name ExampleClaimMetric.eti and click OK.
c. In the Text tab, enter the following entity definition.
Note: If you copy and paste the following code, delete any leading spaces before the first line of code.

<?xml version="1.0"?>
<subtype desc="Example Claim Metric" entity="ExampleClaimMetric"
final="false" priority="1" supertype="TimeBasedClaimMetric">
<implementsInterface
iface="gw.api.metric.MetricMethods"
impl="gw.claim.metric.general.ExampleClaimMetricMethodsImpl"/>
<implementsInterface
iface="gw.api.claim.metric.RecalculateMetrics"
impl="gw.claim.metric.general.ExampleClaimMetricMethodsImpl"/>
</subtype>

• You must use the first implementsInterface element and specify your own implementation class for the
impl attribute. The implementation class name is, by convention, SubtypeNameMethodsImpl.
• The second implementsInterface element makes it possible for the Recalculate Claim Metrics batch job
to recalculate this metric. You rarely need to implement RecalculateMetrics. If you do so, you must also
implement this interface in the class you specify in the impl attribute, which is the same class in the
previous implementsInterface element. For more information, see “Step 2 – Extend the TimeBasedMetric
class” on page 665.
• Save the file.
3. Close Studio, and then restart it to automatically add a typekey for your new subtype to the ClaimMetric
typelist.
4. In Studio, navigate to configuration→config→Extensions→Typelist and double-clicking ClaimMetric.ttx.

664 chapter 46 Configuring claim health metrics

 Configuration Guide 9.0.5

Note: If you do not see the new typecode in the ClaimMetric typelist, there is probably an error in your
entity definition. Check your definition and make sure that it is correct.
5. Click the new typecode to edit it. Set the following values:

Code Name Description Priority Retired

ExampleClaimMetric Example Example Claim Metric 4 false

The Name of the typecode element is the name that appears in the user interface for this type of metric. You
can localized this name. The Priority determines the ordering of the metric in the Claim Metrics user interface.
It appears after any metrics with priority less than 4 and before any with priority more than 4.
After completing this procedure, continue to “Step 2 – Extend the TimeBasedMetric class” on page 665.

Step 2 – Extend the TimeBasedMetric class

Before starting this procedure, complete “Step 1 – Add a new claim metric in Guidewire Studio” on page 664.
1. Extend one of the following classes:
• gw.api.claim.metric.DecimalClaimMetricMethodsImpl
• gw.api.claim.metric.IntegerClaimMetricMethodsImpl
• gw.api.claim.metric.MoneyClaimMetricMethodsImpl
• gw.api.claim.metric.PercentClaimMetricMethodsImpl
• gw.api.claim.metric.TimeBasedClaimMetricMethodsImpl
Note the following:
• If you are subtyping from one of the entities listed in “Step 1 – Add a new claim metric in Guidewire Studio” on
page 664, you can extend a matching Gosu class. For example, if you extended TimeBasedClaimMetric, then
you need to implement TimeBasedClaimMetricMethodsImpl.
• If your metric does not match any of these classes, you can extend one of the MetricMethodsImpl classes. To
choose one of these classes, press Ctrl+N and search for MetricMethodsImpl.
1. If you extend one of the claim metric classes, you must create a class with a constructor and override the
updateMetricValue method. The following class extends the TimeBasedClaimMetricMethodsImpl class and
implements the RecalculateMetrics interface. If you implement this interface, you must also override the
recalculate method:

package gw.claim.metric

uses gw.api.claim.metric.TimeBasedClaimMetricMethodsImpl
uses gw.api.metric.MetricUpdateHelper
uses gw.api.claim.metric.RecalculateMetrics
uses java.util.Date
@Export
class ExampleClaimMetricMethodsImpl extends TimeBasedClaimMetricMethodsImpl
implements RecalculateMetrics {
construct(exampleClaimMetric : ExampleClaimMetric) {
super(exampleClaimMetric, ClaimMetricCategory.TC_OVERALLCLAIMMETRICS)
}
override function updateMetricValue(helper : MetricUpdateHelper) : Date {
Metric.StartTime = Metric.Claim.ReportedDate
handleClaimStateChange()
return null
}
override function recalculate() : Date {
var result = recalculateValue()
updateMetricLimitReachedTimes()
return result
}
}

Example – Add a new claim metric 665

 Configuration Guide 9.0.5

This example is time-based. It extends the provided TimeBasedClaimMetricMethodsImpl class, which gives
access to time-specific fields like Metric.StartTime. The class also provides the handleClaimStateChange
method for updating the metric state if the claim opens or closes. Additionally, the recalculate method
updates the limit reached times if the new metric value has caused it to pass a limit. The method returns the
time when you want to metric to be recalculated.
Note: This example is somewhat artificial, because as long as the metric is open, its value changes with time. You
typically use RecalculateMetrics with a metric that is not time-based and whose value might change due to
some known future event that does not affect the database. For example, a metric that provides a count of overdue
activities must be recalculated by the batch job when an existing activity becomes overdue.

IMPORTANT All implementation classes must have a constructor that takes one parameter of the actual metric
type. The implementsInterface mechanism requires this constructor because the object is created whenever the
metric is read from the database.

1. If you need to do something only as the metric is first created, you can add a constructor like the following
one:

construct(exampleClaimMetric : ExampleClaimMetric) {
super(exampleClaimMetric, ClaimMetricCategory.TC_OVERALLCLAIMMETRICS)
if (exampleMetric.New) {
// Do your initialization here
}
}

The constructor also determines the category of the metric and hands it as a parameter to the superclass
constructor.
The updateMetricValue method evaluates the current state of the associated claim and updates the metric
accordingly. The method in the example is simple. Other update methods might compute more complex
values. You can use the MetricUpdateHelper passed to the update method to find out if relevant entities
changed. For example:

if (helper.updateContainsChangesOfType(History)) {
// A history event was added, updated or removed
// You can access the changed items by using
// Metric.Bundle.getAllModifiedBeansOfType(History).
}

After completing this procedure, continue to “Step 3 - Update claim metric rule” on page 666.

Step 3 - Update claim metric rule

Before starting this procedure, complete “Step 2 – Extend the TimeBasedMetric class” on page 665.
If you want to apply the new claim metric or indicator to claims that already have metrics, you must enable
ClaimException rule CER04000 Recalculate claim metrics.
1. In the Studio Project window, navigate to configuration→config→Rule Sets→Exception→ClaimExceptionRules.
2. Select the check box for CER04000 Recalculate claim metrics to activate it.
This rule verifies that all claim metrics, exposure metrics, and claim indicators are created on every claim. If
there are any missing metrics or indicators in a claim, ClaimCenter adds them to the claim.
3. Save your work in Studio.
4. If ClaimCenter is running, stop it.
5. Open a command prompt in the ClaimCenter installation directory, and enter the following command.

gwb genDataDict

This action regenerate the data dictionary and ensures that your data model changes are correct.

666 chapter 46 Configuring claim health metrics

 Configuration Guide 9.0.5

6. At the command prompt, enter the following command to restart ClaimCenter:

gwb runServer

After completing this procedure, continue to “Step 4 – Add limits for metric type” on page 667.

Step 4 – Add limits for metric type

Before starting this procedure, complete “Step 3 - Update claim metric rule” on page 666.

IMPORTANT Before users start creating new claims or processing of existing claims begins, you must perform the
following steps in each environment to which you deploy the new configuration. For example, environments might
include a development environment, UAT, and production.

1. Log into ClaimCenter as an administrator, such as user name su with password gw.
2. Click the Administration tab and then navigate to Business Settings→Metrics and Thresholds in the left sidebar.
3. Click Edit and on the Claim Metric Limits tab, add limits for your new metric type. For more information, see the
Application Guide.
After completing this procedure, continue to “Step 5 – Run claim health batch processing” on page 667.

Step 5 – Run claim health batch processing

Before starting this procedure, complete “Step 4 – Add limits for metric type” on page 667.

IMPORTANT Before users start creating new claims or processing of existing claims begins, you must perform the
steps in each environment to which you deploy the new configuration. For example, environments might include a
development environment, UAT, and production.

This procedure runs Claim Health Calculations batch processing to populate metrics on claims that have never had
any metrics. Running this batch process does not add the new metric to claims that already have metrics.
1. Log into Guidewire ClaimCenter using an administrative account.
2. Press Alt+Shift+T to open the Server Tools tab.
3. Click Batch Process Info in the left sidebar.
4. Run the Claim Health Calculations batch process.
5. If you have any metrics that implement RecalculateMetrics, set Recalculate Claim Metrics batch process to run
on a regular basis.
You can also manually run this process for testing.
6. If you enabled the Recalculate Claim Metrics rule previously in “Step 3 - Update claim metric rule” on page 666,
click Work Queue Info in the left sidebar. Then run the ClaimException batch process writer to begin processing
existing claims and adding the new metric.
For more information on batch processes, see the System Administration Guide.

How to configure days in metrics calculations

It is possible to make claim metric calculations using calendar days or business days. In the base configuration, the
default is business days, which ClaimCenter specifies in the following classes:
• TimeBasedClaimMetricMethodsImpl
• TimeBasedExposureMetricMethodsImpl
In the superclasses, the date calculation is defined as follows:

/**
* Returns the calculator used by the metric for date calculations.

Example – Add a new claim metric 667

 Configuration Guide 9.0.5

* Default is BUSINESS.
*/
override property get DateCalculator() : DateCalculator
{
return ExtensionInterfaces.DateCalculatorExtensions.BUSINESS_DAYS
}

You will need to override the DateCalculator method in the subclasses, as needed, to specify calendar days as the
calculation parameter, as shown in the following example.

override property get DateCalculator() : DateCalculator

{
return DateCalculators.CALENDAR
}

The following subclasses of TimeBasedClaimMetricMethodsImpl are relevant to metrics calculations for claims.
• DaysLastViewedByUserClaimMetricMethodsImpl
◦ DaysLastViewedBySupervisorClaimMetricMethodsImpl
◦ DaysLastViewedByAdjusterClaimMetricMethodsImpl
• DaysInitialContactWithInsuredClaimMetricMethodsImpl
• DaysOpenClaimMetricMethodsImpl
• TimeToFirstPaymentClaimMetricMethodsImpl
Similarly, the following subclasses of TimeBasedExposureMetricMethodsImpl are relevant to metrics calculations
for exposures.
• DaysOpenExposureMetricMethodsImpl
• TimeToFirstPaymentExposureMetricMethodsImpl
• DaysInitialContactWithClaimantExposureMetricMethodsImpl

668 chapter 46 Configuring claim health metrics

chapter 47

Configuring recently viewed claims

You can configure recently viewed claim information in the Claim tab. You use this tab to either create a new claim,
search for a specific claim, or access a recently viewed claim from a list. In the base configuration, the lines of
business are configured to show the claim number and the insured’s name. However, an exception is the workers’
compensation line of business. In the base configuration, this line of business displays the claim number and the
claimant’s (injured worker’s) name. This makes sense as a carrier can insure a large-sized employer and have many
workers’ compensation claims from different employees under that one employer. In another example, one adjuster
can be working on multiple claims for one insured in the commercial lines of business. It is even possible that all the
open claims for one adjuster could belong to the one insured. Therefore, seeing the insured’s name is not as
informative as seeing the claimant’s name.
This topic explains how to configure the recently viewed claims list that is used in the Claim tab.

Add a loss date to the recently viewed claim list

In the Claim tab, a carrier often finds it useful to see recently viewed claims that include other information, such as
the loss date. This example describes how to add the loss date to recently viewed claims for the Auto loss type.
This example uses the following files:
• ClaimRecentView.etx
• ClaimRecentView.en
The current format in ClaimCenter is the claim number and the insured’s or claimant’s (for workers compensation
claims) display name.
1. In Guidewire Studio, open ClaimRecentView.etx.

2. Click the sign to add a new viewEntityColumn and enter the following values.

Name Value
name LossDate

path LossDate

Configuring recently viewed claims 669

 Configuration Guide 9.0.5

1. Navigate to configuration→config→Localizations→en_US and open the display.properties file.

Search (Ctrl+F) for the ClaimSessionState display key. If the ClaimSessionState.DateLabel does not
exist, add it as follows:
Java.ClaimSessionState.DateLabel = {0} {1} {2}
2. Open file ClaimRecentView.en.

3. Click the icon to add a name using the following values:

Name Value
Name LossDate

Entity Path ClaimRecentView.LossDate

1. Modify the Gosu logic to add the loss date.

The following example codes changes include:
• Extending the display length so that information is not truncated in the tab.
◦ Adding the Auto loss type so that the change affects only commercial and personal auto.
◦ Adding the loss date format.
2. Save your work and exit Studio.
3. To ensure that ClaimCenter reflects the changes that you made to the data model, do the following.
a. If you are currently running your application, shut down the server.
b. Restart the server.
In the Claim tab, you now see the loss date included in the list of recently viewed auto claims.

670 chapter 47 Configuring recently viewed claims

chapter 48

Configuring incidents

There are several different approaches to creating and editing exposures based on incidents in the user interface.

Implicit incidents
After creating a new exposure, a new incident is also created, and the exposure and incident remain bound together
from that point. All exposures require a reference to an incident. In cases where the user cannot select an incident,
such as the exposure type GeneralDamage, the incident is created implicitly.
Use the New Exposure and Exposure Detail screens to edit a mix of exposure and incident fields. For example, the
description field, which is part of an incident, displays like a normal exposure field.
There are two exposure screens in the New Claim wizard and in the main claim file that can create implicit incidents.
For example, NewExposure.pcf has the following Variables definitions for Exposure and Incident:
• Exposure
◦ name – Exposure
◦ type – Exposure
◦ initialValue – Claim.newExposureWithNoIncident(
◦ CoverageType, CoverageSubtype, Coverage)
• Incident
◦ name – Incident
◦ type – Incident
◦ initialValue – Exposure.initializeIncident()
Code is also defined for these two variables in NewClaimWizard_NewExposurePopup.pcf:
• Exposure
◦ name – Exposure
◦ type – Exposure
◦ initialValue – Wizard.addExposureWithNoIncident(

Configuring incidents 671

 Configuration Guide 9.0.5

◦ Claim, Coverage, CoverageType, CoverageSubtype)

• Incident
◦ name – Incident
◦ type – Incident
◦ initialValue – Exposure.initializeIncident()
The exposure is initially created without an incident, and the enhancement method Exposure.initializeIncident
then sets the incident up. In the base configuration, this method, defined in ExposureUI.gsx, uses the
Exposure.newIncident method to create a new, implicit incident for the following exposure types:
• EmployerLiability
• GeneralDamage
• LossOfUseDamage
• LostWages
• PersonalPropertyDamage
• WCInjuryDamage
See also
• “Explicit incidents” on page 672
•
• “LOB typelists and incidents” on page 563

Explicit incidents
For injury, vehicle damage, and property damage exposure types, incidents can be created ahead of time on the Loss
Details screen. They are explicitly linked with an exposure on the New Exposure or Exposure Detail pages.
On the ClaimCenter screen, you see a drop-down list of all suitable incidents. You can also create a new incident.
For these exposure types, the Exposure.initializeIncident method attempts to pre-fill the incident picker. You
can always configure his picker and change the pre-filled value. For information on how this method is used to
create implicit incidents, see “Implicit incidents” on page 671.

Choosing an Incident Type

Choose the best existing incident of the correct type. An incident is considered better if:
• It has not already been used for another exposure.
• It contains a vehicle or property on the policy.
If you are unable to choose an incident by using the previous criteria, choose the incident by using display name sort
order. If there are no incidents of the appropriate type it is left as null, so you must create a new one using the New...
menu item.
After adding a new exposure type and possibly an incident type, you have to decide whether to use the implicit or
explicit incident approach. It is best to have a single approach for a single incident type, or the user interface
becomes confusing. The only exception to this rule is quick claim configuration, described in the next topic.
See also
• “Implicit incidents” on page 671

Quick claim configuration

You can use some of the quick claim pages to create a claim and one or more exposures all on one page. If the page
creates the exposure immediately, use the implicit incident style to initialize the exposure. Otherwise, use two steps
to set up the exposure.The first one creates the incident and the second associates it with the exposure. Since anyone

672 chapter 48 Configuring incidents

 Configuration Guide 9.0.5

who uses a quick claim page is always creating an immediate exposure, use the quick claim configuration to create
the exposure and incident together. Edit the contents, but not the association between them, on the quick claim page.

Injured contact role

The Injured contact role is the injured party associated with an injury incident. With a claim open, navigate to Loss
Details→General. As part of the loss details on this screen, there is a list of Injuries. Each injured party in this list links
to an instance of an injury incident.

Contact role constraints

ClaimCenter has constraints that can be applied to contact roles. For example, there must be one and only one
claimant on a claim. A claimant on a claim must be a person, but a claimant on an exposure can also be a company.
Incidents are one of the types of entities that can use roles.
You define role constraints in entityroleconstraints-config.xml.
See also
• “Defining role constraints” on page 681

The Incident data model

At the domain level, Gosu can work with incident types and their properties. The following topics described some
Gosu properties and methods that are exposed on the Claim, Exposure, and Incident entities to make working with
incidents easier.
• “Incidents and the Claim Entity” on page 673
• “Incidents and the Exposure entity” on page 673
• “The Incident entity” on page 674
• “Incidents and the Coverage entity” on page 674

Incidents and the Claim Entity

Claim has an Incidents array that contains all the incidents on the claim. Claim also provides special arrays for
access to incidents of a particular type. These arrays have names of the form IncidentTypesOnly. For example,
VehicleIncidentsOnly, IncidentsOnly, and FixedPropertyIncidentsOnly.
These arrays are typed—VehicleIncidentsOnly has type VehicleIncident[]—so you can access all the incidents
of a particular type without casts. They do not return any incidents that are subtypes of the named type. For example,
Claim.Incidents and Claim.IncidentsOnly are different arrays. Claim.Incidents returns all the incidents on
the claim, no matter what their type. Claim.IncidentsOnly returns only the incidents that actually have the type
Incident and are not subtypes of Incident. The Only arrays are read-only. They do not provide methods for adding
or removing incidents.
It is advisable to use the Claim.IncidentTypesOnly arrays when dealing with incidents because you are usually
interested only in incidents of a particular type. If you use Claim.Incidents, you see implicit incidents as well as
the ClaimInjuryIncident. These incidents do not show up in the user interface and do not represent incidents in
the real world, but exist only to hold data for the exposure or claim. These kinds of incidents are filtered out of the
Claim.IncidentTypesOnly arrays.

Incidents and the Exposure entity

Exposure has an accessor for each incident type, allowing typesafe access to incident subtypes. For example,
Exposure.VehicleIncident returns a VehicleIncident and can be used as follows:

Exposure.VehicleIncident.DriverRelation = "self"

Explicit incidents 673

 Configuration Guide 9.0.5

The type safe incident accessor returns null if the exposure's incident is not the named type. So
Exposure.VehicleIncident returns null on a BodilyInjuryDamage exposure. After you are reading the property,
you can use a supertype of the actual incident type. For example, Exposure.MobilePropertyIncident can be used
to read mobile property incident fields on a VehicleDamage exposure, because MobilePropertyIncident is a
supertype of VehicleIncident. But if you set the property, you must use an incident of the exact type because all
exposures of a particular type must have incidents of a particular type. For example:

Exposure.ExposureType = "GeneralDamage"
var Incident = new Incident(Exposure)
var VehicleIncident = new VehicleIncident(Exposure)
Exposure.Incident = VehicleIncident // fine
Exposure.MobilePropertyIncident = VehicleIncident // throws exception

Incident properties are actually on the exposure's incident, so the syntax for setting an incident property is:

Exposure.Incident.Description = "whatever"

There are also some exposure methods for creating or selecting incidents for an exposure. These methods are mainly
intended for use by the user interface code when a new exposure is created.

The Incident entity

Incident has a few methods that are mainly used in PCF files. The isUsedByExposure method is used to disable the
remove incident button if an incident is in use. The getNonExclusiveRoles and
getSuitableNonExclusiveRolesFor methods are useful when constructing a list view for adding contacts and
roles to an incident (exclusive roles can be handled by a simple picker).

Incidents and the Coverage entity

Coverage has an findOrCreateIncident method that is used when creating a new exposure if that exposure has a
specific coverage.
This method is used in the initializeIncident library method.

Entities and typelists related to incidents

The InjuryIncident subtype is the preferred incident type for all injury-related exposure types (see the
ExposureType typelist).
Each InjuryIncident provides the following fields with the given type:
• Description : String
• GeneralInjuryType : InjuryType
• DetailedInjuryType : DetailedInjuryType
• MedicalTreatmentType : MedicalTreatrmentType
• LostWages : Boolean
• Impairment : percentagedesc
• BodyParts, an array of BodyPartDetails entities.
The BodyPartDetails entity provides the following fields:
• PrimaryBodyPart : BodyPartType
• DetailedBodyPart : DetailedBodyPartType
• CompensabilityDecision : CompensabilityDecision
• CompensabilityDecisionDate : datetime
• CompensabilityComments : varchar
674 chapter 48 Configuring incidents
chapter 49

Configuring special handling

instructions

Special handling instructions are a set of additional steps in claims processing that can be associated with accounts
or service tiers.
This topic explains how to configure special instructions, specifically service tiers, email notifications, and claim
headline comments.
The following configuration tasks can be performed:
• Create and enable new service tiers.
• Configure contact roles for special handling notifications.
• Configure Instruction Types and Instruction Categories for claim headline comments.
See also
• Application Guide

Creating service tiers

Service tiers represent level of customer service to be provided to a group of policies. Service tier information is
typically included in both the policy administration system (PAS) and ClaimCenter. In the base configuration, the
ServiceTier attribute is on the Account entity in PolicyCenter, and the CustomerServiceTier attribute is on the
Policy entity in ClaimCenter.
ClaimCenter provides three service tiers as samples in the base configuration:
• Platinum
• Gold
• Silver
The Platinum and Gold tiers are active, and the Silver is not enabled. These are provided merely as examples and
have no viable functionality associated with them.

Configuring special handling instructions 675

 Configuration Guide 9.0.5

Special handling data model

Service tiers are represented by the CustomerServiceTier typelist, which is an attribute on the Policy entity. The
following diagram illustrates the relationships in the SpecialHandling data model.

Special Handling Data Model

SpecialHandling

AccountSpecialHandling CustomerServiceTier
Account SpecialHandling
CustomerServiceTier

«typelist»
Account CustomerServiceTier
AccountNumber
AccountHolder
SpecialHandling Policy
CustomerServiceTier

Legend

A relates to B
A B
B relates to A

A B A is a subtype of B

Add service tiers

About this task
You can add service tiers in ClaimCenter using a two-step process. Service tiers in ClaimCenter must be mapped to
the corresponding fields in the PAS for them to be utilized appropriately. Discuss with your integration developer
before creating new service tiers.

Procedure
1. Start ClaimCenter Studio.
2. In the Studio Project window, navigate to configuration→config→Extensions→Typelist, double-click and open the
CustomerServiceTier.ttx typelist.
3. Right-click and select Add new... typecode and enter the values for your new service tier.
For example, enter the following values:

Code Name Description Priority Retired

Bronze Bronze Customer The service for Bronze customers. -1 false

676 chapter 49 Configuring special handling instructions

 Configuration Guide 9.0.5

Note: Restart the server before proceeding to enable the service tier.
4. In the Administration menu, click Administration→Special→Handling→Service Tiers and select AddServiceTier to add
the tier.

Next steps
See also
• the Application Guide

Configure email notifications

About this task
Special handling instructions include automated email notifications that can be triggered based on claim indicator or
financial events. Email notifications can be sent to single or multiple recipients, or contacts with roles on the claim.
You can configure the claim contact roles that are available for email notifications using the steps below:

Procedure
1. Start ClaimCenter Studio.
2. In the Studio Project window, navigate to configuration→config→Extensions→Typelist, double-click and open the
ContactRole.ttx typelist.
3. Select the SpecialHandling typefilter.
4. Add the contact role to the typefilter, as follows:
a. Right-click, select Addnew... and click IncludeIntoFilter....
b. Select the desired claim contact role and click Finish.
The role now appears in the SpecialHandling typefilter list.
5. Restart the application server.

Result
You can now see the recently added contact role in the ContactRole field of the NewAutomated Notification screen.

Next steps
See also
• Application Guide

Configure claim headline comments

About this task
Claim headline comments are note-like comments shown in the claim headline and are created under the
OtherInstructions section of the Special Handling menu. Claim headline comments can be created based on policy
types, instruction categories and instruction type.
You can configure the instruction categories and types available in the Other Instructions screen. You will need to
create extensions for the InstructionCategory and InstructionType typelists in Studio, as shown in the
following steps.

Procedure
1. Start ClaimCenter Studio.

Configure email notifications 677

 Configuration Guide 9.0.5

2. In the Studio Project window, navigate to configuration→config→Metadata→Typelist, right-click the

InstructionCategory.tti typelist and select NewTypelistExtension.
3. In the Typelist Extension window, click OK to accept the default name, InstructionCategory.ttx.
The typelist extension file opens in the typelist editor.
4. In the typelist editor, right-click InstructionCategory and select Addnew... typecode.
5. Enter the code, name, and description.
6. Select Save.
7. Repeat the previous steps to extend the InstructionType.tti typelist in a similar manner to the
InstructionCategory typelist.
8. In the resulting InstructionType.ttx typelist, right-click to add either a new typecode or a category to one of
the existing typecodes.
9. Click Save.
10. Restart the application server.

Configure activity patterns for special handling

About this task
Special handling includes the creation of automated activities, based on predefined claim indicator or financial
events. You must specifically configure an activity pattern for special handling.

Procedure
1. Log into Guidewire ClaimCenter using an administrative account.
2. Navigate to Administration→Business→Settings→ActivityPatterns.
3. Do one of the following:
• Select AddActivityPattern to create a new activity pattern.
• Select an existing activity pattern and click Edit.
4. In the Category field, select Handling Instructions.

Result
This action marks the activity pattern for special handling and makes it available for selection in the SpecialHandling
menu.

678 chapter 49 Configuring special handling instructions

chapter 50

Configuring roles and relationships

This topic describes how to customize and configure contact roles and relationships in a Guidewire application. It
supplies some common examples you can use to configure your own installation. The roles discussed in this topic
apply only to contacts. Another type of role is the user role, which is a collection of permissions that enable a user to
view or edit various ClaimCenter or ContactManager objects.
See also
• For information on user roles and security related to accessing contacts in the Address Book, see the Guidewire
Contact Management Guide.
• For information on roles in general and on roles used in ClaimCenter, see the Application Guide.

Adding contact roles

The contacts in the system have associations with your business entities that depend on the functions they perform
for the business entities. For example, a Person can be associated with a claim as the insured party. In ClaimCenter,
these associations are defined as roles that contacts perform for claims, evaluations, incidents, exposures,
negotiations, matters, and policies. For example, a defense attorney performs a role in a matter that involves
litigation on a claim.
The ClaimCenter base configuration has a number of predefined contact roles. Your business might require unique
associations that would necessitate adding your own roles.

IMPORTANT Do not add a contact role to a custom entity. ClaimCenter does not support this configuration.

Example - Add a contact role

About this task
To add a contact role, you define an association between a role and a contact type, and then associate that role to an
entity.

Configuring roles and relationships 679

 Configuration Guide 9.0.5

Procedure
1. Add the role to the ContactRole typelist.
2. Define the following two types of constraints for the role in the entityroleconstraints-config.xml file.
• A contact role constraint indicates the contact subtype, such as Person or Company, to which the role
applies.
• An entity role constraint defines which roles an entity can use. It can also optionally specify whether a role
is required, exclusive, or prohibited, and conditions that apply to use of the role by the entity.
3. After completing work on the typelist and the XML file, you must rebuild and redeploy ClaimCenter.
Guidewire also recommends that you regenerate the Data Dictionary. In any case, Guidewire requires that you
regenerate the Data Dictionary for production deployments.

Next steps
See also
• “About contact roles” on page 680
• “Defining role constraints” on page 681
• “About entity role constraints” on page 682

Policy contact roles

Some contact roles are used specifically for policy contacts. You define them in the ContactRole typelist and you
give them appropriate constraints, just as you do any other contact roles. However, one difference is that a policy
contact role must have a corresponding former role defined for it.
If you add a contact role, you must also define a former role in case the user refreshes the policy and a policy
contact’s role changes from its original setting. In this case, if you do not define a former role, ClaimCenter
generates the following error:
No 'former' role configured for rolename
For example, in the ContactRole typelist, there is both an agent role and a corresponding formeragent role. The
formeragent role is also included in the type filter formerpolicyrole. Additionally, formeragent is declared in
ContactRoleCategory.ttx as a ContactRole category under the typecode former.
Finally, there are entity role constraints defined in entityroleconstraints-config.xml for agent and
formeragent:
• agent – Defined as a contactRoleCode element for the entityType elements Evaluation and Policy.
• formeragent – Defined as a contactRoleCode element for the entityType elements ems, Exposure, and
Policy.
Follow this general pattern whenever you create a new policy contact role and its former role.
Note: The entity role constraints you define for the new roles will not necessarily be exactly the same.
See also
• “About contact roles” on page 680
• “Defining role constraints” on page 681

About contact roles

The ContactRole typelist defines the available roles. For example, the following contact role definition creates a
mattermanager role:

Code Name Description

mattermanager Legal Case Manager Legal Case Manager

680 chapter 50 Configuring roles and relationships

 Configuration Guide 9.0.5

Many of the codes in the ContactRole typelist, such as activityowner, claimant, insured, vendor, and venue,
are internal to the application. The typelist editor lists the internal codes with a Code field that has a gray
background. The editor does not let you remove these typecodes.
You can also look up the ContactRole typelist in the Data Dictionary. The dictionary marks the Internal column true
for the codes that Guidewire defines as internal.

IMPORTANT In general, if you remove any typecodes from any typelist, first ensure that the code is not in use in
the application instance in a PCF file. Also verify that another typelist does not reference that typecode.

Contact roles exist in relation to entities. You define which entities use a role by referencing the role from the
entityroleconstraints-config.xml file.
See also
• “View or edit the ContactRole typelist” on page 681

View or edit the ContactRole typelist

Procedure
1. Open Guidewire Studio, if it is not already running.
a. Open a command prompt and navigate to the ClaimCenter installation directory
b. Enter the following command:

gwb studio

2. In the Project window, navigate to configuration→config→Extensions→Typelist and double-click ContactRole to

open it in the typelist editor.

Next steps
See also
• “Defining role constraints” on page 681

Defining role constraints

You configure the relationships between entities and roles in the entityroleconstraints-config.xml file. In this
file, you define which Contact subtypes can use a role. Additionally, you configure which contact roles are
available to which entities, such as a Claim or an Exposure entity. You must define the contact role codes that you
use in entityroleconstraints-config.xml in the ContactRole typelist.
Only the entities supplied in the base configuration and configured on ClaimContactRole can use roles. These
entities are Claim, Evaluation, Exposure, Incident, Matter, Negotiation, and Policy.
To view or edit the file, in ClaimCenter Studio, press Ctrl+Shift+N and enter entityroleconstraints-config.xml, and then
press Enter.
See also
• “About contact roles” on page 680

About contact role constraints

The ContactroleTypeConstraint element defines the Contact subtype to which the role belongs. For example, a
mattermanager is of type Person, as the following code defines it:

<ContactRoleTypeConstraint contactRoleCode="mattermanager" contactSubtype="Person"/>

About contact roles 681

 Configuration Guide 9.0.5

In this example:
• The contactRoleCode specifies the role’s code name, which is mattermanager.
• The contactSubtype identifies the subtype to which the role belongs, which is Person.
If each of your contact roles uses only one Contact subtype, ClaimCenter can ensure that the role is assigned to the
correct contact type. Additionally, your PCF configuration is relatively simple. However, if a role uses more than
one subtype, you must configure an ExceptionConstraint. This configuration helps to ensure that selection of this
role does not result in assignment of the wrong contact type. Even with this configuration, it is possible to have the
wrong type assigned to the role, as explained in the following claimant role description.
The base configuration roles are all set up to use one subtype, with a single exception, the claimant role, which can
be both a Person and a Company. To specify the additional subtype, this configuration uses the
ExceptionConstraint tag, as shown in the following example:

<ContactRoleTypeConstraint contactRoleCode="claimant" contactSubtype="Person">

<ExceptionConstraint contactSubtype="Company" entityRef="Exposure"/>
</ContactRoleTypeConstraint>

The ExceptionConstraint tag ensures that the claimant role is always performed by a Person except if using an
Exposure entity. In that case, a Company can also perform this role. As the system starts up, it calculates the nearest
supertype of the two subtypes and effectively assigns the claimant role to that supertype. For the claimant role, the
nearest supertype is Contact.
Note: Calculating the nearest supertype can still result in assignment of an incorrect contact type unless you
account for this possibility in your configuration. The possibility of incorrect type assignment is one reason
Guidewire encourages you to associate a contact role with a single subtype.

About entity role constraints

The EntityRoleConstraint block defines the associations between roles and entities. An EntityRef tag designates
an entityType, an entity that can use contact roles, and contains one or more RoleRef tags that define contact roles
for the entity. By default, there are no constraints on the entity’s use of the role. In this example, a Claim can use or
not use the InsuredRep, LawEnfcAgcy, OccTherapist, PhysTherapist, claimantdep, and codefendant roles
without restriction.
The following example from the base configuration entityroleconstraints-config.xml file shows uses of
configuration tags:

<EntityRoleConstraint>
<EntityRef entityType="Claim">
<RoleRef contactRoleCode="FirstIntakeDoctor">
<RoleConstraint constraintType="Exclusive"/>
</RoleRef>
<RoleRef contactRoleCode="InsuredRep"/>
<RoleRef contactRoleCode="LawEnfcAgcy"/>
<RoleRef contactRoleCode="OccTherapist"/>
<RoleRef contactRoleCode="PhysTherapist"/>
<RoleRef contactRoleCode="PrimaryDoctor">
<RoleConstraint constraintType="Exclusive"/>
</RoleRef>
<!-- some definitions skipped for brevity -->
<RoleRef contactRoleCode="claimant">
<RoleConstraint constraintType="Exclusive"/>
<RoleConstraint constraintType="Required">
<AdditionalInfo propertyName="LossType" value="WC"/>
</RoleConstraint>
<RoleConstraint constraintType="Prohibited">
<AdditionalInfo propertyName="LossType" value="AUTO"/>
<AdditionalInfo propertyName="LossType" value="PR"/>
<AdditionalInfo propertyName="LossType" value="GL"/>
</RoleConstraint>
</RoleRef>
<RoleRef contactRoleCode="claimantdep"/>
<RoleRef contactRoleCode="codefendant"/>
...

682 chapter 50 Configuring roles and relationships

 Configuration Guide 9.0.5

</EntityRef>
</EntityRoleConstraint>

How to add constraints to a contact role

You can constrain the relationship between an entity and a role by putting a RoleConstraint tag in the RoleRef
block. As shown in the <EntityRoleConstraint> example, the FirstIntakeDoctor, PrimaryDoctor, and
claimant contact role codes use this tag. The following constraintType values are possible:

Exclusive At most one contact associated with the entity can fulfill this role. It is possible that the entity does not have
anyone in this role.
Required This entity must have at least one contact in this role.
Prohibited None of the contacts for this entity can have this role. Often qualified with an AddtionaInfo tag to limit the
application of this constraint.
ZeroToMore This entity can have no contact, one contact, or many contacts that use this role, which is the default behavior
for a role that has no constraint types defined. Do not use this constraintType with Exclusive.

If you want to ensure that an entity has exactly one contact that fills a particular role, add two RoleConstraint tags
to the RoleRef—an Exclusive and a Required constraint.
In the previous <EntityRoleConstraint> example, the FirstIntakeDoctor role has an Exclusive constraint.
This constraint means that a FirstIntakeDoctor is not required for a Claim, but if a FirstIntakeDoctor is needed
for the Claim, only one can be assigned. The same is true for a PrimaryDoctor.

How to set limitations on constraints

It is possible to further refine a constraint on a contact role with AdditionalInfo tags. An AdditonalInfo tag
specifies a propertyName and value that must exist for the system to apply the constraint. In the previous
<EntityRoleConstraint> example, a claimant has three constraints:
• Exclusive
• Required
• Prohibited.
The Exclusive constraint applies to all allowable types of claims, limiting the number of claimants on these claims
to no more than one. The Required and Prohibited constraints have AdditionalInfo tags that restrict their
application. If the LossType for a claim is WC (workers compensation), then the claimant role is Required and must
be filled. If the LossType for a claim is AUTO, PR (property), or GL (general liability), the claimant role is
Prohibited and cannot be filled at all.
For auto, property, and general liability claims, the claimants do not exist at the claim level. For these types of
claims, you cannot add a claimant until you have exposures. The claimant contacts are owned by the exposures, not
by the claim itself, because each exposure can have a separate claimant. For workers compensation claims, there is
always a single claim, regardless of the number of exposures. Therefore, a workers compensation claim can (and
must) own a contact with the role of claimant.

How to resolve conflicts in role constraint configuration

It is possible to specify role constraints that can result in conflicts between constraints. For example, take the
following fictional configuration:

<EntityRef entityType="Claim">
<RoleRef roleCode="claimant">
<RoleConstraint constraintType="Required">
<AdditionalInfo propertyName="LossType" value="AUTO"/>
</RoleConstraint>
<RoleConstraint constraintType="Prohibited">
<AdditionalInfo propertyName="State" value="CA"/>
</RoleConstraint>

About entity role constraints 683

 Configuration Guide 9.0.5

</RoleRef>
</EntityRef>

If, at run time, a Claim has a LossType of AUTO and a State value of CA, there is a conflict. Auto claims require a
claimant, but according to this constraint definition, in California, a claimant is prohibited on a claim.
ClaimCenter resolves this conflict by calculating constraint precedence and using the constraint with the highest
precedence. The following list shows the order of constraint precedence from highest to lowest:
• Prohibited
• Exclusive & Required
• Exclusive
• Required
• ZeroToMore
In the previous example, Prohibited has higher precedence than Required, so the claimant role cannot be
assigned on this auto insurance claim in California.
Note: A workers compensation claim can (and must) own a contact with the role of claimant.
See also
• “How configuring roles impacts entity data and types” on page 684
• “Add a new contact role: example” on page 688
• “Relationships between contacts” on page 690

How configuring roles impacts entity data and types

Creating or changing a role configuration affects the data definition of the associated entity. Whenever ClaimCenter
generates the entity’s type information, it must include information for the role. Depending on how you configure a
contact role, the application generates either a simple property or an array property on the entity. The system also
provides methods on the entity for manipulating roles in general and for specific properties.
Note: If a role is prohibited for an entity, the system does not generate a property or any methods for the role.

Generated role methods

ClaimCenter generates a number of methods on the entities related to a role. You use these methods to manipulate
and gather information about roles and contacts. The following table lists some of the methods available on the
Claim entity:

Method Description
getClaimant(): Contact Returns the claimant for a claim or, in the case of an
exposure that has a claimant, for the exposure.
getClaimants(): Contact[] Returns all claimants for a claim, such as an Auto claim
that has multiple exposures.
getClaimantNames(): String[] Returns names of all claimants on a claim as well as
those on related exposures.
getClaimContactsForAllRoles(): ClaimContact[] Gets all ClaimContact entities for all roles.
getContactByRole(role: ContactRole): Contact Gets the contact serving in an exclusive role. If you call
this method on a role that is not exclusive, it throws an
exception.
getContactsByRole(role: ContactRole): Contact[] Gets the directly-related Contact objects in the given
role. This method returns only contacts attached directly
to the entity. It does not return contacts that are
attached to the entity’s subobjects.

684 chapter 50 Configuring roles and relationships

 Configuration Guide 9.0.5

Method Description
getContactsByRoles(roles: ContactRole[]): Contact[] Gets the directly related Contact objects with at least
one of the given roles. It is does not return contacts
related to subobjects.
getContactsExcludeRole(role: ContactRole): Contact[] Gets the directly related Contact objects that are not in
the given role. This method returns only contacts
attached directly to the entity. It does not return
contacts attached to the entity’s subobjects.
getContactsExcludeRoles(roles: ContactRole[]): Contact[] Gets directly related Contact objects that are not in any
of the given roles. It does not return Contact objects
related to subobjects.
getContactType(role: ContactRole): IType Gets the type of the specified contact.
setContactByRole(role: ContactRole, contact : Sets the contact for a specified role if the role is Exclusi
Contact): void ve or both Exclusive and Required.

addRole(role: ContactRole,contact: Contact): Adds a role with the specified contact to the entity. Use
ClaimContactRole this method only with the Required or ZeroToMore roles.
For Exclusive roles or for Exclusive & Required roles,
use the explicit setContactByRole method for the role.
If either the role or contact does not exist, this method
does nothing.
removeRole(claimContactRole: ClaimContactRole): void Removes a role from the entity. If the role is the only role
for the associated contact, it attempts to remove the
contact as well. If either the role or contact do not exist
on the entity, this method does nothing.
removeRole(role: ContactRole, contact: Contact): void Removes a role from the entity for this specific contact.
Use this method only with Required or ZeroToMore
roles. For Exclusive roles or the Exclusive & Required
roles, use the other removeRole method. If either the
role or contact does not exist on the entity, this method
does nothing.

Similar methods are also available on the entities Exposure, Incident, and Matter.
Note: In addition to the get methods for Contact entities, there are get methods for ClaimContact entities that
are similar, except that they return ClaimContact entities rather than Contact entities. To see all the methods
associated with these entities, you can use the Gosu API reference. You can also run the Gosu Tester, which is
available in Studio on the Tools menu. In the Gosu Tester, you can declare variables of the various entity types and
use code completion pop-ups (Ctrl+Spacebar) to show you what is available for an entity.
See also
• Gosu Reference Guide

Entity property for Exclusive or Exclusive & Required Roles

If you add an Exclusive role or an Exclusive & Required role to an entity, the system adds a single property to the
entity for the role. You can view this property in the Data Dictionary. For example, the ContactRole typelist
defines the maincontact role. File entityroleconstraints-config.xml configures this role as follows:

...
<ContactRoleTypeConstraint contactRoleCode="maincontact" contactSubtype="Person"/>
...
<EntityRef entityType="Claim">
...
<RoleRef contactRoleCode="maincontact">
<RoleConstraint constraintType="Exclusive"/>
</RoleRef>

How configuring roles impacts entity data and types 685

 Configuration Guide 9.0.5

</EntityRef>
...

Whenever you regenerate the Data Dictionary, you see a maincontact property on the Claim that has a foreign key
to the Person contact type.

The system also generates getter and setter methods on the Claim plugin class for this property—in this example, the
getMaincontact and setMaincontact methods. You can also get and set this property using Gosu, for example,
by adding Gosu code to a rule.

Entity array key for required or ZeroToMore role

If you add a Required or ZeroToMore role to an entity, the system adds an array key to the entity. If there is no role
constraint specified, the default is ZeroToMore. For example, Guidewire configures the arbitrator role in the base
configuration as follows:

...
<ContactRoleTypeConstraint contactRoleCode="arbitrator" contactSubtype="Adjudicator"/>
...
<EntityRef entityType="Claim">
...
<RoleRef contactRoleCode="arbitrationvenue"/>
<RoleRef contactRoleCode="arbitrator"/>
<RoleRef contactRoleCode="assessor"/>
...
</EntityRef>
...

The system generates the array key arbitrator on the Claim entity. The array key points to an array of
Adjudicator contacts.
The system also generates a getter on the entity that enables you to get a list of the contacts in the arbitrator role.
The system does not generate a setter for array properties. To manipulate the array’s contents, use the addRole and
removeRole methods.

Avoiding errors with contact properties

For every subtype you create, your Guidewire application creates a property for that subtype on its parent. For
example, if you extend CompanyVendor with a Dentist subtype, the system creates a Dentist property. In this case,
do not create additional database entities with the name Dentist. For example, if you create a custom relationship,
do not name the relationship accessor Dentist. If you do use the property name for the name of a database entity,
you will receive an error similar to the following:

[java] java.lang.ClassCastException: com.guidewire.commons.metadata.internal.loader.ArrayData

[java] at com.guidewire.tools.datadictionary.support.TableWriter.writeColumns(TableWriter.java:239)
[java] at com.guidewire.tools.datadictionary.support.TableWriter.writeSubtype(TableWriter.java:504)
[java] at com.guidewire.tools.datadictionary.support.TableWriter.writeSubtypes(TableWriter.java:476)
[java] at com.guidewire.tools.datadictionary.support.TableWriter.writeTable(TableWriter.java:155)
[java] at
com.guidewire.tools.datadictionary.support.DictionaryWriter.writeTable(DictionaryWriter.java:409)
[java] at
com.guidewire.tools.datadictionary.support.
DictionaryWriter.outputDictionary(DictionaryWriter.java:360)
[java] at com.guidewire.tools.datadictionary.Main.main(Main.java:132)
[java] Exception in thread "main"

686 chapter 50 Configuring roles and relationships

 Configuration Guide 9.0.5

See also
• “Adding contact roles” on page 679
• “Add a new contact role: example” on page 688
• “Relationships between contacts” on page 690

Avoiding compilation errors with generated entity and role properties

In some cases, you can define role constraints that generate duplicate properties for an entity or role. For example,
on upgrade you see a compilation error indicating a problem in an entity role enhancement:
The property or field ‘AppraisalSource’ is already defined in the type
‘gw.entity.GWPropertyIncidentEntityRoleConstraintsEnhancement’. Enhancements cannot override properties.
To control generation of duplicate properties, add an attribute to the EntityRef or the RoleRef definition, as
appropriate, in entityroleconstraints-config.xml.

Controlling EntityRef property generation

The EntityRef tag supports an optional superType attribute, which must have a value matching the entityType
attribute of another EntityRef tag. Declare this attribute to suppress generation of properties that conflict with
properties that have already been generated for the indicated entity type.
In the base configuration, all subtypes of Incident have superType attributes defined for them. For example:

<EntityRoleConstraint>
...
<EntityRef entityType="Incident">
<RoleRef contactRoleCode="assessor"/>
<RoleRef contactRoleCode="incidentowner">
<RoleConstraint constraintType="Exclusive"/>
</RoleRef>
...
</EntityRef>
...
<EntityRef entityType="PropertyIncident" superType="Incident">
<RoleRef contactRoleCode="AppraisalSource"/>
<RoleRef contactRoleCode="assessor"/>
...
</EntityRef>
...
<EntityRef entityType="FixedPropertyIncident" superType="PropertyIncident">
<RoleRef contactRoleCode="AppraisalSource"/>
<RoleRef contactRoleCode="assessor"/>
...
</EntityRef>
...

See also
• “About entity role constraints” on page 682

Controlling RoleRef property generation

The RoleRef tag supports an optional generateProperty attribute, which can have the following values:
• readwrite – The default value. Generate read-write property for an exclusive role.
• readonly – Generate read-only property for a non-exclusive role.
• none – Do not generate a property. For example, in the base configuration, the claimant role on the Exposure
entity has generateProperty set to none. The Exposure entity already has a Claimant virtual property defined
in Java code.

<EntityRoleConstraint>
...
<EntityRef entityType="Exposure">
...

How configuring roles impacts entity data and types 687

 Configuration Guide 9.0.5

<RoleRef contactRoleCode="claimant" generateProperty="none">

...

See also
• “About entity role constraints” on page 682

Add a new contact role: example

The following example illustrates how to add a new contact role in Guidewire ClaimCenter and how to use that role
within ClaimCenter.
1. If necessary, start ClaimCenter Studio.
2. In the Project window, navigate to configuration→config→Extensions→Typelist and double-click ContactRole.
3. Right-click an element and choose Add new→typecode, and then add a role with the following values:

code name desc

negotiator Negotiator Person who handles a negotiation

1. In the Project window, also under Extensions→Typelist, double-click the ContactRoleCategory typelist to open it in
the editor.
2. Right-click the Vendors category and click Add new→category to add the following ContactRole:

code typelist
negotiator ContactRole

This step sets up filtering by this particular role for parties involved.
1. In the entityroleconstraints-config.xml file, add the negotiator role, and then add negotiator as a
role reference to the list of Negotiation roles.
a. Press Ctrl+Shift+N and enter entityroleconstraints-config.xml, and then press Enter to edit this file.
b. Add the following ContactRoleTypeConstraint to the section for role constraints at the top of the file:

<ContactRoleTypeConstraint contactRoleCode="negotiator" contactSubtype="Person"/>

2. Add the negotiator role with the Exclusive (zero or one interpreter) constraint to the Negotiation entity,
<EntityRef entityType="Negotiation">:

<RoleRef contactRoleCode="negotiator">
<RoleConstraint constraintType="Exclusive"/>
</RoleRef>

3. Save the file.

4. Stop ClaimCenter, optionally regenerate the data dictionary, and restart ClaimCenter, as described in the steps
that follow.
Note: Because the role changes and additions are data model changes, you must at least stop and restart
ClaimCenter.
5. If necessary, stop ClaimCenter.
6. Optionally, regenerate the data dictionary:

gwb genDataDict

7. Start the ClaimCenter application.

688 chapter 50 Configuring roles and relationships

 Configuration Guide 9.0.5

8. You also need to quit ClaimCenter Studio and restart it to enable use of the Negotiation.negotiator virtual
property.
9. In the Studio Project window, navigate to configuration→config→Localizations, and then double-click
display_en_US.properties.
10. Add the following display key and value:

NVV.Matter.SubView.MatterNegotiationDetail.General.Negotiator = Negotiator

11. In the Studio Project window, navigate to configuration→config→Page Configuration→pcf→claim→newother and

double-click NewNegotiationDV to open it.
12. Drag a ClaimContactInput widget from the Toolbox on the right and drop it after the ClaimContactInput with id
General_NegContact, and then select it and set the following properties:

editable true

id NegotiatorContact

label displaykey.NVV.Matter.SubView.MatterNegotiationDetail.General.Negotiator

required false

value Negotiation.negotiator

claim Negotiation.Claim

valueRange Negotiation.Claim.RelatedContacts as Person[]

Because the Negotiation.negotiator value is a Person, but the valueRange for this field is all Claim contacts, you
must cast the valueRange to be an array of Person objects. If you previously regenerated the Data Dictionary, you
can use it to view the Negotiation entity and the new negotiator field.
1. Navigate to configuration→config→Page Configuration→pcf→planofaction and open ClaimNegotiationDetailsDV.
Repeat the actions of the previous step to add a ClaimContactInput widget after the ClaimContactInput with id
General_NegContact and the same properties.
2. Stop and restart ClaimCenter and then log in again to reload these PCF changes.
3. Open a claim, and then choose Actions→New→Negotiation.
4. Whenever you view the Negotiator field in the New Negotiation window, the system automatically generates a
picker for it:

1. Add a negotiator and enter some information about the negotiation and then save the new negotiation.
2. Click Plan of Action on the left, and then click Negotiations in the blue bar at the top to show the current
negotiations.
3. Select the negotiation you created and look for the Negotiator field, which shows the negotiator you added. You
can click Edit to change the settings for the negotiation, including the Negotiator.

Add a new contact role: example 689

 Configuration Guide 9.0.5

See also
• “Adding contact roles” on page 679
• “How configuring roles impacts entity data and types” on page 684
• “Relationships between contacts” on page 690

Relationships between contacts

Relationships enable you to associate two contacts by applying an association to them. Examples of associations are
employer and employee or attorney and law firm. You see a contact’s relationships on the ClaimCenter Related
Contacts subtab.
For example, if you open a claim in ClaimCenter, then click Parties Involved on the left, you see a list of contacts for
the claim. Below this list is an Edit window for the selected contact that has three tabs, one of which is Related
Contacts.
Relationships are bidirectional automatically. If you add a Person contact to a Company contact as an Employee, the
company appears on the person’s Related Contacts tab as an Employer. Additionally, the person appears on the
company’s Related Contacts tab as an Employee.
You configure contact relationships in ClaimCenter by doing the following:
• Editing file contact-relationship-config.xml to add a contact relationship pair
• Modifying the ContactBidiRel and ContactRel typelists to add the new contact relationships
• Modifying the RelationshipSyncConfig class to ensure that your synchronization configuration also has the
primary relationship defined as a synchronization attribute
In the contact-relationship-config.xml file there are a number of internal contact relationships: guardian,
employer, primarycontact, and so on. To add your own relationships, add them to the end of the file.

IMPORTANT The system relies on these internal relationships. Do not modify or remove the internal contact
relationships. However, you can use a filter attribute to filter these values in a PCF drop-down list.

Adding a bidirectional contact relationship: example

This example illustrates how to add a relationship between two contacts to indicate the primary and secondary
insured parties on a claim.
Note: This example requires that you first integrate Guidewire ContactManager with Guidewire ClaimCenter. See
the Guidewire Contact Management Guide for details on how to integrate the two applications.
This example contains the following steps:
1. “Add new contact relationship to ClaimCenter” on page 690
2. “Test new contact relationship in ClaimCenter” on page 692
3. “Add new contact relationship to ContactManager” on page 693
4. “Test new contact relationship in ContactManager” on page 694

Add new contact relationship to ClaimCenter

Before you begin
This example requires that you first integrate Guidewire ContactManager with Guidewire ClaimCenter.
See the Guidewire Contact Management Guide for details on how to integrate the two applications.
Before starting this procedure, review “Adding a bidirectional contact relationship: example” on page 690.

690 chapter 50 Configuring roles and relationships

 Configuration Guide 9.0.5

Procedure
1. If necessary, start ClaimCenter Studio.
a. Open a command prompt and navigate to the ClaimCenter installation directory.
b. Enter the following command:

gwb studio

2. In the Studio Project window, navigate to configuration→config→Metadata→Typelist.

3. Right-click ContactRel.tti and choose New→Typelist Extension and then click OK.
Studio creates ContactRel.ttx in configuration→config→Extensions→Typelist and opens it in the typelist editor.
4. In ContactRel.ttx, right-click an existing typecode and choose Add new→typecode.
5. Enter the following values for the new typecode:
• code – primaryinsured
• name – Primary Insured
• desc – Primary insured
6. In the Project window, navigate to configuration→config→Extensions→Typelist and double-click
ContactBidiRel.ttx to edit it.
7. In ContactBidiRel.ttx, right-click an existing typecode and choose Add new→typecode.
8. Enter the following values for the new typecode:
• code – primaryinsured
• desc – Primary insured
9. Right-click the new primaryinsured typecode and choose Duplicate
10. Enter the following values for the duplicated typecode:
• code – secondaryinsured
• name – Secondary Insured
• desc – Secondary insured
11. In the contact-relationship-config.xml file, add elements to combine the relationship primaryinsured
with its inverse, secondaryinsured, as follows:
a. In the Project window, navigate to configuration→config→addressbook and double-click contact-
relationship-config.xml to open it in the editor.
b. Add the following elements before the final </ContactRelationshipConfigFile> tag:

<ContactRelationshipPair contactRelCode="primaryinsured" >

<Primary name="PrimaryInsured"
cardinality="zeroorone"
contactBidiRelCode="primaryinsured"
entity="Contact" />
<Inverse name="SecondaryInsured"
cardinality="zeroormore"
contactBidiRelCode="secondaryinsured"
entity="Contact" />
</ContactRelationshipPair>

12. Ensure that your synchronization configuration also has the primary relationship defined as a synchronization
attribute. Add the relationship to Contact as follows:
a. Press CTRL+N and enter RelationshipSyncConfig, and then double-click the class name in the search
results.
b. Add the following chained method call to the init method before the final .create method call:

Adding a bidirectional contact relationship: example 691

 Configuration Guide 9.0.5

.includeRelationship(Contact,TC_PRIMARYINSURED,true)

For information on using RelationshipSyncConfig, see the Guidewire Contact Management Guide.
13. Stop ClaimCenter, regenerate the data dictionary, and then restart ClaimCenter, as described in the following
steps. You need to perform all of these steps because the relationship additions cause data model changes to
Contact.
a. Open a command prompt in the ClaimCenter directory and then enter the following command:

gwb stopServer

b. Regenerate the data dictionary to ensure that your changes are correct:

gwb genDataDict

c. Start the ClaimCenter application:

gwb runServer

14. Open ContactManager Studio and fetch updates for the ClaimCenter web service ContactAPI.
a. In the Project window, navigate to configuration→gsrc and then to wsi.remote.gw.webservice.cc.
b. Double click cc900.wsc.
c. Select the resource ${cc}/ws/gw/webservice/cc/cc900/contact/ContactAPI?wsdl.
d. Click Fetch .

Next steps
After completing this procedure, continue to “Test new contact relationship in ClaimCenter” on page 692.

Test new contact relationship in ClaimCenter

Before you begin
This example requires that you first integrate Guidewire ContactManager with Guidewire ClaimCenter. See the
Guidewire Contact Management Guide for details on how to integrate the two applications.
Before starting this procedure, complete “Add new contact relationship to ClaimCenter” on page 690.

Procedure
1. Log into ClaimCenter as a user that can edit claims.
For example, if using the sample data, use aapplegate/gw.
2. Open an existing claim and open the Parties Involved→Contacts screen.
3. If necessary, add contacts to this screen so that there are at least two contacts.
4. Click the name of one of the contacts to open the Basics card, and then click the Related Contacts card.
5. Click Edit, then Add, and then click the new Name field to add one of the contacts on the list.
6. Under Relation to Contact, click the file and choose Primary Insured from the drop-down list.
7. Click Update to save your changes.
8. In the list of contacts above the Related Contacts card, click the contact you just added as a related contact, and
then click the Related Contacts card for that contact.
That tab shows the first contact you picked and the inverse relationship Secondary Insured.

692 chapter 50 Configuring roles and relationships

 Configuration Guide 9.0.5

Next steps
After completing this procedure, continue to “Add new contact relationship to ContactManager” on page 693.

Add new contact relationship to ContactManager

Before you begin
This example requires that you first integrate Guidewire ContactManager with Guidewire ClaimCenter. See the
Guidewire Contact Management Guide for details on how to integrate the two applications.
Before starting this procedure, complete “Test new contact relationship in ClaimCenter” on page 692.

Procedure
1. Start Contact Manager Studio.
a. Open a command prompt and navigate to the Contact Manager installation directory.
b. Enter the following command:

gwb studio

2. In the Studio Project window, navigate to configuration→config→Extensions→Typelist and double-click

ContactRel.ttx to edit it.
3. In ContactRel.ttx, right-click an existing typecode and choose Add new→typecode.
4. Enter the following values for the new typecode:
• code – primaryinsured
• name – Primary Insured
• desc – Primary insured
5. In the Studio Project window, in the same Typelist folder, double-click ContactBidiRel.ttx to edit it.
6. In ContactBidiRel.ttx, right-click an existing typecode and choose Add new→typecode.
7. Enter the following values for the new typecode:
• code – primaryinsured
• name – Primary Insured
• desc – Primary insured
8. Right-click the new primaryinsured typecode and choose Duplicate
9. Enter the following values for the duplicated typecode:
• code – secondaryinsured
• name – Secondary Insured
• desc – Secondary insured
10. In the abcontact-relationship-config.xml file, add elements to combine the relationship
primaryinsured with its inverse, secondaryinsured, as follows:
a. In the Project window, navigate to configuration→config→addressbook and double-click abcontact-
relationship-config.xml to open it in the editor.
b. Add the following elements before the final </ContactRelationshipConfigFile> tag:

<ContactRelationshipPair contactRelCode="primaryinsured" >

<Primary name="PrimaryInsured"
cardinality="zeroorone"
contactBidiRelCode="primaryinsured"
entity="ABContact" />
<Inverse name="SecondaryInsured"
cardinality="zeroormore"

Adding a bidirectional contact relationship: example 693

 Configuration Guide 9.0.5

contactBidiRelCode="secondaryinsured"
entity="ABContact" />
</ContactRelationshipPair>

11. Stop Contact Manager, regenerate the data dictionary, and restart Contact Manager, as described in the steps
that follow.
You need to perform all these actions because the relationship additions cause data model changes to
ABContact.
a. If necessary, stop the Contact Manager application:
Open a command prompt in the ContactManager directory and then enter the following command:

gwb stopServer

b. Regenerate the data dictionary to ensure that your changes are correct:

gwb genDataDict

c. Start the Contact Manager application:

gwb runServer

12. Open ClaimCenter Studio and fetch updates for the ContactManager web service ABContactAPI.
a. In the Project window, navigate to configuration→gsrc and then to wsi.remote.gw.webservice.ab.
b. Double click ab900.wsc.
c. Select the resource ${ab}/ws/gw/webservice/ab/ab900/abcontactapi/ContactAPI?wsdl.
d. Click Fetch .

Next steps
After completing this procedure, continue to “Test new contact relationship in ContactManager” on page 694.

Test new contact relationship in ContactManager

Before you begin
This example requires that you first integrate Guidewire ContactManager with Guidewire ClaimCenter. See the
Guidewire Contact Management Guide for details on how to integrate the two applications.
Before starting this procedure, complete “Add new contact relationship to ContactManager” on page 693.

Procedure
1. Log into ClaimCenter as a user such as the sample user ssmith/gw.
2. Open an existing claim and open the Parties Involved→Contacts screen.
3. Click Add existing contact and search for a contact, such as the company Whole Foods from the imported
sample data.
4. Select the contact and add a role so you can add it to the list of contacts for the claim.
5. Click Update to add the contact to the claim.
6. Select the newly added contact and then click the Related Contacts card.
7. Click Edit and then click Add to add a new related contact.
8. Click the drop-down button in the Name field and choose Search from the list, and then search for an existing
contact.
For example, search for the Person with First Name of Eric and Last Name of Andy from the imported sample
data.
694 chapter 50 Configuring roles and relationships
 Configuration Guide 9.0.5

9. Click Select next to the contact you want to add.

10. On the Related Contacts card in the Relationship to Contact field, click the field and choose Primary Insured
from the drop-down list.
11. Click Update to save your changes.
12. In the Related Contacts card for your contact, click the Name Eric Andy.
13. Click the Related Contacts tab.
This tab shows the first contact you picked, such as Whole Foods, and the inverse relationship Secondary
Insured.

Adding a bidirectional contact relationship: example 695

 Configuration Guide 9.0.5

696 chapter 50 Configuring roles and relationships

chapter 51

Configuring multicurrency

ClaimCenter supports multiple currencies in financial transactions. You can configure ClaimCenter financials to
display as well as use multiple currencies. If multicurrency is enabled, you can view monetary transactions in
different currencies as well as manage reserves, checks, and payments in multiple currencies. You can track and
erode reserves in the currency of choice, avoiding exchange rate fluctuations and their potential impact on reserve
amounts.
This topic describes multicurrency configuration in ClaimCenter.
See also
• Globalization Guide

How to configure multicurrency

You can configure ClaimCenter in three different modes for currency.
• Single currency mode – All money amounts use one currency. Edit config.xml as follows:

<param name="MulticurrencyDisplayMode" value="SINGLE"/>

Set the DefaultApplicationCurrency to the one currency to use, as in the following example:

<param name="DefaultApplicationCurrency" value="usd"/>

• Multicurrency display – Determines if ClaimCenter displays multiple currencies. Set this parameter as follows:

<param name="MulticurrencyDisplayMode" value="MULTIPLE"/>

• Multicurrency reserving – Determines if you can track reserves and recovery reserves in multiple currencies on a
claim. Set this parameter as follows:

<param name="EnableMultiCurrencyReserving" value="true"/>

Configuring multicurrency 697

 Configuration Guide 9.0.5

With multicurrency reserving enabled, you can:

◦ Create and track reserves and recovery reserves in any currency.
◦ Create Payments and Recoveries in any currency. They erode reserves and recovery reserves respectively in the
currency the reserve was created.
◦ Track these transactions as part of the financial calculations and summary.
Note: As reserves are tracked in the currency they were created in, exchange rate fluctuations do not impact the
remaining amount on a reserve.

IMPORTANT In the base configuration, multicurrency display and reserving are disabled, and ClaimCenter tracks
all financial transactions in the default application currency.

IMPORTANT The MulticurrencyDisplayMode and EnableMultiCurrencyReserving configuration parameter

settings are semi-permanent. You can change the values of these parameters only once,
MulticurrencyDisplayMode from SINGLE to MULTIPLE and EnableMultiCurrencyReserving from false to
true. After you change the values and restart the server, you must not later change them back. If you do change the
value of MulticurrencyDisplayMode back to SINGLE or of EnableMultiCurrencyReserving back to false,
subsequent attempts to start the server fail. These configuration parameters are in config.xml.

Multicurrency in financial calculations

ClaimCenter supports multicurrency transactions. You can carry out transactions (create reserves and recovery
reserves, make payments, and collect recoveries), as well as write checks, in more than one currency in a single
claim. ClaimCenter supports a single default currency and multiple secondary transaction currencies:

Default ClaimCenter defines its default currency with the configuration parameter DefaultApplicationCurrency (in
currency config.xml) on server startup.
The term reporting currency also refers to this default currency.
Note: The ExchangeRate entity contains a BaseCurrency typekey. Do not confuse this with the default
currency.
Claim currency The claim’s currency, inherited from the associated policy, which is defined in the Currency typekey field on
the Claim entity.
Reserving Currency of a reserve line, defined by the ReservingCurrency typekey field on the ReserveLine entity.
currency
Transaction ClaimCenter maintains a list of all of the available currencies in the Currency typelist.
currencies

See also
• For information on how ClaimCenter handles multiple currencies, see the Application Guide.
• For information on using methods on ClaimFinancialsAPI that are specific to foreign exchange adjustments,
see the Integration Guide.

Multicurrency data model

The following section summarize the main entities related to multicurrency.

698 chapter 51 Configuring multicurrency

 Configuration Guide 9.0.5

Multicurrency Entities

Claim Policy

Currency Currency

Claim is 0 to 1 to many transactions

Transaction
ExchangeRateSet ExchangeRate
BaseCurrency Currency
MarketRates
PriceCurrency ReservingCurrency
EffectiveDate
ExchangeRateSet TransactionAmount
ExpireDate
TransToClaimExchangeRate
TransToReservingExchangeRate
ClaimToReportingExchangeRate
Legend

A is one-to-
A B one B Transaction is 1 to many TransactionLineItem

A B A is one-to-
many B
A B A extends B
TransactionLineItem
A B A implements B
ClaimAmount
A has foreign key TransactionAmount
A B
to B
ReservingAmount
ReportingAmount

Notice the following:

• The currency of the claim always equals the currency of the policy.
• There is a foreign key from Transaction to Claim.
• TransactionLineItem stores amounts in all four currencies that affect a transaction: transaction, claim,
reserving, and reporting. The TransactionLineItem table itself only stores the amounts. The currencies are
stored in the Transaction and Claim entities respectively and statically in the system, as configured in the
config.xml file. The ReportingAmount is from the application’s default currency. ClaimCenter stores this
currency as a configuration parameter in the config.xml file.
• The transaction-to-claim, transaction-to-reserving, and claim-to-reporting exchange rates are stored in the
corresponding fields in Transaction.

Entity Description
Check Contains an array of Payments. Payment is a subtype of Transaction, so every Payment stores a currency and
two exchange rates. All the payments on a check must have the same currency and exchange rates. For this
reason, the currency for a payment can also be called the check currency. The Check entity does not store a
currency or any exchange rates, but Check does have virtual properties to get the currency and exchange
rates for its payments.
CheckPortion Determines the amount for which a secondary check will be written. For example, a secondary check could be
a check on a multi-payee check that is not the primary check. CheckPortion can indicate that a secondary
check receives either a percentage of the sum of the payments or a fixed amount.
Checks with a CheckPortion do not have any payments, but just receive a percentage or fixed amount of the
Payments in the primary Check of the CheckGroup. CheckPortion cannot have its percentage and fixed
amount fields both populated.
Important fields include:
• FixedTransactionAmount – If set, the amount in the transaction currency that is allocated to this
secondary check.
• FixedClaimAmount – If set, the amount in the claim currency that is allocated to this secondary check.
• FixedReportingAmount – If set, the amount in the reporting currency that is allocated to this secondary
check.

Multicurrency data model 699

 Configuration Guide 9.0.5

Entity Description
• Percentage – If set, the fraction of the amounts of the payments that are allocated to this secondary
check. Setting this field clears the fixed amount fields.
Deduction Represents a deduction from a check, usually for tax purposes.
Important fields include:
• ClaimAmount – Amount of the deduction in the claim currency.
• TransactionAmount – Amount of the deduction in the transaction currency.
• ReportingAmount – Amount of the deduction i the reporting currency.
Transaction Represents a financial operation. It has the following subtypes: Payment, Recovery, RecoveryReserve, and Re
serve.
Important fields include:
• Currency – Transaction currency.
• TransToReservingExchangeRate – Exchange rate between transaction and reserving currencies that is in
effect for this Transaction.
• TransToClaimExchangeRate – Exchange rate between transaction and claim currencies that is in effect
for this Transaction.
• ClaimToReportingExchangeRate – Exchange rate between claim and reporting currencies that is in effect
for this Transaction. This field is not shown in the user interface in the base configuration.
TransactionL TransactionLineItems provide a means to split the amount of a transaction into multiple categories such as
ineItem Doctor, Hospital, Legal, and so forth. Every transaction has one or more TransactionLineItems, and the
amount of the transaction is the sum of all its line items’ amounts.
Important fields include:
• Deductible – Deductible represented by this TransactionLineItem, if any. Used when deductible
handling is enabled.
• TransactionAmount, ClaimAmount, ReservingAmount, ReportingAmount – Store the amount in the four
currencies. TransactionAmount is also accessible through the Amount virtual property for single currency
implementations.
ExchangeRate Represents an exchange rate between a pair of currencies. This rate can be a market rate, in which case it will
exist in an ExchangeRateSet with rates between every currency pair. It can also be a manually-entered custo
m rate, in which case it typically contains the amount entered by the user and resides alone in an ExchangeRa
teSet.
Important fields include:
• BaseCurrency – The currency from which this exchange rate converts, as in GB pounds.
• PriceCurrency – The currency to which this exchange rate converts, as in Euros.
• Rate – The exchange rate between the two currencies, such as 1.301.
Note: If you are doing a multicurrency implementation, the ExchangeRate table can grow large. This table is
created by default in the ADMIN tablespace, which usually does not have as much room as the main
tablespace. Therefore, this table can cause the ADMIN tablespace to run out of room. After creating the
database schema in a production system, manually migrate this table out of the ADMIN tablespace to the
normal tablespace where more room is usually allocated.
ExchangeRate Represents a set of exchange rates, along with supplemental information about those rates, including the
Set dates the set goes into effect and expires.
The MarketRates field, when true, indicates that the exchange rates are market rates. When this field is fals
e, the set contains only one user-entered custom rate.
Important fields include:
• EffectiveDate – Sets the date and time at which the rate set starts to be in effect.
• ExpireDate – Sets the date and time at which the rate set becomes no longer in effect.
• MarketRates – If set to true, the rate set is included in the search for the latest market rates.
Note: If you are doing a multicurrency implementation, the ExchangeRateSet table can grow large. This table
is created by default in the ADMIN tablespace, which usually does not have as much room as the main
tablespace. Therefore, this table can cause the ADMIN tablespace to run out of room. After creating the

700 chapter 51 Configuring multicurrency

 Configuration Guide 9.0.5

Entity Description
database schema in a production system, manually migrate this table out of the ADMIN tablespace to the
normal tablespace, where more room is usually allocated.

Foreign exchange adjustments

For foreign-currency payments, it is possible that the exchange rate can change during a transaction. For example,
the exchange rate between the payment's currency and the claim’s base currency can change. This can happen,
perhaps, in between the time that the payment was created and the time its associated check finally clears the bank.
For this reason, ClaimCenter provides the ability to update the converted amount of a check and its payments once
the final converted amount is known.
ClaimCenter supports this update process by having the user specify the final converted amount of the check or its
payments, as opposed to the final exchange rate. ClaimCenter then uses this final converted amount to calculate a
foreign exchange adjustment for the payments. It then updates the underlying accounts appropriately. ClaimCenter
makes the adjustment for each payment at the level of the TransactionLineItem, making each adjustment
proportional to the line items' amounts.
For example, suppose that you have a check with a single payment that has three line-items with the following
transaction and claim amounts:

Line-item Transaction Claim

Amount Amount
1 60 50
2 35 30
3 22 20
Total Amount 117 100

At some future time, the payment's check clears, and the converted claim amount is actually $110, rather than $100.
ClaimCenter applies the foreign exchange adjustment proportionally across all the line-items, resulting in the
following:

Line-item Transaction Claim Foreign Exchange Cleared Claim

amount amount Adjustment Amount
1 60 50 5 55
2 35 30 3 33
3 22 20 2 22
Total Amount 117 100 10 110

ClaimCenter provides methods for foreign exchange adjustments to be made on either a payment-by-payment basis,
or for an entire check at once. In the latter case, the adjustment is split proportionally between all the active
payments on the check (excluding any recoded, offsetting or canceled payments). Then, for each such payment, its
adjustment is split amongst its line-items as discussed in the previous example.
Applying a foreign exchange adjustment to an existing payment or check is equivalent to setting a custom exchange
rate on the payment or payments.

Foreign exchange adjustments 701

 Configuration Guide 9.0.5

Foreign exchange transactions and calculated values

Guidewire ClaimCenter treats foreign exchange adjustments as non-eroding. This means the following:
• Foreign exchange adjustments do not decrease calculated values such as Open, Remaining and Available
Reserves.
• Foreign exchange adjustments do increase all total incurred calculations (Net and Gross), as well as overall Total
Paid and Total Paid Non-Eroding.
In the example, assume that the only other transaction on the payment's reserve line is a reserve transaction for $150.
(This transaction is in the base currency.) As the payment is first escalated, you see the following calculated values:

Open, Remaining, and Available Reserves $50.00

Total Incurred (gross and net) $150.00
Total Paid $100.00
Total Paid Non-eroding $0.00
Total Paid Eroding $100.00

After ClaimCenter applies the foreign exchange adjustment, the calculated values become:

Open, Remaining and Available Reserves $50.00 (unchanged)

Total Incurred (gross and net) $160.00 (+$10.00)
Total Paid $110.00 (+$10.00)
Total Paid Non-eroding $10.00 (+$10.00)
Total Paid Eroding $100.00 (unchanged)

To work with foreign exchange calculations, Guidewire provides three expressions accessible from
gw.api.financials.FinancialsCalculationUtil:

getForeignExchangeAdjustmentsExpression
getErodingPaymentsForeignExchangeAdjustmentsExpression
getNonErodingPaymentsForeignExchangeAdjustmentsExpression

See also
• “Foreign exchange adjustments” on page 701

Foreign exchange adjustments on claims and payments

Guidewire ClaimCenter provides the following methods to apply a foreign exchange adjustment to a check or a
payment within the context of the ClaimCenter business rules:
• Check.applyForeignExchangeAdjustment
• Payment.applyForeignExchangeAdjustment
Note: Foreign exchange adjustments only affect total incurred and total paid calculations. They do not further
erode reserves.

Check.applyForeignExchangeAdjustment

Check.applyForeignExchangeAdjustment( newClaimAmount : BigDecimal ) : void

702 chapter 51 Configuring multicurrency

 Configuration Guide 9.0.5

This method applies a foreign exchange adjustment to this Check's claim currency amount. The parameter
newClaimAmount specifies the new amount for this check in the claim currency. It cannot be null.
The amount of the adjustment is the percentage difference between the new passed-in amount and the current
amount for claim currency. Suppose, for example, that the original check has three payments of $50, $20 and $10 for
a total claim amount of $80, and the new claim amount is $100. Then, every payment will get a 25% offset, making
them $62.50, $25 and $12.50, for a total of $100.
Only use this method on a check that is in a committed but uncanceled state, meaning that the check status must be
one of the following:
• Requesting
• Requested
• Issued
• Cleared

Payment.applyForeignExchangeAdjustment

Payment.applyForeignExchangeAdjustment( newClaimAmount : BigDecimal ) : void

This method applies a foreign exchange adjustment to this Payment's claim currency amount. The parameter
newClaimAmount specifies the new amount for this payment in the claim currency. It cannot be null.
The amount of the adjustment is the percentage difference between the new passed-in amount and the current
amount for claim currency. Suppose, for example, that the original payment has three line items of $50, $20 and $10
for a total claim amount of $80, and the new claim amount is $100. Then, every line-item will get a 25% offset,
making them $62.50, $25 and $12.50, for a total of $100.
Only use this method on a payment that is an offsetting payment. The payment must also be in a committed but
uncanceled state, meaning that the payment status must be one of the following:
• Submitting
• Submitted

Applying foreign exchange adjustments multiple times

You can apply a foreign exchange adjustment to a payment or check multiple times. However, each application of
the adjustment negates and replaces the prior one. Using the example in “Foreign exchange adjustments” on page
701 (three payments of $50, $30, and $20), assume that you make a second call to
applyForeignExchangeAdjustment on the payment. This time, you pass in a value of $120.00. You would then end
up with the following three line-items:
• $60.00 ($10.00 adjustment)
• $36.00 ($6.00 adjustment)
• $24.00 ($4.00 adjustment)
The ClaimCenter database maintains a history of both of these adjustments in order to maintain an audit trail.
However, it only applies the last adjustment to calculated values.

Foreign exchange adjustments on claims and payments 703

 Configuration Guide 9.0.5

TransactionLineItem fields
ClaimCenter provides the following fields on the TransactionLineItem entity for use with foreign exchange
adjustments:
• ClaimForExAmount
• ReportingForExAmount
It also provides the following fields on the Transaction entity:
• ClaimForExAdjustmentAmount
• ReportingForExAdjustmentAmount

704 chapter 51 Configuring multicurrency

chapter 52

Claim archiving

Archiving is the process of moving a closed claim and associated data from the active ClaimCenter database to a
document storage area. You can still search for and retrieve archived claims, but they occupy less space in the active
database while archived.

How ClaimCenter selects claims for archive eligibility

ClaimCenter bases the criteria that determine whether a claim is eligible for archive on the
Claim.DateEligibleForArchive property. Specifically, for a claim to be eligible for archiving:
• The value of the DateEligibleForArchive property for that claim must have a non-null date and time.
• This date and time must be earlier than the current system date and time.
In the base configuration, ClaimCenter manages the value of Claim.DateEligibleForArchive from multiple
places:

Claim ClaimCenter action DateEligibleForArchive value

event
Claim ClaimCenter does not set the DateEligibleForArchive property as it null
created creates a claim. Therefore, the value of the DateEligibleForArchive
property is null.
Claim ClaimCenter triggers a Claim Closed rule (CCL04000 - Set archive eligibility DaysClosedBeforeArchive +
closed date) as it closes a claim. This rule sets the value of Claim.DateEligibleFo current date
rArchive to a date computed by adding the value of the DaysClosedBefor
eArchive configuration parameter (in days) to the current system date.

Claim ClaimCenter uses base configuration class ClaimInfoIArchiveSource DaysRetrievedBeforeArchive +

retrieved (which extends IArchiveSource) to set the value of DateEligibleForArch current date.
from ive. This value is a date computed by adding the value of the DaysRetriev
archive edBeforeArchive configuration parameter (in days) to the current system
date.

Claim archiving 705

 Configuration Guide 9.0.5

Claim ClaimCenter action DateEligibleForArchive value

event
Claim ClaimCenter triggers a Claim Reopened rule (CRO04000 - Clear archive null
reopened eligibility date) as it reopens a claim. This rules sets DateEligibleForArchi
ve to null.

Thus:
• To change the amount of time after a claim has been closed before ClaimCenter archives it, edit the
DaysClosedBeforeArchive configuration parameter.
• To change the amount of time after a claim has been retrieved from the archive before ClaimCenter archives the
claim again, edit the DaysRetrievedBeforeArchive configuration parameter.
• To achieve a more fine-grained control over the DateEligibleForArchive property, you can edit one of the
configuration points listed in the previous table or add code elsewhere to modify it.

Claims closed before implementing archiving

If your installation includes claims that you closed before you implemented archiving, then you need to detect those
claims and set the Claim.DateEligibleForArchive date based on your business requirements. You must also do
this if you previously implemented a database-backed version of archiving.

Claims loaded through staging tables

After you implement archiving, you need to set the DateEligibleForArchive property on any closed claims that
you load through staging tables. ClaimCenter does not set a DateEligibleForArchive date on these claims.

Restore archived claims using system tools

About this task
Using the system tools available at a command prompt, an administrator can retrieve one or more archived claims
and restore the claims to the ClaimCenter database.

Procedure
1. Ensure that ClaimCenter is running.
2. In a command prompt, navigate to the ClaimCenter admin/bin directory.
3. Enter one of the following commands to retrieve claims from the archive store.
• Single claim:

maintenance_tools -restore comment -claim claimnumber -user user -password password

• Group of claims:

maintenance_tools.bat -restore comment -claim file -user user -password password

For these commands, you must supply a username and password (user and password). Parameter file names
a text file that contains a list of claim numbers, separated by new lines. You can also add a comment
(comment) after the -restore command option.

706 chapter 52 Claim archiving

 Configuration Guide 9.0.5

Next steps
See also
• System Administration Guide

Monitoring archiving activity

ClaimCenter provides server tools to help you monitor and supervise the archiving process:

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 ClaimCenter 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 ClaimCenter 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 claim, ClaimCenter typically
generates an EntityStateException exception.
• If an archive worker cannot archive a claim for any reason, the worker marks the claim with an
ExcludedFromArchive flag.
The Archive Info screen Excluded from Archive value shows the number of claims that ClaimCenter excluded from
archiving.

See also
• System Administration Guide

Logging archiving activity

If enabled, ClaimCenter 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, ClaimCenter writes this information to the console log as well.
To configure archive logging, modify file logging.properties to suit your business needs. Use the existing
loggers in the file as examples.

Monitoring archiving activity 707

 Configuration Guide 9.0.5

See also
• System Administration Guide

Archive configuration options

This topic describes various configuration options that affect ClaimCenter archiving.

Archive configuration parameters

Guidewire provides a set of configuration parameters in file config.xml that you use to enable and manage various
aspects of the archiving process. These configuration parameters are:
• AssignClaimToRetriever
• DaysClosedBeforeArchive
• DaysRetrievedBeforeArchive
• DomainGraphKnownUnreachableTables
• RestorePattern
• SnapshotEncryptionUpgradeChunkSize
See also
• “Archive parameters” on page 44

Archive rules
Guidewire provides a set of rules that you can use to implement business logic related to archiving. You can find
these rules in Guidewire Studio in the following location:
configuration→config→Rule Sets→Archive
Through the Archive rules, you can do the following:
• Skip a claim – Skipping a claim during archiving makes that claim temporarily unavailable for archiving during
the current archiving pass.
• Exclude a claim – Excluding a claim from archiving makes that claim unavailable for archiving during this and
future archiving passes.
You can view information about skipped and excluded claims in the Server Tools→Info Pages→Archive Info screen.
This screen lists:
• Total number of claims skipped by the archiving process
• Number of claims excluded because of rules
• Number of claims excluded because of failure
For skipped and excluded claims, you can investigate each individual item. You can also reset any excluded claim so
that the archiving process attempts to archive that claim the next time the archiving process runs.

Default group claim archiving rule set

The Archive rule set category contains the Default Group Claim Archiving rule set. ClaimCenter runs the rules in
this rule set on each claim in the archive work queue during the archiving process. In the base configuration,
Guidewire provides the following sample rules in this rule set:
• Claim State Rule – If the claim is open, ClaimCenter skips the claim.
• Bulk Invoice Item State Rule – If the claim has links to a bulk invoice item that is in a certain state, ClaimCenter
skips the claim.
• Open Activities Rules – If the claim has open activities, ClaimCenter skips the claim.

708 chapter 52 Claim archiving

 Configuration Guide 9.0.5

• Incomplete Review Rule – If the claim has a vendor review that is incomplete, ClaimCenter skips the claim.
• Unsynched Review Rule – If the claim has a vendor review that is not synchronized with Guidewire
ContactManager, ClaimCenter skips the claim.
• Transaction State Rule – If a claim has un-escalated or un-acknowledged transactions, ClaimCenter skips the
claim.
It is possible for you to add your own, additional, archive-related rules to this rule set, or to modify the sample rules
that Guidewire provides. Thus, it is possible to write archiving rules that reflect your unique business conditions. For
example, you can write rules to do the following:
• Do not archive a sensitive claim, or one with restricted access control.
• Do not archive a claim that meets a certain condition, such as having medical payments over some amount.
• Do not archive a claim whose claimant has other open claims pending.
There are additional archiving-related methods, such as Claim.hasReportedArchiveProblem, that are useful in rule
writing.
See also
• Rules Guide

Archive events
Whenever ClaimCenter creates a claim, it also creates a ClaimInfo entity, which is the root of the Claim domain
graph. If a ClaimInfo entity changes, which can happen during claim archiving, retrieval, claim exclusion, and
archive failure, ClaimCenter generates a ClaimInfoChanged event.
See also
• Rules Guide

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.

Understanding the archiving plugins

If you implement archiving, you must implement the following plugins.

Plugin interface Description Implementation class

IArchiveSource Provide methods to store and retrieve a serialized XML document that ClaimInfoArchiveSource
represents one instance of the Claim archive graph.

See also
• Integration Guide

Archive configuration options 709

 Configuration Guide 9.0.5

710 chapter 52 Claim archiving

chapter 53

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, ClaimCenter 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 claim and contact data from ClaimCenter. There can
be multiple objects associated with the claim 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.
Obfuscation might be required if destroying the data affects claims that cannot be destroyed. For example, purging
user data for a former employee could affect hundreds or even thousands of claims. Therefore it makes more sense
to obfuscate the data for the user and leave the other data alone.

Configuring personal data destruction 711

 Configuration Guide 9.0.5

Data destruction configuration parameters

In the base configuration of ClaimCenter, data destruction is not enabled. You must set the following configuration
parameters in config.xml to enable data destruction:
• PersonalDataDestructionEnabled – Set this parameter to true to enable destruction of personal data. In the
base configuration, this parameter is false.
• 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.
• ArchiveReferenceTrackingEnabled – When archiving is enabled, you must set this parameter to true to
enable tracking of archived objects for purging. This parameter must also be set to true before you run the
ArchiveReferenceTrackingSync batch process to build the table of objects that you have already archived. In
the base configuration, this parameter is false.
See also
• “Identifying archived objects that affect destruction of data” on page 722
• “Work queues used in personal data destruction” on page 716
• Application Guide

Data destruction web service

ClaimCenter provides a web service that enables external software programs to initiate and track requests to destroy
data. In the base configuration, this web service, PersonalDataDestructionAPI, enables an external application to
request:
• Destruction of a contact’s data by AddressBookUID or by PublicID.
• Destruction of a user by user name.
In the base configuration, the PersonalDataDestroyer obtained by the class that implements
PersonalDataDestructionPlugin uses a Contact PublicID. You can configure the PublicID to correspond to an
entity other than Contact.
The requests for removal return a unique requesterID that can be used to check the status of the request.
Additionally, this requesterID is available in the plugin notification call when the request has been completed.

712 chapter 53 Configuring personal data destruction

 Configuration Guide 9.0.5

Note: The PersonalDataDestructionAPI web service checks for both retired and active contacts when a contact
data destruction request is received. When implementing data obfuscation for contacts, you must evaluate the need
to look for related objects that are retired in the database. Retired objects can be obfuscated in the same fashion as
active objects, but must be retrieved from the database with a query that is specified to look for retired objects. For
example: query.withFindRetired(true).

IMPORTANT The external software program that calls the web service must request and verify destruction of data
for a contact in ClaimCenter before requesting that ContactManager destroy the contact. If you have more than one
core application installed, the external application must request that the contact be destroyed in all of them before
sending the request to ContactManager. When ContactManager processes a request to destroy a contact, it first
verifies with all installed core applications that it can destroy the contact. If any core application indicates that the
contact cannot be destroyed, ContactManager does not proceed with the destruction request and notifies the web
service that the contact cannot be destroyed.

See also
• “Defining the destroyer” on page 724
• “Specifying which objects in the graph can be destroyed” on page 726

PersonalDataDestructionAPI web service methods

PersonalDataDestructionAPI provides the following methods:
• requestContactRemovalWithABUID(addressBookUID : String, requesterID: String) : String – A
request to destroy a contact by AddressBookUID. This method is implemented as an asynchronous process that
uses work queues.
• requestContactRemovalWithPublicID(contactPublicID : String, requesterID: String) : String –
A request to destroy a contact by PublicID. This method is implemented as an asynchronous process that uses
work queues.
• doesABUIDExist(addressBookUID: String): boolean – Uses translateABUIDToPublicIDs as defined in
the class that implements the PersonalContactDestroyer interface.
• doesContactWithPublicIDExist(publicID: String): boolean
• currentDestructionRequestStatusByRequestID(uniqueRequestID : String):
DestructionRequestStatus
• destroyUser(username : String) : boolean – Given a username, verifies the existence of the credential and
the user. This method is a synchronous destruction request that does not involve work queues.
◦ If the credential exists and the user does not, then the method obfuscates the credential and logs that the user
does not exist.
◦ If both credential and user exist, the method obfuscates the user, which obfuscates both the credential and the
UserContact object.
◦ The method returns a boolean value which is true if the user destruction succeeded, or false otherwise.
See also
• “Defining the destroyer” on page 724

Lifecycle of a personal data destruction request

The lifecycle of a contact removal request depends on the method that the external system calls to start the request.
The lifecycle, also called an asynchronous personal data destruction request, is started by a call either to
requestContactRemovalWithABUID or requestContactRemovalWithPublicID. For these two web service method
calls, the external system has either the AddressBookUID or the PublicID of the contact whose data to be destroyed.
The destroy action performed is defined in the ClaimCenter implementation of the PersonalDataDestruction
plugin interface.

Data destruction web service 713

 Configuration Guide 9.0.5

Note: The destroyUser method is synchronous and initiates obfuscation. It does not use work queues, and
therefore does not participate in the personal data destruction request lifecycle.
If the web service determines that the request is an existing one, it adds the specified requesterID value to the
existing destruction request and does not start a new request.
If the web service determines that the request is a new one, the web service:
1. Does the following depending on whether the request is for an AddressBookUID or PublicID:
• If the web service call was to requestContactRemovalWithABUID, the web service:
◦ Creates a PersonalDataDestructionRequest object for the AddressBookUID.
◦ Adds PersonalDataContactDestructionRequest objects for all related PublicID values, which are
obtained from a call to the PersonalDataDestroyer implementation.
• If the web service call was to requestContactRemovalWithPublicID, the web service:
◦ Creates a PersonalDataContactDestructionRequest object for the PublicID.
◦ Adds a PersonalDataDestructionRequest object if there is a related AddressBookUID obtained from a
call to the PersonalDataDestroyer implementation.
2. Adds a PersonalDataDestructionRequester object using requesterID.
3. The DestroyContactForPersonalData work queue checks for requests in the ReadyToAttemptDestruction
category, status New or ReRun, and calls the Destroyer.
The class PersonalDataContactDestructionWorkQueue, which implements this work queue, calls the
following method:

PersonalDataDestructionController.destroyContact(contactPurgeRequest)

• If the request status is in the DestructionStatusFinished category, the queue marks the date of
destruction for the contact destruction request.
• If the request status is ManualInterventionRequired, you must implement code that notifies the data
protection officer. That user must determine what to do and then set the status to ReRun so the
DestroyContactForPersonalData work queue can run it again.
4. The NotifyExternalSystemForPersonalData work queue looks at all
PersonalDataContactDestructionRequest objects that are associated with a
PersonalDataDestructionRequest. If they all have a status in the category DestructionStatusFinished,
the work queue does the notification.
5. The NotifyExternalSystemForPersonalData work queue notifies the external system by using
PersonalDataDestructionRequester objects. As part of this notification, the work queue calls the
PersonaDataDestruction plugin method notifyExternalSystemsRequestProcessed.
6. The RemoveOldContactDestructionRequest work queue removes all requests that satisfy both of the
following criteria:
• The date obtained by adding the value of the configuration parameter
ContactDestructionRequestAgeForPurgingResults to the value of
PersonalDataContactDestructionRequest.purgedDate is less than or equal to today’s date.
• The PersonalDataContactDestructionRequest object has a typecode that is in the
DestructionStatusFinished category.

714 chapter 53 Configuring personal data destruction

 Configuration Guide 9.0.5

Personal data destruction request entities

Three kinds of entities are created when a request is made to purge a contact:
• PersonalDataDestructionRequest – Holds the AddressBookUID and information regarding the parts and result
of this destruction request.
• PersonalDataContactDestructionRequest – Holds the PublicID of the Contact and its current destruction
status.
• PersonalDataDestructionRequester – Holds the external system requesterID that requested the purge and a
unique ID associated with the request assigned by ClaimCenter.

Example of a request made with AddressBookUID

If the call is made to the web service method requestContactRemovalWithABUID, and two contacts have the same
AddressBookUID, the destruction request causes the following instances to be created:
• One PersonalDataDestructionRequest
• Two PersonalDataContactDestructionRequest objects, one for each PublicID linked to the AddressBookUID
request
• One PersonalDataDestructionRequester
If the AddressBookUID is not found, an exception is thrown.
If an existing destruction request for AddressBookUID has AllRequestFulfilled equal to true, then the external
system is notified that destruction has already finished.

Example of a request made with PublicID

If two calls are made to the web service method requestContactRemovalWithPublicID for the same PublicID,
the destruction request would create:
• One PersonalDataDestructionRequest
• One PersonalDataContactDestructionRequest
• Two PersonalDataDestructionRequester objects
If the PublicID is not found, an exception is thrown.
If an existing destruction request with PublicD has AllRequestFulfilled on the
PersonalDataDestructionRequest equal to true, then the external system is notified that destruction has already
finished.

Typelists for status of personal destruction workflow

The personal destruction workflow uses typecodes to indicate various statuses. These typecodes are defined in three
typelists, ContactDestructionStatus, DestructionRequestStatus, and ContactDestructionStatusCategory.

ContactDestructionStatus
When a new contact destruction request is started, the initial status of the destruction object is New. These status
values are defined in the ContactDestructionStatus typelist. After a destruction attempt is made on the contact,
the destroyer is expected to return a status corresponding to how much it was able to destroy:
• New – The initial status of the destruction object when a new contact destruction request is started.
• NotDestroyed – Nothing could be destroyed.
• Partial – Some data was destroyed.
Not returned in the base configuration of ClaimCenter.
• Completed – Everything requested was destroyed.

Data destruction web service 715

 Configuration Guide 9.0.5

• ManualIntervention – There was an error. This status enables inspection by the Data Protection Officer and
must be set before setting ReRun.
Not returned in the base configuration of ClaimCenter.
In the base configuration, ClaimCenter provides code that notifies the Data Protection Officer in the plugin class
that implements PersonalDataDestruction. Additionally, after the Data Protection Officer takes action, the
method PersonalDataDestructionController.requeueContactRemovalRequestWithPublicID must be
called. You must configure a way to make that method call, such as a button in the ClaimCenter user interface.
• ReRun – Enables another attempt at destruction.

DestructionRequestStatus
You can retrieve the status of the entire destruction request through the Status property on the request itself. These
statuses are defined in the DestructionRequestStatus typelist. The general status of the entire destruction request
can be:
• DoesNotExist – The object to be destroyed does not exist.
• Unprocessed – Everything is still in the New status.
• InProgress – All other combinations of contact destruction statuses.
• Finished – Everything is in a final state.

ContactDestructionStatusCategory
Every ContactDestructionStatus typecode except ManualInterventionRequired has one or more categories.
• DestructionStatusNotProcessed – The request has not gone through the destruction process.
• ReadyToAttemptDestruction – Labels the contact purge request as being ready to be sent to the destroyer.
• DestructionStatusFinished – Indicates that the request has finished the destruction process.
• ReadyToBeNotified – Labels the request as ready to notify to the external system.
New and ReRun are under the category ReadyToAttemptDestruction.
New also is included in the category DestructionStatusNotProcessed.
Partial, NotDestroyed, and Completed are under both the category DestructionStatusFinished and the
category ReadyToBeNotified.

Work queues used in personal data destruction

There are a number of work queues for use in personal data destruction:

Work queue More information

DestroyContactForPersonalData “DestroyContactForPersonalData work queue” on page 716

NotifyExternalSystemForPersonalData “NotifyExternalSystemForPersonalData work queue” on page 717

RemoveOldContactDestructionRequest “RemoveOldContactDestructionRequest work queue” on page 717

ArchiveReferenceTrackingSync “ArchiveReferenceTrackingSync work queue” on page 717

DestroyContactForPersonalData work queue

This work queue finds all PersonalDataContactDestructionRequest objects that have a status set to New or
ReRun (category ReadyToAttemptDestruction). How far the destruction process went for the found contacts is
determined by the ContactDestructionStatus returned from the Destroyer, the class that implements the
PersonalDataDestroyer interface.
The contact destruction status is set to the returned status. If the status is Completed, Partial, or NotDestroyed
(category DestructionStatusFinished), the date of completion is also populated.
716 chapter 53 Configuring personal data destruction
 Configuration Guide 9.0.5

An exception is thrown if return status is New or if you try to change the status from a typecode in the
DestructionStatusFinished category.
Note: The class that implements this work queue is PersonalDataContactDestructionWorkQueue.

NotifyExternalSystemForPersonalData work queue

This work queue finds all PersonalDataDestructionRequest objects that have a status typecode in the
DestructionStatusFinished category and RequestersNotified set to false. Found requests are processed by
sending a notification to all associated requesters, and RequestersNotified is then marked true. If the notification
fails, an exception is thrown and RequestersNotified remains false.
Note: The class that implements this work queue is
PersonalDataDestructionNotifyExternalSystemsWorkQueue. In your implementation, you must verify that the
notification was successful before marking RequestersNotified true.
A method on the PersonalDataDestruction plugin, notifyExternalSystemsRequestProcessed, is called by the
PersonalDataDestructionNotifyExternalSystemsWorkQueue to notify external systems when a personal data
destruction request is completed. The original RequestID is passed to the method, which does nothing by default.
You are expected to implement this method to notify systems of interest. The RequestID is received when the
destruction request is originally created through the PersonalDataDestructionAPI web service.
Note: In the base configuration, the class that implements the PersonalDataDestruction plugin is
CCPersonalDataDestructionSafePlugin.
See also
• “Personal data destruction plugin implementation classes” on page 726

RemoveOldContactDestructionRequest work queue

This work queue finds all PersonalDataDestructionRequest, PersonalDataContactDestructionRequest, and
PersonalDataDestructionRequester objects that have the following values:
• RequestersNotified set to true
• PersonalDataContactDestructionRequest.DestructionDate plus the value of the
ContactDestructionRequestAgeForPurgingResults configuration parameter is less than or equal to today’s
date
• Each found request that has AllRequestsFulfilled equal to true is removed.
Note: The class that implements this work queue is RemoveOldContactDestructionRequestWorkQueue.

ArchiveReferenceTrackingSync work queue

You run this work queue once to find all references from any archived documents to any object instances in the
entity graph. This work queue creates a table of archived objects to make it faster to make this determination.
The class that implements this work queue is ArchiveReferenceTrackingSyncWorkQueue.
In ClaimCenter, this work queue also adds ClaimInfo to all claims, including archived claims.
See also
• For a full description of the ArchiveReferenceTrackingSync work queue, see “Identifying archived objects that
affect destruction of data” on page 722.

PersonalDataDestructionController class
This class handles the complete lifecycle of the asynchronous destruction process after a destruction request has
been made through the PersonalDataDestructionAPI web service. This class attempts to destroy the contact and
notify the requesters that the contact has been destroyed.

Work queues used in personal data destruction 717

 Configuration Guide 9.0.5

The class provides the following methods relating to the lifecyle:

• notifyRequesterDestructionRequestHasFinished(destructionRequester:
PersonalDataDestructionRequester) – Takes a requester and notifies the external system that the request
with related AddressBookUID and PublicID values was processed and finished.
• destroyContact(contactDestructionRequest: PersonalDataContactDestructionRequest) – Called by
PersonalDataContactDestructionWorkQueue, the class that implements the
DestroyContactForPersonalData work queue, when attempting destruction. Uses the class that implements the
PersonalDataDestroyer interface to destroy the contact, and returns a ContactDestructionStatus. Verifies
status and sets appropriate PersonalDataContactDestructionRequest and
PersonalDataDestructionRequest attributes.
• requeueContactRemovalRequestWithPublicID(publicID : String, bundle : Bundle) – Sets purge
request status to ReRun after manual intervention, allowing the purge request to be reattempted for destruction.
See also
• “Data destruction web service” on page 712
• “Defining the destroyer” on page 724

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 718
• “Do Not Process flag” on page 719
• “Display keys for data destruction messages” on page 719
• “Obfuscatable delegate” on page 719
• “Obfuscator interface” on page 720
• “Marking entity fields for obfuscation” on page 720
• “ContactInfo support for personal data destruction” on page 721

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.
See also
• “ContactInfo support for personal data destruction” on page 721

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 ClaimCenter. Even if the
contact is linked, the field is not sent to ContactManager, nor is it updated from ContactManager.

718 chapter 53 Configuring personal data destruction

 Configuration Guide 9.0.5

In the base configuration of ClaimCenter, the entities Contact, ContactInfo, Claim, and ClaimInfo implement the
DestructionRootPinnable delegate and therefore have DoNotDestroy boolean fields. The default value of the
field is false, which permits destruction of the entity. If this field is set to true, the entity cannot be purged.
You can set this field only for Contact, ContactInfo, and ClaimInfo objects. Use the markDoNotDestroy method
to set the field. For example:

ClaimInfo.markDoNotDestroy(true)

You cannot set this field on a Claim object. In the base configuration, the ClaimCenter personal data destruction
code does not check this field on a claim.

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 ClaimCenter. 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:

PersonalData.Error.ObfuscateNotImplemented = 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.

Data model configuration for data destruction 719

 Configuration Guide 9.0.5

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, UserContact.etx has the following definition:

<extension xmlns="http://guidewire.com/datamodel"
entityName="UserContact">
<implementsInterface
iface="gw.api.obfuscation.Obfuscator"
impl="gw.personaldata.obfuscation.UserContactObfuscator"/>
<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
PersonalDataObfuscator.

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="gw.api.personaldata.Obfuscator"
impl="gw.api.personaldata.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 729
• “Implementing the Obfuscator interface in an entity” on page 728

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

720 chapter 53 Configuring personal data destruction

 Configuration Guide 9.0.5

the kind of obfuscation that will be applied to the field's contents. In the base configuration, two values are defined
in the typelist PersonalDataTagValue.tti:
• ObfuscateDefault – The field's contents are replaced with the default value or null if no default value is
defined.
• ObfuscateUnique – The field's contents are replaced as you define.
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 Contact.etx 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.
• AddressBookConvertible.etx
• GlobalAddress.etx
• GlobalAddress.Global.etx
• GlobalContactName.etx
• GlobalContactName.Global.etx
• GlobalPersonName.etx
• GlobalPersonName.Global.etx
See also
• For a list of entities that implement Obfuscator, see “Implementing the Obfuscator interface in an entity” on
page 728

ContactInfo support for personal data destruction

The ContactInfo entity can retain data about contacts that have been archived. This entity supports locating
contacts that need to be purged that are live and those that are archived, identified by either PublicID or
AddressBookUID.
Fields of ContactInfo that provide this support are:
• ArchivedPublicID – Records the PublicID of an archived contact.
• ArchivedAddressBookUID – Records AddressBookUID of the archived contact. This value is null if the contact
is not linked.
When personal data destruction is enabled, as a claim is being archived:
• The PublicID and AddressBookID values are stored in ContactInfo.
• All contacts on a claim have a corresponding ContactInfo entity created.
ContactInfo also remains backwards compatible with existing user interface pages for archiving. As a result, a
contact can have more than one ContactInfo object generated for it if the contact is both an Insured and a Claimant.
If personal data destruction is not enabled, ContactInfo is a denormalized entity that stores simple fields, such as a
contact's first and last names, role, and some other simple data. Additionally, only contacts that have the role of

Data model configuration for data destruction 721

 Configuration Guide 9.0.5

Insured or Claimant have ContactInfo data created. This data can be used for simple searches and other user
interface purposes.

Entity domain graphs

ClaimCenter 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.
• 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 ClaimCenter, the root entity is ClaimInfo.
• The boundary defines what is inside the aggregate cluster of objects. It identifies all the entities that are part of
the graph.
In ClaimCenter, the boundary defines the entities that relate to a ClaimInfo object, such as Claim and its related
Exposure, Coverage, Matter, and other similar objects.
The unit of work for personal data destruction is a single instance of the domain graph, for example, a single
ClaimInfo object 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
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 ClaimCenter archive domain graph” on page 325
• “Delegate data objects” on page 182

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 claims, 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 ClaimCenter 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 claims in an existing installation of ClaimCenter, you must run the
ArchiveReferenceTrackingSync batch process once to build the initial table of archived objects.
Additionally, previously existing archived claims do not possess sufficient data for personal data removal and need
to be updated. These existing archived claims have ContactInfo data that lacks ArchivedPublicID and
ArchivedAddressBookUID information, and that data exists only for contacts in a claimant or insured role. Running
ArchiveReferenceTrackingSync updates the ContactInfo data for contacts of all archived claims.
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.

722 chapter 53 Configuring personal data destruction

 Configuration Guide 9.0.5

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, ClaimCenter calls

DataDestructionParameterCheck.verifyPersonalDataDestructionEnabled 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 claims, 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 gw.api.archiving.ArchiveDocumentReferencesUtil 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.
See also
• “ContactInfo support for personal data destruction” on page 721

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 ClaimCenter, the Data Protection Officer role has the following permissions relating to
personal data destruction:
• requestcontactdestruction
• editobfuscatedusercontact
This role also has additional permissions to enable the user to work with users and groups. These permissions
include groupcreate, groupdelete, groupedit, usereditattrs, usereditlang, useredit, usergrantroles,
userviewall, grouptreereview, groupreview, and userview.
In the base configuration, ClaimCenter screens prevent a user from editing obfuscated user contacts if the user does
not have permissions to do so. In addition, ClaimCenter prevents a user without the correct permissions from adding
obfuscated user contacts to or removing them from groups and roles. You can create additional permissions and
configure ClaimCenter 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,
CCPersonalDataDestructionSafePlugin, overrides the notifyDataProtectionOfficer method. In this class,
the notifyDataProtectionOfficer method logs messages to the system console if a destruction request fails. You
can configure where these messages are logged as needed.

Data Protection Officer 723

 Configuration Guide 9.0.5

Data destruction purge configuration

Purging is the process of completely removing data from the ClaimCenter database.
• A purge can start with a claim and proceed through the claim graph to include associated objects. That type of
purge is generally associated with claims that are a certain age and no longer need to be preserved or archived.
That type of purge is described at the System Administration Guide.
• A purge can start with a contact and proceed to one or more claims. That type of purge is called personal data
destruction. There can be multiple objects associated with the claim or contact that are also removed as they are
detected by traversing the entity domain graph. Configuring that type of purge is described in the topics that
follow.

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 722
• “Data obfuscation in ClaimCenter” on page 727

Purging and the ClaimCenter entity domain graph

In the base configuration of ClaimCenter, methods of the class PersonalDataPurger call ClaimCenter methods that
traverse the ClaimInfo graph. These methods can purge objects that are on the graph and objects that are related to
the claim but not on the graph, such as MessageHistory objects.
Note: Claim purging is a feature of ClaimCenter used by personal data destruction, but exists separately for
destruction of claims that have aged out or are incomplete.
The following PersonalDataPurger methods are called from CCPersonalDataDestroyer and can also be called
from Gosu classes:

public static void purge(entity.ClaimInfo claimInfo)

public static void purge(entity.Claim claim)

See also
• “Defining the destroyer” on page 724
• “Entity domain graphs” on page 722
• “Claim purging and the archive domain graph” on page 328

Defining the destroyer

The CCPersonalDataDestroyer class implements the PersonalDataDestroyer interface and overrides the
PersonalDataDestroyer interface methods that determine how a destruction request is carried out. The class
provides methods that are called by the PersonalDataDestructionAPI web service and its work queues.
A personal data destruction request to delete a contact by AddressBookUID can correspond in ClaimCenter to many
contacts with different PublicID values on many claims. The method translateABUIDToPublicIDs finds all these
PublicID values and returns them to the web service, and then the web service makes a series of destroyContact
method calls to delete each PublicID.
If a personal data destruction request specifies deleting a contact by PublicID, there can be at most one
corresponding claim, so the processing by the web service is simpler.
The following two methods are the primary Destroyer methods used by the web service.

724 chapter 53 Configuring personal data destruction

 Configuration Guide 9.0.5

translateABUIDToPublicIDs
This public method overrides the PersonalDataDestroyer interface method translateABUIDtoPublicIDs. It
finds all the contacts related to the AddressBookUID and all archived contacts as well, and returns a list the
PublicID values for those contact.
The method is called by the web service PersonalDataDestructionAPI. The web service uses the method to
determine if an AddressBookUID exists and to get the PublicID if the original destruction request was specified by
AddressBookUID.

destroyContact by destruction request

This public method overrides the PersonalDataDestroyer interface method destroyContact. It is the main entry
point for destroying contacts.
This method takes a PersonalDataDestructionRequest and finds the corresponding Contact and its Claim from
the registered PublicID. For an archived contact, the method uses the registered PublicID to find the ContactInfo
and its associated ClaimInfo.
Once the Contact and Claim are found, a call to the PersonalDataDestruction plugin is made to determine
whether the Contact and Claim can be purged.
• If the result of the plugin call is MUST_NOT_DESTROY, the request is not processed for destruction. The reason is
logged in the DATA_DESTRUCTION_REQUEST logger and the Destroyer returns the status
ContactDestructionStatus.TC_NOTDESTROYED.
• If the result of the plugin call is MAY_DESTROY or MUST_DESTROY, the request is processed for destruction and
PersonalDataPurger.purge(claim) is invoked.
◦ If the purge is successful the Destroyer returns the status ContactDestructionStatus.TC_COMPLETED.
◦ If there is a purge error, the Destroyer returns the status ContactDestructionStatus.TC_NOTDESTROYED and
the error or exception is logged in the DATA_DESTRUCTION_REQUEST logger.
It is possible that the contact was previously purged and cannot be found. For example, a previous
PersonalDataDestructionRequest resulted in the Contact being purged. In that case, the method returns
ContactDestructionStatus.TC_COMPLETED.
See also
• “Data destruction web service” on page 712

PersonalDataPurge event
When a personal data purge of certain objects is committed, ClaimCenter 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.
ClaimCenter generates a PersonalDataPurge event when a ClaimInfo purge is committed as part of a personal
data purge. In the base configuration, there is no rule that responds to this event, but you can create an EventFired
rule in the EventMessage rule set category that sends a message.
Your rule could take the following form in the Guidewire Studio Rules editor:

USES:
uses gw.api.locale.DisplayKey

CONDITION (messageContext : entity.MessageContext):

return messageContext.EventName == "PersonalDataPurge"

ACTION (messageContext : entity.MessageContext, actions : gw.Rules.Action):

var claimInfo = messageContext.Root as ClaimInfo
messageContext.createMessage(
"Claim with number ${claimInfo.ClaimNumber} has been successfully purged")

Data destruction purge configuration 725

 Configuration Guide 9.0.5

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 PersonalDataDestruction.gwp plugin registry.

PersonalDataDestruction plugin interface

This interface provides the following methods for implementation by a ClaimCenter 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, ClaimCenter registers the CCPersonalDataDestructionSafePlugin 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 CCPersonalDataDestructionSamplePlugin class.
See also
• “Personal data destruction plugin implementation classes” on page 726
• “Entity domain graphs” on page 722

Personal data destruction plugin implementation classes

In the base configuration of ClaimCenter, the CCPersonalDataDestructionSafePlugin class is registered as the
class that implements the PersonalDataDestruction plugin interface. This class provides default handling for
destruction of pinnable root entities in the base configuration. It prevents destruction of any personal data.
CCPersonalDataDestructionSamplePlugin 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 the plugin registry PersonalDataDestruction.gwp.
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.

CCPersonalDataDestructionSafePlugin
In the base configuration, CCPersonalDataDestructionSafePlugin calls getDestroyer to obtain the destroyer
defined in CCPersonalDataDestroyer. Additionally, this class prevents data destruction by returning
MUST_NOT_DESTROY for all calls to destroy pinnable root entities. For example:

override function shouldDestroyRoot(

root: DestructionRootPinnable,
descendants: Collection<DestructionRootPinnable>,
origin: DestructionRootPinnable): PersonalDataDisposition {
CCPersonalDataLogUtil.logNotDestroyed(
root, "Safe plugin implementation always returns MUST_NOT_DESTROY")

726 chapter 53 Configuring personal data destruction

 Configuration Guide 9.0.5

return MUST_NOT_DESTROY
}
override function shouldDestroyUser(
userContact: UserContact): PersonalDataDisposition {
CCPersonalDataLogUtil.logNotDestroyed(
userContact, "Safe plugin implementation always returns MUST_NOT_DESTROY")
return MUST_NOT_DESTROY
}

CCPersonalDataDestructionSamplePlugin
You can use the class CCPersonalDataDestructionSamplePlugin as a guide for writing your own personal data
destruction code. This class has examples that can return values other than MUST_NOT_DESTROY for a pinnable root
entity.
Some examples:
• The class respects the setting of the DoNotDestroy field. For example, it does not destroy a Contact if
DoNotDestroy is set to true.
• If a claim has been closed for at least two years, it can be purged.
• If a claim is archived, it can be purged.
• If a claim cannot be found, MustNotDestroy is returned. For example:
◦ The Contact is a BulkInvoice payee.
◦ The Contact exists only as a related contact without its own role on a claim.
◦ The Contact is an orphan—has no connection to a claim or any other object.
See also
• “Do Not Destroy flag” on page 718
• “Identifying archived objects that affect destruction of data” on page 722

Data obfuscation in ClaimCenter

In general, personal data destruction in ClaimCenter is done through removal of database records. However, the
entities associated with an employee who works in your installation of ClaimCenter are not conducive to removal
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, ClaimCenter 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 ClaimCenter configuration capabilities. In your obfuscation implementation, you must take into
account how your custom obfuscation might affect existing processes in ClaimCenter.

Data obfuscation in ClaimCenter 727

 Configuration Guide 9.0.5

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 720
• “Implementing the Obfuscator interface in an entity” on page 728
• “Obfuscatable delegate” on page 719
• “Do Not Destroy flag” on page 718

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 DefaultPersonalDataObfuscator.

The entities that have Obfuscator implementations that support obfuscation are:
• Credential – CredentialDefaultObfuscator
Has fields and typekeys marked PersonalData.
• OfficialID – DefaultPersonalDataObfuscator
Has fields and typekeys marked PersonalData.
• User – UserObfuscator
Has fields and typekeys marked PersonalData.
• UserContact – UserObfuscator.
This entity is a subtype of Person, which is a subtype of Contact. It inherits the Contact implementation of the
Obfuscatable delegate and overrides the Contact implementation of the Obfuscator interface. In the base
configuration, the EmployeeNumber field is marked PersonalData.
The following entities implement the Obfuscatable delegate, and in the base configuration their Obfuscator
interface implementation is UnsupportedObfuscator:
• Address
• Contact – Has fields and typekeys that are marked PersonalData.
• ContactCategoryScore
• Person – Inherits obfuscation settings from Contact. Has fields and typekeys that are marked PersonalData.

728 chapter 53 Configuring personal data destruction

 Configuration Guide 9.0.5

See also
• “Obfuscator interface” on page 720

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 gw.api.obfuscation.Obfuscator.
This topic includes:
• “Personal data obfuscation class hierarchy” on page 729
• “PersonalDataObfuscator” on page 730
• “UnsupportedObfuscator” on page 730
• “PersonalDataObfuscatorUtil” on page 730
See also
• “Implementing the Obfuscator interface in an entity” on page 728
• “Obfuscator interface” on page 720
• “Marking entity fields for obfuscation” on page 720

Personal data obfuscation class hierarchy

ClaimCenter provides the following class hierarchy for personal data obfuscation:

ClaimCenter Personal Data Obfuscator Class Hierarchy

PersonalDataObfuscator

DefaultPersonalDataObfuscator

UserContactLinkedObfuscator

UserDefaultObfuscator UserContactDefaultObfuscator CredentialDefaultObuscator

Legend
UserObfuscator UserContactObfuscator
A B A is a subclass of B

DefaultPersonalDataObfuscator and 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
Data obfuscation in ClaimCenter 729
 Configuration Guide 9.0.5

user.Credential.obfuscate and user.Contact.obfuscate 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.
• UserObfuscator overrides the beforeObfuscate method to remove the user’s authority profile, but only if there
is only one owner and there are no archived references.
• UserContactObfuscator overrides the beforeObfuscate method to remove unreferenced ETF records.

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.
PersonalDataObfuscator handles setting the obfuscation for marked 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.
◦ 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
ObfuscatablePublicMethod.setObfuscated.
• obfuscateSimple – Works the same as obfuscate.
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 720

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, gw.personaldata.obfuscation.
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.

730 chapter 53 Configuring personal data destruction

 Configuration Guide 9.0.5

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 720

Personal data obfuscator classes 731

 Configuration Guide 9.0.5

732 chapter 53 Configuring personal data destruction

part 9

Guidewire ClaimCenter financials

Configuration Guide 9.0.5
chapter 54

Configuring ClaimCenter financials

This topic explains the data model and financial values managed by the ClaimCenter Financials. It explains how to
configure both the financials behavior and the ClaimCenter interface to better match your business practices.

The financials data model

The following table contains the key financials entities in the data model that you see in the ClaimCenter base
configuration. Refer to the ClaimCenter Data Dictionary to see other financial-related entities.

Entity or field Description

Check An entity that groups one or more payments made at the same time to a single payee or group of joint
payees. ClaimCenter sends it to an external system to be printed, unless it is a manual check not
created by the application.
CheckGroup An entity that groups together a multipayee check, with a primary check and one or more secondary
checks.
CheckSet The entity that collects all Checks resulting from a single usage of the New Check wizard. It includes all
issuances of a recurring Check and checks of a multipayee Check. It is a subtype of TransactionSet.
All Checks belong to a CheckSet.
CostCategory A Transaction field that categorizes a transaction. In the base configuration, the CostCategory typelist
includes values that you can use as filters to support the various Lines of Business (LOBs)
CostType A Transaction field that categorizes a transaction. In the base configuration, the CostType typelist
includes the following typecodes:
• aoexpense – Adjusting and other expense
• claimcost – Actual loss payments to claimants or repairers
• dccexpense – Defense and cost containment legal expense
• unspecified – Unspecified cost type
Deductible The entity that tracks the amount, the coverage, and the status of the deductible, such as whether it
has been paid or waived. One of the main fields on the Deductible entity is TransactionLineItem,
which is a foreign key to TransactionLineItem.

Configuring ClaimCenter financials 735

 Configuration Guide 9.0.5

Entity or field Description

Line Category A field in a TransactionLineItem that categorizes the amount of that line item.
Payment A subtype of Transaction representing money paid out. A payment can be eroding or non-eroding,
depending on whether it draws down the reserves of its ReserveLine.
Recovery An entity that records money that reduces a claim’s liability, received from such sources as
subrogation, salvage, other insurance, co-payments or deductibles. A Recovery object is a subtype of
Transaction.

RecoveryReserve An entity that records the amount of future expected recoveries. It is a subtype of Transaction.
Reserve An entity that records a potential liability. It is a subtype of Transaction. A Reserve designates money
to be set aside for payments. Typically, a reserve is set soon after a claim is made.
ReserveLine An entity with a unique combination of Claim, Exposure, CostType, and CostCategory fields. Only E
xposure can be null. Reserves or recovery reserves are created, or payments are made, or recoveries
are applied against one ReserveLine.
Transaction An entity that represents a financial transaction for a particular claim or exposure. It also contains a
non-empty array of TransactionLineItem entities.
Transaction is an abstract supertype. The ClaimCenter interface uses its subtypes:
• Reserve
• Payment
• RecoveryReserve
• Recovery
These subtypes are final. Transaction must not be subtyped further. A new subtype will not function
correctly, may interfere with existing code and is not supported.
Every transaction is made against a single ReserveLine object.
TransactionLineIte An entity in every transaction that contains the amount of the transaction. Payment and Recovery
m transactions can have more than one Transaction Line Item. Use the LineCategory and Comments
fields to describe a given Transaction Line Item’s contribution to the total transaction amount.
TransactionOnset This join entity contains a foreign key to the Transaction entity and represents the relationship
between a transaction and its onset. It links a Transferred or Recoded transaction (Payment or
Recovery) to its new onset transaction.
TransactionOffset This join entity contains a foreign key to the Transaction entity and represents the relationship
between a transaction and its Offset. It links a Voided, Stopped, Recoded, or Transferred transaction
(Payment or Recovery) to its new onset transaction.
TransactionSet A collection of all transactions made at the same time and approved together. This collection can be,
for example, a check and all the payments it makes.
TransactionSet is an abstract supertype. The ClaimCenter interface uses the following subtypes of Tr
ansactionSet:
• ReserveSet
• CheckSet
• RecoveryReserveSet
• RecoverySet
CheckSet is a subtype of TransactionSet. A check is not a Transaction. The checks in the set, while
created at the same time, can be issued at different times and to different payees. You can also
associate documents with a TransactionSet.
All transactions (and checks) in a Transaction Set must be:
• Approved together
• Rejected together
• In Pending Approval status together

736 chapter 54 Configuring ClaimCenter financials

 Configuration Guide 9.0.5

Transactions and cost types

Transaction entities are the key to understanding ClaimCenter financials. A transaction is linked either to a claim
or to an exposure (and every exposure is linked to a claim). A Transaction can have a CostType attribute whose
value is non-nullable. You can use the default cost types or create others that reflect your business process. In the
base configuration, ClaimCenter provides the following cost types:

aoexpense Overhead costs such as adjusting and other expenses.

claimcost Indemnity losses—actual loss payments to claimants or repairers.
dccexpense Legal costs for defense and cost containment.

unspecified Unspecified cost type

ClaimCenter applies a transaction against a specific ReserveLine. A ReserveLine is a unique combination of

Claim, Exposure, CostType, and CostCategory.
A Transaction must have at least one—and can have more—TransactionLineItem objects. The
TransactionLineItem object contains an actual value amount. The value of an individual Transaction is the sum
of its TransactionLineItem amounts. Each TransactionLineItem has an associated LineCategory that further
classifies its cost type, for example doctor’s care, physical therapy, and so forth. You can configure the Line
Categories to reflect your business practices.
See also
• Application Guide

Financials-related typelists
The following typlists contain values that you can modify to manipulate the financial configuration in your
ClaimCenter installation:

Typelist Description
BankAccount Lists bank accounts available from the ClaimCenter interface.
BiValidationAlertType Lists the possible alert types returned from the bulk invoice validation plugin.
CheckBatching ClaimCenter populates the Check Batching drop-down list on the check wizard from this list.
Note: The bulkcheck typecode on this typelist has nothing to do with Bulk Invoices.
CheckHandlingInstructions Specifies handling instructions for a check. ClaimCenter populates the Check Instructions drop-
down list on the check wizard from this list.
CostCategory Categories for different costs associated with financial transactions.
CostType Defines different costs associated with your business. ClaimCenter uses the values in this
typelist as a key filter for the CostCategory typelist.
CoverageType Types of coverage available on a claim. ClaimCenter uses the values in this typelist as a key
filter for the CostCategory typelist.
DeductionType Types of deductions that can appear on a check. The typical use for this typelist is to categorize
both a Deduction entity and a secondary check on a multipayee check.
FinancialSearchField Search fields used while searching for checks or recoveries.
LineCategory Populates the Category drop-down on the Payment Information page of the check wizard. Use to
categorize the Amount of a Transaction Line Item.
PaymentMethod Requested payment method for all payments in a check. For example, use to set whether to
send the check as a paper check or EFT.

Transactions and cost types 737

 Configuration Guide 9.0.5

Financial transaction statuses

You can think of a financial transaction as having a life cycle. During its life cycle, as a transaction transitions from
one state to another, the TransactionStatus attribute on the transaction changes. The property on Transaction
that stores the status is called Status. This is a typekey in the TransactionStatus typelist. Review the
TrasactionStatus typelist in the Data Dictionary for a full list of the possible transaction statuses.
You can access the Transaction.Status property from both the ClaimCenter interface and from within Gosu rules.
Its primary use is to indicate the current business state of a transaction, as well as act on the business state of the
transaction.
The following are all valid values for the Transaction.Status property.
• Awaiting submission
• Cleared
• Denied (checks and payments only)
• Issued
• Notifying (manual checks only)
• Pending approval
• Pending recode
• Pending stop
• Pending transfer
• Pending void
• Recoded (payments and recoveries only)
• Rejected
• Requested (checks only)
• Requesting (checks only)
• Stopped (payments only)
• Submitted
• Submitting
• Transferred (payments, checks, and recoveries only)
• Voided (payments, checks, and recoveries only)

Submitted Transactions
Submitted transactions are a subset of Approved transactions. A transaction is considered to be Submitted if its
Status is any of the following:

• Pending • Recoded • Transferred

• Pending Stop • Stopped • Voided
• Pending Transfer • Submitted
• Pending Void • Submitting

738 chapter 54 Configuring ClaimCenter financials

 Configuration Guide 9.0.5

Awaiting Submission Transactions

A transaction is considered to be Awaiting Submission if its Status is AwaitingSubmission. Only payments and
reserves can have this status:
• AwaitingSubmission payments are those payments whose containing Check has not yet been escalated.
• AwaitingSubmission reserves are those reserves that are tied to an AwaitingSubmission payment in order to act as
an offsetting reserve.
Payments with a Status of AwaitingSubmission can also be future-dated. FutureDated payments are those
approved payments whose containing Check has a scheduled send date after the current day.

Pending Approval Transactions

A transaction is considered to be Pending Approval if its Status is PendingApproval.

Approved Transactions
A transaction is considered to be Approved if its Status is any of the following:

• AwaitingSubmission • Pending void • Submitting

• Pending recode • Recoded • Transferred
• Pending stop • Stopped • Voided
• Pending transfer • Submitted

See also
• Application Guide

Financial configuration parameters

Guidewire provides a number of configuration parameters related to ClaimCenter financials. These include the
following:

• AllowMultipleLineItems • ExchangeRatesCacheRefreshIntervalSecs
• AllowMultiplePayments • Financials
• AllowNegativeManualChecks • MulticurrencyDisplayMode
• AllowNoPriorPaymentSupplement • PaymentLogThreshold
• AllowPaymentsExceedReservesLimits • PaymentRoundingMode
• CheckAuthorityLimits • ReserveRoundingMode
• CloseClaimAfterFinalPayment • SetReservesByTotalIncurred
• CloseExposureAfterFinalPayment • UseDeductibleHandling
• DefaultApplicationCurrency • UseRecoveryReserves
• DefaultRoundingMode

Financial configuration parameters 739

 Configuration Guide 9.0.5

See also
• “Financial parameters” on page 66 for a discussion of the parameters related to financials.

Batch processes related to checks and payments

There are three batch process that ClaimCenter runs automatically to process financial transactions. This topic
describes how those batch processes impact checks and payments.

The financials escalation process

ClaimCenter periodically runs a financialsesc batch process that looks for checks that are ready for submission. A
check is automatically eligible for submission:
• If it has a TransactionStatus of awaitingsubmission
• If it has a scheduled send date that is either today or earlier
• If it is not part of a bulk invoice
Note: If a check is marked for PendEscalationForBulk, then it will not be submitted.
As ClaimCenter escalates a check through the financialsesc process, it does the following:
• ClaimCenter updates all the associated T-accounts, unless the taccountesc process has already run and
performed this task.
• ClaimCenter creates any necessary offsetting reserves. This and any other associated reserve changes are given
submitting status. For example, if an eroding payment exceeds its available reserves, it requires an offset to
keep its available reserves from becoming negative (unless taccountesc has already run and done this).
• ClaimCenter changes the TransactionStatus for the check to requesting. At this point, it is possible to send a
message to issue the check to a check writing system.
• ClaimCenter changes the TransactionStatus on all the associated payments to submitting.
• If a payment being escalated is final:
◦ And the payment has an exposure, then ClaimCenter closes its exposure, provided it has no payments
scheduled for sending after today.
◦ And the payment is claim-level, then ClaimCenter closes its claim, provided the claim has no open exposures
and no payments scheduled for sending after today.
If either of these close actions result in a validation error or warning, ClaimCenter creates a reminder activity
showing the error or errors. It then tries to assign the activity to the user that created the payment. If that fails, it
uses auto-assignment to assign the activity. The due date for the activity is today, its priority is normal, and no
escalation date is set.
• ClaimCenter runs the Transaction Post-Setup rules.
• If the check is a recurring check and it is the second-to-last check to be submitted in the recurrence, then
ClaimCenter creates a reminder activity. The activity simply indicates that the recurrence is ending soon.
By default the financialsesc process runs twice a day. It runs the first time at 6:05 a.m. and the second time at
6:05 p.m. To change this value, edit the scheduler-config.xml file. Alternatively, you can also start the process
from the command line to force it to run immediately.

maintenance_tools -startprocess financialsesc -password <password> -user <username>

You can also create a Gosu rule to escalate a check by using the Check.requestCheck method.

740 chapter 54 Configuring ClaimCenter financials

 Configuration Guide 9.0.5

Note: If entering the date for escalation, enter a day only but not a time. If a time is present, the batch process
delays escalation until the first time it runs on the next day.

The TAccounts Escalation process

The TAccountEsc batch process updates T-accounts and summary financial values to reflect the fact that a check is
going to be issued on that date, without the check being issued. The process moves a Check's payments from a
Future Dated state to an AwaitingSubmission today state. (The Status remains AwaitingSubmission.)
Financials calculations such as Total Payments and Open Reserves include payments waiting to be sent today. Thus,
the TAccountEsc process updates those calculations shown in the Financials Summary screen to reflect payments that
will now be sent today. However, since the Checks are still in Awaiting Submission, it is still possible to edit them
until they are escalated by the financialsesc batch process.
When a payment contributes to Open Reserves by eroding reserves, it can make Open Reserve negative. In this case,
ClaimCenter automatically creates offsetting reserves during this batch process to keep OpenReserves at zero.
The TAccountEsc batch process does the following:
• It correctly updates the relevant T-accounts to reflect the fact that the check reached its send date.
• It creates any necessary zeroing-offsets for the payments for each check (if the payment exceeds reserves). This
and any other associated reserve changes are given awaiting submission status, which means that they can still
be retired if their associated payments are retired or changed. For example, if an eroding payment exceeds its
available reserves, it requires an offset to keep its available reserves from becoming negative.
By default, taccountesc runs at 12:01 a.m. every day. You can reschedule the taccountesc batch process by
editing the scheduler-config.xml file. You can also start the process from the command line to force it to run
immediately.

maintenance_tools -startprocess taccountesc -password <password> -username <username>

IMPORTANT The taccountesc batch process works with the T-account balances and the calculated financials
values that depend on these balances. It ensures that these balances are correct during the interval between
midnight and the first scheduled execution of the financialsesc batch process for the day. Guidewire
recommends that you schedule the taccountesc batch process to run as close to just-past midnight as possible and
before the financialsesc batch process.

The bulk invoice escalation process

As its name implies, the bulkinvoiceesc process escalates the status of bulk invoices in your installation. If this
process runs, it does the following:
• Queries for all bulk invoices with a status of awaitingsubmission and a scheduled send date of the current day
or earlier.
• Sets the status of each returned bulk invoice to requesting.
• Locates all of the invoice items for which an associated check exists. If the check property
pendescalationforbulk==true and the check status==awaitingsubmission, then the process escalates the
check also. This has the effect of also moving the invoice item to the submitting status.
By default, the bulkinvoiceesc process runs every day at 6:35 a.m. and 6:35 p.m. You can reschedule the
bulkinvoiceesc batch process by editing the scheduler-config.xml file. Alternatively, you can also start the
process from the command line to force it to run immediately.

maintenance_tools -startprocess bulkinvoiceesc -password <password> -username <username>

Batch processes related to checks and payments 741

 Configuration Guide 9.0.5

Note: Do not schedule the bulkinvoiceesc process to run at the same time as the financialsesc process.
Running these two at the same time makes both processes take much longer than necessary to complete.

The PendEscalationForBulk Property

Checks associated with a bulk invoice are normally escalated whenever the Bulk Invoice is escalated. If
PendEscalationForBulk on a check is set to true, then batch process bulkinvoiceesc escalates the check. You
can set Check.PendEscalationForBulk to false, for example, if your downstream system automatically batches
together checks to the same payee, and you want BIItem checks escalated individually.
This property has the following meanings:
• PendEscalationForBulk==true. Guidewire sets this property to true by default, upon the initial creation of a
Check for a BIItem. A value of true means that ClaimCenter escalates the Check at the same time as the
bulkinvoiceesc batch process escalates the BulkInvoice.
• PendEscalationForBulk==false. It is possible to change the value of this property to false through Gosu
rules. A value of false indicates that ClaimCenter escalates the Check as part of the standard financialsesc
batch process.
Another property, Check.Bulked, indicates whether ClaimCenter associates a Check with a BulkInvoiceItem.
The escalation process only updates data inside Guidewire ClaimCenter. Communicating the escalation to an
external system is done by actions taken in Event Messaging rules and your messaging plugin implementations.

Scheduling the financials batch processes

In the default application, the financialsesc batch process runs twice a day, at 6:05 a.m. and 6:05 p.m. If you do
not run the taccountesc batch process earlier in the day, then the Financials Summary screen can potentially display
out-of-date values. The values are out-of-date from midnight until the time that the financialsesc batch process
does run.
Depending on your implementation, you can schedule these two batch processes differently. For example:
• Schedule one of these two processes to run before the calculated values need to be up-to-date, for example,
before people arrive for work.
• Run taccountesc as soon after midnight as possible and schedule financialsesc at your midday time to keep
checks editable until sometime during the last available working day.
• Schedule financialsesc just after midnight if you do not care about not being able to edit future-dated checks
that have reached their send date before financialsesc runs. In this case, you need not run taccountesc.
See also
• Application Guide
• System Administration Guide
• Integration Guide

742 chapter 54 Configuring ClaimCenter financials

chapter 55

ClaimCenter financial calculations

This topic describes the financial calculation APIs that Guidewire provides in Guidewire ClaimCenter.
See also
• “Creating financial transactions” on page 759

Financial calculation APIs

Guidewire provides a number of APIs to facilitate various operations with financial calculations. You access these
APIs in the following package:

gw.api.financials

Two sets of different classes are available for use with financial calculations—FinancialsCalculations and
FinancialsCalculationUtil. Both classes contain methods with similar names, but note that they have different
return types.

IMPORTANT Guidewire recommends using the FinancialsCalculations and FinancialsCalculator classes.

The getAmount methods on the FinancialsCalculation class are provided for backwards compatibility.

The FinancialsCalculations class

The FinancialsCalculations class provides financial calculation objects and some of the methods that can be
used to retrieve calculated amounts.
This is the preferred API for financial calculations, and Guidewire recommends using this primarily.

ClaimCenter financial calculations 743

 Configuration Guide 9.0.5

gw.api.financials.* Returns
FinancialsCalculations • FinancialsCalculator objects
Sample methods
• getFinancialsCalculation(FinancialsExpression)
• getFuturePayments
• getSubmittedOpenReserves
FinancialsExpression A composite FinancialsExpression provides a building block for custom financial calculations.
You can construct a custom expression by adding or subtracting FinancialsExpression
instances. The resulting custom expression can then be used to create a new FinancialsCalcula
tion to retrieve a calculated amount.
You can wrap a FinancialsExpression in a FinancialsCalculator object in order to evaluate
its amount.
Sample methods
• minus(FinancialsExpression)
• plus(FinancialsExpression)

See also
• “Obtaining calculated amounts” on page 745
• “Retrieving transaction IDs” on page 754
• “Financial calculations with a negative value” on page 755

Understanding ClaimCenter financial calculations

ClaimCenter provides the ability to create calculated financial values that can be used any place that Gosu is
accessible, for example:
• In the ClaimCenter user interface
• In Gosu rules and classes
• In Gosu plugin implementations and similar places
These calculated values provide various critical views of the financial state of a claim and its exposures.
In the base application configuration, Guidewire provides a set of predefined financial calculations. ClaimCenter
uses these financial calculations to compute the values seen on the Financial Summary page. For example, you can
access the Available Reserves financial expression value by using the following Gosu method:

gw.api.financials.FinancialsCalculations.getAvailableReserves

The following classes provide methods that you can use to work with financial calculations:
• gw.api.financials.FinancialsCalculations
• gw.api.financials.FinancialCalculationUtil
In some cases, they appear to duplicate each other. The difference, however, is in the object that each method
returns. Some return a FinancialsCalculation object and others return a FinancialsCalculator object.
Guidewire recommends the you primarily use the FinancialsCalculations methods that return a
FinancialsCalculator object. Use the methods that return a FinancialsExpression object only if you want to
combine these objects to produce custom expressions from which you can obtain the desired value.
If there are multiple versions of a method, then choose the version that returns the type of object that you need.
Generally, you use the predefined financial calculations that Guidewire provides in the base configuration. However,
it is possible to define your own financial calculations out of the set of financial calculations that Guidewire
provides.

744 chapter 55 ClaimCenter financial calculations

 Configuration Guide 9.0.5

See also
• “Financial calculations with a negative value” on page 755.

Using the predefined financial calculations

In the base application configuration, Guidewire provides a set of predefined financial calculations. The
FinancialsCalculations and FinancialsCalculationUtil classes provide static methods for financial
calculations. Both classes have methods with identical names, but with different return types.
This topic describes the objects used in financial calculations and some of the methods used in retrieving calculated
amounts.

Using a FinancialsCalculator object

A FinancialsCalculator is a class in ClaimCenter that provides an alternative way to specify the scope of the
calculation total. You use the gw.api.financials.FinancialsCalculations.* methods, all of which return a
FinancialsCalculator object. The FinancialsCalculator object contains the following methods that you use to
filter the reserve lines that contribute to the calculation total:
• usesClaimLevelReserves
• withAgreement
• withClaim
• withCostCategory
• withCostType
• withCoverageType
• withExposure
• withReserveLine
• withRIAgreement
• withRIAgreementGroup
• withRICoding

Obtaining calculated amounts

You can use a specialized method on financials.FinancialsCalculations to return a FinancialCalculator
object. For example:

gw.api.financials.FinancialsCalculations.getFinancialsCalculation(expression : FinancialExpression)

You can also wrap a FinancialsCalculation object within a FinancialsCalculator object, for example:

FinancialsCalculator.onCalculation(someFinancialsCalculation)

The end result is a new FinancialsCalculator object.

A FinancialsCalculator object exposes the following properties:

Property Type
Amount CurrencyAmount

ReportingAmount CurrencyAmount

TransactionIds Key[]

Using the predefined financial calculations 745

 Configuration Guide 9.0.5

To obtain the actual value of the calculation on this financial expression, use the Amount or ReportingAmount
property on the FinancialsCalculator object, for example:

gw.api.financials.FinancialsCalculations.getTotalIncurredGross()
.withClaim( claim )
.Amount

Note: The getTotalIncurredGross method call returns a FinancialsCalculator object.

It is possible to link the gw.api.financials.FinancialsCalculations methods together to build an expression
that returns the exact value that you want. All return a monetary value for the calculation on which they are called,
limited by the passed-in parameters. The following examples illustrate this concept.
Example 1. The following example calculation returns the Open Reserves amount for the passed-in Claim.

gw.api.financials.FinancialsCalculations.getOpenReserves()
.withClaim(clm)
.Amount

Example 2. The following example calculation returns the amount of Open Reserves for the passed-in Exposure
and CostType values only. It returns only those reserves and payments coded to this exposure and cost type,
regardless of cost category coding.

gw.api.financials.FinancialsCalculations.getOpenReserves()
.withExposure(exp)
.withCostType(cType)
.Amount

Note: Review the ClaimCenter GosuDoc on these methods for more details on how they work.

The FinancialsCalculationUtil class

The FinancialsCalculationUtil API also provides financial calculation objects and methods that can be used to
retrieve calculated amounts. The return types, however, are different.

gw.api.financials.* Returns
FinancialsCalculationU • FinancialsCalculation objects
til Sample methods
• getFinancialsCalculation(FinancialsExpression)
• getFuturePayments
• getOpenReserves
FinancialsExpression A composite FinancialsExpression provides a building block for custom financial calculations.
You can construct a custom expression by adding or subtracting FinancialsExpression
instances. The resulting custom expression can then be used to create a new FinancialsCalcul
ation to retrieve a calculated amount.
You can wrap a FinancialsExpression in a FinancialsCalculation object in order to evaluate
its amount.
Sample methods
• minus(FinancialsExpression)
• plus(FinancialsExpression)
See also
• “Financial calculations with a negative value” on page 755

746 chapter 55 ClaimCenter financial calculations

 Configuration Guide 9.0.5

Different ways to retrieve an amount

Guidewire provides methods in the following classes that you can use to retrieve amounts associated with various
financial calculations:
• gw.api.financials.FinancialsCalculations
• gw.api.financials.FinancialsCalculationUtil

Retrieving Amounts Using FinancialsCalculations

FinancialsCalculations.getAvailableReserves returns a FinancialsCalculator object that also represents
the Available Reserves. Use the following to retrieve the actual amount:

FinancialsCalculations.getAvailableReserves()
.withClaim(claim)
.withExposure(exposure)
.withCostCategory(costCategory)
.Amount

Notice that you must add individual filtering calls to the Gosu expression to filter the reserve lines that ClaimCenter
includes in the calculation total.

Retrieving Amounts Using the FinancialsCalculationUtil API

FinancialsCalculationUtil.getAvailableReserves returns a FinancialsCalculation object representing the
Available Reserves. Use some variant of the following to retrieve the actual amount:

FinancialsCalculationUtil.getAvailableReserves().getAmount(claim, costCategory)
FinancialsCalculationUtil.getAvailableReserves().getAmount(claim, exposure, costType, costCategory)
...

Notice that the getAmount method filters the reserve lines that ClaimCenter includes in the calculation total.

Forming composite custom expressions

Some of the FinancialCalculationsUtil methods end in Expression. These methods always return a
FinancialsExpression object. You can combine the supplied FinancialsExpression instances to form composite
custom expressions. For example, if ClaimCenter did not supply a TotalIncurredNetRecoveryReserves
expression, you could create such an expression in either of the following ways:

//Example 1
gw.api.financials.FinancialsCalculationUtil.getTotalIncurredNetRecoveriesExpression()
.minus(gw.api.financials.FinancialsCalculationUtil.getOpenRecoveryReservesExpression() )

//Example 2
gw.api.financials.FinancialsCalculationUtil.getGrossTotalIncurredExpression()
.minus(gw.api.financials.FinancialsCalculationUtil.getTotalRecoveryReservesExpression() )

In either case, the method returns a new FinancialsExpression instance that is equivalent to the
TotalIncurredNetRecoveryReserves expression.
However, to be useful, you need to obtain a calculated value for the financial expression. To do this, you must
generate an instance of a FinancialCalculator object that is backed by this custom expression. This is done with a
specialized method on gw.api.financials.FinancialsCalculations that returns the required
FinancialCalculator object:

gw.api.financials.FinancialsCalculations.getFinancialsCalculation(FinancialExpression)

Thus, to generate a FinancialCalculation for the example FinancialExpression, you would use:

Using the predefined financial calculations 747

 Configuration Guide 9.0.5

uses gw.api.financials.*

var TotalIncurredNetRecoveryReserves = FinancialsCalculations

.getFinancialsCalculation(FinancialsCalculationUtil
.getGrossTotalIncurredExpression()
.minus(FinancialsCalculationUtil
.getOpenRecoveryReservesExpression() ) )

Creating custom financial gosu classes

Clearly, having to repeat this long string each time that you want to make use of a custom calculation is very tedious.
It is also error prone and inefficient from a performance point of view. Instead, Guidewire recommends that you
create a custom Gosu utility class that contains all your custom financial calculations, which insures that they are all
defined in one location. You can then reference these calculations each place that you reference Gosu code (rules,
Gosu classes and enhancements, and PCF files).
For example, to construct a custom version of TotalIncurredGross, you can do something similar to the following:

package util.financials;

uses gw.api.financials.FinancialsCalculation
uses gw.api.financials.FinancialsCalculationUtil

@Export
class CustomCalcs {
construct() { }
private static var calcMyTotalIncurredNet =
FinancialsCalculationUtil.getFinancialsCalculation(FinancialsCalculationUtil
.getGrossTotalIncurredExpression()
.minus( FinancialsCalculationUtil.getTotalRecoveryReservesExpression() ))

public static property get MyTotalIncurredNet() : FinancialsCalculation {

return calcMyTotalIncurredNet
}
}

This Gosu class defines the custom calculation as a static property. As such, you need to access the property on the
class itself, not an instance of the class. In other words, you do not need to construct an instance of the class using
the new operator to access the property. In fact, any attempt to do so is a mistake.
You reference the example class by using the following syntax:

var amt = util.financials.CustomCalcs.MyTotalIncurredNet.getAmount(claim)

The base configuration sample rules show an example usage of the Guidewire-provided
util.financials.CustomCalcs class in the Transaction Approval rule set. Since MyTotalIncurredNet is merely
an instance of a FinancialCalculator object, the getAmount method works as described previously for the
predefined calculations. Guidewire disables the sample rule that uses the CustomCalcs class in the base
configuration.

Condition

TransactionSet.Subtype == "CheckSet"

Actions

var totalIncurredAmt = util.financials.CustomCalcs.MyTotalIncurredNet.getAmount(transactionSet.Claim)

var exceedAmount = gw.api.financials.CurrencyAmount.getStrict(20000, totalIncurredAmt.Currency)
if (totalIncurredAmt > exceedAmount) { transactionSet.requireApproval(
displaykey.Rules.TransactionApproval.LimitExceeded.TotalIncurredOnClaimExceedsN(
gw.api.util.CurrencyUtil.renderAsCurrency(exceedAmount)))
}

748 chapter 55 ClaimCenter financial calculations

 Configuration Guide 9.0.5

Predefined financial calculations

ClaimCenter provides calculations related to the following financial features:
• “Payment calculations” on page 749
• “Reserve calculations” on page 750
• “Floating financials calculations” on page 751
• “Recovery calculations” on page 751

Payment calculations
In the base configuration, ClaimCenter provides the following calculations related to payments.

Calculated values
TotalPayments

Sum of all submitted and awaiting submission payments whose scheduled send date is today or earlier.
Access using:
FinancialsCalculations.getTotalPayments()

FuturePayments

Sum of all future payments (for example, those approved payments whose scheduled send date is after today). This includes
both eroding and non-eroding payments.
Access using:
FinancialsCalculations.getFuturePayments()

PendingApprovalPayments

Sum of pending eroding and non-eroding payments.

Access using some variant of the following:
FinancialsCalculations.getFinancialsCalculation(FinancialsCalculationUtil.
PendingApprovalPaymentsExpression)

PendingApprovalErodingPayments

Pending approval eroding payments.

Access using some variant of the following:
FinancialsCalculations.getFinancialsCalculation(FinancialsCalculationUtil.
PendingApprovalErodingPaymentsExpression)

PendingApprovalNonErodingPayments

Pending approval non-eroding payments.

Access using some variant of the following:
FinancialsCalculations.getFinancialsCalculation(FinancialsCalculationUtil.
PendingApprovalNonErodingPaymentsExpression)

PaymentsForExAdjustments

Total foreign exchange adjustments for both eroding and non-eroding payments
ErodingPaymentsForExAdjustments

Total foreign exchange adjustment for eroding payments only.

Access using some variant of the following:
FinancialsCalculations.getFinancialsCalculation(FinancialsCalculationUtil.
ErodingPaymentsForeignExchangeAdjustmentsExpression)

NonErodingPaymentsForExAdjustments

Predefined financial calculations 749

 Configuration Guide 9.0.5

Calculated values
Total foreign exchange adjustments for non-eroding payments only.
Access using some variant of the following:
FinancialsCalculations.getFinancialsCalculation(FinancialsCalculationUtil.
NonErodingPaymentsForeignExchangeAdjustmentsExpression)

Reserve calculations
In the base configuration, ClaimCenter provides the following calculations related to reserves.

Calculated reserve values

TotalReserves

Sum of all submitted reserves and reserves that are awaiting submission.
Access using:
FinancialsCalculations.getTotalReserves()

AwaitingSubmissionReserves

Sum of all reserves that are awaiting submission.

Access using:
FinancialsCalculations.getAwaitingSubmissionReserves()

PendingApprovalReserves

Sum of all reserves that are pending approval.

Access using:
FinancialsCalculations.getPendingApprovalReserves()

OpenReserves

Total Reserves minus Total Payments

Detailed description: Sum of all submitted and awaiting submission reserves minus the sum of all submitted and awaiting
submission eroding payments whose scheduled send date is today or earlier.
Access using:
FinancialsCalculations.getOpenReserves()

RemainingReserves

Open Reserves minus Future Eroding Payments

Detailed description: Similar to Open Reserves except that it includes future eroding payments. Thus, it is the sum of all
submitted and awaiting submission reserves minus all approved eroding payments (awaiting submission eroding payments
and future eroding payments).
This calculation can legitimately have a negative value. See “Predefined reinsurance calculations” on page 753 for an
example.
Access using:
FinancialsCalculations.getRemainingReserves()

AvailableReserves

Remaining Reserve minus Pending Approval Eroding Payments

Similar to Open Reserves, except that it includes pending approval and future eroding payments. Thus, it is the sum of all
submitted and awaiting submission reserves minus the sum of all approved eroding payments and all pending approval
eroding payments.
This calculation can legitimately have a negative value. See “Predefined reinsurance calculations” on page 753 for an
example.
Access using:

750 chapter 55 ClaimCenter financial calculations

 Configuration Guide 9.0.5

Calculated reserve values

FinancialsCalculations.getAvailableReserves()

Recovery calculations
In the base configuration, ClaimCenter provides the following calculations related to recoveries.

Calculated recovery values

TotalRecoveries

Sum of all submitted recoveries.

Access using:
FinancialsCalculations.getTotalRecoveries()

TotalRecoveryReserves

Sum of all submitted recovery reserves.

Access using some variant of the following:
FinancialsCalculations.getFinancialsCalculation(FinancialsCalculationUtil.
TotalRecoveryReservesExpression)

TotalIncurredGross

Open Reserves plus Total Payments, plus foreign exchange adjustments (described next in the detailed description),
equivalent to Total Reserve plus Total NonEroding Payments plus foreign exchange adjustments described next.
Detailed description:
Sum of remaining reserves plus pending reserves plus noneroding payments plus awaiting submission noneroding payments
plus foreign exchange adjustment for eroding payments plus foreign exchange adjustment for noneroding payments.
Access using some variant of the following:
FinancialsCalculations.getFinancialsCalculation(FinancialsCalculationUtil.
GrossTotalIncurredExpression)

TotalIncurredNetRecoveries

Gross Total Incurred value minus Total Recoveries.

Access using some variant of the following:
FinancialsCalculations.getFinancialsCalculation(FinancialsCalculationUtil.
TotalIncurredNetRecoveriesExpression)

TotalIncurredNetRecoveryReserves

Gross Total Incurred value minus Total Recovery Reserves.

Access using some variant of the following:
FinancialsCalculations.getFinancialsCalculation(FinancialsCalculationUtil.
TotalIncurredNetRecoveryReservesExpression)

Floating financials calculations

In the base configuration, ClaimCenter provides the following calculations related to floating financials. Foreign
exchange rates in ClaimCenter can be configured to be updated periodically. These calculations are used to update
the floating financial components, such as reserve and recovery reserve amounts, using dynamic exchange rates.
Payments and recoveries are not considered floating values and are evaluated with fixed rates from their respective
transactions.

Predefined financial calculations 751

 Configuration Guide 9.0.5

Note: All the following calculations return a FinancialsCalculator object.

Calculated values
AvailableReserves

Remaining Reserves minus Pending Approval Eroding Payments

Sum of all submitted and awaiting submission reserves minus the sum of all approved, eroding payments
and all eroding payments pending approval.
Access using:
FinancialsCalculations.getFloatingFinancials().AvailableReserves

AwaitingSubmissionReserves

Sum of all reserves that are awaiting submission today.

Access using:
FinancialsCalculations.getFloatingFinancials().AwaitingSubmissionReserves

OpenRecoveryReserves

Submitted recovery reserves minus submitted recoveries.

Access using:
FinancialsCalculations.getFloatingFinancials().OpenRecoveryReserves

OpenReserves

Total Reserves minus Total Payments

Sum of all submitted and awaiting submission reserves minus the sum of all submitted and awaiting
submission eroding payments whose scheduled send date is today or earlier.
Access using:
FinancialsCalculations.getFloatingFinancials().OpenReserves

PendingApprovalReserves
Sum of all reserves that are pending approval.
Access using:
FinancialsCalculations.getFloatingFinancials().PendingApprovalReserves

RemainingReserves

Open Reserves minus Future Eroding Payments

Similar to Open Reserves, except that it includes future eroding payments. It is the sum of all submitted and
awaiting submission reserves minus all approved, eroding payments (eroding payments awaiting submission
and future eroding payments).
This calculation can legitimately have a negative value. See “Predefined reinsurance calculations” on page
753 for an example.
Access using:
FinancialsCalculations.getFloatingFinancials().RemainingReserves

SubmittedOpenReserves

Submitted, open reserves minus eroding, submitted payments.

Access using:
FinancialsCalculations.getFloatingFinancials().SubmittedOpenReserves

TotalIncurredGross
Sum of all open reserves and total payments.
Access using:
FinancialsCalculations.getFloatingFinancials().TotalIncurredGross

TotalIncurredNet

752 chapter 55 ClaimCenter financial calculations

 Configuration Guide 9.0.5

Calculated values
Sum of all open reserves and total payments minus total recoveries.
Access using:
FinancialsCalculations.getFloatingFinancials().TotalIncurredNet

TotalIncurredNetMinusOpenRecoveryReserves
Sum of all open reserves and total payments minus all open recovery reserves.
Access using:
FinancialsCalculations.getFloatingFinancials().TotalIncurredNetMinusOpenRecoveryReserves

TotalRecoveryReserves

Sum of all submitted recovery reserves.

Access using:
FinancialsCalculations.getFloatingFinancials().TotalRecoveryReserves

SubmittedTotalIncurredNet
Sum of all open reserves
Reserves + Payments Submitted - Total Recoveries
Access using:
FinancialsCalculations.getFloatingFinancials().SubmittedTotalIncurredNet

See also
• “Using floating financial calculations” on page 756.

Predefined reinsurance calculations

Guidewire provides predefined calculations related to the subjects of the following topics:
• “Predefined reinsurance calculations” on page 753
• “Predefined reinsurance reserves calculations” on page 754
• “Predefined reinsurance recoveries” on page 754

Predefined reinsurance calculations

In the base configuration, ClaimCenter provides the following calculations related to reinsurance.

Calculation Description
RITotalReinsurance Sum of RI ceded reserves plus RI total recoverables.
Access using:
FinancialsCalculations.getRITotalReinsurance()

RINetNetPayments Net payments (defined as total payments minus total recoveries) minus RI total recoverables.
Access using:
FinancialsCalculations.getRINetNetPayments()

RINetNetReserves Open reserves minus RI open ceded reserves

Access using:
FinancialsCalculations.getRINetNetReserves()

RITotalIncurred Sum of RI net payments plus RI net reserves

Access using:
FinancialsCalculations.getRITotalIncurred()

Predefined reinsurance calculations 753

 Configuration Guide 9.0.5

Calculation Description
RISubmittedNetNetReserves Submitted open reserves minus RI open ceded reserves.
Access using:
FinancialsCalculations.getRISubmittedNetNetReserves()

RISubmittedNetNetPayments Submitted net payments (defined as total payments minus total recoveries) minus RI total
recoverables.
Access using:
FinancialsCalculations.getRISubmittedNetNetPayments()

RISubmittedTotalIncurred Sum of RI submitted net payments plus RI submitted net reserves.

Access using:
FinancialsCalculations.getRISubmittedTotalIncurred()

Predefined reinsurance reserves calculations

In the base configuration, ClaimCenter provides the following calculations related to reinsurance reserves.

Calculation Description
RITotalCededReservesAdjustments Committed ceded reserve adjustments.
Access using:
FinancialsCalculations.getRITotalCededReservesAdjustments()

RITotalCededReservesNonAdjustments Committed ceded reserves non-adjusted.

Access using:
FinancialsCalculations.getRITotalCededReservesNonAdjustments()

RIOpenCededReserves Total ceded reserves minus total RI recoverables.

Access using:
FinancialsCalculations.getRIOpenCededReserves()

Predefined reinsurance recoveries

In the base configuration, ClaimCenter provides the following calculations related to reinsurance recoveries.

Calculation Description
RITotalRecoverables Total recoverables.
Access using:
FinancialsCalculations.getRITotalRecoverables()

RITotalRecoverablesAdjustments Total committed recoverables including adjustments.

Access using:
FinancialsCalculations.getRITotalRecoverablesAdjustments()

RITotalRecoverablesNonAdjustments Total committed recoverables not including adjustments.

Access using:
FinancialsCalculations.getRITotalRecoverablesNonAdjustments()

Retrieving transaction IDs

The FinancialsCalculator.TransactionIds property does not return the monetary amount of the calculation.
Instead, it returns the IDs of the transactions that contribute to the calculated value. Thus, for example, executing the

754 chapter 55 ClaimCenter financial calculations

 Configuration Guide 9.0.5

following returns the IDs of all transaction objects that contribute to the open reserves calculated values (reserves
and payments).

gw.api.financials.FinancialsCalculations.getOpenReserves().TransactionIds

Again, it is possible to link multiple FinancialsCalculator methods together to uniquely identify the open
reserves to include. For example:
• If you pass in only the claim, then the method returns the IDs of all the transactions that contribute to the Open
Reserves for the entire claim.

gw.api.financials.FinancialsCalculations.getOpenReserves().withClaim(clm).TransactionIds

• If you use a version that takes an exposure only, then it returns the IDs of all the transactions that contribute to
Open Reserves for that exposure only. It does not return the IDs of transactions for other exposures on the same
claim.

gw.api.financials.FinancialsCalculations.getOpenReserves().withExposure(exp).TransactionIds

You can construct other versions of these methods that allow you to account only for certain Cost Types and/or Cost
Categories, for example.

Financial calculations with a negative value

Only two of the predefined financial calculations described in topic “Predefined financial calculations” on page 749
can legitimately have a negative value. They are:
• Available Reserves
• Remaining Reserves
These two calculations are defined at “Reserve calculations” on page 750. They can subtract payments for which
offsetting reserves have not yet have been created.
The following example illustrates this concept.
Consider a claim or exposure with the following transactions:
• Submitted reserve: $500.00
• Submitted payment: $300.00
• Awaiting submission payment: $400.00, scheduled send date is one week from the current day.
For this example to be possible, you need to set the AllowPaymentsExceedReservesLimits parameter in
config.xml to true to allow payments to exceed reserves. With that parameter set, the Remaining Reserves in this
case are -$200.00. ClaimCenter does not automatically create the necessary offsetting reserves for the payment that
exceeds reserves—the $400.00 payment—until the scheduled send date of the payment check is reached. Because
ClaimCenter counts these payments against remaining reserves, the Remaining Reserves value ends up negative.
Now, consider if an additional pending approval payment were created:
• Pending approval payment: $350
In this case, the calculated values would be:
• Remaining reserves: -$200.00
• Available reserves: -$550.00
Available reserves are even further into negative territory, in this case because ClaimCenter subtracts the pending
approval payment also.

Financial calculations with a negative value 755

 Configuration Guide 9.0.5

Eroding and non-eroding payments

It is important to understand the following about payments:
• Supplemental payments are non-eroding by definition. Any partial or final payment can also be marked as non-
eroding using one the previously described methods.

Using floating financial calculations

ClaimCenter includes support for the use of multicurrency reserving in financial transactions. When multicurrency
reserving is disabled, although it is possible to create reserve transactions in currencies other than the claim
currency, reserves are tracked and eroded in the claim’s currency.
When multicurrency reserving is enabled, you can track and erode reserves and recovery reserves in the currency of
choice. ClaimCenter provides the floating financials API to get financial calculation totals based on dynamic
exchange rates. ClaimCenter includes a set of predefined floating financial calculations to support this feature. See
“Floating financials calculations” on page 751.
This topic includes some examples that describe the use of floating financial calculations.
Note: It is assumed that multicurrency reserving is enabled in configuration for all of the following examples.

Example – Using reserve lines in multiple currencies

In this example, claim reserves and payments use currencies other than the claim currency.
1. Consider a claim filed on January 1, 2014 with a claim currency of Euros and a reporting currency of U. S.
Dollars. A new reserve line is created with the reserve currency set to British pounds and a reserve amount of
100 pounds. Whenever ClaimCenter creates a transaction, it stores the reserve in the transaction, reserving,
claim, and reporting currencies.
• Claim Currency—Euros (EUR)
• Reporting Currency—U. S. Dollars (USD)
• Reserve Line 1—100 pounds (GBP)
The exchange rates stored in ClaimCenter are:
• GBP to EUR—1.2
• EUR to USD—1.4
• GBP to USD—1.6
1. On January 5, 2014, a payment of 10 pounds is created. The payment is stored in the system in the transaction,
reserving, claim, and reporting currencies, when the transaction is created.
The exchange rates in ClaimCenter, dated January 1, 2014, are:
• GBP to EUR—1.2
• EUR to USD—1.4
• GBP to USD—1.6
ClaimCenter calculates the available reserves as follows:

Financial Component Transaction Amount Reserving Amount Claim Amount Reporting Amount
Reserve 100 GBP 100 GBP 120 EUR 168 USD
Payment 10 GBP 10 GBP 12 EUR 16.8 USD
Available Reserves 100-10 = 90 GBP 120 -12 168 -16.8
= 108 EUR = 151.2 USD

756 chapter 55 ClaimCenter financial calculations

 Configuration Guide 9.0.5

ClaimCenter calculates the available reserves using the following formula:

Available Reserves = Reserves - Payments

The values used in the equation are in the corresponding currencies—reserving, claim, or reporting. The calculations
in this step access the FinancialsCalculations class, calling FinancialsCalculations.
getAvailableReserves(), to arrive at these values.
1. The FloatingFinancialsCalcuations API can be used when you need to calculate available reserves based
on current market rates rather than rates that were in force when the reserves were created.
On February 1, 2014, assume the market exchange rates have changed, as follows.
• GBP to EUR—1.1
• EUR to USD—1.3
• GBP to USD—1.45
ClaimCenter accesses the FloatingFinancialsCalculations class, calling
FinancialsCalculations.getFloatingFinancials().getAvailableReserves(), with the following results.

Financial Component Transaction Amount Reserving Amount Claim Amount Reporting Amount
Reserve 100 GBP 100 GBP 120 EUR 168 USD
Payment 10 GBP 10 GBP 12 EUR 16.8 USD
Available Reserves 100-10 = 90 GBP 120 -12 = 108 EUR 168 -16.8 = 151.2 USD
Available Reserves (Floating) 100-10 = 90 GBP (100 - 10) * 1.1 (100 - 10) * 1.45
= 99 EUR = 130.5 USD

In the preceding table, the Available Reserves row shows the calculated amounts based on the exchange rates stored
in the system when the transactions were created. The Available Reserves (Floating) row shows the calculated
amounts with reserves updated to the latest exchange rates available in the system.
For example:

Available Reserves (Floating) in Claim Currency = (Reserves - Payments) in Reserve Currency *

(Exchange Rate to Claim Currency) = (100 - 10) * (1.1) = 99 Euros

In the Financials Summary screen, you can view amounts using market rates, that is, floating financial calculations.
See the Application Guide.
1. On February 20, 2014, a recovery is received for the amount of 5 pounds.
The exchange rates in ClaimCenter, dated February 1, 2014, are:
• GBP to EUR—1.1
• EUR to USD—1.3
• GBP to USD—1.45

Financial Component Transaction Reserving Amount Claim Amount Reporting Amount

Amount
Reserve 100 GBP 100 GBP 120 EUR 168 USD
Payment 10 GBP 10 GBP 12 EUR 16.8 USD
Recovery 5 GBP 5 GBP 5.5 EUR 7.15 USD
Total Recoveries 5 GBP 5.5 EUR 7.15 USD
Total Incurred Net 100 - 5 = 95 GBP 120 - 5.5 168 - 7.15 = 160.85 USD

Using floating financial calculations 757

 Configuration Guide 9.0.5

Financial Component Transaction Reserving Amount Claim Amount Reporting Amount

Amount
= 114.5 EUR
Total Incurred Net 100 - 5 = 95 GBP (100 - 10) * 1.1 + 12 - 5.5 = 105.5 (100 - 10) * 1.45 + 16.8
(Floating) EUR - 7.15 = 140.15 USD

The Total Incurred Net value is calculated as follows:

Total Incurred Net = (Open Reserves + Total Payments) - Total Recoveries

Open Reserves are calculated, in turn, as follows:

Open Reserves = Total Reserves - Total Payments

The Total Incurred Net row shows the calculated amounts based on the exchange rates stored in the system when the
transactions were created. The Total Incurred Net (Floating) row shows the calculated amounts with reserves
updated to the latest exchange rates available in the system.
For example

Total Incurred Net (Floating) in Reporting Currency = ( (Open Reserves in Reserve Currency
* Exchange Rate to Reporting Currency) + Total Payments) - Total Recoveries
= ( (100 - 10) * 1.45) + 16.8 - 7.15 = 140.15 USD

Note: ClaimCenter only applies floating calculations to reserves and recovery reserves.
See also
• “Predefined financial calculations” on page 749.
• “The financials data model” on page 735
• Application Guide

758 chapter 55 ClaimCenter financial calculations

chapter 56

Creating financial transactions

This topic describes how to use the financial calculation APIs that create various kinds of transactions in
ClaimCenter.
See also
• “ClaimCenter financial calculations” on page 743

Setting reserves
You read (retrieve) the values for Available Reserves by using the following static method, which returns a
FinancialsCalculator object:

gw.api.financials.FinancialsCalculations.getAvailableReserves

Available reserves are similar to open reserves except that they include pending approval and future eroding
payments. Thus, they are the sum of all submitted and awaiting submission reserves minus the sum of all approved
eroding payments and all pending approval eroding payments.
See also
• The definition of Available Reserves at “Reserve calculations” on page 750

Setting reserve values

To set the level of Available Reserves, use one of the methods that the following topics describe:
• “The setAvailableReserves method” on page 760
• “Available reserves method on reserve line objects” on page 760
You can also create a ReserveSet and reserve transactions directly.

Creating financial transactions 759

 Configuration Guide 9.0.5

The setAvailableReserves method

To set reserve values, you must call setAvailableReserves directly on one of the following objects:
• Claim
• Exposure
The following code shows the method parameters:

setAvailableReserves(costType, costCategory, amount, submittingUser)

The method sets the available reserves for an exposure or claim to the given amount by creating a new reserve
transaction that increases or decreases the currently available reserves.
Executing the setAvailableReserves method from a Gosu rule provides significantly different behavior than
performing the equivalent action through the ClaimCenter interface. If you execute this method as part of a rule:
• The method creates a separate ReserveSet object.
• The method ignores any existing reserve set objects for the giving ReserveLine that have a status of Pending
Approval.
The setAvailableReserves method takes the following parameters:

Parameter Description
costType The cost type for the reserve. This value cannot be null, but it can be unspecified.
costCategory The cost category for the reserve. This value cannot be null, but it can be unspecified.
amount The amount to which to set the available reserves. The amount must be zero or greater, and cannot be
negative.
submittingUser User submitting this reserve.

Available reserves method on reserve line objects

ClaimCenter also provides a mirror to the method described previously for use with the ReserveLine object. For
example:

reserveLine.setAvailableReservesInReservingCurrency( "1000", User.util.CurrentUser )

This method sets the available reserves for this reserve line to the given amount by creating a new reserve
transaction that increases or decreases the currently available reserves. It creates reserves in the same reserving
currency as the reserve line.
The method takes the following parameters:

Parameter Description
newReserveAmount The amount to which to set the new reserve. The amount must be non-null and zero or greater, and
cannot be negative.
submittingUser User submitting this recovery reserve.

760 chapter 56 Creating financial transactions

 Configuration Guide 9.0.5

See also
• “Available reserves method on reserve line objects” on page 760

Creating reserve transactions directly

ClaimCenter provides an API that you can use to create reserve transactions directly. This API is more flexible than
the FinancialsCalculations API and include the following:
• Claim.newReserveSet()
• ReserveSet.newReserve(exposure, costType, costCategory)
• Reserve.addNewLineItem(amount, comments, lineCategory)
• ReserveSet.prepareForCommit()
For example:

var claim : Claim

var exposure : Exposure
var costType : CostType
var costCategory : CostCategory

var reserveSet = claim.newReserveSet()

var reserve = reserveSet.newReserve(exposure, costType, costCategory)

// Modify the new Reserve transaction as you want – for example:

reserve.Currency = Currency.TC_EUR

// Set the amount to 100 EUR.

// A Reserve transaction must have only one TransactionLineItem,
// and its LineCategory must be null.
reserve.addNewLineItem( gw.api.financials.CurrencyAmount.getStrict(
100, Currency.TC_EUR) , null, null)

// Add more reserve transactions if required

reserveSet.prepareForCommit()

The newReserve method returns the new transaction entity so that you can modify it. At minimum, you must call
the addNewLineItem method to add a TransactionLineItem with the Amount of the transaction. You can also
create a multicurrency Reserve transaction by modifying the Currency field on the transaction.
After you finish creating transactions, call the ReserveSet.prepareForCommit method to submit the reserve set for
approval and to update the financial calculations. After calling the prepareForCommit method, it is not possible to
modify the transaction amount, currency, exchange rates, or other key fields on the transaction.
See also
• “Setting reserves” on page 759

Creating checks and payments by using CheckCreator

Guidewire provides methods on gw.api.financials.CheckCreator to use as you create new Check objects in
Gosu business rules. This class provides a builder-like interface to assist you in creating Check entities and their
subobjects.
You can use one of the following methods to create a CheckCreator object:
• Claim.newCheckCreator
• Exposure.newCheckCreator
Use the builder-like methods on CheckCreator to modify a new Check object before you submit the check for
approval and before ClaimCenter updates any affected TAccount objects. For example, you can add additional
payments or line items to the check before you submit the check.

Creating reserve transactions directly 761

 Configuration Guide 9.0.5

The CheckCreator methods start typically with with and provide a way for you to specify parameters such as the
cost type or the mail-to-address of the check. For example:

CheckCreator.withPayee(payee)
.withPayeeRole(payeeRole)
.withRecipient(recipient)
.withMailingAddress(mailingAddress)
.withReportabilityType(reportabilityType)
.withCostType(costType)
...

The following example illustrates how to create a new CheckCreator object and pass in various parameters. You
need, of course, to define or to retrieve values for each of the supplied parameters.

var claimCheck = claim.newCheckCreator()

claimCheck.withPayee(payee)
.withPayeeRole(payeeRole)
.withRecipient(recipient)
.withMailingAddress(mailingAddress)
.withReportabilityType(reportabilityType)
.withCostType(costType)
.withCostCategory(costCategory)
.withPaymentType(paymentType)
.withLineCategory(lineCategory)
.withCheckAmount(checkAmount)
.withComments(comments)
.withMemo(memo)
.withPayTo(payTo)
.withScheduledSendDate(scheduledSendDate)
.withRequestingUser(requestingUser)

In actual practice, you need supply only those parameters that meet your business needs. However, at a minimum,
supply valid values for the following Check parameters. You cannot leave these values null.
• Payee
• PayeeRole
• CostType
• CostCategory
• PaymentType
• CheckAmount
• ScheduledSendDate
In a similar manner, you can create a check for an exposure. The following examples illustrate how to do this.

exposure.newCheckCreator().withPayee(payee)
.withPayeeRole(payeeRole)
.withRecipient(recipient)
.withMailingAddress(mailingAddress)
.withReportabilityType(reportabilityType)
.withCostType(costType)
.withCostCategory(costCategory)
...

After you create a CheckCreator object, you then use one of the following methods on CheckCreator to create the
check:

Check creation methods Description

createCheck Creates a check defined by the current state of CheckCreator. It is possible to modify the check
and any subentities of the check after you create the check.

762 chapter 56 Creating financial transactions

 Configuration Guide 9.0.5

Check creation methods Description

The createCheck method call returns a new Check object. It also stores the new Check object
inside the CheckCreator for the subsequent call to prepareForCommit. You must call CheckCreato
r.prepareForCommit to submit the check for approval and to update the appropriate TAccount
objects.
prepareForCommit Prepares the previously created check for commit to the database. Call this method after calling Che
ckCreator.createCheck and after performing any modifications to the check, such as adding
additional Payments or Transaction Line Items. This methods submits the check for approval and
updates the appropriate TAccount objects.
It is not possible to modify the check after you call this method, except for extension fields.
createAndPrepareForC Use to prepare and commit the check in one operation. This method calls the following methods in
ommit the listed order:
• createCheck
• prepareForCommit

For example, on a specific exposure:

var cc = exp.newCheckCreator().withPayee(payee1)
.withPayeeRole("checkpayee")
.withCostType("claimcost")
.withCostCategory("autoglass")
.withPaymentType("final")
.withCheckAmount(100.00)
.withScheduledSendDate("2012-01-31" as java.util.Date)

var thisCheck = cc.createCheck()

thisCheck.BankAccountNumber = "123456789"
cc.prepareForCommit()

Notes
• A check with an eroding payment must have reserves already created, so it can erode the available reserves. This
case is the typical one.
• You can create the check with a non-eroding payment, which does not require a reserve.
• In the case of claims created using the First and Final wizard, the eroding payment is both the first and the final
payment on a reserve line. It does not need reserves for simple claims like auto glass claims. An offset reserve is
created automatically for a first and final payment.
See also
• “Setting reserves” on page 759.
• The Gosu API reference for the latest information on Gosu types and methods. See the Gosu Reference Guide.
• Application Guide

Creating recovery transactions

Guidewire provides methods to create recoveries on the following objects.

Object See…
Claim “Claim objects” on page 764
Exposure “Exposure objects” on page 764
RecoverySet “Creating recoveries directly” on page 764

Creating recovery transactions 763

 Configuration Guide 9.0.5

Claim objects
The following example illustrates how to create a recovery on a claim. You need to define or retrieve values for each
of the supplied parameters. Also, you need to supply only those parameters that meet your business needs.

claim.createRecovery( payer,
costType,
costCategory,
recoveryCategory,
lineCategory,
recoveryAmount,
recoveryCurrency,
exchangeRateOverride,
customExchangeRateDescription,
claimAmountOverride,
reportingAmountOverride,
comments,
requestingUser )

Exposure objects
The following example illustrates how to create a recovery on an exposure.

exp.createRecovery( payer,
costType,
costCategory,
recoveryCategory,
lineCategory,
recoveryAmount,
comments,
requestingUser )

Creating recoveries directly

ClaimCenter provides an API that you can use to create recoveries directly. The API methods include the following:
• Claim.newRecoverySet()
• RecoverySet.newRecovery(exposure, costType, costCategory, recoveryCategory, currency)
• RecoverySet.prepareForCommit()
For example:

var claim : Claim

var exposure : Exposure
var costType : CostType
var costCategory : CostCategory

var recoverySet = claim.newRecoverySet()

var recovery = recoverySet.newRecovery(exposure, costType, costCategory, recoveryCategory, currency)

// Modify the new Recovery transaction as you want. For example:

recovery.Currency = Currency.TC_EUR
recovery.RecoveryCategory = RecoveryCategory.TC_SALVAGE

// Set the amount to 100 EUR.

// A Recovery transaction must have at least one TransactionLineItem.
recovery.addNewLineItem(gw.api.financials.CurrencyAmount.getStrict(
100, Currency.TC_EUR) , null, null)

// Add more recovery transactions if required

recoverySet.prepareForCommit()

The newRecovery method returns the new transaction entity so that you can modify it. At the minimum, you must
call the addNewLineItem method to add a TransactionLineItem with the Amount of the transaction. You can also
create a multicurrency Recovery transaction by modifying the Currency field on the transaction.

764 chapter 56 Creating financial transactions

 Configuration Guide 9.0.5

After you finish creating transactions, call the RecoverySet.prepareForCommit method to submit the recovery set
for approval and to update the financial calculations. After calling the prepareForCommit method, it is not possible
to modify the transaction amount, currency, exchange rates, or other key fields on the transaction.

Creating recovery reserve transactions

You read (retrieve) the values for Open Recovery Reserves by using the following static method, which returns a
FinancialsCalculator object:

gw.api.financials.FinancialsCalculations.getOpenRecoveryReserves

The Open Recovery Reserves calculation, Total Recovery Reserves minus Total Recoveries, is analogous to
payments decreasing open reserves. After a recovery is received, it decreases the open recovery reserve associated
with that reserve line.
See also
• Application Guide

Setting recovery reserve values

To set the level of Open Recovery Reserves, use one of the methods described in the following topics:
• “setOpenRecoveryReserves” on page 765
• “Recovery reserve method on reserve line objects” on page 766
You can also create a recovery reserves set and recovery reserves transactions directly. For details, see “Recovery
reserve method on reserve line objects” on page 766.

setOpenRecoveryReserves
To set recovery reserve values, you must call setOpenRecoveryReserves directly on one of the following:
• Claim
• Exposure
The following code shows the method parameters:

setOpenRecoveryReserves(costType, costCategory, recoveryCategory,

newRecoveryReserveAmount, submittingUser)

The method sets the open recovery reserves for an exposure or claim to the given amount. It does so by creating a
new recovery reserve transaction that increases or decreases the current open recovery reserves. The method takes
the following parameters:

Parameter Description
costType The cost type for the reserve. This value cannot be null, but it can be unspecified.
costCategory The cost category for the reserve. This value cannot be null, but it can be unspecified.
recoveryCategory The recovery category for the recovery reserve. This value cannot be null.
newRecoveryReserveAmount The amount to which to set the open recovery reserves. The amount must be non-null and zero
or greater, and cannot be negative.
submittingUser User submitting this recovery reserve.

Creating recovery reserve transactions 765

 Configuration Guide 9.0.5

Recovery reserve method on reserve line objects

ClaimCenter also provides a mirror to the method described previously for use with the ReserveLine object. For
example:

reserveLine.setOpenRecoveryReservesInReservingCurrency("Salvage", "1000", User.util.CurrentUser)

This method sets the open recovery reserves for this reserve line to the given amount in the reserving currency. It
creates a recovery reserve that increases or decreases the current open recovery reserves. It returns the new recovery
reserve, or null if the recovery reserve is not created.
The method takes the following parameters:

Parameter Description
recoveryCategory The recovery category for the recovery reserve. This value cannot be null.
newRecoveryReserveAmount The amount to which to set the open recovery reserves. The amount must be non-null and zero
or greater, and cannot be negative
submittingUser User submitting this recovery reserve.

Creating recovery reserve transactions directly

ClaimCenter provides an API that you can use to create recovery reserve transactions directly. This API is more
flexible than those listed previously in this topic. The methods include the following:
• Claim.newRecoveryReserveSet()
• RecoveryReserveSet.newRecoveryReserve(exposure, costType, costCategory, recoveryCategory,
currency)
• RecoveryReserve.addNewLineItem(currencyAmount, comments, lineCategory)
• RecoveryReserveSet.prepareForCommit()
For example:

var claim : Claim

var exposure : Exposure
var costType : CostType
var costCategory : CostCategory

var recoveryReserveSet = claim.newRecoveryReserveSet()

var recoveryReserve = recoveryReserveSet.newRecoveryReserve(exposure, costType, costCategory)

// Modify the new RecoveryReserve transaction as you want – for example:

recoveryReserve.Currency = Currency.TC_EUR

// Set the amount to 100 EUR.

// A RecoveryReserve transaction must have only one TransactionLineItem,
// and its LineCategory must be null.
recoveryReserve.addNewLineItem( gw.api.financials.CurrencyAmount.getStrict(
100, Currency.TC_EUR) , null, null)

// Add more RecoveryReserve transactions if required

recoveryReserveSet.prepareForCommit()

The newRecoveryReserve method returns the new transaction entity so that you can modify it. At minimum, you
must call the addNewLineItem method to add a TransactionLineItem with the Amount of the transaction. You can
also create a multicurrency recovery reserve transaction by modifying the Currency field on the transaction.
After you finish creating transactions, call the RecoveryReserveSet.prepareForCommit method to submit the
reserve set for approval and to update the financial calculations. After calling the prepareForCommit method, it is
not possible to modify the transaction amount, currency, exchange rates, or other key fields on the transaction.

766 chapter 56 Creating financial transactions

chapter 57

Configuring ClaimCenter financial

screens

This topic discusses how you can modify various ClaimCenter screens related to financials. It is also discusses how
to configure financial holds and bulk invoice payments.

Configuring the financial summary screen

This topic explains how to configure the claim Financials Summary page to reflect information in a manner consistent
with your business practices. It covers the following:
• “The Financials Summary page” on page 767
• “Configuring the filter drop-down” on page 768
• “Defining the model used by a panel set” on page 769
• “Controlling the display of the financial model” on page 770

The Financials Summary page

You can configure the Financials Summary page to appear as you like. The page definition is made up of files in the
configuration→config→Page Configuration→pcf →claim→financials→summary folder in Guidewire Studio:

ClaimFinancialsSummary Defines the summary tab. You modify this page to change the contents of the drop-down
that filters available options at the top of the screen.
FinancialsSummaryLV Defines the list view that shows in the ClaimFinancialsSummary screen.
FinancialsSummaryPanelSet.M Defines a model PCF that corresponds to an item in the drop-down filter. ClaimCenter
ode renders a separate Shared Section panel (distinguished by Mode) for each item in the filter.
Base configuration modes include the following:
• Claimant
• ClaimCostOnly
• Coverage

Configuring ClaimCenter financial screens 767

 Configuration Guide 9.0.5

• Exposure
• ExposureOnly
• ReservingCurrency
• RecoveryCategory
You can modify these modes and configure additional modes in Gosu.

Configuring the filter drop-down

The ClaimFinancialsSummary PCF file contains a Toolbar element that defines the View filter drop-down list:

If you select the Toolbar element, you see a set of basic properties for it. You can also scroll down to see the list of
advanced properties associated with it.
Note that the value property is set to filterOption. This is a page variable that you can access by selecting the
entire page, then opening the Variables tab.

768 chapter 57 Configuring ClaimCenter financial screens

 Configuration Guide 9.0.5

It sets the initial value to either the last saved option or to a default value.
Note the onChange property is set to the following:

financials.FinancialsUtil.setFinancialsSummaryOption(Claim, filterOption)

This saves the filter option for the financials summary screen for the user session.
The optionLabel property uses a page method to determine the option label:

getFilterOptionLabel(VALUE)

You can access this method by selecting entire page, then opening the Code tab.

Defining the model used by a panel set

In the ClaimFinancialSummary PCF file, for each item in the View filter drop-down list, there is a panel set file. For
example, the following example illustrates the Exposure mode of the FinancialsSummaryPanelSet PCF file. You
edit this file to define the financial model used to determine both the levels and the columns that appear in your
summary screens.

Configuring the financial summary screen 769

 Configuration Guide 9.0.5

Notice that if you select Panel Ref, the def property is set to the following:

FinancialSummaryLV(Claim, financialsSummaryBridge)

Controlling the display of the financial model

A list view controls how ClaimCenter displays the models defined in the FinancialsSummaryPanelSet.Mode file.
By default, all the different modes use the same list view file, FinancialSummaryLV. The list view contains a single
FinancialsSummaryRow element containing multiple FinancialSummaryCell subelements. Each cell represents a
column in the row.

770 chapter 57 Configuring ClaimCenter financial screens

 Configuration Guide 9.0.5

The cell object has a getValue accessor that takes as an argument a FinancialsExpression. You can pass in any
expression that you added to the model as you configured the FinancialsSummaryPanelSet.Mode file.
For example, if you try to access a value for an expression not in your FinancialsSummaryPanelSet.Exposure
model, ClaimCenter throws an exception similar to the following:

IllegalArgumentException: An expression, 'TotalPayments' was accessed in the FinancialsSummaryModel

that was not specified on creation of the model (click for error details)

Configuring the financial summary screen 771

 Configuration Guide 9.0.5

If you want to change the list view, the interesting fields are value and action. These attributes must reference the
same FinancialExpression. If the attributes do not match, a link for a value takes the user to a list of transactions
that have nothing to do with the actual selected value.
You can control the visibility of an individual column by setting its permission in the visible attribute. The default
list view hides columns that ClaimCenter does not permit users to see. For example, in the default configuration, the
FinancialSummaryCell:RemainingReserves cell in the FinancialsSummaryLV PCF sets the following for the
visible attribute.:

perm.Claim.viewreserves(Claim) and perm.Claim.viewpayments(Claim)

This cell only displays the remaining reserves if the user has permission to view payments and reserves for a claim.
For users without the permission, the Remaining Reserves column is invisible.

Configuring reserve behavior

This topic describes how to configure the behavior of reserves and their related dialogs within ClaimCenter.

Understanding how configuration impacts reserves

The ClaimCenter Set Reserve screen has two mutually exclusive modes for setting reserves. The first mode is to set
reserves by available reserves and second is to set reserves by total incurred. (You access the Set Reserves screen by
first opening a claim, then navigating the following path: Actions→New Transaction→Reserve.)

Set reserves by available It is possible to change the state of the reserves on a claim by changing the value of the NewAvailable
reserves Reserves field for a reserve line.

Set reserves by total It is possible to change the state of the reserves on a claim by changing the value of the New Total
incurred Incurred field for a reserve line.

772 chapter 57 Configuring ClaimCenter financial screens

 Configuration Guide 9.0.5

To set the mode to one or the other of these choices, edit the SetReservesByTotalIncurred parameter in the
config.xml file.
• If the SetReservesByTotalIncurred value is false, ClaimCenter sets reserves by the available reserves.
• If the SetReservesByTotalIncurred value is true, ClaimCenter sets reserves by the total incurred.
The default is false.
During creation of a new reserve for a claim, ClaimCenter displays the current state of the entire claim's reserves
including the available and unapproved reserves.

Each line in this screen corresponds to one of the ReserveLine items on the claim. A ReserveLine is a unique
combination of Exposure, CostType, and CostCategory on a particular claim. You can set reserves for, and make
payments against, each reserve line item in a claim. The SetReservesByTotalIncurred parameter value sets which
PCF page defines the reserve line items:
• If SetReservesByTotalIncurred is true, then the EditableReservesLV.SetByNewTotalIncurred PCF
defines the content for the page.
• If SetReservesByTotalIncurred is false, then the EditableReservesLV.SetByNewAvailableReserves PCF
defines the content for the page.
You can find these files in pcf→claim→newtransaction→reserve.

The fields in the reserve dialog

The following table describes the possible fields that can appear in the Set Reserve dialog:

Field Description
Exposure The claim’s exposure corresponding to the reserve line. This is a read-only field for an existing ReserveLine.

Understanding how configuration impacts reserves 773

 Configuration Guide 9.0.5

Field Description
Coverage The policy coverage corresponding to the reserve. This is a read-only field.
Cost Type The cost type corresponding to the reserve. This is a read-only field for an existing ReserveLine.
Cost Category The cost category corresponding to the reserve. This is a read-only field for an existing ReserveLine.
Currently The calculated amount of available reserves for this ReserveLine. This is a read-only field.
Available
Pending The pending approval reserves for this reserve line. This field is read-only.
Approval
New This field is visible only if SetReservesByTotalIncurred is false. If visible, you use this field to change
Available reserves for a ReserveLine. The field is editable as long as the exposure for the specific line item is also open.
Reserves • If ClaimCenter displays the Set Reserve page, this field is equal to Available Reserves plus the Pending Reserves.
• If a user enters a value in this field, the value represents the reserve the user wants for the ReserveLine.
• After a user clicks Save, if the user requires approval for a reserve, ClaimCenter updates the Pending Approval
field. Otherwise, it updates Available Reserves.
Change This field tracks the changes taking place between the time that a user first opens the Set Reserve dialog and
the time that the user presses the Save button. The meaning of this field changes depending on how you have
set SetReservesByTotalIncurred.
• If SetReservesByTotalIncurred is false, the field contains difference between the New Available Reserves
and Available Reserves columns.
• If SetReservesByTotalIncurred is true, the field contains the difference between the New Total Incurred
and Total Incurred columns.
Comments Comments about the reserve. The value in this field is saved only for a new reserve or for a reserve for which
the reserve amount changes.
New Total This field is visible only if SetReservesByTotalIncurred is true. If visible, you use this field to change reserves
Incurred for a ReserveLine. The field is editable as long as the exposure (or claim) for the specific reserve line is open
as well.
• If ClaimCenter displays the Set Reserve page, this field is equal to Total Incurred plus the Pending Reserves.
• If a user enters a value in this field, the value represents the reserve the user wants for the ReserveLine.
• After a user clicks Save, if the user requires approval for a reserve, ClaimCenter updates the Pending Approval
field. Otherwise, it updates Total Incurred.
Total Incurred This field is visible only if SetReservesByTotalIncurred is true. This field contains the current total incurred
for this line item. This field is read-only.

How multiple changes interact

If a user changes the value in the Available Reserves on a particular reserve line to a new value and saves the change,
ClaimCenter creates a new reserve transaction. (This works in a similar manner for the Total Incurred field, if you use
total incurred.) The value of this transaction is the value of the change between the original Available Reserves value
and the new value. (If using total incurred, then it is the value of the change between the Total Incurred field and the
new value.)
If there are changes pending approval in the same reserve line, ClaimCenter does not add the new change to any
existing Pending Approval values. Instead. ClaimCenter replaces the new changes appropriately. For example, suppose
that you enter the Set Reserves dialog, which looks similar to the following:

774 chapter 57 Configuring ClaimCenter financial screens

 Configuration Guide 9.0.5

After you enter a new reserve value, ClaimCenter reflects the change:

Then, suppose that you save the change, exit the dialog, and come back to it later. You see:

Suppose that you continue to change the reserve even more:

The next time you return to the dialog, if ClaimCenter has not yet approved the changes, you see the following:

Reserve permissions and authority limits

You can use the following permissions to control access to reserve activities:
Configuring reserve behavior 775
 Configuration Guide 9.0.5

Permission Description
claimviewrecres View recovery reserves (and derived information) on a claim

claimviewres View reserves (and derived information) on a claim

recrescreate Create recovery reserve transactions
recresdelete Delete recovery reserve transactions
recresedit Edit recovery reserve transactions
rescreate Create reserve transactions
resdelete Delete reserve transactions
resedit Edit reserve transactions

The following roles have all of the reserve-related permissions:

• Adjuster
• Claims Supervisor
• Clerical
• Manager
• New Loss Processing Supervisor
• Superuser
The following additional roles have only the claimveiwrecres and claimviewres permissions:
• Customer Service Representative
• Integration Admin
• Viewer
A user with the rescreate permission can create a reserve on an open claim provided the user has one of the proper
AuthorityLimitType limits (defined in the AuthorityLimitType typelist). The following list describes the
allowable reserve AuthorityLimitType values.

Code Name Description

car Claim available reserves The available reserves on or for a claim
ctr Claim total reserves The total reserves on or for a claim
ear Exposure available reserves The available reserves for a single exposure
etr Exposure total reserves The total reserves for a single exposure
rcs Reserve change size The size of a singe reserve change

A user can only create a reserve with a non-null exposure if the selected exposure is open.

Set the number of reserve items to show

About this task
You can change the number of reserve items that appear on the Set Reserve dialog. To configure this value, do the
following:

Procedure
1. Open EditableReservesLV. You can find this files in pcf→claim→newtransaction→reserve.

776 chapter 57 Configuring ClaimCenter financial screens

 Configuration Guide 9.0.5

2. Select the RowIterator widget near the top of the page. Scroll through the advanced options and find the
pageSize attribute. The default value is 5.
3. Set the pageSize as needed.
4. Save and close the file.

Configuring checks and payments

Each time a user creates a check, ClaimCenter associates it with at least one Payment transaction. This topic
describes the points in ClaimCenter in which you can configure the behavior of the Check wizard and its associated
payment fields.

Understanding checks and payments

Each Check entity has one or more Payment entities associated with it. Each Payment, in turn, has one or more
related TransactionLineItem objects that contain an Amount value. An individual Payment is worth the total of its
TransactionLineItem amounts. The value of each Check is the sum of its related Payment objects.
The PaymentType typelist is a final typelist that sets a payment type. A payment can be a partial, a final, or a
supplement type. Users set the check type on the Check wizard.
Payments can either erode the reserves or not. All supplemental payments do not erode reserves. A user must
explicitly mark a payment that is partial or final as non-eroding. Otherwise, these payment types always erode
reserves.
ClaimCenter maintains a running total of both the eroding and non-eroding payments. To access this information,
use the following:
• gw.api.financials.FinancialsCalculationUtil.getPendingApprovalErodingPaymentsExpression
• gw.api.financials.FinancialsCalculationUtil.getPendingApprovalNonErodingPaymentsExpression

Permissions and authority limits that apply to payments

The following are default system permissions associated with checks and payments:

Permission Description
claimviewpay View checks and payments (and derived information) on a claim
clearedpayvoid Void a cleared check

manpaycreate Create manual payment transactions

manpaydelete Delete manual payment transactions
manpayedit Edit manual payment transactions
paycreate Create payment transactions
paydelete Delete payment transactions
payedit Edit payment transactions
payrecode Recode a payment
paystop Stop a check
payvoid Void a check

Configuring checks and payments 777

 Configuration Guide 9.0.5

In the base configuration, Guidewire grants the clearedpayvoid permission to the User Admin or Superuser roles
only. Guidewire grants all other check and payment permissions to the following roles:
• Adjuster
• Claims Supervisor
• Clerical
• Manager
• New Loss Processing Supervisor
• Superuser
The following roles have the claimviewpay permission:
• Customer Service Representative
• Integration Admin
• Viewer
On the Administration page, you can set the following payment authority limits for users. (Again, these are taken from
the AuthorityLimitType typelist.)

Code Name Description

cptd Claim payments to The total amount of payments to date for the claim
date
eptd Exposure payments The total amount of payments to date for a single exposure
to date
pa Payment amount The amount of a single payment
per Payments exceed The amount by which payments are allowed to exceed reserves—if configuration parameter All
reserves owPaymentsExceedReservesLimits is set to true. See “Application configuration parameters”
on page 41 for more information on configuration parameters.

Editing checks in rules

When multiple currencies are used in ClaimCenter, some discrepancies can arise between the time a payment is
created and approved. For example, if a payment is created in a foreign currency, it uses the exchange rate that is
current at the time. If the exchange rate changes in the time period between when the payment is created and
approved or issued, the payment amount is impacted.
You can create a Gosu rule to make this payment amount adjustment to accommodate the exchange rate variance.
Use the CheckSet.prepareForCommit method to edit existing payments in rules.

Reset exchange rate in a check

About this task

In the following example, a sample rule is created that resets the manual exchange rate used in a check to the market
exchange rate.

Procedure
1. Start Guidewire Studio.
2. Navigate to the configuration→config→Rule Sets→Preupdate→TransactionSetPreupdate rule set.
3. Right-click the TransactionPre-update root entity and select NewRule.
4. Create a new rule, TPU09000 - Edit Existing Payment, as follows:

778 chapter 57 Configuring ClaimCenter financial screens

 Configuration Guide 9.0.5

uses gw.api.locale.DisplayKey
uses gw.api.financials.CheckUtil
uses gw.api.util.CurrencyUtil
uses gw.api.financials.TransactionApprovalRuleParameters

CONDITION(transactionSet : entity.TransactionSet) :
return transactionSet typeis CheckSet

ACTION (transactionSet : entity.TransactionSet, actions : gw.rules.Action) :

// Edit existing payment to make foreign exchange rate adjustment

var checkSet = transactionSet as CheckSet
checkSet.resetCheckAndPaymentsToDraft()
for (check in (transactionSet as CheckSet).Checks)
{
for (payment in (check.Payments))
{
if (payment.OverrideTransToReservingExchangeRate == true)
{
payment.OverrideTransToReservingExchangeRate = false
payment.TransToReservingExchangeRate =
CurrencyUtil.getMarketExchangeRateEntity(payment.Currency, payment.ReservingCurrency)
}
}
}
checkSet.prepareForCommit()

Configuring the check wizard

You can configure the Check Wizard screens using the Check Wizard PCF files and the functionality in the
CheckWizardInfoBase and CheckWizardInfo classes and their subtypes in gw.api.financials. For creating
checks in rules and locations other than the user interface, use a CheckCreator available from Claim and Exposure.
For more information, see “Creating checks and payments by using CheckCreator” on page 761.
The most commonly configured aspects of check validation are included in the CheckValidationMethodsImpl
class. These validations are enforced both in the Check Wizard and when creating a check in rules that use the
CheckCreator methods on Claim and Exposure.
You can modify the Check Wizard PCF files to provide defaults and add additional code. Your changes must be
additive. Do not remove method calls or logic from the Check Wizard without consulting Guidewire.

Configuring the check wizard recurrence settings

Suppose that you would like to pre-populate recurrence settings in the Check wizard with values entered elsewhere
in ClaimCenter. The recurrence settings appear in the Set Check Instructions step of the Check wizard.
To pre-populate these fields, navigate in Guidewire Studio to pcf → claim → newtransaction → check and click
NewPaymentInstructionsDV. Locate the CheckRecurrenceInputSet widget and double-click the widget to open it in a
separate view.
If you click the main CheckRecurrenceInputSet widget and then click the Variables tab below the widget, you see that
there is recurrenceHelper variable defined. This variable maps to the following class:

gw.financials.CheckRecurrenceUIHelper

You can open this class and view or modify its business logic.
For example, to modify the defaults when creating a new weekly or monthly check recurrence, modify the
createRecurrenceWithDefaults method on one of the inner classes WeeklyRecurrenceUIHelper or
MonthlyRecurrenceUIHelper. These inner classes are defined at the bottom of CheckRecurrenceUIHelper.

Configuring the check wizard 779

 Configuration Guide 9.0.5

Check recurrence data model

In the base configuration, ClaimCenter provides the following entities for working with check recurrence:
• Supertype CheckRecurrence contains the general information such as number of checks and first send date.
• Subtypes MonthlyCheckRecurrence and WeeklyCheckRecurrence provide more fields for granular frequency.
The following lists describe the important fields on these entities.

CheckRecurrence
IssuanceDateOffset Number of days before a check is due that ClaimCenter needs to issue the check

FirstDueDate Due date of the first check in recurrence

NumChecks Number of checks in the recurrence
RecurrenceDay Day of the week the check is due
MonthlyCheckRecurrence
MonthlyFrequency Generate a check every n months
RecurrenceDate Day of every month the check is due
RecurrenceWeek Week in the month the check is due
WeeklyCheckRecurrence
WeeklyFrequency Generate a check every n weeks

Configuring the check wizard’s default payment type

For a new payment on an open exposure, the Payment Type drop-down list has the following options:
• Partial
• Final
You can set the default for this control to one value or the other based on the selected Cost Type or some other value.
First, edit the file at pcf→claim→newtransaction→shared→NewPaymentDetailDV. In this file, you create a Gosu method
that sets the Payment.PaymentType property. You can create this method either in a Gosu class or in the PCF file.
To create it in the PCF file, click the top level DetailViewPanel : NewPaymentDetailDV and then click the Code tab below.
After defining the method, you can click the Reserve Line selector control on NewPaymentDetailDV and call it in the
onChange property. In the base configuration, the onChange property sets the payment type to null with the code
Payment.PaymentType = null;. If you change this code to use your method, the payment’s payment type is
updated when the user selects a particular reserve line.

Configuring straight-through invoice processing (STIP)

Straight-through Invoice Processing (STIP) enables the automatic approval and payment of invoices in ClaimCenter.
Only invoices that meet certain predefined criteria are eligible for STIP. Payments can be made at the claim or
exposure level.
Using STIP, you can:
• Automatically approve invoices
• Automatically pay invoices
Invoices can be added to ClaimCenter in two ways:
• They can be created manually by a ClaimCenter user.

780 chapter 57 Configuring ClaimCenter financial screens

 Configuration Guide 9.0.5

In this case, the user’s permissions and authority limits determine if the invoices can be automatically approved
or paid.
• They can be imported into ClaimCenter from an external vendor portal.
In the case of imported invoices, the user permissions and authority limits associated with the web service used
for the import determine whether invoices can be automatically approved or paid.
This topic describes how STIP can be configured.

Using the IInvoiceAutoProcessingPlugin plugin

Invoice approval and payment can be automated using two STIP components—a list of
InvoiceAutomaticStateTransitionHelper classes and the IInvoiceAutoProcessingPlugin. In ClaimCenter, an
invoice can be entered directly or imported through integration with another financial system. When an invoice is
entered, imported, or changed, the InvoiceAutomaticProcessor works with each of the helper classes to determine
if it qualifies for automatic, straight-through processing. Then, based on the evaluation, it takes appropriate action.
In the base configuration, the IInvoiceAutoProcessingPlugin plugin uses two helper classes:
• InvoiceAutoApprovalHelper—This helper class processes invoices that require approval. It contains a
checklist of reasons that will disqualify an invoice from auto-approval. For example, if the claim is closed or
under investigation. If none of the disqualifying reasons are met, the invoice is automatically approved. If any of
the disqualifying reasons are met, the invoice is not automatically approved and the list of failures is recorded on
the invoice.
The following is an example of some failure reasons that can be included in the InvoiceAutoApprovalHelper.
A common configuration would be to comment out or modify these, as required.

/**
* Returns a list of the reasons the supplied invoice is NOT qualified.
* If the collection is empty, no objections could be found.
**/
override protected function getFailedToQualifyReasons(invoice: ServiceRequestInvoice): List<String>
{
var serviceRequest = invoice.ServiceRequest
var claim = serviceRequest.Claim
var failureReasons: List<String> = {}

if (claim.State == ClaimState.TC_CLOSED)
{
failureReasons.add(DisplayKey.get("Web.Plugin.InvoiceAutoApproveAutoPayPlugin.ClaimIsClosed"))
}

if (claim.SIUStatus == SIUStatus.TC_UNDER_INVESTIGATION)
{
failureReasons.add(DisplayKey.get("Web.Plugin.InvoiceAutoApproveAutoPayPlugin
.ClaimHasActiveSIU"))
}

if (claim.applyFinancialHolds())
{
failureReasons.add(DisplayKey.get("Web.Plugin.InvoiceAutoApproveAutoPayPlugin.
ClaimIsUnderFinancialHold"))
}

• InvoiceAutoPaymentHelper—This helper class processes invoices that require payment. It contains a list of
failure reasons, similar to the InvoiceAutoApprovalHelper class, which might disqualify an invoice from auto-
payment. In the case of manual invoices, the creating user’s permission and authority limits are used to determine
if an invoice can be automatically paid.
The following is an example of some failure reasons that can be included in the InvoiceAutoPaymentHelper. A
common configuration would be to comment out or modify these, as required.

/**
* Returns a list of the reasons the supplied invoice is NOT qualified.
* If the collection is empty no objections could be found.
**/
override protected function getFailedToQualifyReasons(invoice: ServiceRequestInvoice): List<String>

Configuring straight-through invoice processing (STIP) 781

 Configuration Guide 9.0.5

{
final var failureReasons = new ArrayList<String>()
final var serviceRequest = invoice.ServiceRequest
final var owners = getFilteredReserveLineOwners(invoice)
final var claim = serviceRequest.Claim

if (!serviceRequest.Claim.AtAbilityToPay)
{
failureReasons.add(DisplayKey.get("Rules.TransactionApproval.ClaimNotAtAbilityToPay"))
}

// Are owners AtAbilityToPay?

var exposuresNotAtPayment = new TreeSet<Integer>()
for (owner in owners)
{
if (owner typeis Exposure and !owner.AtAbilityToPay)
{
exposuresNotAtPayment.add(owner.ClaimOrder)
}
}
if (exposuresNotAtPayment.HasElements)
{
failureReasons.add(DisplayKey.get("Java.Rules.TransactionApproval.
ExposuresNotAtAbilityToPay", exposuresNotAtPayment.join(", ")))
}

// Has this invoice ever had any unpay operations?

var finalUnpayOperation: ServiceRequestChange
for (change in invoice.ServiceRequest.History)
{
if (change.RelatedStatement == invoice and change.Operation ==
ServiceRequestOperation.TC_UNPAYINVOICE)
{
// save the one with the highest sequence
if (finalUnpayOperation == null or finalUnpayOperation.Sequence < change.Sequence)
{
finalUnpayOperation = change
}
}
}

If an invoice does not qualify for STIP, you need to process it manually using the usual steps in the application, such
as using the Check Wizard to make payments.
When an imported invoice fails to qualify for STIP, a new activity is generated to notify users that the work must be
done manually.

Disabling STIP
You can change or disable invoice automation by modifying the IInvoiceAutoProcessingPlugin and its
associated helper classes.

Disabling invoice automation

You can disable automatic invoice processing by simply removing the IInvoiceAutoProcessingPlugin
implementation from the registry. Subsequently, all invoices entered in ClaimCenter would need to go through the
usual, manual steps in the application.
Alternately, you can choose to disable either one of the helper classes for selective invoice automation. For example,
if you comment out the InvoiceAutoPaymentHelper class, invoices that qualify would be automatically approved,
but payment would still be processed manually.

Modifying STIP helper classes

You can alter or disable the failure reasons included in the helper classes used by the
IInvoiceAutoProcessingPlugin. The InvoiceAutoApprovalHelper and InvoiceAutoPaymentHelper classes
contains a list of reasons, which disqualify an invoice from automatic approval and payment respectively. You can
edit these reasons, or comment them out altogether if you prefer to process all invoices manually.
In the following example, the check for the claim’s validation level is disabled for invoice auto-approval:

782 chapter 57 Configuring ClaimCenter financial screens

 Configuration Guide 9.0.5

/**
* Returns a list of the reasons the supplied invoice is NOT qualified.
* If the collection is empty no objections could be found.
**/
override protected function getFailedToQualifyReasons(invoice: ServiceRequestInvoice): List<String>
{
...
/*if (!serviceRequest.Claim.AtAbilityToPay)
{
failureReasons.add(DisplayKey.get("Rules.TransactionApproval.ClaimNotAtAbilityToPay"))
} */

Configuring STIP – modifying limits

You can configure several aspects of STIP, including selection of reserve lines for invoices, the creation and
processing of checks, and the qualification criteria for automatic processing. This topic includes an example of
configuring the monetary amounts specified in invoice processing.

Example 1. Modify the approval limit amount

About this task

In the base configuration of ClaimCenter, straight-through invoice processing includes two monetary limits in the
InvoiceAutoApprovalHelper and InvoiceAutoPaymentHelper classes. These values specify the monetary limit
for invoices that qualify for automatic approval and payment.
Use the following steps to modify these limits:

Procedure
1. If necessary, start Guidewire Studio.
At a command prompt, navigate to the ClaimCenter directory and enter:

gwb studio

2. Navigate to configuration→gsrc→gw→plugin→vendormanagement and open InvoiceAutoApprovalHelper.

3. The SmallAmountThresholds method defines limit values for auto-approval by currency. Edit the threshold
limit for the United States dollar as follows:

Currency.TC_USD -> 1000bd

Note: You can use a similar method to define a payment limit in the InvoiceAutoPaymentHelper class.
4. Save your changes.

Result
The monetary limit for auto-approval for invoices is now set to $1000.

Example 2. Disqualify claims with large losses from auto-payment

About this task

In the base configuration of ClaimCenter, straight-through invoice processing includes an initial list of failure
reasons in the InvoiceAutoApprovalHelper and InvoiceAutoPaymentHelper classes. These reasons, if met,
would disqualify an invoice from being automatically approved or paid.
In this example, an additional failure reason to disqualify large loss claims from being auto-paid is added to the
helper class.
Use the following steps to add a failure reason:

Configuring straight-through invoice processing (STIP) 783

 Configuration Guide 9.0.5

Procedure
1. If necessary, start Guidewire Studio.
At a command prompt, navigate to the ClaimCenter directory and enter:

gwb studio

2. Navigate to configuration→gsrc→gw→plugin→vendormanagement and open InvoiceAutoPaymentHelper.

3. Navigate to the getFailedToQualifyReasons method, which lists the failure reasons included in the base
configuration.
4. Add a new failure reason, which checks for the claim’s large loss status, as follows:

//Is the claim classified as a large loss?

if (claim.LargeLossClaimIndicator.IsOn)
{
failureReasons.add(DisplayKey.get("Web.Plugin.InvoiceAutoApproveAutoPayPlugin.ClaimIsALargeLoss"))
}

5. Navigate to configuration→config→locale and open display_en_US.properties.

6. Add a display key to describe the new failure reason added in Step 4, as follows:

Web.Plugin.InvoiceAutoApproveAutoPayPlugin.ClaimIsALargeLoss = The Claim is classified as a large loss

7. Save your changes.

Configuring financial holds

You can configure several things about financial holds functionality, including:
• How ClaimCenter automatically sets the Coverage in Question field.
See “Modifying the automatic setting of coverage in question” on page 784.
• The conditions that cause financial holds to be placed on a claim.
See “Modifying the conditions for applying financial holds” on page 785.
• The conditions that permit claimcost initial reserves to be created.
See “Modifying claimcost initial reserves” on page 785.
For an introduction to financial holds, see the Application Guide.

Modifying the automatic setting of coverage in question

In the base ClaimCenter configuration, the ClaimPreupdate rule CPU20000 - Coverage in question and its children set the
Coverage in Question field on the Summary Claim Status screen. This rule calls a method found in a claim enhancement,
GWClaimFinancialHoldsEnhancement.gsx.
The method called from CPU20000 is claim.isCoverageInQuestion. This method calls the helper method
getCoverageInQuestionFactors, which does the real work to determine if any of the factors apply.
In the base configuration, the GWClaimFinancialsHoldsEnhancement.getCoverageInQuestionFactors method
checks the following to see if the coverage is in question:
• If the loss date is after the policy expiration date
• If loss date is prior to the policy effective date
• If the policy status is something other than In force or Archived
Extending the getCoverageInQuestionFactors method to test for additional factors is as simple as adding an
additional case, parallel to the other three. Check your new condition, and then add an entry to the return variable if
your condition applies.

784 chapter 57 Configuring ClaimCenter financial screens

 Configuration Guide 9.0.5

Modifying the conditions for applying financial holds

In the base ClaimCenter configuration, ClaimCenter applies financial holds in the following cases:
• The claim’s coverage is in question.
• The claim is marked as incident only.
• The claim’s policy is unverified.
You can configure this functionality in Guidewire Studio in the transaction set validation rule TXV15000 – Financial
Holds and its children. This functionality is controlled by the method applyFinancialHolds found in the
gw.entity.GWClaimFinancialHoldsEnhancement.gsx claim enhancement.

Add a new condition for applying financial holds

Procedure
1. In ClaimCenter Studio, edit the gw.entity.GWClaimFinancialHoldsEnhancement.applyFinancialHolds
method, adding an additional case for it to return true. The default method code is as follows:

function applyFinancialHolds() : Boolean {

return this.CoverageInQuestion
or this.IncidentReport
or not this.Policy.Verified
}

2. Navigate in the resources pane on the left to configuration→config→Rule

Sets→Validation→TransactionSetValidationRules→Transaction Validation Rules→TXV15000 - Financial Holds.
3. Add a new transaction validation rule under TXV15000 - Financial Holds that has specific warning and error
rejections for the new case. Use one of the existing rules, such as TXV15100 - Coverage In Question, as a template.

Modifying claimcost initial reserves

The base configuration of ClaimCenter prevents any claimcost initial reserves from being created when financial
holds apply. This functionality is handled by checking for financial holds status before creating initial reserves in the
InitialReserve rule set.
For example, navigate to configuration→config→Rule Sets→InitialReserve→InitialReserve→Initial Reserve→IRR01000 -
Auto→IRR01100 - Vehicle Damage→IRR01110 - Minor. This rule checks for financial holds and creates a claimcost
reserve only if there are no financial holds:

if(exposure.Claim.applyFinancialHolds() == true) {
exposure.Claim.createNoteIfInitialReservesNotCreated()
} else {
exposure.createInitialReserve(
"claimcost", "body", ScriptParameters.InitialReserve_AutoMinorVehicleDamageBody )
}

IMPORTANT If you add rules to the InitialReserve rule set, you must also perform the check for financial holds
before creating claimcost reserves. If you do not perform this check, ClaimCenter will create the reserves in the
rule set and then reject them in the TransactionSetValidationRules rule set. Because the reserve and the new exposure
are in the same bundle, you will not be able to save your new exposure.

Configuring authority limits

In ClaimCenter, authority limits are used to determine if a financial transaction can be automatically approved or
requires manual intervention by a supervisor. Authority limits are grouped into an Authority Limit Profile, which
can then be associated with different users. You manage authority limit profiles in the ClaimCenter Administration tab.

Configuring financial holds 785

 Configuration Guide 9.0.5

You can configure authority limits according to application requirements. Some examples are adding authority limit
types such as policy type or , coverage, cost type, lines of business, coverage subtype, and cost category.
Authority limits are configured and extended using the TransactionSetAuthorityLimitsPlugin. For example,
you can add additional limit types, such as Recovery.
See also
• Application Guide

Add an authority limit type

About this task
In this example, you add a new authority limit type to ClaimCenter – Recovery.
Use the following steps to extend authority limits to include the new type.

Procedure
1. If necessary, start Guidewire Studio.
At a command prompt, navigate to the ClaimCenter directory and enter:

gwb studio

2. Extend the AuthorityLimitType typelist. Navigate to configuration→config→Extensions→Typelist.

3. Right-click and select New→TypelistExtension.
4. In the Typelist Extension window, select Authority Limit Type.
5. In the new AuthorityLimitType.ttx window, enter the following:

Name Value
code ra

name Recovery amount

desc The amount of recoveries allowed on a claim.

6. Add a corresponding method to calculate the sum of recoveries in a TransactionSet. Navigate to

configuration→gsrc→gw→plugin→authoritylimits→sum and open the AbstractAuthoritySum Gosu class.
7. Add the following function, sumRecoveries, to calculate recoveries:

/**
* Sums up the claim amounts of the given recoveries matching the given CoverageType and CostType.
*
* @param recoveries array of recoveries whose claim amounts are to be summed
* @param coverageType only recoveries with this CoverageType should be included in the sum
* @param costType only recoveries with this CostType should be included in the sum
* @return the sum of the claim amounts of the given recoveries matching the given
* CoverageType and CostType
*/
function sumRecoveries(recoveries: Recovery[], coverageType: CoverageType, costType: CostType):
CurrencyAmount
{
Assert.check(recoveries.length > 0 ? null : "There must be at least one recovery in the
RecoverySet.")
var sum = CurrencyAmount.getStrict(BigDecimal.ZERO, recoveries[0].Claim.Currency)
for (var recovery in recoveries)
{
var reserveExposureCoverageType = (null != recovery.Exposure) ?
recovery.Exposure.PrimaryCoverage : null
if (isNullOrEquals(coverageType, reserveExposureCoverageType)
&& isNullOrEquals(costType, recovery.CostType))
{
sum = sum.addStrict(recovery.ClaimAmount)
}

786 chapter 57 Configuring ClaimCenter financial screens

 Configuration Guide 9.0.5

}
return sum
}

8. Create a new Gosu class, RecoveryAmountSum, which extends AbstractAuthoritySum. Right-click

AbstractAuthoritySum and select New→GosuClass.
9. Create RecoveryAmountSum as follows:

package gw.plugin.authoritylimits.sum

uses gw.pl.util.Assert
uses gw.api.financials.CurrencyAmount
uses java.math.BigDecimal
uses java.math.RoundingMode

@Export
class RecoveryAmountSum extends AbstractAuthoritySum
{
override function exceedsLimit(bean: Approvable, limit: AuthorityLimit): boolean
{
Assert.check(bean typeis RecoverySet ? null : "Bean must be a RecoverySet")
Assert.check(limit.LimitType == AuthorityLimitType ? null : "The limit must be of type " +
AuthorityLimitType + " not " + limit.LimitType)
var recoveries = (bean as RecoverySet).Recoveries
Assert.check(recoveries.length > 0 ? null : "There must be at least one recovery in the
RecoverySet.")
var sum = CurrencyAmount.getStrict(BigDecimal.ZERO, recoveries[0].Claim.Currency)
sum = sum.addStrict(sumRecoveries(recoveries,
limit.CoverageType, limit.CostType))
var limitAmount = limit.LimitAmount
if (sum.Currency != limitAmount.Currency)
{
limitAmount = limitAmount.convert(sum.Currency, RoundingMode.UP)
}
return (sum.absStrict().compareTo(limitAmount) > 0)
}

override property get AuthorityLimitType(): AuthorityLimitType

{
return typekey.AuthorityLimitType.TC_RA
}
}

10. The next step is to reference the new typecode and recovery sum class. Navigate to
configuration→gsrc→gw→plugin→authoritylimits and open AuthorityLimitsConfiguration.
In the buildEntryMap function, add the following line of code:

entries.add(new RecoveryEntry(AuthorityLimitType.TC_RA, new RecoveryAmountSum()))

11. Finally, comment out the overridden requiresApproval method in the RecoveryLimitTester Gosu class so
that the method in the base class, AuthorityLimitTester, is called:

/* override function requiresApproval(): ApprovalResult

{
return ApprovalResult.NO_APPROVAL_REQUIRED
}
*/

Add an authority limit filter

About this task
Authority limits can be filtered by specific values in the Administration screens. In this example, a new filter,
Coverage Subtype, is added to authority limits.

Procedure
1. If necessary, start Guidewire Studio.
Configuring authority limits 787
 Configuration Guide 9.0.5

At a command prompt, navigate to the ClaimCenter directory and enter:

gwb studio

2. Navigate to configuration→config→Extensions→Entity and open AuthorityLimit.etx.

3. Add CoverageSubType as a typekey. Click the plus icon ( ), and select typekey from the drop-down choice
list.
Enter the following values:

Name Value
name CoverageSubType

typelist CoverageSubType

nullok true
desc If non-null, the limit applies only to this coverage subtype.

4. Expand the index element in the typekey.

5. Click the plus icon ( ), and select indexcol from the drop-down choice list.
Enter the following values:

Name Value
name CoverageSubType

keyposition 5

6. Edit the key positions of two other index elements, as follows:

indexcol Name keyposition Value

CostType 6

Retired 7

7. Next, navigate to configuration→gsrc→gw→plugin→authoritylimits and open AuthorityLimitsConfiguration.

In AuthorityLimitComparator, add support for CoverageSubtype. The new lines of code are indicated with
a plus sign.

...
static class AuthorityLimitComparator implements Comparator<AuthorityLimit>
{
override function compare(al1: AuthorityLimit, al2: AuthorityLimit): int
{
// NOTE - NO NEED TO SORT ON AMOUNT, SINCE 2 DIFFERENT LIMITS CANNOT DIFFER ONLY IN AMOUNTS

var limitType1 = al1.LimitType

var policyType1 = al1.PolicyType
var coverageType1 = al1.CoverageType
+ var coverageSubType1 = al1.CoverageSubType
var costType1 = al1.CostType

var limitType2 = al2.LimitType

var policyType2 = al2.PolicyType
var coverageType2 = al2.CoverageType
+ var coverageSubType2 = al2.CoverageSubType
var costType2 = al2.CostType

if (limitType1 != limitType2)
{
// limit types are not equal, so we can just return result of comparing them
(we know they are not null).
return limitType1.compareTo(limitType2)
}
else if (policyType1 != policyType2)

788 chapter 57 Configuring ClaimCenter financial screens

 Configuration Guide 9.0.5

{
// policyTypes are not equal so sort them, putting null values (if any) last
return compareTypeKeysWithNullsOrderedLast(policyType1, policyType2)
}
else if (coverageType1 != coverageType2)
{
// coverageTypes are not equal so sort them, putting null values (if any) last
return compareTypeKeysWithNullsOrderedLast(coverageType1, coverageType2)
}
+ else if (coverageSubType1 != coverageSubType2)
+ {
+ // coverageSubTypes are not equal so sort them, putting null values (if any) last
+ return compareTypeKeysWithNullsOrderedLast(coverageSubType1, coverageSubType2)
+ }
else
{
// compare costTypes, putting null values (if any) last
return compareTypeKeysWithNullsOrderedLast(costType1, costType2)
}
}
...
}

8. In the limitApplies function, add the following condition:

...
var coverageSubType = limit.CoverageSubType
if (coverageSubType != null)
{
var exposure = transaction.Exposure
if (exposure == null || coverageSubType != exposure.CoverageSubType)
{
return false
}
}
...

9. Modify the getExposures function as follows (new code is indicated with a plus sign):

...
public static function getExposures(claim: Claim, final limit: AuthorityLimit) : Collection<Exposure>
{
+ if (limit.CoverageType == null && limit.CoverageSubType == null)
{
return null
}
return new HashSet<Exposure>(Arrays.asList(claim.Exposures.where(\ exposure ->
{
return (limit.CoverageType == null || (exposure.PrimaryCoverage != null && limit.CoverageType ==
exposure.PrimaryCoverage))
+ && (limit.CoverageSubType == null || (exposure.CoverageSubType != null && limit.CoverageSubType ==
exposure.CoverageSubType))
})))
}
...

10. Next, modify the reserveMatchesExposureAttributes method as follows (new code is indicated with a plus
sign):

...
public static function reserveMatchesExposureAttributes(reserve : Reserve, limit : AuthorityLimit) :
boolean
{
var reserveExposureCoverageType = (null != reserve.Exposure) ? reserve.Exposure.PrimaryCoverage :
null
+ var reserveCoverageSubType = (null != reserve.Exposure) ? reserve.Exposure.CoverageSubType : null
return (limit.CoverageType == null || limit.CoverageType == reserveExposureCoverageType)
+ && (limit.CoverageSubType == null || reserveCoverageSubType == limit.CoverageSubType)
}
...

11. Now, modify the validateTypecodeHierarchy method as follows (new code is indicated with a plus sign):

Configuring authority limits 789

 Configuration Guide 9.0.5

...
public static function validateTypecodeHierarchy(authorityLimit : AuthorityLimit)
{
if (authorityLimit.PolicyType != null && authorityLimit.CoverageType != null &&
!authorityLimit.CoverageType.hasCategory(authorityLimit.PolicyType))
{
authorityLimit.CoverageType = null
+ authorityLimit.CoverageSubType = null
}
+ if (authorityLimit.CoverageType != null && authorityLimit.CoverageSubType != null &&
+ !authorityLimit.CoverageSubType.hasCategory(authorityLimit.CoverageType))
+ {
+ authorityLimit.CoverageSubType = null
+ }
}
...

12. Lastly, still in AuthorityLimitsConfiguration, modify the getUniqueIdentifier method to include

CoverageSubType as follows (new code is indicated with a plus sign):

...
private static function getUniqueIdentifier(limit : AuthorityLimit) : String
{
return (limit.LimitType == null ? limit.LimitType : limit.LimitType.Code) + "-" +
(limit.PolicyType == null ? limit.PolicyType : limit.PolicyType.Code) + "-" +
(limit.CoverageType == null ? limit.CoverageType : limit.CoverageType.Code) + "-" +
+ (limit.CoverageSubType == null ? limit.CoverageSubType : limit.CoverageSubType.Code) + "-" +
(limit.CostType == null ? limit.CostType : limit.CostType.Code) /*+ "-" +
asAuthorityLimitInternal(limit).ClaimID */;
}
...

13. Navigate to configuration→config→locale and open the display_en_US.properties file. Add coverage
subtype to AuthorityLimit.AuthorityLimitError.

AuthorityLimit.AuthorityLimitError = Cannot create two authority limits with the same limit type,
policy type, coverage, coverage subtype, and cost type

14. Add a display key for the new authority limit filter.

LV.Admin.EditableAuthorityLimits.CoverageSubType = Coverage SubType

15. The next step is to make the corresponding changes to the relevant PCF files. Navigate to
configuration→config→web→pcf→admin→authoritylimits and open AuthorityLimitProfileDV.pcf.
16. Add a new TypeKeyCell widget to the right of Coverage Type. In the Properties tab, enter the following
values:

Name Value
editable true

id CoverageSubType

label "DisplayKey.get('LV.Admin.EditableAuthorityLimits.CoverageSubtype')"

value AuthorityLimit.CoverageSubType

valueType typekey.CoverageSubtype

Select the PostOnChange tab. Click the Enable targeted Post On Change check box and enter the following values:

Name Value
onChange gw.plugin.authoritylimits.AuthorityLimitsConfiguration.validateTypecode Hierarchy(Authorit
yLimit)

790 chapter 57 Configuring ClaimCenter financial screens

 Configuration Guide 9.0.5

Name Value
target DATA_ONLY

17. Navigate to configuration→config→web→pcf→admin→users and open EditableAuthorityLimitsLV.pcf.

18. Add a new TypeKeyCell widget to the right of Coverage Type. In the Properties tab, enter the following
values:

Name Value
editable true

id CoverageSubType

label "DisplayKey.get('LV.Admin.EditableAuthorityLimits.CoverageSubtype')"

sortOrder 4
value AuthorityLimit.CoverageSubType

valueType typekey.CoverageSubtype

Select the PostOnChange tab. Click the Enable targeted Post On Change check box and enter the following values:

Name Value
onChange gw.plugin.authoritylimits.AuthorityLimitsConfiguration.validateTypecode Hierarchy(Authorit
yLimit)

target DATA_ONLY

19. Edit the CostType TypeCell widget to update the sort order as follows:

Name Value
sortOrder 5

Configuring bulk invoice payments

This topic provides information about the support ClaimCenter provides for paying bulk invoices and contains the
following:
• “Overview of bulk invoices” on page 791
• “The bulk invoices data model” on page 792
• “Permissions for bulk invoice processing” on page 793

Overview of bulk invoices

You use a bulk invoice in Guidewire ClaimCenter to make a payment for an invoice that covers multiple claims. For
example, this can be an insurance company that receives a single monthly invoice from a rental car company for all
the rentals provided for the claims for that month. These types of invoices can have hundreds of line items (or
more), all for different claims. Using Bulk Invoices, users can create a single payment that corresponds to the
invoice and that assigns the appropriate portion of the payment to the individual claims.

Configuring bulk invoice payments 791

 Configuration Guide 9.0.5

ClaimCenter comes equipped with a set of permissions and roles that you can use to control access to the Bulk
Invoices feature. These permission are separate from the standard payment permissions. A user with the proper
permissions can work with the life cycle for a bulk invoice. This typically involves a user doing the following:
• Creating a bulk invoice object.
• Working on the invoice and saving a draft until all the associated information is complete.
• Validating the bulk invoice (and correcting any validation flags if necessary).
• Submitting the invoice for approval and subsequent payment.
ClaimCenter supports a batch process for processing bulk invoice payments. You can configure how often this batch
process occurs. Guidewire also provides a BulkInvoiceAPI web service that you can use to do post-processing on a
bulk invoice payment. For example, you can detect holds or voids originating in an external application and have it
reflected in the Bulk Invoices user interface. See the the Integration Guide for information on working with this API.
The Bulk Invoices user interface allows users to work on the invoice over time. ClaimCenter saves a draft of the
invoice until the user is ready to submit it for payment. Of course, before a user can submit a invoice, the invoice
must be both validated and approved. A bulk invoice validation plugin is responsible for handling this validation. If
you do not implement a validation plugin, after a user presses the Validate button, ClaimCenter simply marks the
invoice as Valid. See the Integration Guide for information on implementing a bulk invoice validation plugin.
If a bulk invoice requires approval, ClaimCenter creates an approval activity and assigns it to a user determined by
the approval routing rules. You must write bulk invoice approval rule sets that manage approval routing. These rule
sets are the only mechanism for controlling approval of bulk invoices. See the Rules Guide for information on
creating approval rule sets for bulk invoices.
Unlike other financial transactions, there are no specific authority limits for bulk invoices. Bulk invoices for
payments are subject to the general financial transaction authority limits for that user. ClaimCenter checks each
individual payment in the bulk invoice against the authority limit for the user.

The bulk invoices data model

The following table lists the data entities associated with bulk invoices:

Entity Description
BIValidationAlert An alert generated from the validation of a BulkInvoice. Your implementation of the IBulkInvoiceVa
lidationPlugin is responsible for returning these objects as necessary. Each alert consists of a
message and an alert type from the BIValidationAlertType typelist.
BulkInvoice Corresponds to the invoice requiring payment. This is the top-level entity. The creation and submission
of a BulkInvoice entity results in a single large payment to the payee for this BulkInvoice. A BulkInv
oice contains one or more BulkInvoiceItem objects.

BulkInvoiceItem An individual line item on the bill that contains an amount and other fields necessary to code the cost
of the item to a particular reserve line.
ReserveLineWrapper Supports the creation of a draft reserve line while the BulkInvoice is in a draft state. This entity exists
to support internal processing within ClaimCenter.

The following table lists the typelists associated with bulk invoices:

Typelist Description
BIValidationAlertType Defines possible alerts returned from the validation plugin. This list contains a single alert type:
• unspecified
You can extend this list to support your validation plugin.
BulkInvoiceItemStatus Status of a single BulkInvoiceItem. This value controls which actions are possible for a given Item.
This list is final. You cannot extend it.

792 chapter 57 Configuring ClaimCenter financial screens

 Configuration Guide 9.0.5

Typelist Description
BulkInvoiceStatus Defines business statuses of a BulkInvoice. This status controls which actions are possible for the
invoice (such as edit, submit, void, and so forth). This list is final. You cannot extend it.

Permissions for bulk invoice processing

By default, the following system permissions control access to the Bulk Invoices functionality:

bulkinvcreate Create a bulk invoice

bulkinvdelete Delete a bulk invoice

bulkinvedit Edit a bulk invoice

bulkinvview View a bulk invoice

In the base application configuration, Guidewire grants these permissions, by default, to the following roles:
• Adjuster
• Claims Supervisor
• Clerical
• Customer Service Representative
• Manager
• New Loss Processing Supervisor
• Superuser
There are no specific authority limits that apply only to bulk invoices. See “The CheckAuthorityLimits parameter
and bulk invoices” on page 793 for more information on the interaction between system-defined authority limits
and bulk invoices.

Configuring the bulk invoices feature

The config.xml file contains the following parameters that you can use to configure bulk payments:

BulkInvoiceApprovalPattern The name of the activity pattern to use while creating bulk invoice approval
activities. By default, the name of the activity is approve_bulkinvoice.
AllowPaymentsExceedReservesLimits This parameter applies to all payments, not just bulk payments. If this value is true,
bulk payments can exceed reserves for each BulkInvoiceItem on the invoice.

In the scheduler-config.xml file, you can configure how often the application runs the bulkinvoiceesc batch
process. By default, this happens every day 15 minutes after midnight and 5:00 PM.

The CheckAuthorityLimits parameter and bulk invoices

Bulk invoices are not subject to the ClaimCenter standard payment authority limits. However, your bulk invoice
configuration must take into account the CheckAuthorityLimits configuration parameter in config.xml. This is
because ClaimCenter submits a check created for a bulk invoice item through the same approval process as it does
for a check created through the New Check Wizard.

The bulk invoices data model 793

 Configuration Guide 9.0.5

The CheckAuthorityLimits configuration parameter controls whether ClaimCenter checks authority limits for all
financial transaction in ClaimCenter. By default, this parameter is true which means ClaimCenter does check. To
check authority limits on most transactions but exclude bulk invoices, you can do the following:
• Set CheckAuthorityLimits to false.
• Use the CheckSet.isForBulkedCheck method to test whether a transaction set has an associated bulk invoice.
• Use the TransactionSet.testAuthorityLimits method in your approval rules to manually check authority
limits for transactions not related to bulk invoices.
For more information about working with transaction approval in Gosu rules, see the Rules Guide.

794 chapter 57 Configuring ClaimCenter financial screens