Guidewire

ClaimCenter ™

System Administration 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: System Administration Guide
Document Revision: 27-April-2018
 System Administration Guide 9.0.5

Contents

About ClaimCenter documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

Conventions in this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

Part 1
Application Administration
1 Managing Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
ClaimCenter Default System Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
Default Owner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21
Super User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
System User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
Change the Unrestricted User. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
Minimum and Maximum Password Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

2 Application Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

Overview of Application Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25
The Logging Properties File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
The Logging Directory Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
Changes to the Logging Level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
Logging and the env Environment Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
The Log Files Directory and the View Logs Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
Adding Loggers to the Logging Properties File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
Logging Level Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
Understanding Logging Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
Logging Category Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
Viewing a List of Logging Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
Enabling Logging Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
Logging Category Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
Logger Category API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
Formatting a Log Message. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
Conversion Character Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
Format Modifier Reference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
Configure Logging in a Multiple Instance Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
Dynamic Changes to Logging Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
Setting the Logging Configuration Dynamically . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
Reloading the Logging Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38
Changing a Logging Level Temporarily . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
Configuring Archive Logging Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40
Print Details of the Archive Graph. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
Generate a Separate Archive Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
ClaimCenter Logging Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41
Batch Processes that Generate Archive Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42

Part 2
Server Administration

Contents 3
 System Administration Guide 9.0.5

3 ClaimCenter Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45

Important ClaimCenter Server Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
Understanding the ClaimCenter Server Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
Understanding the Configuration Registry Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
The Configuration Registry Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46
Example Syntax for Registry Server Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
Example Syntax for the Registry System Property Element . . . . . . . . . . . . . . . . . . . . . . . . .49
Assigning Server Roles to ClaimCenter Cluster Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . .50
Defining a New Server Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50
JVM Options and Server Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
JVM Options for gwb Build Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51
JVM Options Specific to the runServer Build Command . . . . . . . . . . . . . . . . . . . . . . . . . . .52
Setting JVM Options in ClaimCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52
Configuration Parameters by Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53
Default Configuration Values and Environment Properties . . . . . . . . . . . . . . . . . . . . . . . . . .54

4 ClaimCenter Server Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55

Starting Guidewire ClaimCenter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
Start ClaimCenter on QuickStart (Jetty) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
Start the Application Server from ClaimCenter Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
Stopping GuidewireClaimCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
Stop Guidewire ClaimCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56
Server Startup Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
Server Modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57
Important Server Mode Caveats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58
Server Modes as a Safety Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58
Server Test Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58
Setting the Server Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58
Determining the Server Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
Server Run Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59
Server Modes and Server Run Levels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
Setting the Quick Start Server Run Level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
Set the QuickStart Run Level at Server Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
Set the Server Run Level Through System Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
Set the Server Run Level Through Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
Determining the Server Run Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
Use System Tools to Determine the Server Run Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62
Use Web Services to Determine the Server Run Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62
Server Maintenance Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .62
Place the Server in Maintenance Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
Monitoring Server Performance in ClaimCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
Monitoring Server Status with WebSphere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63
Monitoring and Managing Event Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64
About Message Failure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64
Message Queues Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .64
Message Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .65
Access the Messaging Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
Purge Completed Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66
Session Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67
User Session Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67
Server Caching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68
Cache Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68
Caching and Stickiness. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68
Concurrent Data Change Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69
Caching and Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69

4
 System Administration Guide 9.0.5

Cache Behavior and Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69

Server Cache Tuning Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71
Special Caches for Rarely Changing Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
Server Memory Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
Memory Usage Logging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73
Enabling Garbage Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .74
Understanding Possible Memory Leak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
Heap Dump Generation and Analysis Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
JVM Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78
Large Object Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78

5 Geocoding, Catastrophe Search, and Heat Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79

Understanding Geocoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79
Configuring Geocoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80
About Guidewire Geocoding Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81
Enable the Geocode Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81
Schedule Geocode Batch Processing Runs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82
Configure the Number of Worker Instances for Geocode Batch Processing. . . . . . . . . . . . . . .82
Catastrophe Search and Heat Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
Enable the Catastrophe Heat Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83
Enable the Catastrophe Policy Location Download Batch Process . . . . . . . . . . . . . . . . . . . . .84

6 Administering Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85

Overview of Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
Work Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86
Batch Processes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
Working with batch processing types in Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89
Working with Work Queue Writers and Batch Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
Run a Writer from ClaimCenter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90
Run a Batch Process from ClaimCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .91
Run a Writer or Batch Process from the Command Prompt. . . . . . . . . . . . . . . . . . . . . . . . . .91
Terminate a Writer or Batch Process from the Command Prompt . . . . . . . . . . . . . . . . . . . . .92
Check Status of a Writer or Batch Process from the Command Prompt . . . . . . . . . . . . . . . . .92
The Work Queue Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
Understanding a Work Queue Schedule Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93
Determine If It Is Possible to Schedule a Batch Process . . . . . . . . . . . . . . . . . . . . . . . . . . . .95
View a Batch Process Schedule in ClaimCenter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96
Scheduling Batch Processes for Specific Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . .96
Disabling the ClaimCenter Scheduler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96
Configuring Work Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96
The Work Queue Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96
General Work Queue Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .97
Worker Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .98
Worker Task Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99
Work Queues and Server Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99
Performing Custom Actions After Batch Processing Completion . . . . . . . . . . . . . . . . . . . . . . . . 100
Schedule the Process Completion Monitor Batch Process . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Implement the IBatchCompletedNotification Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Register a Custom Batch Notification Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Troubleshooting Work Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Work Queues and Batch Processes, a Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Activity Escalation Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Address Delete Batch Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Aggregate Limit Calculations Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Archive Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Archive Reference Tracking Sync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Contents 5
 System Administration Guide 9.0.5

Bulk Invoice Escalation Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Bulk Invoice Submission Batch Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Bulk Invoice Workflow Monitor Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Bulk Purge Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Catastrophe Claim Finder Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Catastrophe Policy Location Download Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . 108
Claim Contacts Calculations Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Claim Exception Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Claim Health Calculations Batch Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Claim Validation Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
ClaimCenter (SPM) Completed Review Sync Batch Processing . . . . . . . . . . . . . . . . . . . . . 111
Contact Retire Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Contact Auto-synchronization Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Dashboard Statistics Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Data Distribution Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Database Consistency Check Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Database Statistics Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Deferred Upgrade Tasks Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Destroy Contact For Personal Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Encryption Upgrade Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Exchange Rate Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Financials Calculations Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Financials Escalation Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Geocode Writer Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Group Exception Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Idle Claim Exception Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Idle Closed Claim Exception Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Notify External System For Personal Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Phone Number Normalizer Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Populate Search Columns Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Process Completion Monitor Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Process History Purge Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Purge Cluster Members Batch Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Purge Failed Work Items Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Purge Message History Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Purge Old Transaction IDs Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Purge Profiler Data Batch Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Purge Workflow Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Purge Workflow Logs Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Recalculate Claim Metrics Batch Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Remove Old Contact Destruction Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Retired Policy Graph Disconnector Batch Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Service Request Metric Escalation Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Solr Data Import Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Statistics Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
T-accounts Escalation Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
User Exception Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
User Workload Update Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Workflow Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Work Item Set Purge Batch Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Work Queue Instrumentation Purge Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Unused and Internal Batch Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

6
 System Administration Guide 9.0.5

Part 3
Server Clustering Administration
7 Understanding ClaimCenter Server Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Cluster Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Guidewire ClaimCenter Cluster Installations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Cluster Communication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Configuring Cluster Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Cluster Plugin Parameter Reference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Cluster Plugin System Properties Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Cache eviction messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Logging cluster plugin parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Server Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
batch Server Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
messaging Server Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
scheduler Server Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
startable Server Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
workqueue Server Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
ui Server Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Example ClaimCenter Cluster Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Cluster Member Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Cluster Member Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
User Interface Cluster Member Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Non-ui Role Cluster Member Shutdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

8 Working with a ClaimCenter Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Planning a ClaimCenter Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Create a Guidewire ClaimCenter Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Managing a ClaimCenter Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Enabling Guidewire Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Adding a Server to a ClaimCenter Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Performing a Cluster Configuration Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Add a Server to a ClaimCenter Cluster. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Restarting the ClaimCenter Cluster Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Monitoring Cluster Health . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Cluster Member Health . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Cluster Member Monitoring in ClaimCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Monitor Cluster Members Using System Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Using the ClaimCenter ping Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

9 Working with Component Leases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Component Lease Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Simple Lease Management Lifecycle for a Batch Process. . . . . . . . . . . . . . . . . . . . . . . . . . 160
Simple Lease Management Lifecycle for a Message Destination . . . . . . . . . . . . . . . . . . . . . 160
Component Lease Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Automatic Failover of a Component Lease . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
The Background Task Failover Plugin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Batch Process Prioritization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Messaging and Startable Service Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

10 Deploying Configuration Changes in a Clustered Environment . . . . . . . . . . . . . . . . . . . . . . . 167

Rolling Upgrade Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Risks Associated with Rolling Upgrade of Cluster Server Members . . . . . . . . . . . . . . . . . . 168
Backing Out a Rolling Upgrade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Assumptions Around a Rolling Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Differences between a Rolling Upgrade and a Full Upgrade. . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Contents 7
 System Administration Guide 9.0.5

Configuration Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Making Changes to Typelists in a Rolling Upgrade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Making Changes to LOB Typelists in a Rolling Upgrade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Adding New Loss Types in a Rolling Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Adding New Exposure Types in a Rolling Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Verification of Configuration Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Performing a Rolling Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Prepare for a Rolling Upgrade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Perform a Rolling Upgrade in a Test Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Perform a Rolling Upgrade in a Production Environment . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Unexpected Upgrades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Configuration Upgrade of a Production Stand-alone ClaimCenter Server . . . . . . . . . . . . . . . . . . 178

Part 4
Security Administration
11 Managing Secure Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
ClaimCenter and the Transport Layer Security Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
ClaimCenter and Secure Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
The ClaimCenter Connection Address. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Restricting access to a ClaimCenter screen by server mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

12 Securing Access to ClaimCenter Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Understanding the Object Access Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Understanding the ClaimCenter Permission Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Permission Class Generation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Beyond Roles and Permissions to Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Access Control Configuration Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
The Security Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Static Handler Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Wrap Handler Elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Object and Optional Object Handler Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

13 Securing Access to Notes and Documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Note Permission Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Note Permission Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Document Permission Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Document Permission Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Document Access Control Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Create a New Document Security Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Create Custom Permissions for a New Document Security Type . . . . . . . . . . . . . . . . . . . . . 197
Create a Document Access Profile for a New Document Type . . . . . . . . . . . . . . . . . . . . . . 197
Rebuild and Redeploy ClaimCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Add New Security Permissions to the Appropriate Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 198

14 Securing Access to Claims and Exposures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Claim Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Claim Access Control Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Claim Access Types and System Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
ClaimCenter and Claim ACL Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Controlling Access to Claim Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Claim Access Mapping Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Access Mapping Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Access Profile Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Activity Access Levels Elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

8
 System Administration Guide 9.0.5

Claim Access Levels Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

Claim Own Permission Elements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Exposure Access Levels Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
SubObject Own Permission Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Restrict Claim Ownership. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Example: Default Access Profile for Unsecured Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Example: Default Access Profile for Sensitive Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Exposure Access Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Exposure Security Controls Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Static Versus Claim-based Exposure Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Exposure Permissions Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Implementing Claim-based Exposure Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

Part 5
Database Administration
15 Database Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Accessing the Database Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
The Database Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
The Database autoupgrade Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
The databasestatistics Database Configuration Element. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
The dbcp-connection-pool Database Configuration Element . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
The reset-tool-params Database Configuration Element . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
The jndi-connection-pool Database Configuration Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Configuring JNDI Connection Initialization for Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
The loader Database Configuration Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
The callback Database Configuration Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
The loader-table Database Configuration Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
The oracle-settings Database Configuration Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
The sqlserver-settings Database Configuration Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
The upgrade Database Configuration Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
The mssql-db-ddl Database Configuration Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
The ora-db-ddl Database Configuration Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
The versiontriggers Database Configuration Element. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254

16 Database Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

About the Upgrade and Versions Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Database Best Practices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Understanding Data Model Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Run a Schema Verification Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Guidewire Database Direct Update Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
ClaimCenter Database Back Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Database Consistency Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Recommendations for Running Database Consistency Checks . . . . . . . . . . . . . . . . . . . . . . 263
Running Consistency Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Configuring the Number of Threads for Consistency Checks . . . . . . . . . . . . . . . . . . . . . . . 265
Recalculating Financial Summaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Rebuilding Contact Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Resize Database Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Purging Unwanted Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
About Purging Activity-related Workflow Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Purging Claim Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Purging Batch Process History Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Purging Cluster Member Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Purging Failed Work Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Contents 9
 System Administration Guide 9.0.5

Purging Message History Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

Purging Old Transaction ID Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Purging Profiler Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Purging Workflow Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Purging Workflow Log Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Purging Work Item Set Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Purging Work Queue Instrumentation Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Working with Claim Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Understanding Claim Purging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Understanding Claim Marking for Purging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Purging Claims Using Command Prompt Tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Purge Claims Using Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Configuration Parameters that Affect Claim Search on Oracle . . . . . . . . . . . . . . . . . . . . . . 277
Oracle Materialized Views for Claim Searches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

17 Database Statistics Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

Understanding Database Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Database Statistics Generation for Oracle Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Database Statistics Generation for SQL Server Databases. . . . . . . . . . . . . . . . . . . . . . . . . . 281
Updates to Database Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Understanding Database Statistics Batch Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Automatic Generation of Database Statistics During Upgrade . . . . . . . . . . . . . . . . . . . . . . . 281
Managing Database Statistics using System Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Perform a Full Database Statistics Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
Update Statistics on Tables that Exceed a Change Threshold. . . . . . . . . . . . . . . . . . . . . . . . 282
Check the Database Statistics Updating Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Cancel the Database Statistics Updating Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Generate Statistics SQL for All Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Generate Statistics SQL for Tables that Exceed a Threshold . . . . . . . . . . . . . . . . . . . . . . . . 284
Configuring Database Statistics Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Configuring the Number of Threads for Statistics Generation . . . . . . . . . . . . . . . . . . . . . . . 284
Statistics and the Database Configuration File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
The Database Statistics Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
The Table Statistics Database Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
The Histogram Statistics Database Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290

18 Importing and Exporting Administrative Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

Ways to Import Administrative Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
About the import Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Administration Data Import at Initial Server Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Security Zone Data Import at Initial Server Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Business Rules Import at Initial Server Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Controlling the Import of Data During Server Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
About Adding Admin Data after Initial Server Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Add Additional Roles and Privileges after Initial Server Startup . . . . . . . . . . . . . . . . . . . . . 294
Character Set Encoding for File Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Maintain Data Integrity During Administrative Data Import . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Administrative Data and the ClaimCenter Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Public ID Prefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Support for Unique Public IDs in a Development Environment . . . . . . . . . . . . . . . . . . . . . . 296
Constructing a CSV File for Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Constructing a Heading Line in CSV-formatted Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Constructing Data Lines in CSV-formatted Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Construct an XML File for Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Constructing the XML for the Administrative Data Import File. . . . . . . . . . . . . . . . . . . . . . 300
Using Tools to Import Administrative Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
10
 System Administration Guide 9.0.5

Import Administrative Data Using Import Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302

Importing and Exporting Administrative Data from ClaimCenter . . . . . . . . . . . . . . . . . . . . . . . . 303
About Importing ClaimCenter Administrative Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
About Exporting ClaimCenter Administrative Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Understanding Roles and Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Role Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Understanding Authority Limits and Authority Limit Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . 306
The Authority Limit Definition File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Importing Additional ICD Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Import New ICD Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Update ICD Code Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Expire Invalid ICD Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Importing Security Zone Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Understanding the Security Zones File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
View the XSD for Security Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Import Security Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
About Importing Zone Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Importing a Zone Data File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Importing Custom Zone Data Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312

19 Free-text Batch Load Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315

When to Run the Free-text Batch Load Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Prerequisites for Running the Free-text Batch Load Command. . . . . . . . . . . . . . . . . . . . . . . . . . 316
Run the Free-text Batch Load Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Recovering from Solr Batch Load Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Clean-up Tasks after Running the Free-text Batch Load Command. . . . . . . . . . . . . . . . . . . . . . . 317
Free-text Batch Load Command and Native SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

20 Production Data Fix Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

Overview of the Production Data Fix Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Typical Use of the Production Data Fix Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Writing Gosu Data Change Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Registering Data Change Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Run Gosu Data Change Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Logging Data Change Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Data Change Command Tool Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Data Change Web Service Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325

Part 6
Business Rules Administration
21 Administering Business Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Business Rules in Guidewire ClaimCenter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Business Rule Roles and Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Business Rule Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Business Rule Production Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Business Rule Versioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Rules for Deleting a Business Rule Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Business Rule Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Business Rule State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Business Rule Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Business Rule Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Invalid Business Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335

Contents 11
 System Administration Guide 9.0.5

22 Business Rules Import and Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337

Overview of Business Rule Export and Import. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
About Rule Version Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
Business Rule Import Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
Source and Target Data Models and Rule Export and Import . . . . . . . . . . . . . . . . . . . . . . . 338
Export Business Rules from Guidewire ClaimCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
Import Business Rules into Guidewire ClaimCenter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
The Import/Export Status Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
About the Business Rules Export File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
The Review Import/Complete Import Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
The Rule Import Disposition Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
The Rule Import Manage Synchronization Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Business Rule Validation Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
The Compare Rules Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342
Resolve Rule Import Conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Automatic Import of Business Rules at Server Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Import ClaimCenter Business Rules at Server Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Correct Duplicate BizRuleDeploymentId Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345

Part 7
Administration Tools
23 Server Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Accessing the Server Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Batch Process Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Processes Table Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Chart and History Tabs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Download a Batch Process History Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Work Queue Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Work Queue Table Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Item Statistics Tabs and Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Work Queue Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
The Work Queue Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Download a Work Queue Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
The Work Queue Raw Data Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
Download the Work Queue Raw Data Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
The Work Queue History Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Download the Work Queue History Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
About Work Queue Efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Set Log Level. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
View Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Info Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Archive Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Domain Graph Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Consistency Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Database Table Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Database Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
Database Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
Data Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Database Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Oracle Statspack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Oracle AWR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
Oracle AWR Unused Indexes Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379

12
 System Administration Guide 9.0.5

Oracle Outlines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380

SQL Server DMV Snapshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Microsoft JDBC Driver Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Load History. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Load Integrity Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Load Errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Runtime Environment Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Safe Persisting Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Loaded Gosu Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Serialization Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385
Management Beans. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Startable Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Cluster Members and Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
Cluster Members – This Application Server Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
Cluster Members – Application Server Instances. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Cluster Members – Components Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Cluster Members – History Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
The Cluster Components Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Download a Server Component Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Schedule a Planned Cluster Member Shutdown. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Upgrade and Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
The Upgrade Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Understanding Guidewire Software Versioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Cache Info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
The Cache Summary View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
The Historical Performance View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
The Cache Details View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Understanding the Cache Data Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Guidewire Profiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Guidewire Profiler Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Profiler Entry Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Web Session Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
ClaimCenter Application Profiling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Profiler Trace Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Guidewire Profiler Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Save a Profiler Analysis Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Ways to View a Guidewire Profiler Analysis Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Review Profiler Upgrade Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Profiler Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Profiler Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Profiler Stacks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Using Custom Profile Tags with Guidewire Profiler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Understanding Properties and Counters on a Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Understanding the Guidewire Profiler API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Profiler-related Configuration Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
JProfiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Metro Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410

24 Internal Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411

Accessing the Internal Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Reload. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
CC Sample Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412

25 Command Prompt Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413

Administration Tools Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
ClaimCenter Command Prompt Tools Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Contents 13
 System Administration Guide 9.0.5

Accessing Administration Tool Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414

Administration Tools Default User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
Administrative Tool Command Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
Data Change Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Data Change Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
FNOL Mapper Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
FNOL Mapper Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416
Import Tools Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Import Tools Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Maintenance Tools Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Maintenance Tools Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Messaging Tools Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
Messaging Tools Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
System Tools Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
System Tools Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Table Import Command. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
Table Import Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
Template Tools Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
Template Tools Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Workflow Tools Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Workflow Tools Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Zone Import Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Zone Import Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435

14
System Administration Guide 9.0.5

15
 System Administration 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.

16 About ClaimCenter documentation

 System Administration 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.
About ClaimCenter documentation 17
 System Administration Guide 9.0.5

Guidewire Customers
https://community.guidewire.com

Guidewire Partners
https://partner.guidewire.com

18 About ClaimCenter documentation

part 1

Application Administration
System Administration Guide 9.0.5
chapter 1

Managing Users

This topic discusses the default system users that Guidewire provides in the base ClaimCenter configuration.

ClaimCenter Default System Users

In the base configuration, ClaimCenter provides the following default system users:
• Default Owner
• Super User
• System User
Note: ClaimCenter default system users are separate and distinct from the users in the sample data that Guidewire
provides for testing and development purposes.
Guidewire provides each of these default users for a specific purpose and to fulfill one or more specific roles. In
most cases, it is not possible to delete a default user as internal code uses that user for a specific purpose. It is
possible to edit various aspects of user information, for example, setting a new password for that user.

Default Owner
Default system user defaultowner has the following characteristics.

User Default Owner

User name defaultowner
Group Default Root Group
Can delete No

User defaultowner has first name Default and last name Owner. In the base configuration, ClaimCenter does not
assign roles to this user.
If ClaimCenter cannot assign certain business objects to a specific user, ClaimCenter assigns that object to user
defaultowner. ClaimCenter performs this assignment internally.

Managing Users 21
 System Administration Guide 9.0.5

IMPORTANT Do not make direct assignments to user defaultowner.

Guidewire recommends, as a business practice, that someone in the organization periodically search for outstanding
work assigned to user defaultowner. If the search finds one of these assignments, the searcher must reassign these
items to a proper owner. Guidewire also recommends that the rule administrator investigate why ClaimCenter did
not assign an item of that type and correct any errors in the rules.

Super User
Default system user su has the following characteristics.

User Super User

User name su
Group Default Root Group
Can delete No

User su has first name Super and last name User. In the base configuration, ClaimCenter assigns the Superuser role
to the su user. The Superuser role has all permissions. Thus, user su has unrestricted access to the entire
ClaimCenter application.

IMPORTANT Guidewire strongly recommends that you change the Super User password from its default value.

User su and the Command Line Tools

To run the ClaimCenter command prompt tools, you must supply a user name and password. If you do not supply
the -user parameter, the command defaults to user su and you must supply that user’s password.
See also
• “Change the Unrestricted User” on page 23
• “Command Prompt Tools” on page 413
• Installation Guide

System User
Default system user sys has the following characteristics.

User System User

User name sys
Group Not a member of a group
Can delete No

User sys has first name System and last name User. In the base configuration, ClaimCenter does not assign roles to
this user.
ClaimCenter requires user sys to exist. ClaimCenter uses this user to perform automated work such as running batch
processing, messaging polling, and server startup. Each time ClaimCenter needs to do such work, it creates a session
with the sys user. This is why there might appear to be many sessions with the sys user. Session in this sense is not
a web session. Rather, it represents the authentication of a user.

22 chapter 1 Managing Users

 System Administration Guide 9.0.5

WARNING Do not rename or delete the sys user. Deleting or renaming this user disables ClaimCenter.

Temporary System Users

ClaimCenter creates system users in addition to the standard users who log into ClaimCenter.
ClaimCenter gives a designation of Temporary system user to an unauthenticated user session. ClaimCenter
creates such sessions for login. By design, ClaimCenter does not associate a user with the login screen. The
system_tools -sessioninfo command does not filter out this user. The Server Tools Management Beans screen
does filter out this user.

Change the Unrestricted User

About this task
By default, ClaimCenter uses su as the user with unrestricted access to the entire ClaimCenter application. It is
possible to change the unrestricted user.

Procedure
1. In the Studio Project window, expand configuration→config:
2. Open file config.xml for editing.
3. Set configuration parameter UnrestrictedUserName to the user name of the new unrestricted user:

<param name="UnrestrictedUserName" value="userName"/>

Minimum and Maximum Password Length

The MinPasswordLength and MaxPasswordLength parameters in config.xml control the minimum and maximum
number of characters for passwords. For example, if you want all users in your system to have a password length of
at least six characters and a maximum of sixteen, set the following in config.xml:

<param name="MinPasswordLength" value="6"/>

<param name="MaxPasswordLength" value="16"/>

Change the Unrestricted User 23

 System Administration Guide 9.0.5

24 chapter 1 Managing Users

chapter 2

Application Logging

ClaimCenter creates automatic logs of many actions by users and operations by the server.

Overview of Application Logging

Guidewire uses the slf4j API, in conjunction with Apache log4j libraries and internal Guidewire libraries, to
provide logging in the ClaimCenter application. A logging properties file controls the behavior of the logging
activity in the application.
The logging properties file uses Apache log4j formatting to define the following logging components:

Logger Logical file name. It is possible to configure each logger independently to log information at a certain level.
Appender Output point (destination) for a logger. This can be, for example, the application console or a specific logging file.
Layout Log entry formatting instructions. Each logger category can have its own layout format.

These logging component types work together to log messages according to the message type and severity level.
These components also define the format and the output destination for the various logging categories.
For more information on slf4j, see the following web site:

http://slf4j.org/index.html

For more information on Apache log4j loggers, appenders, and layouts, see the following web site:

http://logging.apache.org/log4j/1.2/manual.html

See also
• “The Logging Properties File” on page 26
• “Logging Category Reference” on page 31
• “Formatting a Log Message” on page 34

Application Logging 25
 System Administration Guide 9.0.5

The Logging Properties File

Properties file logging.properties specifies a number of system logging options for the ClaimCenter server. You
access this file from the following location in Guidewire Studio:
configuration→config →logging
The logging.properties file uses the format specified by Apache log4j. The entries in logging.properties
control what to log and to which file to write the log. In the base configuration, ClaimCenter sets the basic logging
configuration to the following:

log4j.rootCategory=INFO, Console, DailyFileLog

This setting:
• Instructs ClaimCenter to send system-wide informational messages to two output points: the ClaimCenter
console (Console) and a log file (with name DailyFileLog in the default configuration).
• Sets the default logging level to INFO.
Within file logging.properties, entries such as log4j.appender.* indicate the parameters of each output point.
These entries identify properties such as location or output format options. As ClaimCenter starts, it attempts to
write a log file in the location specified by log4j.appender.DailyFileLog.File. By default, ClaimCenter writes
to the following log file:

tmp/gwlogs/ClaimCenter/logs/cclog.log

ClaimCenter creates the log file automatically. However, if the directory specified by DailyFileLog.File does not
exist, ClaimCenter writes log information to the console only.
For more information about how to create and manage log4j entries in logging.properties, see the following
Apache web site:

http://logging.apache.org/log4j/1.2/manual.html

The Logging Directory Path

In file logging.properties, express all file locations using an absolute path. Regardless of operating system, you
must use forward slashes and not backslashes. The directory path that you specify must exist. ClaimCenter creates
the log file itself automatically.
Note: If you specify a non-existent logging directory path, ClaimCenter writes logging information to the
application console only.

Changes to the Logging Level

If you edit the logging.properties file and do not restart the server, the new logging level only take effects for
new database connections. You can, however, make an immediate logging change in the ClaimCenter server without
having to first redeploy ClaimCenter through the use of one of the following:
• Command prompt administration tool system_tools
• Web service SystemToolsAPI
See also
• “Dynamic Changes to Logging Configuration” on page 38
• “System Tools Command” on page 422
• Integration Guide

26 chapter 2 Application Logging

 System Administration Guide 9.0.5

Logging and the env Environment Property

If the env environment property is non-existent (null), ClaimCenter reads the logging configuration from the
default logging.properties file.
If the env environment property is non-null, however, ClaimCenter tries to obtain the logging configuration from an
env-logging.properties file in the following ClaimCenter directory:

modules/configuration/config/logging

For example, if you have an environment called test, ClaimCenter looks for logging properties in test-
logging.properties. If this file does not exist, then ClaimCenter reads the logging configuration from the default
logging.properties file.
See also
• “Understanding the ClaimCenter Server Environment” on page 46
• “Configure Logging in a Multiple Instance Environment” on page 36

The Log Files Directory and the View Logs Screen

ClaimCenter includes a log viewer on the Server Tools View Logs screen, accessible to administrators. The
guidewire.logDirectory property in logging.properties specifies the location of log files for the ClaimCenter
log viewer.
In the base configuration, Guidewire sets this property to the following value:

guidewire.logDirectory = /tmp/gwlogs/ClaimCenter/logs/

Set the log file locations for the individual log4j.appender.category.File entries to the same directory as that
used for guidewire.logDirectory. This ensures that these log files are visible as well from the View Logs screen.
See also
• See “View Logs” on page 358 for more information about the View Logs screen.

Adding Loggers to the Logging Properties File

File logging.properties provides a number of the examples of how to set up a logger for a specific logging
category. However, it is very likely that you will want to add additional logging categories to this file. To add
additional logging categories to file logging.properties, do one of the following:
• Uncomment an existing example logger
• Add a new logging category
See also
• “Make an Example Logger in the Logging Properties File Active” on page 27
• “Add a New Logging Category to the Logging Properties File” on page 28

Make an Example Logger in the Logging Properties File Active

About this task

Guidewire comments out many of the example loggers in file logging.properties. This action makes the logger
inactive. To an example logger active, uncomment the logger entry by removing the hash mark (#) at the beginning
of the line. For example, in the base configuration, the Messaging logging category is inactive in Guidewire
ClaimCenter.

##### Messaging #####

#

Overview of Application Logging 27

 System Administration Guide 9.0.5

# Defines the log file for messaging.

#
#log4j.category.Messaging=DEBUG, MessagingLog
#log4j.category.Messaging.Events=DEBUG, MessagingLog
log4j.additivity.Messaging=false
log4j.appender.MessagingLog=org.apache.log4j.DailyRollingFileAppender
log4j.appender.MessagingLog.encoding=UTF-8
log4j.appender.MessagingLog.File=/tmp/gwlogs/BillingCenter/logs/messaging.log
log4j.appender.MessagingLog.DatePattern = .yyyy-MM-dd
log4j.appender.MessagingLog.layout=org.apache.log4j.PatternLayout
log4j.appender.MessagingLog.layout.ConversionPattern=%-10.10X{server}
%-8.24X{userID} %d{ISO8601} %p %m%n

To make the Messaging logging category active, remove the hash mark from the following line of code.

log4j.category.Messaging=DEBUG, MessagingLog

Next steps
See also
• “Enabling Logging Categories” on page 31

Add a New Logging Category to the Logging Properties File

About this task

Guidewire supports a number of logging categories for which there are no existing examples in the ClaimCenter
base configuration. To add a new logging category to file logging.properties, do the following:

Procedure
1. Determine whether Guidewire supports the logging category.
2. Copy an existing example logger in the logging properties file and paste it at the end of the file.
3. Modify the copy of an existing logger to create your new logger.

Next steps
See also
• See “Viewing a List of Logging Categories” on page 30 to understand how to determine whether Guidewire
supports the logging category that you want to add.

Logging Level Reference

The logging level determines how much information ClaimCenter records in the log. The following list describes the
different levels of information that ClaimCenter records in the log, in the increasing order of the severity of the
information.

Level Description
TRACE Messages about processes that are about to start or that completed. These types of messages provide flow-of-control
logging. Trace logging has no or minimal impact on system performance. Typical messages might include:
• Calling plugin.
• Returned from plugin call.
DEBUG Messages that test a provable and specific theory intended to reveal some system malfunction. These messages need
not be details but include information that would be understandable by an administrator. For example, dumping the

28 chapter 2 Application Logging

 System Administration Guide 9.0.5

Level Description
contents of an XML tag or short document is acceptable. However, exporting a large XML document with no line
breaks is usually not appropriate. Typical messages might include:
• Length of Array XYZ = 2345.
• Now processing record with public ID ABC:123456.
INFO Messages that convey a sense of correct system operation. Typical messages might include:
• Component XYZ started.
• User X logged on to ClaimCenter.
WARN Messages that indicate a potential problem. Examples include:
• An assignment rules did not end in an assignment.
• Special setting XYZ was not found, so ClaimCenter used the default value.
• A plugin call took over 90 seconds.
ERROR Messages that indicate a definite problem. Typical messages might include:
• A remote system refused a connection to a plugin call.
• ClaimCenter can not complete operation XYZ even with a default.

Understanding Logging Categories

File logging.properties contains examples of the component categories available for logging in Guidewire
ClaimCenter. It is possible for both internal ClaimCenter code or custom integration code to define additional
logging categories that do not show in the logging properties file. It is also possible for third-party components, such
as Apache, to provide their own logging categories. Each Guidewire application has its own unique categories as
well.

Logging Categories for Plugins

In some cases, ClaimCenter does not use a particular plugin interface. In those cases, the logging category exists in
file logging.properties, but, ClaimCenter does not use the category for logging.
See also
• “Logging Category Inheritance” on page 29
• “Viewing a List of Logging Categories” on page 30
• “Enabling Logging Categories” on page 31
• “Logging Category Reference” on page 31

Logging Category Inheritance

The RootLogger category in logging.properties is the parent of all other logging categories. Setting the logging
level on RootLogger causes all categories to inherit the same logging level, provided those categories do not set a
different logging level. Set the logging level property of the different logging entries to set how much information
you want sent to each type of log.
Logging levels inherit from parent categories unless the child category defines a different level. For example, setting
Messaging to DEBUG also sets Messaging.Email and Messaging.Events to DEBUG, unless those categories
individually define another logging level.
In the base configuration, Guidewire sets the value of rootCategory to INFO:

log4j.rootCategory=INFO

Understanding Logging Categories 29

 System Administration Guide 9.0.5

Viewing a List of Logging Categories

You can use any of the following means to view a list of the currently enabled logging categories.

View More information

Set Log Level screen “View Logging Categories from the Set Log Level Screen” on page 30
system_tools command “View Logging Categories Using a System Tools Command” on page 30
SystemToolsAPI web service “View Logging Categories Using Web Services” on page 31

See also
• “Enabling Logging Categories” on page 31
• “Set Log Level” on page 357

View Logging Categories from the Set Log Level Screen

Procedure
1. Log into ClaimCenter as a user with administrative privileges.
2. Navigate to the Server Tools Set Log Level screen.
3. Expand the Logger drop-down.
In the drop-down list, you can view the ClaimCenter standard logging categories, logging categories for
internal Guidewire code, and logging categories for third-party software.

Next steps
See also
• “Set Log Level” on page 357

View Logging Categories Using a System Tools Command

About this task

The system_tools command lists logging categories defined by ClaimCenter only. It does not list third-party
logging categories.

Procedure
1. Ensure that the ClaimCenter server is running.
2. Navigate to the following directory in the ClaimCenter installation directory:

admin/bin

3. Enter the following command:

system_tools -user user -password password -loggercats

To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.

30 chapter 2 Application Logging

 System Administration Guide 9.0.5

View Logging Categories Using Web Services

About this task

The SystemToolsAPI method lists logging categories defined by ClaimCenter only. It does not list third-party
logging categories.

Procedure
1. Ensure that the ClaimCenter server is running.
2. Call the following method on the SystemToolsAPI web service:

SystemToolsAPI.getLoggingCategories

Enabling Logging Categories

The logging.properties file contains additional logging categories for system components such as plugins or
integration code. In the base configuration, Guidewire comments out these entries by default. To enable a logging
category, uncomment the appropriate log4j.category.* entry.
For example, to log the processing of Gosu code by the ClaimCenter rule engine, uncomment the first line in the
following example code.

# log4j.category.RuleEngine=INFO, RuleEngineLog
log4j.additivity.RuleExecution=false
log4j.appender.RuleExecutionLog=org.apache.log4j.DailyRollingFileAppender
log4j.appender.RuleExecutionLog.encoding=UTF-8
log4j.appender.RuleExecutionLog.File=/tmp/gwlogs/ClaimCenter/logs/ruleexecution.log

In this example, notice the following:

• ClaimCenter ignores all logging entries related to a specific category if the log4j.category.* entry for that
category has a hash mark (#) at the beginning of the line. To make a specific logging category active, uncomment
the log4j.category.* entry for that category.
• ClaimCenter writes the log information to a different output point, as defined by the following line in
logging.properties:

log4j.appender.RuleEngineLog.File=/tmp/gwlogs/ClaimCenter/logs/ruleengine.log

Just as with the daily log, the directory location for any specialized log file must exist. The most important settings
to change are the location and name of the log file and the logging threshold for that logging category.

Related information
Apache Logging Services

Logging Category Reference

The following list describes many of the major Guidewire logging categories that are available in ClaimCenter.

Logging category Description

Api.* Base logging category for calls for all SOAP APIs.
Application.* Base logging category for internal Guidewire application logging.
Application.Addressbook Logging for Guidewire platform code that interacts with ContactManager. Guidewire
ContactManager does not use this category.

Viewing a List of Logging Categories 31

 System Administration Guide 9.0.5

Logging category Description

Application.Segmentation Logging for the segmentation engine, used to segment new claims and exposures.
Segmentation is done either by rules or by the segmentation plugin.
Assignment.* Base logging category for the assignment subsystem.
Availability Logging of the determination of availability of an item in ClaimCenter. ClaimCenter bases
the availability criteria for each item on the item type.
For example, suppose that one criterion is the effective date of an item. If the effective
date is not prior to or equal to today’s date, the item is not available.
BizRules Base logging category for business rule activity and events.
Configuration.* Base logging category for configuration problems in such areas as in security configuration,
PCF configuration, locale configuration and so forth.
Datagen Logging of internal Guidewire code used for testing.
Geodata.* Base logging category for the Geodata daemon.
Globalization.* Base logging category for the globalization subsystem.
Import Logging for import of XML data into ClaimCenter.
Integration.* Base logging category for general integration issues.
LDAP Logging of issues related to the LDAP subsystem.
Messaging.* Base logging category for the messaging system. ClaimCenter writes logging information in
this category to a separate messaging.log file.
Messaging.metro Logging of messages to and from Metropolitan Reporting Bureau. See the Application
Guide.
For information about integrating with Metropolitan Reporting Bureau, see the Integration
Guide
For more information about Metropolitan Reporting Bureau services, refer to the following
web site:
http://www.metroreporting.com

OSGi.* Base logging category for calls to OSGi plugins.

PXLOGGER Logging for the internal Guidewire test platform.
PerfAction.* Base logging category for issues related to performance.
PerfAnalyzer Logging of issues related to the performance analyzer.
Plugin.* Base logging category for all calls into any plugin. For child categories of Plugin, use the
plugin name (PluginName), for example:
Plugin.PluginName
ClaimCenter writes logging information in this category to a separate plugins.log file.
Profiler Base logging category for the Guidewire Profiler. See “Guidewire Profiler” on page 400 for
more information on the Guidewire Profiler.
RuleEngine Do not use. Use RuleExecution instead.
RuleExecution.* Base logging category for ClaimCenter rule execution. Only rule execution actions generate
logging events in this category. This category does not contain any information from the
rules engine itself.
ClaimCenter writes logging information in this category to a separate ruleexecution.log
file.
RuleExecutionUI Logging of rule execution activity in the ClaimCenter interface.
Rules Do not use. Use the RuleExecution logging category instead.

32 chapter 2 Application Logging

 System Administration Guide 9.0.5

Logging category Description

Security Internal Guidewire base logging category for security logging.
Server.* Internal Guidewire base logging category for server and platform logging.
Studio Logging of Guidewire Studio activity. This category applies to non-Gosu-related activities in
Guidewire Studio only. However, if you execute Gosu code within the Studio Gosu
Scratchpad, Studio executes the Gosu code on the server. Thus, it is possible to trigger Rule
Engine logging on the server as well.
ClaimCenter writes logging information in this category to a separate studio.log file.
Test.* Internal Guidewire base logging category for the test subsystem.
User Logging of each user’s log in and log out of ClaimCenter.
UserInterface.* Internal Guidewire base logging category for user interface logging.
Workqueue.* Base logging category for work queue functionality. For more information on work queues,
see “Administering Batch Processing” on page 85.

See also
• “Understanding Logging Categories” on page 29

Logger Category API

Guidewire uses the following API to trigger logging action by category:

gw.api.system.CCLoggerCategory

For example, to use this API in Gosu code to perform assignment logging, do something similar to the following:

uses gw.api.system.CCLoggerCategory
...
var logger = CCLoggerCategory.ASSIGNMENT
...
logger.debug("Print out this message.")

Notice the following:

• The code defines the logger category, in this case, Assignment.
• The code defines the logging level, in this case, debug.
• The code defines the statement to print in the log file or to the console, as configured.
The category that you define in this code must exist as one of the base configuration logging categories.

Base Configuration Logging Categories

A logging category defines how the Apache log4j logging utility handles different types of logging requests. In the
base configuration, Guidewire provides a number of readily usable logging categories,

Logger Category API 33

 System Administration Guide 9.0.5

There are several ways to view the base configuration logging categories:
• From the Set Log Level Server Tools screen.
• By running the system_tools command from a command prompt and adding the -loggercats option.

Logging Levels
You can use the logger category API to generate logging messages for any valid ClaimCenter logging level. The
following are all valid log levels:
• Trace
• Info
• Debug
• Warn
• Error
The following code is an example of the use of a debug logging statement in a Gosu rule.

logger.debug( DisplayKey.get("Rules.Assignment.DefaultGroup.Activity", actions.ShortRuleName) )

The log level that you set here overrides the default logging level set for this category in logging.properties.

Formatting a Log Message

Each logger category in file logging.properties associates a log4j layout with the logging category appender.
The log4j layout definition controls the formatting of the logging message. The appender controls the output point
or destination.
The following example illustrates the layout definition for the application console log.

log4j.appender.Console.layout=org.apache.log4j.PatternLayout
log4j.appender.Console.layout.ConversionPattern=%-10.10X{server} %-8.24X{userID} %d{ISO8601} %p %m%n

Notice that:
• Apache utility class PatternLayout, a standard part of the Apache log4j distribution, provides the means of
handling string patterns.
• Conversion patterns use control characters, similar to the C language printf function, to specify the output
format for the message.
You can modify the log4j.appender.log.layout.ConversionPattern value to change the information included
in log messages for a log type. For example, to list the logging category for console logs, add %c to the
log4j.appender.Console.layout.ConversionPattern value. You can then filter logs by category.
See also
• “Conversion Character Reference” on page 34
• “Format Modifier Reference” on page 36

Conversion Character Reference

Use the conversion characters listed in the following table to specify the formatting of logging category conversion
patterns in file logging.properties.

Character Description
%% Writes the percent sign to output.

34 chapter 2 Application Logging

 System Administration Guide 9.0.5

Character Description
%c Name of the logging category. See “Understanding Logging Categories” on page 29 for categories provided with
ClaimCenter.
%C Name of the Java class. Because the ClaimCenter logging API is a wrapper around log4j, %C returns the class
name of the logger. If you want class names in your log messages, include them specifically in the message
rather than by using %C in the conversion pattern.
%d Date and time. Acceptable formats include:
• %d{ISO8601}
• %d{DATE}
• %d{ABSOLUTE}
• %d{HH:mm:ss,SSS}
• %d{dd MMM yyyy HH:mm:ss,SSS}
• ...
ClaimCenter uses %d{ISO8601} by default.
%F Name of the Java source file. Because the ClaimCenter logging API is a wrapper around log4j, %F returns a file
name for the ClaimCenter logging API. If you want file names in your log messages, include them specifically in
the message rather than by using %F in the conversion pattern.
%l Abbreviated format for %F%L%C%M. This outputs the Java source file name, line number, class name and method
name. Because the ClaimCenter logging API is a wrapper around log4j, the information returned is for the
ClaimCenter logging API. If you want information such as class and method names in your log messages, include
them specifically in the message rather than by using %l in the conversion pattern.
%L Line number in Java source. Because the ClaimCenter logging API is a wrapper around log4j, %L returns a line
number from the ClaimCenter logging API. If you want line numbers in your log messages, include them
specifically in the message rather than by using %L in the conversion pattern.
%m The log message.
%M Name of the Java method. Because the ClaimCenter logging API is a wrapper around log4j, %M returns info stri
ng. If you want method names in your log messages, include them specifically in the message rather than by
using %M in the conversion pattern.
%n New line character of the operating system. This is preferable to entering \n or \r\n as it works across platforms.
%p Priority of the message. Typically, either FATAL, ERROR, WARN, INFO or DEBUG. You can also create custom priorities
in your own code.
%r Number of milliseconds since the program started running.
%t Name of the current thread.
%throwable Include a throwable logged with the message. Available format is:
• %throwable – Display the whole stack trace.
• %throwable{n} – Limit display of stack trace to n lines.
• %throwable{none} – Equivalent of %throwable{0}. No stack trace.
• %throwable{short} – Equivalent of %throwable{1}. Only first line of stack trace.

%X The nested diagnostic context. You can use this to include server and user information in logging messages.
Specify a key in the following format to retrieve that information from the nested diagnostic context: %X{key}.
The following keys are available:
• server
• user
• userID
• userName
For example, to include the server name, add %X{server}. For example, to include the server name, add %X{ser
ver}.
There are three options for logging user information in logging patterns:

Formatting a Log Message 35

 System Administration Guide 9.0.5

Character Description
user – prints the numeric opaque ID for the user
userID – a unique user ID string, such as "aapplegate"
userName – a real name, such as "Andy Applegate"
For any of these, specify the minimum and the maximum size of the field. For example: %-16.16X{userName}.
If the actual value is shorter than the minimum field size, the user identifier gets padded with spaces on the
right. If the actual value is longer than the maximum size of the field, the user identifier gets truncated from the
left.
The user key lists a sequence number assigned to the user by the server and is not very informative. To include
user login ID information, instead use the userID key.

Related information
Log4j Pattern Layout

Format Modifier Reference

File logging.properties defines how Guidewire ClaimCenter handles application logging. In the logging
properties file, you can specify the format of information in log messages by using a conversion pattern for the
characters. See “Conversion Character Reference” on page 34 for information on the types of conversion characters
that you can use.
In using the conversion characters to define an output format, you can also add a format specification between the
percent sign and the letter in the conversion pattern. The following table describes conversion patterns available with
Apache log4j libraries.

Pattern Description
%N Specifies a minimum width of N for the output. N is an integer. If the output is less than the minimum width, the
logger pads the output with spaces. Text is right-justified.
For example, to specify a minimum width of 30 characters for the logging category, add %30c to the conversion
pattern.
%-N Left-justifies the output within the minimum width of N characters. N is an integer.
For example, to have the logging category left justified within a minimum width of 30 characters, add %-30c to the
conversion pattern.
The default output is right-justified.
%.N Specifies a maximum width of N for the output. N is an integer.
For example, to have the logging category output have a maximum width of 30 characters, add %.30c to the
conversion pattern. The logger truncates output from the beginning if it exceeds the maximum width.
%M.N Pads with spaces to the left if output is shorter than M characters. If output is longer than N characters, then the
logger truncates from the beginning.
%-M.N Pads with spaces to the right if output is shorter than M characters. If output is longer than N characters, then the
logger truncates from the beginning.

Configure Logging in a Multiple Instance Environment

About this task
Within file logging.properties, it is possible to use variables to specify log file names and locations. This is
particularly useful if there are multiple ClaimCenter instances on the same physical server. This enables you to use a
common logging properties file and generate log files for each separate ClaimCenter instance.

36 chapter 2 Application Logging

 System Administration Guide 9.0.5

Procedure
1. In file config.xml, add an entry to the <registry> element for each cluster server that you want to log.
For example:

<registry roles="…" >

<server env="test" serverid="testserver1" roles="…" />
<server env="test" serverid="testserver2" roles="…" />
</registry>

2. In file logging.properties, do the following:

a. Set the logging directory.
For example:

guidewire.logDirectory = /tmp/gwlogs/ClaimCenter/logs/

Set this variable to an absolute path to a directory that already exists. You must use forward slashes as the
path separator.
b. Set a value for log4j.appender.DailyFileLog.File that uses the guidewire.logDirectory and that
uses a -D JVM property to set the server ID.
For example, enter something similar to the following:

log4j.appender.DailyFileLog.File=${guidewire.logDirectory}/${gw.serverid.noroles}-cclog.log

The use of the serverid.noroles property suppresses the names of the roles associated with each server.
Otherwise, ClaimCenter lists the server roles associated after the server ID in the log name.
3. Start each server using the system properties that set the environment and server ID values.
For example, if using development Jetty test servers, use the following commands:

gwb runServer -Denv=test -Dserverid=testserver1

gwb runServer -Denv=test -Dserverid=testserver2

As each server starts, the server writes a log file to the common log file directory specified by the value of
guidewire.logDirectory. Each log file includes the value of serverid in the log file name.
In this example, after starting the servers, the /tmp/gwlogs/ClaimCenter/logs directory contains two log
files:
• testserver1-cclog.log
• testserver2-cclog.log

Next steps
If you edit file config.xml, you must rebuild and redeploy ClaimCenter for the changes to take effect. If you update
the logging configuration file, you must also reload this file before your changes take effect.
See also
• “Reloading the Logging Configuration” on page 38
• “Understanding the Configuration Registry Element” on page 46
• “JVM Options and Server Properties” on page 51
• Installation Guide

Configure Logging in a Multiple Instance Environment 37

 System Administration Guide 9.0.5

Dynamic Changes to Logging Configuration

It is possible, under certain circumstances, to make dynamic changes to the ClaimCenter logging configuration
without having to redeploy ClaimCenter. Changing the database logging level dynamically does not make any
change to existing database connections. The new logging level only take effects for new database connections.
For example, if the database log level is set to debug, ClaimCenter logs all SQL statements. However, if you set the
debug logging level dynamically, ClaimCenter only logs SQL statements for new connections created within the
connection pool. For an existing connection, dynamically changing the logging level to debug has no affect.
Logging levels that you change dynamically remain in effect only while the server is running. If you restart the
server, ClaimCenter resets the logging behavior to what file logging.properties specifies.
Note: To set the logging level consistently for all database connections, you must set the log level in
logging.properties and restart the server.
See also
• “Setting the Logging Configuration Dynamically” on page 38
• “Reloading the Logging Configuration” on page 38
• “Changing a Logging Level Temporarily” on page 39

Setting the Logging Configuration Dynamically

To reset the logging configuration dynamically, do one of the following:
• Update file logging.properties and reload the file.
• Reset the logging level for a given logging category temporarily.
You must use one of these methods to propagate logging configuration changes dynamically. Otherwise, you must
rebuild your ClaimCenter WAR or EAR and deploy it to the application server for the configuration changes to take
effect.
See also
• “Reloading the Logging Configuration” on page 38
• “Changing a Logging Level Temporarily” on page 39
• Installation Guide

Reloading the Logging Configuration

It is possible to make an immediate change in the configuration of ClaimCenter logging without having to first
redeploy the ClaimCenter application server. You can do this in several different ways:
• Use a system_tools command option
• Use a SystemToolsAPI web service method
Either approach reloads the current logging configuration from the logging.properties file.
See also
• “Reload the Logging Configuration Using a System Tools Command” on page 38
• “Reload the Logging Configuration Using Web Services” on page 39

Reload the Logging Configuration Using a System Tools Command

Procedure
1. In the Studio Project window, update file logging.properties with your logging configuration changes.
2. Ensure that the ClaimCenter application server is running.
3. Open a command prompt in the following location in the ClaimCenter installation directory:

38 chapter 2 Application Logging

 System Administration Guide 9.0.5

admin/bin

4. Enter the following at the command prompt:

system_tools -user user -password password -reloadloggingconfig

To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.

Next steps
See also
• “System Tools Command” on page 422

Reload the Logging Configuration Using Web Services

Procedure
1. In the ClaimCenter Studio Project window, update file logging.properties with your logging configuration
changes.
2. Ensure that the ClaimCenter application server is running.
3. Call the following method on the SystemToolsAPI web service:

SystemToolsAPI.reloadLoggingConfig

Next steps
See also
• Integration Guide

Changing a Logging Level Temporarily

You can temporarily change the logging level for a logger by using one of the following options:
• By using the system_tools command prompt utility
• By using the SystemToolsAPI web service
• By setting the log level on the Server Tools Set Log Level info screen
See also
• “Set the Log Level Using a System Tools Command” on page 39
• “Set the Log Level Using a Web Service” on page 40
• “Set the Log Level from ClaimCenter” on page 40

Set the Log Level Using a System Tools Command

Procedure
1. Ensure that the ClaimCenter application server is running.
2. Open a command prompt in the following location:

admin/bin

3. Enter the following at the command prompt:

Reloading the Logging Configuration 39

 System Administration Guide 9.0.5

system_tools -updatelogginglevel logger level

To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.

Result
The change in the logging level persists while the ClaimCenter application server is running only.

Next steps
See also
• “System Tools Command” on page 422

Set the Log Level Using a Web Service

Procedure
1. Ensure that the ClaimCenter application server is running.
2. Call the following method on the SystemToolsAPI web service:

SystemToolsAPI.updatelogginglevel(logger,level)

Result
The change in the logging level persists while the ClaimCenter application server is running only.

Next steps
See also
• Integration Guide

Set the Log Level from ClaimCenter

It is possible to set the log level temporarily from the ClaimCenter Set Log Level screen.

Procedure
1. Log into Guidewire ClaimCenter using an administrative account.
2. Navigate to the Server Tools Set Log Level screen.
3. Select a logging level from the drop-down list.
4. Enter the new logging level for that category.

Result
The change in the logging level persists only while the ClaimCenter server is running.

Next steps
See also
• “Set Log Level” on page 357

Configuring Archive Logging Operations

40 chapter 2 Application Logging

 System Administration Guide 9.0.5

To configure archive logging in Guidewire ClaimCenter, do the following:

• Set configuration parameter ArchiveEnabled in file config.xml to true.
• Uncomment the archiving-related logging code in file logging.properties by removing the hash mark (#) at
the beginning of the code line.

Print Details of the Archive Graph

About this task
As the ClaimCenter server starts, the server builds the archive domain graph. To print out the details of how
ClaimCenter determines the graph, perform the following steps.

Procedure
1. In the ClaimCenter Studio Project window, open file logging.properties for editing.
2. Add code similar to the following example to the file.

log4j.category.Server.Archiving.Graph=DEBUG,Console

Generate a Separate Archive Log

About this task
Guidewire recommends as a general practice that you create a separate log file for archive information.

Procedure
1. In the ClaimCenter Studio Project window, open file logging.properties for editing.
2. Add code similar to the following example to the file.

log4j.category.Server.Archiving=INFO, ArchiveLog
log4j.appender.ArchiveLog.File=/tmp/gwlogs/ClaimCenter/logs/archivelog.log

ClaimCenter Logging Example

To configure an archive log, add code similar to the following example in file logging.properties.

##### Archived Claims #####

# Set up the logging for Archived Claims.

# Archiving loggers

# Root archiving logger

log4j.category.Server.Archiving=INFO, ArchivedClaimsLog

# Logger for successful archived claims

log4j.category.Server.Archiving.Success=INFO, ArchivedClaimsLog

# Logger for debugging the Claim graphs of claims being archived

log4j.category.Server.Archiving.Graph=DEBUG, ArchivedClaimsLog

# Logger for the the archiving upgrade process

log4j.category.Server.Archiving.DocumentUpgrade=INFO, ArchivedClaimsLog

log4j.appender.ArchivedClaimsLog=org.apache.log4j.DailyRollingFileAppender
log4j.appender.ArchivedClaimsLog.encoding=UTF-8
log4j.appender.ArchivedClaimsLog.File=/tmp/gwlogs/ClaimCenter/logs/archivedClaims.log
log4j.appender.ArchivedClaimsLog.DatePattern = .yyyy-MM-dd
log4j.appender.ArchivedClaimsLog.layout=org.apache.log4j.PatternLayout
log4j.appender.ArchivedClaimsLog.layout.ConversionPattern=%-10.10X{server}
%-8.24X{userID} %d{ISO8601} %p %m%n

Configuring Archive Logging Operations 41

 System Administration Guide 9.0.5

Batch Processes that Generate Archive Data

In Guidewire ClaimCenter, the following batch process generates archive-related data:
• Archive Batch Processing

42 chapter 2 Application Logging

part 2

Server Administration
System Administration Guide 9.0.5
chapter 3

ClaimCenter Server Configuration

This topic discusses ways to set up your ClaimCenter server environment.

Important ClaimCenter Server Configuration Files

ClaimCenter uses the following files to manage application and database functionality.

File Description
config.xml File config.xml contains global system parameters that you use to control the behavior of Guidewire
ClaimCenter. These configuration parameters govern large-scale system options, such as
authentication, server clustering, and the business calendar. You access file config.xml in Guidewire
Studio under configuration→config.
database-config.xml File database-config.xml stores database connection information and Data Definition Language
(DDL) options. You access file database-config.xml in Guidewire Studio under configuration→config.

See also
For more information on file config.xml and basic application configuration, see the following:
• “Configuration” on page 359
• Configuration Guide
For more information on file database-config.xml and basic database configuration options, see the following:
• “Database Configuration” on page 219
• “Database Maintenance” on page 259
• Installation Guide

ClaimCenter Server Configuration 45

 System Administration Guide 9.0.5

Understanding the ClaimCenter Server Environment

During startup, ClaimCenter calculates key environment properties. These property values describe the environment
in which the server runs. After you set environment properties, you can access these properties through the
following methods:
• ClaimCenter commands
• Gosu code
• Java code
It is possible to specify environment property values either through JVM (Java Virtual Machine) options or through
the <registry> element:
• You define environment properties in the <registry> element in file config.xml.
• You set JVM options through command line options as you to start a ClaimCenter server.
Depending on how many ClaimCenter servers your environment requires, you might find it necessary to adjust the
environment properties significantly. You can use environment properties together with configuration file
config.xml to specify and control one or multiple ClaimCenter server environments.
See also
• “Important ClaimCenter Server Configuration Files” on page 45
• “Understanding the Configuration Registry Element” on page 46
• “JVM Options and Server Properties” on page 51
• “Configuration Parameters by Environment” on page 53
• Installation Guide

Understanding the Configuration Registry Element

It is possible to set the ClaimCenter server environment using the <registry> element in config.xml. Through the
<registry> element, you can define the following:
• The set of server roles that are valid for this cluster.
• The set of server roles that are valid for each individual server instance in the cluster.
• The environment in which a specific server operates, for example, a development environment or a production
environment.
Also through the <registry> element, you can redefine certain system properties that you specify at server startup.
See also
• “The Configuration Registry Element” on page 46
• “Example Syntax for Registry Server Element” on page 48
• “Assigning Server Roles to ClaimCenter Cluster Servers” on page 50
• “Defining a New Server Role” on page 50

The Configuration Registry Element

The <registry> element in file config.xml has the following syntax.

<registry roles="role1, role2, …" >

<server env="environment" roles="role1, role2, …" serverid="serverID" />
<systemproperty name="name" value="value" default="default" />
</registry>

46 chapter 3 ClaimCenter Server Configuration

 System Administration Guide 9.0.5

File config.xml contains exactly one required <registry> element. The <registry> element can contain zero to
many <server> and <systemproperty> elements.
The attributes on the various elements have the following meanings.

Element Attribute Required Description

registry roles Yes List of valid cluster roles. See “Server Roles” on page 141 for a description of the
default server roles that Guidewire provides in the base configuration.
server env No The name of the environment in which the server operates. The default is null. The
value of env is immutable while the server is running.
serverid No Unique server name of a server instance in the cluster. If you do not specify this value
explicitly, ClaimCenter sets it to the hostname of the ClaimCenter server. Log entries
display only the first 10 characters of the serverid value.
roles No Specific role or roles assigned to the server specified by serverid.
systemproperty name Yes Specifies the name of the Java -D system property that you want to redefine. This
value can be one of the following:
• env
• serverid
If you run multiple server instances on the same host machine, define a serverid
value for each server instance with a separate systemproperty entry.
value Yes New name of the system property.
default Yes Default property value to use if you do not specify a value at the command prompt.

The following code shows an example <registry> element.

<registry roles="batch, scheduler, workqueue, messaging, startable, ui, custom1">

<server env="prod" serverid="p0001" roles="batch, scheduler, workqueue, messaging" />
<server env="prod" serverid="p0002" roles="batch, workqueue, messaging, startable" />
<server env="prod" serverid="p0003" roles="ui, custom1" />
<server env="test" serverid="t0001" roles="batch, scheduler, workqueue, messaging, startable,
ui, custom1" />
<systemproperty name="env" value="my.env" default="production"/>
<systemproperty name="serverid" value="my.id" default="myDefault"/>
</registry>

Notice that:
• The set of valid server roles includes a custom role (custom1).
• The <server> elements define three separate server instances in the production environment, each of which has
specific server roles.
• There is a single server instance in the test environment that has all server roles.
• There are two system property redefinitions, one for env and one for serverid.

Property serverid.noroles
In standard usage, the value of property serverid includes also the list of server roles defined for that server. If you
want to use this property in code, without the list of server roles, use serverid.noroles instead. For example,
instead of using gw.cc.serverid, use gw.cc.serverid.noroles to suppress the list of server roles associated with
this server ID.

Environment and Logging

The env property has special significance for logging behavior. If the env value is non-null, ClaimCenter tries to
obtain the logging configuration from a config/logging/env-logging.properties file. If this file does not exist
or if env is null, then the logging configuration is taken from the default logging.properties file.

Understanding the Configuration Registry Element 47

 System Administration Guide 9.0.5

Creating Special Server Roles

It is possible to define new server roles by adding the role to the list of roles specified by the roles attribute on the
<registry> element. For an example of how to define and use a specialized server role, see “Work Queues and
Server Roles” on page 99.

Accessing System Properties in Code

Gosu class gw.api.system.server.ServerUtil contains methods for working with system properties associated
with servers. See the Integration Guide for information on how to use this library.
See also
• “Server Roles” on page 141

Example Syntax for Registry Server Element

The following example illustrates how to use the <server> subelement of the <registry> element in config.xml
to set various server properties.

<registry roles="…">
<server env="production" serverid="prodserver" roles="batch, messaging, workqueue" />
</registry>

Notice that the defined <server> element:

• Associates the prodserver server with a production environment.
• Assigns the prodserver server the batch, messaging, and workqueue server roles.
ClaimCenter shows the serverid and role values for each server in a ClaimCenter cluster on the Server Tools
Cluster Members and Components screens.
It is also possible to set server system properties using a -D JVM option at server start up from a command prompt.
For example, you can use JVM options to set the environment variable (env) and the server ID (serverid) at
runtime using the following syntax. The option syntax varies by server type.

QuickStart (Jetty) -Denv=…

-Dserverid=…

Tomcat -Dgw.cc.env=…
-Dgw.cc.serverid=…

If you are starting the Jetty development server from within ClaimCenter Studio, use the syntax for Tomcat in the
Run - Server configuration dialog, for example:

-Dgw.cc.serverid=testServer

For more information, see “Start the Application Server from ClaimCenter Studio” on page 56.

How ClaimCenter uses a -D JVM option

The values of env and serverid are immutable while the server is running.

48 chapter 3 ClaimCenter Server Configuration

 System Administration Guide 9.0.5

ClaimCenter determines the value of a -D option in the following manner, using -Dserverid (on Jetty) as an
example:
• If you specify a -Dserverid=prodserver JVM option at the command prompt at server startup, ClaimCenter
sets the value of serverid for that server to prodserver.
• If you do not specify a -Dserverid JVM option at server start, ClaimCenter checks the server registry for a
serverid value defined by a server entry. If found, ClaimCenter uses that value. In the example, the serverid
value is prodserver.
• If you do not specify the JVM option, and no serverid value defined by a server entry exists, ClaimCenter sets
serverid to the host name of the computer. Under some extreme security settings, this value is not available, in
which case ClaimCenter sets the serverid to localhost.
Note: Log entries display only the first 10 characters of the serverid value.
See also
• “Understanding the Configuration Registry Element” on page 46
• “JVM Options and Server Properties” on page 51
• “Cluster Members and Components” on page 386

Example Syntax for the Registry System Property Element

The following example illustrates how to set the server environment using the <systemproperty> element of the
<registry> element in config.xml.

<registry roles="…" >

<systemproperty name="env" value="my.env" default="production"/>
</registry>

Notice that the defined <systemproperty> element:

• Redefines the name of the env property to be my.env. Thus, in places in which you formerly used env, you now
use my.env. For example, -Denv becomes -Dmy.env.
• Sets a default value (production) for the system property.
To use this system property, you specify its value as a -D JVM option at server startup. The option syntax varies by
server type.

QuickStart (Jetty) -Dmy.env=…

Tomcat -Dgw.cc.my.env=…

The value of my.env is immutable while the server is running.

ClaimCenter determines the value of the redefined env system property in the following manner, using -Dmy.env
(on Jetty) as an example:
• If you specify the -Dmy.env=test JVM option at the command prompt at server startup, ClaimCenter sets the
value of env to test.
• If you do not specify a -Dmy.env option at server start, ClaimCenter sets env to the value of default that you
specified in the systemproperty, in this example, production.
• If you do not set the value of my.env either through a default registry property or with a JVM option,
ClaimCenter sets the value of the env property to null.
ClaimCenter ignores any attempt to set the environment property through the command prompt if you have
previously defined that property using a <systemproperty> element. For example, suppose that you set the
following <registry> element in config.xml:

<systemproperty name="env" value="my.env" default="standalone" />

Understanding the Configuration Registry Element 49

 System Administration Guide 9.0.5

Then, at server startup, you specify a -Denv="test" JVM option. ClaimCenter ignores any -Denv option that you
specify on the command prompt and sets the env value to standalone.
See also
• “Understanding the Configuration Registry Element” on page 46
• “JVM Options and Server Properties” on page 51

Assigning Server Roles to ClaimCenter Cluster Servers

You assign specific server roles to individual servers using the roles attribute on the <server> element (on
<registry>) in config.xml. For example, suppose that the ClaimCenter cluster contains the following servers.

Server name Assigned roles

prodserver1 ui

prodserver2 ui

prodserver3 batch, workqueue, scheduler, messaging, startable

prodserver4 batch, workqueue, scheduler, messaging, startable

testserver1 batch, workqueue, scheduler, messaging, startable, ui

The <registry> element in config.xml defines these servers and server roles as follows:

<registry roles="batch, workqueue, scheduler, messaging, startable, ui" >

<server env="prod" roles="ui" serverid="prod1" />
<server env="prod" roles="ui" serverid="prod2" />
<server env="prod" roles="batch, workqueue, scheduler, startable" serverid="prod3" />
<server env="prod" roles="batch, workqueue, scheduler, startable" serverid="prod4" />
<server env="test" roles="batch, workqueue, scheduler, messaging, startable, ui" serverid="test1" />
</registry>

Notice the following:

• The roles attributes on <registry> defines the valid server roles for the ClaimCenter cluster servers.
• The env attribute on <server> defines a server environment for each individual server.
• The roles attribute on <server> defines the server roles assigned to each individual server.
• The serverid attribute on <server> associates a specific server with one or more specific server roles.

Server Mode and Server Roles

ClaimCenter servers in development mode default to having all existing, defined server roles. ClaimCenter servers
in test or production mode default to having no assigned server roles. Thus, you must manually add any desired role
to a test or production ClaimCenter server using one of the following methods:
• Use the <registry> element to assign roles to a production server.
• Use the -Dserverid JVM option at server startup to assign a specific role to the server.
See “JVM Options Specific to the runServer Build Command” on page 52 for information about the -Dserverid
JVM option.

Defining a New Server Role

You define server roles using the roles attribute on the <registry> element in file config.xml. In the base
configuration, Guidewire defines the following server roles:

<registry roles="batch, workqueue, scheduler, messaging, startable, ui" />

50 chapter 3 ClaimCenter Server Configuration

 System Administration Guide 9.0.5

To add a specialized server role, say, one to use in managing activities, you need merely to add the new server role
to the list of roles:

<registry roles="batch, workqueue, activity, scheduler, messaging, startable, ui" />

See also
• “Defining a New Work Queue Role” on page 100

JVM Options and Server Properties

It is possible to set certain ClaimCenter server properties using -D JVM options on the ClaimCenter gwb build
commands. Some of these JVM options work with all of the gwb build commands. Other of the JVM options work
only with the gwb runServer build command. In all cases, the exact manner in which you define and use the JVM
option depends on the type of server involved.
Once set, a server property is immutable while the server is running.
See also
• “The Configuration Registry Element” on page 46
• “Example Syntax for Registry Server Element” on page 48
• “Example Syntax for the Registry System Property Element” on page 49

JVM Options for gwb Build Commands

The following JVM options work with many of the ClaimCenter gwb build commands.

JVM option syntax Description

-Denv=aaaa Starts the ClaimCenter server using the specified environment variable (env).
-Dgw.passthrough.systemProperty=d Starts the ClaimCenter server using the provided system property value. The option
ddd parameters have the following meanings:
• systemProperty – The name of a system property defined in the <registry>
element in file config.xml.
• dddd – The value of the system property.

It is possible to use the -Denv and the -Dgw.passthrough JVM options with some, but not all, of the gwb build
commands. The following table indicates whether the listed JVM command options work with the core gwb
commands (tasks).

Core task Can use JVM option Cannot use JVM option
clean •
cleanIdea •
codegen •
compile •
dropDb •
genDataDictionary •
idea •
runServer •
JVM Options and Server Properties 51
 System Administration Guide 9.0.5

Core task Can use JVM option Cannot use JVM option
stopServer •
studio •

Examples
For example, to pass -DmySystemProperty=someValue to build command dropDB, use the following command
option.

gwb dropDb -Dgw.passthrough.mySystemProperty=someValue

Then, to make the dropDB command specific to a test environment, use the following command (for a Jetty server).

gwb dropDb -Denv=test -Dgw.passthrough.mySystemProperty=someValue

See also
• “Setting JVM Options in ClaimCenter” on page 52

JVM Options Specific to the runServer Build Command

The following JVM options work with the ClaimCenter gwb runServer command only.

JVM option syntax Description

-Dgw.port=nnnn Starts the ClaimCenter server on the specified port (nnnn). The server URL reflects this port
number, for example:
localhost:nnnn/cc/ClaimCenter.do

-Dgw.server.mode=xxxx Starts the ClaimCenter server in the specified server mode. Valid values are:
• dev
• prod
The default is dev.
-Dserverid=aaaa Sets the server ID, and possibly, one or more server roles for the ClaimCenter server:
-Dserverid=aaaa#bbbb • Server ID – Without the hash mark (#), aaaa represents a server ID only.
• Server role – With the hash mark, #bbbb assigns the bbbb server role to the server with aaaa
server ID. Use a comma-separated list, with no spaces, to list multiple server roles.

The exact JVM syntax to use depends on the server type, for example:
• Quickstart (Jetty) – Use -Dserverid=aaaa
• Tomcat – Use -Dgw.cc.serverid=aaaa
See also
• “Assigning Server Roles to ClaimCenter Cluster Servers” on page 50
• “Setting JVM Options in ClaimCenter” on page 52

Setting JVM Options in ClaimCenter

It is possible to set server system properties using the -D JVM option syntax. How you set a command option
depends on the server type:

JBoss Pass the options as arguments to the JBoss run script.

52 chapter 3 ClaimCenter Server Configuration

 System Administration Guide 9.0.5

QuickStart Set the options at server start using the following syntax:
(Jetty) gwb runServer -Denv=…
gwb runServer -Dserverid=…

Tomcat Set the options using the CATALINA_OPTS environment variable. Use the following syntax:
-Dgw.cc.env=…
-Dgw.cc.serverid=…

WebLogic Edit the startManagedWebLogic file.

WebSphere Open the Administrative Console and add the option to Generic JVM arguments. If you have multiple servers, set
the option for each server.

See also
• “JVM Options for gwb Build Commands” on page 51
• “JVM Options Specific to the runServer Build Command” on page 52

Configuration Parameters by Environment

Typically, you need to support more than one server environment. Guidewire recommends you maintain at least
development, test, and deployment environments. So that you do not have to change configuration parameters each
time you switch between environments, ClaimCenter provides the ability to set a configuration parameters for a
specific environment.
Environment-specific parameters can reference environment properties to indicate in which environment they are
valid. You specify the environment for a parameter in config.xml by adding one or both of an env or server
attribute. For example:

<param name="BusinessDayStart" value="9:00 AM" server="dev1" />

<param name="BusinessDayStart" value="7:00 AM" env"=test" />
<param name="BusinessDayStart" value="8:00 AM"/>

Then, you can have ClaimCenter use the environment-specific parameter by specifying the environment in JVM
options at server startup. Continuing the example, to have BusinessDayStart resolve to 7:00 a.m., specify the test
environment in your JVM options:

gwb runServer -Denv=test

However, if ClaimCenter resolves serverid to dev1, ClaimCenter sets BusinessDayStart to the 9:00 a.m. value.
If you define environment-specific parameters, ClaimCenter applies the setting if either the env or server resolves
to a known value. For example, suppose that you specify the BusinessDayStart parameter as follows:

<param name="BusinessDayStart" value="9:00 AM" env="test" server="prodserver" />

<param name="BusinessDayStart" value="8:00 AM" />

ClaimCenter sets BusinessDayStart to 9:00 a.m. if either env resolves to test or serverid resolves to
prodserver. Thus:
• If ClaimCenter resolves env to test and serverid to chicago, the BusinessDayStart is 9:00 a.m.
• Similarly, if ClaimCenter resolves env to production and serverid to prodserver, the BusinessDayStart is
also 9:00 a.m.
• If env does not resolve to test and server does not resolve to prodserver, ClaimCenter uses the default
BusinessDayStart of 8:00 a.m.
For a list of configuration parameters, including information about which parameters can be set by environment, see
the Configuration Guide.
Configuration Parameters by Environment 53
 System Administration Guide 9.0.5

See also
• “Understanding the Configuration Registry Element” on page 46
• “JVM Options and Server Properties” on page 51

Default Configuration Values and Environment Properties

At startup, ClaimCenter requires many parameters. Consider this carefully if you specify parameters by
environment. In some cases, you might want to specify a configuration parameter without any env or server
attribute to assure the parameter always resolves to some value. In the following example, the last line always
resolves to a known value if the other two parameter lines do not resolve:

<param name="ClusteringEnabled" value="false" server="chicago" />

<param name="ClusteringEnabled" value="true" env="test" />
<param name="ClusteringEnabled" value="true"/>

The last line setting in this example acts as the default value for the parameter. Of course, you might want the server
to start only if a certain environment is available. In this case, a default is inappropriate.
See also
• “Understanding the Configuration Registry Element” on page 46
• “Configuration Parameters by Environment” on page 53
• “JVM Options and Server Properties” on page 51

54 chapter 3 ClaimCenter Server Configuration

chapter 4

ClaimCenter Server Administration

This topic discusses the ClaimCenter server, run levels, modes, monitoring servers, and server caching.

Starting Guidewire ClaimCenter

How you start ClaimCenter depends on the application server type.

Application Server More information...

QuickStart (Jetty) from a command prompt “Start ClaimCenter on QuickStart (Jetty)” on page 55
QuickStart (Jetty) from ClaimCenter Studio “Start the Application Server from ClaimCenter Studio” on page 56
JBoss Installation Guide
Tomcat Installation Guide
WebLogic Installation Guide
WebShpere Installation Guide

Start ClaimCenter on QuickStart (Jetty)

About this task
Guidewire recommends the following sequence in starting ClaimCenter on the QuickStart server.

Procedure
1. Open a command prompt and navigate to the root of ClaimCenter application directory.
2. Run the following command to compile the needed application resources and move them to the correct
location in the application server:

gwb compile

3. Run the following command to start the application server.

ClaimCenter Server Administration 55
 System Administration Guide 9.0.5

gwb runServer -x compile

There is a dependency between the runServer command and the compile command. Guidewire recommends
that you always use the -x compile option with the runServer command to remove that dependency after
you initially run the compile command. Otherwise, ClaimCenter must first verify what resources, if any, need
to be recompiled, then perform an incremental recompile of those resources before starting the server.

Next steps
See also
• “JVM Options Specific to the runServer Build Command” on page 52
• Installation Guide

Start the Application Server from ClaimCenter Studio

It is possible to start the ClaimCenter development server (Jetty) from within ClaimCenter Studio.

Procedure
1. Navigate to the following location in ClaimCenter Studio, using the menu bar at the top of the screen:
Run→Run...
Studio opens a Run drop-down with a list of server-related options.
2. Select Edit Configurations.. from the list.
Studio opens the Run - Server dialog.
3. Select Server in the left-hand navigation pane and verify the configuration options set for the server.
It is possible to modify the base configuration server settings by adding additional VM options. If you do so,
use the following format (using server ID an example):

-Dgw.cc.serverid=testServer

4. Click Run.
Studio opens a pane at the bottom of the screen to display the server log. This area also has controls (icons) for
stopping and starting the server.

Stopping GuidewireClaimCenter
Before you stop Guidewire ClaimCenter, you must stop all work queues. Distributed workers run on daemon
threads. As the JVM (Java Virtual Machine) exits, it destroys these threads. This can cause issues if the JVM
destroys a thread while that thread is processing a work item. For example, suppose that a work queue calls a plugin
that makes a blocking call to an external system or otherwise take a long time to return. In that case, if you do not
shut down the work queue threads correctly, it is possible to end up with inconsistent data.

Stop Guidewire ClaimCenter

Procedure
1. Login into Guidewire ClaimCenter as a user with administrative privileges.
2. Within ClaimCenter, press ALT+SHIFT+T to display the Server Tools screens.
3. Navigate to Batch Process Info screen:
a. For any process that has a Last Run Status that indicates that the process is running, click the Stop button in
the Action column.

56 chapter 4 ClaimCenter Server Administration

 System Administration Guide 9.0.5

b. For any process that has a Next Scheduled Run time that is before the time that you intend to stop
ClaimCenter, click Stop in the Schedule column.
All processes must have a Status of Completed before you stop the ClaimCenter server.
4. Stop Guidewire ClaimCenter:
• To stop ClaimCenter in a production environment, stop the server on which it is running.
• To stop ClaimCenter in a development environment, run the following command from the ClaimCenter
installation directory:

gwb stopServer

Server Startup Tests

The ClaimCenter server performs a series of tests during start up. For some of these tests, a test failure prevents the
server from starting. For other tests, a test failure is simply a warnings and ClaimCenter permits the server to start.
In many cases, these checks warn about potential problems with the archive and domain graphs, but which might not
be an issue depending on business logic.
In ClaimCenter, these checks verify that the current data model can support archiving, purging and export of claims.
See also
• “Domain Graph Info” on page 361
• “Consistency Checks” on page 361
• Configuration Guide

Server Modes
Server mode determines what functionality is available at various server run levels. All ClaimCenter server types,
except for QuickStart, can run in any of the following server modes:
• Development
• Test
• Production
ClaimCenter starts in production mode on all supported servers by default, except for the QuickStart server.
ClaimCenter on the QuickStart server always runs in development mode. You cannot run ClaimCenter on the
QuickStart server in production or test mode.
See also
• “Server Test Mode” on page 58
• “Server Run Levels” on page 59
• “Setting the Server Mode” on page 58
• “Set the QuickStart Run Level at Server Start” on page 61
• Installation Guide

Server Startup Tests 57

 System Administration Guide 9.0.5

Important Server Mode Caveats

The following caveats are important in working with the Guidewire development and production databases:
• It is not permissible to start a server in development mode using a production mode database.
• It is not permissible to start a server in production mode using a development mode database. Starting the server
in production mode expressly does not upgrade the development mode database to production mode.

Server Modes as a Safety Feature

Guidewire provides the server modes as a safety precaution so that it is not possible to use development tools on a
production server. Some system functions are useful for development, but are not appropriate, or, are dangerous if
used in a production environment. Thus:
• In development and test modes, it is possible to access both the Server Tools and Internal Tools screens.
• In production mode, it is possible to access the Server Tools screens only.
For more information on these tools, see “Server Tools” on page 349 and “Internal Tools” on page 411.
Setting or resetting the system time is also not safe to do in a production environment. The use of the
ITestingClock plugin is critical for testing time-sensitive processes. You can also use this plugin to modify the
current time in a running server for demonstrations. However, it is possible for the use of this plugin in a production
environment to cause disastrous results. Therefore, you can only use this plugin if the server is in development or
test mode.

Server Test Mode

Other than the exceptions listed in the following table, server test mode is identical to server production mode.

Functionality Test mode Production mode

System clock You can adjust the testing system clock by using the setCurrentTime Not available
method on the ITestingClock plugin.
See also
• Integration Guide
Server Tools screens Available Available
Internal Tools screens Available Not available
Console and log file ClaimCenter prints a message to the console during startup indicating ClaimCenter prints a message
that the server is running in test mode. to the console during startup
indicating that the server is
running in production mode.
ClaimCenter title bar The title bar for a browser connected to ClaimCenter indicates that Not applicable
ClaimCenter is in test mode.

Setting the Server Mode

You can change the server mode while using any server type except QuickStart. The QuickStart server always runs
ClaimCenter in development mode.
To set the server mode at server start, use the following system parameter:

-DserverMode={dev|prod|test}

To change the mode of a running server, restart the server and set the -DserverMode parameter to dev, test or prod.
ClaimCenter ignores this parameter on the QuickStart server.

58 chapter 4 ClaimCenter Server Administration

 System Administration Guide 9.0.5

Determining the Server Mode

You can determine the server mode through one of the following methods:
• By reading the console log as you start ClaimCenter
• By checking the title bar of the browser in which ClaimCenter is running
Note: Whenever the server starts in development mode, ClaimCenter logs a warning.

Server Run Levels

Guidewire ClaimCenter supports the concept of a server run level. A run level provides the ability to start the
ClaimCenter server with a specific level of functionality. For example, during a full application and database
upgrade, Guidewire recommends that you start ClaimCenter with limited functionality, in MAINTENANCE mode.
Guidewire specifies the server run levels in several different ways:
• A numeric run level, ranging from 0 to 5, used with the development QuickStart server.
• A server run level name that corresponds to the numeric run levels
• A system run level name used with the administrative system tools to set the server to one of the server run levels
The following table lists the correspondence between the various ways of describing the server run levels.

QuickStart Server run level System run level

0 NONE —
1 GUIDEWIRE_STARTUP —

2 SHUTDOWN —
3 NODAEMONS maintenance

4 DAEMONS daemons

5 MULTIUSER multiuser

The following list describes each type of server run level in more detail.

Type Description
QuickStart run Set at QuickStart server start using the following command, with n being a specific run level number:
level gwb runServer --run-level n
See “Set the QuickStart Run Level at Server Start” on page 61.
Server run level Shown in the server log. The server starts at level 0 and proceeds to move through each server run level in
the sequence until arriving at the requested run level.
System run level Set through command prompt system_tools options, for example:
system_tools -maintenance
See “System Tools Command” on page 422 for details.

Server run levels are independent of the server mode. The combination of mode and run level determines the
availability of functionality, such as the user interface and web services.
See also
• “Server Modes” on page 57
• “Server Modes and Server Run Levels” on page 60
• “Place the Server in Maintenance Mode” on page 63

Server Modes 59
 System Administration Guide 9.0.5

• Installation Guide

Server Modes and Server Run Levels

The following table shows which functionality is available for the possible combinations of server modes and server
run levels. For a description of the numeric values used with the development QuickStart server, see “Server Run
Levels” on page 59.

QuickStart Server run level Production mode Development mode

0 NONE • Nothing available. • Nothing available.
1 GUIDEWIRE_STARTU • User interface not available. • User interface not available.
P • Web services not available. • Web services not available.
• Database not available. • Database not available.
2 SHUTDOWN • User interface not available. • User interface not available.
• Web services not available. • Web services not available.
• Database not available. • Database not available.
3 NODAEMONS • User interface not available. • User interface available. All logins allowed.
• Web services available. • Web services available.
• Staging table loading available. • Staging table loading available.
• Batch processes available. • Batch processes available.
4 DAEMONS • User interface not available. • User interface available. All logins allowed.
• Web services available. • Web services available.
• Work queues (including workflow) • Work queues (including workflow) available.
available. • Workflow Stat Manager available.
• Workflow Stat Manager available. • Scheduler available.
• Scheduler available. • Daemons started by ClaimCenter, such as
• Daemons started by ClaimCenter, those used to dispatch messages.
such as those used to dispatch
messages.
5 MULTIUSER • User interface available. All logins • User interface available. All logins allowed.
allowed. • Server Tools available to all users if EnableInt
• Server Tools available for users with ernalDebugTools is set to true in config.xml
admin permission only. • Internal Tools available.
• Internal Tools not available. • Web services available.
• Web services available.

Setting the Quick Start Server Run Level

It is possible to set the run level of a server to one of the following system run levels:
• daemons
• maintenance
• multiuser
If you run ClaimCenter in a clustered environment, you cannot place all the computers in a particular run level with
a single command. Instead, you must run the command individually on each cluster member.
See also
• “Server Run Levels” on page 59
• “Server Modes and Server Run Levels” on page 60
• “System Tools Command” on page 422
60 chapter 4 ClaimCenter Server Administration
 System Administration Guide 9.0.5

• Integration Guide

Set the QuickStart Run Level at Server Start

Procedure
1. Open a command prompt and navigate to the ClaimCenter installation directory.
2. Run the following command:

gwb runServer -run-level n

The value of n is the numeric value of the run level as defined in “Server Run Levels” on page 59.

Set the Server Run Level Through System Tools

Procedure
1. Ensure that the ClaimCenter server is running.
2. Open a command prompt and navigate to the following location in your ClaimCenter installation directory:

admin/bin

3. Enter one of the following commands:

system_tools -user user –password password –daemons

system_tools -user user –password password –maintenance
system_tools -user user –password password –multiuser

You must supply the username (user) and password (password) for a user with administrative privileges on
the ClaimCenter server. The run level is a value as defined in “Server Run Levels” on page 59.

Set the Server Run Level Through Web Services

Procedure
1. Ensure that the ClaimCenter server is running.
2. Call the following method on the SystemToolsAPI web service:

SystemToolsAPI.setRunLevel

Next steps
If you run ClaimCenter in a clustered environment, you cannot place all the computers in a particular run level with
a single method call. Instead, you must call the method individually on each cluster member.

Determining the Server Run Level

You can determine the server run level through any of the following methods.

Type More information

System tools “Use System Tools to Determine the Server Run Level” on page 62
Web services “Use Web Services to Determine the Server Run Level” on page 62

Setting the Quick Start Server Run Level 61

 System Administration Guide 9.0.5

Type More information

Server ping “Using the ClaimCenter ping Utility” on page 155

The returned message indicates the server run level. The possible responses are:
• MULTIUSER
• DAEMONS
• MAINTENANCE
• STARTING
See also
• “Server Run Levels” on page 59

Use System Tools to Determine the Server Run Level

Procedure
1. Ensure that the ClaimCenter server is running.
2. Open a command prompt and navigate to the following location in the ClaimCenter installation directory:

admin/bin

3. Enter the following command:

system_tools -user user -password password –ping

You must supply the username (user) and password (password) for a user with administrative privileges on
the ClaimCenter server.

Use Web Services to Determine the Server Run Level

Procedure
1. Ensure that the ClaimCenter server is running.
2. Call the following method on the SystemToolsAPI web service:

SystemToolsAPI.getRunLevel

Next steps
See also
• Integration Guide

Server Maintenance Mode

Periodically, you need to perform maintenance on ClaimCenter, for example, batch importing First Notice of Loss
claims or importing new security roles. To prevent users from logging into ClaimCenter during these activities,
place ClaimCenter into the maintenance run level.
The maintenance run level effectively disables the ClaimCenter web interface if the server is in production mode.
ClaimCenter stops allowing new user connections and halts existing user sessions to production mode instances
while running at the maintenance run level.

62 chapter 4 ClaimCenter Server Administration

 System Administration Guide 9.0.5

ClaimCenter still allows connections made through APIs or command prompt tools for any daemons with a
minimum run level equal or lower than NODAEMONS. Restricting the run level permits integration processes to
proceed without interference from non-administrator users.
See also
• “Server Run Levels” on page 59
• “Set the QuickStart Run Level at Server Start” on page 61
• “Set the Server Run Level Through System Tools” on page 61
• “Set the Server Run Level Through Web Services” on page 61

Place the Server in Maintenance Mode

Procedure
1. Open a command prompt and navigate to the following ClaimCenter installation directory:

admin/bin

2. Run the following command:

system_tools -password password -user user -maintenance

You must supply the username (user) and password (password) for a user with administrative privileges on
the ClaimCenter server.

Monitoring Server Performance in ClaimCenter

Use standard operating system tools to monitor memory usage, CPU usage, and disk space to verify that the servers
run smoothly. In particular, monitor disk space for log files, so ClaimCenter does not run out of disk space for logs.
Archive and truncate system logs periodically to prevent the ClaimCenter logs from growing too large.
If the server crashes with the following JVM error, increase the maximum heap size (-Xmx setting) of the JVM.

Internal Error (53484152454432554E54494D450E43505001A8)

See also
• “Monitoring Server Status with WebSphere” on page 63
• “Monitoring Cluster Health” on page 153
• Documentation specific to the application server
• Installation Guide

Monitoring Server Status with WebSphere

You can monitor the status of the ClaimCenter server from the WebSphere console. To view the server’s status,
select the ClaimCenter cluster member from the main console. WebSphere displays the Show Status option if the
server is running. WebSphere also generates and displays system logs. Also, you can start an Export for Backup from
the WebSphere console. Guidewire recommends that you back up the server before performing any major system
maintenance.

Server Maintenance Mode 63

 System Administration Guide 9.0.5

Monitoring and Managing Event Messages

ClaimCenter generates a large number of events. In a ClaimCenter installation, it is often helpful, or even necessary,
for ClaimCenter to notify other applications of these events. ClaimCenter integration developers create message
destination objects that provide the means for passing information between ClaimCenter and a particular destination.
Rule writers can write Gosu rules to generate messages in response to events of interest. ClaimCenter queues these
messages and dispatches them to receiving systems by using the destination objects.
Guidewire recommends that you monitor message traffic to verify that the integration is running smoothly.
See also
• For more information about messages, including how to create message destination objects, see the Integration
Guide.

About Message Failure

If ClaimCenter receives an unrecoverable or unexpected exception from a send attempt, or reaches the retry limit, it
does not send messages to that destination until you clear the error. If ClaimCenter receives a processing error that is
not retryable, ClaimCenter also suspends the destination and waits for you to clear the error.
To clear a message error, do one of the following:
• Manually retry to send the message
• Skip the message
You can retry or skip messages:
• Through the Message Queues screen available to application administrators
• Through messaging_tools command prompt options
If ClaimCenter becomes completely out of synchronization with an external system, such that skipping or retrying a
message is insufficient to re-synchronize the two systems, re-synchronize the entire destination. A re-
synchronization causes ClaimCenter to drop all pending and failed messages and resend all the messages associated
with a particular item.
See also
• “Message Queues Screen” on page 64
• “Messaging Tools Command” on page 420

Message Queues Screen

ClaimCenter lists each message destination in the Message Queues screen. You access this screen from the
ClaimCenter Administration screen by first choosing Monitoring. The first screen of Message Queues contains cumulative
information about message destinations.
From this screen, you can select a message destination and perform the following actions:
• Suspend – Click to suspend the operation of the selected message destination.
• Resume – Click to resume the operation of the selected message destination if that destination is in a state of
suspension.
• Restart – Click to restart the operation of a selected message destination.
You can also restart the messaging engine by clicking Restart Messaging Engine.
If a message destination is running correctly, you do not see any accumulation of information in the columns on this
screen. If there is a problem and messages begin to accumulate, you can drill down into a message destination by
clicking the destination name. This action opens a Destination screen. From the Destination screen, you can see
additional detail about any issues with a destination. This information can assist you in diagnosing the error. In
particular, you can use the Error Message column to see the possible cause of a particular issue.

64 chapter 4 ClaimCenter Server Administration

 System Administration Guide 9.0.5

The Destination Screen

The Destination screen lists all failed or in-process messages for a claim for all destinations. You can search for a
particular claim and then open the claim’s detail view. From this screen, you can select one or more objects and
instruct ClaimCenter to skip, retry, or re-synchronize any message that is still in process or in a failed state.
The Detailed Statistics table column headers have the following meanings.

Column Meaning
header
Safe Ordering ClaimCenter groups messages for each messaging destination based on their associated primary object.
Object Name (ClaimCenter processes messages associated with objects other than the primary object as non-safe-ordered
messages.)
Send Time Time the ClaimCenter sent the message.
Failed A message can fail for several reasons, for example:
• The message destination did not process the message successfully due to a processing error.
• The message destination returns a negative acknowledge (nack) indicating that the message delivery
failed.
• The message was part of a series of messages, one or more of which failed.
Retryable Error Waiting to attempt a retry. ClaimCenter attempted to send the message but the destination threw an
exception. If the exception was retryable, ClaimCenter automatically attempts to retry the send before turning
the message into a failure. ClaimCenter attempts to send an event message several times. Typically, you can
configure the number of retries and the interval between them for an integration. Review documentation for
the specific destination to find out how to configure it.
In Flight ClaimCenter is waiting for an acknowledgement.
Unsent The message has not been sent, for example:
• The message is waiting on a prior message.
• The destination is not processing messages as the destination is in a state of suspension.
• The destination is falling behind in processing messages.
Error Message Error message returned if a message fails.

It is possible to filter the messages that show in the table by selecting a filtering characteristic from the filtering
drop-down list.

Message Handling
A ClaimCenter server reads integration messages from a queue and dispatches them to their destinations. However,
there is no guarantee that messages in the queue are ready for dispatching in the same order in which ClaimCenter
places the messages in the queue.
For example, suppose that a messaging server starts writing message 1 to the queue, and then starts writing message
2 to the same queue. It is possible that the server completes and commits message 2 while still writing message 1.
This does not, in itself, present an issue. However, if the server attempts to read messages off the queue at this
moment, then it skips the uncommitted message1 and reads message 2. You are most likely to encounter this
situation in a clustered ClaimCenter environment.
To address this situation, ClaimCenter provides the IncrementalReaderSafetyMarginMillis parameter in file
config.xml. This parameter determines how long after detecting a skipped message that ClaimCenter attempts to

Monitoring and Managing Event Messages 65

 System Administration Guide 9.0.5

read messages again. This waiting period gives ClaimCenter a chance to commit the skipped message. If it is not
possible to commit the message before the expiration of the waiting period:
• ClaimCenter assumes the message is lost and that it is not possible to commit the message.
• ClaimCenter skips the message permanently, thereafter.
For example, in the previous scenario, ClaimCenter waits 10 seconds (the default parameter value) before
attempting to read messages again, beginning with the skipped message 1. If message 1 has still not been committed
at that time, ClaimCenter skips it permanently.
Set the IncrementalReaderSafetyMarginMillis parameter sufficiently long so that the server can commit the
messages, but without prematurely marking messages as permanently skipped. As the server does not read any other
messages during this waiting period, do not set IncrementalReaderSafetyMarginMillis so long as to delay the
delivery of messages.
You can also set the following configuration parameters in config.xml to configure the messages reading
environment:
• IncrementalReaderPollIntervalMillis
• IncrementalReaderChunkSize

Access the Messaging Editor

About this task
You create and configure message environments and destinations in file messaging-config.xml.

Procedure
1. In the ClaimCenter Studio Project window, navigate to configuration→config→Messaging.
2. Double-click file messaging-config.xml to open the file in the Studio Messaging editor.

Next steps
See also
• Configuration Guide

Purge Completed Messages

About this task
Every time ClaimCenter sends an event message, it expects to receive a positive acknowledgement (ack) back from
the destination indicating it received and processed the message. ClaimCenter retains completed messages until you
purge them. As the number of messages in ClaimCenter can grow to be large, Guidewire recommends that you
purge completed messages on a regular basis.

Procedure
1. Ensure that the Guidewire ClaimCenter server is running.
2. Open a command prompt in the following location in the ClaimCenter installation directory:

admin/bin

3. Enter the following messaging_tools command, replacing the variables as needed:

messaging_tools -user user -password password -purge MM/DD/YY

For example, the following command purges all completed messages received prior to 02/06/06.

66 chapter 4 ClaimCenter Server Administration

 System Administration Guide 9.0.5

messaging_tools -user su -password gw -purge 02/06/17

You must supply the username (user) and password (password) for a user with administrative privileges.

Session Timeout
ClaimCenter creates a session for each browser connection. ClaimCenter uses the server’s session management
capability to manage the session. Each individual session receives a security token that the ClaimCenter server
preserves across multiple requests. The server validates each token against an internal store of valid tokens.
You configure the timeout value for a session by setting the SessionTimeoutSecs parameter in config.xml. This
value sets the session expiration timeout globally for all ClaimCenter browser sessions.
Typically, the server determines the session timeout value according to the following hierarchy.

Level Description
Server The session timeout to use for all applications on the server if the timeout value is not set at a higher level.
Enterprise The session timeout specified at the enterprise application level. You can specify this value at the EAR file
application level. You can set the enterprise application session timeout value to override the server session timeout
value.
Web application The session timeout specified at the web application level. You can specify this value at the WAR file
level.You can set the web application session timeout value to override the enterprise application and server
session timeout values.
Application The session timeout specified in the application web.xml file. ClaimCenter does not specify a session
level timeout in web.xml.
Application An application can override any other session timeout value. ClaimCenter uses the session timeout value
code specified by the SessionTimeoutSecs parameter in config.xml.
User An administrator can set the session expiration timeout value on an individual user basis, using the Session
timeout field on the ClaimCenter User screen.

See also
• Configuration Guide

User Session Replication

Do not attempt to replicate sessions across ClaimCenter cluster members. ClaimCenter does not implement or
support user session replication for a number of reasons, including the following:
• ClaimCenter sessions are not serializable. Therefore, you cannot replicate a ClaimCenter session, either with or
without persistence to the database.
• ClaimCenter sessions hold the user state in memory and contain large amounts of information. Guidewire
estimates that this information amounts to 1 MB of data on average for a 32-bit server and close to 2 MB for a
64-bit server. Session replication would create significant cross-member communication that is detrimental to
performance.
• ClaimCenter commits changes to the database on almost all transactions. Notable exceptions are some wizards
for which ClaimCenter commits data changes only after the user completes all necessary entries.
• ClaimCenter scales horizontally almost linearly. The implementation of a session replication solution would very
likely impede that linear scalability.
Instead, Guidewire recommends that you implement a ClaimCenter cluster consisting of multiple ClaimCenter
application instances with failover and a load balancing solution. The load balancer must implement session affinity,
meaning that it must route connections from the same user session to the same ClaimCenter server.
Session Timeout 67
 System Administration Guide 9.0.5

See also
• “Planning a ClaimCenter Cluster” on page 149
• Installation Guide

Cache Management
Objects do not remain forever present or valid in the ClaimCenter database cache. Guidewire provides several
caching mechanisms to verify that cache entries are still relevant. They are:
• Stale timeout
• Eviction timeout
• Cluster member object tracking

Stale Timeout
A stale timeout mechanism ensures that the server instance does not use old object entries excessively. An object is
stale if it has not been refreshed from the database within a configurable amount of time. Upon accessing a cache
entry, the server instance calculates the duration since the object was last read from the database. If that duration
exceeds the stale time, the server instance refreshes the cache entry from the database.
To avoid increased complexity, ClaimCenter prefers this mechanism over evicting objects upon stale timeout. You
can set a default stale time by adjusting the GlobalCacheStaleTimeMinutes parameter in config.xml.

Eviction Timeout
A ClaimCenter evict timeout mechanism removes old objects from the cache. For example, an object has an evict
time of 15 minutes and a stale time of 30 minutes. If the server uses the object a single time every 14 minutes,
ClaimCenter never evicts the cache entry, but the entry does eventually become stale.
You can set the default evict time by adjusting the GlobalCacheReapingTimeMinutes parameter in config.xml. In
the base configuration Guidewire sets the value of GlobalCacheReapingTimeMinutes to 15 minutes. The minimum
value for this parameter is 1 minute. The effective maximum value for parameter
GlobalCacheReapingTimeMinutes is the lesser of its set value or the value of GlobalCacheStaleTimeMinutes
parameter.

Cluster Member Object Tracking

Upon receipt of an inter-cluster message indicating that a cluster member changed an object value, the other cluster
members mark the corresponding entry in the cache as obsolete. The object value then becomes available for reuse.
See also
• “Guidewire ClaimCenter Cluster Installations” on page 134
• “Cache Info” on page 398
• Configuration Guide

Caching and Stickiness

ClaimCenter is fully leveraging the caching mechanism if a user returns to the same server instance across different
HTTP requests. In a clustered environment, the load balancer must direct requests to the same ClaimCenter server
upon consecutive interactions. This mechanism, referred to as stickiness, enables a true horizontal scalability
solution. For more information on load balancing options for ClaimCenter, consult Guidewire Services.
Each server manages its own cache. It is possible for the same object to live in the cache of two or more servers at
the same time. Some object sets, such as users, likely live in the global cache of all servers in a cluster.

68 chapter 4 ClaimCenter Server Administration

 System Administration Guide 9.0.5

Concurrent Data Change Prevention

It is possible for different users, either on the same ClaimCenter server or on a different server, to attempt to change
data objects concurrently. To prevent data corruption, Guidewire implements a data object versioning mechanism.
During the update to an object value to the database, ClaimCenter compares a counter associated with the object to
the counter in the database. A counter value mismatch indicates that two different user changed the object
concurrently. In such case, ClaimCenter rejects the change and the cache mechanism throws a concurrent data
change exception. ClaimCenter presents the user who initiated the concurrent change with the error and reloads the
latest data. The user can then reapply the changes.
Furthermore, ClaimCenter commits changes in an atomic bundle, ensuring transactional integrity. Therefore,
ClaimCenter enforces protection against concurrent data changes across the whole transaction. This mechanism is a
standard design pattern called optimistic locking.
Concurrent data change exceptions occur only if two users modify the same object. A proper organization of the
user community avoids this. Nevertheless, if two users modify the same object, any automatic resolution carries a
significant risk of causing unwanted modifications. The optimistic locking mechanism causes very few concurrent
data change exceptions and users can easily resolve those exceptions.
Other design patterns exist for concurrent data changes. The pessimistic locking pattern prevents all other users from
modifying an object while one user or batch process is making a change. In many cases, pessimistic locking
becomes completely dysfunctional. For example, if a user or batch process cannot complete a change, the locking
mechanism blocks any other user of batch process from making a change. Pessimistic locking systems generally
become impractical. Therefore, ClaimCenter uses the optimistic locking mechanism.

Caching and Clustering

For information on how Guidewire clusters handle caching, see “Guidewire ClaimCenter Cluster Installations” on
page 134.

Cache Behavior and Performance

Guidewire generally distinguishes two types of caches:
• Server cache – A cache that is purely local to the ClaimCenter server
• Database cache – A cache used by a database to hold data retrieved from storage
Proper database caching behavior is critical to performance.
The server cache is purely local to each individual ClaimCenter server. Therefore, one server instance might contain
information on a specific object while another server might not contain that information.
For example, if a ClaimCenter user works on a claim, ClaimCenter loads corresponding objects on the server to
which the user connects. If another user must approve the action of the first user, the approver user might interact
with another ClaimCenter server. In that case, the second server likely does not have the corresponding information
in cache. Therefore, the approver might experience slower performance as the server must populate the cache.
Cache content is lost every time that you stop a ClaimCenter server. Therefore, after you start a ClaimCenter server,
expect lower performance during a ramp-up phase.
Batch processes leverage the cache mechanism. Batch jobs can work on many objects. Therefore, batch jobs can use
the cache extensively. This can have the adverse effect of prematurely evicting objects from the cache, thereby
forcing additional cache loads. If you run many intensive batch processes, Guidewire recommends that you have a
dedicated server with the batch role with no online traffic directed to it.

69
 System Administration Guide 9.0.5

See also
• “Server Cache Tuning Parameters” on page 71

Cache Thrashing
Cache thrashing is a phenomenon whereby evictions remove cache entries prematurely and force additional database
reloads that are detrimental to performance. There are several cases that can lead to cache thrashing:
• A single data set can be too large to reside in the global cache. This forces the server to load the same data from
the database and subsequently evict the data, potentially thousands of times, while loading a single web page.
This results in serious performance issues.
• Some concurrent actions result in thrashing. For example, a user logs onto a server that has the batch server role.
A batch job, which can load many objects into the cache, can remove objects from the cache. This forces the
server to reload the cache as the user again needs those objects. For this reason, Guidewire recommends that you
have separate servers for handling batch processing and user interface transactions.
If an individual cache reports hundreds or thousands of evictions and a low cache hit rate, then that cache is
experiencing cache thrashing. If you notice cache thrashing on a server that is not processing batch jobs, re-size the
cache. Otherwise, dedicate the server to batch jobs.
See also
• “Detect Cache Thrashing” on page 70.

Detect Cache Thrashing

Procedure
1. Log into Guidewire ClaimCenter as a user with administrative privileges.
2. Press ALT+SHIFT+T to open the Server Tools screens.
3. Navigate to the Cache Info screen.
4. Use the information in the Cache Info screen to analyze the number of evictions.
5. Click Clear Global Cache to clear the cache.
6. Reproduce the operation that you suspect caused the cache thrashing.
7. Reanalyze the information on the Cache Info screen.

Next steps
After you have taken the proper action, repeat the analysis to verify that the change yielded the results you expected
to occur.
See also
• “Cache Thrashing” on page 70.

Cache Impact on Memory Utilization

The maximum size of the cache is dependent on cache parameters. The server cache grows in size to reach a
maximum specified by cache sizing parameters. Java does not provide a good means to estimate the memory usage
of objects. Therefore, it is difficult to reliably estimate the maximum size of a cache. If the cache size exceeds the
maximum heap size, the application eventually runs out of memory.
Larger caches increase memory starvation issues. Larger caches expand the memory footprint of the application.
Performance decreases as garbage collection becomes more frequent and analyzes more objects.
Set the cache as large as needed, but no larger. Monitor garbage collection to extrapolate memory usage patterns and
garbage collection statistics.

70 chapter 4 ClaimCenter Server Administration

 System Administration Guide 9.0.5

See also
• “Server Cache Tuning Parameters” on page 71.
• “Server Memory Management” on page 73

Server Cache Tuning Parameters

File config.xml contains cache parameters for ClaimCenter. Access this file from Guidewire Studio at
configuration→config.

Parameter Description
ExchangeRatesRefreshIntervalSecs The number of seconds between refreshes of the exchange rates cache.
ClaimCenter uses this specialized cache for exchange rates only.
GlobalCacheActiveTimeMinutes Time, in minutes, that ClaimCenter considers cached objects active. You
can think of this as a period in which ClaimCenter is heavily using an item,
for example, how long a user stays on a screen. The cache mechanism
gives higher priority to preserving these higher-use objects.
Set GlobalCacheActiveTimeMinutes to a value less than GlobalCacheRea
pingTimeMinutes.

GlobalCacheDetailedStats Boolean value that specifies whether to collect detailed statistics for the
global cache. Detailed statistics are data that ClaimCenter collects to
explain why the caching mechanism evicted items from the cache.
ClaimCenter collects basic statistics, such as the miss ratio, regardless of
the value of GlobalCacheDetailedStats. Disabling collection of detailed
cache statistics can sometimes improve performance.
Guidewire sets the value of GlobalCacheDetailedStats to false by
default. Set the parameter to true to help tune your cache.
If the GlobalCacheDetailedStats parameter is set to false, the Cache Info
screen does not include the Evict Information and Type of Cache Misses graphs.
At runtime, use the Management Beans screen to enable the collection of
detailed statistics for the global cache.
GlobalCacheReapingTimeMinutes Time, in minutes, since the last use of a cached object before ClaimCenter
considers the object eligible for reaping. This can be thought of as the
period during which ClaimCenter is most likely to reuse an object.
An evict timeout mechanism removes old objects from the cache. Once per
minute, a thread evicts cache entries that have not been used for a period
equal to or greater than GlobalCacheReapingTimeMinutes. This
mechanism differs from the stale timeout mechanism. The stale timeout
mechanism refreshes from the database those cache entries that have
exceeded the stale time. This process occurs as the server accesses a
cached object. The evict timeout mechanism deletes any cache entries that
are older than the default evict time. An object can become stale but not
evicted if it is continually in use. For example, a bean has an evict time of
15 minutes and a stale time of 30 minutes. If the server uses the object
once every 14 minutes, ClaimCenter never evicts the cache entry, but the
entry does eventually become stale.
GlobalCacheReapingTimeMinutes is initially set to 15 minutes. The
minimum value for this parameter is 1 minute. Since the eviction thread
only runs once per minute, a smaller value would not make sense. The
maximum value for this parameter is 15 minutes.
GroupCacheRefreshIntervalSecs The number of seconds between refreshes of the groups cache.
ClaimCenter uses this specialized cache for group-related data only.
GlobalCacheSizeMegabytes Maximum amount of heap space used to store cached entities, expressed
as a number of megabytes. This parameter supersedes the value of Global
CacheSizePercent.

71
 System Administration Guide 9.0.5

Parameter Description
At runtime, you can use the Cache Info or Management Beans screen to modify
this value.
GlobalCacheSizePercent Maximum amount of heap space used to store cached entities, expressed
as a percentage of the maximum heap size.
GlobalCacheStaleTimeMinutes Time, in minutes, after which ClaimCenter considers an object in the cache
stale if it has not been refreshed from the database.
A stale timeout mechanism ensures that the server does not use
excessively old object entries. An object is stale if it has not been refreshed
from the database within a configurable amount of time. Upon accessing a
cache entry, the server calculates the duration since the object was last
read from the database. If that duration exceeds the stale time, the server
refreshes the cache entry from the database. To avoid increased
complexity, ClaimCenter prefers this mechanism over evicting objects upon
stale timeout.
At runtime, you can use the Cache Info or Management Beans screen to modify
this value.
GlobalCacheStatsWindowMinutes This parameter denotes a period of time, in minutes, that ClaimCenter uses
for two purposes:
• The period of time to preserve the reason that ClaimCenter evicted an
object, after the event occurred. If a cache miss occurs, ClaimCenter
reports the reason on the Cache Info screen.
• The period of time to display statistics on the chart on the Cache Info
screen.
ScriptParametersRefreshIntervalSecs The number of seconds between refreshes of the script parameters cache.
ClaimCenter uses this specialized cache for script parameters only.
ZoneCacheRefreshIntervalSecs The number of seconds between refreshes of the zones cache. ClaimCenter
uses this specialized cache for zones only.

See also
• “Special Caches for Rarely Changing Objects” on page 73
• “Cache Info” on page 398
• “Management Beans” on page 386
• Configuration Guide

Understanding Cache Metrics

Cache hit ratio metric information intrinsically depends on the workflow that is using the object. Some workflows
involve reading an object only one time while others involve reading the object many times. The cache hit varies
depending on these workflows.
Also, it is also for the data be appear skewed to the low side if a server started recently, or if the server has not had
much user load. For example, if you recently started the server, and users have only visited a few screens, the hit rate
is very low because ClaimCenter encountered only a few cache hits. As users visit more pages, the hit rate increases.
Thus, there are no good default cache hit ratios. Experimentation combined with performance measurements
constitutes the only approach to identifying appropriate cache sizes.

72 chapter 4 ClaimCenter Server Administration

 System Administration Guide 9.0.5

See also
• For information on how to view cache performance, see “Cache Info” on page 398.

Special Caches for Rarely Changing Objects

ClaimCenter includes specific individual caches for the following rarely changing objects:
• Exchange rates
• Groups
• Script parameters
• Zones
These specialized caches periodically refresh the entire set of the rarely changing object. This prevents the server
from querying the database each time ClaimCenter accesses one of these objects, thereby improving performance.
For each of these special caches, you can set the refresh interval through a configuration parameter in file
config.xml.
The following table lists the objects with specialized caches, along with the configuration parameter that controls the
refresh rate of each specialized cache.

Cache objects Cache refresh rate set by…

ExchangeRate ExchangeRatesCacheRefreshIntervalSecs

Group GroupCacheRefreshIntervalSecs

ScriptParameter ScriptParametersRefreshIntervalSecs

Zone ZoneCacheRefreshIntervalSecs

See also
• “Server Cache Tuning Parameters” on page 71.
• Configuration Guide

Server Memory Management

Java provides platform-side memory management that significantly simplifies coding. The JVM (Java Virtual
Machine) periodically identifies unused objects and reclaims associated memory. In general, computer science calls
this term garbage collection. Garbage collection can have a significant impact on server performance.
This topic describes Java platform garbage collection analysis.

Memory Usage Logging

If configured in file logging.properties, Guidewire logs contain memory usage messages that provides
information on the use of memory by the JVM. To enable memory usage logging, you must set parameter
MemoryUsageMonitorIntervalMins in config.xml to a value other than the default of 0.
A memory usage message looks similar to the following:

serverName 2016-04-09 16:44:14,423 INFO Memory usage: 80.250 MB used, 173.811 MB free, 254.062 MB total,
2048.000 MB max

The following list describes the different types of information that you see in a memory logging message.

73
 System Administration Guide 9.0.5

Memory usage Meaning

used Amount of memory allocated to objects. This includes memory for the following memory types:
• Memory used by active objects still in use
• Memory used by stale objects (on which the JVM eventually performs garbage collection)
free Amount of un-allocated memory
total Amount of memory that the JVM process reserves from the operating system.
max Amount of maximum total memory that ClaimCenter allows the JVM to use.

It is common for a server to use up the maximum amount of memory fairly quickly, so that used and total are at or
near the max value. This indicates normal operation. If the server needs more memory, it triggers garbage collection
to free up the memory used by stale objects.

Memory Usage Messages and Garbage Collection

It is not possible to configure the content of the logging messages to provide enough detail to indicate or warn of
memory issues. The only way to obtain a more accurate picture of memory usage is through running the garbage
collector.
Guidewire does not support running the garbage collector merely for the sake of more detailed logging. However, to
obtain more detailed information on ClaimCenter memory usage in the current configuration, enable garbage
collector logging.
You only need to worry about memory issues if the server throws an OutOfMemoryError exception. If that happens,
Guidewire recommends that you configure the garbage collector to print out detailed memory information.
See also
• “Enabling Garbage Collection” on page 74
• “Understanding Possible Memory Leak” on page 76

Enabling Garbage Collection

The garbage collector can provide additional information on collection statistics. Careful analysis helps understand
garbage collector behavior.
Verify that the performance analysis tool you choose supports the version of the JVM that you use for ClaimCenter.
To determine the supported JVM versions, visit the Guidewire Community and search for knowledge article 1005,
Supported Software Components.
See also
• “Enabling Verbose Garbage Collection for IBM JVM” on page 74
• “Enabling Verbose Garbage Collection for Oracle Java Hotspot VM” on page 75

Enabling Verbose Garbage Collection for IBM JVM

To enable verbose garbage collection for IBM Java Virtual Machines, add the -verbose:gc flag to the JVM options.
Other options exist for the same functionality.
IBM estimates that the overhead associated with verbose garbage collection is minimal and estimated to be 2% of
the garbage collection time. In other words, if the JVM spends 5% of its time garbage collecting without verbose
garbage collection, it would spend 5.1% of the time garbage collecting with verbose garbage collection.
The output provided is in XML format. This output is generally rich enough for a thorough analysis. In general,
there is no need for additional levels of logging.
Used with WebSphere, the IBM JVM outputs garbage collection logs into a file called native_stderr.log.

74 chapter 4 ClaimCenter Server Administration

 System Administration Guide 9.0.5

IBM provides the IBM Support Assistant. You can install multiple plugins within this tool. Several plugins are
available for the IBM JVM and WebSphere. These tools provide deep analysis of JVM behavior, spot issues, and
recommend how to tune the JVM.

IBM Support Assistant

IBM provides the IBM Support Assistant Workbench. It is possible install multiple plugin tools within the
workbench. The “IBM Monitoring and Diagnostic Tools for Java – Garbage Collection and Memory Visualizer” is
the tool to use to analyze garbage collection logs.
The tool provides some tuning recommendations. The recommendations work more for the IBM JDK than the
HotSpot JDK. Additionally, the tool provides graphs with hints on JVM behavior that help identify issues such as
memory shortages or excessive pauses.
Refer to the following web site for more information about the IBM Support Assistant:

http://www.ibm.com/software/support/isa/

Enabling Verbose Garbage Collection for Oracle Java Hotspot VM

To enable verbose garbage collection on an Oracle Java Hotspot JVM, add the -verbose:gc flag to the Java
HotSpot VM options. Several levels of logging exist, providing more or less output.
The garbage collection time logs can time stamp the various entries with the exact date. Guidewire recommends the
following options:

-XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -XX:+PrintGCApplicationConcurrentTime

-XX:+PrintGCApplicationStoppedTime

These options provide the following:

• Nature of the garbage collection (minor or full)
• Amount of memory reclaimed
• Time elapsed since JVM start or date corresponding to the event, depending on available options
• Before and after state of the different memory pools (nursery, tenured and permanent)
• Amount of time the application runs between collection pauses
• Duration of the collection pause
The level of information can be overwhelming, though it is necessary in some cases.
Add the -Xloggc:file option to redirect output to the specified file.

HPjmeter and GCViewer

HPjmeter and GCViewer are tools that enable you to visually analyze the HotSpot JDK garbage collection logs.
Both tools generate:
• Key metrics about the period (number of minor/major collections, percent of time spent paused, and so forth)
• Visual representation of the different garbage collections
These tools might require different verbose garbage collection options. Otherwise, HPjmeter or GCViewer might not
be able to analyze the corresponding output.
For information on these utility tools, refer to the respective company web sites.

Enabling Garbage Collection 75

 System Administration Guide 9.0.5

Refer to the following web sites for more information:

• HPjmeter – http://www.javaperformancetuning.com/tools/hpjmeter/index.shtml
• GCViewer – http://www.tagtraum.com/gcviewer.html

Understanding Possible Memory Leak

Guidewire applications are memory-intensive. Guidewire applications generally require larger heaps than most other
Java applications.
Garbage collection logs might show that memory usage grows significantly over time, resulting in a lack of
available memory. Computer science commonly describes this condition as a memory leak. To diagnose the
problem, it is necessary to collect a dump of all used objects, called a heap dump, to identify all objects in the heap.
Developers familiar with ClaimCenter can then analyze the heap dump. Such analysis helps identify excessive
memory usage, identify its root cause and possibly find a change that will avoid such issues.
The investigation of memory leaks differs slightly depending on the JVM platform.

Common Approaches for Heap Dump Generation

In general, you can use the following options to generate a heap dump:
1. Set specific flags to force the following behaviors:
• Heap dump generation if the heap is full and an out-of-memory condition occurs
• Heap dump generation if an application CTRL-BREAK or SIGQUIT occurs
Combine these options with options instructing the JVM to generate the heap dump at a specific directory
location.
2. Use tools to connect to a running JVM. Such tools provide the option to trigger a heap dump.

Generating Heap Dumps with IBM JDK

In general, the capability for generating heaps dumps is satisfactory in all of the IBM JVM release levels. For
information on generating heap dumps for IBM JDK 1.6, refer to the following document:
IBM Developer Kit and Runtime Environment, Java Technology Edition, Version 6

Related information
IBM Developer Kit and Runtim Environment - Diagnostics Guide

Generating Heap Dumps with Oracle HotSpot JDK

Use the following flags for heap dump generation:
• HeapDumpOnCtrlBreak
• HeapDumpOnOutOfMemoryError
For more information about analyzing heap dumps, refer to the following Oracle document:
Troubleshooting Guide for Java SE 6 with HotSpotVM

Related information
Troubleshooting Guide for Java SE 6 with HotSpot VM

Additional Heap Dump Recommendations

While generating heap dumps, pay attention to the following facts:
• Heap dump generation frequently fails because the single file it generate is very large and the configuration of
the supporting environment prevents regular accounts from creating such large files. Therefore, it is usually the

76 chapter 4 ClaimCenter Server Administration

 System Administration Guide 9.0.5

case that you must provide some configuration to allow the account running the ClaimCenter instance to create
such large files.
• The generation of a heap dump during out-of-memory conditions is sometimes challenging. As a JVM is
reaching maximum memory utilization, it generally experiences severely degraded performance. As the pace of
the leak decreases gradually, the occurrence of the out-of-memory condition might take an inordinate amount of
time. This length of time might be incompatible with the need to restore performance for users or processes.
• Windows only: Windows does not support signals. Therefore, generating a heap by starting the JVM with a heap
dump on CTRL-BREAK, depends on the capacity to send a CTRL-BREAK. You cannot send a CTRL-BREAK to a JVM
started as a background process. Therefore, for the time of the investigation, start the JVM from a command
prompt rather than as a background process.
• The JVM generally provides optional flags that prevent it from listening to signals. Disable these flags while
trying to generate a heap dump through signals.
• Heap dump analysis is very memory intensive. Assume that the tool used to analyze the heap dump might need a
heap two to three times larger than the amount of objects captured in the heap dump. Host the heap dump
analyzer on a server with a 64-bit JVM and a significant amount of memory. If such a configuration is not
available, you might want to reduce the heap size so that the memory leak reaches an identifiable threshold
sooner. This method allows the generation of smaller, easier to analyze heap dumps.
• Heap dump analysis tools generally point to the CacheImpl class as the largest memory consumer. This class
corresponds to the Guidewire cache. It is normal that the cache consumes a few hundred megabytes. In this case,
the memory issue is likely not caused by cache growth. If the cache consumes significantly more memory, you
might need to be downsize the cache. See .

Heap Dump Generation and Analysis Tools

Several tools are available for heap dump generation and analysis. Both IBM and Oracle provide some tools to assist
with these tasks on their respective JVMs. Other vendors also provide some tools that aim to assist with these tasks
on the most common JVM platforms.

IBM-only Tools for Heap Dump Generation

IBM provides tools that can assist with heap dump analysis. You can find information on these tools on the IBM
Support Assistant web site.
IBM also provides the IBM DTJF adapter for Eclipse Memory Analyzer for use in analyzing IBM JVM heap
dumps. You can tune the tool to use a larger heap, which is frequently necessary to analyze very large heap dumps.

Related information
IBM Support Assistant
IBM DTJF adapter for Eclipse Memory Analyzer

Oracle-only Tools for Heap Dump Generation

Oracle Java Monitoring and Management Console, or JConsole, is a management tool that connects to a running
Java HotSpot VM. You can trigger a heap dump by using jConsole. Refer to the following Oracle document for
more information:
Using JConsole to Monitor Applications
Oracle bundles the Java Heap Analysis Tool (jhat) with Java HotSpot VM 1.6. Therefore, if you want to analyze a
heap with jhat, you can install Java HotSpot VM 1.6 and use the jhat release provided. Refer to the following
Oracle document for more information:
Java Heap Analysis Tool
Oracle jVisualVM is another multipurpose tool that you can use to analyze heap dumps. Refer to the following
Oracle document for more information:

Server Memory Management 77

 System Administration Guide 9.0.5

Java VisualVM

Related information
Using JConsole to Monitor Applications
Java Heap Analysis Tool
Java VisualVM

Generic Tools for Heap Dump Generation

YourKit is a commercial product that provides many functions. You can use YourKit to connect to the JVM, analyze
the JVM, and trigger heap dumps. It also provides some very interesting heap dump analysis tools.
JProbe is another commercial product providing many capabilities, including heap dump analysis.
Guidewire development mainly uses YourKit with good success. Guidewire Support uses YourKit and several other
products like jVisualVM, IBM DTJF adapter and JProbe.

JVM Profiling
Java profilers are available for two main purposes:

Memory Identifies memory usage, and, more specifically, memory leaks due to referenced but unused objects.
profiling
CPU profiling Helps identify programmatic hot spots and bottlenecks. This analysis might help remove the corresponding
bottlenecks, thereby increasing performance.

Guidewire has used two profiling tools internally and found each to be of good quality. Both tools provide both
memory and CPU profiling:
• Guidewire recommends YourKit for memory profiling.
• Guidewire recommends JProfiler for CPU profiling.
To profile ClaimCenter, load the profiler agent into the ClaimCenter JVM either as it is starting ClaimCenter or by
attaching the profiler agent to a running JVM. Refer to the profiler documentation for instructions.

Large Object Analysis

Large Java objects cause an extra strain on the JVM for various reasons. If garbage collection analysis shows that
the JVM is allocating very large objects, investigate this further and understand the source of the objects.

78 chapter 4 ClaimCenter Server Administration

chapter 5

Geocoding, Catastrophe Search, and

Heat Maps

Geocoding is the process of assigning a latitude and longitude to an address. Guidewire supports geocoding in
ClaimCenter, PolicyCenter, and ContactManager. If enabled, ClaimCenter uses geocoding in producing ClaimCenter
catastrophe searches and heat maps.

Understanding Geocoding
The geocoding process assigns latitudes and longitudes to addresses. Software then uses geocoded addresses to
present users with geographic information, such as the distance between two addresses. All primary addresses in
ClaimCenter, PolicyCenter, and ContactManager are candidates for geocoding.

The Geocode Plugin Interface

To implement geocoding, ClaimCenter provides a default GeocodePlugin plugin interface. Implementations of the
plugin connect with specific external geocoding services, which provide geocode coordinates for specific addresses.
Typically, plugin implementations also use an external mapping service to calculate and return proximity
information, driving instructions, and maps. You enable the plugin implementation in Guidewire Studio and specify
the parameters for the implementation you choose.
ClaimCenter provides a fully functioning and supported GeocodePlugin implementation, the BingMapsPlugin
Gosu class. This plugin implementation connects to the Microsoft Bing Maps Geocode Service. If you intend to use
the BingMapsPlugin implementation, your organization must have a valid account with Microsoft.

Microsoft Bing Maps

Before you can use the default Bing Maps plugin implementation, your organization must have its own account,
login, and application key with Microsoft Bing Maps. To obtain these items, access the Bing Maps Dev Center.
You must set up a Bing Maps account and obtain an application key. After you create an application key, the
application name is arbitrary and there is no need for an application URL.

Geocoding, Catastrophe Search, and Heat Maps 79

 System Administration Guide 9.0.5

Working with Geocode Batch Processing

Guidewire implements geocode batch processing as a work queue. Geocode batch processing searches the database
for instances of the Address entity with the BatchGeocode property set to true and the GeocodeStatus property set
to none. The geocoding process submits qualifying addresses to your implementation of the GeocodePlugin plugin.
After the GeocodePlugin plugin adds geocode coordinates to an address, the geocoding process updates the address
in the database.

Geocode Status Typelist

The GeocodeStatus typelist defines the set of status codes returned from the default GeocodePlugin plugin
implementation. As the typelist is final, you cannot edit it. You access the GeocodeStatus typelist in Guidewire
Studio in the following location:
configuration→config→Metadata→Typelist
See also
• Integration Guide

Related references
“Geocode Writer Batch Processing” on page 118

Related information
Bing Maps Dev Center

Configuring Geocoding
Configuring geocoding involves the following tasks:
• Enabling your implementation of the GeocodePlugin plugin
• Setting geocoding feature parameters
• Scheduling the Geocode work queue
• Configuring the number of Geocode batch processing workers

Enabling the Geocode Plugin

By default, the base configuration GeocodePlugin plugin implementation uses the Bing Maps implementation.
Guidewire disables this plugin in the base configuration. You must enable the geocode plugin before you can use the
geocoding functionality. If you intend to use geocoding in multiple Guidewire applications, you must make these
changes in each application separately.

Scheduling the Geocode Plugin

By default, Guidewire does not schedule geocode batch processing in the base configuration. To schedule geocode
batch processing, you need to uncomment the relevant section in file scheduler-config.xml. Guidewire
recommends that you schedule the geocoding process to run during periods of minimal activity on the ClaimCenter
servers.

IMPORTANT Schedule geocode batch processing for ClaimCenter and ContactManager with sufficient processing
windows between runs to assure sufficient time for runs to fully process the work items in the work queues. If you
find duplicate work items in the work queues for the same address ID, extend the interval between runs.

Configuring the Number of Geocoding Batch Processing Workers

At the time you first start ClaimCenter, it is possible for your database to have many addresses to geocode,
especially if you imported many new addresses into your production database. A large number of new addresses can
cause the GeocodePlugin plugin implementation to take a long time to process these new addresses. Guidewire
80 chapter 5 Geocoding, Catastrophe Search, and Heat Maps
 System Administration Guide 9.0.5

recommends that you configure the geocoding process with a sufficient number of worker instances before you start
your production servers.
The default configuration specifies one worker instance. Worker instances pass addresses from the work queue to
the GeocodePlugin plugin implementation. Consider increasing the number of worker instances to improve
throughput. To further improve throughput, assign worker instances to run on multiple servers.
See also
• “Understanding Geocoding” on page 79

About Guidewire Geocoding Parameters

Configure geocoding features in the ClaimCenter user interface with the following parameters in config.xml.

Parameter Description
UseGeocodingInPrimaryApp Set to true to enable geocoding in the ClaimCenter user interface, such
as in assignment or user search screens.
The default is false.
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.
The default is false.
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 Guidewire applications that use
geocoding.
The default is false.
ProximitySearchOrdinalMaxDistance A distance that provides an approximate bound to improve
performance of an ordinal (nearest n) proximity search. This distance is
in miles, unless you set UseMetricDistancesByDefault to true. The
search can return results that are farther away than the distance
specified.
Set this parameter identically in Guidewire applications that use
geocoding.
This parameter has no effect on radius (within n miles or kilometers)
proximity searches or walking-the-group-tree-based proximity
assignment.
The default is 300.
ProximityRadiusSearchDefaultMaxResultCount The maximum number of results to return if performing a radius
(within n miles or kilometers) proximity search. This parameter has no
effect on ordinal (nearest n items) proximity searches. This parameter
does not have to match the value of the corresponding parameter in
other Guidewire applications.
The default is 1000.

Enable the Geocode Plugin

Procedure
1. In the ClaimCenter Project window, expand configuration→config→Plugins→registry.
2. Double-click GeocodePlugin to open it.
3. If the Disabled check box is checked, un-select the check box to enable the plugin.

Configuring Geocoding 81
 System Administration Guide 9.0.5

4. Ensure that the Class field specifies the Bing Maps implementation class:
gw.plugin.geocode.impl.BingMapsPluginRest
5. Under Parameters, specify the following:

applicationKey The application key that you obtained from Bing Maps.
geocodeDirectionsCulture The locale for geocoded addresses and routing instructions returned from Bing Maps. For
example, use the locale code ja-JP for addresses and instructions for Japan. The plugin uses en
-US if you do not specify a value. For a current list of codes that Bing Maps supports, refer to
the following web site
http://msdn.microsoft.com/en-us/library/cc981048.aspx

imageryCulture The language for map imagery. For example, use the language code ja for maps labeled in
Japanese. The plugin uses en if you do not specify a value. For a current list of codes that Bing
Maps supports, refer to the following web site
http://msdn.microsoft.com/en-us/library/cc981048.aspx

mapUrlHeight Height of maps, in pixels. The plugin uses 500 if you do not specify a value.
mapUrlWidth Width of maps, in pixels. The plugin uses 500 if you do not specify a value.

6. Save your changes.

Next steps
See also
• Integration Guide

Schedule Geocode Batch Processing Runs

About this task
By default, the schedule runs geocode batch processing at 1:30 AM daily. If you regularly add many new contacts,
especially in ContactManager, tune the schedule to match your expected daily load of new addresses.

Procedure
1. In Guidewire Studio, navigate to configuration→config→scheduler and open scheduler-config.xml for
editing.
2. Uncomment the following section in scheduler-config.xml file.

<ProcessSchedule process="Geocode">
<CronSchedule hours="1" minutes="30"/>
</ProcessSchedule>

Next steps
See also
• “The Work Queue Scheduler” on page 93
• “Understanding a Work Queue Schedule Specification” on page 93

Configure the Number of Worker Instances for Geocode Batch Processing

Procedure
1. In Guidewire Studio, navigate to configuration→config→workqueue and open work-queue.xml for editing.
2. Modify the number of worker instances in the following section in file work-queue.xml to meet your business
needs.

82 chapter 5 Geocoding, Catastrophe Search, and Heat Maps

 System Administration Guide 9.0.5

<work-queue workQueueClass="com.guidewire.pl.domain.geodata.geocode.GeocodeWorkQueue"
progressinterval="600000">
<worker instances="1"/>
</work-queue>

3. Update database statistics by running the Database Statistics batch process.

Next steps
See also
• “Worker Configuration” on page 98
• “Database Statistics Batch Processing” on page 114

Catastrophe Search and Heat Maps

Before you can see the Catastrophe Search screen and its catastrophe heap map, you must enable the use of heat maps
in Guidewire ClaimCenter.
In addition, if your installation of Guidewire ClaimCenter integrates with Guidewire PolicyCenter, you must enable
batch process CatastrophePolicyLocationDownload as well. This batch process retrieves policy locations for a
specific geographic area of interest from the policy system. The catastrophe heat map shows retrieved policies as
policy locations if PolicyCenter stores the addresses with geocode information.
Note: For information on using and configuring a geocoding service other than Microsoft Bing Maps, see the
Integration Guide.

Enable the Catastrophe Heat Map

Before you begin
You must obtain a license for the Bing Maps Ajax Control from Microsoft Corporation. Guidewire currently uses
version 6.3 of this software. Use the credential that you obtain from this license in the following procedure.

Procedure
1. Decide which geocoding service you want to use, then configure a geocoding plugin implementation to work
with that service.
If you use the Microsoft Bing Maps service, you can use the default geocoding plugin interface supplied with
ClaimCenter.
2. Enable your implementation of the geocode plugin.
3. In the ClaimCenterStudio Project window, expand configuration→config:
a. Double-click config.xml to open it.
b. Locate the following parameters and set them as shown:

<param name="HeatMapServiceTemplate" value="gw.api.heatmap.BingMap"/>

<param name="HeatMapCredential" value="Credential"/>

Set Credential to the value that you obtained during the licensing process for the Bing Maps Ajax
Control.
4. Save your changes.
5. Restart the application server.

Catastrophe Search and Heat Maps 83

 System Administration Guide 9.0.5

Enable the Catastrophe Policy Location Download Batch Process

Procedure
1. In the ClaimCenter Studio Project window, expand configuration→config→scheduler:
a. Double-click scheduler-config.xml to open it.
b. Remove any comments around the CatastrophePolicyLocationDownload configuration parameter. The
following default entry schedules the batch process to run every day at 2 a.m.

<ProcessSchedule process="CatastrophePolicyLocationDownload">
<CronSchedule hours="2"/>
</ProcessSchedule>

2. Depending on whether you are working in a development or production environment, do one of the following:

Environment type Action

Development Restart the server using the gwb stopServer and gwb runServer commands. You can optionally
environment load the catastrophe sample data supplied with ClaimCenter. This data enables you to see the
Catastrophe Search page and heat maps before you load any production claims and catastrophe
data.
Production Stop the application server. Then, repackage and redeploy the WAR or EAR file and restart the
environment server.

Next steps
See also
• “The Work Queue Scheduler” on page 93
• “Catastrophe Policy Location Download Batch Processing” on page 108
• Installation Guide

84 chapter 5 Geocoding, Catastrophe Search, and Heat Maps

chapter 6

Administering Batch Processing

ClaimCenter provides tools for configuring and managing various forms of batch processing. You can schedule
batch processing to run regularly or on demand.
See also
• “Batch Process Info” on page 349
• “Work Queue Info” on page 352
• Integration Guide

Overview of Batch Processing

ClaimCenter supports two modes of batch processing:
• Work queue
• Batch process

Work queue
A work queue operates on a batch of items in parallel. ClaimCenter distributes work queues across all servers in a
ClaimCenter cluster that have the appropriate role. In the base configuration, Guidewire assigns this functionality to
the workqueue server role.
A work queue comprises the following components:
• A processing thread, known as a writer, that selects a group (batch) of business records to process. For each
business record (a claim record, for example), the writer creates an associated work item.
• A queue of selected work items.
• One or more tasks, known as workers, that process the individual work items to completion. Each worker is a
short-lived task that exists in a thread pool. Each work queue on a cluster member shares the same thread pool.
By default, each work queue starts a single worker on each server with the appropriate role, unless configured
otherwise.
Work queues are suitable for high volume batch processing that requires the parallel processing of items to achieve
an acceptable throughput rate.

Administering Batch Processing 85

 System Administration Guide 9.0.5

Batch process
A batch process operates on a batch of items sequentially. Batch processes are suitable for low volume batch
processing that achieves an acceptable throughput rate as the batch process processes items in sequence. For
example, writers for work queues operate as batch processes because they can select items for a batch and write
them to their work queues relatively quickly.
See also
• “Server Roles” on page 141
• “Work Queues” on page 86
• “Batch Processes” on page 89
• Integration Guide

Work Queues
A work queue comprises the following components.

Writer A writer thread selects units of work for batch processing and writes their identities to a work queue.
Work A work queue is a database table that the writer loads with a batch of work items and from which workers check
queue out work items for processing.
Worker One or more worker tasks that check out work items from the work queue and process them to completion. By
default, each work queue starts a single worker on each cluster member with the workqueue role, unless
configured otherwise.

Starting the writer initiates a run of batch processing on a work queue. The batch is complete if the workers exhaust
the queue of all work items, except those that they failed to process successfully.

Work Queue Architecture

The following diagram illustrates the components of a work queue and how they function.

86 chapter 6 Administering Batch Processing

 System Administration Guide 9.0.5

YES

Wake Table empty?

Locate items
Sleep NO

Notify Workers Load table

Writer Server with ‘batch’ Role

Server A Server C
Server B

C C

A B

Wait for notification Check out item

Process item
NO

YES

Workers
Table empty?

Work Queue Writers

Whenever the writer thread awakes or starts on demand, it checks the work queue table for any work items that
remain from a prior batch. The specific configuration of each work queue determines how the work queue creates
and processes work items.
The following workflow examples provides a simple description of how ClaimCenter work queues operate.

Work Items Remaining

If work items remain from a previous batch, the following sequence of events occur:
1. The writer thread notifies the workers that they have work to process.
2. ClaimCenter terminates the writer thread.

No Work Items Remaining

If no work items remain from a previous batch, the following sequence of events occurs:
Work Queues 87
 System Administration Guide 9.0.5

1. The writer thread selects items for a new batch.

2. The writer writes the identifiers of the selected items to the work queue table.
3. The writer notifies the workers that they have work to process.
4. ClaimCenter terminates the writer thread.

Work Queue Workers

Typically, each work queues shares the standard work item table (StandardWorkQueue) for its work items. However,
a worker task operates only on work items that its associated writer inserts into the table. For example, suppose that
ClaimCenter distributes the Activity Escalation work queue across a Guidewire cluster, with six workers operating
on three different servers. Those workers work only on activity escalation items in the standard work item table.
Typically, you configure work queues for multiple workers. Thus, typically, some number of workers operate
throughout the day on work items in the standard work queue table.
At specified intervals (defined through the maxpollinterval attribute on worker in work-queue.xml), a worker
awakens and checks the work item table for work items from its associated writer. If a worker finds work items
available for processing, the worker checks out its quota from the work queue. For each item, the worker sets the
following attributes.

Status Set to checkedout.

The value of the Status attribute can be any one of the following:
• available
• checkedout
• failed
LastUpdateTime Set to the time at which the worker checks out the work item.

CheckedOutBy Set to the worker.

After it checks out a quota of work items, the worker task processes them sequentially. Whenever a worker
completes a work item successfully, it deletes the item from the table and begins to process the next item. The
standard work item table (StandardWorkQueue) is retireable, so successfully completed work items remain in the
table for historical reference.
Note: In rare cases, it is possible for ClaimCenter to notify a worker of work, but, the worker finds no work is
available after it awakens. For example, for small batch runs, a worker can check out all items in the batch with its
first check out quota of items. This action can occur between the time the writer notifies the workers and other
workers awaken. If a worker awakens and finds no work items, the worker goes back to sleep.

Work Queue Scheduling and Processing Intervals

A writer for a work queue starts at the interval specified in scheduler-config.xml. Typically, you schedule the
writer to start several times during the day or once at night. Access schedule configuration file schedule-
config.xml in Guidewire Studio at the following location:
configuration→config →scheduler
Worker tasks awaken much more frequently than their writers start. One writer awakens at least as frequently as a
specified maximum polling interval, if not more frequently.
You do not schedule worker tasks. Instead, they awaken in response to notification from the writer or upon
expiration of the polling interval. After a worker awakens, if there are work items to process, it processes up to the
number of batchsize items, as defined in work-queue.xml. If there are more items than the batch size to process,
the worker awakens another worker. This worker repeats the process of checking out work items and waking up
another worker if necessary, until maximum allowed number of workers are active.
You configure the number of workers, polling interval, and batch size in work-queue.xml. Access work queue
configuration file work-queue.xml in Guidewire Studio at the following location:

88 chapter 6 Administering Batch Processing

 System Administration Guide 9.0.5

configuration→config→workqueue
You can view and manage work queues from the Server Tools Work Queue Info screen in ClaimCenter, if you have
the appropriate administrative privilege.
See also
• “The Work Queue Scheduler” on page 93
• “Performing Custom Actions After Batch Processing Completion” on page 100
• “Work Queue Info” on page 352

Batch Processes
ClaimCenter distributes batch processes across all ClaimCenter cluster members that have the batch server role.
Each server with the batch role also has a batch process lease manager that acquires and manages the batch process
leases on that server. In this context, a lease represents a single run of a single batch process.
Available servers with the batch role compete for available batch processing leases. After a server acquires a lease,
that server runs the batch process to completion.
How aggressively the cluster servers compete with each other depends on how many batch processes each one is
individually already running. Those servers running fewer or no batch processes are more likely to acquire a new
batch process lease than other servers already busy running processes. It is possible to configure this behavior.
For scheduled batch processes, a scheduler component, running on a cluster member with the scheduler role,
decides to start a batch process according to the published schedule. The scheduler first creates a new lease for the
batch process in the database. All cluster members with the batch server role then compete to acquire that lease.
The cluster member that wins the competition starts the batch process.

The Batch Process Info Screen

Generally, a batch process runs to completion and then reports its result back to a log or to the administrative user
interface. You can view and manage batch processing from the Server Tools Batch Process Info screen in
ClaimCenter, if you have the appropriate administrative privilege. From this screen, you can view the batch process
schedule, if any, and start or stop a scheduled batch process.

Batch Process Caching

Batch processes that run concurrently on the same server share a common cache. The cache demands of each
process end up flushing the cache more frequently, so fewer cache hits occur for each process. That increases the
amount of physical reads from the relational database, thus degrading performance. Concurrent data change
exceptions can occur also if multiple batch processes (on the same or different servers) attempt to update the same
cached entity instances. This requires one or the other batch process to retry an item, leading to further performance
degradation.
See also
• “Working with Work Queue Writers and Batch Processes” on page 90
• “The Work Queue Scheduler” on page 93
• “Component Lease Management” on page 159
• “Batch Process Prioritization” on page 163
• “Batch Process Info” on page 349

Working with batch processing types in Studio

To access information about the ClaimCenter batch processing types, open the following files in Studio:
• BatchProcessType.ttx – Provides the name and codes for each batch processing type.
• work-queue.xml – Provides the name of the backing class and number of work instances for a processing type.
• scheduler-config.xml – Provides the schedule for any batch process type that is Schedulable.
Overview of Batch Processing 89
 System Administration Guide 9.0.5

The number of worker tasks is important if zero (0). Setting the number of worker tasks to 0 disables the work queue
as there are no workers to perform the work. To enable the work queue, set the number of workers to greater than
zero.

Working with Work Queue Writers and Batch Processes

You can run many batch processes, including writers for work queues, from ClaimCenter or from the command
prompt.

How to Run a Writer from the Work Queue Info Screen

It is possible to run a writer for a work queue from the Server Tools Work Queue Info screen. ClaimCenter enables the
Run Writer button on this screen for all work queue types that belong to the BatchProcessTypeUsage category
UIRunnable.
To access the Work Queue Info screen, you must have the internaltools permission. The Admin role has this
permission by default. Alternatively, if the EnableInternalDebugTools parameter is set to true in config.xml and
the server is running in development mode, all users can access the Work Queue Info screen.

How to Run a Batch Process from the Batch Process Info Screen
It is possible to run batch processes from the Server Tools Batch Process Info screen in ClaimCenter. ClaimCenter
enables the Run button on this screen for all batch process types that belong to the BatchProcessTypeUsage
category UIRunnable.
To access the Batch Process Info screen, you must have the internaltools permission. The Admin role has this
permission by default. Alternatively, if the EnableInternalDebugTools parameter is set to true in config.xml and
the server is running in development mode, all users can access to the Batch Process Info screen.

How to Terminate a Writer or Batch Process from the Command Prompt

It is possible to terminate some in-progress processes, including writers for work queues, from a command prompt.
To determine if it is possible to terminate an in-progress batch process, consult the reference topic for that particular
batch processing type. The information for each individual batch process includes whether it is a single phase or
multiphase process. You can only stop those processes listed as being multiphase.
Note: It is not possible to terminate a single phase batch process. Single phase processes run in a single
transaction. Thus, there is no convenient place to terminate the process.
See also
• “Work Queues and Batch Processes, a Reference” on page 103
• “Batch Process Info” on page 349
• “Work Queue Info” on page 352
• “Maintenance Tools Command” on page 418
• Integration Guide

Run a Writer from ClaimCenter

Start, or stop, a work queue from the Work Queue Info screen.

Before you begin

You must have the internaltools user permission to access the Work Queue Info screen.

90 chapter 6 Administering Batch Processing

 System Administration Guide 9.0.5

About this task

Note: You can run writers for work queues from either the Work Queue info screen or the Batch Process Info screen.

Procedure
1. Log in to ClaimCenter.
2. Press ALT+SHIFT+T to display the Server Tools tab.
3. Navigate to Work Queue Info.
4. Click Run Writer in the Actions column of the work queue that you want to run.

Run a Batch Process from ClaimCenter

Start, or stop, a batch process from the Batch Process Info screen.

Before you begin

You must have the internaltools user permission to access the Batch Process Info screen.

Procedure
1. Log in to ClaimCenter.
2. Press ALT+SHIFT+T to display the Server Tools tab.
3. Navigate to Batch Process Info.
4. Click Run in the Action column of the batch process that you want to run.

Run a Writer or Batch Process from the Command Prompt

Start a batch processing type using a maintenance_tools command option.

About this task

It is possible to run many batch processes, including writers for work queues, from a command prompt.

Procedure
1. Start the ClaimCenter server if it is not already running.
2. Open a command prompt.
3. Navigate to the following location in the ClaimCenter installation directory:

admin/bin

4. Run the following command:

maintenance_tools -password password -startprocess process

To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.
For the process value, specify a valid process code. For the process code for each batch processing type,
including writers for work queues, consult the reference topic for the individual batch processing type.

Working with Work Queue Writers and Batch Processes 91

 System Administration Guide 9.0.5

Next steps
See also
• “Work Queues and Batch Processes, a Reference” on page 103

Terminate a Writer or Batch Process from the Command Prompt

Stop a batch processing type using a maintenance_tools command option.

About this task

It is not possible to use following procedure to terminate the operation of the table_import command.

Procedure
1. Start the ClaimCenter server if it is not already running.
2. Open a command prompt.
3. Navigate to the following location in the ClaimCenter installation directory:

admin/bin

4. Run the following command:

maintenance_tools -password password -terminateprocess process

To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.
For the process value, specify a valid process code. For the process code for each batch processing type,
including writers for work queues, consult the reference topic for the individual batch processing type.

Next steps
See also
• “Work Queues and Batch Processes, a Reference” on page 103

Check Status of a Writer or Batch Process from the Command Prompt

Check the status of a batch process using a maintenance_tools command option.

About this task

It is possible to check the status of processes, including writer processes for work queues, from a command prompt.

Procedure
1. Start the ClaimCenter server if it is not already running.
2. Open a command prompt.
3. Navigate to the following location in the ClaimCenter installation directory:

admin/bin

4. Run the following command:

maintenance_tools -password password -processstatus process

92 chapter 6 Administering Batch Processing

 System Administration Guide 9.0.5

To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.
For the process value, specify a valid process code. For the process code for each batch processing type,
including writers for work queues, consult the reference topic for the individual batch processing type.

Result
For work queues, executing this command returns the status of the writer process. The command does not check
whether any work items remain in the work queue. Thus, it is possible for the process status to report as being
complete after the writer finishes adding items to the work queue. However, it is possible that there are work items
that need processing that remain in the work queue.

Next steps
See also
• “Work Queues and Batch Processes, a Reference” on page 103

The Work Queue Scheduler

The ClaimCenter scheduler launches many batch processes, including writer processes for work queues, according
to a schedule defined in scheduler-config.xml. Access this file in Guidewire Studio at the following location:
configuration→config→scheduler
The scheduler-config.xml file contains entries in the following format:

<ProcessSchedule process="process_code" env="environment">

<CronSchedule schedule_attributes/>
</ProcessSchedule>

The process attribute sets the process to run. The env attribute is an optional attribute that specifies the environment
in which the schedule definition for the process applies. The schedule_attributes value is a valid schedule
specification.
If needed, you can list multiple ProcessSchedule entries for the same process. The process then runs according to
each specified schedule. If you schedule a process to run while the same process is already running, then
ClaimCenter skips the overlapping process. If the scheduler-config.xml file does not list a process, then the
process does not run.
Generally, schedule the amount of time between batch process runs in hours as opposed to minutes. This is because
some batch processes require a lot of server resources. Schedule such processes to wake infrequently or at times that
the server is less busy, such as late at night or very early in the morning.
You may want to schedule some ClaimCenter batch processes to run periodically throughout the business day. For
example, the default configuration of ClaimCenter schedules the ActivityEsc batch process to run every 30
minutes. Exclude running such batch processes periodically during your nightly batch processing window. Instead,
wait until the end of the batch window to run them. For example, schedule the ActivityEsc batch process to run
every 30 minutes except during your nightly batch window. Alternatively, run such batch processes at prescribed
places in your chain of nightly batch process.
The ClaimCenter scheduler uses the ClaimCenter server time for reference.
See also
• “Understanding a Work Queue Schedule Specification” on page 93

Understanding a Work Queue Schedule Specification

The <CronSchedule> element in file scheduler-config.xml describes when ClaimCenter is to run the process.

The Work Queue Scheduler 93

 System Administration Guide 9.0.5

<CronSchedule schedule_attributes/>

Use this element to define a schedule_attributes value to specify the exact timing, such as once every hour or
every night at a certain time. The schedule_attributes value is a combination of one or more of the following
attributes:

Attribute Standard Values Default Example

seconds 0-59 0 seconds="0"

minutes 0-59 0 minutes="15"

hours 0-23 * hours="12"

dayofmonth 1-31 * dayofmonth="1"

month 1-12 or JAN-DEC * month="2"

dayofweek 1-7 or SUN-SAT ? dayofweek="1"

IMPORTANT If you do not provide a value for a defined schedule attribute, the scheduler uses its default value in
determining the work queue schedule. For example, if you do not specify a value for the hours attribute, the
scheduler assumes a value of * and ClaimCenter runs the work queue process every hour. Thus, Guidewire
recommends that you provide a value for each scheduler attribute. If you do not provide a value for a specific
attribute, carefully review that attribute's default value and determine if the default value meets your business
needs.

Useful Attribute Characters

Along with the standard values listed, there are some special characters that give you more flexible options.

Character Meaning
* Indicates all values. For example, minutes="*" means run the process every minute.
? Indicates no specific value. Used only for dayofmonth and dayofweek attributes. See the examples for clarification.
- Specifies ranges. For example, hour="6-8" specifies the hours 6, 7 and 8.
, Separates additional values. For example, dayofweek="MON,WED,FRI" means every Monday, Wednesday, and
Friday.
/ Specifies increments. For example, minutes="0/15" means start at minute 0 and run every 15 minutes.
L Specifies the last day. Used only for dayofmonth and dayofweek attributes. See the examples for clarification.
W Specifies the nearest weekday, use only with dayofmonth. For example, if you specify 1W for dayofmonth, and that
day is a Saturday, the trigger then fires on Monday the 3rd. You can combine this with L to schedule a process for
the last weekday of the month by specifying dayofmonth="LW".
# Specifies the nth day of the week within a month. For example, a dayofweek value of 4#2 means the second
Wednesday of the month (day 4 = Wednesday and #2 = the second Wednesday in the month).

These represent only some of the values that you can use for setting schedule.

Scheduler Examples
The following table lists a few examples of how to work with the <CronSchedule> element.

Example Description
<CronSchedule hours="10" /> Run every day at 10 a.m.

94 chapter 6 Administering Batch Processing

 System Administration Guide 9.0.5

Example Description
<CronSchedule hours="0" /> Run every night at midnight.
<CronSchedule minutes="15,45" /> Run at 15 and 45 minutes after
every hour.
<CronSchedule minutes="0/5" /> Run every five minutes.
<CronSchedule hours="0" dayofmonth="1" /> Run at midnight on the first day of
the month.
<CronSchedule hours="12" dayofweek="MON-FRI" dayofmonth="?" /> Run at noon every weekday (without
regard to the day of the month).
<CronSchedule hours="22" dayofmonth="L" /> Run at 10 p.m. on the last day of
every month.
<CronSchedule hours="22" dayofmonth="L-2" /> Run at 10 p.m. on the second-to-last
day of every month.
<CronSchedule minutes="3" hours="8-18/2" dayofweek="1-5" dayofmonth="?"/> Run 3 minutes after every other
hour, 8:03 a.m. to 6:03 p.m.,
Monday through Friday.
<CronSchedule minutes="*/15" hours="0-8,18-23"/> Run every 15 minutes after the hour,
12:15 a.m. to 8:45 a.m. and 6:15
p.m. to 11:45 p.m.
<CronSchedule hours="0" dayofmonth="6L" /> Run at midnight on the last Friday of
the month.
<CronSchedule hours="4" dayofmonth="4#2" /> Run at 4 a.m. on the second
Wednesday of the month.

The Quartz Enterprise Job Scheduler

These characters represent only some of the values that you can use for setting a schedule. Guidewire bases the
ClaimCenter scheduler on the open source Quartz Enterprise Job Scheduler. The scheduler therefore uses the same
specification for schedule attributes that Quartz uses. To determine the exact Quartz version, check the filename of
the Quartz JAR file in ClaimCenter/admin/lib.

Related information
Quartz Documentation

Determine If It Is Possible to Schedule a Batch Process

Use the Batch Process Info screen to determine if it is possible to schedule a batch process.

About this task

It is possible to schedule many batch processes, including work queue writers. It is not possible, however, to
schedule all batch processes.

Procedure
1. Log into ClaimCenter as an administrative user.
2. Press ALT+SHIFT+T to access Server Tools.
3. Navigate to the Batch Process Info screen.
4. Select Schedulable from the processes drop-down filter.

The Work Queue Scheduler 95

 System Administration Guide 9.0.5

ClaimCenter displays only those batch processes, including work queue writers, that it is possible to schedule
in file scheduler-config.xml.

View a Batch Process Schedule in ClaimCenter

Review information in the Batch Process Info screen.

Procedure
1. Log in to ClaimCenter as an administrative user.
2. Press ALT + SHIFT + T to access Server Tools.
3. Navigate to the Batch Process Info screen.
4. Click the Next Scheduled Run column header to sort processes by schedule.
If there is no current schedule for a process, the Next Scheduled Run field is blank.

Scheduling Batch Processes for Specific Environments

You can define a schedule for each batch process for different environments. To specify an environment for the
process schedule, include the env attribute on the <ProcessSchedule> element in file scheduler-config.xml.

<ProcessSchedule process="process_code" env="environment">

<CronSchedule schedule_attributes/>
</ProcessSchedule>

In this way, you can have different results for batch processing based on environment.

Disabling the ClaimCenter Scheduler

It is possible to disable the internal scheduler by setting the SchedulerEnabled configuration parameter to false in
file config.xml. If you do so, then you need to implement your own mechanism for running ClaimCenter batch
processes. For example, you can use your own scheduling application to trigger batch processing execution along
with one of the following:
• The startBatchProcess method on the MaintenanceToolsAPI web service
• The maintenance_tools -startprocess process command option

Configuring Work Queues

In working with work queues, there are multiple general areas that you can configure.

Configuration area Configuration file More information

Work queue scheduling scheduler-config.xml “The Work Queue Scheduler” on page 93

Workers and work queues work-queue.xml “The Work Queue Configuration File” on page 96
Work queue configuration parameters config-xml Configuration Guide

The Work Queue Configuration File

You may want to modify the configuration of Guidewire-provided work queues to improve performance. You
configure attributes of a work queue and its workers in file work-queue.xml. For custom work queues, you must
modify work-queue.xml to enable your work queue to operate.
File work-queue.xml contains one top-level element, which is <work-queues>. This element has one required
attribute, defaultServer. In the base configuration, Guidewire sets the value of this attribute to workqueue.

96 chapter 6 Administering Batch Processing

 System Administration Guide 9.0.5

<work-queues xmlns="http://guidewire.com/work-queue" defaultServer="#workqueue">

Note: The hash mark in front of workqueue (#workqueue) indicates that the value that follows the hash mark is a
server role and not a server ID.
Attribute defaultServer requires a value. There is no default. The ClaimCenter server refuses to start if you do not
provide a value for this attribute. The server also refuses to start if you set defaultServer to a role that does not
exist in <registry> element in config.xml.

Work Queue Definitions

Within the top-level <work-queues> element in work-queue.xml, use subelement <work-queue> to define
individual work queues.

<work-queue workQueueClass="string" progressinterval="decimal">

<worker instances="integer" throttleinterval="decimal" env="string" server="string"/>
</work-queue>

The <work-queue> subelement has attributes to configure a named work queue in general. The <worker>
subelement has attributes to configure worker tasks on specific servers. You can declare as many workers as you
want for a work queue by specifying on which servers the workers run.
Access work-queue.xml in Guidewire Studio at the following location:
configuration→config →workqueue
See also
• “General Work Queue Configuration” on page 97
• “Worker Configuration” on page 98

General Work Queue Configuration

The <work-queue> element in work-queue.xml contains attributes for configuring the general characteristics of a
work queue.

Attribute Description
Required attributesdon't
progressinterval The progressinterval value is the amount of time, in milliseconds, that
ClaimCenter allots for a worker to process the number of batchsize work
items. If the time a worker has held a batch of items exceeds the value of p
rogressinterval, then ClaimCenter considers the work items to be
orphans. ClaimCenter reassigns orphaned work items to a new worker
instance. The progressinterval value must be greater than the time to
process the slowest work item, or that work item never completes.
Guidewire recommends that you set the progressinterval value greater
than the processing time for an entire batchsize of work items:
• If a worker takes more time than the time specified by progressinterv
al to processes its assigned work items, ClaimCenter reverts the
remaining work items to available from checkedout.
• If many worker batches take longer than the time specified by progres
sinterval, the repeated checking out and reverting to available of
work items can have a negative impact on performance.

Configuring Work Queues 97

 System Administration Guide 9.0.5

Attribute Description
workQueueClass (Required) The workQueueClass value must be one of the following:
• A Guidewire-provided work queue class listed in the base configuration
version of work-queue.xml
• A custom work queue class derived from Gosu class WorkQueueBase
You cannot configure Guidewire-provided batch processes or custom batch
processes derived from the Gosu class BatchProcessBase.
Optional attributes
blockWorkersWhenWriterActive If the work queue workers start execution before the work queue writer
completes writing work items to the work queue, it can possibly cause
performance issues under certain circumstances.
If set to true, ClaimCenter blocks the work queue workers from acquiring
new work items until the writer completes writing work items to the
queue. After the writer completes writing any new work items, the workers
automatically start acquiring work items again.
The default is false. Only enable this attribute for the work queues for
which you require this capability. Guidewire recommends that you
consider setting this attribute to true if the work queue writer can run for
extensive periods of time due to the work load generated.
logRetryableCDCEsAtDebugLevel If the value of logRetryableCDCEsAtDebugLevel is set to true for a work
queue, ClaimCenter logs any retryable Concurrent Data Change Exception
(CDCE) at the DEBUG level. The log message includes a prepended string to
indicate that the error is non-fatal.
ClaimCenter logs any CDCE that pushes the retry count over the value of re
tryLimit, or the value of workItemRetryLimit if retryLimit is not set, at
the ERROR level.
retryInterval How long in milliseconds to wait before retrying a work item that threw an
exception. The default value is 0, meaning ClaimCenter retries processing
the item immediately.
retryLimit The number of times ClaimCenter retries a work item that threw an
exception or that became an orphan for this work queue.
If you do not specify a retryLimit value for a work queue, ClaimCenter
uses the value of the WorkItemRetryLimit configuration parameter in con
fig.xml as the default value.
IMPORTANT: Guidewire generally recommends that you increase, never
decrease, the number of retries for a work queue.

Worker Configuration
The use of the <worker> element in work-queue.xml is optional. However, in actual practice, it is necessary for
there to be at least one <worker> element for each <work-queue> element for the work queue to operate properly.
The <worker> element contains an instances attribute that has a default value of 1. Without a <worker> element to
provide this default, the processing logic does not allocate any workers for the work queue.
All of the following attributes are optional.

Attribute Description
instances The number of workers to create. By default, ClaimCenter sets the values of this attribute to 1.
If a worker wakes up and detects work items, it checks out those work items from the work queue. If
there are more work items than the value specified by the batchsize attribute, the worker starts another
worker. Each new worker checks out up to the maximum batchsize number of work items. If there are
more work items remaining, the new worker starts another worker. The creation of workers continues

98 chapter 6 Administering Batch Processing

 System Administration Guide 9.0.5

Attribute Description
until the number of workers reaches the maximum limit of workers as specified by the instances
attribute.
maxpollinterval How often a worker wakes up automatically and queries for work items, even if the worker receives no
notification. You might need to increase the value of maxpollinterval to prevent excessive numbers of
queries for work items. The default value of maxpollinterval is 60,000 milliseconds.
throttleinterval The delay between processing work items in milliseconds. The value controls how long the process
sleeps. A value of 0 (zero) means worker tasks process work items as rapidly as possible. To reduce the
CPU load, set the value of throttleinterval to a positive non-zero value.
batchsize How many work items the worker attempts to check out while searching for more work items. Larger
batch sizes are more efficient, but might not result in good load distribution. The default value for batchs
ize is 10.

env The environment in which this particular worker is active.

server The serverid of the server on which this particular worker is active.

See also
• For information about the definition of the env and the serverid values in the cluster registry in config.xml,
see “Understanding the Configuration Registry Element” on page 46.

Worker Task Management

An executor manages the worker tasks on each cluster server with the appropriate role. In the base configuration,
Guidewire assigns this functionality to the workqueue server role. Each server with the worqueue role creates one
executor for each work queue on that server.
Each work queue executor periodically creates a worker. (The executor can also create a worker upon receiving a
notification from the writer.) This worker checks the work queue for items to process. If necessary, the initial worker
creates an additional worker if there is more work to process than it can handle. This new worker can also create a
worker if there is still more work to process. After there is no more work to process, all active workers stop.
It is possible to control the maximum number of workers, for all work queues on a server, by setting the value of
configuration parameter WorkQueueThreadPoolMaxSize in config.xml. It is possible to set this value individually
on each ClaimCenter server in the cluster.
See also
• “General Work Queue Configuration” on page 97
• “Worker Configuration” on page 98
• “Work Queues and Server Roles” on page 99
• Configuration Guide

Work Queues and Server Roles

In the base configuration, Guidewire assigns work queue functionality to servers with the workqueue role. File
work-queue.xml associates the workequeue server role with the application work queue functionality.

<work-queues xmlns="http://guidewire.com/work-queue" defaultServer="#workqueue" />

Note: The hash mark in front of workqueue (#workqueue) indicates that the value that follows the hash mark is a
server role and not a server ID.
The workqueue role is merely the default role, however. You are free to create and assign new work queue
management roles. You can also use server roles to enable or disable certain work queues on a specific ClaimCenter
server.

Configuring Work Queues 99

 System Administration Guide 9.0.5

Defining a New Work Queue Role

You define server roles using the roles attribute on the <registry> element in file config.xml. In the base
configuration, Guidewire defines the following server roles:

<registry roles="batch, workqueue, scheduler, messaging, startable, ui" />

To add a specialized work queue role, say, one to use in managing activity work queues, you need merely to add the
new server role to the list of roles:

<registry roles="batch, workqueue, activityworkqueue, scheduler, messaging, startable, ui" />

See also
• “Defining a New Server Role” on page 50

Assigning a Work Queue to Specific ClaimCenter Cluster Servers

Suppose, for example, that you want to assign the management of the activity work queues in the ClaimCenter
cluster to a subset of the cluster servers with the activityworkqueue role. By default, ClaimCenter distributes all
other work queues to those servers with the default workqueue role.
For example, in file work-queue.xml, you define the following:

<?xml version="1.0"?>
<work-queues xmlns="http://guidewire.com/work-queue" defaultServer="#workqueue">
<work-queue workQueueClass="com.guidewire.pl.domain.escalation.ActivityEscalationWorkQueue" … >
<worker server="#activityworkqueue"/>
</work-queue>
<work-queue workQueueClass="com.guidewire.pl.domain.geodata.geocode.GeocodeWorkQueue" … >
<worker/>
</work-queue>
</work-queues>

In this example:
1. If a server has the workqueue role only, then that server:
a. Starts an executor for the GeocodeWorkQueue work queue.
b. Does not start an executor for the ActivityEscalationWorkQueue work queue.
2. If a server has the activityworkqueue role only, then that server:
a. Starts an executor for ActivityEscalationWorkQueue work queue.
b. Does not start an executor for the GeocodeWorkQueue work queue.
3. If a server has both the activityworkqueue and workqueue roles, then that server starts executors for both
work queues.
4. If a server has neither the activityworkqueue nor the workqueue role, then the server does not start an
executor for either of these work queues.
See also
• “Assigning Server Roles to ClaimCenter Cluster Servers” on page 50

Performing Custom Actions After Batch Processing Completion

You can use Process Completion Monitor batch processing to launch custom actions after a work queue or batch
process completes a batch of items. For example, you might want to start the writer of a follow-on work queue
during nightly batch processing.
Process Completion Monitor batch processing runs at schedulable intervals and examines the ProcessHistory table
for all completed work queues and batch processes.
100 chapter 6 Administering Batch Processing
 System Administration Guide 9.0.5

For each completed work queue that it finds, Process Completion Monitor:
• Determines if all the work items in that work queue have either completed or failed.
• Calls the IBatchCompletedNotification plugin implementation on a process if the process is complete and has
no remaining available or checked-out work items.
• Sets ProcessHistory.NOTIFICATIONSENT to true to invoke the IBatchCompletedNotification plugin
implementation a single time only for any given process.
The IBatchCompletedNotification interface has a completed method that you can override to perform specific
actions if a work queue or batch process finishes a batch of work. The parameters of the completed method are the
ProcessHistory entity and the number of failed items. ClaimCenter considers work queue processing as complete
if no work items remain on the queue, other than work items that failed. ClaimCenter considers a batch process as
complete if the process stopped and its process history is available.
See also
• “Schedule the Process Completion Monitor Batch Process” on page 101
• “Implement the IBatchCompletedNotification Interface” on page 101
• “Register a Custom Batch Notification Plugin” on page 102
• “Process Completion Monitor Batch Processing” on page 121

Schedule the Process Completion Monitor Batch Process

Process Completion Monitor batch processing runs at schedulable intervals and examines the ProcessHistory table
for all completed work queues and batch processes.

About this task

In the base configuration, Guidewire does not schedule the Process Completion Monitor batch process. To enable
this batch process, you need to add the batch process to file scheduler-config.xml.

Procedure
1. In the ClaimCenterStudio Project window, expand configuration→config→scheduler.
a. Open scheduler-config.xml.
b. Add the following <ProcessSchedule> element:

<ProcessSchedule process="ProcessCompletionMonitor">
<CronSchedule minutes="*/5"/>
</ProcessSchedule>

2. Save your changes.

Next steps
See also
• “Understanding a Work Queue Schedule Specification” on page 93

Implement the IBatchCompletedNotification Interface

The Process Completion Monitor calls the IBatchCompletedNotification plugin implementation on a process if
the process is complete and has no remaining available or checked-out work items.

Procedure
1. In the ClaimCenterStudio Project window, expand configuration→gsrc.

Performing Custom Actions After Batch Processing Completion 101

 System Administration Guide 9.0.5

2. Do one of the following:

• If a package for your plugin implementation classes already exists within gsrc, navigate to that package, then
skip to step 6.
• If a package for your plugin implementation classes does not exist, continue to step 4.
3. Right-click gsrc, then click New→Package.
4. Enter a package name, such as workqueue.
5. Right-click your implementation class package and click New→Gosu Class.
6. Enter the name IBatchCompletedNotification for the gosu class.
7. Click OK.
8. Define your Gosu class, using the following framework:

package myCompany.plugin.workqueue
uses gw.plugin.workqueue.IBatchCompletedNotification

class IBatchCompletedNotification implements IBatchCompletedNotification {

construct() { }

override function completed(batch : ProcessHistory, numFailed : int) {

//do something

return
}
}

9. Save your work.

Register a Custom Batch Notification Plugin

After you create your IBatchCompletedNotification plugin implementation, you need to register the plugin with
ClaimCenter.

Procedure
1. In the ClaimCenterStudio Project window, expand configuration→config→Plugins.
2. Right-click registry and click New→Plugin.
3. In the Plugin dialog, enter IBatchCompletedNotification for the name of your plugin.
4. In the Plugin dialog, click …
5. In the Select Plugin Class dialog, type IBatchCompletedNotification and select the IBatchCompletedNotification
interface.
6. In the Plugin dialog, click OK.
Studio creates a GWP file under Plugins→registry with the name that you entered.
7. Click the Add Plugin icon and select Add Gosu Plugin.
8. For Gosu Class, enter your class, including the package.
9. Save your changes.

102 chapter 6 Administering Batch Processing

 System Administration Guide 9.0.5

Next steps
See also
• Configuration Guide

Troubleshooting Work Queues

It is possible for a work queue worker to encounter a problem that causes it to fail, before the worker completes all
the items it checked out from the queue. For example, it is possible for a server to die, killing its workers in the
middle of processing. This action can result in orphan work items. A work item becomes an orphan if a worker has
an item checked out but does not complete processing the item within an allotted amount of time. The
progressinterval attribute on the <worker> element in work-queue.xml defines this time span.
Workers treat orphans just as they do available items. The next worker that encounters the orphan item in the table
adopts it for processing and resets the LastUpdateTime, CheckedOutBy, and Status fields on the orphan work item.
If a work queue is experiencing a large number of orphans, review log files to locate timeouts during processing. For
example, a timeout can occur while a worker waits for an external server to return a value. If the log contains these
type of timeouts, increase the progressinterval value for the work queue in work-queue.xml to give workers
more processing time.
Sometimes, a problem inherent in the item itself causes the processing of the item to fail. For example, a batch
process throws an exception. In such cases, the worker stops processing the item and goes on to the next. The item
becomes an orphan and the next worker attempts to process it. In this way, a work queue attempts to process each
item multiple times up to a limit configured for the work queue. If a work item exceeds the limit of processing
attempts, ClaimCenter changes the status of the work item to failed. Workers ignore items with a status of failed
and no longer attempt to process them.
See also
• “Purge Failed Work Items Batch Processing” on page 123

Work Queues and Batch Processes, a Reference

In the base configuration, ClaimCenter provides a number of work queues and batch processes.
See also
• “Working with Work Queue Writers and Batch Processes” on page 90
• “Terminate a Writer or Batch Process from the Command Prompt” on page 92
• “The Work Queue Scheduler” on page 93
• “Unused and Internal Batch Processes” on page 130
• “Batch Process Info” on page 349
• “Work Queue Info” on page 352

Activity Escalation Batch Processing

Code ActivityEsc

Categories UIRunnable, Schedulable

Implementation Work queue

Workers 0
Schedule Every 30 minutes
Class ActivityEscalationWorkQueue.java

Troubleshooting Work Queues 103

 System Administration Guide 9.0.5

Activity Escalation batch processing finds activities that meet certain escalation criteria and marks the activity for
escalation. The batch processing logic looks for activities that meet each of the following criteria:
• The activity has an escalation date.
• The escalation date is prior to today’s date.
• ClaimCenter has not previously escalated the activity.
If Activity Escalation batch processing finds an activity that meets all the criteria, it marks the activity as escalated
and calls the activity escalation rules to determine any actions.
If you set your escalation deadline in days, then there is no reason to run activity escalation more than daily.
However, if your escalation deadline is shorter, then run this process more frequently to take action on overdue
activities in a timely manner. By default, ClaimCenter runs Activity Escalation batch processing every 30 minutes.
As indicated, you can change this schedule as needed.
By default, Guidewire disables Activity Escalation batch processing the base configuration by setting the number of
workers in work-queue.xml to 0. You must set the number of workers in this file to 1 or more to be able to run this
process.
See also
• “Configuring Work Queues” on page 96
• Application Guide
• Configuration Guide
• Rules Guide

Address Delete Batch Processing

Code AddressDelete

Implementation Work queue

Schedule Not schedulable
Class AddressDeleteWorkQueue.java

AddressDeleteWorkQueue is an internal work queue that ClaimCenter uses to delete orphaned addresses. During
every bundle commit, ClaimCenter identifies addresses that are potentially orphaned as a result of that bundle
commit. Potentially orphaned addresses fall into the following categories:
• It is a newly inserted address that does not have any entity pointing to it.
• It is the original address on an entity, which now contains an updated address.
For each identified potential orphan, the work queue creates an AddressDeleteWorkItem work item and associates
it with public ID of the address. As the work queue processes a work item, it attempts to delete the corresponding
address row from the Address table. If there are any remaining foreign key references to the address from any other
table, the delete operation fails silently. The work queue then continues to process any remaining work items.
During a bundle commit, ClaimCenter calls a writer that creates the actual work items. The writer creates the work
items such that they only become available for processing one minute after creation, by default. This delay gives a
user time to associate a newly orphaned address with a different entity, if desired. It is possible to configure this time
delay through configuration parameter AddressDeletionDelay in file config.xml.
See also
• Configuration Guide

Aggregate Limit Calculations Batch Processing

Code AggLimitCalc

104 chapter 6 Administering Batch Processing

 System Administration Guide 9.0.5

Categories APIRunnable, UIRunnable

Implementation Work queue

Schedule Not schedulable
Class RebuildAggLimitsWorkQueue.java

Aggregate Limit Calculations batch processing forces a recalculation of the aggregate limits stored in the
ClaimCenter database. (An aggregate limit is the maximum financial amount that an insurer must pay on a policy or
coverage during a given policy period.) The process then repopulates the database tables with this updated data. Run
Aggregate Limit Calculations batch processing only if you encounter consistency check failures and cannot identify
the reason for the inconsistency.
By default, Guidewire sets the number of workers in work-queue.xml to 2 in the base configuration. However,
Guidewire recommends that you use substantially more workers with Aggregate Limit Calculations batch
processing. Using just a few workers in a large database can take a very long time.
The optimal number of workers to use varies according to the available hardware and the volume of the data
involved. It is also possible to allocate work queue workers to several different ClaimCenter servers rather than
simply increasing the number of workers on a single server.
You can run Aggregate Limit Calculations batch processing in the following ways:
• From the ClaimCenter Server Tools Batch Process Info screen available to administrators.
• From a command prompt using the maintenance_tools -rebuildagglimits command option. If using the
maintenance_tools command, the following command options are also useful:

-forceall Use to mark all aggregate limits as invalid to force a rebuild.

-startprocess Use to monitor and review the progress of this process.
-processstatus use to review the process execution after completion.

See also
• “Run a Writer or Batch Process from the Command Prompt” on page 91
• “Configuring Work Queues” on page 96
• “Maintenance Tools Command” on page 418

Archive Batch Processing

Code Archive

Categories APIRunnable, UIRunnable, Schedulable

Implementation Work queue

Schedule Once a day, at 2:20 a.m.
Class ArchiveWorkQueue.java

Archive batch processing archives claims. For a claim to be eligible for archiving, the server time must have reached
the Claim.DateEligibleForArchive date for the claim.
Archive batch processing makes large changes to database tables. After running Archive batch processing,
Guidewire recommends that you update database statistics. Updating database statistics enables the optimizer to pick
better queries based on more current data.

Work Queues and Batch Processes, a Reference 105

 System Administration Guide 9.0.5

See also
• “Understanding Database Statistics” on page 279
• Application Guide
• Integration Guide

Archive Reference Tracking Sync

Code ArchiveReferenceTrackingSync

Categories Schedulable, UIRunnable

Implementation Work queue

Schedule Not scheduled
Class ArchiveReferenceTrackingSyncWorkQueue.java

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.
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 the Configuration Guide.

Bulk Invoice Escalation Batch Processing

Code BulkInvoiceEsc

Categories APIRunnable, UIRunnable, Schedulable

Implementation Batch process

Stoppable No (single phase process)
Schedule Twice a day, at 6:05 a.m. and 6:05 p.m.
Dependency Run “T-accounts Escalation Batch Processing” on page 127 batch processing before running Bulk Invoice
Escalation.
Class BulkInvoiceEscalationMonitor.java

Bulk Invoice Escalation batch processing updates bulk invoices that meet the following criteria:
• A status of Awaiting submission
• A send date of the current date or later
This process transitions the status of each retrieved bulk invoice to Requesting. It also escalates all the checks
associated with the items on the invoice to Submitting status, as long as their PendEscalationForBulk fields are
true.

Bulk Invoice Submission Batch Processing

Code BulkInvoiceSubmission

Categories UIRunnable

Implementation Work queue

Schedule Not schedulable

106 chapter 6 Administering Batch Processing

 System Administration Guide 9.0.5

Class BulkInvoiceWorkQueue.java

Bulk Invoice Submission batch processing processes bulk invoice items for bulk invoice submission.
Processing each item consists of creating the placeholder check on that item's associated claim. After the approval of
a bulk invoice, Bulk Invoice Submission batch processing runs against the bulk invoice and creates a work item for
each bulk invoice item. Then, batch processing workers pick up each item and process that work item's bulk invoice
item.
Note: If a bulk invoice remains in the PendingItemValidation status and all workers have finished, run the Bulk
Invoice Submission batch process again.

Bulk Invoice Workflow Monitor Batch Processing

Code BulkInvoiceWF

Categories UIRunnable, Schedulable

Implementation Work flow

Schedule Every 30 minutes
Class BulkInvoiceWorkflowMonitor.java

Bulk Invoice Workflow Monitor batch processing transitions the status of each bulk invoice to one of the following:
• Awaiting submission – The bulk invoice contains only approved checks.
• Invalid bulk invoice – The bulk invoice contains rejected checks.

Bulk Purge Batch Processing

Code BulkPurge

Categories UIRunnable, Schedulable

Implementation Work queue

Schedule Once a day, at 2:00 a.m.
Class BulkPurgeWorkQueue.java

Bulk Purge batch processing deletes records through table deletes and by notifying the IArchiveSource plugin
implementation to delete archived claims. This process looks for ClaimInfo objects marked as retired and then
traverses the archive domain graph to delete entities, presumably already retired, related to the retired claim.
See also
• “Purging Claim Data” on page 268

Catastrophe Claim Finder Batch Processing

Code CatastropheClaimFinder

Categories UIRunnable, Schedulable

Implementation Batch process

Stoppable No (single phase process)
Schedule Once a day, at 4:30 a.m.
Class CatastropheClaimFinderBatch.java

Work Queues and Batch Processes, a Reference 107

 System Administration Guide 9.0.5

Catastrophe Claim Finder batch processing finds possible claims related to a catastrophe. For each claim that it find,
Catastrophe Claim Finder creates an activity to review the claim. The purpose of the activity is to determine if there
is an association between the claim and the catastrophe.
By default, this work queue operates on claims that meet the following criteria:
• The claim must not be already associated with a catastrophe.
• The claim loss date must be within the effective date range of the catastrophe.
• The claim loss type and loss cause must match the coverage perils for the catastrophe.
• The claim must not have skipped or completed the catastrophe_review activity.
• The claim must be active (not retired).
You can modify which claims the work queue operates on by changing the findClaims() method in
GWCatastropheEnhancement.gsx. Access this enhancement in Studio at configuration→Classes→gw→entity.

Catastrophe Policy Location Download Batch Processing

Code CatastrophePolicyLocationDownload

Categories Not enabled

Implementation Batch process
Stoppable No (single phase process)
Schedule Not scheduled
Dependencies Requires integration with a policy administration system (PAS)
Class CatastrophePolicyLocationDownload.gs

IMPORTANT Catastrophe Policy Location Download batch processing requires integration with a policy
administration system. If that policy administration system is not Guidewire PolicyCenter, you must modify the
batch processing code to work with that system. Guidewire strongly recommends that you modify Gosu class
CatastrophePolicyLocationDownload rather than base class CatastrophePolicyLocationDownloadBase.

Catastrophe Policy Location Download batch processing looks for catastrophes for which the last modified date is
later than the date of the last download of policy locations. For each catastrophe that qualifies, the process updates
the policy locations in the modified area in two phases:
1. Location Query Phase – Queries the policy administration system for locations within the area of interest
through the PolicyLocationsSearchAPI web service that PolicyCenter publishes
2. Claim Matching Phase – Matches policy locations downloaded from the policy administration system with
policies on claims that already are in ClaimCenter
Note: Some, possibly many, policy locations can fail to match existing claims. The usual case is that there are
many more policy locations than claims in an area of interest.

Scheduling Catastrophe Policy Location Download Batch Processing

By default, Guidewire disables Catastrophe Policy Location Download batch processing in the base configuration.
Generally, you want to schedule it to run regularly on a daily cycle. The process can take a long time to complete,
depending on the number of areas of interest, the size of the areas, and the number of locations within them. For
performance reasons, schedule the process to run during a time of day in which the use of ClaimCenter is low, such
as late at night.
See also
• “Catastrophe Search and Heat Maps” on page 83
• Application Guide

108 chapter 6 Administering Batch Processing

 System Administration Guide 9.0.5

• Integration Guide

Claim Contacts Calculations Batch Processing

Code ClaimContactsCalc

Categories APIRunnable, MaintenanceOnly

Implementation Batch process

Stoppable Yes (multi-phase process)
Schedule Not schedulable
Class ClaimContactsCalculationBatchProcess.java

IMPORTANT You can run Claim Contacts Calculations batch processing only if the ClaimCenter server is in
maintenance mode.

In the base configuration, ClaimCenter de-normalizes several contact fields into different objects for performance
reasons. Claim Contacts Calculations batch processing recalculates the denormalization fields in case the fields ever
fall out of synchronization.
This process updates the following fields:
• Exposure.ClaimantDenorm
• Claim.ClaimantDenorm
• Claim.InsuredDenorm
• CheckPayee.PayeeDenorm
• Recovery.PayerDenorm
Only run this process if you encounter consistency check failures. The server must be at the maintenance run level to
run Claim Contacts Calculations. You cannot run this process from the ClaimCenter user interface or schedule the
process. You can only run Claim Contacts Calculations by calling MaintenanceToolsAPI.
See also
• “Place the Server in Maintenance Mode” on page 63
• “Run a Writer or Batch Process from the Command Prompt” on page 91

Claim Exception Batch Processing

Code ClaimException

Categories APIRunnable, UIRunnable, Schedulable

Implementation Work queue

Schedule Once a day, at 2:00 a.m.
Class ClaimExceptionMonitorWorkQueue.java

Claim Exception batch processing runs claim exception rules on the following types of claims:
• The claim contains updates since the process last ran.
• The exposures, transactions, claim contacts, claim contact roles, or matters associated with the claim contain
updates since the process last ran.
Claim Exception batch processing also runs claim exception rules on claims created since Claim Exception
processing last run.

Work Queues and Batch Processes, a Reference 109

 System Administration Guide 9.0.5

Configuration parameter SeparateIdleClaimExceptionMonitor controls whether Idle Claim Exception and Claim
Exception run independently or together. If SeparateIdleClaimExceptionMonitor is false, then Idle Claim
Exception and Claim Exception run claims concurrently through claim exception rules for recently modified and
idle claims.
ClaimCenter sets configuration parameter SeparateIdleClaimExceptionMonitor to true in the default
configuration. If you set the parameter to false, also disable the schedule for running Idle Claim Exception batch
processing.
Because running claim exceptions is processing intensive, Guidewire recommends that you schedule Claim
Exception batch processing during periods of low activity.
See also
• “Idle Claim Exception Batch Processing” on page 119
• Rules Guide

Claim Health Calculations Batch Processing

Code ClaimHealthCalc

Categories APIRunnable, UIRunnable, Schedulable

Implementation Batch process

Stoppable No (single phase process)
Schedule Not scheduled
Class ClaimHealthCalculatorBatch.gs

Claim Health Calculations batch processing calculates health indicators and metrics for all claims for which no
calculated metrics exist. The value of MaxClaimResultsPerClaimHealthCalcBatch configuration parameter in
config.xml determines the maximum number of claims that Claim Health Calculations processes in a single run.
Guidewire recommends that you run Claim Health Calculations batch processing in the following circumstances:
• After an upgrade from a version of ClaimCenter that did not have Claim Metrics, meaning ClaimCenter 6.0 or
earlier.
• Optionally, after staging table loading of claims into the database.
Bulk Claim Validation batch processing also forces the creation of Claim Health Metrics on the claims that it
processes if metrics do not exist. Therefore, if you run Bulk Claim Validation batch processing for each batch of
claims loaded through staging tables, you do not need to run Claim Health Calculations batch processing.
Claim Health Calculations does not update metrics on claims that already have metrics. Guidewire provides a
sample claim exception rule that you can use to force creation of new claim metrics, exposure metrics, and claim
indicators on every claim. The name of the sample rule is CER04000 - Recalculate claim metrics.
See also
• “Claim Validation Batch Processing” on page 110
• Rules Guide
• Configuration Guide

Claim Validation Batch Processing

Code ClaimValidation

Categories APIRunnable

Implementation Work queue

110 chapter 6 Administering Batch Processing

 System Administration Guide 9.0.5

Workers 0
Schedule Not schedulable
Class ClaimValidationWorkQueue.java

Claim Validation batch processing creates work items to schedule loaded claims for validation. By default,
Guidewire disables Claim Validation batch processing in the base configuration by setting the number of workers in
work-queue.xml to 0. You must set the number of workers in this file to 1 or more to be able to run this process.

Using ClaimAPI to validate claims

It is possible to launch the Claim Validation process using the startClaimValidation method on ClaimAPI:

startClaimValidation(ID : String) : ProcessID

Parameter ID is a String value that identifies the conversion batch process that imported the claims. This value is
available through the TableImportResult object returned from a table import operation. For example:

var result : TableImportAPI.integrityCheckStagingTableContentsAndLoadSourceTables(...)

var pid = claimAPI.startClaimValidation(result.ID)

Using maintenance_tools to validate claims

It is also possible to launch the Claim Validation process from a command prompt by using the maintenance_tools
command:

maintenance_tools -user user -password password -startprocess claimvalidation -args loadCommandPublicID

The value of loadCommandPublicID is the public ID from table CC_LOADCOMMAND of the claims that were loaded
during an import process. You can use a SQL query similar to the following to determine the public ID.

SELECT PublicID from cc_loadcommand a, cc_claim b

WHERE b.LoadCommandID=a.ID and b.LoadCommandID=LoadCommandID

The value of LoadCommandID is the LoadCommandID from table CC_CLAIM.

See also
• “Configuring Work Queues” on page 96
• “Claim Health Calculations Batch Processing” on page 110
• Rules Guide

ClaimCenter (SPM) Completed Review Sync Batch Processing

Code ReviewSync

Categories APIRunnable, UIRunnable, Schedulable

Implementation Work queue

Schedule Every 20 minutes
Class ReviewSyncWorkQueue.java

ClaimCenter (SPM) Completed Review Sync batch processing transmits completed reviews of service providers to
Guidewire ContactManager. ContactManager uses this information to construct a ReviewSummary object. After the

Work Queues and Batch Processes, a Reference 111

 System Administration Guide 9.0.5

process submits a review to ContactManager, the process sets the AddressBookUID field on the ClaimCenter Review
object, indicating the transmission of the review.
See also
Application Guide

Contact Retire Batch Processing

Code ContactRetire

Categories APIRunnable, UIRunnable, Schedulable

Implementation Work queue

Schedule Once a day, at 1:00 a.m.
Class ContactRetireWorkQueue.java

Contact Retire batch processing checks for contacts that are potentially eligible for retirement and removes them. On
bundle commit, ClaimCenter checks for any entities that have a foreign key link to the contact and creates
ContactRetireWorkItem objects for any contacts being affected by the following:
• The owning entity selected for retirement.
• The property being changed, and a new value being set
As Contact Retire batch processing runs, it calls the ContactRetireHelper.retireContact() method to attempt
to retire the contact referenced by each ContactRetireWorkItem.
See also
• Guidewire Contact Management Guide

Contact Auto-synchronization Batch Processing

Code ContactAutoSync

Categories APIRunnable, UIRunnable, Schedulable

Implementation Work queue

Schedule Twice a day, at 5:00 a.m. and 5:00 p.m.
Dependencies Run Contact Auto-synchronization batch processing before Financials Escalation batch processing to prevent
that process from encountering validation errors due to out-of-synchronization contacts.
Class CCContactAutoSyncWorkQueue.java

ContactAutoSync batch processing synchronizes contact information between Guidewire ContactManager and
Guidewire ClaimCenter. You can configure ClaimCenter to synchronize contact information whenever a user
updates a contact, or you can schedule the ContactAutoSync work queue to synchronize contact information at a set
time.
See also
• “The Work Queue Scheduler” on page 93
• Guidewire Contact Management Guide

Dashboard Statistics Batch Processing

Code DashboardStatistics

Categories APIRunnable, UIRunnable, Schedulable

112 chapter 6 Administering Batch Processing

 System Administration Guide 9.0.5

Implementation Batch process

Stoppable No (single phase process)
Schedule Once a day, at 1:00 a.m.
Class DashboardStatsBatchProcess.java

Dashboard Statistics batch processing recalculates the statistics for data shown in the ClaimCenter Dashboard tab that
is available to supervisors only.
See also
• Application Guide

Data Distribution Batch Processing

Code DataDistribution

Categories APIRunnable

Implementation Batch process

Stoppable No (single phase process)
Schedule Not schedulable
Class CCDataDistributionBatchProcess.java

Data Distribution batch processing generates data on the distribution of various items in the ClaimCenter database. It
is not possible to schedule this process. You must run this process from the Data Distribution screen of the Server
Tools Info Pages or by using the maintenance_tools command line utility.
As this type of batch processing can be very resource intensive, it has the possibility of adversely affecting the
performance of the application. Before you run this process in a production environment, Guidewire recommends
that you run the process first against a test environment that contains a full copy of production data.
See also
• “Data Distribution” on page 372
• “Maintenance Tools Command” on page 418
• Integration Guide

Database Consistency Check Batch Processing

Code DBConsistencyCheck

Categories Schedulable

Implementation Work queue

Non-exclusive Yes
Schedule First Sunday of every sixth month, at 4:00 p.m.
Class DBConsistencyCheckWorkQueue.java

Database Consistency Check batch processing runs consistency checks on the ClaimCenter database.
Use the Server Tools Info Pages→Consistency Checks screen to launch the checks from ClaimCenter. You can set the
number and type of workers to use in running the consistency checks through this screen.

Work Queues and Batch Processes, a Reference 113

 System Administration Guide 9.0.5

Alternatively, to schedule consistency checks, use the following system_tools command, adding the optional
information on which checks to run against which tables:

system_tools -user user -password password -checkdbconsistency ...

See also
• “Work Queues” on page 86 for a discussion of how ClaimCenter handles work queues.
• “Database Consistency Checks” on page 262 for an overview of database consistency checks
• “Consistency Checks” on page 361 for details of the Consistency Checks screen in ClaimCenter
• “Command Prompt Tools” on page 413 for an explanation of command prompt options

Database Statistics Batch Processing

Code DBStats

Categories Schedulable

Implementation Work queue

Schedule Not scheduled
Class DBStatisticsWorkItemWorkQueue.java

Database Statistics batch processing generates database statistics about how the ClaimCenter application and data
model interact with the physical database. For example, database statistics store row counts in a table, how a table
distributes the data, and much more. A database management system uses statistics to determine query plans to
optimize performance.

IMPORTANT Do not run or schedule this process if you set <databasestatistics> attribute
useoraclestatspreferences to true in file database-config.xml.

Development Mode
In development mode, it is possible to run Database Statistics batch processing in any of the following ways:
• From a command prompt, using the -updatestatistics option of the system_tools command
• From the Execution History tab of the Server Tools Database Statistics screen
• As a scheduled batch process

Production Mode
In production mode, it is possible to run Database Statistics batch processing in the following ways only:
• From a command prompt, using the -updatestatistics option of the system_tools command.
• As a scheduled batch process

Guidewire recommendation
Guidewire specifically recommends that you collect full statistics in the following circumstances:
• If there are significant changes to data such as after a major upgrade.
• If using the table_import -integritycheckandload or zone_import command.
• If you are trying to troubleshoot performance problems.
In all other cases, Guidewire recommends that you collect INCREMENTAL database table statistics only.

114 chapter 6 Administering Batch Processing

 System Administration Guide 9.0.5

See also
• “Understanding Database Statistics” on page 279
• “Managing Database Statistics using System Tools” on page 282
• “Database Statistics” on page 373
• “System Tools Command” on page 422

Deferred Upgrade Tasks Batch Processing

Code DeferredUpgradeTasks

Categories APIRunnable

Implementation Batch process

Stoppable No (single phase process)
Schedule Not schedulable
Class DeferredUpgradeBatchProcess.java

Deferred Upgrade Tasks batch processing creates the nonessential performance indexes and indexes on archived
entities.
ClaimCenter runs Deferred Upgrade Tasks batch processing automatically after an upgrade if you set the following
attribute on <upgrade> in database-config.xml to true:

defer-create-nonessential-indexes

If DeferredUpgradeTasks batch processing fails, manually run the batch process again during non-peak hours. To
manually run the Deferred Upgrade Tasks batch processing, use the following command:

maintenance_tools -server url -password password -startprocess DeferredUpgradeTasks

Note: To run this command, you must have permission to create indexes until after the DeferredUpgradeTasks
batch process completes.
To check the status of the DeferredUpgradeTasks batch processing, review the upgrade logs and the ClaimCenter
Server Tools Upgrade and Versions screen.

Production Mode
Do not go into full production while the Deferred Upgrade Tasks process is still running. The lack of so many
performance-related indexes can likely make ClaimCenter unusable.
Until the Deferred Upgrade Tasks batch process has run to completion, ClaimCenter reports errors during schema
validation while starting. These include errors for column-based indexes existing in the data model but not in the
physical database and mismatches between the data model and system tables.
Do not use the ClaimCenter archiving feature until the Deferred Upgrade Tasks batch processing completes
successfully.
See also
• “Upgrade and Versions” on page 393
• “Maintenance Tools Options” on page 418
• Upgrade Guide

Work Queues and Batch Processes, a Reference 115

 System Administration Guide 9.0.5

Destroy Contact For Personal Data

Code DestroyContactForPersonalData

Categories Schedulable

Implementation Work queue

Schedule Not scheduled
Class PersonalDataContactDestructionWorkQueue.gs

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.
An exception is thrown if return status is New or if you try to change the status from a typecode in the
DestructionStatusFinished category.
See also
• Configuration Guide

Encryption Upgrade Batch Processing

Code EncryptionUpgrade

Categories UIRunnable, Schedulable

Implementation Work queue

Schedule Once a day, at 1:00 a.m.
Class SnapshotUpgradeWorkQueue.java

Encryption Upgrade batch processing upgrades encryption fields for previous entity versions. ClaimCenter supports
the encryption of sensitive data, such as tax IDs, on claim snapshots.
The ClaimSnapshot entity includes an EncryptionVersion integer column. This column stores a number
representing the version of the IEncryption plugin implementation used to encrypt the snapshot fields.
ClaimCenter also stores the current encryption version. If the encryption metadata or plugin algorithm change,
ClaimCenter increments this version number.
The Encryption Upgrade work queue recalculates encrypted field values for any ClaimSnapshot that has a value for
EncryptionVersion less than the current encryption version. ClaimCenter decrypts the encrypted value by using
the original plugin implementation. Then, ClaimCenter encrypts the value with the new plugin implementation.
Finally, ClaimCenter updates the EncryptionVersion of the snapshot to mark it current.
You can adjust the number of snapshots that this process upgrades at one time by modifying the
SnapshotEncryptionUpgradeChunkSize parameter in config.xml. A value of 0 for
SnapshotEncryptionUpgradeChunkSize sets no limit to the number of snapshots upgraded at once.
See also
• Integration Guide

Exchange Rate Batch Processing

Code ExchangeRate

116 chapter 6 Administering Batch Processing

 System Administration Guide 9.0.5

Categories APIRunnable, UIRunnable, Schedulable

Implementation Batch process

Stoppable No (single phase process)
Schedule Not scheduled
Class ExchangeRateBatchProcess.java

Exchange Rate batch processing uses a class that implements the IExchangeRateSetPlugin interface to populate
exchange rate data in ClaimCenter.
See also
• Application Guide

Financials Calculations Batch Processing

Code FinancialsCalculations

Categories MaintenanceOnly

Implementation Batch process

Stoppable No (single phase process)
Schedule Not schedulable
Class FinancialsCalculationBatchProcess.java

IMPORTANT Before you run this batch process, first run Database Consistency Check batch processing and verify
that there are no consistent children failures.

Financials Calculations batch processing recalculates denormalized financial values. ClaimCenter denormalizes
several financial fields into different objects for performance reasons. The Financials Calculations process
recalculates denormalization fields in case they ever become unsynchronized. This process updates the following
entities:
• CheckRpt
• ClaimRpt
• ExposureRpt
Each of these entities stores denormalized financials totals to improve performance if ClaimCenter displays the
entity. These entities are kept current by the normal operation of ClaimCenter. However, issues in a custom
configuration can cause the values to become unsynchronized and cause database consistency checks to fail. To help
address such issues, it is possible for Guidewire Support to ask you to run this batch process.
Never add new claims to ClaimCenter with the web service APIs while the Financials Calculations batch process is
running. This applies to both addFNOL() and migrateClaim() methods.
This batch process can only be run from the command prompt while the server is at the maintenance run level.

Warning
Financials Calculations batch processing recalculates denormalized financial values in two distinct steps:
1. It first zeros out all denormalization fields in all the RPT tables.
2. It then recalculates the denormalization fields in the RPT tables.
If Financials Calculations batch processing does not complete successfully, there is a risk that ClaimCenter can leave
all denormalization (transaction summary) fields in the RPT tables zeroed out. If this is the case, ClaimCenter users
can see this result in the financial summary screens.
Work Queues and Batch Processes, a Reference 117
 System Administration Guide 9.0.5

There are multiple reasons that Financials Calculations batch processing can fail:
• Restarting the database server while Financials Calculations batch processing is executing.
• Manually stopping Financials Calculations batch processing before the process completes, perhaps because batch
processing is taking longer then the scheduled maintenance time window.
• Encountering a triangle inconsistency DBCC error for a claim, in which the child objects on the Claim object do
not consistently point to the same claim.
If Financials Calculations batch processing fails for any reason, do the following:
1. Determine the root cause of the batch processing failure and fix it.
2. Rerun Financials Calculations batch processing and ensure that it completes successfully.

Financials Escalation Batch Processing

Code FinancialsEsc

Categories APIRunnable, UIRunnable, Schedulable

Implementation Batch process

Stoppable No (single phase process)
Schedule Twice a day, at 6:00 a.m. and 6:00 p.m.
Dependencies • Run T-accounts Escalation batch processing before running Financials Escalations.
• Run Contact Auto-Synchronization batch processing before running Financials Escalations to prevent
validation errors due to out-of-synchronization contacts.
Class FinancialsEscalationMonitor.java

Financials Escalation batch processing changes the status of unissued payments that have passed their date
requirements from Awaiting Submission to Submitting. ClaimCenter can then send the unissued payments to the
financial system.
Although the intention for many payments is to produce a check as soon as possible, it is possible to schedule the
issuance of a check for a future date. This is very common, for example, if creating a schedule of recurring
payments.
See also
• Application Guide

Geocode Writer Batch Processing

Code Geocode

Categories APIRunnable, UIRunnable, Schedulable

Implementation Work queue

Schedule Not scheduled
Class GeocodeWorkQueue.java

Geocode Writer batch processing is the writer for the Geocode work queue. This work queue runs periodically to
update geocoding information on user contact (UserContact) primary addresses and account locations. The
UserContact entity represents a ClaimCenter user.

118 chapter 6 Administering Batch Processing

 System Administration Guide 9.0.5

See also
• “Understanding Geocoding” on page 79
• “Configuring Geocoding” on page 80

Group Exception Batch Processing

Code GroupException

Categories UIRunnable, Schedulable

Implementation Work queue

Workers 0
Schedule Once a day, at 4:00 a.m.
Class GroupExceptionWorkQueue

Group Exception batch processing runs any defined group exception business rules on all groups in the system.
By default, Guidewire disables Group Exception batch processing in the base configuration by setting the number of
workers in work-queue.xml to 0. You must set the number of workers in this file to 1 or more to be able to run this
process.
See also
• “Configuring Work Queues” on page 96
• Rules Guide

Idle Claim Exception Batch Processing

Code IdleClaim

Categories APIRunnable, UIRunnable, Schedulable

Implementation Work queue

Schedule Once a week, at Sunday noon (12:00 a.m.)
Class IdleClaimExceptionMonitorWorkQueue.java

Idle Claim Exception batch processing runs the claim exception rules on open claims that are idle. ClaimCenter
considers a claim to be idle if the exception rules have not been run on it in the number of days specified by the
IdleClaimThresholdDays configuration parameter.
The SeparateIdleClaimExceptionMonitor configuration parameter controls whether Idle Claim Exception and
Claim Exception run independently or together. If SeparateIdleClaimExceptionMonitor is false, then Idle
Claim Exception and Claim Exception run claims concurrently through claim exception rules for recently modified
and idle open claims. SeparateIdleClaimExceptionMonitor is set to true in the default configuration. If you set
the parameter to false, also disable the schedule for running Idle Claim Exception batch processing.
See also
• “Claim Exception Batch Processing” on page 109
• Rules Guide

Idle Closed Claim Exception Batch Processing

Code IdleClosedClaim

Categories APIRunnable, UIRunnable, Schedulable

Work Queues and Batch Processes, a Reference 119

 System Administration Guide 9.0.5

Implementation Work queue

Schedule Unscheduled
Class IdleClosedClaimExceptionMonitorWorkQueue.java

Idle Closed Claim Exception batch processing runs the claim exception rules on closed claims that are idle.
ClaimCenter considers a claim to be idle if the exception rules have not been run on it in the number of days
specified by the IdleClosedClaimThresholdDays configuration parameter. By default, Guidewire disables Idle
Closed Claim Exception in the scheduler.
See also
• Rules Guide

Notify External System For Personal Data

Code NotifyExternalSystemForPersonalData

Categories Schedulable

Implementation Work queue

Schedule Not scheduled
Class PersonalDataDestructionNotifyExternalSystemsWorkQueue.gs

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
• Configuration Guide

Phone Number Normalizer Batch Processing

Code PhoneNumberNormalizer

Categories UIRunnable

Implementation Work queue

Schedule Once only, after an upgrade to 8.0.0+
Class CompactPhoneNormalizerWorkQueue.java

120 chapter 6 Administering Batch Processing

 System Administration Guide 9.0.5

IMPORTANT Run Phone Number Normalizer batch processing once only, after upgrading from earlier application
versions to 8.0.0+. Disable Phone Number Normalizer batch processing in a production environment.

Phone Number Normalizer batch processing calls the registered plugin that implements the
IPhoneNumberNormalizer interface. Use Phone Number batch processing to normalize phone numbers after
upgrading from earlier versions of ClaimCenter to 8.0.0+.
Guidewire recommends that you use a substantial number of workers with Phone Number Normalizer batch
processing. Using a small number of workers to normalize the phone numbers in a large database can take a very
long time. The optimal number of workers to use varies according to the available hardware and the volume of the
data involved. It is also possible to allocate workers to several different ClaimCenter servers rather then simply
increasing the number of workers on a single server.
Disable this work queue after the process completes normalizing all old phone numbers by setting the number of
workers in work-queue.xml to 0. You never need run Phone Number Normalizer batch processing more than once,
after an upgrade to 8.0.0+.
See also
• “Configuring Work Queues” on page 96
• Upgrade Guide

Populate Search Columns Batch Processing

Code PopulateSearchColumns

Categories APIRunnable

Implementation Batch process

Stoppable Yes (multi-phase process)
Schedule Not schedulable
Class PopulateSearchColumnBatchProcess.java

Populate Search Columns batch processing populates denormalized searchColumn columns from their designated
sourceColumn columns.
This process is only available from the maintenance_tools command or from a web service.
See also
• Configuration Guide

Process Completion Monitor Batch Processing

Code ProcessCompletionMonitor

Categories UIRunnable, Schedulable

Implementation Batch process

Stoppable No (single phase process)
Schedule Not scheduled
Class ProcessCompletionMonitor.java

Process Completion Monitor batch processing runs at schedulable intervals and examines the ProcessHistory table
for all completed work queues and batch processes.

Work Queues and Batch Processes, a Reference 121

 System Administration Guide 9.0.5

For each completed work queue that it finds, Process Completion Monitor:
• Determines if all the work items in that work queue have either completed or failed.
• Calls the IBatchCompletedNotification plugin implementation on a process if the process is complete and has
no remaining available or checked-out work items.
• Sets ProcessHistory.NOTIFICATIONSENT to true, to prevent the process from invoking the
IBatchCompletedNotification plugin implementation more than a single time for any given process.
The IBatchCompletedNotification interface has a completed method that you can override to perform specific
actions after a work queue or batch process completes a batch of work.
See also
• “Performing Custom Actions After Batch Processing Completion” on page 100.

Process History Purge Batch Processing

Code ProcessHistoryPurge

Categories UIRunnable, Schedulable

Implementation Batch process

Stoppable No (single phase process)
Schedule On the third day of the month, at 3:30 a.m.
Class ProcessHistoryPurge.gs

Process History Purge batch processing purges batch process history data from the ProcessHistory table. It is
important to periodically delete process history data. A large number of history records in the database can slow
performance during use of the Server Tools Batch Process Info or Work Queue Info screens.
This process uses Gosu class ProcessHistoryPurge to read the value of the BatchProcessHistoryPurgeDaysOld
parameter in config.xml. The process then uses this value to determine the history data to purge.
Note: ClaimCenter also uses configuration parameter BatchProcessHistoryPurgeDaysOld to determine how
many days to retain process history records, which the separate “Work Item Set Purge Batch Processing” on page
129 process removes.

Purge Cluster Members Batch Processing

Code PurgeClusterMembers

Categories UIRunnable, Schedulable

Implementation Batch process

Stoppable No (single phase process)
Schedule On the first day of each month, at 2:00 a.m.
Class PurgeClusterMembers.gs

Purge Cluster Members batch processing purges ClusterMemberData entities. This process uses Gosu class
PurgeClusterMembers to read the value of the ClusterMemberPurgeDaysOld parameter in config.xml. The
process then uses this value to determine to purge the ClusterMemberData entities that have a LastUpdate value
prior to the current date minus the value of the ClusterMemberPurgeDaysOld.

122 chapter 6 Administering Batch Processing

 System Administration Guide 9.0.5

Purge Failed Work Items Batch Processing

Code PurgeFailedWorkItems

Categories UIRunnable, Schedulable

Implementation Batch process

Stoppable No (single phase process)
Schedule On the first day of the month, at 1:00 a.m.
Class PurgeFailedWorkItems.gs

Purge Failed Work Items batch processing purges failed work items from all work queues. This process uses Gosu
class PurgeFailedWorkItems to determine which work items to delete.
During a scheduled execution of the batch process, the batch process deletes failed work items that are older than the
last run date of the batch process. It then set the last run date to the current date. Thus, if the scheduled execution of
this batch process is monthly, the process deletes work items that are older than a month only.
If you run this batch process manually and there are work items that are newer than the last run date, the batch
process does not delete them. If you then run the batch process a second time on the same day, the process deletes
work items that are older than the current date. This is the expected behavior.

Purge Message History Batch Processing

Code PurgeMessageHistory

Categories APIRunnable, UIRunnable, Schedulable

Implementation Batch process

Stoppable No (single phase process)
Schedule Each Sunday, at 4:30 a.m.
Class PurgeMessageHistory.gs

Purge Message History batch processing purges old messages from the message history table. The
KeepCompletedMessagesForDays parameter in config.xml specifies how many days a message can remain in the
message history table before Purge Message History batch processing removes the message.

Purge Old Transaction IDs Batch Processing

Code PurgeTransactionIDs

Categories UIRunnable, Schedulable

Implementation Batch process

Stoppable No (single phase process)
Schedule Not scheduled
Class PurgeTransactionIds.gs

Purge Old Transaction IDs batch processing deletes SOAP header transaction IDs generated by systems external to
ClaimCenter. This process uses Gosu class PurgeTransactionIds to read the value of the
TransactionIdPurgeDaysOld parameter in config.xml. The process then purges transaction IDs that have a
creation date prior to the current date minus the value of the TransactionIdPurgeDaysOld parameter.

Work Queues and Batch Processes, a Reference 123

 System Administration Guide 9.0.5

Guidewire does not schedule this batch process in the base configuration as the table that stores the transaction IDs
takes very little space in the database. Unless there is a constant buildup of these transaction IDs, there is no real
need to continually purge this data. In fact, if you do purge this data, it is then not possible to determine if a new
transaction is a duplicate of a transaction sent by the external system at an earlier date. There are other alternatives to
purging this data. For example, you can partition the table by date.
See the ClaimCenter Integration Guide for information on SOAP headers. Also see
WsiCheckDuplicateExternalTransaction.

Purge Profiler Data Batch Processing

Code PurgeProfilerData

Categories UIRunnable, Schedulable

Implementation Batch process

Stoppable Yes (multi-phase process)
Schedule Once a day, at 2:00 a.m.
Class ProfilerDataPurgeBatchProcess.java

Purge Profiler Data batch processing purges profiler data at regularly specified intervals. This process uses the read-
only ProfilerDataPurgeBatchProcess class to read the value of the ProfilerDataPurgeDaysOld parameter in
config.xml. The process then uses the value of this parameter to determine how many days to retain profiler data
before Purge Profiler Data batch processing removes it.

Purge Workflow Batch Processing

Code PurgeWorkflows

Categories UIRunnable, Schedulable

Implementation Batch process

Stoppable No (single phase process)
Schedule On the first day of the month, at 1:30 a.m.
Class PurgeWorkflows.gs

Purge Workflow batch processing purges completed workflows after resetting any referenced workflows. This
process uses Gosu class PurgeWorkflow to read the value of the WorkflowPurgeDaysOld days parameter in
config.xml. The process then uses this value to determine the number of days to retain workflow data before
purging it.

Purge Workflow Logs Batch Processing

Code PurgeWorkflowLogs

Categories UIRunnable, Schedulable

Implementation Batch process

Stoppable No (single phase process)
Schedule On the first day of the month, at 2:30 a.m.
Class PurgeWorkflowLogs.gs

124 chapter 6 Administering Batch Processing

 System Administration Guide 9.0.5

Purge Workflow Logs batch processing purges completed workflows logs. This process uses Gosu class
PurgeWorkflowLogs to read the value of WorkflowLogPurgeDaysOld parameter in config.xml. The process then
uses this value to determine the number of days to retain workflow logs before purging them.

Recalculate Claim Metrics Batch Processing

Code RecalculateMetrics

Categories APIRunnable, UIRunnable, Schedulable

Implementation Work queue

Schedule Once a day, at 3:30 a.m.
Class RecalculateClaimMetricsWorkQueue.java

Recalculate Claim Metrics batch processing recalculates claim metrics on claims for which the metric update time
has already passed.
See also
• Configuration Guide

Remove Old Contact Destruction Request

Code RemoveOldContactDestructionRequest

Categories Schedulable

Implementation Work queue

Schedule Not scheduled
Class RemoveOldContactDestructionRequestWorkQueue.gs

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
ClaimCenter removes each found request that has AllRequestsFulfilled equal to true.
See also
• Configuration Guide

Retired Policy Graph Disconnector Batch Processing

Code RetiredPolicyGraphDisconnector

Categories APIRunnable, UIRunnable, Schedulable

Implementation Batch process

Stoppable No (single phase process)
Schedule Once a day, at 3:30 a.m.
Class RetiredPolicyGraphDisconnectorBatch.gs

Work Queues and Batch Processes, a Reference 125

 System Administration Guide 9.0.5

Changing the policy or risk units within the FNOL wizard leads to residual data links that can prevent ClaimCenter
from archiving a claim. Retired Policy Graph Disconnector batch processing identifies and removes those links.
The process calls the RetiredPolicyGraphDisconnector class defined in Gosu class
RetiredPolicyGraphDisconnector to perform the uncoupling of claim and policy. Suppose, for example, that you
added extension properties that produce new links between policy and non-policy entities within a claim. In this
case, you need to add additional logic to the RetiredPolicyGraphDisconnector class to unlink them.

Test for the Removal of Links between a Claim and a Policy

About this task

It is possible that running Retired Policy Graph Disconnect batch process does not entirely remove the links between
a claim and a retired policy graph. These remaining links can prevent ClaimCenter from archiving the claim.
Use the following approach to test that the RetiredPolicyGraphDisconnector class logic is removing all links
between claim and policy.

Procedure
1. In Guidewire ClaimCenter, open the FNOL wizard to create a claim.
2. Select a policy for the claim. ClaimCenter attaches the policy to the new claim.
3. Select a different policy for the claim. This action causes the FNOL wizard to retire the previous policy, unlink
it from the claim, and then link the new policy to the claim.
4. Run Retired Policy Graph Disconnector batch processing. The process severs the remaining links between the
claim and the unused policy.
5. Schedule the claim for archiving.
6. Run “Archive Batch Processing” on page 105 batch processing and verify that it is possible to archive the
claim.

Next steps
See also
• Integration Guide

Service Request Metric Escalation Batch Processing

Code ServiceRequestMetricEscalation

Categories APIRunnable, UIRunnable, Schedulable

Implementation Work queue

Schedule At 10 and 40 minutes past the hour
Class ServiceRequestMetricEscalationWorkQueue

Service Request Metric Escalation batch processing escalates service metrics if they have exceeded an upper limit.

Solr Data Import Batch Processing

Code SolrDataImport

Categories UIRunnable, Schedulable

Implementation Batch process

Stoppable No (single phase process)

126 chapter 6 Administering Batch Processing

 System Administration Guide 9.0.5

Schedule Not scheduled

Class SolrDataImportBatchProcess.gs

Solr Data Import batch processing tests the operation of the free-text batch load command, especially its embedded
SQL query. Only run Solr Data Import batch processing on development-mode servers.

IMPORTANT Do not run this process in production to load and re-index the Guidewire Solr Extension. Instead, run
the free-text batch load command (batchload) on the host on which the Guidewire Solr Extension resides.

See also
• “Free-text Batch Load Command” on page 315
• Configuration Guide

Statistics Batch Processing

Code Statistics

Categories APIrunnable, UIRunnable, Schedulable

Implementation Batch process

Stoppable No (single phase process)
Schedule Every hour, at three minutes past the hour
Class StatisticsBatchProcess.java

Statistics batch processing calculates the work activity statistics that ClaimCenter shows in the Dashboard Statistics
screen. The process also calculates aging values on claims and exposures.
Only users with the Supervisor role in ClaimCenter are able to view work activity statistics for the team in the
Statistics screen. This screen shows counts of open claims, activities, exposures, and matters for each user.
By default, this batch process runs every hour at three minutes past the hour. You can schedule this process to run
more frequently. However, monitor system performance for possible negative impact if you change the schedule.

T-accounts Escalation Batch Processing

Code TaccountEsc

Categories APIrunnable, UIRunnable, Schedulable

Implementation Batch process

Stoppable No (single phase process)
Schedule Once a day, at 12:01 a.m.
Dependencies Run before Financials Escalation and Bulk Invoice Escalation batch processing.
Class TAccountEscalationMonitor.java

T-accounts Escalation batch processing updates the t-accounts of the payments on a future-dated check that has now
reached its scheduled send date. After this update, the payment amount no longer contributes to future payments.
Instead, the payment contributes to calculations that include payments scheduled for today, such as total payments,
open reserves, remaining reserves, and available reserves.
T-accounts Escalation batch processing updates financials calculations in the event that the schedule for the
Financials Escalation or Bulk Invoice Escalation processes runs after the end of the business day. That way, the

Work Queues and Batch Processes, a Reference 127

 System Administration Guide 9.0.5

financial calculations are current for the day scheduled to send the check, but, the check is still editable as it has not
yet been escalated. T-accounts Escalation ensures that T-account balances and dependent calculated financials values
are correct between midnight and the first scheduled run of Financials Escalation or Bulk Invoice Escalation for that
day.
Schedule T-accounts Escalation batch processing to run as close to just past midnight as possible and before
Financials Escalation and Bulk Invoice Escalation batch processing runs.
See also
• “Financials Escalation Batch Processing” on page 118
• “Bulk Invoice Escalation Batch Processing” on page 106

User Exception Batch Processing

Code UserException

Categories APIRunnable, UIRunnable, Schedulable

Implementation Work queue

Workers 0
Schedule Once a day, at 3:00 a.m.
Class UserExceptionWorkQueue.java

User Exception batch processing runs the user exception rule set on all users in the system.
By default, Guidewire disables User Exception batch processing in the base configuration by setting the number of
workers in work-queue.xml to 0. You must set the number of workers in this file to 1 or more to be able to run this
process.
See also
• “Configuring Work Queues” on page 96
• Rules Guide

User Workload Update Batch Processing

Code UserWorkloadUpdate

Categories APIRunnable, UIRunnable, Schedulable

Implementation Work queue

Schedule Not scheduled
Class UserWorkloadUpdateWorkQueue.java

User Workload Update batch processing updates workload data for ClaimCenter users. Run User Workload Update
any time a change is made that affects existing weighted workload values. In particular, run User Workload Update
batch processing to recalculate workload classifications and assignments to groups after any change to
classifications. Otherwise, it is likely that the stored computed workload weights are out of date.
See also
• Application Guide

Workflow Batch Processing

Code Workflow

128 chapter 6 Administering Batch Processing

 System Administration Guide 9.0.5

Categories UIRunnable, Schedulable

Implementation Work queue

Schedule Every 10 minutes
Class WorkflowDistributedWorkQueue.java

Workflow batch processing wakes up at 10 minute intervals and runs workflow worker tasks. Workflow cannot
advance any faster in the background than this schedule.
See also
• Configuration Guide

Work Item Set Purge Batch Processing

Code WorkItemSetPurge

Categories UIRunnable, Schedulable

Implementation Batch process

Stoppable No (single phase process)
Schedule On the second day of the month, at 1:30 a.m.
Class WorkItemSetPurge.gs

Work Item Set Purge batch processing purges work item sets from the database. This process uses Gosu class
WorkItemSetPurge to read the value of the BatchProcessHistoryPurgeDaysOld parameter in config.xml. The
process then uses this value to determine the number of days to retain work item sets before purging them.
Note: The BatchProcessHistoryPurgeDaysOld parameter also configures how many days to retain process
history records, which the separate “Process History Purge Batch Processing” on page 122 process removes.

Work Queue Instrumentation Purge Batch Processing

Code WorkQueueInstrumentationPurge

Categories UIRunnable, Schedulable

Implementation Batch process

Stoppable No (single phase process)
Schedule On the second day of the month, at 2:30 a.m.
Class WorkQueueInstrumentationPurge.gs

Work Queue Instrumentation Purge batch processing purges instrumentation data for work queues. This process uses
Gosu class WorkQueueInstrumentationPurge to read the value of the InstrumentedWorkerInfoPurgeDaysOld
parameter in config.xml. The process then uses this value to determine how long to retain work queue
instrumentation data.

Work Queues and Batch Processes, a Reference 129

 System Administration Guide 9.0.5

See also
• “Work Queue Info” on page 352

Unused and Internal Batch Processes

ClaimCenter uses some batch process types either internally, or, in a few cases, not at all. You cannot run these
processes from ClaimCenter, maintenance_tools, or a web services API.

Unused processes
The Batch Process Type typelist (BatchProcessType.tti) includes a few Guidewire platform processes that
PolicyCenter does not currently use. Guidewire indicates this status by setting the retired flag on the process
typecode to true and placing a line through the typecode the typelist. You can ignore these processes.

Internal processes
PolicyCenter uses some Guidewire batch processes internally. PolicyCenter runs these processes to generate
database performance reports only. You cannot run these processes separately. They are:
• Microsoft DMV Report
• Oracle AWR Report

130 chapter 6 Administering Batch Processing

part 3

Server Clustering Administration

System Administration Guide 9.0.5
chapter 7

Understanding ClaimCenter Server

Clustering

To improve performance and reliability, you can install multiple ClaimCenter servers in a configuration known as a
cluster. A ClaimCenter cluster distributes client connections among multiple ClaimCenter servers, reducing the load
on any one server. If one server fails, the other servers seamlessly handle its traffic. This topic describes how a
ClaimCenter cluster functions.
See also
• Installation Guide

Cluster Terminology
Guidewire uses the following terminology in discussions involving Guidewire ClaimCenter clusters.

Term Meaning
Host The physical machine on which one or more Guidewire applications run.
Application instance An individual ClaimCenter deployment. It is possible to run multiple application instances on the same
host.
ClaimCenter server The server associated with each application instance. For production environments, Guidewire supports
JBoss, Tomcat, WebLogic, and WebSphere servers. If running multiple servers on the same host, each
server must map to a different physical port.
Server role A categorization of each application instance in the cluster by its function, as defined by its role.
Examples of server roles are ui (manages user interface requests), batch (manages batch processing),
and messaging (manages messaging and message destinations).
You define server roles using the cluster <registry> element in config.xml. See “Server Roles” on page
141 for more information. See also “Understanding the Configuration Registry Element” on page 46.
Cluster A grouping of two or more Guidewire application instances that have a common configuration and
function as an integrated unit. Typically, each server in the cluster has one or more roles or function.

Understanding ClaimCenter Server Clustering 133

 System Administration Guide 9.0.5

Term Meaning
Most often, if there are multiple servers assigned the ui role, the cluster contains a third-party load
balancer as well.
The individual application instances in the cluster must all connect to a common database.
Cluster member A single application instance within a Guidewire cluster.

Guidewire ClaimCenter Cluster Installations

The typical ClaimCenter cluster consists of two or more ClaimCenter servers, each of which has one or more server
roles, and a load balancer. In general, a ClaimCenter cluster contains the following types of servers:
• One or more user interface servers (online servers) that process web requests, perform business transactions, and
render web pages.
• One or more non-user interface servers (offline servers) that manage batch processing, work queues, scheduling,
message destinations, and startable services (plugins).
• A load balancer that manages user interface requests if there are multiple user interface servers.
Technically, non-user interface servers can also process web requests from business users, meaning that they can
also act as user interface servers. However, Guidewire recommends that you avoid redirecting business user web
requests to non-user interface servers to simplify the management of the cluster.

Cluster Membership
As a ClaimCenter server joins the cluster, it updates a membership table in the ClaimCenter database. All cluster
servers periodically poll this table to determine cluster membership.

Cluster Availability
To ensure a high degree of availability, Guidewire recommends that the cluster configuration include two or more
servers with each specific server role. You also need to provide ample capacity for running role-constrained items
such as message destinations or batch processes.

Cluster Monitoring
Guidewire provides cluster monitoring screens that are available to those with privileges to view the Server Tools
screens:
• The Server Tools Cluster Members screens provide information on each server in the cluster.
• The Server Tools Cluster Components screen provides information on the components running on a given server.
Also, there are system_tools command options that provide information on cluster members and components in
the ClaimCenter cluster.

Cluster Cache Usage

Cluster inter-communication ensures that if an object changes in one cluster member cache, that member sends a
cache invalidation message to the other members of the cluster. This message instructs the other cluster members to
tag the cache entry for the object as obsolete and evict it from the cache. The next time a ClaimCenter server needs
the object, it reloads the object value directly from the database. This mechanism is different from full cache
synchronization, in which a server broadcasts the new value of the object to other cluster members.
It is possible to lose message packets. Network failures or other issues also can disrupt communication between
cluster members. Such cases can result in cache eviction messages not being propagated to all cluster members. As a
result, one or more cluster members can contain stale cache entries.
Guidewire applications implement a data versioning mechanism to prevent data corruption. One or more version
mismatches indicates that one or more objects have changed since ClaimCenter last accessed the entities. This

134 chapter 7 Understanding ClaimCenter Server Clustering

 System Administration Guide 9.0.5

mismatch results in ClaimCenter issuing a Concurrent Data Change Exception (CDCE). The user or batch job can
then re-issue a change based on the latest values entered.
See also
• “ClaimCenter Server Configuration” on page 45
• “Cache Management” on page 68
• “Concurrent Data Change Prevention” on page 69
• “Planning a ClaimCenter Cluster” on page 149
• “Server Roles” on page 141
• “Batch Process Prioritization” on page 163
• “Messaging and Startable Service Load Balancing” on page 164
• “Cluster Members and Components” on page 386
• “System Tools Options” on page 423

Cluster Communication
In the base ClaimCenter configuration, ClaimCenter clusters use the following types of transport mechanisms for
sending messages between cluster members:
• Reliable broadcast without replies
• Unreliable fast broadcast without replies
• Reliable unicast with reply
Guidewire provides a default plugin implementation to support each of these transport types. However, it is possible
to implement your own unicast/multicast transport by implementing the corresponding plugin. Guidewire disables
fast broadcast messaging in the base configuration.

Unicast Communications
ClaimCenter clusters use PPP protocol over TCP for direct server-to-server communication. For example, it is
possible for a ClaimCenter Server Tools screen function to create a message request that directly targets a specific
server. In this case, server A, on which the message request originate, sends a unicast message to server B, who
receives and processes the request. ClaimCenter server lease management also leverages unicast communication to
speed up certain actions, such as lease transfers.

Multicast Communications
ClaimCenter clusters leverage the database for distributing broadcast messages.

Cluster Plugin Implementations

In the base configuration, Guidewire provides the following plugin interfaces to support cluster communication:

ClusterBroadcastTransportFactory Provides a single factory method for creating a cluster transport for reliable
broadcast of messages, with no replies. ClaimCenter stores broadcast
messages in the database and then periodically loads any new broadcast
messages onto each node in the cluster. This type of cluster transport
guarantees the delivery order and the reliable delivery of the broadcast
message.
ClaimCenter uses this mechanism for default message broadcast if you do
not enable the ClusterFastBroadcastTransportFactory plugin
implementation.

Cluster Communication 135

 System Administration Guide 9.0.5

ClusterFastBroadcastTransportFactory Provides a single factory method for creating a cluster transport for fast
broadcast of messages, with no replies. This type of transport:
• Uses UDP multicast protocol
• Does not guarantee the delivery order or even the actual delivery of
the broadcast message
ClaimCenter typically uses this type of cluster transport for broadcasting
cache eviction notifications to cluster members.
The use of this transport type is optional. In the base configuration,
Guidewire disables the ClusterFastBroadcastTransportFactory plugin
implementation due to its use of the UDP protocol. If you do not enable
the plugin implementation, ClaimCenter uses the ClusterBroadcastTrans
portFactory cluster transport for broadcast messages instead.

ClusterUnicastTransportFactory Provides a single factory method for creating a cluster transport for point-
to-point unicast messages between specific servers in the cluster. The
default plugin implementation uses TCP for the transport protocol.

Guidewire provides internal Java classes for these cluster-related plugin implementations. It is not possible to
modify these Java classes. To see the plugin definitions, open ClaimCenter Studio and navigate to the following
location in the Studio Project window:
configuration→config→Plugins→registry

Configuring Cluster Communication

The cluster-related plugin implementations that Guidewire provides in the base ClaimCenter configuration are
sufficient for most purposes. However, if you need more fine grained control over cluster communications, it is
possible to use one of the following methods to provide that control:
• Plugin parameters
• System property overrides
For example, if you need precise control over binding ports, then use one of these methods to configure the ports
directly.

Plugin Parameters
The cluster plugin implementations that Guidewire provides in the base configuration all support plugin parameters
that you can use to reconfigure the plugin. All plugin parameters are optional. Guidewire provides default values for
each of the plugin parameters. See “Cluster Plugin Parameter Reference” on page 137 for more information.
To define a plugin parameter, you manually add that parameter to the plugin definition in the ClaimCenter plugin
editor. For example, suppose that you want to directly control the number of threads in the thread pool that handle
inbound requests in the ClusterUnicastTransportFactory plugin. In this case, you manually add the poolSize
parameter and value to the plugin definition for ClusterUnicastTransportFactory, using the Studio plugin editor.

System Property Overrides

ClaimCenter provides the ability to reconfigure your plugin configuration using system properties set from a
command prompt as you start the application server. One advantage to using system property overrides to set
transport values is that you do not have to modify the configuration inside a WAR/EAR file to do so. This makes it
easier to use the same WAR/EAR file in different environments.
The exact syntax to use in setting system parameters at application server start is dependent on the application server
type. See “Setting JVM Options in ClaimCenter” on page 52 for more information. See “Cluster Plugin System
Properties Reference” on page 139 for a list of the system parameters that you can use with the clustering plugins.

136 chapter 7 Understanding ClaimCenter Server Clustering

 System Administration Guide 9.0.5

Cluster Plugin Parameter Reference

In the base configuration, ClaimCenter provides the following plugin implementations that manage message
transport in a ClaimCenter cluster. Each of these plugin implementations provide a number of configuration
parameters that you can set to precisely control such transport variables as server address and bind port number.

Plugin implementation For more information

ClusterBroadcastTransportFactory “Configuration parameters for ClusterBroadcastTransportFactory” on page 137
ClusterFastBroadcastTransportFactory “Configuration Parameters for ClusterFastBroadcastTransportFactory” on page
138
ClusterUnicastTransportFactory “Configuration Parameters for ClusterUnicastTransportFactory” on page 139

Defining a plugin parameter

To define a plugin parameter, you manually add that parameter to the plugin definition in the ClaimCenter plugin
editor. For example, suppose that you want to directly control the number of threads in the thread pool that handle
inbound requests in the ClusterUnicastTransportFactory plugin. In this case, you manually add the poolSize
parameter and value to the plugin definition for ClusterUnicastTransportFactory, using the Studio plugin editor.

Configuration parameters for ClusterBroadcastTransportFactory

Use the configuration parameters in the following table to provide precise control over the plugin parameter values
available in the implementation of ClusterBroadcastTransportFactory.

Parameter Description
batchesDeleteInterval Average time (in milliseconds) between the execution of a SQL statement that deletes old
message batches from the database. Each server node in the cluster executes this SQL
statement. Therefore, if the cluster installation contains many nodes, Guidewire recommends
that you increase this value.
The default is 60000 milliseconds (1 minute).
batchKeepPeriod Maximum amount of time for ClaimCenter to retain a batch in the database before deleting it.
The default is 600000 (10 minutes).
batchReadInterval Maximum time interval (in milliseconds) between reading and receiving new batches. The
default is 3000 milliseconds (3 seconds).
batchWriteAttempts Maximum number of attempts to write to a batch queue. If the number of consecutive errors
exceeds this threshold, the transport switches to ERROR mode in which each new messages
pops the oldest message out of the in-memory queue. The purpose of this parameter value is
to avoid out-of-memory issues. The default is 30.
batchWriteInterval Maximum time interval to wait (in milliseconds) before ClaimCenter writes, or sends, the
current batch of messages. The default is 2000 milliseconds (2 seconds).
maxOutboundBufferSize Maximum size of outbound buffer (in megabytes). The purpose of this parameter value is to
prevent out-of-memory issues if a transport is having problems writing or sending messages.
The default is 25 megabytes.
preferredBatchDataSize Maximum size of the batch (in bytes). If the size of the current batch (the sum of all of the
message batch sizes) reaches this threshold, ClaimCenter writes, or sends, the current batch of
messages immediately.
This value must be less than or equal to the largest possible integer value supported by your
hardware.
preferrredBatchMessageCnt Maximum number of pending messages allowed in the batch queue. If the number of
messages in the batch queue reaches this threshold, ClaimCenter writes, or sends, the current
batch of messages immediately.

Cluster Communication 137

 System Administration Guide 9.0.5

Parameter Description
The value must be less than or equal to the largest possible integer value supported by your
hardware.
receiverPoolSize Number of threads in the thread pool that handle inbound messages. The default is 4.

To set a plugin parameter, you must manually add that parameter to the plugin definition in the ClaimCenter plugin
editor. To access the plugin editor, navigate to the following location in ClaimCenter Studio and double-click the
plugin name:
configuration→config→Plugins→registry
See also
• Configuration Guide

Configuration Parameters for ClusterFastBroadcastTransportFactory

Note: Guidewire disables the implementation of the plugin in the base ClaimCenter configuration. You must
enable the plugin implementation before ClaimCenter recognizes any of these parameters.
Use the configuration parameters in the following table to provide precise control over the plugin parameters in
ClusterFastBroadcastTransportFactory.

Parameter Description
bindAddr Inet address to which ClaimCenter is to bind. This parameter can be useful if there are
multiple-NIC hosts. The default fallback for this parameter is the first non-loopback interface
found on the host as defined by the NetworkInterface Java API.
bindPort Port number to which ClaimCenter is to bind. This parameter can be useful for server hosts
behind a firewall.
maxMessageSize Maximum allowable size of message. ClaimCenter calculates the default value of this
parameter using the following algorithm:
(Maximum IP datagram size) - (UDP header size) - (IP header size)
The maximum IP datagram size is 65,535. The UDP header size is 8. The IP header size is one of
the following values:
• IPv4 = 20
• IPv6 = 40
Thus, if using IPv6, the default value for this parameter is 65,535 - 8 - 40, which is 65,487.
messageKeepPeriod Time (in milliseconds) to keep messages in memory in order to skip retransmitted messages
and to combine divided messages. The default is one of the following:
• 2 * (maximum retransmit interval)
• 10 seconds, if not using retransmit
messageSalt Integer value that ClaimCenter uses in calculating the sending message checksum. This value
must be the same on all servers in the ClaimCenter cluster. The default is 12345.
multicastAddress Multicast Inet address. The default is 228.8.8.8.
multicastPort Multicast port. The default is 38180.
nodeStatisticsKeepPeriod Time (in milliseconds) to keep node statistics in memory after last activity. The default is
3,600,000 (1 hour).
oldMessagesDeleteInterval Average time between the removal old messages from the memory (in milliseconds). The
default is 1,000.
receiverPoolSize Number of threads in the thread pool that handle inbound messages. The default is 4.
receiverQueueCapacity Thread pool queue capacity. The default is 100.

138 chapter 7 Understanding ClaimCenter Server Clustering

 System Administration Guide 9.0.5

Parameter Description
retransmitIntervals Comma-separated list of retransmit intervals (in milliseconds). The default is 10000.
sendHeartbeatInterval Time (in milliseconds) between sending heartbeat messages. The default is 30,000 (30
seconds).
ttl Time-to-live (TTL) for multicast datagram packets. The default is 8.

To set a plugin parameter, you must manually add that parameter to the plugin definition in the ClaimCenter plugin
editor. To access the plugin editor, navigate to the following location in ClaimCenter Studio and double-click the
plugin name:
configuration→config→Plugins→registry
See also
• Configuration Guide

Configuration Parameters for ClusterUnicastTransportFactory

Use the configuration parameters in the following table to provide precise control over the plugin parameters in
ClusterUnicastTransportFactory.

Parameter Description
bindAddr Inet address to which ClaimCenter is to bind. This parameter can be useful if there are multiple-NIC
hosts. The default fallback for this parameter is the first non-loopback interface found on the host as
defined by the NetworkInterface Java API.
bindPort Port number to which ClaimCenter is to bind. This parameter can be useful for server hosts behind a
firewall. The default fallback for this parameter is an ephemeral port, a free port above 1024 that is
within a range supplied by the host operating system.
poolQueueCapacity Thread pool queue capacity. The default is 50.

poolSize Number of threads in the thread pool that handle inbound requests. The default is 4.

To set a plugin parameter, you must manually add that parameter to the plugin definition in the ClaimCenter plugin
editor. To access the plugin editor, navigate to the following location in ClaimCenter Studio and double-click the
plugin name:
configuration→config→Plugins→registry
See also
• Configuration Guide

Cluster Plugin System Properties Reference

You can use system properties, set at server startup from a command prompt, to modify certain parameters that
affect message transport in the ClaimCenter cluster. Using these system properties, you can precisely control such
transport variables as server address and bind port number to override the plugin parameter settings in the following
plugin implementations:
• ClusterFastBroadcastTransportFactory
• ClusterUnicastTransportFactory
The following list describes the plugin parameters that you can set through system properties at application start.

Plugin type Plugin parameter System property

ClusterFastBroadcastTransportFactory • bindAddr • gw.cluster.fudp.bind_addr

Cluster Plugin Parameter Reference 139

 System Administration Guide 9.0.5

Plugin type Plugin parameter System property

ClusterUnicastTransportFactory.bindAddr • bindAddr • gw.cluster.nbtcp.bind_addr
• bindPort • gw.cluster.nbtcp.bind_port

The exact syntax to use in setting system parameters at application server start is dependent on the application server
type. See “Setting JVM Options in ClaimCenter” on page 52 for more information.

Cache eviction messages

Guidewire does not guarantee the delivery of cache eviction messages in a ClaimCenter cluster. However, with that
said, the following is true:

Message plugin type Notes

ClusterBroadcastTransportFactory It is unlikely for there to be a missed eviction message with this type of
message transport as the message plugin reads the messages in order from
the database. It is possible in extreme circumstances such as losing
database connectivity for a time period longer than the configured
cleaning interval for the broadcast table. However, it is not likely.
ClusterFastBroadcastTransportFactory If enabled, ClaimCenter typically uses this type of cluster transport for
broadcasting cache eviction notices to cluster members. As this type of
message transport uses UDP packets, it is possible to drop a UDP packet
during transmission. Is is also possible for ClaimCenter to miss a packet if a
garbage collection operation takes longer than the wait time for
retransmitting a packet. If dropped packets become an issue, try setting
the retransmitIntervals parameter on the plugin to a smaller value than
its 10 second default value.

Logging cluster plugin parameters

By default, ClaimCenter logs cluster-related information at the INFO level in the server log. The cluster information
that ClaimCenter provides includes information on where the bind parameter values come, for example, from the
bind property default or from a parameter definition in the plugin editor.

Plugin Logging header

ClusterFastBroadcastFactory Server.Cluster.FastUdpMulticast

ClusterUnicastTransportFactory Server.Cluster.PointToPoint

Ephemeral port values

Unless you provide a value for the bindPort value on the ClusterUnicastTransportFactory plugin, ClaimCenter
randomly selects a free port above 1024 that is within a range supplied by the host operating system. You can view
information on an ephemeral port in the server log. Look for information that looks similar to the following:

Server.Cluster.PointToPoint Listener(host, port=#####): Listening

Cluster logging examples

In the first logging example, the cluster installation enables both the ClusterFastBroadcastFactory and
ClusterUnicastTransportFactory plugins. The installation does not, however, provide separate values for the
bind parameters for these plugins. Notice, therefore, that the following logging example provides information for
both plugins and indicates that bind values are the default values (first address of the first network
interface).

140 chapter 7 Understanding ClaimCenter Server Clustering

 System Administration Guide 9.0.5

19:50:30,131 INFO Server.Cluster Starting cluster channel...

19:51:45,885 INFO Server.Cluster.FastUdpMulticast Bind address is /nn.nn.n.nnn
(first address of the first network interface)
19:51:45,915 INFO Server.Cluster.PointToPoint com.guidewire.pl.cluster.internal.ptp.
PointToPointUnicastTransport@xxxxxxxx: Starting...
19:51:48,047 INFO Server.Cluster.PointToPoint Bind address is /nn.nn.n.nnn
(first address of the first network interface)
19:51:48,887 INFO Server.Cluster.PointToPoint Listener(serverid=prod1,port=53872): Listening...
19:51:48,954 INFO Server.Cluster.FastUdpMulticast Started on /nn.nn.n.nnn
19:51:48,959 INFO Server.Cluster Members joined the cluster: prod1 (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)
19:51:49,290 INFO Server.Cluster Inserted new record for prod1 node into cluster table
19:51:49,303 INFO Server.Cluster Cluster channel started.

In the second logging example, the cluster installation again enables both the ClusterFastBroadcastFactory and
ClusterUnicastTransportFactory plugins. In this case, however, the installation provide a value for the
ClusterUnicastTransportFactory.bindPort parameter, which is 53870, defined in the plugin editor for this
plugin.

11:51:23,059 INFO Starting cluster channel...

11:51:23,250 INFO Bind address is /nn.n.n.n (first address of the first network interface)
11:51:23,273 INFO com.guidewire.pl.cluster.internal.ptp.PointToPointUnicastTransport@xxxxx: Starting...
11:51:23,375 INFO Bind address is /nn.n.n.n (first address of the first network interface)
11:51:23,375 INFO Bind address is 53870 (specified via plugin configuration)
11:51:23,377 INFO Listener(serverid=prod1,port=53870): Listening...
11:51:23,465 INFO Started on /nn.n.n.n
11:51:23,470 INFO Members joined the cluster: prod1 (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)
11:51:23,869 INFO Inserted new record for prod1 node into cluster table
11:51:23,877 INFO Cluster channel started.

Server Roles
In general, Guidewire application cluster contains servers (cluster members) that manage the following types of
functionality.

Function Description
Online processing Server interactively manages requests from users logged into Guidewire ClaimCenter.
Background processing Server manages batch process execution, work queue processing, message destination processing,
lease management, and other similar items.

Guidewire categorizes each individual server instance in the cluster by its function, as defined by its role. In the base
configuration, ClaimCenter defines server roles to handle the following functionality. In a typical installation, only
those servers that support external requests such as user input use the ui server role.

Server Server role Servers with these roles manage...

function
Online “ui Server Role” on page 145 • Interactions (user requests) between the ClaimCenter user
processing interface and ClaimCenter itself.
• Web service calls; there is no distinct server role for web services.
However, any cluster member that receives a web service request
can process that request by default.
• Work queue processing, if there are distributed workers.
Guidewire recommends that a server with the ui role handle
these types of requests only during periods of low-load and during
off-peak hours.
Background “batch Server Role” on page 142 • Batch scheduling.
processing • Batch process execution.

Server Roles 141

 System Administration Guide 9.0.5

Server Server role Servers with these roles manage...

function
“messaging Server Role” on page 143 Message destination processing.
“scheduler Server Role” on page 144 Schedule handling.
“startable Server Role” on page 144 Startable service management.
“workqueue Server Role” on page Work queue management, if there are distributed workers.
144

It is possible for multiple servers in the ClaimCenter clusters to have the same server role. Servers that have the
same role type typically have similar resource allocations and configuration. Conversely, servers with different
server role types typically have different workloads and allocate their resources differently.

Server Roles and Lease Managers

Guidewire associates a specific lease manager type with each server role. Thus, a message destination lease manager
on a server with the messaging role manages message destinations for that server.
Each Guidewire server contains all types of lease managers. However, a lease manager only becomes active on a
server with a server role that matches its lease type.

Server Role Validation

ClaimCenter performs the following server role validation at server start up:
• Validation of roles used in the application configuration files – If ClaimCenter detects the use of an unknown role
in any of the configuration files, it throws an exception and refuses to start.
• Validation of roles assigned a specific server – If ClaimCenter detects the assignment of an unknown role to a
server, it prints a warning to the server log and ignores the unknown role.
See also
• “Component Lease Management” on page 159
• “Assigning Server Roles to ClaimCenter Cluster Servers” on page 50
• “JVM Options Specific to the runServer Build Command” on page 52

batch Server Role

Guidewire ClaimCenter distributes batch processing across all server instances in the cluster that have the batch
server role. At least one server in the ClaimCenter cluster must have the batch server role. It is possible to request
the start of a batch process from any server in the cluster. However, only a batch server is capable of performing the
work involved in the batch process. If the start request originates from a server that does not have the batch role,
that server communicates the request to the other members of cluster. A server with the batch role accepts the
request and performs the work.

Exclusive and non-exclusive batch processing

Guidewire categorizes batch processes into exclusive and non-exclusive batch processes:
• For exclusive batch processes, Guidewire guarantees that the batch process runs on exactly one cluster member
with the batch role at a time.
• For non-exclusive batch processes, Guidewire guarantees that a single submission of a batch process runs exactly
once. However, it is possible to submit non-exclusive batch processes for execution multiple times. In this case, it
is possible for the batch process to run once for each submission, possibly concurrently, on multiple servers that
have the correct server role.
Cluster members with the batch role use a batch-specific lease manager. Guidewire provides a configurable load
balancing strategy for those servers with the batch role.

142 chapter 7 Understanding ClaimCenter Server Clustering

 System Administration Guide 9.0.5

See also
• “Work Queues and Batch Processes, a Reference” on page 103
• “Understanding the Configuration Registry Element” on page 46
• “Batch Process Prioritization” on page 163

messaging Server Role

Message destinations and messaging server roles
In Guidewire ClaimCenter, it is possible to associate a specific server role with each message destination. In the
base configuration, ClaimCenter does not specify a server role for any of the predefined message destinations. For
all message destinations without a defined server role, ClaimCenter automatically sets the associated server role to
the base configuration role of messaging.
The following table describes the relationship between server roles and message destinations.

Server Messaging destination

Assigned messaging role Can acquire the lease of any message destination
Assigned role or host Can only acquire the lease to a message destination with an assigned role that matches that of
name the server. For example, suppose that there is a message destination with an assigned role of A.
Only a server that has role A can acquire the destination lease. A server with only role B cannot
acquire the lease.
It is possible to associate a specific host name with a specific message destination as well. Then,
only that server host can acquire the lease to the message destination.
No assigned messaging Cannot acquire the lease of any message destination.
role

You associate a specific server role or host name with a message destination in the Studio message-config.xml
editor. If you do not set a server role for a message destination, the messaging editor shows a default role of
messaging at the top of the screen.
You set a specific role on a ClaimCenter server through one of the following ways:
• Through an option on the gwb runServer command used to start the server from a command prompt.
• Through the registry metadata definitions in file config.xml.

Message destinations and leases

Guidewire ClaimCenter distributes message processing across all server instances that have the messaging server
role (which is any roled assigned to a message destination). Cluster members with these roles use a messaging-
specific lease manager. In this case, a lease corresponds with a message destination, with each destination having a
server declaration.
ClaimCenter creates message destination leases during messaging initialization. As each ClaimCenter starts, if it has
a messaging role, it looks for a message destination to start. This message destination is any available message
destination whose assigned role matches a role assigned to the server. ClaimCenter repeats this process until there
are no more qualified destinations to assign.
Each messaging lease manager accepts a listener from the messaging system. Upon the activation of a lease
operation by the lease manager such as deleting or expiring a messaging lease (and similar operations), the listener
notifies the messaging system. ClaimCenter then stops messaging destinations that are deleted or acquired by other
servers.
A shutdown command for a messaging destination initiates a request to expire the lease on the server for that
destination. The destination listener accepts that request and passes the request to the lease manager for that
destination.

Server Roles 143

 System Administration Guide 9.0.5

ClaimCenter periodically reviews all destination leases to determine if the leases are still valid and to look for new
leases to acquire. If a lease expires or the lease manager creates a new lease, ClaimCenter again searches for new
messaging destinations to assign.
Guidewire provides a configurable load balancing strategy for those servers with the messaging role.
See also
• “Understanding the Configuration Registry Element” on page 46
• “Messaging and Startable Service Load Balancing” on page 164
• “Messaging Tools Command” on page 420
• Integration Guide
• Configuration Guide

scheduler Server Role

Guidewire ClaimCenter typically utilizes only a small number of cluster members with the scheduler server role.
These server instances run multiple synchronized instances of the scheduler in parallel.

IMPORTANT Each server with the scheduler role must also have configuration parameter SchedulerEnabled set
to true in config.xml.

Servers with the scheduler role

Guidewire recommends that even small clusters have at least two servers with the scheduler role. This mitigates
the possibility of a single server with the scheduler role becoming a single point of failure. However, Guidewire
does not recommend more than four servers with this role in a cluster as large number of servers competing for
database resources can possibly increase database contention.
See also
• “Understanding the Configuration Registry Element” on page 46
• “Startable Services” on page 386

startable Server Role

Guidewire ClaimCenter implements certain plugins (services) as cluster singletons. These plugins implement the
IStartablePlugin interface and do not carry the distributed annotation. ClaimCenter runs a single instance of
these plugins only, on a server with the startable server role. Cluster member with this role use a plugin-specific
lease manager.
Guidewire provides a configurable load balancing strategy for those servers with the startable role.
Note: Guidewire defines an additional type of cluster singleton plugins, known as inbound integrations, in file
inbound-integration-config.xml.
See also
• “Understanding the Configuration Registry Element” on page 46
• “Messaging and Startable Service Load Balancing” on page 164
• “Startable Services” on page 386
• Integration Guide

workqueue Server Role

Guidewire ClaimCenter distributes work queues across all server instances that have the workqueue server role. By
default, each work queue starts a single worker on each server with the appropriate role, unless configured
otherwise.

144 chapter 7 Understanding ClaimCenter Server Clustering

 System Administration Guide 9.0.5

See also
• “Work Queues” on page 86
• “Work Queues and Server Roles” on page 99
• “Understanding the Configuration Registry Element” on page 46

ui Server Role
Guidewire ClaimCenter uses the ui server role as a placeholder role only. Guidewire ClaimCenter servers typically
operate in conjunction with a non-Guidewire load balancer that manages the user interface transactions.
ClaimCenter distributes web requests to the various cluster members according to the rules specified for the load
balancer. Any cluster server that receives a web request processes that request, regardless of role assignment.
See also
• “Understanding the Configuration Registry Element” on page 46
• “Guidewire ClaimCenter Cluster Installations” on page 134
• “Planning a ClaimCenter Cluster” on page 149

Example ClaimCenter Cluster Configuration

You assign a role to an individual server using the <registry> element in file config.xml. See “Understanding the
Configuration Registry Element” on page 46 for details.
The following sample code illustrates a ClaimCenter cluster definition with five cluster members.

<registry roles="batch, scheduler, workqueue, messaging, startable, ui>

<server env="prod" serverid="ccnode1"roles="batch, scheduler, messaging, startable"/>
<server env="prod" serverid="ccnode2"roles="batch, scheduler, messaging, startable"/>
<server env="prod" serverid="ccnode3"roles="workqueue, ui" />
<server env="prod" serverid="ccnode4"roles="workqueue, ui" />
<server env="prod" serverid="ccnode5"roles="ui" />
</registry>

Cluster Member Startup

As each member of the cluster starts, a number of events occur:
• During startup, each ClaimCenter server runs a checksum on its own configuration. The server then compares its
checksum with the configuration checksum stored in the database. If the startup server determines that the two
configurations are not compatible, it does not start.
• As each ClaimCenter server joins the cluster, it updates a membership table in the ClaimCenter database. All
cluster members periodically poll this table to determine cluster membership.
• During a rolling upgrade of the individual server members in the cluster, the startup server verifies that it is
running either the source (original) or target (new) configuration. If the server detects any other configuration, it
does not start.
See also
• “Guidewire ClaimCenter Cluster Installations” on page 134
• “Restarting the ClaimCenter Cluster Servers” on page 152
• “Configuration Compatibility” on page 169
• “Performing a Rolling Upgrade” on page 174

Server Roles 145

 System Administration Guide 9.0.5

Cluster Member Shutdown

In general, a ClaimCenter cluster contains the following types of servers:
• One or more user interface servers that process web requests, perform business transactions, and render web
pages.
• One or more non-user interface servers that manage batch processing, work queues, scheduling, message
destinations, and startable services (plugins).
The shutdown procedure for a Guidewire ClaimCenter cluster member is dependent on the role of server involved.
See also
• “User Interface Cluster Member Shutdown” on page 146
• “Non-ui Role Cluster Member Shutdown” on page 146

User Interface Cluster Member Shutdown

Guidewire ClaimCenter provides the means to schedule a planned ClaimCenter server shutdown. You schedule a
server shutdown through the Server Tools Cluster Components screen.
After you schedule a planned shutdown:
• ClaimCenter shows a banner to each logged in user on that server instance warning of the impending shutdown.
• ClaimCenter does not permit new users, except administrators, to log into that server instance.
See “Schedule a Planned Cluster Member Shutdown” on page 392 for more information.

Non-ui Role Cluster Member Shutdown

As with ClaimCenter user interface servers, you schedule a shutdown of a server cluster member with a non-user
interface role through the Server Tools Cluster Components screen. However, there are additional requirements for
shutting down a non-user interface server.
Stop any running background tasks in the following order:

Background task Shutdown considerations

1. Scheduler The scheduler typically runs on several servers, as a distributed component. Thus, stopping the
scheduler on one server does not affect the cluster.
2. Batch It is necessary for all running batch processes to complete before starting the server shutdown. In many
processing cases, it is better to let a batch process complete, without attempting to terminate the process.
However, as some batch processes can take significant amount of time to complete, potentially hours,
you often need to make an individual determination for each batch process.
See “About Planned Server Shutdowns” on page 387 for more information.
3. Work queue It is necessary to stop all work queue workers on the server that you intend to shut down. As
ClaimCenter distributes work queues across cluster members, stopping workers on one server does not
typically affect the cluster. However, it is possible for the overall performance of work items processing
to drop.
Stop work queues after stopping batch processing to stop generating business transactions that can
potentially generated messages.
4. Messaging It is necessary to stop messages destinations on the server that you intend to shut down. Other servers
destinations in the cluster must take over the stopped message destination.
5. Startable It is necessary to stop startable plugins (services) on the server that you intend to shut down. Other
plugins servers in the cluster must take over the stopped services.

Most background tasks, except batch processes, stop quickly as their units of work are small. The actual task
managers, for example the Batch Process Manager of the Message Destination Manager, do not instantly stop in a

146 chapter 7 Understanding ClaimCenter Server Clustering

 System Administration Guide 9.0.5

server shutdown. Instead, each lease manager moves to a passive mode in which it does not start new background
tasks and moves to stop or complete any currently running tasks.
After all components stop their background tasks, you can shut down the batch server safely.

Server Shutdown Monitoring

As it may take some time to stop all background tasks, you can use the following API method to track the
background task shutdown progress:

ISystemTools.getClusterState()

You can also use the following system_tools command options to gather information about a server and the state
of the server components:

system_tools -components
system_tools -nodes

See “System Tools Options” on page 423 for a discussion of these command options.

Cluster Member Shutdown 147

 System Administration Guide 9.0.5

148 chapter 7 Understanding ClaimCenter Server Clustering

chapter 8

Working with a ClaimCenter Cluster

This topic discusses ways to implement, manage, and monitor a Guidewire ClaimCenter cluster.

Planning a ClaimCenter Cluster

Plan the cluster so that if any one server fails, the other servers in the cluster can handle its traffic without being
overwhelmed. ClaimCenter servers in the cluster can run on separate computers, or you can run multiple servers on
the same computer. Guidewire recommends you maintain at least three ClaimCenter servers in the cluster, whether
on the same or different physical computers. With multiple servers running on the same computer, in the event of a
failure, then all servers are unusable. Of course, the exact configuration depends on specific usage needs.
To establish a cluster, you must also install your own load balancing solution. The load balancer acts as the bridge
between client connections and the private network. Clients send a connection request to the load balancer and it
routes the request to a ClaimCenter server. The load balancer must implement session affinity, meaning that it must
route connections from the same user session to the same ClaimCenter server. If the load balancer directed a user to
a different server, the session is reset. This can result in loss of unsaved data.
See also
• “Guidewire ClaimCenter Cluster Installations” on page 134
• Installation Guide

Create a Guidewire ClaimCenter Cluster

To create a ClaimCenter cluster, first define the individual servers in configuration, then deploy your configuration
to each server in the cluster.

Procedure
1. In your source configuration, for use on all ClaimCenter servers in the cluster, open config.xml for editing.
2. In config.xml, set the following clustering-related configuration parameters appropriately:
ClusteringEnabled
ClusterMemberPurgeDaysOld

Working with a ClaimCenter Cluster 149

 System Administration Guide 9.0.5

ConfigVerificationEnabled
PDFMergeHandlerLicenseKey
3. In config.xml, using the <registry> element, define the following:
a. The set of valid server roles for use in this cluster.
b. The server roles for each individual ClaimCenter server on the cluster.
Note: Guidewire does not require that you use the server <registry> element in config.xml to define the
individual server instances in the cluster. You can also set these values through JVM parameters at server
start up.
4. In config.xml, set the value for KeyGeneratorRangeSize.
5. Create a deployment WAR or EAR file for Guidewire ClaimCenter.
6. Install a ClaimCenter cluster server in the same way that you install a standalone ClaimCenter server.

IMPORTANT If you install multiple ClaimCenter servers on the same host machine, each ClaimCenter server
must run in its own JVM instance.

7. Start each member of the cluster in turn.

8. In ClaimCenter, navigate to the Server Tools Cluster Members screen and verify the information.

Result
See also
• “Understanding the Configuration Registry Element” on page 46
• “Cluster Members and Components” on page 386
• Installation Guide
• Configuration Guide

Managing a ClaimCenter Cluster

This topic discusses the ongoing management of a clustered environment.

Enabling Guidewire Clustering

To enable clustering in a Guidewire installation, set the ClusteringEnabled parameter in config.xml to true on
all cluster members, for example:

<param name="ClusteringEnabled" value="true"/>

To disable clustering and remove a server from a cluster, set this parameter to false on that server. After the server
is no longer in a cluster, it behaves as any other standalone ClaimCenter server.

150 chapter 8 Working with a ClaimCenter Cluster

 System Administration Guide 9.0.5

See also
• Configuration Guide

Adding a Server to a ClaimCenter Cluster

ClaimCenter does not require that you use the cluster registry in file config.xml to define cluster members. Its use
is optional in that regard. Instead:
• You can specify the server ID and server roles from the command prompt at server startup using JVM command
options.
• Or, you can specify a subset of the cluster server members in the cluster registry and set other server properties
from the command prompt.
For example, you can define the set of servers assigned the batch server role in the cluster registry and specify the
remaining server IDs through JVM options at server start.
In adding a server to the ClaimCenter cluster:
• Server not specified in config.xml – There is no issue. You can add a server to the cluster without any change of
configuration or stopping and restarting servers.
• Server specified in config.xml – It is possible to perform a rolling upgrade of each server instance in the cluster
to upgrade the cluster registry of each individual server instance in turn.
See also
• “Understanding the Configuration Registry Element” on page 46
• “JVM Options and Server Properties” on page 51
• “Add a Server to a ClaimCenter Cluster” on page 151
• “Performing a Rolling Upgrade” on page 174
• “Configuration Compatibility” on page 169

Performing a Cluster Configuration Upgrade

Guidewire provides a way to upgrade individual servers in a ClaimCenter cluster individually. This type of upgrade,
called a rolling upgrade, is in contrast to a full database and application upgrade. Guidewire permits only a few
specific changes to files, file types, and installation folders during a rolling upgrade of the individual servers in a
ClaimCenter cluster.
See also
• “Configuration Compatibility” on page 169
• “Performing a Rolling Upgrade” on page 174

Add a Server to a ClaimCenter Cluster

Procedure
1. Deploy the current cluster configuration WAR or EAR file to the server that you intend to add to the
ClaimCenter cluster.
2. Verify that this configuration has parameter ClusteringEnabled set to true in the configuration’s
config.xml file.
3. If using the config.xml server registry, you must set the serverid attribute for this server to a unique value
within the cluster.
If you use a non-unique serverid value, the server with the duplicate ID does not start and does not join the
cluster. See “Understanding the ClaimCenter Server Environment” on page 46.
4. Start the new server.

Managing a ClaimCenter Cluster 151

 System Administration Guide 9.0.5

Result
After you start the new server, it connects to the cluster and compares its configuration with the cluster configuration
stored in the ClaimCenter database. It performs a checksum of the config.xml file and checks the config
subdirectories. If the configurations differ, the server fails startup and ClaimCenter writes failure messages to the log
file.

Restarting the ClaimCenter Cluster Servers

There are several different scenarios that require you to bring down one or more members of the ClaimCenter cluster
and then restart the servers.

Server Restart after Server Maintenance

In performing maintenance on the servers in the ClaimCenter cluster, do the following for each ClaimCenter server
in the Guidewire cluster, as required:
• Set the server run level to maintenance.
• Perform the needed work.
• Restart the server.
See also
• “Place the Server in Maintenance Mode” on page 63
• “System Tools Command” on page 422

Server Restart after Rolling Upgrade

In an application configuration upgrade (known as rolling upgrade), you bring down a single server, in the cluster,
upgrade its application configuration, and bring that server back up. You then repeat this process with each member
of the ClaimCenter cluster in turn, until all cluster members use the upgraded configuration.

IMPORTANT Start the configuration upgrade on a single cluster server and let it fully initialize before starting the
upgrade process on the other cluster members.

Before starting a rolling upgrade, click Start Rolling Upgrade in the Server Tools Upgrade and Versions screen. You can
do this on any server in the ClaimCenter cluster. This action indicates that a rolling upgrade of the individual cluster
members is in progress.
After completing the upgrade of all cluster servers, click Rolling Upgrade Complete in the Server Tools Upgrade and
Versions screen. This action indicates that all servers in the cluster now use the upgrade WAR/EAR file and that the
rolling upgrade process is complete.
See also
• “Performing a Rolling Upgrade” on page 174
• “Unexpected Upgrades” on page 177

Server Restart after Full ClaimCenter Upgrade

In a full upgrade, you bring down all members of the ClaimCenter cluster completely. Before starting a full upgrade,
click Start Full Upgrade in the Server Tools Upgrade and Versions screen. You can do this on any server in the
ClaimCenter cluster. This action sets a flag in the ClaimCenter database to indicate that a full upgrade is in progress.
As long as the upgrade-in-progress flag exists, it is not possible to start a ClaimCenter cluster member that uses the
old (non-upgrade) WAR/EAR file.
In a full database upgrade, you must start a single cluster server and allow it to complete the full upgrade cycle
before starting the upgrade on the remaining servers. After all the servers in the ClaimCenter cluster start with the
upgrade WAR/EAR file, ClaimCenter automatically deletes the upgrade-in-progress flag from the ClaimCenter
database.

152 chapter 8 Working with a ClaimCenter Cluster

 System Administration Guide 9.0.5

Use the following guidelines as you bring up the individual cluster members:
• After the first cluster server completes the upgrade cycle, it is possible to bring up all other servers in the
ClaimCenter cluster in parallel. However, if starting a large numbers of servers causes resource contention, insert
a short interval of time between each server start, for example, 10 seconds.
• As a general rule, start servers that manage back-end processes first. For example, start servers with the batch
and messaging roles before starting servers with the ui role.
See also
• Upgrade Guide

Monitoring Cluster Health

You can monitor the health of a Guidewire application cluster in multiple ways.

Cluster Member Health

Typically, hardware or software load balancers check the health of the various cluster members and stop directing
traffic to a cluster member that stops responding. This check is very summary and simply verifies that the
corresponding network port responds. Therefore, it is possible that a load balancer redirects traffic to a cluster
member that is not capable of processing that traffic appropriately.
Some examples are that ClaimCenter is:
• Not fully started yet
• At the MAINTENANCE run level
• Experiencing significant issues, such as an out-of-memory condition
Some other infrastructure constraints exist. For example, some environments cannot use source IP stickiness to load-
balance conversational SOAP calls. In this situation, if using Guidewire ContactManager, you can instantiate one
ContactManager instance on each server machine hosting one or more ClaimCenter instances. You then configure
each ClaimCenter instance on that machine to direct contact requests to that local ContactManager instance. In this
scenario, if the local ContactManager instance is not functioning properly, it is advisable to stop directing traffic to
any of the ClaimCenter instances on that server.
Guidewire applications include a simple HTTP ping utility that enables you to check the application status with a
web browser. For instance, to check the status of an instance of ClaimCenter running on port 8080 of the local
computer, you would enter the following URL into a web browser:

http://localhost:8080/cc/ping

There are three possible responses by the web browser:

• If the application is running at the default MULTIUSER run level, the browser displays the number 2.
• If, however, the application is running in any mode other than MULTIUSER, the browser displays a specific ASCII
character, depending on the circumstances.
• If the ClaimCenter server is not running, the browser displays an HTTP failure message, depending on the
configuration of the server.
See the Integration Guide for a list of the specific ASCII characters that the ping utility can return. Invoking this
utility programmatically provides more granular information on the server’s status.
It is possible to configure the load balancers access this URL on a regular basis to determine the health of each
member of the cluster. You can then use these results to create redirection logic.
For example, suppose that you have an environment in which ClaimCenter directs traffic to a local ContactManager
instance. You then configure the load balancer to only redirect traffic to a ClaimCenter instance if both that instance
and the ContactManager instance on that server are accessible for user requests.

Monitoring Cluster Health 153

 System Administration Guide 9.0.5

Cluster Member Monitoring in ClaimCenter

The Server Tools Cluster screens, accessible to system administrators, provide information on your ClaimCenter
cluster installation. For ClaimCenter to make this screen visible, the value of cluster configuration parameter
ClusteringEnabled in config.xml must be true.
The Cluster screens provide information on the server cluster installation that includes the following items.

Information about the local server member Its server ID, the server roles assigned to this ClaimCenter
server, and similar information
Information about individual members recognized by the Their server IDs, number of active user sessions on each
cluster server instance, the server roles assigned to each application
instance, date and time of each server start, and similar
information
Information on the components running on each cluster The component state, date and time of each component start,
member and similar information
Information on any component lease failover in progress The date and time of the deadline in which to complete the
failover process
History of each member in the cluster The start and stop times for each cluster member, server
roles, run level, and similar information

From this screen, on any cluster member, you can start or cancel a planned shutdown for any recognized server
instance in the cluster.
See also
• See “Cluster Members and Components” on page 386 for more information on the Server Tools Cluster screens.
• See “Schedule a Planned Cluster Member Shutdown” on page 392 for information on starting or cancelling a
planned cluster member shutdown.

Monitor Cluster Members Using System Tools

About this task
Guidewire provides several system_tools command options that provide information about individual members of
the ClaimCenter cluster.

-components Provides information about the components that exist on each ClaimCenter server in the cluster.

-nodes Provides information about each ClaimCenter server in the cluster.

Procedure
1. Ensure that the ClaimCenter server is running.
2. Open a command prompt and navigate to the ClaimCenter installation directory:

admin/bin

3. Enter the following commands:

system_tools -user user -password password -components

system_tools -user user -password password -nodes

To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.

154 chapter 8 Working with a ClaimCenter Cluster

 System Administration Guide 9.0.5

Next steps
See also
• “System Tools Command” on page 422

Using the ClaimCenter ping Utility

Guidewire provides an unauthenticated web page that you can ping to access information about a ClaimCenter
server. To access this web page, use the following URL:

http://server:port/cc/ping?v=2

The ping utility returns the following types of information, depending on various factors, including whether the
server is a production server and whether the server start was successful.

Information type Result description

Planned shutdown status Shutdown status (for example, planned, ready) if the server is involved in a planned shutdown.
Server run level code ASCII decimal code, for example, 45, which represents the ‘(‘ character.
Server run level name Server run level, for example, MULTIUSER.
Server run level ordinal QuickStart (Jetty) run level, for example, 5, which corresponds to the MULTIUSER run level.
Server ID Name of the server host.
Server up time Time, in seconds, for which the server has been operational.
Server start up exception Exception that caused the server to fail start up, if applicable. By default, the ping utility does not
display this information on a production server.
Thread stack trace Stack trace of the thread performing the transition from one server run level to another. By default,
the ping utility does not display this information on a production server.

Using the ping Utility with a Production Server

Due to security concerns, the ClaimCenter ping utility does not return certain information if used with a production
server. In production mode, the ping utility does the following:
• It replaces the text of any exception that occurs at server start up with <not null>.
• It removes entirely the stack trace of the thread that performs the work of transitioning from one server run level
to another.
To view this information for a production mode server, start the production server with the following JVM command
option:
-Dgw.ping.servlet.show.stack=true

ping Utility Examples

The following examples illustrate the kind of information that the server generates for the different server scenarios:
• Successful server start
• Failed server start
• Server transition between run levels
• Planned server shutdown

Successful server start

The following code is an example of the ping utility return values if the ClaimCenter server starts successfully.

Monitoring Cluster Health 155

 System Administration Guide 9.0.5

{
"runLevelCode": 50,
"runLevelName": "MULTIUSER",
"runLevelOrdinal": 5,
"serverId": "ClaimCenterServer1",
"uptimeSeconds": 45
}

Failed server start

The following code is an example of the ping utility return values if the ClaimCenter development server fails to
start.

{
"runLevelCode": 40,
"runLevelName": "NODAEMONS",
"runLevelOrdinal": 3,
"serverId": "ClaimCenterServer1",
"startupException": "java.lang.RuntimeException: Test Startup Exception\n\tat
com.guidewire.pl.system.server.PingServerServletTest.
testInitTabStateJSONObjectShowsStartupException(PingServerServletTest.java:52)\n
\tat... ",
"uptimeSeconds": 40
}

The following code is an example of the ping utility return values if the ClaimCenter production server fails to start.
By default, ClaimCenter does not show the actual exception text and instead replaces the text with <not null>.

{
"runLevelCode": 40,
"runLevelName": "NODAEMONS",
"runLevelOrdinal": 3,
"serverId": "ClaimCenterServerPROD1",
"startupException": "<not null>",
"uptimeSeconds": 40
}

Server transition between run levels

The following code is an example of the ping utility return values on a development server while it is transitioning
from one run level to another. In this example, the server is transitioning from MULTIUSER run level to the DAEMONS
run level.

{
"attemptingTransition": {
"fromRunLevelName": "MULTIUSER",
"fromRunLevelOrdinal": 5,
"threadStackTrace": "Thread-142:TIMED_WAITING\n\tat sun.misc.Unsafe.park(Native Method)
\n\tat
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)\n\tat...”,
"toRunLevelName": "NODAEMONS",
"toRunLevelOrdinal": 3
},
"runLevelCode": 45,
"runLevelName": "DAEMONS",
"runLevelOrdinal": 4,
"serverId": "ClaimCenterServer1",

156 chapter 8 Working with a ClaimCenter Cluster

 System Administration Guide 9.0.5

"uptimeSeconds": 6814
}

Note: Use system_tools command options to transition a ClaimCenter server from one run level to another.

Planned server shutdown

The following code is an example of the ping utility return values.

{
"runLevelCode": 50,
"runLevelName": "MULTIUSER",
"runLevelOrdinal": 5,
"serverId": "testsrv1",
"uptimeSeconds": 1820
}

The following code is an example of the ping utility return values after starting a planned server shutdown from the
(Server Tools) Info Pages→Cluster Members page.

{
"plannedShutdownStatus": "activated",
"runLevelCode": 50,
"runLevelName": "MULTIUSER",
"runLevelOrdinal": 5,
"serverId":
"testsrv1",
"uptimeSeconds": 1825
}

The following code is an example of the ping utility return values after the server shutdown completes.

{
"plannedShutdownStatus": "ready",
"runLevelCode": 50,
"runLevelName": "MULTIUSER",
"runLevelOrdinal": 5,
"serverId": "testsrv1",
"uptimeSeconds": 1830
}

See also
• “Using the ping Utility with a Production Server” on page 155
• “Set the Server Run Level Through System Tools” on page 61
• “System Tools Command” on page 422

Using the ClaimCenter ping Utility 157

 System Administration Guide 9.0.5

158 chapter 8 Working with a ClaimCenter Cluster

chapter 9

Working with Component Leases

This topic discusses server component lease managers, lease management, and component lease load balancing.

Component Lease Management

A lease represents the right to perform some job for some period of time. Within a ClaimCenter application cluster, a
lease specifically represents one of the following:
• A single run of a batch process
• An instance of a message destination
• An instance of a startable plugin, if it is a single instance plugin
Each server instance in the ClaimCenter cluster has a lease manager for each lease type. However, some
functionality require a server with a specific server role. For example, only a server with the messaging role can
acquire and manage a lease for a message destination.
Each type of lease manager can perform the following actions:
• Create, acquire, renew, or retire a lease
• Release a lease or request the release of a lease from another lease manager
• Transfer a lease to, or request the transfer of a lease from, another lease manager

Lease Management Contention

ClaimCenter lease management provides for minimal contention if two lease managers attempt to acquire the same
lease at approximately the same time. Guidewire guarantees that only one server can acquire a specific lease.
Guidewire also guarantees that, for an exclusive batch process, only a single such lease can exist at any one time.

Working with Component Leases 159

 System Administration Guide 9.0.5

Simple Lease Management Lifecycle for a Batch Process

The following is a general description of the lease management lifecycle for a batch process:
• ClaimCenter translates the request to execute a batch process into the creation of an available lease and
broadcasts the lease availability to all servers in the cluster.
• A lease manager on a server with the batch role discovers the available lease and acquires it. No other server in
the cluster can acquire the lease. The lease is exclusive.
• The server with the active lease executes the batch process until processing is complete, with the server
extending the lease as needed.
• At the completion of the batch process, the server lease manager releases the lease.

Simple Lease Management Lifecycle for a Message Destination

The following is a general description of the lease management lifecycle for a message destination:
• At message initialization, ClaimCenter creates each enabled destination as an available lease.
• A lease manager on a server with the messaging role discover the available leases and attempts to acquire a
lease.
• As a server succeeds in acquiring a lease, it initializes the corresponding destination and places the destination
into the proper state (started, stopped, or suspended).
• A destination runs as intended, based on its state.
• A server periodically extends its destination lease until the messaging daemon stops, such as during server
shutdown or if you set the server run level to a level below DAEMONS.
• The server releases its destination lease.

Component Lease Failover

In the course of standard cluster operation, meaning no network issues, no lost cluster members or similar problems,
ClaimCenter periodically and automatically renews all component leases. The expiration of a lease is an exceptional
condition that requires attention. If a component lease expires, ClaimCenter considers the owner of that lease to have
failed. To detect this situation, the cluster lease managers periodically search for expired leases and initiate failover
of the expired lease to another member of the cluster.
After a lease manager detects an expired lease, it does the following:
• It terminates the lease.
• It updates the lease history.
• It deletes the lease or recreates the lease for acquisition by another cluster member, depending on the type of the
lease.

160 chapter 9 Working with Component Leases

 System Administration Guide 9.0.5

Automatic and Manual Failover

Guidewire ClaimCenter supports both automatic and manual failover of a component lease from one cluster member
to another member of the cluster. However, there are situations in which an automatic component failover is not
desirable, for example:
• There is a need for further additional configuration of an external third-party product before it is possible to start
a destination or plugin on a different computer.
• There is a need for further diagnostic testing to determine the exact cause of failure before initiating the failover
process.
See also
• See “Automatic Failover of a Component Lease” on page 161 for a description of the automatic failover process
that occurs after a lease expires.
• See “The Background Task Failover Plugin” on page 162 for a description of the default plugin implementation
that Guidewire provides for handling component lease failover.

Automatic Failover of a Component Lease

The following state diagram illustrates the different states in the automatic failover of a component lease.
ClaimCenter defines these states in the FailoverState typelist. The FailoverState typelist does not contain the
Completed state. The Completed state is implicit after the failover process completes and the lease manager deletes
the original lease.

Postponed

Not Started In Progress Completed

Failed

Initially, each component lease starts in the Not Started failover state. If a lease expires, the first lease manager that
discovers the expired lease does the following:
• It sets the lease to the In Progress failover state. After set to this state, the component associated with the lease
cannot run anywhere until there is a resolution of the issue that caused the lease to expire.
• It sets the Retry Failover field in the Server Tools Cluster Components screen to the following value.

CurrentTime + BackgroundTaskFailoverPlugin.FailoverTimeout

If more than one lease manager discovers the expired lease at the same time, only the first lease manager continues
the failover handling. The other lease managers detect that their SQL updates do not change anything and do not
continue the failover process for that lease.
The lease manager that started the failover calls the handleComponentNameFailover method on the
BackgroundTaskFailoverPlugin plugin to determine what to do next with the lease. The method returns one of the
following actions to handle the component lease failover.

Possible Description
actions
Complete The BackgroundTaskFailoverPlugin plugin logic confirms the lease failure and instructs the lease manager to
the failover complete the failover. In this case, the lease manager completes the failover process, either by deleting or
expiring the lease.

Component Lease Failover 161

 System Administration Guide 9.0.5

Possible Description
actions
Postpone It is possible that the BackgroundTaskFailoverPlugin plugin logic cannot reliably confirm the lease failure. In
the failover this case, it can postpone the failover process by returning an associated action to take and the time duration to
wait before taking that action. The lease manager updates the Retry Failover field in the Server Tools Cluster
Components screen with the following value:
Current Time + FailoverHandlingResult.Duration
After the updated retry failover time expires, the lease manager considers the lease expired and starts the
process of lease failover again.
Dismiss the It is possible that the BackgroundTaskFailoverPlugin plugin logic decides the specified background task did
failover not fail, or, that this particular task requires some manual action. In this case, the BackgroundTaskFailoverPlu
gin plugin logic dismisses or fails the automatic failover of the lease. The lease with its FailoverState set to
Failed remains in the database until there is some kind of manual intervention. The failover process does not
attempt to retry the automatic failover.
Use The BackgroundTaskFailoverPlugin plugin logic returns a failover handled acton. This action instructs the
external lease manager to do nothing with the lease. An external tool either deletes or renews the lease.
tool Calling an external tool to complete the failover can happen in any of the following ways:
• Programmatically calling the SystemToolsAPI.nodeFailed method.
• Programmatically calling the SystemToolsAPI.completeFailedFailover method.
• Clicking the Complete Failover button on the Server Tools Cluster Components screen.

If the cluster member that started the failover does not complete the failover in the specified retry failover time,
another cluster member detect this condition. The second cluster member then restarts the failover.
If at any point the original lease manager for the lease takes action to renew the lease, it does the following:
• It sets the FailOver state for the lease to Not Started.
• It resets the Retry Failover value to null.
At this point, the renewal of the lease resets the automatic failover process and negates any previous failover action
undertaken for the renewed lease.

The Background Task Failover Plugin

In the base configuration, Guidewire provides a BackgroundTaskFailoverPlugin plugin implementation that you
configure to manage component lease failover. The default implementation class for this plugin is Gosu class
DefaultBackgroundTaskFailoverPlugin. This default implementation makes the implicit assumption that there is
no manual cleanup work required for any batch process, message destination, or startable plugin after a component
lease failover.
At the failover of a component lease, the failover logic postpones the start of the failover process by several minutes,
the value of static variable INITIAL_POSTPONE_TIMEOUT. Failover logic implements the timeout to handle the case
in which the database was unavailable for a relatively long period of time, and then comes back online. The failover
postponement provides some time for the cluster members to recover and renew their leases.
After the failover postponement completes:
• If the cluster member that owns the lease does not return to the cluster, the automatic failover process continues.
• If the cluster member that owns the lease does return to the cluster, the automatic failover process fails.

Active External Monitoring

Some clusters use external monitoring and management software to watch the JVM processes of cluster members.
Guidewire provides Gosu class ActiveExternalMonitoringBackgroundTaskFailoverPlugin as a template that
you can to use in such installations. You must implement your own logic for the
notifyExternalMonitoringAboutExpiredlease method in this class.

162 chapter 9 Working with Component Leases

 System Administration Guide 9.0.5

Passive External Monitoring

Guidewire provides Gosu class PassiveExternalMonitoringBackgroundTaskFailoverPlugin as a template to
use in requesting a cluster member status report from external monitoring and management software. In this case,
the external monitoring and management software is not actively watching the JVM processes of cluster members.
Instead, it provides cluster member data on request.
Any monitoring and management software that you use for this purpose needs to be able to do the following:
• Check if a JVM process on a specified cluster member is alive and return the process uptime in seconds if the
process is running.
• Terminate a specified JVM process.
• Start a new JVM process.
The plugin implementation manages the failover.

Batch Process Prioritization

In the base configuration, Guidewire provides an implementation of a lightweight strategy to prioritize the running
of batch processes within the ClaimCenter cluster. File batch-process-config.xml provides a way to control the
execution of multiple batch processes. This file contains a required <settings> element and an optional <batch-
process> element.
In the base configuration, file batch-process-config.xml looks similar to the following example.

<batch-process-config xmlns="http://guidewire.com/batch-process-config">
<settings defaultServer="#batch"
startupDelay="0, 5, 15, 90, 180"
startupTimeout="600"
pollInterval="60"/>
<settings defaultServer="#batch"
startupDelay="0, 5, 15, 90, 180"
startupTimeout="60"
pollInterval="10"
env="test"/>
</batch-process-config>

The attributes on the various elements have the following meanings.

Element Attribute Required Description

settings defaultServer Yes Prefaced by the # (hashtag) symbol, this value specifies a server
role. For example, defaultServer="#batch" means that every
cluster member with the batch role is capable of running batch
processes.
Without the # symbol, this value specifies a server ID. For
example, defaultServer="node1" means that the cluster
member defined in the <registry> element in config.xml as se
rverid=node1 is capable of running batch processes.

pollInterval Yes Time, in seconds, between polling the database for new available
leases.
ClaimCenter also broadcasts information on new batch process
leases. See “Simple Lease Management Lifecycle for a Batch
Process” on page 160 for more information.
startupDelay Yes Number of seconds the batch process manager has to wait
before starting the next process. The delay is dependant on the
number of already running batch processes on the current
server. In the base configuration, Guidewire sets this value to the
following:
"0, 5, 15, 90, 180"

Batch Process Prioritization 163

 System Administration Guide 9.0.5

Element Attribute Required Description

These values have the following meaning:
0 – Start the first process immediately
5 – Start the second process after 5 seconds
15 – Start the third process after 15 seconds
90 – Start the fourth process after 90 seconds
180 – Start the fifth and all subsequent processes after 180
seconds
startupTimeout Yes Number of seconds allotted for a batch process to acquire a
lease. If the time expires without the batch process acquiring the
lease, ClaimCenter generates an error message similar to the
following text (600 is the default value):
ERROR Server.BatchProcess No one started batch process
after 600 seconds

env No Use to set setting values for distinct installation environments.

batch-process typeCode Yes Typecode value of a batch processes defined in the BatchProces
sType typelist.

env No Use to set batch prioritization values for distinct installation

environments.
server No Specifies a server on which to run the batch process specified by
the typeCode attribute.

Messaging and Startable Service Load Balancing

In the base configuration, Guidewire provides several default strategies for managing the load balancing of
messaging destinations and startable services (plugins) within the ClaimCenter cluster.
Gosu class DefaultBackgroundTaskLoadBalancingPlugin provides the implementation details for plugin
BackgroundTaskLoadBalancingPlugin. Using this class, you can implement the following strategies for load
balancing.

Strategy Description
Work stealing Periodically transfers a component lease from an over-utilized server to a server that is under-utilized.
Work acquisition Provides under-utilized servers with a chance to acquire a lease on an available component.

To enable or disable the use of each strategy, Guidewire provides the following plugin parameters.

Parameter Description
messageDestinationLoadBalancingMode Manages the load balancing strategies for message destinations.

startablePluginLoadBalancingMode Manages the load balancing strategies for startable services.

Each of these plugin parameters can take one of the following values.

Value Description
disabled Disables both the work acquisition and work stealing strategies.
dynamic Enables both the work acquisition and work stealing strategies.
notransfer Enables the work acquisition strategy only.

164 chapter 9 Working with Component Leases

 System Administration Guide 9.0.5

It is possible to modify Gosu class DefaultBackgroundTaskLoadBalancingPlugin to meet your business needs.

Messaging and Startable Service Load Balancing 165

 System Administration Guide 9.0.5

166 chapter 9 Working with Component Leases

chapter 10

Deploying Configuration Changes in a

Clustered Environment

Guidewire provides a way to deploy configuration changes to each individual server in a ClaimCenter cluster.
Guidewire calls this type of configuration deployment a rolling upgrade, in the sense that upgrade changes move
through the cluster, one server instance at a time. This type of configuration deployment is in contrast to a full
database and application upgrade. A full upgrade requires that you bring down all ClaimCenter servers in the cluster
to complete the upgrade. Typically, a full upgrade includes changes to the ClaimCenter database.

Rolling Upgrade Overview

To support the need to perform regular configuration updates without stopping the entire production installation,
Guidewire provides a way to update each application instance in a ClaimCenter cluster separately. Guidewire calls
this a rolling upgrade or configuration deployment. In a rolling upgrade, it is possible to stop an individual
ClaimCenter server and deploy configuration changes to it without stopping the other servers in the cluster. In this
way, ClaimCenter continues to function even through the configuration process.
For this to be possible, Guidewire restricts the types of configuration changes that are possible with a rolling
upgrade. The target (new) upgrade configuration must be compatible with the source (old) application configuration.
Guidewire provides a command line tool that you use to determine if the two application configurations are
compatible. If the two configurations are compatible, you can perform a rolling upgrade of each server instance in
the cluster. If not, you must perform a full application and database upgrade.
The requirements for a rolling upgrade are much simpler than for a full application upgrade. Thus, it is possible for a
ClaimCenter system administrator to perform a rolling upgrade of the cluster server members. Alternatively, a
member of your IT department can perform this type of upgrade.

Deploying Configuration Changes in a Clustered Environment 167

 System Administration Guide 9.0.5

IMPORTANT You cannot use a rolling upgrade to upgrade from a major or minor version of Guidewire
ClaimCenter to another major or minor version of ClaimCenter. In almost every case, a rolling upgrade is not
suitable for Guidewire application patches or maintenance releases. Only if an application patch meets the
compatibility criteria necessary for a rolling upgrade is a rolling upgrade of that patch possible. A rolling upgrade
is not a replacement or substitute for a full application and database upgrade.

Risks Associated with Rolling Upgrade of Cluster Server Members

In performing a rolling upgrade, you trade safety for convenience. In particular, there are risks associated with
modifying any configuration related to distributed processing such as batch processes and work queues. Do not
attempt to perform a rolling upgrade of the production ClaimCenter cluster if your changes affect those areas of the
application.
It is possible for individual ClaimCenter servers in the cluster to fail the configuration deployment process for a
variety of reasons. If so, you need to spend time testing and recovering from a failed attempt to return a server to a
safe state. In particular, you need to review any entities that possibly changed due to the deployment process.

Backing Out a Rolling Upgrade

It is possible to back out configuration changes on a given server application instance, depending on the state of the
configuration deployment on that instance. Guidewire does not recommend that you back out an ongoing
deployment on a server instance except in extraordinary circumstances. If you do so, you need to test that the server
configuration returns to a safe state.

Assumptions Around a Rolling Upgrade

As a rolling upgrade occurs in a live production environment, it is important to understand the assumptions
underlying a rolling upgrade.
After starting the rolling upgrade:
• Guidewire expects most ClaimCenter users to continue to interact with the cluster members running the source
build.
• Guidewire expects only a small set of users to interact with the cluster members running the target build.
• Guidewire expects a user to not switch between the source and target configurations as a matter of course. For
example, Guidewire does not expect a user to process the same claim on two different cluster members with
different configurations by switching back and forth between the configurations.
Guidewire expects you to execute and complete a rolling upgrade during a single scheduled maintenance window.
The maintenance window is a period of low activity that spans a duration of hours, not days.
See also
• “Configuration Compatibility” on page 169
• “Verification of Configuration Compatibility” on page 173
• “Unexpected Upgrades” on page 177

Differences between a Rolling Upgrade and a Full Upgrade

Guidewire provides two different ways to modify the configuration of a ClaimCenter server in a cluster:
• Full upgrade
• Rolling upgrade
Each of these upgrade types has associated advantages and disadvantages. You use each upgrade type in different
circumstances.

168 chapter 10 Deploying Configuration Changes in a Clustered Environment

 System Administration Guide 9.0.5

Full Application and Database Upgrade

A full application upgrade has the following functionality:
• Supports either a single or multiple server configuration and upgrade.
• Supports making significant changes to both the ClaimCenter application and database.
• Requires that you stop the entire ClaimCenter production installation for a period of time.
• Requires a significant amount of testing before and after complex changes.
It is possible to start a full upgrade from any server instance in the ClaimCenter cluster, from the Server Tools
Upgrade and Versions screen.

Rolling Cluster Member Upgrade

A rolling upgrade of the individual server members in the cluster has the following functionality:
• Supports configuration deployment to multiple server instances.
• Successively targets a single cluster member for configuration deployment while leaving the remaining cluster
members available for the processing of ClaimCenter operations.
• Supports a limited set of configuration changes.
• Requires that the new target configuration be compatible with the existing source configuration.
• Supports a command-line utility that checks the compatibility of the source and target configurations before
deployment.
• Supports configuration deployment management and tracking from within ClaimCenter.
It is possible to start a rolling upgrade from any server instance in the ClaimCenter cluster, from the Server Tools
Upgrade and Versions screen.
See also
• “Configuration Compatibility” on page 169
• “Verification of Configuration Compatibility” on page 173
• “Upgrade and Versions” on page 393

Configuration Compatibility
Guidewire permits changes to the following files, file types, and installation folders in ClaimCenter Studio during
configuration deployment to the individual members of a cluster.

Item Safe actions

config.xml It is safe to change the value of a configuration parameter that Guidewire designates as possible to
vary on different servers in the same environment. Guidewire lists these parameters as Set for
Environment: Yes in the parameter description. To access a list of configuration parameters for
review, see .
database-config.xml It is safe to change the value of attribute useoraclestatspreferences (from false to true or true
to false) during a rolling upgrade. However, if you reset the value of this attribute from true to fal
se, you must also perform manual steps to complete the process. See “Revert to DBStats Batch
Processing for Database Statistics” on page 288 for more information.
gsrc It is generally safe to add new Gosu classes. It is absolutely unsafe to modify or remove a Gosu class.
import It is safe for the import directory to differ across individual ClaimCenter instances, as long as the
database is not empty on server startup. This is because the import directory contains files that
ClaimCenter imports by default on server startup into an empty database.
Localizations It is safe to add, delete, or modify any of the display keys in the various display_languageCode.pro
perties files.

Configuration Compatibility 169

 System Administration Guide 9.0.5

Item Safe actions

IMPORTANT It is not safe to make changes to either language.xml or localization_localeCode.x
ml as these files must remain consistent across all cluster members.

plugin It is safe to modify a .gwp file in the root plugin directory, including pointing to a new
implementation class.
Guidewire does not permit the following with respect to plugins in a rolling upgrade:
• Modifications to non-distributed, startable plugins
• Modifications to files in the plugin/Gosu or plugin/shared directories
Changes to plugin implementations can cause individual ClaimCenter instances to have different
versions of an object. Thus, it is possible that ClaimCenter instances running the source configuration
to consider objects create or updated on the target configuration to be invalid.
rules It is safe to perform the following operations on ClaimCenter Gosu rules:
• Add a new rule
• Modify an existing rule, including enabling or disabling the rule
• Rename a rule, which is actually deleting a rule and adding the rule under a different name
Changes to pre-update or validation rules can cause individual ClaimCenter instances to have
different versions of an object. Thus, it is possible that ClaimCenter instances running the source
configuration. to consider the objects created or updated on the target configuration to be invalid.
servlets It is generally safe to make changes to servlets. However, a change to an existing servlet has the
potential to break integration with a third-party product.
IMPORTANT Guidewire recommends that you undertake thorough testing after making changes to
servlet configuration to verify that all product integrations continue to work as intended.
templates It is safe to make modifications to note, email, and document templates as the impact of a change to
a template affects only that template.
typelists Depending on the type of typelist, it is generally safe to add typecodes to an existing typelist or to
add an entirely new typelist. It is also safe to edit the typelist description or change its category. It is
unsafe, however, to make changes to LOB typelists outside of a very narrow context. See “Making
Changes to LOB Typelists in a Rolling Upgrade” on page 171 for details.
Note: If you add a typelist, the typelist shows on servers running the target (new) configuration only.
On servers running the source (old) configuration, the typelist shows as blank. See “Making Changes
to Typelists in a Rolling Upgrade” on page 170.
web It is safe to add or a delete a PCF or to modify an existing PCF.
webservices It is generally safe to make changes to web services. However, a change to an existing web service
has the potential to break integration with a third-party product.
IMPORTANT Guidewire recommends that you undertake thorough testing after making changes to
web services configuration to verify that all product integrations continue to work as intended.

See also
• “Verification of Configuration Compatibility” on page 173

Making Changes to Typelists in a Rolling Upgrade

Guidewire permits only certain changes to typelists during a rolling upgrade of application servers in a ClaimCenter
cluster.

170 chapter 10 Deploying Configuration Changes in a Clustered Environment

 System Administration Guide 9.0.5

Typelist Changes that Are Safe to Make in a Rolling Upgrade

In general, the following typelist configuration changes are safe to make in a rolling upgrade:
• Adding a new typelist
• Adding one or more typecodes to an existing typelist, either by extension or otherwise
• Modifying the name, description, priority, and sort order of an existing typecode
There are only certain configuration changes that you can make to ClaimCenter LOB typelists that are safe to make
in a rolling upgrade. See “Making Changes to LOB Typelists in a Rolling Upgrade” on page 171 for information.

Typelist Changes that Are Not Safe to Make in a Rolling Upgrade

It general, the following typelist configuration changes are not safe to make in a rolling upgrade:
• Deleting an existing typecode
• Renaming an existing typecode, which is essentially a delete and add operation
• Adding a typecode to a typelist marked as final

Typelists that You Cannot Change in a Rolling Upgrade

There are specific typelists for which it is not safe to make a change of any kind in a rolling upgrade. These typelists
are:
• AggLimitCalcCriteria
• BatchProcessType
• Currency
• GroupType
• LanguageType
• RoleType
• SystemPermissionType
• UserRole
• ValidationLevel
Guidewire maintains the list of blacklisted typelists in the following internal files:
• cc-rolling-upgrade-typelist-blacklist.txt
• pl-rolling-upgrade-typelist-blacklist.txt

It is not possible to modify the list of blacklisted typelists in any way.

Making Changes to LOB Typelists in a Rolling Upgrade

In the ClaimCenter base configuration, Guidewire provides the following LOB (Line of Business) typelists (listed in
hierarchical order):
• LossType
• LOBCode
• PolicyType
• CoverageType
• CoverageSubtype
• ExposureType
Guidewire uses the line of business typelists to configure the ClaimCenter screens used for entering a new claim and
working with existing claims. For example, a number of ClaimCenter modal PCF files use the LossType and

Making Changes to LOB Typelists in a Rolling Upgrade 171

 System Administration Guide 9.0.5

ExposureType typelist typecodes to control the list view or detail view that shows on the screen. Guidewire also
uses the loss type typecodes to control the visibility of menus and submenus within the claim screens in
ClaimCenter.
Because of the interconnections between LOB typelists and ClaimCenter claim screens, Guidewire severely restricts
the kinds of changes that you can make to the LOB typelists in a rolling upgrade. In general, you can only make
changes safely to certain typefilters on the LossType typelist.
See also
• Configuration Guide

Adding New Loss Types in a Rolling Upgrade

The following configuration parameters control application behavior for the ClaimCenter Actions→New Exposure
menu and its submenus:

Configuration parameter Controls ClaimCenter menu element…

ShowNewExposureMenuForLossTypes Actions→New Exposure

ShowNewExposureChooseByCoverageTypeMenuForLossTypes Actions→New Exposure→Chose by Coverage Type

ShowNewExposureChooseByCoverageMenuForLossTypes Actions→New Exposure→Chose by Coverage

HidePolicyObjectsWithNoCoveragesForLossTypes Submenus of Actions→New Exposure→Chose by Coverage

If you modify any of these configuration parameters, you must then restart the server and let the ClaimCenter server
upgrade the database.
However, it is possible to affect the functionality and behavior of the New Exposure menu and its submenus in the
same manner by modifying typefilters on the LossType typelist. Changes that you make to the LossType typelist do
not require a database upgrade. Instead, you can implement these changes through a rolling upgrade of the servers in
the ClaimCenter cluster.
In the base configuration, Guidewire provides a LossType typefilter, with the same name, for each associated
configuration parameter. The typelist editor shows these typefilters on the LossType typelist Typelist tab. To affect
the behavior of the New Exposure menu and submenus, add a typekey to a typefilter in a similar manner as adding a
value to the associated configuration parameter.
ClaimCenter merges any changes that you make to one of these typefilter with the typecode list in the configuration
parameter with the same name as the typefilter. In other words, the two lists are additive. For example, suppose that
configuration parameter X contains a typecode list of A, B, C, D. You then modify the LossType typefilter with the
same name and add typecode E. ClaimCenter then uses loss type typecodes A, B, C, D, and E to determine what to
show in the claim screens.
See also
• Configuration Guide

Add a New Loss Type in Rolling Upgrade

1. Follow the instructions for creating a new loss type as outlined in .
2. Include the loss type to one of the following typefilters on the LossType typelist:
• ShowNewExposureMenuForLossTypes
• ShowNewExposureChooseByCoverageTypeMenuForLossTypes
• ShowNewExposureChooseByCoverageMenuForLossTypes
• HidePolicyObjectsWithNoCoveragesForLossTypes
3. Create new detail and list views for the new loss type as needed.
4. Perform the rolling upgrade of the application servers in the ClaimCenter cluster.
172 chapter 10 Deploying Configuration Changes in a Clustered Environment
 System Administration Guide 9.0.5

5. the Configuration Guide

Adding New Exposure Types in a Rolling Upgrade

ClaimCenter uses the typecodes on the ExposureType typelist to determine which modal PCF file to show in
creating an incident on an exposure. Internal Gosu enhancement ExposureUI.gsx uses the ExposureType typecodes
to determine the type of incident to create. Thus:
• For certain exposure types, such as Vehicle Damage, the enhancement attempts to first determine the coverage,
then if possible, to reuse an existing incident of the same coverage. If it is not possible to reuse an existing
incident, then the enhancement creates an incident of the necessary type on the exposure.
• For other exposure types, such as Personal Property Damage, the enhancement always creates a new incident of
the required type on the exposure.
Any attempt to add new exposure type typecodes directly to the ExposureUI.gsx enhancement in a rolling upgrade
causes the upgrade to fail. Instead, add the new exposure type typecode to one of the following typefilters on the
ExposureType typelist:
• IncidentFromCoverage
• IncidentAlwaysNew
The typelist editor shows the typefilters on the ExposureType typelist Typelist tab.

Add New Exposure Type in Rolling Upgrade

1. Follow the instructions for creating a new exposure type as outlined in the Configuration Guide.
2. Include the new exposure type typecode in one of the following typefilters on the ExposureType typelist:
• IncidentAlwaysNew
• IncidentFromCoverage
3. Create new detail and list views for the new exposure type as needed.
4. Ensure that any PCF file that uses the new exposure type has Incident as a required field if you added the
typecode to the IncidentFfromCoverage typefilter.
5. Perform the rolling upgrade of the application servers in the ClaimCenter cluster.

Verification of Configuration Compatibility

Guidewire provides a command line build tool to use in determining if the source and target application
configurations are sufficiently compatible to support configuration deployment in a clustered environment. To use,
run the following command from a command prompt on any cluster member.

system_tools -verifyconfig filepath

This utility compares the following two server configurations:

• The new or target server configuration contained in a WAR/EAR file pointed to by the filepath parameter.
• The existing server configuration of the cluster member on which you run the system_tools command.
The tool provides an on-screen report that contains information about the feasibility of a configuration deployment
for the server members in the cluster. For example, the tool provides the following types of information:

Configurations are different Requires a full server upgrade. Guidewire does not permit a configuration deployment (rolling
upgrade) using the target configuration.
Configurations are identical No upgrade is necessary.
Configurations are compatible Guidewire permits a configuration deployment of these changes.

Making Changes to LOB Typelists in a Rolling Upgrade 173

 System Administration Guide 9.0.5

If a configuration deployment is not possible, the command lists the incompatible or missing files.
If a configuration deployment is in progress, there are two possible configurations active in the cluster. Each
individual server instance in the cluster is using either the source configuration or the target configuration.
The -verifyconfig command option checks for both configurations on the cluster member on which you run the
command and reports which of the configurations is active on this cluster member. If neither configuration is active,
the command reports that a configuration deployment is in progress and that it is not possible to verify the
configuration at this time.
See also
• “System Tools Command” on page 422

Performing a Rolling Upgrade

Performing a rolling upgrade (configuration deployment) on your production ClaimCenter cluster requires extensive
testing to minimize the risk of deploying new configuration changes in a production environment.
The following list describes the steps involved in performing a rolling upgrade.

Step Description For more information

Prepare Verify that your environment is set up correctly for a rolling “Prepare for a Rolling Upgrade” on page 174
upgrade.
Test Test the ClaimCenter upgrade configuration in a non-production “Perform a Rolling Upgrade in a Test Environment”
environment before you implement the configuration in a on page 175
production environment.
Upgrade Upgrade the servers in your production environment with the “Perform a Rolling Upgrade in a Production
new ClaimCenter configuration, one by one. Environment” on page 176

Rolling Upgrade Terminology

Guidewire uses the following term definitions in the discussion on rolling upgrade.

Instance An individual ClaimCenter server running in a VM (Virtual Machine) or JVM (Java Virtual Machine) or
stand-alone ClaimCenter server.
Test instance A ClaimCenter instance with the same data model and EAR/WAR build file as that used on a production
instance. The test cluster does not need to have the same number of test instances as the production
cluster. However, there needs to be at least two instances in the test cluster to be able to test the rolling
upgrade process.
Production instance A member of the production cluster accessed and used by external ClaimCenter users.

Prepare for a Rolling Upgrade

Before you begin
Before you begin the rolling upgrade process, review “Performing a Rolling Upgrade” on page 174.

About this task

The following list describes the necessary actions that you need to undertake before performing the rolling upgrade.

Action How? More information

Verify that the database schema Use the database schema verification tool available from “Database Table Info” on
matches the ClaimCenter data the Server Tools Database Table Info screen. page 366

174 chapter 10 Deploying Configuration Changes in a Clustered Environment

 System Administration Guide 9.0.5

Action How? More information

model as defined in the data
model metadata files.
Verify that the source and target Use the system_tools -verifyconfig utility to verify “Verification of Configuration
configurations are compatible. compatibility between the old and new configurations. Compatibility” on page 173
Back up your current application Create a robust database backup and restore strategy in Consult with your database
configuration. case there are problems upgrading individual cluster administrator
members.
Create a custom version label for This step is optional. However, a version label provides a “Understanding Guidewire
your configuration deployment. way to identify this configuration deployment for future Software Versioning” on page
reference. 395

Next steps
After you complete these steps, continue to “Perform a Rolling Upgrade in a Test Environment” on page 175.

Perform a Rolling Upgrade in a Test Environment

Before you begin
Before you begin testing your rolling upgrade configuration, review “Prepare for a Rolling Upgrade” on page 174.

Procedure
1. In file database-config.xml, verify that the <database> element autoupgrade attribute is set to manual (or
non-existent).
If the attribute is missing, the default value for this attribute is manual. The value cannot be full.
2. Create a new EAR/WAR ClaimCenter build that includes all the proposed configuration changes. The build
name must includes some identification such as a date or a version number.
3. Place the EAR/WAR build in a local directory on a test instance.
4. Run the following command option from the command prompt.
system_tools -verifyconfig filepath
This verification process tests if the target configuration is compatible with the source configuration on that
server. If the configuration verification tool indicates that the proposed changes are compatible with the
existing configuration, continue to the next step.
5. Back up the test database.
6. On any server instance in the cluster, navigate to the Server Tools Upgrade and Versions screen and click Start
Rolling Upgrade.
7. Bring down one of the servers in the test environment and deploy the new EAR/WAR file to this server
instance.
8. Bring the test instance back up.
9. Perform user acceptance testing on the test cluster, on both the old and new configurations. .
If testing indicates that there are no major issues in running the two configurations simultaneously, continue to
the next step.
10. Deploy the new EAR/WAR file to all test instances.
11. Navigate to the Server Tools Upgrade and Versions screen of any server instance in the test environment.
12. Click Rolling Upgrade Complete.
This action clears the upgrade flag indicating that a rolling upgrade is in progress. The rolling upgrade of the
new configuration changes is now complete.

Performing a Rolling Upgrade 175

 System Administration Guide 9.0.5

13. Perform acceptance testing on all the test instances to verify that ClaimCenter works as intended.

Next steps
If testing indicates that there are no issues with the new configuration running on all test instances, continue to
“Perform a Rolling Upgrade in a Production Environment” on page 176.

Perform a Rolling Upgrade in a Production Environment

Before you begin
Before performing a rolling upgrade in a production environment, ensure that you have completed all steps in
“Perform a Rolling Upgrade in a Test Environment” on page 175.

Procedure
1. In file database-config.xml, verify that the <database> element autoupgrade attribute is set to manual (or
non-existent).
If the attribute is missing, the default value for this attribute is manual. The value cannot be full.
2. On any instance in the ClaimCenter production cluster, navigate to the Server Tools Upgrade and Versions
screen.
a. Click Start Rolling Upgrade.
b. Verify the checklist of upgrade prerequisites.
c. Click Start Rolling Upgrade.
This action sets a flag in the ClaimCenter database that indicates a rolling upgrade is in progress.
3. Navigate to the Server Tools Cluster Members screen on any server instance.
a. For the instance that you want to shutdown, click Start Planned Shutdown in the Actions column.
b. Set the appropriate shutdown parameters in the Schedule Planned Shutdown screen.
c. Click Schedule Shutdown.
This action schedules a shutdown of the specified instance. All users logged into this ClaimCenter
instance see an on-screen message indicating that a planned shutdown is in progress. After the scheduled
period of time elapses, there are no more user connections to this production instance.
4. Deploy the new ClaimCenter build to the production instance that you shut down.
5. Bring the instance with the configuration build back up.
6. Perform acceptance testing on the production instances to determine if there are any major issues with running
the two configurations in the same cluster.
If testing indicates that there are no major issues with the new configuration in the production cluster, continue
to the next step. If there are issues, repeat the previous steps until you have upgraded all the production
instances with the new configuration build.
7. Perform another round of acceptance testing.
If testing indicates that there are no major issues with the new configuration on the production instances,
continue to the next step.
8. Navigate to the Server Tools Upgrade and Versions screen of any instance in the ClaimCenter production cluster.
9. Click Rolling Upgrade Complete.
This action clears the upgrade flag indicating that a rolling upgrade is in progress. The rolling upgrade of the
new configuration changes is now complete.
10. Perform another round of acceptance testing to ensure that there are no issues with the new configuration.

176 chapter 10 Deploying Configuration Changes in a Clustered Environment

 System Administration Guide 9.0.5

Unexpected Upgrades
Any time that you deploy a new WAR/EAR file to a ClaimCenter server and restart the server, ClaimCenter assumes
that an upgrade is in progress. To prevent the unexpected upgrade of a server, Guidewire requires that you set an
upgrade flag in ClaimCenter before starting either a full or rolling upgrade.
Guidewire requires the use of this flag to mitigate the risk of accidentally triggering an unexpected upgrade. As a
consequence, however, it is possible to encounter situations in which the ClaimCenter server does not start. In that
case, you must undertake a recovery sequence to return the server to a state in which it can start.

Full Upgrade
For a full upgrade, Guidewire first requires that you click Start Full Upgrade in the Server Tools Upgrade and Versions
screen (on any cluster member). This action signals your intention to perform a full upgrade. ClaimCenter then sets
a database flag to indicate that a full upgrade is in progress. After you complete the upgrade, ClaimCenter deletes
the database flag. You must set the upgrade flag again before starting a new full upgrade.
It is possible to set the full upgrade in progress flag in the following ways as well.

System To set the upgrade flag through system tools, use the following command option:
tools system_tools -startfullupgrade
At least one cluster member must be running in order for you to use this option.
Web To set the upgrade flag using web services, call the SystemToolsAPI web service method startFullUpgrade. At
services least one cluster member must be running in order for you to use this option.
Java system To set the upgrade flag through a Java system property, use the following system parameter to set the expected
property date of the upgrade while starting one of the affected servers:
gwb runServer -Dgw.cc.full.upgrade.intended.date=date
The date parameter is the current date in yyyyMMdd format.

If you encounter a situation in which all cluster members refuse to start because the upgrade flag was not set, you
cannot set the upgrade flag through the server. Instead, you must set the upgrade flag using the Java system
parameter.

Rolling Upgrade
For a rolling upgrade, Guidewire first requires that you click Start Rolling Upgrade in the Upgrade and Versions screen
(on any cluster member). This action signals your intention to perform a rolling upgrade and sets a rolling upgrade
in progress database flag. If you do not set the upgrade flag, ClaimCenter refuses to start a rolling upgrade.
After you complete the upgrade of all servers in the cluster, you must click Rolling Upgrade Complete on the Upgrade
and Versions screen, which removes the upgrade flag. After you do so, it is not possible start a cluster member
running the source (old) configuration.
Guidewire permits a rolling upgrade of the individual members of a ClaimCenter cluster under certain conditions
only. In effect, the source (old) configuration and target (new) configuration must be compatible in very specific
ways.
Thus, during a rolling upgrade, if you mistakenly deploy an incompatible WAR/EAR file to a ClaimCenter server,
you can encounter a situation in which the server does not start. This is true whether you have set the rolling upgrade
in progress flag. In this case, remove the incompatible WAR/EAR file and deploy a compatible WAR/EAR file
before attempting to restart the server.

Unexpected Upgrades 177

 System Administration Guide 9.0.5

See also
• “Configuration Compatibility” on page 169
• “Verification of Configuration Compatibility” on page 173

Configuration Upgrade of a Production Stand-alone ClaimCenter

Server
A stand-alone server has configuration parameter ClusteringEnabled set to false. The use of a rolling
(configuration) upgrade is not possible on a stand-alone server. However, some upgrade changes require a full
database upgrade, other upgrade changes do not.
A full upgrade on a production ClaimCenter stand-alone server causes the following behavior.

Upgrade type Example Behavior

Data model Changing the value of a semi-permanent If you do not initiate a full upgrade from the Server Tools Upgrade
configuration parameter. ClaimCenter and Versions screen, the application server does not start.
writes these kinds of changes to the Conversely, if you do initiate a full upgrade from Server Tools, the
application database. upgrade completes and ClaimCenter updates the Upgrade and
Versions screen.

Configuration Changing the value of a general It does not matter whether you initiate a full upgrade from the
configuration parameter, one that is Server Tools Upgrade and Versions screen. In any case, the
neither permanent nor semi-permanent. application server starts without any errors or warnings and
ClaimCenter reads these kinds of changes ClaimCenter updates the Upgrade and Versions screen.
from configuration files.

178 chapter 10 Deploying Configuration Changes in a Clustered Environment

part 4

Security Administration
System Administration Guide 9.0.5
chapter 11

Managing Secure Communications

Guidewire products use a three-tier architecture:

• The browser tier presents the ClaimCenter interface to the user.
• The web/application tier processes business logic.
• The database tier stores data.
Encryption secures communication between computer systems. You can secure the communication between the
browser, web server and a ClaimCenter server to a level strong enough that it cannot be easily compromised.

IMPORTANT Computer security and encryption is a complex topic in which network architecture plays a major
role. Use this documentation as a starting point. Guidewire strongly recommends that you also perform
independent research and testing to develop a secure solution for your company network and installed applications.
Guidewire strongly recommends that you deploy ClaimCenter over TLS (Transport Layer Security) for at least the
login and change password pages. Ideally, deploy ClaimCenter entirely under TLS to protect all sensitive
transmitted data.

ClaimCenter and the Transport Layer Security Protocol

Guidewire applications use the TLS (Transport Layer Security) protocol while making WS-I and RPC web service
connections to HTTPS endpoints. TLS is the only communication protocol that Guidewire supports for this purpose.
There are multiple versions of the TLS protocol. All current releases of JDK 7 support TLS 1.0, TLS 1.1, and TLS
1.2.
The TLS default version is the underlying JDK default for the installed release of JDK 7. This is TLS 1.0 for the
public, free (non-paid support), releases. However, use of the TLS 1.0 default can cause the connection to a server to
fail if the server requires either TLS 1.1 or TLS 1.2.

Setting TLS version overrides

Guidewire provides several Java property overrides to set the default TLS version to use on outgoing secured
connections. You can use these property overrides with either the paid support or the free versions of JDK 7. Use
these property overrides to provide a comma-separated list of TLS protocol versions. ClaimCenter uses the first item

Managing Secure Communications 181

 System Administration Guide 9.0.5

on the list as the preferred protocol. If that protocol is not available, ClaimCenter tries the subsequent protocols on
the list until the connection either succeeds or fails completely.
The following table lists the available property overrides.

Web service type Property Syntax

WS-I gw.webservices.tls.protocols -D.gw.webservices.tls.protocols="a, b"

RPC gw.tls.protocols -Dgw.tls.protocols="a, b"

In the table, a and b refer to TLS versions, for example:

<java> ... -D.gw.webservices.tls.protocols="TLSv1.2, TLSv1.1"

Notice the following for this example:

• The property definition indicates that TLS1.2 is the preferred protocol. However, if TLS1.2 is not available,
ClaimCenter attempts to use TLS 1.1 instead.
• The property definition affects only client WS-I web service calls.

ClaimCenter and Secure Communications

A strong password policy is the first and best line of defense. Guidewire also recommends the following:
• Encrypt the communication between the Internet and the ClaimCenter server or cluster.
• Configure a separate server to act as an intermediary layer between the Internet and any ClaimCenter server or
servers. Typically, you locate this intermediary server in a DMZ that you establish through your network
architecture.
If you off-load encryption to a server, understand that non-native encryption processing is not as efficient. Native
applications generally use optimized encryption modules.
You can use a web server or proxy both to encrypt communications and to provide a layer between the Internet and a
ClaimCenter server. Computer network terminology generally calls a server working as an intermediary in this
manner a reverse proxy. There are multiple methods you can use to achieve an encrypted proxy solution.
See also
• “The ClaimCenter Connection Address” on page 182

The ClaimCenter Connection Address

In setting up a secure connection with Guidewire ClaimCenter, ensure that you use a connection address similar to
the following:
https://server:port/cc/ClaimCenter.do
You need to set the server name and port number to that on which the proxy server is running. Notice the use of the
https protocol instead of http, indicating that the server is connecting through a secure version of HTTP.
Set this address for every client that connects to the ClaimCenter application server, including web browsers,
ClaimCenter plugins, and applications that use ClaimCenter APIs.
In configuring this URL, also check ClaimCenter file config.xml for any URL specifications that you need to
specify.

182 chapter 11 Managing Secure Communications

 System Administration Guide 9.0.5

Restricting access to a ClaimCenter screen by server mode

Guidewire uses PCF (Page Configuration Format) files to render ClaimCenter screens. Properties associated with
each PCF screen determine whether it is possible to visit, or edit, the screen.
It is possible to restrict access to a screen based on server mode. For example, an administrator can usually access an
Activity Patterns screen. This screen provides a list of all of the activity patterns available in ClaimCenter. Clicking
one of the listed activity patterns opens that pattern's detail screen.
Suppose, for some reason, that you want to restrict access to the Activity Patterns Detail screen on a production system.
Opening up ActivityPatternDetails.pcf in Studio shows the following properties:
• canEdit
• canVisit
To not permit access to the Activity Patterns Detail screen on a production system, enter the following value for the
canVisit property:

gw.api.system.server.ServerUtil.getEnv() != "PROD"

The canVisit property must evaluate to true for the Activity Patterns Detail screen to be accessible to a ClaimCenter
administrative user. If the server is in development or test mode, the expression evaluates to true and ClaimCenter
allows access to the screen.

Restricting access to a ClaimCenter screen by server mode 183

 System Administration Guide 9.0.5

184 chapter 11 Managing Secure Communications

chapter 12

Securing Access to ClaimCenter

Objects

Guidewire designs its security infrastructure so that you can add custom permissions, automatically enforce
permissions, and easily map between users, permissions, and actions. This topic explains how to use the
ClaimCenter permission infrastructure to control access to key ClaimCenter objects.

Understanding the Object Access Infrastructure

You can assign each user one or more roles that contain permissions. These permissions control what the user can do
in Guidewire ClaimCenter. For example, a user in ClaimCenter with the correct role can create a note on a Claim.
The limitation of roles is that they do not distinguish among objects of the same type. In the previous example,
“note” means all notes and all note types. However, suppose that you want to restrict access to notes that contain
sensitive information. In this case, ClaimCenter provides access control features that you use to restrict access to
specific types of notes.
By implementing access control, you can subcategorize an object type and then restrict object access by these
subcategories. In the base configuration, you can apply access control to the following business objects:
• Activity
• Claim
• Document
• Exposure
• Note
• User
It is possible to apply access control (permissions) to any ClaimCenter business object.

Understanding the ClaimCenter Permission Types

ClaimCenter contains the following types of permissions.

Securing Access to ClaimCenter Objects 185

 System Administration Guide 9.0.5

“System Permission Keys” on page 186 System permission keys apply to specific user interface elements or data model
entities.
“Application Permission Keys” on page 186 Application permission keys represent a set of one or more system permissions.

You can view a list of both system and application permission keys in the Guidewire Security Dictionary.
See also
• Configuration Guide

System Permission Keys

Guidewire groups system permissions into the following categories:
• Screen-level permissions that apply to user interface elements
• Domain-level permissions that apply to data model entities
You can view a list of system permissions in the SystemPermissionType typelist. You can also extend this typelist
and add custom permissions.

Screen-level Permissions
Screen-level permissions apply to user interface elements, for example, the permission to view the administrative
Server Tools screens. ClaimCenter defines many user interface permissions internally.
In general, screen-level permissions start with the word “view” followed by a reference to the user interface object
they protect. You can add custom screen-level permissions to Guidewire ClaimCenter by extending the
SystemPermissionType typelist.
PCF files define the point at which ClaimCenter calls user interface permissions. It is possible to change this point
by customizing the PCF file that calls it.

Domain-level Permissions
Domain permissions apply to data model entities, such as permission to view Note objects. For example, as a user
attempts to access the summary for a sensitive note, ClaimCenter verifies that the user has the following
permissions:
• Permission to view the Claim screen
• Permission to access that particular note type
Most top-level objects in the ClaimCenter data model have associated domain-level permissions. ClaimCenter
defines all of an object’s domain-level permissions internally. It is not possible to add, remove, or edit domain
permissions. Similarly, ClaimCenter defines the points at which it checks these permissions in internal code and in
page configuration format (PCF) files. You cannot change the internal checks. You can, however, change the point at
which the PCF files calls these checks.

Application Permission Keys

Application permission keys represents a set of one or more system permissions. ClaimCenter defines application
permission keys internally as a method for improving system performance. For example, the Activity own
permission key represents the system permission for owning an activity. The Activity edit permission key
represents the system permission for the editing activities.
Guidewire defines all configurable application permissions in file security-config.xml. It is possible for you to
modifying this file and add new application permissions.
Guidewire defines many other access application permissions internally. It is not possible to change these
permissions.

186 chapter 12 Securing Access to ClaimCenter Objects

 System Administration Guide 9.0.5

See also
• “The Security Configuration File” on page 188
• Configuration Guide

Permission Class Generation

ClaimCenter generates its permission classes at server startup by parsing file security-config.xml. The
ClaimCenter log shows this activity:

...INFO SecurityManager finished parsing ...\modules\configuration\config\security\security-config.xml

ClaimCenter does not generate permissions automatically for the subtypes of an entity. You must explicitly add the
entity subtype to security-config.xml for ClaimCenter to generate permissions for that subtype.

Beyond Roles and Permissions to Access Control

You can group system permissions by adding them to roles and then assigning the role to a user. So, if a particular
role has a view claim document permission, any user with that role can view a document attached to a claim. And,
of course, the user must first have access to that claim.
In practice, however, you likely do not want all users to access all objects of the same type. For example, suppose
that an object has an associated document that contains information on a famous celebrity. You most likely want to
restrict access so that only certain people have access to the personal information contained in this document. You
use the ClaimCenter access control feature to make distinctions among objects of the same type and then secure
access to them.
While roles and permissions determine what actions a user can perform, access control determines the objects on
which the user can act. After you enable access control, a user requires both the correct role and the proper access.
To use access control, you apply a security attribute to an object and then determine which users have access to
objects with that attribute.

Access Control Configuration Files

You manage access control in ClaimCenter with the following files:

File Role the file plays in access control

config.xml Contains parameters for turning access control on or off and for configuring how it behaves. See
the Configuration Guide for more information.
security-config.xml Defines business object security handlers.
ClaimAccessType.ttx Specifies different types of access related to claims.
ClaimSecurityType.ttx Defines the claim security types. This typelist specifies the contents of the claim user interface
Special Claim Permission drop-down.

DocumentSecurityType.ttx Defines access control types related to documents.

NoteSecurityType.ttx Defines access control types related to notes.

SystemPermissionType.ttx Contains customizable and custom system permissions.

UserRole.ttx Defines possible claim user roles. These roles appear on the Users tab of the claim, on the Parties
Involved screen.

Understanding the Object Access Infrastructure 187

 System Administration Guide 9.0.5

You modify these files in Guidewire Studio.

• File config.xml is available under configuration→config.
• File security-config.xml is available are under configuration→config →security.
• The various typelist TTX files are available under configuration→config→Metadata→Typelist.
See also
• “Understanding the Object Access Infrastructure” on page 185

The Security Configuration File

ClaimCenter provides the means to specify user access to business objects through application configuration file
security-config.xml. This XML-formatted file contains a number of XML elements that you use to configure
user access to specific business objects.
You access security-config.xml in Guidewire Studio, in the following location:
configuration→config →security

Object Access and security

The following topics discuss the standard XML elements in security-config.xml that relate to ClaimCenter
object access and security:
• “Static Handler Elements” on page 188
• “Wrap Handler Elements” on page 190
• “Object and Optional Object Handler Elements” on page 192

Note and document objects

The following topics discuss the XML elements in security-config.xml that relate to ClaimCenter note and
document objects
• “Note Permission Overview” on page 193
• “Document Permission Overview” on page 194
• “Document Access Control Example” on page 196

Claim and exposure objects

The following topics discuss the XML elements in security-config.xml that relate to ClaimCenter claim and
exposure objects:
• “Access Mapping Elements” on page 204
• “Access Profile Elements” on page 205
• “Exposure Permissions Elements” on page 213
See also
• “Understanding the Object Access Infrastructure” on page 185
• “Access Control Configuration Files” on page 187

Static Handler Elements

You use the <StaticHandler> element in security-config.xml to define security permissions on an entity. This
type of security permission is static and requires no object.
There is no limit to the number of <StaticHandler> elements that can exist in security-config.xml. Each
<StaticHandler> element can contain zero to many <SystemPermType> elements.

188 chapter 12 Securing Access to ClaimCenter Objects

 System Administration Guide 9.0.5

This element has the following syntax.

<StaticHandler entity="entity" permKey="perm" desc="..." noPermissionDisplayKey="key">

<SystemPermType code="code"/>
...
</StaticHandler>

You access this permission in code as perm.entity.perm. This syntax has the following meaning:
• entity – The business object or entity on which the permission acts.
• perm – The permission given for this entity.
The attributes on the various elements have the following meanings.

Element Attribute Required Description

StaticHandler entity Yes The entity type on which this security handler acts.
permKey Yes The application permission to grant.
desc No A human-readable description of the permission.
noPermissionDisplayKey No A display key that provides the text to show if the user does not have
a required permission.
SystemPermType code Yes A code value defined in the SystemPermissionType typelist.

The following example shows a typical <StaticHandler> element.

<StaticHandler entity="User" permKey="ViewProfiler" noPermissionDisplayKey="No access to ViewProfiler.">

<SystemPermType code="internaltools"/>
<SystemPermType code="toolsprofilerview"/>
</StaticHandler>

Notice that:
• The security permissions work on a User entity.
• The application permission key is ViewProfiler.
• The handler lists a set of specific system permission types to which the handler grants the user access, if any of
the conditions are met.
To have the ViewProfiler application permission, the user must have an assigned role that contains one or more of
the listed system permissions.

Static Handlers Specify OR Conditions

Static security handlers define Boolean OR conditions. This means for the user to have a certain application
permission, the user must have an assigned role that contains at least one of the following:
• System permission A
• Or, system permission B
• Or, system permission C
• Or, …
Suppose that you have the following code that references the ViewProfiler static handler shown previously.

if (perm.User.ViewProfiler) ...

The sample code condition evaluates to true if the current user has an assigned role with either the internaltools
permission or the toolsprofilerview permission.

Static Handler Elements 189

 System Administration Guide 9.0.5

See also
• “The Security Configuration File” on page 188
• “Wrap Handler Elements” on page 190
• “Object and Optional Object Handler Elements” on page 192

Wrap Handler Elements

The <WrapHandler> element in security-config.xml defines complex security permissions on an entity. The
wrap handler “wraps around” the permission conditions of the associated handler. The associated handler type must
not be object-based, meaning that it must be one of the following:
• <OptionalObjectHandler>
• <StaticHandler>
• <WrapHandler>
It is not possible to create a security handler that takes an object using a <WrapHandler> element. A wrap security
handler always create a new static handler.
There is no limit to the number of <WrapHandler> elements that can exist in security-config.xml. Each
<WrapHandler> element can contain zero to many <SystemPermType> elements.
A <WrapHandler> element must come after the <Handler> element that defines the permission referenced by
wrapPermKey. The associated handler can be another <WrapHandler>. It is possible to cascade <WrapHandler>
elements.
This element has the following syntax.

<WrapHandler entity="entity" permKey="perm" wrapPermKey="wrapPerm" desc="..." noPermissionDisplayKey="key">

<SystemPermType code="code"/>
...
</WrapHandler>

You access this permission in code as perm.entity.perm. This syntax has the following meaning:
• entity – The business object or entity on which the permission acts.
• perm – The permission given for this entity.
The attributes on the various elements have the following meanings.

Element Attribute Required Description

WrapHandler entity Yes The entity type on which this security handler acts.
permKey Yes The application permission to grant.
wrapPermKey Yes The associated permission being wrapped. You must declare the
permission referenced by the wrapPermKey earlier in security-conf
ig.xml than this <WrapHandler> element.

desc No A human-readable description of the permission.

noPermissionDisplayKey No A display key that provides the text to show if the user does not have
a required permission.
SystemPermType code Yes A code value defined in the SystemPermissionType typelist.

The following example illustrates a <StaticHandler> element with two cascading <WrapHandler> elements
following it.

// Static Handler - ViewProfiler permission

<StaticHandler entity="User" permKey="ViewProfiler" noPermissionDisplayKey="No access to ViewProfiler.">

190 chapter 12 Securing Access to ClaimCenter Objects

 System Administration Guide 9.0.5

<SystemPermType code="internaltools"/>
<SystemPermType code="toolsProfilerview"/>
</StaticHandler>

//First Wrap Handler - EditProfiler permission

<WrapHandler entity="User" permKey="EditProfiler" wrapPermKey="ViewProfiler" noPermissionDisplayKey="No access to Edit
Profiler.">
<SystemPermType code="internaltools"/>
<SystemPermType code="toolsProfileredit"/>
</WrapHandler>

//Second Wrap Handler - EditWebserviceProfiler permission

<WrapHandler entity="User" permKey="EditWebserviceProfiler" wrapPermKey="EditProfiler" noPermissionDisplayKey="No acce
ss to EditWebServiceProfiler.">
<SystemPermType code="toolsProfilerwebserviceedit"/>
</WrapHandler>

This sequence of handlers does the following:

1. The first wrap handler verifies that the user meets the security criteria defined in the handler specified by its
wrapPermKey attribute (ViewProfiler). If the user has an assigned role that contains any of the system
permissions specified by the ViewProfiler handler, the handler permits the user to have the EditProfiler
application permission. If the user does not have such a role, she receives an error message.
2. The second wrap handler checks to see that the user meets the security criteria defined in the handler specified
by its wrapPermKey attribute (EditProfiler). If the user has an assigned role that contains the
toolsProfilerwebserviceedit permission, the handler permits the user to have the
EditWebserviceProfiler application permission. If the user does not have such a role, she receives an error
message.

Wrap Handlers Specify AND Conditions

Wrap security handlers define Boolean AND conditions. Using the example shown previously, the sequence of
security handlers evaluates the following set of conditions:

(perm.System.internaltools OR perm.System.toolsProfilerview)
AND (perm.System.internaltools OR perm.System.toolsProfilerEdit)
AND (permission.System.toolsProfilerwebserivceedit)

For this compound condition to evaluate to true, all of the following conditions must be true:
• The user must have a role that contains either the interntools or toolsProfilerview system permission as
specified in ViewProfiler static handler.
• The user must have a role that contains either the interntools or toolsProfileredit system permission as
specified in the EditProfiler wrap handler.
• The user must have a role that contains the toolsProfilerwebservicesedit system permission as specified in
the EditWebServiceProfiler wrap handler.
Only if the user meets all sets of security criteria does the security handler permit the user to have the specified
application permission (EditwebserviceProfiler).
See also
• “The Security Configuration File” on page 188
• “Static Handler Elements” on page 188
• “Object and Optional Object Handler Elements” on page 192

Wrap Handler Elements 191

 System Administration Guide 9.0.5

Object and Optional Object Handler Elements

Along with <StaticHandler> and <WrapHandler> elements, the following types of standard security handlers are
also possible in security-config.xml:
• <ObjectHandler>
• <OptionalObjectHandler>
Guidewire uses these types of security handlers to define methods on permission classes that take objects, for
example, perm.Claim.View(claim). As these types of permissions are internal to ClaimCenter, it is not possible to
modify these permissions.
It is possible to create your own <ObjectHandler> and <OptionalObjectHandler> security handlers in security-
config.xml. However, Guidewire recommends that you do not define security handlers that use either of these
types except in consultation with Guidewire.
The <ObjectHandler> element has the following syntax.

<ObjectHandler entity="entity" permKey="perm" desc="..." noPermissionDisplayKey="key">

<SystemPermType code="code"/>
...
</ObjectHandler>

The <OptionalObjectHandler> element has the following syntax.

<OptionalObjectHandler entity="entity" permKey="perm" desc="..." noPermissionDisplayKey="key">

<SystemPermType code="code"/>
...
</OptionalobjectHandler>

You access these types of permissions in code as perm.entity.perm(obj). This syntax has the following meaning:
• entity – The business object or entity on which the permission acts.
• perm – The permission given for this object.
• obj – An instance of the business object governed by the permission.
The details of the element attributes and subelements for the <ObjectHandler> and <OptionalObjectHandler>
security handlers are similar to those for <StaticHandler> elements.
See also
• “The Security Configuration File” on page 188
• “Static Handler Elements” on page 188
• “Wrap Handler Elements” on page 190

192 chapter 12 Securing Access to ClaimCenter Objects

chapter 13

Securing Access to Notes and

Documents

This topic explains how to use the ClaimCenter permission infrastructure to control access to document and note
objects.
See also
• “Understanding the Object Access Infrastructure” on page 185
• “The Security Configuration File” on page 188
• “Static Handler Elements” on page 188
• “Wrap Handler Elements” on page 190
• “Object and Optional Object Handler Elements” on page 192

Note Permission Overview

Besides the standard note-related system permissions, you can control access to notes by configuring note access
permissions in security-config.xml. To use this feature, a note must have a note security type set. To see a note of
a particular type, a user must have both permission to view notes generally and the permission to access to the note
security type.
You set the security type for a note type by setting the note Security Type in ClaimCenter or through a Gosu class that
you write. In the base configuration, ClaimCenter provides the following note security types in the
NoteSecurityType typelist:
• Medical
• Public
• Private
• Sensitive

Securing Access to Notes and Documents 193

 System Administration Guide 9.0.5

See also
• For information on the various security handler elements, see “The Security Configuration File” on page 188.
• For information on permissions, refer to the system permissions area of the ClaimCenter Security Dictionary.
• For information on typelists, refer to ClaimCenter Studio, or the typelists area of the ClaimCenter Data
Dictionary.

Note Permission Elements

File security-config.xml must contain a <NoteAccessProfile> element for every note security type listed in the
NoteSecurityType typelist. If you add a new note security type to the typelist, then you must add a corresponding
<NoteAccessProfile> element to security-config.xml.
Thus, a <NotePermission> element in the security-config.xml file controls access to a note type.
The <NotePermission> element has the following syntax:

<NotePermissions>
<NoteAccessProfile securitylevel="level">
<NoteCreatePermission permission="perm"/>
<NoteDeletePermission permission="perm"/>
<NoteEditBodyPermission permission="perm"/>
<NoteEditPermission permission="perm"/>
<NoteViewPermission permission="perm"/>
</NoteAccessProfile>
</NotePermissions>

The attributes on the various elements have the following meanings.

Element Attribute Required Description

NoteAccessProfile securitylevel Yes A document security type defined in the NoteSecurityType typelist.
NoteCreatePermission permission Yes A system permission defined in the SystemPermissionType typelist.
NoteDeletePermission
NoteEditBodyPermission
NoteEditPermission
NoteViewPermission

The following code sample illustrates the security access levels for the Public security access type.

<NotePermissions>
<NoteAccessProfile securitylevel="public">
<NoteViewPermission permission="noteview"/>
<NoteEditPermission permission="noteedit"/>
<NoteDeletePermission permission="notedelete"/>
</NoteAccessProfile>
</NotePermissions>

Note: ClaimCenter grants access permissions based on the roles assigned to a user only. It is not possible to restrict
Note access based on security zones or groups.

Document Permission Overview

Besides the standard document-related system permissions, you can control access to documents by configuring
document access permissions in security-config.xml. To use this feature, a document must have a document
security type set. To see a set of documents of a particular type, a user must have both permission to view documents
generally and access to the document security type.

194 chapter 13 Securing Access to Notes and Documents

 System Administration Guide 9.0.5

You set a document type by using the document’s Security Type on the user interface or through a Gosu class that you
write. In the base configuration, ClaimCenter provides the following document security types in the
DocumentSecuritytype typelist:
• Sensitive
• Unrestricted
See also
• For information on the various security handler elements, see “The Security Configuration File” on page 188.
• For information on permissions, refer to the system permissions area of the ClaimCenter Security Dictionary.
• For information on typelists, refer to ClaimCenter Studio, or the typelists area of the ClaimCenter Data
Dictionary.

Document Permission Elements

File security-config.xml must contain a <DocumentAccessProfile> element for every document security type
listed in the DocumentSecurityType typelist. If you add a new document security type to the typelist, then you must
add a corresponding <DocumentAccessProfile> element to security-config.xml.
Thus, a <DocumentPermission> element in the security-config.xml file controls access to a document type.
This element has the following syntax:

<DocumentPermissions>
<DocumentAccessProfile securitylevel="level">
<DocumentCreatePermission permission="perm"/>
<DocumentDeletePermission permission="perm"/>
<DocumentEditPermission permission="perm"/>
<DocumentViewPermission permission="perm"/>
</DocumentAccessProfile>
</DocumentPermissions>

The attributes on the various elements have the following meanings.

Element Attribute Required Description

DocumentAccessProfile securitylevel Yes A document security type defined in the DocumentSecurityType
typelist.
DocuumentCreatePermission permission Yes A system permission defined in the SystemPermissionType
DocumentDeletePermission typelist.
DocumentEditPermission
DocumentViewPermission

The following code sample illustrates the security access levels for the Unrestricted and Sensitive security access
type.

<DocumentPermissions>
<DocumentAccessProfile securitylevel="unrestricted"/>
<DocumentAccessProfile securitylevel="sensitive">
<DocumentViewPermission permission="viewsensdoc"/>
<DocumentEditPermission permission="editsensdoc"/>
<DocumentDeletePermission permission="delsensdoc"/>
</DocumentAccessProfile>
</DocumentPermissions>

Document Permission Overview 195

 System Administration Guide 9.0.5

Note: ClaimCenter grants these permissions based on the user’s roles alone. You cannot restrict document access
based on security zones or groups.

Document Access Control Example

It is possible configure document security such that different ClaimCenter groups have different security access to
the documents on a claim.
For example, you configure document access control with a document security type of subrogation. You want to
limit the creation of subrogation documents to users who had an Subrogation role. You want to limit who can view
the attached subrogation documents to users who have a Subrogation role.
To configure document access control, perform the following procedures in the listed order:
1. “Create a New Document Security Type” on page 196
2. “Create Custom Permissions for a New Document Security Type” on page 197
3. “Create a Document Access Profile for a New Document Type” on page 197
4. “Rebuild and Redeploy ClaimCenter” on page 198
5. “Add New Security Permissions to the Appropriate Roles” on page 198
See also
• “The Security Configuration File” on page 188
• “Static Handler Elements” on page 188
• “Document Permission Overview” on page 194

Create a New Document Security Type

Before you begin
Before you perform this procedure, review “Document Access Control Example” on page 196.
To create a new document security type, you need to plan the kinds of permissions that you intend to associate with
the security type.

Procedure
1. In the ClaimCenter Studio Project window, expand configuration→config→Metadata→Typelist.
2. Open DocumentSecurityType.tti.
3. Click the link for DocumentSecurityType.ttx.
4. Click the plus icon next to typecode.
5. Enter a code value for the new security type. The code must be 16 characters or less.
For example, enter subrogation for the code value.
6. Add values for the name and desc (description) of the new permission.
Leave the priority as -1 and retired as false.
7. Save your changes.

Next steps
After completing the preceding steps, perform procedure “Create Custom Permissions for a New Document Security
Type” on page 197.

196 chapter 13 Securing Access to Notes and Documents

 System Administration Guide 9.0.5

Create Custom Permissions for a New Document Security Type

Before you begin
Before you perform this procedure, you need to define the new document security type. See “Create a New
Document Security Type” on page 196.

Procedure
1. In the ClaimCenter Studio Project window, expand configuration→config→Metadata→Typelist.
2. Open the SystemPermissionType typelist.
3. Click the link for SystemPermissionType.ttx.
4. Click the plus icon next to typecode.
5. Enter a code value for the new permission.
Include the type of action you want the permission to control in the code. The code must be 16 characters or
less. For example, enter viewsubdoc(view subrogation document).
6. Add values for the name and desc (description) of the new permission.
Leave the priority as -1 and retired as false.
7. Save your changes.

Next steps
After completing the preceding steps, perform procedure “Create a Document Access Profile for a New Document
Type” on page 197.

Create a Document Access Profile for a New Document Type

Before you begin
Before you perform this procedure, you need to define the new custom document permissions. See “Create a New
Document Security Type” on page 196.

Procedure
1. In the ClaimCenter Studio Project window, expand configuration→config→security.
2. Open security-config.xml.
3. Add a <DocumentAccessProfile> element to the <DocumentPermissions> element for your document type.
This requires that you set the securitylevel attribute to a document security type defined in the
DocumentSecurityType typelist.
For example, on the <DocumentAccessProfile> element, define the securitylevel attribute as
subrogation, as the following example XML shows:

<DocumentPermissions>
<DocumentAccessProfile securitylevel="unrestricted"/>
...
<DocumentAccessProfile securitylevel="subrogation">
<DocumentViewPermission permission="viewsubdoc" />
<DocumentEditPermission permission="editsubdoc"/>
<DocumentDeletePermission permission="delsubdoc"/>
</DocumentAccessProfile>
</DocumentPermissions>

4. Save your changes.

Next steps
After completing the preceding steps, perform procedure “Rebuild and Redeploy ClaimCenter” on page 198.
Document Access Control Example 197
 System Administration Guide 9.0.5

Rebuild and Redeploy ClaimCenter

Before you begin
Before you perform this procedure, you need to complete the creation of a custom document access profile. See
“Create a Document Access Profile for a New Document Type” on page 197.

Procedure
1. Rebuild and redeploy your application package file if you are in a production environment.
2. Open a command prompt and navigate to the ClaimCenter installation directory.
3. Run the following command:

gwb genDataDictionary

This command updates the typelist documentation.

Next steps
After completing the preceding steps, perform procedure “Add New Security Permissions to the Appropriate Roles”
on page 198.
See also
• Installation Guide
• Configuration Guide

Add New Security Permissions to the Appropriate Roles

Before you begin
Before you perform this procedure, you need to redeploy your updated configuration and regenerate the typelist
documentation. See “Rebuild and Redeploy ClaimCenter” on page 198.

Procedure
1. Log into Guidewire ClaimCenter using an administrative account.
2. Add the new permissions to the appropriate roles.
For example, add the new subrogation system permissions to the Subrogation role, or whichever role is
appropriate for your configuration.
3. Repeat “Add New Security Permissions to the Appropriate Roles” on page 198 for the special investigation
permissions adding them to the appropriate role.
4. Add the subrogation and special investigation permissions to the Manager role.
5. Verify that the members of each group have the associated roles.

Next steps
At this point, you can test the new configuration.
See also
• Application Guide

198 chapter 13 Securing Access to Notes and Documents

chapter 14

Securing Access to Claims and

Exposures

This topic explains how to use the permission infrastructure to control access to ClaimCenter claim objects.
See also
• “Understanding the Object Access Infrastructure” on page 185
• “The Security Configuration File” on page 188
• “Static Handler Elements” on page 188
• “Wrap Handler Elements” on page 190
• “Object and Optional Object Handler Elements” on page 192

Claim Access Control

It is possible configure claim security such that different ClaimCenter roles have different security access to a claim.

Securing Access to Claims and Exposures 199

 System Administration Guide 9.0.5

See also
• “The Security Configuration File” on page 188

Claim Access Control Overview

In ClaimCenter, claim permissions control who has access to the claim and what actions a user can take on the
claim. You set access control on a claim by configuring the following:
• Specify the claim security types. For example, you might need to be able to designate claims associated
celebrities as sensitive claims.
• Map the claim access to permissions. This specifies what you can do to a claim if you have a specific type of
access. For example, if a user has edit access, that user can close a claim.
• Create an access profile for each claim security level. Within the profile, you specify access levels that define the
organizational relationship to the claim a user must have to have a specific access type. For example, you can set
that only the claim owner can edit the claim.
By implementing access profiles, you can restrict access by ownership, group, and security zone — or open access
to anyone at all. For example, you can specify the following:
• To view an unsecured claim, the user must be in the same group as that assigned to the claim.
• To modify the unsecured claim, the user must be the claim owner.
You can also specify that, to edit claims that are at the sensitive level, a user must have a role that contains the
ownsensclaim permission.
Note: Access control is cumulative. If you grant access to a user at the group level, you cannot remove that access
by more restrictive access at the role level.
Having access is not the same as having permission. Even though an access profile may grant a user access to an
object, that user still requires a role with the proper permissions. For example, suppose an access profile grants view
access to any user who is a member of the claim owner’s security zone. To view the claim, users must both belong to
the proper security zone and have the viewclaim permission on one of their roles.
ClaimCenter supports downline access for supervisors. This feature effectively gives supervisors the equivalent
access as any user, group, or security zone that they administer. If a user has access to a claim, that user’s supervisor
also has access. Keep in mind, the supervisor must also have a role that grants the proper claim permissions as well.
You can change this default behavior by changing the access control parameters in the config.xml file.
See also
• Configuration Guide

Claim Access Types and System Permissions

It is possible to map claim access types to permissions. Claim access types group claim-related permissions. The
mapping of claim access types to permissions determines what actions ClaimCenter permits a user to take within the
scope of a given access type. For example, the view access type might consist of all of the permissions for viewing
claim data, such as View Claim, View Exposures, View Activities, and so forth.
The <AccessMapping> element in security-config.xml specifies the mapping between claim access types to
permissions. This element has the following syntax:

<AccessMapping claimAccessType="access_type" systemPermission="perm" />

See also
• “The Security Configuration File” on page 188
• “Add a New Claim-related System Permission” on page 202
• “Map Claim Access Types to System Permissions” on page 203
• “Add a New Claim Access Type” on page 203

200 chapter 14 Securing Access to Claims and Exposures

 System Administration Guide 9.0.5

• “Access Mapping Elements” on page 204

ClaimCenter and Claim ACL Changes

It is important to understand how ClaimCenter applies a change you make to a claim’s access control. Suppose that
you change the access control settings in the security-config.xml file, deploy the changes, and restart the server.
After the restart, ClaimCenter automatically subjects all new claims to the new access control level (ACL). Existing
claims remain unchanged.
ClaimCenter does not attempt to verify existing claims against the new access control level. ClaimCenter applies
new ACL changes to pre-existing claims if a user attempts a claim modification related to the ACL. At that point,
ClaimCenter alters the claim’s access based on the new configuration but does not discard the old configuration.
You can force ClaimCenter to rebuild existing access controls and use only the new controls. Suppose, for example,
that you want to apply a new sensitiveclaim access control to all claims that pre-date your changes. In that case,
you need to force ClaimCenter to discard and rebuild the existing access controls by making a claim modification
related to the ACL.
You can also rebuild access controls from an exception rule by using the rebuildClaimACL method.
See also
• “Rebuild Claim Access Controls” on page 201
• Rules Guide

Rebuild Claim Access Controls

Procedure
1. Deploy your new security changes and restart the server.
2. Log into Guidewire ClaimCenter.
3. Locate an existing sensitive claim.
4. Change the security level of the claim from Sensitive to a new value.
5. Save the claim.
6. Set the claim back to Sensitive.
7. Save the claim.

Controlling Access to Claim Objects

It is possible to use access control to refine a user’s access to specific claim types. The first step in establishing
claim access control is to define claim security types. Guidewire defines a number of default claim security types
ClaimSecurityType typelist. You can also add custom types to the ClaimSecurityType typelist. The security
levels appear in the claim details under the ClaimCenter Special Claim Permission drop-down.
Note: ClaimCenter assigns claims without a defined security type to the default type of unsecuredclaim.
Guidewire defines this type internally. The unsecuredclaim type does not appear in the ClaimSecurityType
typelist.
See also
• “Access Mapping Elements” on page 204
• “Access Profile Elements” on page 205
• “Restrict Claim Ownership” on page 210
• “Example: Default Access Profile for Unsecured Claims” on page 210
• “Example: Default Access Profile for Sensitive Claims” on page 211

Claim Access Control 201

 System Administration Guide 9.0.5

Add a Claim Security Type

About this task

It is possible to use Gosu code to apply a security type to a claim.

Procedure
1. In the ClaimCenter Studio Project window, expand configuration→config→Metadata→Typelist:
a. Open ClaimSecurityType.tti.
b. Click the ClaimSecurityType.ttx link.
c. Click the plus icon next to typecode.
d. Enter a code value for the new permission.
Include the type of action you want the permission to control in the code, for example, viewvacation.
The code must be 16 characters or less.
e. Add values for the name and desc (description) attributes.
f. Leave the priority attribute as -1 and the retired attribute as false.
g. Save your changes.
2. Rebuild and redeploy your application package file if in a production environment.
3. Update and rebuild the typelist information:
a. In a command prompt window, navigate to the ClaimCenter installation directory
b. Run the following command:

gwb genDataDict

Next steps
See also
• Installation Guide
• Configuration Guide

Add a New Claim-related System Permission

About this task

It is possible to edit the SystemPermissionType typelist to add your own screen-level permissions to ClaimCenter.
You can also retire or modify existing permissions in this typelist. This typelist does not contain all the permissions
in the system. Internal system permissions, both domain and user interface, do not appear in this typelist.

Procedure
1. In the ClaimCenter Studio Project window, expand configuration→config→Metadata→Typelist:
a. Open SystemPermissionType.tti.
b. Click the SystemPermissionType.ttx link.
c. Click the plus icon next to typecode.
d. Enter a code value for the new permission.
Include the type of action you want the permission to control in the code, for example, viewvacation.
The code must be 16 characters or less.
e. Add values for the name and desc (description) attributes.
f. Leave the priority attribute as -1 and retired attribute as false.

202 chapter 14 Securing Access to Claims and Exposures

 System Administration Guide 9.0.5

g. Save your changes.

2. Rebuild and redeploy your application package file if you are in a production environment.
3. Update and rebuild the typelist information:
a. In a command prompt window, navigate to the ClaimCenter installation directory
b. Run the following command:

gwb genDataDict

Next steps
See also
• Installation Guide
• Configuration Guide

Map Claim Access Types to System Permissions

Procedure
1. In the ClaimCenter Studio Project window, expand configuration→config→security:
a. Open security-config.xml.
b. Add an access mapping element that specifies a claim access type and a system permission.
If necessary, copy and modify an existing <AccessMapping> element.
c. Save your changes.
2. Rebuild and redeploy your application package file if you are in a production environment.
3. Update and rebuild the typelist information:
a. In a command prompt window, navigate to the ClaimCenter installation directory
b. Run the following command:

gwb genDataDict

Next steps
See also
• “The Security Configuration File” on page 188
• “Access Mapping Elements” on page 204
• Installation Guide

Add a New Claim Access Type

About this task

The ClaimAccessType typelist defines claim access types. You can modify the default types and you can define new
custom types.

IMPORTANT For performance reasons, Guidewire does not recommend that you define more than a few custom
claim access types.

Procedure
1. In the Studio Project window, expand configuration→config→Metadata→Typelist:

Controlling Access to Claim Objects 203

 System Administration Guide 9.0.5

a. Open claimAccessType.tti.
b. Click the ClaimAccesstype.ttx link.
c. Click the plus icon next to typecode.
d. Enter a value in the code field for the new access type.
The code value must be 16 characters or less.
e. Add values for name and desc (description) attributes to the new security type.
f. Leave the Priority attribute as -1 and the Retired attribute as false.
g. Save your work.
2. Rebuild and redeploy your application package file if you are in a production environment.
3. Update and rebuild the typelist information:
a. In a command prompt window, navigate to the ClaimCenter installation directory
b. Run the following command:

gwb genDataDict

Next steps
See also
• Installation Guide
• Configuration Guide

Claim Access Mapping Overview

ClaimCenter does not require you to map all claim access types. However, access control does not function properly
if you do not map them all. Mappings must meet the following requirements:
• You must map all claim-related system permissions.
• You can map a claim-related permission to one claim access type only. For example, you can map paycreate to
view but not to edit also.
• Of the internal system permissions, you can only map claim-related permissions. For example, the paycreate
permission permits a user to create a payment on a claim. It is claim-related. The ruleadmin permission is not
claim related. Mapping it causes a configuration error.

Access Mapping Permissions are Object-based

If you add an permission in security-config.xml using an <AccessMapping> element, ClaimCenter interprets that
permission as object-based. This means that you need to pass in an object if checking the permission. If you add a
non-object-based permission using an <AccessMapping> element, the permission becomes object-based. If you add
this type of permission, you must always evaluate the permission in the context of a given claim, or some other
object that refers to a claim.
See also
• “The Security Configuration File” on page 188

Access Mapping Elements

<AccessMapping> elements in security-config.xml group permissions that relate to claim access. The mapping
of claim access types to permissions determines the actions that ClaimCenter permits a user to take within the scope
of a given access type. For example, the view access type might consist of all of the permissions for viewing claim
data, such as View Claim, View Exposures, View Activities, and so forth.
There is no limit to the number of <AccessMapping> elements that can exist in security-config.xml.
204 chapter 14 Securing Access to Claims and Exposures
 System Administration Guide 9.0.5

This element has the following syntax:

<AccessMapping claimAccessType="access_type" systemPermission="perm" />

The attributes on the <AccessMapping> element have the following meanings.

Attribute Required Description

claimAccessType Yes The type of claim access. This must be a value defined in the ClaimAccessType typelist.
systemPermission Yes A system permission defined in the SystemPermissionType typelist.

The following example maps the permission to create new activities on a claim (actcreate) to the create access
type:

<AccessMapping claimAccessType="create" systemPermission="actcreate" />

Typically, security-config.xml maps multiple permissions to a single claim access type. The default edit access
illustrates this concept.

<AccessMapping claimAccessType="edit" systemPermission="actcreate"/>

<AccessMapping claimAccessType="edit" systemPermission="actcreateclsd"/>
<AccessMapping claimAccessType="edit" systemPermission="checktransfer"/>
<AccessMapping claimAccessType="edit" systemPermission="claimclose"/>
<AccessMapping claimAccessType="edit" systemPermission="claimedit"/>
...

Access Profile Elements

<AccessProfile> elements in security-config.xml determine claim access by defining an access profile for each
claim security level. By defining an access profile, you can control security related to the details, activities, and
exposures of a claim.
There is no limit to the number of <AccessProfile> elements that can existing security-config.
The <AccessProfile> element in the security-config.xml file has the following syntax:

<AccessProfile securitylevel="level">
<ClaimOwnPermission permission="perm"/>
<SubObjectOwnPermission permission="perm"/>
<ClaimAccessLevels>
<AccessLevel level="level" permission="access_type" />
<DraftClaimAccessLevel level="level"/>
<ClaimUserAccessLevel role="user_role" level="level" permission="access_type" />
</ClaimAccessLevels>
<ActivityAccessLevels>
<AccessLevel level="level" permission="access_type" />
<ActivityAccessLevels/>
<ExposureAccessLevels>
<AccessLevel level="level" permission="access_type" />
</ExposureAccessLevels>
</AccessProfile>

The <AccessProfile> element has one attribute.

Attribute Required Description

securitylevel Yes A security type defined in the ClaimSecurityType typelist, or the default security type, unsecure
dclaim.

Claim Access Mapping Overview 205

 System Administration Guide 9.0.5

An <AccessProfile> element contains zero to one of the following subelements. See the respective subelements for
a discussion of their attributes and subelements.

Subelement Required Description

ActivityAccessLevels Yes Specifies one or more <AccessLevel> elements. An access level describes a particular
relationship with the claim and the access permitted to users who have that
relationship.
ClaimAccessLevels Yes Specifies one or more AccessLevel, DraftClaimAccessLevel, or ClaimUserAccessLev
el. An access level describes a particular relationship with the claim and the access
permitted to users who have that relationship.
ClaimOwnPermission No The permission a user must have to own claims of this type. This element is optional.
ExposureAccessLevels Yes Specifies one or more <AccessLevel> elements. An access level describes a particular
relationship with the claim and the access permitted to users who have that
relationship.
SubObjectOwnPermission No The permission a user must have to own subobjects on this claim. This element is
optional.

See also
• “The Security Configuration File” on page 188
• “Restrict Claim Ownership” on page 210
• “Example: Default Access Profile for Unsecured Claims” on page 210
• “Example: Default Access Profile for Sensitive Claims” on page 211

Activity Access Levels Elements

<ActivityAccessLevels> elements in security-config.xml define who can access an activity and the
permissions that the user has with the activity.
This element is a subelement of the <AccessProfile> element. The <AccessProfile> element contains exactly
one <ActivityAccessLevels> subelement. Each <ActivityAccessLevels> element can contain from zero to
many <AccessLevel> elements.
This element has the following syntax.

<ActivityAccessLevels>
<AccessLevel level="level" permission="access_type" />
...
<ActivityAccessLevels/>

The attributes on the <AccessLevel> element have the following meanings.

Attribute Required Description

level Yes Defines the organizational relationship a user must have with the activity to access it. In the base
configuration, the value of level must be one of the following:
• anyone – All users
• group – Users who are in the same group as that assigned to the claim, exposure, or activity
• securityzone – Users who are in the same group in the security zone as that assigned to the
claim, exposure, or activity
• user – Owner of the claim, exposure, or activity.
permission Yes The allowed permission. This must be a value defined in the ClaimAccessType typelist.

206 chapter 14 Securing Access to Claims and Exposures

 System Administration Guide 9.0.5

See also
• “The Security Configuration File” on page 188

Claim Access Levels Elements

<ClaimAccessLevels> elements in security-config.xml define who can access a claim and what permissions the
user has with the claim.
This element is a subelement of the <AccessProfile> element. The <AccessProfile> element contains exactly
one <ClaimAccessLevels> subelement. Each <ClaimAccessLevels> element can contain from zero to many
<AccessLevel> and <ClaimUserAccessLevel> elements. It can also contain from zero to one
<DraftClaimAccessLevel> elements.
This element has the following syntax.

<ClaimAccessLevels>
<AccessLevel level="level" permission="access_type" />
...
<DraftClaimAccessLevel level="level"/>
<ClaimUserAccessLevel role="user_role" level="relationship" permission="access_type" />
...
</ClaimAccessLevels>

The attributes on the various elements have the following meanings.

Element Attribute Required Description

AccessLevel level Yes Defines the organizational relationship a user must have with the
activity to access it. In the base configuration, the vale of level
must be one of the following:
• anyone – All users
• group – Users who are in the same group as that assigned to the
claim, exposure, or activity
• securityzone – Users who are in the same group in the security
zone as that assigned to the claim, exposure, or activity
• user – Owner of the claim, exposure, or activity.
permission Yes The allowed permission. This must be a value defined in the ClaimA
ccessType typelist.

ClaimUserAccessLevel level Yes Sets the security type that the claim must have for the user to
access the claim. This must be either a value defined in the ClaimSe
curityType typelist or the string “any”.

permission Yes The claim access types available to a user with the proper role and
level. This must be a value defined in the ClaimAccessType
typelist.
role Yes The role that a user must have to access this claim. This must be a
value defined in the UserRole typelist. User roles show on the claim
Users tab, on the Parties Involved screen.

DraftClaimAccessLevel level Yes Defines the access level necessary to work on a claim while its
status is draft. It has the same meaning as the level attribute for Ac
cessLevel.

Claim Access Mapping Overview 207

 System Administration Guide 9.0.5

WARNING Be careful adding a <ClaimUserAccessLevel> element. Depending on how you define the
element, adding one user through the Users tab can grant access to the membership of entire groups or security
zones.

See also
• “The Security Configuration File” on page 188

Claim Own Permission Elements

<ClaimOwnPermission> elements in security-config.xml restrict claim ownership to users with a specific system
permission. For example, sensitive claims might require that only users with ownsensclaim (permission to own
sensitive claims) can own a claim.
This element is a subelement of the <AccessProfile> element. The <AccessProfile> element can contain from
zero to one <ClaimOwnPermission> subelements.
This elements has the following syntax:

<AccessProfile securitylevel="level">
<ClaimOwnPermission permission="perm"/>
...
</AccessProfile>

The attributes on the various elements have the following meanings.

Element Attribute Required Description

AccessProfile securitylevel Yes A security type defined in the ClaimSecurityType typelist, or to the
default security type, unsecuredclaim.
ClaimOwnPermission permission Yes A system permission defined in the SystemPermissionType typelist.

You are not likely to use this element on a profile for unsecured claims, but it can be useful to control ownership of
secured claims. For example, you can use this element to restrict the users who can own any claims that involve an
employee.
See also
• “The Security Configuration File” on page 188

Exposure Access Levels Elements

<ExposureAccessLevels> elements in security-config.xml define who can access an exposure and what
permissions the user has with the exposure.
This element is a subelement of the <AccessProfile> element. The <AccessProfile> element contains exactly
one <ExposureAccessLevels> subelement. Each <ExposureAccessLevels> element can contain from zero to
many <AccessLevel> elements.
This element has the following syntax.

<ExposureAccessLevels>
<AccessLevel level="level" permission="access_type" />
...
</ExposureAccessLevels>
The attributes on the <AccessLevel> element have the following meanings.

208 chapter 14 Securing Access to Claims and Exposures

 System Administration Guide 9.0.5

Element Attribute Required Description

AccessLevel level Yes The organizational relationship a user must have with the activity to access it. In the
base configuration, the vale of level must be one of the following:
• anyone – All users
• group – Users who are in the same group as that assigned to the claim, exposure,
or activity
• securityzone – Users who are in the same group in the security zone as that
assigned to the claim, exposure, or activity
• user – Owner of the claim, exposure, or activity.
permission Yes The allowed permission. This must be a value defined in the ClaimAccessType typelist.

WARNING Be careful adding an <ExposureUserAccessLevel> element. Depending on how you define the
element, adding one user through the Users tab can grant access to the membership of entire groups or security
zones.

See also
• “The Security Configuration File” on page 188

SubObject Own Permission Elements

<SubObjectOwnPermission> elements in security-config.xml restrict ownership of objects on the claim to users
with a specific system permission. For example, sensitive claims might require that only users with ownsensclaim
(permission to own sensitive claims) can own a claim. Similarly, the <SubObjectOwnPermission> element restricts
access to exposures and activities to users with a specific system permission.
This element is a subelement of the <AccessProfile> element. The <AccessProfile> element can contain from
zero to one <SubOjectAccessLevels> subelements.
This element has the following syntax:

<AccessProfile securitylevel="level">
<SubObjectOwnPermission permission="perm"/>
...
</AccessProfile>

The attributes on the various elements have the following meanings.

Element Attribute Required Description

AccessProfile securitylevel Yes A security type defined in the ClaimSecurityType typelist, or the
default security type, unsecuredclaim.
SubObjectOwnPermission permission Yes A system permission defined in the SecurityPermissionType
typelist.

You are not likely to use these elements on a profile for unsecured claims, but they can be useful to control
ownership of secured claims. For example, you can restrict ownership of claims involving an employee.

Claim Access Mapping Overview 209

 System Administration Guide 9.0.5

See also
• “The Security Configuration File” on page 188

Restrict Claim Ownership

About this task
It is possible to define an access profile that controls the security related to the details, activities, and exposures of a
claim. The <AccessProfile> element in the security-config.xml file provides this functionality.

Procedure
1. In the ClaimCenter Studio Project window, expand configuration→config→security:
2. Open security-config.xml.
3. If creating an access profile for a new security type or for a security type that does not yet have an access
profile, do one of the following:
• Create a new <AccessProfile> element using an existing <AccessProfile> element as a template.
• Copy and modify an existing <AccessProfile> element.
4. Create or edit the <ClaimOwnPermission> and <SubObjectOwnPermission> elements.
The following example illustrates how to restrict access to a claim filed by a company employee.

<AccessProfile securitylevel="employeeclaim">
<ClaimOwnPermission permission="ownemployeeclaim"/>
<SubObjectOwnPermission permission="ownemployeeclaimsub"/> ...
</AccessProfile>

These elements specify which system permission a user must have to own the claim or subobjects of the
claim. If the required system permissions do not exist, you must add them to the SystemPermissionType
typelist.
5. Within ClaimCenter, add the system permissions to the appropriate roles.
For example, add the ownemployeeclaim and ownemployeeclaimsub permissions to the Sensitive Claim
Adjuster role.

Next steps
See also
• “The Security Configuration File” on page 188
• “Add a New Claim-related System Permission” on page 202
• “Access Mapping Elements” on page 204
• “Example: Default Access Profile for Unsecured Claims” on page 210
• “Example: Default Access Profile for Sensitive Claims” on page 211

Example: Default Access Profile for Unsecured Claims

In the base configuration, Guidewire provides the following default access profile in security-config.xml for
unsecured claims:

<AccessProfile securitylevel="unsecuredclaim">
<ClaimAccessLevels>
<AccessLevel level="securityzone" permission="view"/>
<AccessLevel level="securityzone" permission="edit"/>
<DraftClaimAccessLevel level="securityzone"/>
<ClaimUserAccessLevel role="subrogationowner" level="user" permission="view"/>
<ClaimUserAccessLevel role="subrogationowner" level="user" permission="edit"/>
<ClaimUserAccessLevel role="reinsmgr" level="group" permission="view"/>

210 chapter 14 Securing Access to Claims and Exposures

 System Administration Guide 9.0.5

<ClaimUserAccessLevel role="reinsmgr" level="group" permission="edit"/>

<ClaimUserAccessLevel role="relateduser" level="user" permission="view"/>
</ClaimAccessLevels>
<ActivityAccessLevels>
<AccessLevel level="group" permission="view"/>
<AccessLevel level="user" permission="edit"/>
<ActivityAccessLevels/>
<ExposureAccessLevels>
<AccessLevel level="group" permission="view"/>
<AccessLevel level="group" permission="edit"/>
</ExposureAccessLevels>
</AccessProfile>

This example specifies the following for all unsecured claims:

• Any user in the security zone of the claim owner can view and edit the claim.
• Any user in the security zone of the claim owner can access the claim while it is a draft.
• Any user added to the claim with the subrogation owner role can view or edit the claim.
• Any user added to the claim who is in the same group as a reinsurance manager can view or edit the claim.
• Any user added to the claim with the related user role can view the claim.
• Any user belonging to the same group as an exposure owner can view or edit the claim.
• Any user belonging to the same group as an activity owner can view the claim, but only the activity owner can
edit the claim.
See also
• “The Security Configuration File” on page 188
• “Access Profile Elements” on page 205
• “Restrict Claim Ownership” on page 210
• “Example: Default Access Profile for Sensitive Claims” on page 211

Example: Default Access Profile for Sensitive Claims

In the base configuration, Guidewire provides the following default access profile in security-config.xml for
sensitive claims:

<AccessProfile securitylevel="sensitiveclaim">
<ClaimOwnPermission permission="ownsensclaim"/>
<SubObjectOwnPermission permission="ownsensclaimsub"/>
<ClaimAccessLevels>
<AccessLevel level="group" permission="view"/>
<AccessLevel level="group" permission="edit"/>
<DraftClaimAccessLevel level="group"/>
</ClaimAccessLevels>
<ActivityAccessLevels>
<AccessLevel level="user" permission="view"/>
<AccessLevel level="user" permission="edit"/>
<ActivityAccessLevels/>
<ExposureAccessLevels>
<AccessLevel level="user" permission="view"/>
<AccessLevel level="user" permission="edit"/>
</ExposureAccessLevels>
</AccessProfile>

This example specifies the following for all sensitiveclaim claims:

• To own the claim or any of its sub objects, a user must have a role that includes the ownsensclaimsub system
permission.
• Any members of the claim owner's groups can view or edit the claim and any of its subobjects.
• The owner of an exposure can view or edit the claim and any of its subobjects.
• The owner of an activity can view or edit the claim and any of its subobjects.

Claim Access Mapping Overview 211

 System Administration Guide 9.0.5

See also
• “The Security Configuration File” on page 188
• “Access Profile Elements” on page 205
• “Restrict Claim Ownership” on page 210
• “Example: Default Access Profile for Unsecured Claims” on page 210

Exposure Access Control

It is possible to refine the controls that allow users to access exposures on a claim. For example, you might want to
restrict adjusters working on different exposures on the same claim to only exposures of a certain type. You do this
through exposure access control.

Exposure Security Controls Overview

Exposure level access control restricts access to exposures within a claim. An adjuster on a claim can have access to
some exposures on a claim but not all. Users granted access through exposure access control can view:
• The exposure screen
• The existence and contents of all notes related to a secured exposure
• The existence and contents of all documents tied to a secured exposure
• The contents of activities related to a secured exposure
• The contents of matters related to an exposure
Exposure access control does not prevent users from viewing:
• The existence of exposures to which the user does not have permission to view (a claim lists all exposures).
• Any financial transactions related to an exposure to which the user does not have permission to view.
ClaimCenter generates a permission error only if a user attempts to access an exposure to which the user does not
have access.
See also
• “The Security Configuration File” on page 188
• “Exposure Access Control” on page 212
• “Static Versus Claim-based Exposure Security” on page 212
• “Exposure Permissions Elements” on page 213
• “Implementing Claim-based Exposure Security” on page 214

Static Versus Claim-based Exposure Security

You can implement static or claim-based exposure security.

Static exposure Requires only that you construct an <ExposurePermissions> element in security-config.xml.
security
Claim-based Requires that you map the exposure security type to a system permission, which you then map to a claim
exposure access type. See “Add a Custom Permission” on page 214 for an example of how to construct this type of
security security access.

212 chapter 14 Securing Access to Claims and Exposures

 System Administration Guide 9.0.5

See also
• “The Security Configuration File” on page 188
• “Exposure Access Control” on page 212
• “Exposure Security Controls Overview” on page 212
• “Exposure Permissions Elements” on page 213
• “Implementing Claim-based Exposure Security” on page 214

Exposure Permissions Elements

<ExposurePermissions> elements provides a means for setting the security type on an exposure. There are no
limits to the number of <ExposurePermission> elements that can exist in security-config.xml. However, all
<ExposurePermissions> elements must come at the end of the security-config.xml file. Each
<ExposurePermissions> element can contain zero to many <ExposurePermission> elements.
This element has the following syntax.

<ExposurePermissions>
<ExposurePermission securitylevel="type" permission="perm"/>
</ExposurePermissions>

The attributes on the various elements have the following meanings.

Element Attribute Required Description

ExposurePermission permission Yes A system permission defined in the SystemPermissionType typelist.
securitylevel No An security type defined in the ExposureSecurityType typelist. In the
base configuration, Guidewire does not provide any exposure security
types. You must define your own exposure security types.

ClaimCenter considers exposures with an undefined securitylevel as having the null security level. To assign a
permission to these exposures, specify an <ExposurePermission> element without a securitylevel parameter.
Only define one <ExposurePermission> that omits the securitylevel. If you specify more than one,
ClaimCenter assigns the last one encountered to exposures at the null level.
The following example illustrates an <ExposurePermissions> element.

<ExposurePermissions>
<ExposurePermission securitylevel="secured" permission="expeditsec"/>
<ExposurePermission permission="unsecexpedit"/>
</ExposurePermissions>

Note: You can only map each security type single time. Thus, you can map secured exposures to expeditsec, but
not to viewsecexp.
To access a secured exposure (or its related objects), users also need to have the expeditsec permission on at least
one role.
See also
• “The Security Configuration File” on page 188
• “Exposure Access Control” on page 212
• “Exposure Security Controls Overview” on page 212
• “Static Versus Claim-based Exposure Security” on page 212
• “Implementing Claim-based Exposure Security” on page 214

Exposure Access Control 213

 System Administration Guide 9.0.5

Implementing Claim-based Exposure Security

It is possible use a custom abexposures permission to implement claim-based security on an exposure. If this
access control is in place, then users must have both the abexposures permission and access to the particular claim
to access an exposure. The abexposures permission grants access to exposures. A custom <ClaimAccessProfile>
element defines access to the particular claim.
Guidewire recommends that you implement the claim-based method only with custom claim access types. You need
one custom claim access type for each exposure security type. Many custom claim access types can put a
performance load on the system. Use this method with care.
Note: You cannot use the default claim access types for claim-based exposure security. Mapping the default claim
access type view to both the abexposures and the expview would eliminate the distinction between all claim
exposures and abexposures exposures.

Add a Custom Permission

Before you begin

Read and understand the concepts in “Implementing Claim-based Exposure Security” on page 214 before attempting
the steps listed in this procedure.

Procedure
1. In the ClaimCenter Studio Project window, expand configuration→config→Metadata→Typelists.
a. Open SystemPermissionType.tti.
b. Click the SystemPermissionType.ttx link.
c. Click the plus icon next to typecode.
d. Enter abexposures in the code field.
The code value must be 16 characters or less.
e. Add values for name and desc (description) attributes to the new security type.
f. Leave the priority attribute as -1 and the retired attribute as false.
2. In a similar manner, create an abexposures type code in the ClaimAccessType typelist.
It is possible to create a claim access type and an exposure security type with the same typecode.
3. In Studio, expand configuration→config→security:
a. )Open security-config.xml.
b. Create an <ExposurePermissions> element that looks similar to the following in file security-
config.xml.

<ExposurePermissions>
<ExposurePermission securitylevel="abexposures" permission="abexposures"/>
</ExposurePermissions>

All <ExposurePermissions> elements must come at the end of security-config.xml.

c. Create an <AccessMapping> element in the security-config.xml file, for example:

<AccessMapping claimAccessType="abexposures" systemPermission="abexposures"/>

d. Create an <AccessProfile> element for security level sensitiveclaim that references this access type,
for example:

<AccessProfile securitylevel="sensitiveclaim">
...
<ExposureAccessLevels>
<AccessLevel level="user" permission="abexposure"/>

214 chapter 14 Securing Access to Claims and Exposures

 System Administration Guide 9.0.5

</ExposureAccessLevels>
</AccessProfile>

e. Save your work.

4. Rebuild and redeploy your application package file if you are in a production environment.
5. Update and rebuild the typelist information:
a. In a command prompt window, navigate to the ClaimCenter installation directory
b. Run the following command:

gwb genDataDict

Next steps
See also
• “The Security Configuration File” on page 188
• “Add a New Claim-related System Permission” on page 202
• “Access Mapping Elements” on page 204
• “Access Profile Elements” on page 205
• “Exposure Access Control” on page 212
• “Exposure Security Controls Overview” on page 212
• “Static Versus Claim-based Exposure Security” on page 212
• “Exposure Permissions Elements” on page 213

Implementing Claim-based Exposure Security 215

 System Administration Guide 9.0.5

216 chapter 14 Securing Access to Claims and Exposures

part 5

Database Administration
System Administration Guide 9.0.5
chapter 15

Database Configuration

This topic discusses database configuration file database-config.xml and how to use the file to configure
ClaimCenter database options.
See also
• “Database Best Practices” on page 259
• “Guidewire Database Direct Update Policy” on page 261
• “ClaimCenter Database Back Up” on page 262
• “Database Consistency Checks” on page 262
• “Resize Database Columns” on page 267
• “Purging Unwanted Data” on page 267
• “Understanding Database Statistics” on page 279
• “Understanding Claim Purging” on page 273
• “Configuration Parameters that Affect Claim Search on Oracle” on page 277
• “Oracle Materialized Views for Claim Searches” on page 277

Accessing the Database Configuration File

You access file database-config.xml from the Guidewire Studio Project window, in the following location:
configuration→config
You can view, but not edit, many of the database configuration parameters from within ClaimCenter at Server
Tools→Info Pages→Database Parameters.

Database Configuration 219

 System Administration Guide 9.0.5

See also
• “The Database Configuration File” on page 220
• “Database Parameters” on page 368

The Database Configuration File

Guidewire provides the means to configure various aspects of the ClaimCenter database through configuration file
database-config.xml. This XML-formatted file contains a root <database> element with a number of
subelements that you use to implement database configuration options specific to your database type.
The <database> element has the following syntax. The following code sample shows required attributes in bold
font.

<database addforeignkeys="true|false" autoupgrade="full|manual" checker="true|false" dbtype="h2|oracle|sqlserver" en

v="string"
name="string" printcommands="true|false" versionchecksonly="true|false">

<!-- Sets options for the generation of database statistics at the global, database level -->
<databasestatistics databasedegree="integer" incrementalupdatethresholdpercent="integer"
numappserverthreads="integer" samplingpercentage="integer" useoraclestatspreferences="true|false">

<!-- Sets database statistics options for the named table -->
<tablestatistics action="delete|keep|update" databasedegree="integer" name="string"
samplingpercentage="integer">

<!-- Sets database statistics options for the named column on the named table -->
<histogramstatistics name="string" numbbuckets="integer"/>

</tablestatistics>

</databasestatistics>

<!-- Sets options for the connection pool that Guidewire provides -->
<dbcp-connection-pool jdbc-url="string" max-idle="integer" max-total="integer" max-wait="integer"
min-evictable-idle-time="integer" num-tests-per-eviction-run="integer" password-file="string"
test-on-borrow="true|false" test-on-return="true|false" test-while-idle="true|false"
time-between-eviction-runs="integer" when-exhausted-action="block|fail|grow">
<reset-tools-params collation="string" oracle-tnsnames="string" system-password="string"
system-username="string"/>
</dbcp-connection-pool>

<!-- Sets the data source for a JBoss, Tomcat, WebLogic, or WebSphere application server-->
<jndi-connection-pool datasource-name="string"/>

<!-- Sets performance-related database options at a global, database level -->

<loader after-insert-select-callback-degree-of-parallelism="integer"
before-gen-ids-callback-degree-of-parallelism="integer"
before-insert-select-callback-degree-of-parallelism="integer"
drop-deferrable-indexes="disable|enable|enable_all"
fk-enable-degree-of-parallelism="integer" insert-select-degree-of-parallelism"integer"
num-threads-integrity-checking="integer" row-counts-degree-of-parallelism="integer">

<!-- Sets database parallelism optons for database callbacks -->

<callback after-insert-select-callback-degree-of-parallelism="integer"
before-gen-ids-callback-degree-of-parallelism="integer"
before-insert-select-callback-degree-of-parallelism="integer"
insert-select-degree-of-parallelism="integer" name="string"/>

<!-- Sets performance options for the named table, overrides values set at the database level -->
<loader-table drop-deferrable-indexes="disable|enable|enable_all"
fk-enable-degree-of-parallelism="integer" name="string"
row-counts-degree-of-parallelism="integer"/>
<loader-index key-columns="string"/>
</loader-table>

</loader>

<!-- Sets options for an Oracle database -->

220 chapter 15 Database Configuration

 System Administration Guide 9.0.5

<oracle-settings adaptive-optimization="OFF|REPORTING_ONLY" db-resource-mgr-cancel-sql="string"

query-rewrite="true|false" statistics-level-all="true|false"
stored-outline-category="string"/>

<!-- Sets options for a SQL Server database -->

<sqlserver-settings jdbc-trace-file="string" jdbc-trace-level="string" unicodecolumns="true|false"/>

<!-- Sets various options related to database upgrade -->

<upgrade>

<mssql-db-ddl>

<!-- Sets SQL Server database options at the global, database level -->
<mssql-compression index-compression="NONE|PAGE|ROW" table-compression="NONE|PAGE|ROW/>
<mssql-filegroups admin="string" index="string" lob="string" op="string" staging="string"
typelist="string"/>

<!-- Set SQL Server options for the named table, overrides values set at database level -->
<mssql-table-ddl table-name="string">
<mssql-index-ddl filter-where="string"index-compression="NONE|PAGE|ROW"
index-filegroup="string" key-columns="string" partition-scheme="string"/>
<mssql-table-compression index-compression="NONE|PAGE|ROW" table-compression="NONE|PAGE|ROW"/>
<mssql-table-filegroups="string" index-filegroup="string" lob-filegroup
table-filegroup="string"/>
</mssql-table-ddl>

</mssql-db-ddl>

<ora-db-ddl>

<!-- Sets Oracle database options at the global, database level -->
<ora-compression index-compression="true|false" table-compression="ADVANCED|BASIC|NONE"/>
<ora-lobs caching="true|false" type="BASIC|SECURE|SECURE_COMPRESSED/>
<tablespaces admin="string" index="string" lob="string" op="string" staging="string"
typelist="string"/>

<!-- Sets Oracle options for the named table, overrides values set at the database level -->
<ora-table-ddl table-name="string">
<ora-index-ddl index-compression="true|false" index-tablespace="string" key-columns="string"/>
<ora-lobs caching="true|false" type="BASIC|SECURE|SECURE_COMPRESSED/>
<ora-table-compression index-compression="true|false" table-compression="ADVANCED|BASIC|NONE">
<ora-table-date-interval-partitioning datecolumn="string"
interval="DAILY|MONTHLY|QUARTERLY|WEEKLY|YEARLY">
<ora-table-hash-partitioning hash-columns="string" num-partitions="integer"/>
<ora-table-tablespaces index-tablespace="string" lob-tablespace="string"
table-tablespace="string"/>
</ora-table-ddl>

</ora-db-ddl>

<versiontriggers dbmsperfinfothreshold="integer">

<!-- Sets override options for the named database version trigger -->
<versiontrigger extendedquerytracingenabled="true|false" name="string"
parallel-dml="true|false" parallel-query="true|false"
queryoptimizertracingenabled="true|false" recordcounters="true|false"
updatejoinorderedhint="true|false" updatejoinusemergehint="true|false"
updatejoinusenlhint="true|false"/>

</versiontriggers>

</upgrade>

</database>

File database-config.xml contains a single root-level <database> element that takes the following attributes.

name Required. String identifying the database for which ClaimCenter uses this connection specification.
dbtype Required. Database type, either h2 (for the QuickStart database), oracle, or sqlserver.
The following attributes are all optional.

The Database Configuration File 221

 System Administration Guide 9.0.5

addforeignkey Used only for development and testing. Do not use this attribute in production. The default is true.
autoupgrade Use to set how to upgrade the database. Valid values are:
• full – Takes precedence and initiates a full upgrade assuming all other necessary conditions are
met.
• manual – Requires that you set either the database upgrade type (in Server Tools Upgrade and
Versions screen) or the date system property.
checker Boolean. Whether ClaimCenter runs consistency checks before it starts:
• Development environments – For development environments with small data sets, you can
enable consistency checks to run each time the ClaimCenter server starts. Set the value of check
er in the database block to true to enable checks on server startup.
• Production environments – Running consistency checks upon server startup can take a long time,
impact performance severely, and possibly time out on very large datasets. Set the value of chec
ker in the database block to false to disable checks on server startup.
Valid values are:
• true – Guidewire recommends that you only set checker to true in development environments
with a small set of test data.
• false – Guidewire recommends that you set checker to false under most circumstances.
The default is true.
See the following for more information:
• “Database Consistency Checks” on page 262
• “Configure Consistency Checks to Run at Server Startup” on page 264
env Use of the env attribute to set a server environment enables you to provide different database
configurations for different server environments. For example, you can set up different database
configurations for a production environment and a test environment.
See “Example Syntax for Registry Server Element” on page 48 for more information.
printcommands Boolean. Whether the server prints database upgrade messages to the console upon startup. Valid
values are:
• true - By default, Guidewire sets the value of printcommands to true in the base configuration.
• false - Do not set printcommands to false in a production environment.
The default is true.
versionchecksonly Boolean. Whether the ClaimCenter server runs only database version checks at startup, without
performing any actual database upgrade steps:
• true - ClaimCenter runs all version checks regardless of a failure in one of the checks.
• false - ClaimCenter stops the upgrade if it detects an error.
The default is false. Changes to this attribute take effect only during an application upgrade.

The <database> element takes the following subelements. There is, at most, a single occurrence of each of these
subelements in the <database> element.

databasestatistics Specifies parameters that control the generation of database statistics. See “The databasestatistics
Database Configuration Element” on page 224 and “Database Statistics Generation” on page 279
for more information.
dbcp-connection-pool Specifies parameters for connection pool shared using dbcp. You must include this subelement if
using a dbcp data source. See “The dbcp-connection-pool Database Configuration Element” on page
225 and the Installation Guide for more information.
jndi-connection-pool Specifies parameters for a connection pool shared using JNDI. You must include this subelement if
using a jndi data source. See “The jndi-connection-pool Database Configuration Element” on page
228 and the Installation Guide for more information.

222 chapter 15 Database Configuration

 System Administration Guide 9.0.5

loader Specifies configuration parameters that affect the loading of data into the ClaimCenter database
using staging tables. See “The loader Database Configuration Element” on page 231 for more
information.
oracle-settings Specifies settings for Oracle databases. See “The oracle-settings Database Configuration Element” on
page 236 and the Installation Guide for more information.
sqlserver-settings Specifies settings for SQL Server databases. See “The sqlserver-settings Database Configuration
Element” on page 237 and the Installation Guide for more information.
upgrade Specifies ClaimCenter behavior during a database upgrade. See “The upgrade Database
Configuration Element” on page 237 for more information.

See also
• Installation Guide

The Database autoupgrade Attribute

You use the autoupgrade attribute on the <database> element in file database-config.xml to manage
ClaimCenter configuration and database upgrades. The autoupgrade attribute has the following syntax:
<database ... autoupgrade="full|manual" .../>
The attribute value has the following meaning. The default value is manual if the attribute is missing.

autoupgrade Description
attribute
full Whenever the application server starts, if it determines the need for a full upgrade, the presence of this
attribute set to full is sufficient permission to perform the upgrade. With this setting:
• If a rolling (configuration) upgrade is already in progress as the server starts, the server throws an
exception, to force the choice of an upgrade type.
• If a full upgrade is already in progress by other means as the server starts, there is no issue as this
setting is consistent with the a full upgrade.
manual This setting requires that you explicitly set the permission to upgrade through one of the following means:
• Setting the database upgrade type in the Server Tools Upgrade and Versions screen and initiating the
upgrade from that screen.
• Setting the following Java system property to the current date as the application server starts:
-Dgw.cc.full.upgrade.intended.date
See “Unexpected Upgrades” on page 177 for a discussion of the use of this Java system property.
You must set the value of autoupgrade to manual if performing a rolling (configuration) upgrade.

The behavior of this attribute depends on the following:

• Whether you are working with a single ClaimCenter server or with multiple ClaimCenter servers in a clustered
server environment.
• Whether you are attempting a full ClaimCenter database upgrade or using a rolling upgrade to implement
application configuration changes.

Single ClaimCenter Server Installations

The following tables describe the interactions between setting Start Full Upgrade on the Upgrade and Versions screen and
the value of the autoupgrade attribute.

Start Full Upgrade autoupgrade Result

Set Not set or full The server starts, the upgrade completes, and ClaimCenter updates the Upgrade and
Versions screen.

The Database Configuration File 223

 System Administration Guide 9.0.5

Start Full Upgrade autoupgrade Result

Not set Not set or manual The server does not start, the upgrade fails, and ClaimCenter logs an error message.

The following table describes the interactions between setting Start Full Upgrade on the Upgrade and Versions screen and
the value of the autoupgrade attribute during deployment of non-data model changes to a production mode server.

Start Full Upgrade autoupgrade Result

Set Not set or full The server starts, the upgrade completes, and ClaimCenter updates the Upgrade and
Versions screen.

Not set Not set or manual The ClaimCenter server starts.

Clustered ClaimCenter Server Installations

In clustered ClaimCenter server installations, the autoupgrade attribute has the following behavior.

autoupgrade Result
full If you set the value of autoupgrade attribute to full, any attempt to start a rolling upgrade fails. In addition,
you must always set the upgrade type (full) using the Server Tools Upgrade and Versions screen, or, by using the sy
stem_tools -startfullupgrade command option, for example.

manual If you set the value of autoupgrade attribute to manual, you must always set the upgrade type (full or rolling) or
the upgrade fails. You can set the upgrade type in the Server Tools Upgrade and Versions screen or by setting a
JVM parameter at server startup. For a rolling upgrade, the new configuration (database-config.xml) must set
this value to manual. This new value overrides any value set in the old configuration.
Not set If you do not set the value of autoupgrade attribute, ClaimCenter assumes a default value of manual and
behaves accordingly.

The databasestatistics Database Configuration Element

The <database> element in file database-config.xml contains a single occurrence of subelement
<databasestatistics>. Use this element to control how ClaimCenter generates database statistics statements.
The <databasestatistics> element has the following syntax. The following code sample shows required
attributes in bold font.

<database>

<databasestatistics databasedegree="integer" incrementalupdatethresholdpercent="integer"

numappserverthreads="integer" samplingpercentage="integer" useoraclestatspreferences="true|false">

<!-- Sets database statistics options for the named table -->
<tablestatistics action="delete|keep|update|force" databasedegree="integer" name="string"
samplingpercentage="integer">

<!-- Sets database statistics options for the named column on the named table -->
<histogramstatistics name="string" numbbuckets="integer" />

</tablestatistics>

</databasestatistics>

</database>

The following list describes the attributes that you can configure on the <databasestatistics> element. All of
these attributes are optional. See “The Database Statistics Element” on page 285 for more information on these
attributes.

224 chapter 15 Database Configuration

 System Administration Guide 9.0.5

databasedegree On Oracle, this attribute controls the degree of database parallelism that
Oracle uses in executing each individual statement. The default is 1.
ClaimCenter uses the value of this attribute for all statements.
SQL Server ignores the databasedegree attribute.
incrementalupdatethresholdpercent This attribute specifies the percentage of table data that must have
changed since the last statistics process for the incremental statistics
generation batch process to update statistics for the table.
numappserverthreads On both Oracle and SQL Server, the numappserverthreads attribute
controls the number of threads that ClaimCenter uses to update database
statistics for staging tables during import only.
samplingpercentage The behavior of this attribute depends on the database type. For Oracle,
Guidewire recommends that you always set this value to 0 to enable Oracle
auto-sampling.
useoraclestatspreferences On Oracle, this attribute sets the database statistics preferences to be able
to use the Oracle Autotask infrastructure instead of the DBStats batch
process from ClaimCenter. The default is false, which requires that you
disable the Autotask and schedule DBStats batch processing in its place.
Changes to the value of this attribute only take effect during an application
upgrade.

The <databasestatistics> element has the following subelement.

tablestatistics Provides overrides of database-wide statistics settings defined on the <databasestatistics> element for
a specific table. There can be multiple occurrences of the <tablestatistics> subelement on the <databa
sestistics> element.

See also
• “The Database Configuration File” on page 220
• “Understanding Database Statistics” on page 279
• “Configuring Database Statistics Generation” on page 284
• “The Database Statistics Element” on page 285
• “The Table Statistics Database Element” on page 289
• “Database Statistics” on page 373
• “Using Oracle AutoTask for Statistics Generation” on page 287
• “System Tools Options” on page 423

The dbcp-connection-pool Database Configuration Element

The <database> element in file database-config.xml contains, at most, a single occurrence of subelement <dbcp-
connection-pool>. The use of the <dbcp-connection-pool> element is optional. If using ClaimCenter to manage
the connection pool rather than a JNDI data source managed by the application server, you must use this element to
configure the connection pool behavior.
Note: Guidewire implements its own version of the Apache Commons Pool, overriding specific values to provide
improved functionality.
If you experience slow performance, it is possible that the ClaimCenter server is not allocating enough database
connections. If all database connections are in use, any client attempting to connect to the server must wait until a
connection is free. By default, ClaimCenter periodically tests connections in the connection pool using a simple
query and evicts idle connections and those that fail with an exception.

The dbcp-connection-pool Database Configuration Element 225

 System Administration Guide 9.0.5

The <dbcp-connection-pool> element has the following syntax. The following code sample shows required
attributes in bold font.

<database>

<!-- Sets options for the connection pool that Guidewire provides -->
<dbcp-connection-pool jdbc-url="string" max-idle="integer" max-total="integer" max-wait="integer"
min-evictable-idle-time="integer" num-tests-per-eviction-run="integer" password-file="string"
test-on-borrow="true|false" test-on-return="true|false" test-while-idle="true|false"
time-between-eviction-runs="integer" when-exhausted-action="block|fail|grow">
<reset-tools-params collation="string" oracle-tnsnames="string" system-password="string"
system-username="string"/>
</dbcp-connection-pool>

</database>

The following list describes the attributes that you can configure on the <dbcp-connection-pool> element.
Note: These attributes apply only if you use the default connection pool. If you use the server connection pool,
these settings do not apply. Configure the server connection pool instead through the administration console
provided with the server. See the Installation Guide for more information.

jdbc-url Required. Stores connection information for the database. The format of
the jdbc-url value changes depending on the database type. See the
Installation Guide for more information.
The following attributes are all optional.
max-idle Maximum number of connections that can sit idle in the pool at any time.
If negative, there is no limit to the number of connections that can be idle
at any given time. The default is -1.
max-total Maximum number of connections that the connection pool can allocate,
including those in use by a client or that are in an idle state awaiting use. A
reasonable initial value for this is about 25% of the number of users that
you expect to use ClaimCenter at the same time.
If set to a negative integer, there is no limit to the number of allowed
database connections. The default is -1.
If the number of database connections reaches the value of max-total,
ClaimCenter considers the connection pool to have no more available
connections.
max-wait Maximum amount of time, in milliseconds, that the data source waits for a
connection before one becomes available in the pool to service. The
default is 30000.
The value of the max-wait attribute interacts with the when-exhausted-ac
tion attribute. See that attribute for more information.

min-evictable-idle-time Maximum time, in milliseconds, that a connection can sit idle in the pool
before it is eligible for eviction due to idle time. If a connection is idle more
the specified number of milliseconds, ClaimCenter evicts the connection
from the pool. The default is 300000 milliseconds.
If this value is a non-positive integer, ClaimCenter does not drop
connections from the pool due to idle time alone. This setting has no effect
unless the value of time-between-eviction-runs is greater than 0.
During an eviction run, ClaimCenter scans the connection pool and tests
the number of idle connections equal to the value of num-tests-per-evic
tion-run.

num-tests-per-eviction-run Number of idle connections that ClaimCenter tests in each eviction run.
This setting has no effect unless the value of time-between-eviction-run
s is greater than 0. The default is 3.

226 chapter 15 Database Configuration

 System Administration Guide 9.0.5

password-file Use to hide the value of the database connection password in the jdbc-ur
l connection string. Instead of providing the password in the connection
string, you can place the password in an external file and reference this file
from file database-config.xml. See the Installation Guide for more
information.
test-on-borrow Boolean. Whether ClaimCenter tests a connection by running a simple
validation query as ClaimCenter first borrows the connection from the
connection pool. If set to true, the connection pool attempts to validate
each connection before ClaimCenter uses the connection from the
connection pool. If a connection fails validation, the connection pool drops
the connection and chooses a different connection to borrow. The default
is false.
ClaimCenter returns any connection used only for a query to the pool
immediately after the query completes. Thus, running a test query every
time that a connection returns to the pool can potentially affect
performance.
test-on-return Boolean. Whether ClaimCenter tests a connection by running a simple
validation query as ClaimCenter returns the connection to the connection
pool. If set to true, the connection pool attempts to validate each
connection that ClaimCenter returns from the database. The default is fal
se.
ClaimCenter returns any connection used only for a query to the pool
immediately after the query completes. Thus, running a test query every
time that a connection returns to the pool can potentially affect
performance.
test-while-idle Boolean. Whether ClaimCenter performs validation on idle connections in
the connection pool. If set to true, the connection pool performs
validation on idle connections. It drops connections that fail the validation
test. The default is true.
This attribute value has no effect unless the value of time-between-evict
ion-runs is greater than zero.

time-between-eviction-runs Time, in milliseconds, that ClaimCenter waits between eviction runs of idle
connections in the connection pool. The default is 60000.
If set to a a non-positive integer, ClaimCenter does not launch any eviction
threads.
when-exhausted-action Specifies the behavior of the connection pool if the pool has no more
connections. Set this attribute to one of the following values:
• fail – If the there are no more connections available, ClaimCenter
throws a NoSuchElementException exception.
• grow – If there are no more connections available, ClaimCenter creates
a new connection and returns it, essentially making max-active
meaningless.
• block – If there are no more connections available, ClaimCenter blocks
connections until a new or idle connection becomes available. If the
value of max-wait is positive, then ClaimCenter blocks, at most, for that
number of milliseconds, after which ClaimCenter throws a NoSuchElem
entException exception. If the value of max-wait is non-positive,
ClaimCenter blocks indefinitely.
The default is block.

The <dbcp-connection-pool> element has the following subelement.

reset-tools-params See “The reset-tool-params Database Configuration Element” on page 228 for more information.

The dbcp-connection-pool Database Configuration Element 227

 System Administration Guide 9.0.5

See also
• “The Database Configuration File” on page 220
• “Database Parameters” on page 368

The reset-tool-params Database Configuration Element

The <dbcp-connection-pool> element in file database-config.xml contains, at most, a single occurrence of
subelement <reset-tool-params>. The use of the <reset-tool-params> element is optional. Use this element to
configure DBResetTool, not the DBCP connection pool. Guidewire defines the <reset-tool-params> element as a
subelement of the <dbcp-connection-pool> element because DBResetTool only works on databases defined in the
<dbcp-connection-pool> element.
The <reset-tool-params> element has the following syntax.

<database>
<dbcp-connection-pool>
<reset-tools-params collation="string" oracle-tnsnames="string" system-password="string"
system-username="string"/>
</dbcp-connection-pool>
</database>

The following list describes the attributes that you can configure on the <reset-tools-params> element. All of
these attributes are optional.

collation Collation value to use if creating a new H2 (QuickStart) or SQL Server database:
• H2 – Sets database collation using the Java Collation class.
• SQL Server – Sets database collation to a Microsoft Window’s or SQL collation name.
DBResetTool (dropdb) uses the value of this attribute if creating a new H2 or SQL Server database.

oracle-tnsnames (Oracle) Name of the Oracle tnsnames.ora file.

system-password (Oracle) Database system password.

system-username (Oracle) Database system username.

The <reset-tools-arams> element has no subelements.

See also
• “The Database Configuration File” on page 220

The jndi-connection-pool Database Configuration Element

The <database> element in file database-config.xml contains, at most, a single occurrence of subelement <jndi-
connection-pool>. The use of the <jndi-connection-pool> element is optional. However, file database-
config.xml must contain this element if you use a JNDI (Java Naming and Directory Interface) data source
managed by a JBoss, Tomcat, WebLogic, or WebSphere application server.
The <jndi-connection-pool> element has the following syntax. The following code sample shows required
attributes in bold font.

<database>

<!-- Sets the data source for a JBoss, Tomcat, WebLogic, or WebSphere application server-->
<jndi-connection-pool datasource-name="string"
connections-initialized-for-application="true|false"/>

</database>

228 chapter 15 Database Configuration

 System Administration Guide 9.0.5

IMPORTANT If you modify the <jndi-connection-pool> element in any way, you must restart the application
server.

The following list describes the attributes that you can configure on the <jndi-connection-pool> element.

datasource-name Required. Specifies the JNDI name to assign to the data source. See the
Installation Guide for more information.
The following attribute is optional.
connections-initialized-for-application (Oracle) Boolean. Controls the number of SQL statements that ClaimCenter
executes on every connection that it borrows from an external data source.
This setting applies to the named JNDI database connection set up in this <
jndi-connection-pool> element only.
Valid values are:
• true – If configured appropriately, the data source provides
connections with certain Oracle database parameters set to their
desired values.
• false – ClaimCenter runs a set of SQL statements on each and every
database connection that it borrows from the data source.
The default is false.
To take advantage of this feature:
• Your ClaimCenter installation must use an Oracle database.
• You must configure the data source appropriately.
See “Configuring JNDI Connection Initialization for Oracle” on page 229 for
more information.
IMPORTANT If you set this attribute to true and do not initialize the
connections properly, the application server refuses to start and logs an
error message for each incorrect setting.

The <jndi-connection-pool> element has no subelements.

See also
• “The Database Configuration File” on page 220
• “Configuring JNDI Connection Initialization for Oracle” on page 229

Configuring JNDI Connection Initialization for Oracle

Boolean attribute connections-initialized-for-application on the <jndi-connection-pool> element in
database-config.xml configures how the JNDI data source provides connections to ClaimCenter.

Attribute connections-initialized-for-application Set to True

If you set the value of attribute connections-initialized-for-application to true, you must provide the
correct settings for the Oracle database parameters that the external data sources uses for connection initialization. If
you do not initialize the connections properly, the application server refuses to start and logs an error message for
each incorrect setting. Guidewire recommends that you set this attribute to true, then start the application server.
You can then determine the correct values to use for your database from the log error messages.
In general, the Oracle database parameters to use for connection initialization have the following meanings:

Oracle parameter Meaning

CURSOR_SHARING Boolean. The exact setting is dependant on your database installation.
MODULE The module name, which must include the database user name as well. For example, if your database user
name is CCPROD1, then set the module name to ClaimCenter_CCPROD1.

The jndi-connection-pool Database Configuration Element 229

 System Administration Guide 9.0.5

Oracle parameter Meaning

NLS_SORT The default sort collation for the Oracle database. The exact setting is dependent on your Guidewire
installation. See the Globalization Guide for more information.
NLS_COMP The database collation behavior. Set this value to BINARY.

To use this feature, you must configure the application server to manage the connection initialization. See “Set
Oracle Database Parameters for Connection Initialization” on page 230 for more information.

Attribute connections-initialized-for-application Set to False

If you set the value of attribute connections-initialized-for-application to false, the external data source
takes no action to configure the borrowed connections before placing an item in the connection pool. This causes
ClaimCenter to run a set of SQL statements on each and every connection that it borrows from the data source.
Although the cost in time of each of these statements is very small, Guidewire applications sometimes borrow
connections at a very high rate. Thus, it is possible for the time to execute these statements to become measurable
and to become visible during performance analysis in the Guidewire Profiler.

Set Oracle Database Parameters for Connection Initialization

About this task

Boolean attribute connections-initialized-for-application on the <jndi-connection-pool> element in
database-config.xml configures how the JNDI data source provides connections to ClaimCenter. To use this
feature with an external data source, you must configure your data source to initialize a set of Oracle database
parameters.

Procedure
1. Set attribute connections-initialized-for-application on the <jndi-connection-pool> element to
true.
2. Start the application server.
3. From the server log, determine the exact values to set for connection initialization.
4. Depending on your application server, set up the connection initialization as appropriate.
See “Connection Initialization for Oracle Databases” on page 230 for more information.
5. After completing your initialization configuration, restart the application server and Guidewire ClaimCenter.

Connection Initialization for Oracle Databases

If using an Oracle database, it is possible to configure an application server to initialize a data pool connection
before ClaimCenter uses that connection. This can improve performance. To use this functionality, you must set
Boolean attribute connections-initialized-for-application on the <jndi-connection-pool> element in
database-config.xml to true.

WebLogic Application Servers

Use the WebLogic Administration Console to specify a SQL statement that initializes each data source connection
before WebLogic adds that connection to the pool.
If you have more than one statement to execute, you can put the statements into a SQL block. For example:

SQL BEGIN
DBMS_APPLICATION_INFO.SET_MODULE('ClaimCenter_CCPROD1', NULL);
EXECUTE IMMEDIATE 'ALTER SESSION SET NLS_SORT = BINARY_CI';
END;

230 chapter 15 Database Configuration

 System Administration Guide 9.0.5

Note: In the sample code, replace ClaimCenter_CCPROD1 with the actual name of the Oracle database followed by
the logon user username.
See also
• “Configuring JNDI Connection Initialization for Oracle” on page 229

Non-WebLogic Application Servers

One way to initialize the connections appropriately is to create an Oracle logon trigger for the owner of the database
schema. The following sample code illustrates how to create a logon trigger. You must be logged on as the system
user to execute this trigger.

CREATE OR REPLACE TRIGGER

AFTER LOGON ON DATABASE
BEGIN

IF (USER = 'Guidewire schema owner')

THEN
DBMS_APPLICATION_INFO.SET_MODULE('ClaimCenter_CCPROD1', NULL);
EXECUTE IMMEDIATE 'ALTER SESSION SET NLS_SORT = BINARY_CI';
END IF;

END;
/

Note: In the sample code, replace Guidewire schema owner with Oracle database system username. Replace
ClaimCenter_CCPROD1 with the actual name of the Oracle database followed by the logon user username.
See also
• “Configuring JNDI Connection Initialization for Oracle” on page 229

The loader Database Configuration Element

The <database> element in file database-config.xml contains, at most, a single occurrence of subelement
<loader>. The use of the <loader> element is optional. Use this element to define configuration parameters that
affect the loading of data into the ClaimCenter database using staging tables. One important area of configuration is
the degree of database parallelism to use in an Oracle database. Database parallelism refers to the ability of an
Oracle database to execute a database SQL statement such as CREATE or INSERT using simultaneous, parallel slave
processes.
If using parallel DML (Data Manipulation Language) statements:
• ClaimCenter commits data after every INSERT statement during data load to the staging tables. ClaimCenter also
commits data during some of the callback operations related to UPDATE and INSERT statements.
• If there are failures in the data load, you need to restore the database from a backup of the database taken prior to
the execution of the data load. Data load can fail, for example, if there are Oracle space errors or memory issues.
The <loader> element has the following syntax. The following code sample shows required attributes in bold font.

<database>

<!-- Sets performance-related database options at a global, database level -->

<loader after-insert-select-callback-degree-of-parallelism="integer"
before-gen-ids-callback-degree-of-parallelism="integer"
before-insert-select-callback-degree-of-parallelism="integer"
drop-deferrable-indexes="disable|enable|enable_all"
fk-enable-degree-of-parallelism="integer" insert-select-degree-of-parallelism"integer"
num-threads-integrity-checking="integer" row-counts-degree-of-parallelism="integer">

<!-- Sets database parallelism optons for database callbacks -->

<callback after-insert-select-callback-degree-of-parallelism="integer"
before-gen-ids-callback-degree-of-parallelism="integer"
before-insert-select-callback-degree-of-parallelism="integer"
insert-select-degree-of-parallelism="integer" name="string"/>

The loader Database Configuration Element 231

 System Administration Guide 9.0.5

<!-- Sets performance options for the named table, overrides values set at the database level -->
<loader-table drop-deferrable-indexes="disable|enable|enable_all"
fk-enable-degree-of-parallelism="integer" name="string"
row-counts-degree-of-parallelism="integer"/>
<loader-index key-columns="string"/>
</loader-table>

</loader>

</database>

The following list describes the attributes that you can configure on the <loader> element. All of these attributes are
optional.

after-insert-select-callback-degree-of-parallelism (Oracle) Controls the degree of database parallelism that

Oracle uses for callback operations after an INSERT SELECT
operation on staging data:
• 1 – No database parallelism.
• Positive integer less than 1000 – Database parallelism,
with the specified value as the degree of parallelism.
The default is 1.
before-gen-ids-callback-degree-of-parallelism (Oracle) Controls the degree of database parallelism that
Oracle uses for callback operations before ID generation:
• 1 – No database parallelism.
• Positive integer less than 1000 – Database parallelism,
with the specified value as the degree of parallelism.
The default is 1.
before-insert-select-callback-degree-of-parallelism (Oracle) Controls the degree of database parallelism that
Oracle uses for callback operations before an INSERT SELECT
operation on staging data:
• 1 – No database parallelism.
• Positive integer less than 1000 – Database parallelism,
with the specified value as the degree of parallelism.
The default is 1.
drop-deferrable-indexes Specifies whether it is possible to drop performance-only
indexes at a global, database level before the loading of data
into staging tables. ClaimCenter then recreate the indexes
after the data load. Dropping these indexes improves the
performance of data loading.
Valid values are:
• disable – Do not drop performance-only indexes.
• enable – Drop performance-only indexes on the table
specified by a <loader-table> subelement.
• enable_all – Drops all performance-only indexes for all
tables in the database.
The default is disable. See the Installation Guide for more
information.
fk-enable-degree-of-parallelism (Oracle) Controls the degree of database parallelism that
Oracle uses for re-enabling foreign key constraints after an IN
SERT SELECT operation.
• 1 – No database parallelism.
• Positive integer less than 1000 – Database parallelism,
with the specified value as the degree of parallelism.
The default is 1.

232 chapter 15 Database Configuration

 System Administration Guide 9.0.5

insert-select-degree-of-parallelism (Oracle) Controls the degree of database parallelism that

Oracle uses for the INSERT SELECT operation itself:
• 1 – No database parallelism.
• Positive integer less than 1000 – Database parallelism,
with the specified value as the degree of parallelism.
The default is 1.
num-threads-integrity-checking Specifies the number of threads to use while running integrity
checks. Adjust this number to the load capacity of the
database server. The default is 1.
Valid values are:
• Not specified – ClaimCenter assumes the number of
threads to be one, no multithreading.
• 1 – No multithreading, the default.
• Positive integer less than 100 – ClaimCenter runs the
database integrity checks with the number of specified
threads.
The default is 1.
It is possible to override this attribute value at runtime by
using the following command prompt option:
table_import -numthreadsintegritychecking
See “Table Import Options” on page 430 for more
information.
row-counts-degree-of-parallelism (Oracle) Controls the degree of database parallelism that
Oracle uses for all row counts of the tables before the INSERT
SELECT operation:
• 1 – No database parallelism.
• Positive integer less than 1000 – Database parallelism,
with the specified value as the degree of parallelism.
The default is 1.

The <loader> element has the following subelements.

callback Specifies parameters related to database parallelism and overrides for individual callbacks. See “The callback
Database Configuration Element” on page 233 for details.
loader-table Specifies parameters related to overrides for individual tables. See “The loader-table Database Configuration
Element” on page 235 for details.

See also
• “The Database Configuration File” on page 220
• “Table Import Options” on page 430
• Installation Guide

The callback Database Configuration Element

The <loader> element in file database-config.xml contains any number of occurrences of subelement
<callback>. The use of a <callback> element is optional. The use of the <callback> element is specific to Oracle
databases. One important area of configuration is the degree of database parallelism to use in an Oracle database.
Database parallelism refers to the ability of an Oracle database to execute a database SQL statement such as CREATE
or INSERT using simultaneous, parallel slave processes.
The <callback> element has the following syntax.

The loader Database Configuration Element 233

 System Administration Guide 9.0.5

<database>
<loader>

<callback after-insert-select-callback-degree-of-parallelism="integer"
before-gen-ids-callback-degree-of-parallelism="integer"
before-insert-select-callback-degree-of-parallelism="integer"
insert-select-degree-of-parallelism="integer" name="string"/>

</loader>
</database>

The following list describes the attributes that you can configure on the <callback> element.

name Required. Name of callback to which these

attribute overrides apply.
The following attributes are all optional.
after-insert-select-callback-degree-of-parallelism (Oracle) Controls the degree of database
parallelism that Oracle uses for this named
callback after an INSERT SELECT operation on
staging data:
• 1 – No database parallelism.
• Positive integer less than 1000 – Database
parallelism, with the specified value as the
degree of parallelism.
before-gen-ids-callback-degree-of-parallelism (Oracle) Controls the degree of database
parallelism that Oracle uses for this named
callback before ID generation:
• 1 – No parallelism.
• Positive integer less than 1000 – Parallelism,
with the specified value as the degree of
parallelism.
before-insert-select-callback-degree-of-parallelism (Oracle) Controls the degree of database
parallelism that Oracle uses for this named
callback before an INSERT SELECT operation on
staging data:
• 1 – No database parallelism.
• Positive integer less than 1000– Database
parallelism, with the specified value as the
degree of parallelism.
insert-select-degree-of-parallelism (Oracle) Controls the degree of database
parallelism that Oracle uses for the INSERT SELE
CT operation itself:
• 1 – No database parallelism.
• Positive integer less than 1000 – Database
parallelism, with the specified value as the
degree of parallelism.

The <callback> element has no subelements.

234 chapter 15 Database Configuration

 System Administration Guide 9.0.5

See also
• “The Database Configuration File” on page 220
• “The loader Database Configuration Element” on page 231

The loader-table Database Configuration Element

The <loader> element in file database-config.xml can contain any number of occurrences of subelement
<loader-table>. The use of the <loader-table> element is optional. Use this element to specify table-specific
overrides. One important area of configuration is the degree of database parallelism to use in an Oracle database.
Database parallelism refers to the ability of an Oracle database to execute a database SQL statement such as CREATE
or INSERT using simultaneous, parallel slave processes.
The <loader-table> element has the following syntax. The following code sample shows required attributes in
bold font.

<database>

<loader>
<loader-table drop-deferrable-indexes="disable|enable|enable_all"
fk-enable-degree-of-parallelism="integer" name="string"
row-counts-degree-of-parallelism="integer"/>
<loader-index key-columns="string"/>
</loader-table>
</loader>

</database>

The following list describes the attributes that you can configure on the <loader-table> element.

name Required. Name of table to which these attribute overrides apply.

The following attributes are all optional.
drop-deferrable-indexes Specifies whether to drop performance-only indexes on a specific table. The value
of this attribute overrides the equivalent attribute set at the global database level.
Valid values are:
• disable – Do not drop performance-only indexes on this named table,
regardless of how configuration sets this behavior at the global, database level.
• enable – Drop only the index columns named in the <loader-index>
subelement. You must supply a <loader-index> element if you use this setting.
• enable_all – Drop all performance-only indexes on this named table.
The default is disable.
See “The loader Database Configuration Element” on page 231 for a discussion of
the equivalent attribute on the <loader> element. See the Installation Guide for a
discussion of how these two attributes interact.
fk-enable-degree-of-parallelism (Oracle) Controls the degree of database parallelism that Oracle uses for re-
enabling foreign key constraints on the named table after an INSERT SELECT
operation.
• 1 – No database parallelism.
• Positive integer less than 1000 – Database parallelism, with the specified value
as the degree of parallelism.
row-counts-degree-of-parallelism (Oracle) Controls the degree of database parallelism that Oracle uses for all row
counts of the named table before the INSERT SELECT operation:
• 1 – No database parallelism.
• Positive integer less than 1000 – Database parallelism, with the specified value
as the degree of parallelism.
The default is 1.

The loader Database Configuration Element 235

 System Administration Guide 9.0.5

The <loader-table> element has the following subelement. The <loader-table> element can contain any number
of occurrences of subelement <loader-index>.

loader-index If present, the <loader-index> element specifies the columns on the index to which the <loader-table>
overrides apply. This element has one required attribute, keycolumns. This attribute provides the index’s key
columns in an ordered, comma-separated list.

See also
• “The Database Configuration File” on page 220
• “The loader Database Configuration Element” on page 231
• Installation Guide

The oracle-settings Database Configuration Element

The <database> element in file database-config.xml contains, at most, a single occurrence of subelement
<oracle-settings>. The use of the <oracle-settings> element is optional. Use this element to configure Oracle-
only database parameters.
The <oracle-settings> element has the following syntax.

<database>

<oracle-settings adaptive-optimization="OFF|REPORTING_ONLY" db-resource-mgr-cancel-sql="string"

query-rewrite="true|false" statistics-level-all="true|false"
stored-outline-category="string"/>

</database>

The following list describes the attributes that you can configure on the <oracle-settings> element. All of these
attributes are optional.

adaptive-optimization Specifies the behavior of the Oracle Adaptive Optimization feature. Valid values are:
• OFF
• REPORTING_ONLY
db-resource-mgr-cancel-sql Name of an Oracle Resource Consumer Group, if any. Guidewire currently uses this attribute
with Claim Search only. The main purpose of this attribute is to cancel long running queries
during the search.
query-rewrite Boolean. Whether to enable query rewrite.
Valid values are:
• true – Enable query rewrite and use a matching materialized view.
• false – Set the Oracle query-rewrite parameter to false to disable use of Oracle
materialized views.
If not present, Guidewire does not set this value at the session level
statistics-level-all Boolean. Whether to set the Oracle statistics_level parameter to ALL and enable
collection of detailed execution plan statistics.
The default is false.
stored-outline-category Name of the stored outline category to use, if any

The <oracle-settings> element does not contain additional subelements.

236 chapter 15 Database Configuration

 System Administration Guide 9.0.5

See also
• “The Database Configuration File” on page 220

The sqlserver-settings Database Configuration Element

The <database> element in file database-config.xml contains, at most, a single occurrence of subelement
<sqlserver-settings>. The use of the <sqlserver-settings> element is optional. Use this element to configure
Microsoft JDBC driver logging.
The <sqlserver-settings> element has the following syntax.

<database>
...
<sqlserver-settings jdbc-trace-file="string" jdbc-trace-level="string"
unicodecolumns="true|false"/>
...
</database>

The following list describes the attributes that you can configure on the <sqlserver-settings> element. All of
these attributes are optional.

jdbc-trace-file Specifies the name of the trace file. If you do not provide a file name, this value defaults to the
following:
C:\temp\msjdbctrace%u.log
ClaimCenter replaces the symbols in the file name at runtime with their meaning as listed at the
following web site.
http://java.sun.com/j2se/1.5.0/docs/api/java/util/logging/FileHandler.html
Use the listed symbols to uniquely name the trace file.
jdbc-trace-level Valid trace level as listed at the following web site:
http://msdn.microsoft.com/en-us/library/ms378517(SQL.90).aspx?ppud=4

unicodecolumns Required if starting a new database that exclusively uses Unicode-capable column character data
types (nvarchar, …). ClaimCenter ignores this attribute if the database does not support Unicode or
if the attribute is not relevant to the new database. The default is false.

The <sqlserver-settings> element does not contain additional subelements.

See also
• “The Database Configuration File” on page 220
• Installation Guide

The upgrade Database Configuration Element

The <database> element in file database-config.xml contains, at most, a single occurrence of subelement
<upgrade>. The use of the <upgrade> element is optional. This element specifies various options related to database
upgrade. One important area of configuration is the degree of database parallelism to use in an Oracle database.
Database parallelism refers to the ability of an Oracle database to execute a database SQL statement such as CREATE
or INSERT using simultaneous, parallel slave processes.
The <upgrade> element has the following syntax. The following code sample shows required attributes in bold font.

<database>
<upgrade>

<mssql-db-ddl>

<!-- Sets SQL Server database options at the global, database level -->

The sqlserver-settings Database Configuration Element 237

 System Administration Guide 9.0.5

<mssql-compression index-compression="NONE|PAGE|ROW" table-compression="NONE|PAGE|ROW/>

<mssql-filegroups admin="string" index="string" lob="string" op="string" staging="string"
typelist="string"/>

<!-- Set SQL Server options for the named table, overrides values set at database level -->
<mssql-table-ddl table-name="string">
<mssql-index-ddl filter-where="string"index-compression="NONE|PAGE|ROW"
index-filegroup="string" key-columns="string" partition-scheme="string"/>
<mssql-table-compression index-compression="NONE|PAGE|ROW" table-compression="NONE|PAGE|ROW"/>
<mssql-table-filegroups="string" index-filegroup="string" lob-filegroup
table-filegroup="string"/>
</mssql-table-ddl>

</mssql-db-ddl>

<ora-db-ddl>

<!-- Sets Oracle database options at the global, database level -->
<ora-compression index-compression="true|false" table-compression="ADVANCED|BASIC|NONE"/>
<ora-lobs caching="true|false" type="BASIC|SECURE|SECURE_COMPRESSED/>
<tablespaces admin="string" index="string" lob="string" op="string" staging="string"
typelist="string"/>

<!-- Sets Oracle options for the named table, overrides values set at the database level -->
<ora-table-ddl table-name="string">
<ora-index-ddl index-compression="true|false" index-tablespace="string" key-columns="string"/>
<ora-lobs caching="true|false" type="BASIC|SECURE|SECURE_COMPRESSED/>>
<ora-table-compression index-compression="true|false" table-compression="ADVANCED|BASIC|NONE">
<ora-table-date-interval-partitioning datecolumn="string"
interval="DAILY|MONTHLY|QUARTERLY|WEEKLY|YEARLY">
<ora-table-hash-partitioning hash-columns="string" num-partitions="integer"/>
<ora-table-tablespaces index-tablespace="string" lob-tablespace="string"
table-tablespace="string"/>
</ora-table-ddl>

</ora-db-ddl>

<versiontriggers dbmsperfinfothreshold="integer">
<!-- Sets override options for the named database version trigger -->
<versiontrigger extendedquerytracingenabled="true|false" name="string"
parallel-dml="true|false" parallel-query="true|false"
queryoptimizertracingenabled="true|false" recordcounters="true|false"
updatejoinorderedhint="true|false" updatejoinusemergehint="true|false"
updatejoinusenlhint="true|false"/>
</versiontriggers>

</upgrade>
</database>

The following list describes the attributes that you can configure on the <upgrade> element. All of these attributes
are optional.

allowUnloggedOperations Boolean. Whether to disable logging of certain SQL operations during the database
upgrade.
Valid values are:
• true – Run the upgrade with minimal database redo logging and enable direct-
path INSERT operations.
• false – Run the upgrade with standard database redo logging.
The default is false.
Note: If you run the upgrade with attribute allowUnloggedOperations set to true,
then you need to take a full database backup after the upgrade.
collectstorageinstrumentation (Oracle) Boolean. Whether ClaimCenter collects tablespace usage and object size
data before and after the upgrade.
Valid values are:
• true – ClaimCenter collects tablespace usage and size of segments such as
tables, indexes and LOBs (large object binaries) before and after the upgrade.

238 chapter 15 Database Configuration

 System Administration Guide 9.0.5

You can then compare the before and after values to find the utilization change
caused by the upgrade.
• false – ClaimCenter does not collect this data.
The default is false.
defer-create-nonessential-indexes Boolean. Whether to defer creation of non-essential indexes during the upgrade
process until the upgrade completes and the application server is back up. Creation
of non-essential indexes can add significant time to the upgrade duration.
Valid values are:
• true – Defer creation of non-essential indexes during upgrade.
• false – Do not defer creation of non-essential indexes during upgrade.
The default is false.
Non-essential indexes are:
• Performance-related indexes that do not enforce constraints.
• Indexes on the ArchivePartition column on all entities that ClaimCenter can
archive.
If you choose to defer creation of non-essential indexes, ClaimCenter runs the
Deferred Upgrade Tasks batch process (DeferredUpgradeTasks) as soon as the
upgrade completes and the server starts up. See “Deferred Upgrade Tasks Batch
Processing” on page 115 for more information.
deferDropColumns (Oracle) Boolean. Whether to drop table columns removed during upgrade
immediately or leave their removal to a later time. The database upgrade removes
some columns. For Oracle, you can configure whether the removed columns are
dropped immediately or are marked as unused. Marking a column as unused is a
faster operation than dropping the column immediately.
However, as ClaimCenter does not physically drop the removed columns from the
database, the space used by these columns is not released immediately to the table
and index segments.
Valid values are:
• true – Defer dropping removed columns until after the upgrade, possibly during
off-peak hours of operation. The ClaimCenter database upgrade marks the
removed columns as unused instead.
• false – Drop the removed columns immediately, during the upgrade process.
The default is true.
degree-of-parallelism (Oracle) Controls the degree of database parallelism that Oracle uses for INSERT, UP
DATE, and DELETE database operations.
Valid values are:
• 0 – Defers to Oracle to determine the degree of database parallelism for the
operations that the attribute configures. The Oracle automatic parallel tuning
feature determines the degree based on the number of CPU processors involved
and the value set for the Oracle parameter PARALLEL_THREADS_PER_CPU.
• 1 – Disables the parallel execution of DDL statements.
• Positive integer less than 1000 – Database parallelism, with the specified value
as the degree of parallelism.
The default is 4.
degree-parallel-ddl (Oracle) Controls the degree of database parallelism that Oracle uses to execute
DDL (Data Definition Language) statements during the database upgrade. Use to
configure the degree of database parallelism for commands such as CREATE INDEX
and the ALTER TABLE commands.
Valid values are:
• 0 – Defers to Oracle to determine to determine the degree of database
parallelism for the operations that the attribute configures. The Oracle
automatic parallel tuning feature determines the degree based on the number

The upgrade Database Configuration Element 239

 System Administration Guide 9.0.5

of CPUs involved and the value set for the Oracle parameter PARALLEL_THREADS
_PER_CPU.
• 1 – Disables the parallel execution of DDL statements.
• Positive integer less than 1000 – Database parallelism, with the specified value
as the degree of parallelism.
The default is 4.
If you set the value of ora-parallel-dml to enable or enable_all (default), then
you need to provide a value for attribute degree-of-parallelism as well.
encryptioncommitsize Sets the commit size for rows requiring encryption. If one or more attributes use
ClaimCenter encryption, the ClaimCenter database upgrade commits batches of
encrypted values. The upgrade commits encryptioncommitsize rows at a time in
each batch.
The default value of encryptioncommitsize varies based on the database type:
• Oracle – 10000
• SQL Server – 100
Test the upgrade on a copy of your production database before attempting to
upgrade the actual production database. If the encryption process is slow, and you
cannot attribute the slowness to SQL statements in the database, try adjusting the
encryptioncommitsize attribute. After you optimized the performance of the
encryption process, use that value of encryptioncommitsize as you upgrade your
production database.
ora-parallel-dml (Oracle) Controls database parallelism usage by Oracle in the execution of DML
(Data Manipulation Language) operations.
Valid values are:
• disable – Oracle does not execute DML statements in parallel during upgrade.
• enable – Oracle executes DML statements in parallel during upgrade, if
configured to do so.
• enable_all – Oracle executes DML statements in parallel during upgrade in all
cases, unless turned off in the code or through configuration.
The default is enable_all.
If you set the value of ora-parallel-dml to enable or enable_all, then you need
to provide a value for attribute degree-of-parallelism as well.
Note: The value of this attribute interacts with the parallel-dml attribute on the <
versiontrigger> element. See “The versiontrigger Database Configuration
Element” on page 255 for more information.
ora-parallel-query (Oracle) Controls parallel query usage by Oracle during a database upgrade.
Valid values are:
• disable – Oracle does not use parallel queries during upgrade.
• enable – Oracle uses parallel queries during upgrade, if configured to do so.
The default is enable.
The value of this attribute interacts with the parallel-query attribute on the <ver
siontrigger> element. See “The versiontrigger Database Configuration Element”
on page 255 for more information.
sqlserverCreateIndexSortInTempDB (SQL Server) Boolean. Whether SQL Server stores temporary sort results in tempdb.
By using tempdb for sort runs, disk input and output is typically faster, and the
created indexes tend to be more contiguous. Valid values are:
• true – SQL Server stores sort results in tempdb.
• false – SQL Server stores sort results in the destination filegroup.
The default is false.
If you set sqlserverCreateIndexSortInTempDB to true, you must have enough
disk space available to tempdb for the sort runs, which, for the clustered index,
includes the data pages. You must also have sufficient free space in the destination

240 chapter 15 Database Configuration

 System Administration Guide 9.0.5

filegroup to store the final index structure, because SQL Server creates the new
index before deleting the old index.
Refer to the following web site for details on the requirements to use tempdb for
sort results.
http://msdn.microsoft.com/en-us/library/ms188281.aspx

updatestatistics (Oracle) Boolean. Whether to update table statistics during upgrade. The overall
time that it takes to upgrade the database is shorter if the database upgrade does
not update statistics.
Valid values are:
• true – Enables the upgrader to update statistics on changed objects. It also
allows the upgrader to maintain column level statistics consistent with what is
allowed in the code, data model, and configuration.
• false – Disable statistics generation during the upgrade.
If ClaimCenter does not update statistics during the upgrade:
• It reports a warning that recommends that you run the database statistics batch
process (DBStats) in incremental mode during the next maintenance window.
• It updates the Server Tools Upgrade and Versions screen to show that the upgrade
did not update statistics.
If ClaimCenter does generate statistics during the upgrade, it updates the Upgrade
and Versions screen to report the runs of the statistics batch process, including
incremental runs.
Note: Guidewire recommends that you run statistics in full mode after an upgrade
to a major ClaimCenter version.
See the following for more information:
• “Database Statistics Batch Processing” on page 114
• “Configuring Database Statistics Generation” on page 284
• “Upgrade and Versions” on page 393
verifyschema Boolean. Whether ClaimCenter performs a verification of the database schema
before starting the database upgrade. This process verifies that the ClaimCenter
data model matches the physical database. This process can take some time. The
default is true.
It is possible for the verification process to take some time. Guidewire recommends
that you perform this verification prior to starting the upgrade through the use of
the system_tools -verifydbschema command option. To use the command,
enter the following at a command prompt:
system_tools -password password -verifydbschema
See “System Tools Command” on page 422 for more information.

The <upgrade> element has the following subelements. Each of these elements is optional. There is, at most, a
single occurrence of each of these subelements on the <upgrade> element.

mssql-db-ddl Specifies options for SQL Server database DDL (Data Definition Language) statements. See “The mssql-db-
ddl Database Configuration Element” on page 242 for details.
ora-db-ddl Specifies options for Oracle database DDL (Data Definition Language) statements. See “The ora-db-ddl
Database Configuration Element” on page 247 for details.
versiontriggers Specifies options for named version triggers. See “The versiontriggers Database Configuration Element” on
page 254 for details.

The upgrade Database Configuration Element 241

 System Administration Guide 9.0.5

See also
• “The Database Configuration File” on page 220

The mssql-db-ddl Database Configuration Element

The <upgrade> element in file database-config.xml contains, at most, a single occurrence of subelement <mssql-
db-ddl>. The use of the <mssql-db-ddl> element is optional. Use this element to set SQL Server database DDL
(Data Definition Language) options during the creation of new objects in the database. This configuration applies to
the database at a global level.
The <mssql-db-ddl> element has the following syntax. The following code sample shows required attributes in
bold font.

<database>
<upgrade>

<mssql-db-ddl>
<mssql-compression index-compression="NONE|PAGE|ROW" table-compression="NONE|PAGE|ROW/>
<mssql-filegroups op="string" admin="string" typelist="string" staging="string"
index="string" lob="string"/>
<mssql-table-ddl table-name="string">
<mssql-index-ddl filter-where="string"index-compression="NONE|PAGE|ROW"
index-filegroup="string" key-columns="string" partition-scheme="string"/>
<mssql-table-compression index-compression="NONE|PAGE|ROW" table-compression="NONE|PAGE|ROW"/>
<mssql-table-filegroups="string" index-filegroup="string" lob-filegroup
table-filegroup="string"/>
</mssql-table-ddl>
</mssql-db-ddl>
</upgrade>
</database>

There are no specific attributes on the <mssql-db-ddl> element.

The <mssql-db-ddl> element has the following subelements. Each of these elements is optional. There is, at most, a
single occurrence of the <mssql-compression> and <mssql-filegroups> elements on the <mssql-db-ddl>
element. There can be, however, multiple occurrences of the <mssql-table-ddl> element.

mssql-compression Specifies compression settings for SQL Server database tables and indexes at the global, database level.
See “The mssql-compression Database Configuration Element” on page 242 for more information.
mssql-filegroups Specifies the mapping between SQL Server database filegroups and ClaimCenter logical tablespaces at
the global, database level. See “The mssql-filegroups Database Configuration Element” on page 243 for
more information.
mssql-table-ddl Specifies SQL Server database DDL options for a named table. These settings override values set at the
global, database level. See “The mssql-table-ddl Database Configuration Element” on page 244 for
more information.

See also
• “The Database Configuration File” on page 220
• “The upgrade Database Configuration Element” on page 237
• Installation Guide

The mssql-compression Database Configuration Element

The <mssql-db-ddl> element in file database-config.xml contains, at most, a single occurrence of subelement
<mssql-compression>. The use of the <mssql-compression> element is optional. Use this element to set SQL
Server database compression options at the global, database level. See also the Installation Guide.
The <mssql-compression> element has the following syntax.

242 chapter 15 Database Configuration

 System Administration Guide 9.0.5

<database>
<upgrade>
<mssql-db-ddl>
<mssql-compression index-compression="NONE|PAGE|ROW" table-compression="NONE|PAGE|ROW/>
</mssql-db-ddl>
</upgrade>
</database>

The following list describes the attributes that you can configure on the <mssql-compression> element.

index-compression If present, specifies the index compression setting for all indexes. Valid values are:
• NONE
• PAGE
• ROW
The default is NONE.
table-compression If present, specifies the table compression setting for all tables. Valid values are:
• NONE
• PAGE
• ROW
The default is NONE.

The <mssql-compression> element does not contain additional subelements.

See also
• “The Database Configuration File” on page 220
• “The upgrade Database Configuration Element” on page 237

The mssql-filegroups Database Configuration Element

The <mssql-db-ddl> element in file database-config.xml contains, at most, a single occurrence of subelement
<mssql-filegroups>. The use of the <mssql-filegroups> element is optional. Use this attributes to map SQL
Server filegroups to ClaimCenter logical tablespaces at the global, database level.
The use of these configuration elements applies to newly created objects only. If you map a specific table to a named
filegroup, SQL Server implements the change during table creation or table recreation only. Similarly, if you specify
a LOB filegroup for a table or all tables, only newly created tables have their LOB columns stored in the named
filegroup. The database does not store newly created LOB columns for existing tables in the named filegroup.
Note: The ClaimCenter schema verification process during server startup reports as warnings any database tables
or LOB columns that are not located in a configured filegroup. However, some of the warnings are unavoidable
due to the nature of the implementation mechanism and are purely informational.
The <mssql-filegroups> element has the following syntax. The following code sample shows required attributes
in bold font.

<database>
<upgrade>
<mssql-db-ddl>
<mssql-filegroups op="string" admin="string" typelist="string" staging="string"
index="string" lob="string"/>
</mssql-db-ddl>
</upgrade>
</database>

The following list describes the attributes that you can configure on the <mssql-filegroups> element.

op Required. Name of a SQL Server filegroup.

admin Required. Name of a SQL Server filegroup.

The mssql-db-ddl Database Configuration Element 243

 System Administration Guide 9.0.5

typelist Required. Name of a SQL Server filegroup.

staging Required. Name of a SQL Server filegroup.

index Required. Name of a SQL Server filegroup.
lob Name of a SQL Server filegroup.

The <mssql-filegroups> element does not contain additional subelements.

See also
• “The Database Configuration File” on page 220
• “The upgrade Database Configuration Element” on page 237
• Installation Guide

The mssql-table-ddl Database Configuration Element

The <mssql-db-ddl> element in file database-config.xml can contain any number of occurrences of subelement
<mssql-table-ddl>. The use of the <mssql-table-ddl> element is optional. Use this element to specify DDL
(Data Definition Language) options for a specific, named SQL Server database table.
The <mssql-table-ddl> element has the following syntax. The following code sample shows required attributes in
bold font.

<database>
<upgrade>
<mssql-db-ddl>
<mssql-table-ddl table-name="string">
<mssql-index-ddl filter-where="string"index-compression="NONE|PAGE|ROW"
index-filegroup="string" key-columns="string" partition-scheme="string"/>
<mssql-table-compression index-compression="NONE|PAGE|ROW" table-compression="NONE|PAGE|ROW"/>
<mssql-table-filegroups lob-filegroups="string" index-filegroup="string" table-filegroup="string"/>
</mssql-table-ddl>
</mssql-db-ddl>
</upgrade>
</database>

The <mssql-table-ddl> element has the following attribute.

table-name Required. Name of the table to which these overrides apply.

The <mssql-table-ddl> element has the following subelements. Each of these elements is optional. There is, at
most, a single occurrence of the <mssql-table-compression> and <mssql-table-filegroups> elements on the
<mssql-table-ddl> element. There can be, however, multiple occurrences of the <mssql-index-ddl> element.

mssql-index-ddl Specifies DDL options for a specific index. See “The mssql-index-ddl Database Configuration
Element” on page 245 for more information.
mssql-table-compression Specifies compression for the named table. See “The mssql-table-compression Database
Configuration Element” on page 245 for more information.
mssql-table-filegroups Specifies a filegroup to associate with a table, index, or LOB. See “The mssql-table-filegroups
Database Configuration Element” on page 246 for more information.

244 chapter 15 Database Configuration

 System Administration Guide 9.0.5

See also
• “The Database Configuration File” on page 220
• “The upgrade Database Configuration Element” on page 237

The mssql-index-ddl Database Configuration Element

The <mssql-table-ddl> element in file database-config.xml can contain any number of occurrences of
subelement <mssql-index-ddl>. The use of the <mssql-index-ddl> element is optional. Use this element to
define SQL Server database DDL options for a specific index, based on the key columns. Any value that you set at
this level overrides that same value set at the global, database level. You can create multiple <mssql-index-ddl>
elements on the parent <mssql-table-ddl> element, each of which affects a different index.
The <mssql-index-ddl> element has the following syntax. The following code sample shows required attributes in
bold font.

<database>
<upgrade>
<mssql-db-ddl>
<mssql-table-ddl table-name="string">
<mssql-index-ddl filter-where="string"index-compression="NONE|PAGE|ROW"
index-filegroup="string"
key-columns="string" partition-scheme="string"/>
</mssql-table-ddl>
</mssql-db-ddl>
</upgrade>
</database>

The following list describes the attributes that you can configure on the <mssql-index-ddl> element.

key-columns Required. Comma-delimited list of key columns, in order. Specify DESC after the column name for a
descending sort order on the column.
The following attributes are all optional.
filter-where Specifies an index filter to add after the WHERE keyword in the SQL Server CREATE INDEX ... WHERE
statement. The filter that you create must conform to standard SQL Server rules.
index-compression Specifies the compression setting for the specified index. Valid values are:
• NONE
• PAGE
• ROW
If not specified, ClaimCenter uses the SQL Server database default.
index-filegroup Name of the filegroup associated with this index. Do not use this attribute if you supply a value for the p
artition-scheme attribute as the two attributes are mutually exclusive.

partition-scheme Name of a partition scheme for this index. Use of this attribute implies the use of ClaimCenter
clustering. Do not use this attribute if you supply a value for the index-filegroups attribute as the two
attributes are mutually exclusive.

The <mssql-index-ddl> element does not contain additional subelements.

See also
• Installation Guide

The mssql-table-compression Database Configuration Element

The <mssql-table-ddl> element in file database-config.xml contains, at most, a single occurrence of
subelement <mssql-table-compression>. The use of the <mssql-table-compression> element is optional. Any
value that you set at this level overrides that same value set at the global, database level. See also the Installation
Guide.
The mssql-db-ddl Database Configuration Element 245
 System Administration Guide 9.0.5

The <mssql-table-compression> element has the following syntax. The following code sample shows required
attributes in bold font.

<database>
<upgrade>
<mssql-db-ddl>
<mssql-table-ddl table-name="string">
<mssql-table-compression index-compression="NONE|PAGE|ROW" table-compression="NONE|PAGE|ROW"/>
</mssql-table-ddl>
</mssql-db-ddl>
</upgrade>
</database>

The following list describes the attributes that you can configure on the <mssql-table-compression> element. All
of these attributes are optional.

index-compression Specifies the index compression setting for the specified index. Valid values are:
• NONE
• PAGE
• ROW
If not specified, ClaimCenter uses the database default.
table-compression Specifies the table compression setting for the specified table. Valid values are:
• NONE
• PAGE
• ROW
If not specified, ClaimCenter uses the database default.

The <mssql-table-ddl> element does not contain additional subelements.

The mssql-table-filegroups Database Configuration Element

The <mssql-table-ddl> element in file database-config.xml contains, at most, a single occurrence of
subelement <mssql-table-filegroups>. The use of the <mssql-table-groups> element is optional. Use this
element to associate a filegroup with a table, index, or LOB. Any value that you set at this level overrides that same
value set at the global, database level.
The <mssql-table-filegroups> element has the following syntax. The following code sample shows required
attributes in bold font.

<database>
<upgrade>
<mssql-db-ddl>
<mssql-table-ddl table-name="string">
<mssql-table-filegroups table-filegroup="string" index-filegroup="string" lob-filegroups="string"/>
</mssql-table-ddl>
</mssql-db-ddl>
</upgrade>
</database>

The following list describes the attributes that you can configure on the <mssql-table-filegroups> element. All
of these attributes are optional. However, if you do not specify at least one of these attributes, there is no need for
this element to be present in database-config.xml.

table-filegroup Name of the filegroup to associate with this table.

index-filegroup Name of the filegroup to associate with any indexes on this table.

lob-filegroup Name of the filegroup to associate with any large object (LOB, CLOB, or spatial column).

246 chapter 15 Database Configuration

 System Administration Guide 9.0.5

The <mssql-table-filegroups> element does not contain additional subelements.

The ora-db-ddl Database Configuration Element

The <upgrade> element in file database-config.xml contains, at most, a single occurrence of subelement <ora-
db-ddl>. The use of the <ora-db-ddl> element is optional. Use this element to set Oracle database DDL (Data
Definition Language) options during the creation of new objects in the database. This configuration applies to the
database at a global level.
The <ora-db-ddl> element has the following syntax. The following code sample shows required attributes in bold
font.

<database>
<upgrade
<ora-db-ddl>

<!-- Sets Oracle database options at the global, database level -->
<ora-compression index-compression="true|false" table-compression="ADVANCED|BASIC|NONE"/>
<ora-lobs caching="true|false" type="BASIC|SECURE|SECURE_COMPRESSED/>
<tablespaces admin="string" index="string" lob="string" op="string" staging="string"
typelist="string"/>

<!-- Sets Oracle options for the named table, overrides values set at the database level -->
<ora-table-ddl table-name="string">
<ora-index-ddl index-compression="true|false" index-tablespace="string" key-columns="string"/>
<ora-lobs caching="true|false" type="BASIC|SECURE|SECURE_COMPRESSED/>>
<ora-table-compression index-compression="true|false" table-compression="ADVANCED|BASIC|NONE">
<ora-table-date-interval-partitioning datecolumn="string"
interval="DAILY|MONTHLY|QUARTERLY|WEEKLY|YEARLY">
<ora-table-hash-partitioning hash-columns="string" num-partitions="integer"/>
<ora-table-tablespaces index-tablespace="string" lob-tablespace="string"
table-tablespace="string"/>
</ora-table-ddl>

</ora-db-ddl>
</upgrade>
</database>

There are no specific attributes on the <ora-db-ddl> element.

The subelements on the <ora-db-ddl> element have the following meanings.

ora-compression Specifies Oracle compression settings for all tables and indexes at the global, database level. See “The ora-
compression Database Configuration Element” on page 248 for more information.
ora-lobs Specifies attributes for LOB columns on all tables at the global, database level. See “The ora-lobs Database
Configuration Element” on page 248 for more information.
ora-table-ddl Specifies DDL parameters and overrides for a specific, named Oracle database table. See “The ora-table-
ddl Database Configuration Element” on page 250 for more information.
tablespaces Specifies default mappings for Oracle tablespaces at a global, database level. See “The tablespaces
Database Configuration Element” on page 249 for more information.

See also
• “The Database Configuration File” on page 220
• “The upgrade Database Configuration Element” on page 237
• Installation Guide

The upgrade Database Configuration Element 247

 System Administration Guide 9.0.5

The ora-compression Database Configuration Element

The <ora-db-ddl> element in file database-config.xml contains, at most, a single occurrence of subelement
<ora-compression>. The use of the <ora-compression> element is optional. Use this element to set compression
on Oracle database indexes and tables at a global, database level.
The <ora-compression> element has the following syntax.

<database>
<upgrade>
<ora-db-ddl>
<ora-compression index-compression="true|false" table-compression="ADVANCED|BASIC|NONE"/>
</ora-db-ddl>
</upgrade>
</database>

The following list describes the attributes that you can configure on the <ora-compression> element. All of these
attributes are optional.

index-compression Boolean. Whether to use index compression for all indexes in an Oracle database. The default is false.

table-compression Specifies table compression type for all tables in an Oracle database.
Valid values are:
• ADVANCED
• BASIC
• NONE
The default is NONE.

The <ora-compression> element does not contain additional subelements.

See also
• “The Database Configuration File” on page 220
• “The upgrade Database Configuration Element” on page 237
• Installation Guide

The ora-lobs Database Configuration Element

The <ora-db-ddl> element in file database-config.xml contains, at most, a single occurrence of subelement
<ora-lobs>. The use of the <ora-lobs> element is optional. Use this element to set options for LOB columns on
tables in an Oracle database at a global, database level.
The <ora-lobs> element has the following syntax.

<database>
<upgrade>
<ora-db-ddl>
<ora-lobs caching="true|false" type="BASIC|SECURE|SECURE_COMPRESSED/>
</ora-db-ddl>
</upgrade>
</database>

The following list describes the attributes that you can configure on the <ora-lobs> element. All of these attributes
are optional.

caching Boolean. Whether to use caching for all LOB columns on a table or for the Oracle database globally. The default is fa
lse.

type Sets LOB type globally for the database.

248 chapter 15 Database Configuration

 System Administration Guide 9.0.5

Valid values are:

• BASIC
• SECURE
• SECURE_COMPRESSED
The default is SECURE.
Note: SECURE and SECURE_COMPRESSED refer to the use of Oracle SecureFiles LOBs.

The <ora-lobs> element does not contain additional subelements.

See also
• “The Database Configuration File” on page 220
• “The upgrade Database Configuration Element” on page 237

The tablespaces Database Configuration Element

The <ora-db-ddl> element in file database-config.xml contains a single occurrence of subelement
<tablespaces>. You must provide a <ora-tablespaces> subelement if using the <ora-db-ddl> element. Use this
element to map Oracle tablespaces to ClaimCenter logical tablespaces at a global, database level.
The <tablespaces> element has the following syntax. The following code sample shows required attributes in bold
font.

<database>
<upgrade>
<ora-db-ddl>
<tablespaces admin="string" index="string" lob="string" op="string" staging="string"
typelist="string"/>
</ora-db-ddl>
</upgrade>
</database>

The following list describes the attributes that you can configure on the <tablespaces> element.

The following attributes are all required.

admin Name of a ClaimCenter logical tablespace.
index Name of a ClaimCenter logical tablespace.
op Name of a ClaimCenter logical tablespace.
staging Name of a ClaimCenter logical tablespace.
typelist Name of a ClaimCenter logical tablespace.

The following attribute is optional.

lob Name of a ClaimCenter logical tablespace.

The <tablespaces> element does not contain additional subelements.

See also
• “The Database Configuration File” on page 220
• “The upgrade Database Configuration Element” on page 237
• Installation Guide

The ora-db-ddl Database Configuration Element 249

 System Administration Guide 9.0.5

The ora-table-ddl Database Configuration Element

The <ora-db-ddl> element in file database-config.xml can contain any number of occurrences of subelement
<ora-table-ddl>. The use of the <ora-table-ddl> element is optional. Use this element to set DDL parameters
and overrides for a specific, named table in an Oracle database.
The <ora-table-ddl> element has the following syntax. The following code sample shows required attributes in
bold font.

<database>
<upgrade>
<ora-db-ddl>
<ora-table-ddl table-name="string">
<ora-index-ddl index-compression="true|false" index-tablespace="string" key-columns="string"/>
<ora-lobs caching="true|false" type="BASIC|SECURE|SECURE_COMPRESSED/>>
<ora-table-compression index-compression="true|false" table-compression="ADVANCED|BASIC|NONE">
<ora-table-date-interval-partitioning datecolumn="string"
interval="DAILY|MONTHLY|QUARTERLY|WEEKLY|YEARLY">
<ora-table-hash-partitioning hash-columns="string" num-partitions="integer"/>
<ora-table-tablespaces index-tablespace="string" lob-tablespace="string"
table-tablespace="string"/>
</ora-table-ddl>
</ora-db-ddl>
</upgrade>
</database>

The <ora-table-ddl> element has the following attribute.

table-name Required. Name of the table to which these overrides apply.

The subelements on the <ora-table-ddl> element have the following meanings.

ora-index-ddl Specifies options for a specific Oracle index, based on key columns. See “The ora-
index-ddl Database Configuration Element” on page 251 for more information.
ora-lobs Specifies options for LOB columns on a specific, named table in an Oracle
database. See “The ora-lobs Database Configuration Element” on page 252 for
more information.
ora-table-compression Specifies compression options on a specific, named index or table in an Oracle
database. See “The ora-table-compression Database Configuration Element” on
page 252 for more information.
ora-table-date-interval-partitioning Specifies options for date range partitioning on a specific, named table in an
Oracle database. See “The ora-table-date-interval-partitioning Database
Configuration Element” on page 253 for more information.
ora-table-hash-partitioning Specifies options for hash partitioning of a specific, named table in an Oracle
database. See “The ora-table-hash-partitioning Database Configuration Element”
on page 253 for more information.
ora-table-tablespaces Specifies tablespace options for a specific, named table in an Oracle database.
See “The ora-table-tablespaces Database Configuration Element” on page 254
for more information.

250 chapter 15 Database Configuration

 System Administration Guide 9.0.5

See also
• “The Database Configuration File” on page 220
• “The upgrade Database Configuration Element” on page 237

The ora-index-ddl Database Configuration Element

The <ora-table-ddl> element in file database-config.xml can contain any number of occurrences of subelement
<ora-index-ddl>. The use of the <ora-index-ddl> element is optional. Use this element to set DDL parameters
and overrides for a specific Oracle index, based on key columns. See also the Installation Guide.
The <ora-index-ddl> element has the following syntax. The following code sample shows required attributes in
bold font.

<database>
<upgrade>
<ora-db-ddl>
<ora-table-ddl table-name="string">
<ora-index-ddl index-compression="true|false" index-tablespace="string" key-columns="string"/>
</ora-table-ddl>
</ora-db-ddl>
</upgrade>
</database>

The following list describes the attributes that you can configure on the <ora-index-ddl> element.

key-columns Required. Ordered, comma-delimited list of key columns. Specify DESC after the column name for a
descending sort order on that column.
The following attributes are optional.
index-compression Specifies the index compression for this index. If you do not specify this attribute, ClaimCenter uses the
table or database default.
index-tablespaces Name of the tablespace override for the index.

The subelements on the <ora-index-ddl> element have the following meanings.

ora-index-partitioning Defines partitioning for the specified Oracle index. The <ora-index-partitioning>
element has the following attributes:
• num-hash-partitions – The number of hash partitions to define. The default is 128.
• partitioning-type – Required if using this element. Sets the partitioning type to one
of the following:
◦ LOCAL – Inherit the partitioning type from the table
◦ HASH – Use hash partitions. If you set this attribute to HASH, then you need to specify
the number of partitions to use attribute num-hash-partitions. Do not set partiti
oning-type to HASH if you specify an <ora-index-range-partition> subelement.
◦ RANGE – Specify the range partitioning column list and the partition upper limits with
one or more ora-index-range-partition elements.
• range-partitioning-column-list – Optional. Use to specify the global range
partitioning column list. This attribute requires the definition of one or more ora-index
-range-partitioning elements. Do not specify the last range which is always VALUES
LESS THAN (MAXVALUE). Do not use if you set attribute partitioning-type to HASH.
The <ora-index-partitioning> element contains a single subelement:
• ora-index-range-partition – Optional. A comma-delimited, ordered list of literal
values corresponding to the column list in the range-partitioning-column-list
attribute. Use single quotes with string values. ClaimCenter uses this value in the clause
VALUES LESS THAN(value_list). Do not use if you set attribute partitioning-type
to HASH.

The ora-db-ddl Database Configuration Element 251

 System Administration Guide 9.0.5

See also
• Installation Guide

The ora-lobs Database Configuration Element

The <ora-table-ddl> element in file database-config.xml contains, at most, a single occurrence of subelement
<ora-lobs>. The use of the <ora-lobs> element is optional. Use this element to set attributes for LOB columns on
a specific, named table in an Oracle database. Any value that you set at this level overrides that same value set at the
global, database level.
The <ora-lobs> element has the following syntax. The following code sample shows required attributes in bold
font.

<database>
<upgrade>
<ora-db-ddl>
<ora-table-ddl table-name="string">
<ora-lobs caching="true|false" type="BASIC|SECURE|SECURE_COMPRESSED/>>
</ora-table-ddl>
</ora-db-ddl>
</upgrade>
</database>

The following list describes the attributes that you can configure on the <ora-lobs> element. All of these attributes
are optional.

caching Sets the LOB cache attribute for the named Oracle table. The default is false.

type Sets the LOB type for the named Oracle table. Valid values are:
• BASIC
• SECURE
• SECURE_COMPRESSED
The default is SECURE.
Note: SECURE and SECURE_COMPRESSED refer to the use of Oracle SecureFiles LOBs.

The <ora-lobs> element does not contain additional subelements.

The ora-table-compression Database Configuration Element

The <ora-table-ddl> element in file database-config.xml contains, at most, a single occurrence of subelement
<ora-table-compression>. The use of the <ora-table-compression> element is optional. Use this element to set
compression on a specific, named index or table in an Oracle database. Any value that you set at this level overrides
that same value set at the global, database level. See also the Installation Guide.
The <ora-table-compression> element has the following syntax. The following code sample shows required
attributes in bold font.

<database>
<upgrade>
<ora-db-ddl>
<ora-table-ddl table-name="string">
<ora-table-compression index-compression="true|false" table-compression="ADVANCED|BASIC|NONE">
</ora-table-ddl>
</ora-db-ddl>
</upgrade>
</database>

The following list describes the attributes that you can configure on the <ora-table-compression> element. All of
these attributes are optional.

252 chapter 15 Database Configuration

 System Administration Guide 9.0.5

index-compression Boolean. Whether to use index compression. Valid values are:

• true – Use compression for all indexes on this table.
• false – Do not use compression for the indexes on this table.
If you do not specify this attribute, ClaimCenter uses the database default.
table-compression Specifies table compression for this table. Valid values are:
• ADVANCED
• BASIC
• NONE
If you do not specify this attribute, ClaimCenter uses the database default.

The <ora-table-compression> element does not contain additional subelements.

The ora-table-date-interval-partitioning Database Configuration Element

The <ora-table-ddl> element in file database-config.xml contains, at most, a single occurrence of subelement
<ora-table-date-interval-partitioning>. The use of the <ora-table-date-interval-partitioning>
element is optional. Use to add date range partitioning to a specific, named table in an Oracle database.
The <ora-table-date-interval-partitioning> element has the following syntax. The following code sample
shows required attributes in bold font.

<database>
<upgrade>
<ora-db-ddl>
<ora-table-ddl table-name="string">
<ora-table-date-interval-partitioning datecolumn="string"
interval="DAILY|MONTHLY|QUARTERLY|WEEKLY|YEARLY">
</ora-table-ddl>
</ora-db-ddl>
</upgrade>
</database>

The following list describes the attributes that you can configure on the <ora-table-date-interval-
partitioning> element.

datecolumn Required. Name of the column to use for the date range. The column must be non-nullable and one of the
following types:
• datetime
• dateonly
interval Required. The interval for each partition. Valid values are:
• DAILY
• MONTHLY
• QUARTERLY
• WEEKLY
• YEARLY

The <ora-table-date-interval-partitioning> element does not contain additional subelements.

The ora-table-hash-partitioning Database Configuration Element

The <ora-table-ddl> element in file database-config.xml contains, at most, a single occurrence of subelement
<ora-table-hash-partitioning>. The use of the <ora-table-hash-partioning> element is optional. Use this
element to add hash partitioning to a table in an Oracle database.

The ora-db-ddl Database Configuration Element 253

 System Administration Guide 9.0.5

The <ora-table-hash-partitioning> element has the following syntax. The following code sample shows
required attributes in bold font.

<database>
<upgrade>
<ora-db-ddl>
<ora-table-ddl table-name="string">
<ora-table-hash-partitioning hash-columns="string" num-partitions="integer"/>
</ora-table-ddl>
</ora-db-ddl>
</upgrade>
</database>

The following list describes the attributes that you can configure on the <ora-table-hash-partitioning> element.
All of these attributes are optional.

hash-column Name of the column to use for the hash function:

• For keyable entities, the default is the entity ID.
• For non-keyable entities, you must provide a value.
num-partitions The number of hash partitions to define. The default is 128.

The <ora-table-hash-partitioning> element does not contain additional subelements.

The ora-table-tablespaces Database Configuration Element

The <ora-table-ddl> element in file database-config.xml contains, at most, a single occurrence of subelement
<ora-table-tablespaces>. The use of the <ora-table-tablespaces> element is optional. Use this element to
provide overrides for the default table, index, and LOB tablespaces for a specific, named table in an Oracle database.
The <ora-table-tablespaces> element has the following syntax. The following code sample shows required
attributes in bold font.

<database>
<upgrade>
<ora-db-ddl>
<ora-table-ddl table-name="string">
<ora-table-tablespaces index-tablespace="string" lob-tablespace="string"
table-tablespace="string"/>
</ora-table-ddl>
</ora-db-ddl>
</upgrade>
</database>

The following list describes the attributes that you can configure on the <ora-table-tablespaces> element. All of
these attributes are optional.

index-tablespace Name of the tablespace override for the specified index.

lob-tablespace Name of the tablespace override for the specified LOB column.
table-tablespace Name of the tablespace override for the specified table.

The <ora-table-tablespaces> element does not contain additional subelements.

The versiontriggers Database Configuration Element

The <upgrade> element in file database-config.xml contains, at most, a single occurrence of subelement
<versiontriggers>. The use of the <versiontriggers> element is optional. Use this element to provide overrides
for one or more named database version triggers.

254 chapter 15 Database Configuration

 System Administration Guide 9.0.5

The database upgrade executes a series of version triggers that make changes to the database to upgrade between
ClaimCenter versions. Usually, the default settings are sufficient. Change these settings only while investigating a
slow database upgrade.
The <versiontriggers> element has the following syntax. The following code sample shows required attributes in
bold font.

<database>
<upgrade>
<versiontriggers dbmsperfinfothreshold="integer">
<versiontrigger extendedquerytracingenabled="true|false" name="string"
parallel-dml="true|false" parallel-query="true|false"
queryoptimizertracingenabled="true|false" recordcounters="true|false"
updatejoinorderedhint="true|false" updatejoinusemergehint="true|false"
updatejoinusenlhint="true|false"/>
</versiontriggers>
</upgrade>
</database>

The <versiontriggers> element has the following attribute, which is optional.

dbmsperfinfothreshold Specifies–for all version triggers–the threshold after which the database upgrader gathers
performance information from the database. The default is 600 (seconds).
If a version trigger takes longer than dbmsperfinfothreshold number of seconds to
execute, ClaimCenter:
• Queries the underlying database management system (DBMS).
• Builds a set of HTML pages with performance information for the interval in which the
version trigger was executing.
• Includes these HTML pages in the upgrader instrumentation for the version trigger.
You can completely turn off the collection of database snapshot instrumentation for
version triggers by setting the value of the dbmsperfinfothreshold attribute to 0. If you
do not have the license for the Oracle Diagnostics Pack, you must set dbmsperfinfothresh
old to 0 before running the upgrade.

The <versiontriggers> element has the following subelement, of which there can be multiple occurrences.

versiontrigger Provides override instructions for a specific, named, version trigger. See “The versiontrigger
Database Configuration Element” on page 255

See also
• “The Database Configuration File” on page 220
• “The upgrade Database Configuration Element” on page 237

The versiontrigger Database Configuration Element

The <versiontriggers> element in file database-config.xml can contain any number of occurrences of
subelement <versiontrigger>. The use of the <versiontrigger> element is optional. Use this element to provide
specific override instructions for a named version trigger.
The <versiontriggers> element has the following syntax. The following code sample shows required attributes in
bold font.

<database>
<upgrade>
<versiontriggers>
<versiontrigger extendedquerytracingenabled="true|false" name="string"
parallel-dml="true|false" parallel-query="true|false"
queryoptimizertracingenabled="true|false" recordcounters="true|false"
updatejoinorderedhint="true|false" updatejoinusemergehint="true|false"

The versiontriggers Database Configuration Element 255

 System Administration Guide 9.0.5

updatejoinusenlhint="true|false"/>
</versiontriggers>
</upgrade>
</database>

The following list describes the attributes that you can configure on the <versiontrigger> element.

name Required. Case-sensitive, fully qualified name of a version trigger.

The following attributes are all optional.
extendedquerytracingenabled Boolean. (Oracle) Whether ClaimCenter uses extended SQL tracing (Oracle event
10046) for the SQL statements that the version trigger executes. The default is fals
e.
This output can be very useful if debugging certain types of performance problems.
The trace files that ClaimCenter generates exist only on the actual database
computer. ClaimCenter does not integrate this information into the upgrade
instrumentation.
parallel-dml Boolean. (Oracle) Whether Oracle executes DML (Data Manipulation Language)
statements in parallel for this particular version trigger during the database
upgrade.
Valid values are:
• true – Execute DML statement in parallel for inserts and updates for this
version trigger, unless the ora-parallel-dml attribute on the <upgrade>
element is set to disable.
• false – Disable parallel execution of DML statements for this version trigger,
even if set in code or if the ora-parallel-dml attribute on the <upgrade>
element is set to enable_all.
If not set, Oracle executes DML statements in parallel, if set in the code or the ora-
parallel-dml attribute on the <upgrade> element is set to enable_all (default).
See “The upgrade Database Configuration Element” on page 237 for more
information.
parallel-query Boolean. (Oracle) Whether a version trigger provides a hint to the optimizer to use
parallel queries while executing SQL queries. This can be useful in improving
performance as some version triggers read large amounts of data while running
their version check.
Valid values are:
• true – Execute parallel SQL queries unless the ora-parallel-query attribute
on the <upgrade> element is set to disable.
• false – Do not execute parallel SQL queries.
The default is false.
See “The upgrade Database Configuration Element” on page 237 for more
information.
queryoptimizertracingenabled Boolean. (Oracle) Whether ClaimCenter uses query optimizer tracing (Oracle event
10053) for the SQL statements that the version trigger executes. The default is fals
e.
This output can be very useful if debugging certain types of performance problems.
The trace files that ClaimCenter generates exist only on the actual database
computer. ClaimCenter does not integrate this information into the upgrade
instrumentation.
recordcounters Boolean. Whether to record the values of DBMS-specific counters at the beginning
and end of each execution of the specified version trigger. Valid values are:
• true – ClaimCenter retrieves the current state of the counters from the
underlying DBMS at the beginning of execution of the version trigger. This
behavior is dependent on the value of dbmsperfinfothreshold on <versiontr
iggers>. if the execution time of the version trigger exceeds the value of dbmsp

256 chapter 15 Database Configuration

 System Administration Guide 9.0.5

erfinfothreshold, ClaimCenter retrieves the state of the counters at the end

of the execution of the version trigger.
• false – ClaimCenter does not retrieve data.
The default is false.
ClaimCenter writes differences to the DBMS-specific instrumentation screens of the
upgrade instrumentation. ClaimCenter only persists these values with the upgrade
instrumentation if the execution time of the version trigger exceeds the configured
threshold.
See also “The versiontriggers Database Configuration Element” on page 254.
updatejoinorderedhint Boolean. (Oracle) Whether to use the ORDERED hint if using a SQL UPDATE statement
with a join operation. The default is false.
updatejoinusemergehint Boolean. (Oracle) Whether to use the USE_MERGE hint if using a SQL UPDATE
statement with a join operation. The default is false.
updatejoinusenlhint Boolean. (Oracle) Whether to use the USE_NL hint if using a SQL UPDATE statement
with a join operation. The default is false.

The <version-trigger> element does not contain additional subelements.

See also
• “The Database Configuration File” on page 220
• “The upgrade Database Configuration Element” on page 237

The versiontriggers Database Configuration Element 257

 System Administration Guide 9.0.5

258 chapter 15 Database Configuration

chapter 16

Database Maintenance

This topic discusses key issues for configuring and maintaining the ClaimCenter database. While ClaimCenter
automatically handles most changes to its schema, involve a database administrator in tuning and managing the
database server.

IMPORTANT The versions of third-party products that Guidewire supports for this release are subject to change
without notice. For current system and patch level requirements, visit the Guidewire Community and search for
knowledge article 1005, Supported Software Components.

See also
• Installation Guide

About the Upgrade and Versions Screen

ClaimCenter includes a Server Tools Upgrade and Versions screen that provides detailed information about each
database upgrade. The Upgrade and Versions screen includes information on the following:
• Version number of upgrade
• Status of upgrade
• Type of upgrade
• Start and time of upgrade
• Status of Deferred Upgrade Tasks batch processing
From this screen, you can drill down into more specific details about the upgrade, or download a report of the
upgrade details.
See also
• “Upgrade and Versions” on page 393

Database Best Practices

Guidewire recommends the following best practices for the ClaimCenter application database.
Database Maintenance 259
 System Administration Guide 9.0.5

Database Location and Synchronization

Physically locate the ClaimCenter application server and the database server in the same timezone and geographic
location. Locating the two servers in geographically distant locations increases the time that it takes the application
server to query the database. It is possible for the latency between the two servers to impact performance. As a
measure of this metric, Guidewire logs the time that it takes to verify access to the database at server startup.
Synchronize the application server with the database clock. The maximum time difference allowed between the
application server and database server is 29 minutes. If you use database clustering, synchronize all nodes in the
database cluster with each other.

Database Maintenance
If you need to perform any database maintenance tasks, such as applying a patch, shut down all ClaimCenter servers
that connect to the database. Restart the servers after the database maintenance is complete.
Run consistency checks on the database, especially after importing data.
Back up the database periodically to support disaster recovery options.
Monitor storage performance. If I/O (input/output) times are slower than 10ms, it indicates that there is most likely
an issue.
Monitor tablespace size allocations and disk space to ensure that ClaimCenter does not run out of space.
Update database statistics periodically so that the query optimizer selects an efficient plan for executing application
queries.

Database tables
For Oracle databases, keep the Oracle default settings as much as possible. For example, do not set a 4K block size.
Consult with Guidewire if you want to change the default Oracle settings.
Do not insert data directly into tables managed by ClaimCenter. This can cause the data distribution tool to fail and
cause other problems.
Do not add large numbers of mediumtext and CLOB columns to a table.
Do not add an index outside of ClaimCenter and not declare it in an extension file.
See also
• “Guidewire Database Direct Update Policy” on page 261
• “ClaimCenter Database Back Up” on page 262
• “Database Consistency Checks” on page 262
• “Understanding Database Statistics” on page 279

Understanding Data Model Updates

As ClaimCenter starts, it compares system metadata (the description of the objects and tables in the config
directory) to the database to see if they match. For example, if ClaimCenter contains a new object extension added
after the last server start, the database and metadata do not match. If these two do not match, ClaimCenter attempts
to update the database to match the metadata. This type of update to the data model is different than a product
version upgrade, which includes more extensive changes to the database.
The update process calculates current checksums for all the XML files in the data model. It then compares them
with historical checksums stored in the SystemParameter entity. If the values differ, then ClaimCenter updates the
database to match the metadata. As the last step in the update, ClaimCenter updates the SystemParameter entity
with the current checksums.
If during the update ClaimCenter creates a new table, then it also generates a unique index for the table. The
TableRegistry entity stores this information. In this way, ClaimCenter guarantees uniqueness.

260 chapter 16 Database Maintenance

 System Administration Guide 9.0.5

Before completing the startup process, ClaimCenter again verifies the data model against the physical database. If,
for some reason, the model and database disagree, ClaimCenter writes warnings to the log and, if possible, suggests
corrective actions. Take the corrective action if prompted to do so.
Note: If, for any reason, there is an interruption to the server during a database update, the server resumes the
update upon restart. ClaimCenter accomplishes this by storing the steps in the database and marking them
completed as part of the same database transaction that applies a change. This only applies to data model updates
and does not apply to product version upgrades.
See also
• “Run a Schema Verification Report” on page 261
• “About the Upgrade and Versions Screen” on page 259
• “View an Upgrade Report” on page 395
• “Understanding Guidewire Software Versioning” on page 395
• Configuration Guide

Run a Schema Verification Report

Procedure
1. Ensure that ClaimCenter is running.
2. Open a command prompt and navigate to the following location in the ClaimCenter installation directory:

admin/bin

3. Enter the following command to generate a database schema verification report.

system_tools -password password -verifydbschema

To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.

Guidewire Database Direct Update Policy

ClaimCenter runs on SQL-based Relational Database Management Systems (RDBMS). You can use SQL or other
query tools directly in a read-only manner to extract or view data. Such read-only queries, depending on their scope
and how they are written, can negatively effect overall database performance even though they do not modify any
data. Therefore, Guidewire recommends that you run SQL queries in a replica or copy of their production database,
rather than the production database itself. For applications such as data warehouses and intensive reporting,
Guidewire recommends that you explore mechanisms for replicating or summarizing data into a production
reporting database for this purpose. This practice can help unexpected production performance issues due to
intensive reporting requirements or lengthy queries.
Internal application logic, embedded in ClaimCenter application code and APIs, maintains a variety of data and
metadata that relates to your application data. This might not be obvious from review of the RDBMS table structure.
Examples include:
• Calculations of summary table data for reporting
• Caching of application data in memory for faster access
• Tracking of state information associated with the underlying data, such as the processing state of an integration
message
For this reason, never use SQL to directly update the underlying RDBMS. Any such direct SQL updates can leave
the data in an inconsistent state. Guidewire can require you to restore the database to a previous state if you require

Understanding Data Model Updates 261

 System Administration Guide 9.0.5

support after performing such an update query. Guidewire Support is not able to assist you with diagnosing and
correcting application issues caused by your database queries. It is your responsibility to restore ClaimCenter to a
consistent state.

WARNING Guidewire supports the in-built automatic database upgrade process only for Guidewire
InsuranceSuite products. Guidewire explicitly does not support any alternative process that executes SQL
DDL commands on the database.

If you have a legitimate need to update underlying application data, Guidewire recommends that you use Guidewire
APIs, either Java or Gosu, to perform the necessary updates. This ensures that you do not miss any critical side
effects of the updates in the process of altering the data. Using Guidewire APIs to update application data is safer
than using SQL queries with regard to consistency. However, with any programming language or API it is still
possible to update data incorrectly or in ways that do not perform well. Therefore, before using the APIs, Guidewire
strongly recommends that you review your intended updates with your Guidewire Support Partner and/or Guidewire
Professional Services team.
In the rare case in which no API exists to correct a data corruption problem, Guidewire can advise you on the SQL
queries to use to correct these problems. In these cases, the SQL queries used to update the database must be written,
or approved, by Guidewire. This process ensures that all SQL queries use correct logic and that you take all potential
side effects into account.
Do not apply any other SQL queries to modify data in a ClaimCenter database. Guidewire does not provide, nor
review, such queries for situations in which an API or supported alternate method is available.

ClaimCenter Database Back Up

ClaimCenter stores most information in the database, so the most important part of backing up the system is taking
frequent database backups. Consult the documentation for your database management system for tools and
techniques to backing up the database.
You can perform a hot (also called dynamic) or cold backup of the ClaimCenter database. You can take a hot backup
while users are still accessing ClaimCenter. Read your database documentation to understand the risks involved in
hot backups. If you plan on taking a cold backup, you must put the ClaimCenter server in maintenance mode before
performing the backup.
In the case of a complete system failure, with proper backups you can reinstall the ClaimCenter WAR or EAR file
on a new server, connecting to the same database. In the case of a database failure, you need to restart ClaimCenter
from the last database backup.
After restoring a ClaimCenter database from a backup, instruct ClaimCenter to rebuild its database statistics. See
“Understanding Database Statistics” on page 279.

Keep a Backup Copy of the ClaimCenter Configuration Files

Besides backing up the database, maintain a backup of the ClaimCenter configuration. This is especially important
for any files that you modify as part of installation or configuration of ClaimCenter. Guidewire stores all
configuration files in the ClaimCenter/modules/configuration/config directory, making it easy to keep these
files in a source control system, if desired.

Database Consistency Checks

ClaimCenter includes a number of database consistency checks that you can run. These checks determine if any
unusual conditions exist in the ClaimCenter database such as orphaned child records or inconsistencies between
properties. If found, Guidewire reports any consistency check issues in the application console and also in the
cclog.log file, if configured. These reports are especially useful during trial periods or for testing converted data.

262 chapter 16 Database Maintenance

 System Administration Guide 9.0.5

The ClaimCenter log lists a check type for each consistency check that it runs. Each check type in the log can have a
value of either 0 or 1:
• A value of 0 indicates that ClaimCenter expects the check to return zero results if the database is consistent.
• A value of 1 indicates that ClaimCenter expects the check to have a different return value.
ClaimCenter uses the check type for custom checks:
• If a check type 0 fails, the log records a failure description that ClaimCenter expected the query issued by the
check to return zero rows. The log includes the SQL query run by the check and the number of inconsistencies
returned by the query.
• If a check type 1 fails, the log includes a specific failure description.
Note: The check type in the ClaimCenter log is not the same as the check type shown in the Typelists section of the
ClaimCenter Data Dictionary.
See also
• “Consistency Checks” on page 361

Recommendations for Running Database Consistency Checks

Guidewire recommends that you run the database consistency checks on a regular basis to identify potential
problems. For example, run database consistency checks:
• Before importing data into a production database
• Before and after a database upgrade
• Weekly after a new ClaimCenter deployment
• Monthly after stabilization of a new ClaimCenter deployment
• Monthly while testing imported data that you converted from a legacy system
• Monthly after you have moved the converted data to a production database

Consistency Checks and Performance

For very large databases, running consistency checks can have a major negative effect on ClaimCenter performance.
For example, some consistency check queries use a large amount of temporary space on Oracle
For development environments with very small data sets, you can enable consistency checks to run each time the
ClaimCenter server starts. However, be aware that running consistency tests during server startup:
• Can take a large amount of time to complete
• Can impact performance severely
• Can possibly time out on large datasets

IMPORTANT Set the checker attribute on <database-config> to false under most circumstances. Guidewire
recommends that you do not set checker to true except in development environments with very small test data
sets.

Running Consistency Checks

The following table lists the various ways that you can run or trigger database consistency checks.

Ways to run consistency checks … For more information

From the Consistency Checks screen “Running Consistency Checks from ClaimCenter” on page 264
From a command prompt “Running Consistency Checks from a Command Prompt” on page 264

Database Consistency Checks 263

 System Administration Guide 9.0.5

Ways to run consistency checks … For more information

At server start up “Configure Consistency Checks to Run at Server Startup” on page 264

See also
• “Configuring the Number of Threads for Consistency Checks” on page 265

Running Consistency Checks from ClaimCenter

Guidewire recommends that you view and run consistency checks from the Server Tools Consistency Checks screen in
ClaimCenter. The Consistency Checks screen lists which consistency checks are available for specific tables. You can
also use this page to view the results of previous consistency check runs. If there are consistency check errors, the
results include SQL queries that you can use to identify records that violated the consistency check.
See also
• “Run a Consistency Check from ClaimCenter” on page 364

Running Consistency Checks from a Command Prompt

It is possible to launch database consistency checks from a command prompt. Launching consistency checks from
the command prompt is useful primarily for scheduling checks to run on a regular basis. This approach to running
consistency checks uses the system_tools -checkdbconsistency command option.
Running consistency checks using the -checkdbconsistency option can take a long time. If the connection times
out while running this command, try the following:
• Run consistency checks on fewer tables at a time.
• Increase the number of worker instance threads used by the consistency check work queue.
See also
• “Configuring the Number of Threads for Consistency Checks” on page 265
• “Run a Consistency Check Using System Tools” on page 365
• “System Tools Options” on page 423

Configure Consistency Checks to Run at Server Startup

Procedure
1. In the ClaimCenter Studio Project window, expand configuration→config:
a. Open file database-config.xml.
b. Add a checker attribute on the <database> element and set the attribute to true.

<database checker="true" ...>

By default, Guidewire omits this attribute in the base configuration and sets it value to false.
c. Save and close file database-config.xml.
2. Restart the application server to trigger the database consistency checks:
• If working in a development environment, restart the QuickStart server.
• If working in a production environment, create a new WAR or EAR file and deploy the file to the
production server.

264 chapter 16 Database Maintenance

 System Administration Guide 9.0.5

Next steps
See also
• “The Database Configuration File” on page 220
• “Configure Worker Threads for Consistency Checks in config.xml” on page 266

Configuring the Number of Threads for Consistency Checks

Using a larger number of threads for consistency checks can help performance as long as your server can process the
threads. Guidewire recommends starting with five threads. If you use too many threads, there is a greater chance that
current users can experience reduced performance if the database operates with a full load.
It is possible to set the number of threads to use for each consistency check in several different ways, depending on
how you configure the consistency checks to run. The following table outlines these differences.

Ways to set thread count For more information

From Consistency Checks screen “Configure Worker Threads for Consistency Checks in work-queue.xml” on page 265
From command prompt “Configure Worker Threads for Consistency Checks in work-queue.xml” on page 265
At server start up “Configure Worker Threads for Consistency Checks in config.xml” on page 266

See also
• “Database Consistency Checks” on page 262
• “Consistency Checks” on page 361

Configure Worker Threads for Consistency Checks in work-queue.xml

About this task

ClaimCenter uses the work queue mechanism to run consistency checks.

Procedure
1. In the ClaimCenter Studio Project window, expand configuration→config→workqueue:
a. Open file work-queue.xml for editing.
b. Locate the block of code that contains the following workQueueClass value.

com.guidewire.pl.system.database.checker.DBConsistencyCheckWorkQueue

c. Locate the <worker> element for this code block.

d. Set the instances and batchsize attributes as appropriate for your ClaimCenter installation.
For example, the following code sets the consistency check work queue to use five worker threads, with
each worker checking out ten work items at a time.

<worker instances="5" batchsize="10"/>

2. Restart the application server for your changes to take effect:

• If working in a development environment, restart the QuickStart server.
• If working in a production environment, create a new WAR or EAR file and deploy the file to the
production server.

Database Consistency Checks 265

 System Administration Guide 9.0.5

Next steps
See also
• “Configuring Work Queues” on page 96

Configure Worker Threads for Consistency Checks in config.xml

About this task

If the database connection times out while running consistency checks at server startup, Guidewire recommends that
you increase the number of worker threads available for processing the consistency checks.

Procedure
1. In the ClaimCenter Studio Project window, expand configuration→config:
a. Open file config.xml for editing.
b. Locate the ConsistencyCheckerThreads parameter.
In the base configuration, the value of this parameter is 1.
c. Set the value of this parameter to a number that meets your business needs.
For example, set this value to five.

<param name="ConsistencyCheckerThreads" value="5"/>

2. Restart the application server for your changes to take effect:

• If working in a development environment, restart the QuickStart server.
• If working in a production environment, create a new WAR or EAR file and deploy the file to the
production server.

Recalculating Financial Summaries

ClaimCenter calculates financial values such as open reserves, total payments, and gross check amounts.
ClaimCenter stores these values in the the following database tables:
• cc_claimrpt
• cc_exposurerpt
• cc_checkrpt
If any of the database consistency checks that ClaimCenter performs on these tables fails, use the following
command to recalculate these values and repopulate the database tables.

maintenance_tools –password password –startprocess financialscalculations

To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user su (in
the base configuration) and you must supply that user’s password.
Note: Only run this process if you encounter consistency check failures. You can not schedule this process to run
periodically.

Rebuilding Contact Associations

If any of the database consistency checks that ClaimCenter performs on claims and their contacts fails, use the
following command to recalculate these associations and repopulate the database tables.

maintenance_tools –password password –startprocess claimcontactscalculations

266 chapter 16 Database Maintenance

 System Administration Guide 9.0.5

To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user su (in
the base configuration) and you must supply that user’s password.
Note: Only run this process if you encounter consistency check failures. You can not schedule this process to run
periodically.

Resize Database Columns

About this task
After the ClaimCenter database is in use, you might discover that you need to change the size of certain columns,
such as making a column name longer. ClaimCenter does not provide an automated way of doing this. However, the
following commonly used procedure provides a general outline of the steps involved making this kind of database
change.

IMPORTANT Guidewire does not support re-sizing any database columns that are part of the ClaimCenter base
configuration.

Procedure
1. Shut down ClaimCenter.
2. Alter the table and add a new temporary column that is the new size.
3. Copy all of the data from the source column to the temporary column.
4. Alter the table and drop the source column.
Depending on the database, it is possible that you need to set the data in this column to all nulls before you can
drop the column.
5. Alter the table and add the new source column that is the new size.
6. Copy the data from the temporary column to the new source column.
7. Alter the table and drop the temporary column.
8. Restart ClaimCenter.

Purging Unwanted Data

Over time, the ClaimCenter database acquires and stores ever-increasing amounts of data. Left unchecked, the
database can contain a large amount of unused and unnecessary data. Guidewire recommends that you periodically
remove this stale data to improve performance and reduce complexity during upgrade. To facilitate the removal of
unnecessary data, Guidewire provides a number of purge-related batch processes and work queues.
See also
• “Understanding Claim Purging” on page 273

About Purging Activity-related Workflow Data

Each time ClaimCenter creates an activity, it adds that activity to the following tables:
• cc_Workflow
• cc_WorkflowLog
• cc_WorkflowWorkItem
After a user completes the activity, ClaimCenter sets the workflow status to completed. ClaimCenter never uses the
cc_Workflow, cc_WorkflowLog and cc_WorkflowWorkItem table entry for that activity again. These tables grow in

Resize Database Columns 267

 System Administration Guide 9.0.5

size over time and can adversely affect performance and waste disk space. Excessive records in these tables also
negatively impacts the performance of the database upgrade.
Guidewire recommends that you periodically purge workflows, workflow log entries, and workflow items for
completed activities to improve database upgrade and operational performance and to recover disk space.
See also
• “Purging Workflow Data” on page 271
• “Purging Workflow Log Data” on page 272
• “Purging Work Item Set Data” on page 272

Purging Claim Data

Bulk Purge batch processing deletes ClaimInfo objects marked as retired from the ClaimCenter database. It
traverses the domain graph to delete entities, presumably already retired, related to the retired claim. In the base
configuration, ClaimCenter schedules the BulkPurge batch process to run every day at 2:00 a.m.
To mark a ClaimInfo object and all its subobjects as retired in the claim graph, run the following
maintenance_tools command from a command prompt:

maintenance_tools -password password -markforpurge -claims n1, n2, ...

It is possible to launch Bulk Purge batch processing from within ClaimCenter, or, directly from a command prompt.

ClaimCenter Navigate to the Server Tools Batch Process Info screen and run the Bulk Purge batch process.
Command Launch the Bulk Purge batch process from the ClaimCenter/admin/bin directory with the following
prompt command:
maintenance_tools -password password -startprocess BulkPurge
To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.

See also
• “Bulk Purge Batch Processing” on page 107
• “Understanding Claim Purging” on page 273
• “Batch Process Info” on page 349
• “Maintenance Tools Command” on page 418

Purging Batch Process History Data

Process History Purge batch processing deletes batch process history data from the ClaimCenter ProcessHistory
table. The process uses configuration parameter BatchProcessHistoryPurgeDaysOld to determine the number of
days to retain batch process history before deletion. By default, Guidewire sets the value of
BatchProcessHistoryPurgeDaysOld to 45 days.
In the base configuration, ClaimCenter schedules the ProcessHistoryPurge batch process to run on the third day of
the month at 3:30 a.m.
It is possible to launch Process History Purge batch processing from within ClaimCenter, or, directly from a
command prompt.

ClaimCenter Navigate to the Server Tools Batch Process Info screen and run the Process History Purge batch process.
Command Launch the Purge Workflows batch process from the ClaimCenter/admin/bin directory with the following
prompt command:
maintenance_tools -password password -startprocess ProcessHistoryPurge

268 chapter 16 Database Maintenance

 System Administration Guide 9.0.5

To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.

See also
• “Process History Purge Batch Processing” on page 122
• “Batch Process Info” on page 349
• “Maintenance Tools Command” on page 418

Purging Cluster Member Data

Purge Cluster Members batch processing deletes ClusterMemberData entities from the ClaimCenter database. The
process uses Gosu class PurgeClusterMembers, in conjunction with configuration parameter
ClusterMemberPurgeDaysOld, to determine the date on which to delete a ClusterMemberData entity. By default,
Guidewire sets the value of PurgeClusterMembers to 30days.
In the base configuration, ClaimCenter schedules the PurgeClusterMember batch process to run on the first day of
each month, at 2:00 a.m.
It is possible to launch Purge Cluster Members batch processing from within ClaimCenter, or, directly from a
command prompt.

ClaimCenter Navigate to the Server Tools Batch Process Info screen and run the Purge Cluster Members batch process.
Command Launch the Purge Workflows batch process from the ClaimCenter/admin/bin directory with the following
prompt command:
maintenance_tools -password password -startprocess PurgeClusterMembers
To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.

See also
• “Purge Cluster Members Batch Processing” on page 122
• “Batch Process Info” on page 349
• “Maintenance Tools Command” on page 418

Purging Failed Work Items

Purge Failed Work Items batch processing deletes failed work items from all work queues. The process uses Gosu
class PurgeFailedWorkItems to determine which work items to delete.
In the base configuration, ClaimCenter schedules the PurgeFailedWorkItems batch process to run on the first day
of the month, at 1:00 a.m.
It is possible to launch Purge Failed Work Items batch processing from within ClaimCenter, or, directly from a
command prompt.

ClaimCenter Navigate to the Server Tools Batch Process Info screen and run the Purge Failed Work Items batch process.
Command Launch the Purge Workflows batch process from the ClaimCenter/admin/bin directory with the following
prompt command:
maintenance_tools -password password -startprocess PurgeFailedWorkItems
To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.

Purging Unwanted Data 269

 System Administration Guide 9.0.5

See also
• “Purge Failed Work Items Batch Processing” on page 123
• “Batch Process Info” on page 349
• “Maintenance Tools Command” on page 418

Purging Message History Data

Purge Message History batch processing deletes old messages from the ClaimCenter MessageHistory table.
Configuration parameter KeepCompletedMessagesForDays sets the length of time that a message remains in the
message history table before the batch process considers a message for deletion from the database. By default,
Guidewire sets the value of KeepCompletedMessagesForDays to 90 days.
In the base configuration, ClaimCenter schedules the PurgeMessageHistory batch process to run on the 20th of the
month, at 1:00 a.m.
It is possible to launch Purge Message History batch processing from within ClaimCenter, or, directly from a
command prompt.

ClaimCenter Navigate to the Server Tools Batch Process Info screen and run the Purge Message History batch process.
Command Launch the Purge Message History batch process from the ClaimCenter/admin/bin directory with the
prompt following command:
maintenance_tools -password password -startprocess PurgeMessageHistory
To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.

See also
• “Purge Message History Batch Processing” on page 123
• “Batch Process Info” on page 349
• “Maintenance Tools Command” on page 418

Purging Old Transaction ID Data

Purge Old Transaction IDs batch processing deletes SOAP header transaction IDs generated by systems external to
ClaimCenter. Guidewire does not schedule this batch process in the base configuration as the table that stores the
transaction IDs takes very little space in the database. Unless there is a constant buildup of these transaction IDs,
there is no real need to continually purge this data. In fact, if you do purge this data, it is then not possible to
determine if a new transaction is a duplicate of a transaction sent by the external system at an earlier date.
It is possible to launch Purge Old Transaction IDs batch processing from within ClaimCenter, or, directly from a
command prompt.

ClaimCenter Navigate to the Server Tools Batch Process Info screen and run the Purge Old Transaction IDs batch process.
Command Launch the Purge Old Transaction IDs batch process from the ClaimCenter/admin/bin directory with the
prompt following command:
maintenance_tools -password password -startprocess PurgeTransactionIDs
To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.

270 chapter 16 Database Maintenance

 System Administration Guide 9.0.5

See also
• “The Work Queue Scheduler” on page 93
• “Purge Old Transaction IDs Batch Processing” on page 123
• “Batch Process Info” on page 349
• “Maintenance Tools Command” on page 418

Purging Profiler Data

Purge Profiler Data batch processing deletes profiler data from the ClaimCenter database. This process uses the
read-only ProfilerDataPurgeBatchProcess class, in conjunction with configuration parameter
ProfilerDataPurgeDaysOld, to determine how many days to retain profiler data before deleting it. By default,
Guidewire sets the value of ProfilerDataPurgeDaysOld to 30 days.
In the base configuration, ClaimCenter schedules the PurgeProfilerData batch process to run every day at 2:00
a.m.
It is possible to launch Purge Profiler Data batch processing from within ClaimCenter, or, directly from a command
prompt.

ClaimCenter Navigate to the Server Tools Batch Process Info screen and run the Purge Profiler Data batch process.
Command Launch the Purge Profiler Data batch process from the ClaimCenter/admin/bin directory with the following
prompt command:
maintenance_tools -password password -startprocess PurgeProfilerData
To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.

See also
• “Purge Profiler Data Batch Processing” on page 124
• “Batch Process Info” on page 349
• “Maintenance Tools Command” on page 418

Purging Workflow Data

Purge Workflow batch processing deletes any completed workflows, after resetting any referenced workflows. This
process uses Gosu class PurgeWorkflow, in conjunction with configuration parameter WorkflowPurgeDaysOld, to
determine the number of days to retain workflow data before deletion. By default, Guidewire sets the value of
WorkflowPurgeDaysOld to 60 days, the number of days since the last update to the workflow (the date the workflow
completed).
In the base configuration, ClaimCenter schedules the PurgeWorkflows batch process to run on the first day of each
month, at 1:30 a.m.
It is possible to launch the Purge Workflow batch process from within ClaimCenter, or, directly from a command
prompt.

ClaimCenter Navigate to the Server Tools Batch Process Info screen and run the Purge Workflow batch process.
Command Launch the Purge Workflows batch process from the ClaimCenter/admin/bin directory with the following
prompt command:
maintenance_tools -password password -startprocess PurgeWorkflows
To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.

Purging Unwanted Data 271

 System Administration Guide 9.0.5

See also
• “Purge Workflow Batch Processing” on page 124
• “Batch Process Info” on page 349
• “Maintenance Tools Command” on page 418

Purging Workflow Log Data

Purge Workflow Logs batch processing deletes completed workflow logs. It does not remove workflow records,
only workflow log records. The process uses Gosu class PurgeWorkflowLogs, in conjunction with configuration
parameter WorkflowLogPurgeDaysOld, to determine the number of days to retain the workflow logs before deletion.
By default, Guidewire sets the value of WorkflowLogPurgeDaysOld to 30 days.
In the base configuration, ClaimCenter schedules the PurgeWorkflowLogs batch process to run on the first day of
each month, at 2:30 a.m.
It is possible to launch the Purge Workflow Logs batch process from within ClaimCenter, or, directly from a
command prompt.

ClaimCenter Navigate to the Server Tools Batch Process Info screen and run the Purge Workflow Logs batch process.
Command Launch the Purge Workflow Logs batch process from the ClaimCenter/admin/bin directory with the following
prompt command:
maintenance_tools -password password -startprocess PurgeWorkflowlogs
To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.

See also
• “Purge Workflow Logs Batch Processing” on page 124
• “Batch Process Info” on page 349
• “Maintenance Tools Command” on page 418

Purging Work Item Set Data

Work Item Set Purge batch processing deletes work item sets from the database. The process uses Gosu class
WorkItemSetPurge, in conjunction with configuration parameter BatchProcessHistoryPurgeDaysOld, to specify
the number of days to retain work item sets before deletion.
In the base configuration, ClaimCenter schedules the WorkItemSetPurge batch process to run on the second day of
each month, at 1:30 a.m.
It is possible to launch the Work Item Set Purge batch process from within ClaimCenter, or, directly from a
command prompt.

ClaimCenter Navigate to the Server Tools Batch Process Info screen and run the Work Item Set Purge batch process.
Command Launch the Purge Workflow Logs batch process from the ClaimCenter/admin/bin directory with the following
prompt command:
maintenance_tools -password password -startprocess WorkItemSetPurge
To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.

272 chapter 16 Database Maintenance

 System Administration Guide 9.0.5

See also
• “Work Item Set Purge Batch Processing” on page 129
• “Batch Process Info” on page 349
• “Maintenance Tools Command” on page 418

Purging Work Queue Instrumentation Data

Work Queue Instrumentation Purge batch processing deletes instrumentation data for work queues from the
ClaimCenter database. The process uses Gosu class WorkQueueInstrumentationPurge, in conjunction with
configuration parameter InstrumentedWorkerInfoPurgeDaysOld, to determine how long to retain work queue
instrumentation before deletion. By default, Guidewire sets the value of InstrumentedWorkerInfoPurgeDaysOld to
45 days.
In the base configuration, Guidewire schedules the WorkQueueInstrumentationPurge batch process to run on the
second day of the month, at 2:30 a.m.
It is possible to launch the Work Queue Instrumentation Purge batch process from within ClaimCenter, or, directly
from a command prompt.

ClaimCenter Navigate to the Server Tools Batch Process Info screen and run the Work Queue Instrumentation Purge batch process.
Command Launch the Purge Workflows batch process from the ClaimCenter/admin/bin directory with the following
prompt command:
maintenance_tools -password password -startprocess WorkQueueInstrumentationPurge
To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.

See also
• “Work Queue Instrumentation Purge Batch Processing” on page 129
• “Batch Process Info” on page 349
• “Maintenance Tools Command” on page 418

Working with Claim Data

There are a number of operations that affect claims data.

Understanding Claim Purging

You can purge unwanted claims from the database and the archive. Unwanted claims can be claims that are older
than a certain threshold, or they can be claims that were mistakenly or incorrectly entered into ClaimCenter. You can
also store a date on the claim in Claim.PurgeDate that indicates the date to purge the claim from the ClaimCenter
database. Storing a date in ClaimInfo.PurgeDate indicates the date that it is possible to purge the claim from the
archive. You must write code to check these dates if you want them to affect purging of claims.
ClaimCenter includes sample rules that you can use to set a claim purge date for a closed claim, and to null out the
purge date if the claim reopens. You can find these sample rules in ClaimCenter Studio in the Claim Closed and
Claim Reopened rule sets.
Note: While the sample rules set the values for Claim.PurgeDate and ClaimInfo.PurgeDate, the base
configuration of ClaimCenter does not use these dates. You can extend ClaimCenter to query these fields and use
them to determine the date to purge claims.
Purging a claim removes the claim from the database permanently. If your ClaimCenter installation uses claim
archiving, purging a claim permanently removes the claim from the archive as well. It is not possible to ever again

Purging Unwanted Data 273

 System Administration Guide 9.0.5

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.
For ClaimCenter to purge a claim, the claim must meet the following conditions:
• Unless it has draft status, the claim cannot have any active (unanswered) messages, or ClaimCenter throws an
ActiveMessageException.
• Unless it has draft status, the claim cannot be part of a workflow, or ClaimCenter throws an
ActiveWorkflowException.
Note: These conditions do not prevent you from purging an open claim.
As you purge a claim:
• All traces of the claim disappear from the main database. ClaimCenter uses the claim domain graph, which
identifies all tables and rows associated with the claim, for purging.
• ClaimCenter removes the claim from all claim associations. If there is only one claim remaining in the
association, ClaimCenter also removes the association itself.
• If there are no remaining claims associated with the claim’s policy period, ClaimCenter removes the policy
period.
Before doing your initial purge, Guidewire recommends that you back up the ClaimCenter database. As it is
probably not practical to back up the database before every purge, you need to develop a policy for making backups
that takes purges into account.

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.

Purging Claims with Bulk Invoices

While it is possible to purge a claim that has an associated bulk invoice, there are some restrictions. The status of a
bulk invoice line item determines whether or not the associated claim can be purged.
If the status of a bulk invoice line item is one of the following, it is possible to purge the claim:
• Pending stop
• Pending transfer
• Pending void
• Rejected
• Stopped
• Submitted
• Submitting
• Transferred
• Voided
If the status of a bulk invoice line item is one of the following, it is not possible to purge the associated claim. Any
attempt to do so generates an error within ClaimCenter.
• Item approved
• Awaiting submission
• Check pending approval
• Draft
274 chapter 16 Database Maintenance
 System Administration Guide 9.0.5

• In review
• Not valid
The error message includes the associated bulk invoice number. In the case of multiple bulk invoices causing the
failure, only the first invoice number is referenced.
See also
• “Understanding Claim Marking for Purging” on page 275
• “Purging Claims Using Command Prompt Tools” on page 275
• “Purge Claims Using Web Services” on page 276
• Rules Guide

Understanding Claim Marking for Purging

The first step in purging unwanted claims from the ClaimCenter database is to mark a set of specific claims for
purging. After you mark claims for purging, you can no longer view or edit those claims. However, these claims still
exist in the ClaimCenter database until you actually purge them.
Upon marking a claim for purge, ClaimCenter retires the row for that claim in the following tables:
• Claim
• ClaimInfo
ClaimCenter then deletes any row related to the claim that is not retireable from the following tables:
• ClaimInfoAccess
• ContactInfo
• LocationInfo
• PeriodPolicy

Purging Claims Using Command Prompt Tools

Purging claims using System Tools is a multistep process. The following list describes each step.

Action For more information

Mark the claims to purge “Mark Claims for Purge” on page 275
Run Bulk Purge batch processing to purge the claims “Purge Claims Using Bulk Purge Batch Processing” on page 276

See also
• “Maintenance Tools Command” on page 418
• “Bulk Purge Batch Processing” on page 107

Mark Claims for Purge

Procedure
1. Open a command prompt and navigate to the following location in the ClaimCenter installation.

admin/bin

2. Enter the following maintenance_tools command option.

maintenance_tools -password password -markforpurge -claims claimsforpurging

Working with Claim Data 275

 System Administration Guide 9.0.5

To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.
You must also supply a value for claimsforpurging, which must one of the following:
• A single claim number
• A comma-delimited list of claim numbers
• The name of a text file containing a list of claim numbers separated by commas or new lines
3. (Optional) If any of the claims that are you marking for purging have aggregate limits, include the -
purgefromaggregatelimit command option as well:

maintenance_tools -password password -markforpurge -claims claim_number1, claim_number2... -purgefromaggreg

atelimit

Purge Claims Using Bulk Purge Batch Processing

Before you begin

You must mark claims for purging before running Bulk Purge batch processing.

Procedure
1. Open a command prompt and navigate to the following location in your ClaimCenter installation.

admin/bin

2. Enter the following maintenance_tools command options to run the Bulk Purge batch process.

maintenance_tools -password password –startprocess bulkpurge

To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.

Result
ClaimCenter permanently deletes all claims that you marked for purging from the ClaimCenter database and the
archive. ClaimCenter also deletes the ClaimInfo record for each purged claim.

Purge Claims Using Web Services

Procedure
1. Mark the claims that are ready for purging by calling the markPurgeReady method on the
IMaintenanceToolsAPI web service, passing in the claim numbers for the claims to mark for purging.
2. Run Bulk Purge batch processing using one of the following methods:

Schedule the batch Guidewire does not schedule the Bulk Purge batch process in the base configuration. You can
process schedule this batch process to run at regular intervals or at a convenient time after you complete
marking claims for purging.
Run the batch Call the startBatchProcess("bulkpurge") method on the IMaintenanceToolsAPI web service.
process
immediately

276 chapter 16 Database Maintenance

 System Administration Guide 9.0.5

Result
After the Bulk Purge batch process completes, ClaimCenter deletes the marked claims.

Next steps
See also
• “Understanding Claim Purging” on page 273
• “Purging Claims Using Command Prompt Tools” on page 275
• “Bulk Purge Batch Processing” on page 107
• Integration Guide

Configuration Parameters that Affect Claim Search on Oracle

The execution plan that Oracle uses for certain searches performs poorly. To remedy this issue, Guidewire includes
configuration parameters in the config.xml file that relate to this issue. These Boolean parameters modify the
Oracle configuration if performing claim or team group activity searches. By default, Guidewire sets all of these
parameters to true in the base configuration. None of these parameters has an effect on database types other than
Oracle.
The these configuration parameters are:
• DisableIndexFastFullScanForClaimSearch
• DisableHashJoinForClaimSearch
• DisableSortMergeJoinForClaimSearch
• SetSemiJoinNestedLoopsForClaimSearch
• DisableIndexFastFullScanForTeamGroupActivities
• DisableHashJoinForTeamGroupActivities
• DisableSortMergeJoinForTeamGroupActivities
See also
• Configuration Guide

Oracle Materialized Views for Claim Searches

It is possible to create materialized views in an Oracle schema to improve the performance of queries that
ClaimCenter runs as part of a Claim search operation. Materialized views can be useful if performing a search for a
claimant or for any involved party using the name of a person or a company. If you implement materialized views in
the ClaimCenter schema, then Oracle attempts to use these materialized views if a rewritten query block matches the
text defined in the view.
For a description of how to create materialized views in a ClaimCenter schema, visit the Guidewire Community and
search for knowledge article 1069, ClaimCenter 6.0 using Oracle Database. Consult section 19 (Materialized
Views) of this knowledge article.
The Server Tools→Info Pages→Oracle AWR Information screen is aware of materialized views. You can use the
information on screen page to troubleshoot performance problems with the view. However, if you refresh the view,
the Oracle AWR Information page does not capture the refresh queries.

Stale Data
In performance testing, Guidewire observed significant performance degradation if configuration forced the
materialized view to refresh on commit. This is due to a synchronization enqueue required by the refresh process.
However, any refresh of the data done outside of the commit operation can potentially display stale data during the
search.

Working with Claim Data 277

 System Administration Guide 9.0.5

Oracle uses a cost-based optimizer approach to determine whether to use a materialized view for a given query. It
also expects the data to be fresh for the rewrite. As Guidewire bases the refresh process on the number of changes to
contact and claim contacts, Guidewire strongly recommends that you schedule the refresh process accordingly.

Query Rewrites Using Materialized Views

It is possible to create materialized views in an Oracle schema to improve the performance of queries that
ClaimCenter runs as part of a Claim search operation. Materialized views can be useful if performing a search for a
claimant or for any involved party using the name of a person or a company. If you implement materialized views in
the ClaimCenter schema, then Oracle attempts to use these materialized views if a rewritten query block matches the
text defined in the view.
Guidewire provides the configuration parameter QueryRewriteForClaimSearch to enable various options for an
Oracle query rewrite using materialized view. By setting this parameter, you can force a query to be rewritten using
a materialized view or to let 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.

Disabling Query Rewrites on Oracle

If you implement materialized views in the ClaimCenter schema, Oracle attempts to use these materialized views if
a rewritten query block matches the text defined in the view. However, the use of materialized views in database
queries is not always desirable due to performance considerations.
ClaimCenter provides an option to disable the rewriting of queries using materialized views. You can disable the use
of materialized views in Oracle database queries by setting the query-rewrite attribute on the <oracle-settings>
element to false in file database-config.xml.

278 chapter 16 Database Maintenance

chapter 17

Database Statistics Generation

This topic discusses database statistics, metadata that describe the underlying database.

Understanding Database Statistics

Database statistics are metadata that describe the underlying database. For example, database statistics store row
counts in a table, the distribution of data in the table, and much more. A database management system uses statistics
to determine query plans to optimize performance.
ClaimCenter provides database statistics generation designed specifically for how the ClaimCenter application and
data model interact with the physical database.
Use the Server Tools Database Statistics screen to determine if any statistics are out of date. Guidewire recommends
that you archive database statistics as standard practice. This ensures that you have a record of the database history
that you can review, if it becomes necessary.

IMPORTANT Have your database administrator (DBA) review the database statistics with you.

Database Statistics Generation for Oracle Databases

There are several different ways in which to generate database statistics in Guidewire ClaimCenter if using an
Oracle database:
• Use the Oracle Autotask infrastructure to manage the task of gathering database table statistics.
• Run ClaimCenter batch processing DBStats periodically to collect database table statics.
You enable the use of each method by setting the value of the useoraclestatspreferences attribute on the
<tablestatistics> element in file database-config.xml.

Statistics gathering useoraclestatspreferences Description For more information

Oracle AutoTask true Disable DBStats batch processing and “Using Oracle AutoTask for
use Oracle AutoTask to manage the Statistics Generation” on page
collection of database statistics. 287

Database Statistics Generation 279

 System Administration Guide 9.0.5

Statistics gathering useoraclestatspreferences Description For more information

DBStats batch false (Default) Disable Oracle AutoTask and “Database Statistics Batch
processing use DBStats to manage the collection Processing” on page 114
of database statistics.

Note: A change in the value of useoraclestatspreferences takes effect only during an application upgrade.
Disable the automatic generation of database statistics using Oracle by doing one of the following:
• Disable the Oracle AutoTask “auto optimizer stats collection” automated task.
• Set the AUTOSTATS_TARGET preference to ORACLE. This action ensures that the automated task gathers
statistics for the Oracle Dictionary only.
If using DBStats batch processing to manage the collection of database statistics:
• Do not execute Oracle dbms_stats manually.
• Manually execute, or schedule, DBStats batch processing.
See also Disable Automatic Database Statistics Generation by Oracle in the System Administration Guide.

Guidewire recommendations for Oracle database installations

• Guidewire recommends that Oracle implementations only update database statistics during quiet periods, such as
weekends or nights, so that these updates do not occur while ClaimCenter is under heavy load. By default,
updating statistics on a table or index invalidates existing query plans related to that table or index.
• Guidewire recommends that Oracle implementations use the NO_INVALIDATE => AUTO_INVALIDATE option
while updating database statistics. This is the default option. This option is also what the Guidewire Database
Statistics batch process uses, unless the configuration parameter DiscardQueryPlansDuringStatsUpdateBatch
is set to true.
Setting NO_INVALIDATE => FALSE to force immediate invalidation of query plans has a high likelihood of
causing issues with concurrent batch updates. Using AUTO_INVALIDATE greatly reduces this risk. Ideally, set the
_optimizer_invalidation_period parameter to a low value (a few minutes) to reduce the time window during
which Oracle might invalidate a plan.

Flush Monitoring Information after Table Import

For Oracle, if you want to run the incremental database statistics process after running the table_import -
integritycheckandload command, first flush the monitoring information using the procedure
DBMS_STATS.FLUSH_DATABASE_MONITORING_INFO.

Disable Automatic Database Statistics Generation by Oracle

About this task

If you do not intend to use the Oracle AutoTask infrastructure to manage the collection of database table statistics,
then disable the generation of database statistics by Oracle before you install Guidewire ClaimCenter. If Oracle
database statistics is enabled after the installation of ClaimCenter, do the following:

Procedure
1. Disable Oracle database statistics generation.
2. Delete the schema statistics.
3. Gather full database statistics using the Guidewire DBStats batch process.

280 chapter 17 Database Statistics Generation

 System Administration Guide 9.0.5

Database Statistics Generation for SQL Server Databases

Guidewire recommends that you only update database statistics during quiet periods, such as weekends or nights, so
that these updates do not occur while ClaimCenter is under heavy load. By default, updating statistics on a table or
index invalidates existing query plans related to that table or index.
Guidewire requires that you ensure the following options are set to true on the SQL Server database used for
ClaimCenter:
• Auto Create Statistics
• Auto Update Statistics

Updates to Database Statistics

Updating database statistics can take a long time on a large database. Collect full statistics only if there are
significant changes to data such as after a major upgrade. Guidewire recommends that you collect full statistics if
using the table_import -integritycheckandload or zone_import command or if there are performance
problems. Under standard operating conditions, you generally need to gather incremental database statistics only on
a frequent basis.
If you encounter performance problems or degradation related to the database, check the Database Statistics screen on
the Info Pages section of the Server Tools. If this screen shows suspicious or inaccurate statistics, update database
statistics. If the data change is high, consider using a daily schedule for updating incremental statistics. Use the daily
schedule to provide statistics on tables that have had a configurable percentage of data changed since the last
statistics process was run.

Understanding Database Statistics Batch Processing

ClaimCenter uses Database Statistics batch processing DBStats to generate database statistics. The database
statistics batch process is resource-intensive. To prevent an accidental start of this process, you cannot start Database
Statistics from the Server Tools Batch Process Info screen. Instead, you must start the process manually from a
command prompt.

IMPORTANT Consult with your Database Administrator before starting the database statistics process.

Some ClaimCenter batch processes use work or scratch tables to store intermediate calculations. Other batch
processes populate denormalized tables that ClaimCenter uses internally for performance reasons. These processes
can update database statistics on the scratch tables and denormalized tables during their execution.
As you import data into tables from an external source by using the table_import -integritycheckandload
command, ClaimCenter validates the staging tables against the data model and the production tables. To avoid the
formation of bad queries prior to loading new data, ClaimCenter updates statistics for the involved tables before and
after the load. For optimum performance, generate full database statistics after running the integritycheckandload
command option.
See also
• “Database Statistics Batch Processing” on page 114
• “Managing Database Statistics using System Tools” on page 282
• “Batch Process Info” on page 349
• “Maintenance Tools Command” on page 418
• “Table Import Command” on page 430

Automatic Generation of Database Statistics During Upgrade

ClaimCenter automatically updates specific database statistics during an upgrade, in conjunction with selected batch
processes, or during the table_import integritycheckandload or zone_import processes.

Understanding Database Statistics 281

 System Administration Guide 9.0.5

For database upgrades, ClaimCenter updates database statistics for objects that the upgrade process changes
significantly. For optimum performance, generate full database statistics during the next maintenance window after
performing a major upgrade.

Managing Database Statistics using System Tools

You can use the system_tools command options to explicitly update database statistics or to generate the SQL
statements to update statistics. It is possible to update database statics fully or incrementally.

Full database Generates database statistics for every table in the ClaimCenter database.
statistics
Incremental Generates database statistics for tables for which the change in the table data caused by inserts and deletes
database exceeds a certain percentage threshold. You specify this threshold through the incrementalupdatethresho
statistics ldpercent attribute on the <databasestatistics> element in file database-config.xml. The default is 10
percent.

It is possible to pause the database statistics updating process, just as you can with other work queues. Use the
Server Tools Work Queue Info page to pause an in-progress work queue.
See also
• “Understanding Database Statistics” on page 279
• “System Tools Command” on page 422

Perform a Full Database Statistics Update

Procedure
1. Ensure that the ClaimCenter is running.
2. In a command prompt, navigate to the following location in the ClaimCenter installation directory:

admin/bin

3. Enter the following command to update statistics for all tables.

system_tools -password password -updatestatistics description false

To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.

Update Statistics on Tables that Exceed a Change Threshold

About this task
This process does not update statistics on any table that contains locked statistics.

Procedure
1. Ensure that the ClaimCenter is running.
2. Open a command prompt and navigate to the following location in the ClaimCenter installation directory:

admin/bin

3. Enter the following command to update statistics for tables exceeding the change threshold.

282 chapter 17 Database Statistics Generation

 System Administration Guide 9.0.5

system_tools -password password -updatestatistics description true

To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.

Check the Database Statistics Updating Process

Procedure
1. Ensure that the ClaimCenter is running.
2. Open a command prompt and navigate to the following location in the ClaimCenter installation directory:

admin/bin

3. Enter the following command to check on the state of the process that updates database statistics.

system_tools -password password -getupdatestatsstate

To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.

Cancel the Database Statistics Updating Process

About this task
If you receive the following error on submitting a new database statistics job, it is possible that the Database
Statistics process terminated abruptly:
The Database Statistics process is already in progress
If you receive this error message, you need to manually cancel the process.

Procedure
1. Ensure that the ClaimCenter is running.
2. Open a command prompt and navigate to the following location in the ClaimCenter installation directory:

admin/bin

3. Enter the following command to cancel the process that updates database statistics.

system_tools -password password -cancelupdatestats

To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.

Generate Statistics SQL for All Tables

About this task
You can use the results purely as a reference, or you can edit the statements and execute them outside of
ClaimCenter.

Managing Database Statistics using System Tools 283

 System Administration Guide 9.0.5

Procedure
1. Ensure that the ClaimCenter server is running.
2. Open a command prompt and navigate to the following location in the ClaimCenter installation directory:

admin/bin

3. Enter the following command to generate database statistic SQL statements for all tables.

system_tools -password password -getdbstatisticsstatements

To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.

Result
ClaimCenter groups the output statements by table.

Generate Statistics SQL for Tables that Exceed a Threshold

Procedure
1. Ensure that the ClaimCenter server is running.
2. Open a command prompt and navigate to the following location in the ClaimCenter installation directory:

admin/bin

3. Enter the following command to generate database statistic SQL statements for tables exceeding the change
threshold.

system_tools -password password -getincrementaldbstatisticsstatements

To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.

Result
ClaimCenter groups the output statements by table.

Configuring Database Statistics Generation

You control which database statistics statements ClaimCenter generates by configuring the database connection in
the database-config.xml file. You control the number of threads that ClaimCenter uses for the work queue used in
generating database statistics through configuration of file work-queue.xml.
See also
• “Understanding Database Statistics” on page 279
• “Managing Database Statistics using System Tools” on page 282

Configuring the Number of Threads for Statistics Generation

Note: This topic is relevant only if using DBStats batch processing to manage the collection of database statistics.
ClaimCenter uses the work queue mechanism for statistics generation. You can therefore configure work queue and
worker attributes for statistics generation in the work-queue.xml file. Access this file in Guidewire Studio at
284 chapter 17 Database Statistics Generation
 System Administration Guide 9.0.5

configuration→config→workqueue. Set parameters for the work queue with workQueueClass set to
com.guidewire.pl.system.database.dbstatistics.DBStatisticsWorkItemWorkQueue. For example:

<work-queue
workQueueClass="com.guidewire.pl.system.database.dbstatistics.DBStatisticsWorkItemWorkQueue"
progressinterval="86400000">
<worker instances="5" batchsize="10"/>
</work-queue>

In this configuration, the statistics generation work queue uses five worker threads and each worker checks out ten
work items at a time.
If you edit work-queue.xml, you must rebuild and redeploy ClaimCenter.
See also
• “The Work Queue Scheduler” on page 93

Statistics and the Database Configuration File

File database-config.xml contains a single <databasestatistics> element, which has the following format.

<databasestatistics samplingpercentage="integer" databasedegree="integer"

incrementalupdatethresholdpercent="integer">
<tablestatistics name="string" samplingpercentage="integer" databasedegree="integer"
action="delete|keep|update">
<histogramstatistics name="string" numbuckets="integer" />
...
</tablestatistics>
...
</databasestatistics>

In the following example, an Oracle database connection shows the use of these parameters:

<databasestatistics samplingpercentage="0" databasedegree="4" incrementalupdatethresholdpercent ="15">

<tablestatistics name="cc_table1" samplingpercentage="0" databasedegree="4">
<histogramstatistics name="scheduledsenddate" numbuckets="254"/>
</tablestatistics>
<tablestatistics name="cc_table2" action="delete" />
</databasestatistics>

The previous example configures the following database statistic generation behavior:
• Collects statistics on all ClaimCenter tables using the automatic sampling size and with a degree of parallelism of
4.
• Samples table cc_table1 using Oracle AUTO_SAMPLE_SIZE, which is the recommended value.
• Uses a parallel degree of 4.
• Defines a histogram with 254 buckets (time slots) on cc_check.scheduledsenddate. Guidewire requires that
you provide a value for this attribute.
• Deletes statistics on cc_table2 due to the attribute action="delete".
See also
• “The Database Statistics Element” on page 285
• “The Table Statistics Database Element” on page 289

The Database Statistics Element

You use the <databasestatistics> element in database-config.xml to specify database statistic parameters that
override the database defaults specified on the database. This element has the following attributes.

Configuring Database Statistics Generation 285

 System Administration Guide 9.0.5

databasedegree On Oracle, this attribute controls the degree of parallelism for each individual
statement. The default is 1. ClaimCenter uses the value of this attribute for all
statements.
SQL Server ignores the databasedegree attribute.
incrementalupdatethresholdpercent Specifies the percentage of table data that must have changed since the last
statistics process for the incremental statistics generation batch process to update
statistics for the table.
The default is 10.
numappserverthreads On both Oracle and SQL Server, the numappserverthreads attribute controls the
number of threads that ClaimCenter uses to update database statistics for staging
tables during import only. Command prompt tool table_import launches this
import.
The value defaults to 1. If the value is greater than 1, then the ClaimCenter server
assigns a table at a time to each thread as the thread becomes available. Each
thread executes all of the database statistics statements for its assigned table.
For all other statistics generation operations, set the number of threads by
specifying the number of workers for the database statistics work queue. Set the in
stances attribute on the <workers> subelement of the <work-queue> element for
the database statistics work queue. This element has workQueueClass="com.guide
wire.pl.system.database.dbstatistics.DBStatisticsWorkItemWorkQueue".
The default is 1.
samplingpercentage On Oracle, this attribute controls the value of the estimate_percent parameter in
the dbms_stats.gather_table_stats() SQL statements. You can set samplingpe
rcentage to an integer from 1 to 100 to directly set the estimate_percent value.
However, Guidewire recommends highly that you set the samplingpercentage
value to 0 to set estimate_percent to AUTO_SAMPLE_SIZE. The default value is 0.
On SQL Server, the samplingpercentage attributes controls the value of the WITH
FULLSCAN/SAMPLE PERCENT clause in the UPDATE STATISTICS statements. A value
of 100, the default, translates into WITH FULLSCAN, as does a value of 0.
The default is 0.
useoraclestatspreferences On Oracle, this attribute sets the database statistics preferences to be able to use
the Oracle Autotask infrastructure instead of the DBStats batch process from
ClaimCenter. The default is false, which requires that you disable the Autotask and
schedule DBStats batch processing in its place. Changes to the value of this
attribute only take effect during an application upgrade.

The values you set for these attributes apply to all the tables in the database. You can fine tune these values and set
specific values on individual tables by using the <tablestatistics> subelement. Setting values on a specific table
overrides the values set on the database for just that table.
See also
• “Configuring Database Statistics Generation” on page 284
• “The Database Statistics Element” on page 285
• “Using Oracle AutoTask for Statistics Generation” on page 287
• “Table Import Command” on page 430

286 chapter 17 Database Statistics Generation

 System Administration Guide 9.0.5

Using Oracle AutoTask for Statistics Generation

The purpose of the useoraclestatspreferences attribute on the <databasestatistics> element in file
database-config.xml is twofold:
• To set the table statistics preferences according to those set for Oracle in file database-config.
• To have the Oracle AutoTask infrastructure manage the task of collecting table statistics, based on preferences
that Guidewire sets in the base configuration.
To set Oracle to collect table statistics, set this attribute value to true, for example:

<database name="ExampleDatabase" dbtype="oracle" env="oracle" printcommands="true">

<databasestatistics databasedegree="4" useoraclestatspreferences="true">
...

Any change to this attribute value takes effect only during an upgrade, either a full upgrade or a rolling
(configuration) upgrade. To force ClaimCenter to recognize the change without an application upgrade, increment
the application metadata version and restart the application server.
After you set this attribute to true, the next application upgrade does the following:
• It clears all existing preferences for table statistics.
• It resets the preferences for table statistics to those currently defined for Oracle table statistics in database-
config.xml.
• It creates a new tab named Oracle Statistics Preferences in the Server Tools Info Pages→Database Catalog Statistics
Information screen.
To confirm that the application upgrade set the database statistics preferences, review the Oracle Statistics Preferences
tab and verify the preferences.

Enabling Oracle AutoTask

After you set this parameter to true for the first time, do the following:
• Ensure that the statistics target setting has the default value of AUTO.
• Ensure that you enable Oracle AutoTask for statistics collection.
The Oracle DBA can run the following SQL commands to set these value back to their default.

EXEC dbms_stats.set_global_prefs('AUTOSTATS_TARGET','AUTO');
EXEC dbms_auto_task_admin.enable(client_name => 'auto optimizer stats collection', operation => NULL,
window_name => NULL);

Gathering new statistics

If you enabled the database before you set useoraclestatspreferences to true, you need to delete the existing
schema statistics and gather new statics. The Oracle DBA can use the following SQL commands for this task.

EXEC dbms_stats.delete_schema_stats('CCUSER');
EXEC DBMS_STATS.GATHER_SCHEMA_STATS(ownname=>'CCUSER', options=>'GATHER');

Note: Replace CCUSER with the actual ClaimCenter database user.

After the application upgrade

After you perform an application upgrade with useoraclestatspreferences set to true, there is no longer any
need to run DBStats batch processing. At this point, Oracle AutoTask automatically handles statistics collection
during the maintenance windows defined for the database. To disable DBStats batch processing, remove its schedule
from scheduler-config.xml.

The Database Statistics Element 287

 System Administration Guide 9.0.5

Future application upgrades

For future application upgrades, Guidewire recommends that you consider setting the updatestatistics attribute
on the <upgrade> element in database-config.xml to true, for example:

<upgrade degree-parallel-ddl="6" degree-of-parallelism="6" ora-parallel-dml="enable_all"

updatestatistics="true">

Setting the updatestatistics attribute to true allows the ClaimCenter upgrader to create any additional
histograms required by the new application version.
For more information, refer to the following Oracle documentation:
• Oracle Database Administrator’s Guide, "Managing Automated Database Maintenance Tasks"
• Oracle Database SQL Tuning Guide, "Managing Optimizer Statistics: Basic Topics"

Resetting useoraclestatspreferences
Any change to the useoraclestatspreferences attribute in database-config.xml (from false to true or from
true to false) takes effect only after an upgrade, either a full upgrade or a rolling (configuration) upgrade.
However, if you reset this attribute from true to false, ClaimCenter throws an exception during the next upgrade
and prevents the upgrade from continuing due to locked table statistics in the Oracle database. Review the details of
the exception provided in the server log to determine which table statistics need to be unlocked. See “Revert to
DBStats Batch Processing for Database Statistics” on page 288 for information on how to unlock the table statistics.
See also
• “The Oracle Statistics Preferences Tab” on page 375

Revert to DBStats Batch Processing for Database Statistics

You must perform a sequence of manual steps if you want to revert to using the table statistics preferences set in
database-config.xml rather than using Oracle AutoTask infrastructure to manage the task of collecting table
statistics. Any change to the useoraclestatspreferences attribute in database-config.xml (from false to true
or from true to false) takes effect only after an upgrade, which can be either a full database upgrade or a rolling
configuration update. However, if you attempt to reset this attribute from true to false, ClaimCenter throws an
exception during the next upgrade and prevents the upgrade from continuing due to locked statistics in certain
Oracle database tables. Review the exception log detail to determine which tables statistics need to be unlocked.

Procedure
1. Reset attribute useoraclestatspreferences to false in file database-config.
2. Start the application server in upgrade mode.
The upgrade fails due to locked table statistics in the Oracle database.
3. Review the server log for which table statistics need to be unlocked.
Search for text that is similar to the following:

com.guidewire.pl.system.exception.UpgradeException: The following tables have locked statistics...

4. Unlock the specified table statistics.

The following example code illustrates what SQL commands the BillingCenter database DBA needs to
execute.

SET serverout on timing on

DECLARE
CURSOR locked_tables_cur IS SELECT table_name
FROM user_tab_statistics
WHERE STATTYPE_LOCKED IS NOT NULL;
str VARCHAR2(256);
BEGIN

288 chapter 17 Database Statistics Generation

 System Administration Guide 9.0.5

FOR locked_tables IN locked_tables_cur

LOOP
str:= 'EXEC DBMS_STATS.UNLOCK_TABLE_STATS(USER, ''' || locked_tables.table_name|| ''')' ;
dbms_output.put_line(str);
EXECUTE IMMEDIATE str;
END LOOP;
END;
/

This step is mandatory. Otherwise, the ClaimCenter upgrade fails.

5. Delete the current table statistics preferences. The following example code illustrates what SQL commands
the BillingCenter database DBA needs to execute.

EXEC DBMS_STATS.DELETE_SCHEMA_PREFS('CCUSER', 'NO_INVALIDATE');

EXEC DBMS_STATS.DELETE_SCHEMA_PREFS('CCUSER', 'CASCADE');
EXEC DBMS_STATS.DELETE_SCHEMA_PREFS('CCUSER', 'STALE_PERCENT');
EXEC DBMS_STATS.DELETE_SCHEMA_PREFS('CCUSER', 'ESTIMATE_PERCENT');
EXEC DBMS_STATS.DELETE_SCHEMA_PREFS('CCUSER', 'DEGREE');
EXEC DBMS_STATS.DELETE_SCHEMA_PREFS('CCUSER', 'METHOD_OPT');

Note: Replace CCUSER with the actual ClaimCenter database user.

6. Restart the application server in upgrade mode.
7. After the application upgrade completes, schedule the execution of DBStats batch processing to collect
database table statistics.

The Table Statistics Database Element

The <databasestatistics> element in database-config.xml has one subelement, <tablestatistics>. You use
this element to override database-wide statistics settings defined on the <databasestatistics> element for a
specific table. You can override the databasedegree (Oracle only), samplingpercentage attributes, and statistic
gathering behavior of ClaimCenter. You must provide a name parameter to identify the table for which you want to
set values:

<tablestatistics name="string" samplingpercentage="integer" databasedegree="integer"

action="update|delete|keep|force"/>

By default, ClaimCenter on Oracle does not generate statistics on any table used for processing work items.
ClaimCenter deletes any existing statistics on these tables whenever it updates statistics. You can override this
behavior by using the action attribute of the <tablestatistics> element. You can set the action attribute to one
of the following values:

delete Delete the statistics on the table. This value does nothing in SQL Server.

force Update statistics for this table while running incremental statistics, regardless of the value of attribute incrementalu
pdatethreshold on the <databasestatistics> element.

keep Keep the existing statistics. ClaimCenter does not update statistics for any table for which the user explicitly specifies
keep as the value for the action attribute. This value affects any type of database.

update Update the statistics for the table:

• Full statistics update - Always update
• Incremental statistics update - Update only if the change in table data caused by inserts and deletes exceeds the
value of attribute incrementalupdatethreshold on the databasestatistics> element.

The default value is update.

The <tablestatistics> element is optional. If you do not specify a <tablestatistics> element for a table,
ClaimCenter uses the database-wide statistics defined on the <databasestatistics> element. If you do specify a
<tablestatistics> element, you must also supply a value for the action attribute.

Configuring Database Statistics Generation 289

 System Administration Guide 9.0.5

See also
• “Configuring Database Statistics Generation” on page 284
• “The Database Statistics Element” on page 285
• “The Histogram Statistics Database Element” on page 290

The Histogram Statistics Database Element

The <tablestatistics> element in database-config.xml has several subelements, one of which is the
<histogramstatistics> element. Use this element to specify a column-specific value for the databasedegree
attribute (ignored on SQL Server) and the samplingpercentage attributes. By default, ClaimCenter issues a single
dbms_stats.gather_table_stats(... 'FOR COLUMNS ...') statement for all columns of interest in the table,
including:
• All columns that are the first key column of an index. (Oracle only).
• The retired column, if present.
• The subtype column, if present.
• All columns that have the createhistogram attribute set to true. (Guidewire sets this value internally.)
If you specify non-default values for either the databasedegree or the samplingpercentage on a particular
column, ClaimCenter issues a separate statement for those values alone.
The <histogramstatistics> element has the following format:

<histogramstatistics name="string" numbuckets="integer" />

The name attribute specifies a column name. The numbuckets attribute controls the maximum number of buckets for
the specified histogram. Guidewire requires that you provide a value for this attribute. The default value for the
number of buckets is 254 for the retired and subtype columns. For all other columns, ClaimCenter uses 75, the
database default.

Notes
• For performance reasons, ClaimCenter does not currently create a histogram on publicid columns. These
columns are rarely, if ever, referenced in a WHERE clause.
• Also for performance reasons, ClaimCenter tries to combine as many columns as possible into a single statement.
Certain tabs in the Database Catalog Statistics page display a dbms_stats.gather_table_stats(...'FOR
COLUMNS ...') statement with only the associated column for each histogram, regardless of the parameter
values. This enables you to specify the most granular statement if a given histogram is out of date.
See also
• “Configuring Database Statistics Generation” on page 284
• “The Database Statistics Element” on page 285
• “The Table Statistics Database Element” on page 289

290 chapter 17 Database Statistics Generation

chapter 18

Importing and Exporting

Administrative Data

Guidewire categorizes certain types of application data as administration data. (Guidewire frequently shortens this
tem to just admin data.) For example, activity patterns are administration data. This topic provides information
related to importing administrative data into, and exporting data from, Guidewire ClaimCenter. While users enter
much of the information into ClaimCenter directly, at times, it is more convenient or necessary to enter information
in bulk.

Ways to Import Administrative Data

It is possible to import administrative data into Guidewire ClaimCenter by using the following mechanisms.

Mechanism How Description

ClaimCenter Administration tab Import and export administrative data files in XML format by using functionality
available from the ClaimCenterAdministration tab. The import functionality provides
warnings on collisions between incoming data and existing data and provides a
mechanism for you to resolve the collisions.
For more information, see:
• “Importing and Exporting Administrative Data from ClaimCenter” on page 303
File import import_tools Use the import_tools command prompt tool to import one or more CSV or XML files
ImportToolsAPI containing administrative data. Use this command to import administrative data only.
Guidewire does not support using the import_tools command to import other types
of data.
It is also possible to use the ImportToolsAPI web service to import one or more XML
files containing administrative data.
For more information, see:
• “Import Tools Command” on page 417
• “Using Tools to Import Administrative Data” on page 302
• Integration Guide

Importing and Exporting Administrative Data 291

 System Administration Guide 9.0.5

Mechanism How Description

File load import directory Load data from CSV files contained in the following directory:
configuration→config→import→gen
At initial database upgrade, starting from an empty database, ClaimCenter loads the
administrative data contained in the files in this directory. These files include the
default activity patterns, authority limits, and roles and role privileges.
You can add additional files to this directory for load at initial server startup. For details,
see “About the import Directory” on page 292.
IMPORTANT ClaimCenter loads files from the import→gen directory only if the database
is empty, during the database upgrade at initial server start.
File load Security directory Load security zone data from file security-zones.xml, contained in the following
directory:
configuration→config→Security
For information on the syntax to use with this XML-formatted file, see “Importing
Security Zone Data” on page 309.
IMPORTANT ClaimCenter loads data from file security-zones.xml only if the
database is empty, during the database upgrade at initial server start.
Staging tables table_import Use the table_import command prompt tool to import administrative data from
TableImportAPI staging tables into ClaimCenter database tables. It is also possible to use the TableImpo
rtAPI web service to import administrative data from staging tables into ClaimCenter
database tables.
You can use these tools to import data of any loadable type into the database.
For more information, see:
• “Table Import Command” on page 430
• Integration Guide

IMPORTANT Never modify ClaimCenter operational database tables directly with SQL commands.

About the import Directory

After the initial ClaimCenter installation, the database is empty of data. The first time that you start the ClaimCenter
application server after installation, ClaimCenter upgrades the database and populates it with data. As part of this
initial upgrade, ClaimCenter automatically loads the following administrative data:
• Root group of the user and group tree
• Initial security zone
• Default activity patterns
• Default roles and role permissions (privileges)
ClaimCenter can also import default business rules on initial server startup, depending on the value of configuration
parameter BizRulesImportBootstrapRules.

Administration Data Import at Initial Server Startup

During the initial server startup with an empty database, ClaimCenter uses the data defined in the following files to
load the default activity patterns, roles, and role permissions:
• activity-patterns.csv
• roleprivileges.csv
• roles.csv
These files exist in the following location in Guidewire Studio:
292 chapter 18 Importing and Exporting Administrative Data
 System Administration Guide 9.0.5

configuration→config →import →gen

It is possible to modify but not remove these files. However, at a bare minimum, these files must define the super
user role (superuser) and its privileges in the base configuration. Otherwise, it is not possible to start ClaimCenter
the first time.

Security Zone Data Import at Initial Server Startup

During the initial server startup with an empty database, ClaimCenter loads the security zone data defined in file
security-zones.xml. The use of this file is optional. You cannot use this mechanism to load security zone data
after the initial server startup to populate the database with data.
File security-zones.xml exists in the following directory:
configuration→config →Security
See also
• “Importing Security Zone Data” on page 309

Business Rules Import at Initial Server Startup

During the initial server startup with an empty database, it is possible for ClaimCenter to automatically load
business rules defined in the following location in ClaimCenter Studio:
configuration→config →import →bizrules
Configuration parameter BizRulesImportBootstrapRules controls this behavior:
• If the value of BizRulesImportBootstrapRules parameter is true, ClaimCenter imports the business rules
defined in this location.
• If the value of BizRulesImportBootstrapRules is false, ClaimCenter ignores any business rules in that
location.

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

See also
• “Automatic Import of Business Rules at Server Startup” on page 344
• Configuration Guide

Controlling the Import of Data During Server Startup

During server startup, ClaimCenter examines file importfiles.txt to determine if it lists additional administrative
data files to load. This file exists in the following location in ClaimCenter Studio:
configuration→config →import →gen
In the base configuration, file importfiles.txt contains the name of one file to load, that of authority-
limits.csv.
If you want to load additional administrative data at initial database upgrade, do the following:
1. Place the appropriately formatted CSV files containing the data in the gen folder in Studio.
The file format must be CSV.
2. Add the filename to the list of files in importfiles.txt.
Any file named in importfiles.txt must exist in the gen folder or the database upgrade fails.
ClaimCenter loads the data in sequential order of the files listed in file importfiles.txt.

About the import Directory 293

 System Administration Guide 9.0.5

About Adding Admin Data after Initial Server Startup

In general, it is not possible to import additional administrative data contained in the files in the import→gen
directory after the initial database upgrade. ClaimCenter loads the administrative data contained in the gen folder
only if starting from an empty (non-upgraded) database. Thereafter, ClaimCenter ignores the files in the gen
directory.
There is one exception. It is possible to add the data in file roleprivileges.csv in the gen folder using an
import_tools command option. This command option adds the privileges associated with each ClaimCenter role in
the roleprivileges.csv file to those that already exist in the database.
See also
• “Add Additional Roles and Privileges after Initial Server Startup” on page 294
• “Import Tools Command” on page 417

Add Additional Roles and Privileges after Initial Server Startup

Procedure
1. Ensure that the ClaimCenter server is running.
2. Open a command prompt.
3. Navigate to the following location in the ClaimCenter installation directory:

admin/bin

4. Run the following command to import the data in file roleprivileges.csv in the import→gen folder:

import_tools -password password -privileges

To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.

Next steps
See also
• “Character Set Encoding for File Import” on page 294
• “Import Tools Command” on page 417

Character Set Encoding for File Import

In the base configuration, if you do not supply a value for the import_tools -charset option, ClaimCenter
assumes a character set encoding of UTF-8 for the import file. It is possible that the file that you want to import
contains characters not recognized by the import tools default character encoding.
If this is the case, then you need to set the character set encoding to a more appropriate value. For example, for a file
that contains single-byte data as accented characters or characters with umlauts, a -charset value of ISO-8859-1 is
possibly more appropriate.

294 chapter 18 Importing and Exporting Administrative Data

 System Administration Guide 9.0.5

See also
• “Import Tools Command” on page 417

Maintain Data Integrity During Administrative Data Import

About this task
Some ClaimCenter administrative data has dependencies on business roles. For example, ClaimCenter associates
roles with groups. Therefore, if you export administrative data from one system into another, you must also export
all ClaimCenter roles from the old system and import the roles into the new system.

Procedure
1. Export the ClaimCenter roles.
2. Export the administration data.
3. Import the roles into the new system.
4. Import the administration data into the new system.

Administrative Data and the ClaimCenter Data Model

To import or export data from ClaimCenter, you must understand its data model. In particular, you must understand
how ClaimCenter uses each user interface field and how that use maps to the database. To build this understanding,
review the ClaimCenter Data Dictionary, accessible in the following location in the ClaimCenter installation
directory:

build/dictionary/data/index.html

The Data Dictionary describes the structure of business objects stored persistently by ClaimCenter, and the
dictionary defines the properties and foreign key references for each object. If you change the data model, regenerate
the ClaimCenter Data Dictionary by using the following command:

gwb genDataDictionary

See also
• Configuration Guide

Public ID Prefix
Each entity that you import into ClaimCenter requires a unique public ID. This is separate from the system ID that
ClaimCenter assigns internally and uses for most system processing. Foreign key references between related objects
use this public ID.
Typically, a company imports data from multiple external sources. If you do import data from multiple sources, use
a naming convention to generate public IDs for external sources. For example, if you import from two systems
(Adminsystem and Salessystem), each source can have a contact entity with ID=5432. Thus, Guidewire
recommends that you use the following ID format so that the IDs do not register as duplicates:

origin:ID

By using this format, the contact from the first system comes in as adminsystem:5432 and the contact from the
second system comes in as salessystem:5432. Thus, there is no risk of duplicate IDs. There is also the benefit of
knowing from which system the record originated.

Maintain Data Integrity During Administrative Data Import 295

 System Administration Guide 9.0.5

Public IDs need to be unique only within objects of the same type. For example, all policy objects must have a
different public ID. However, a claim and a policy with the same public ID do not conflict with each other. Public
IDs cannot exceed 20 characters in length.

Support for Unique Public IDs in a Development Environment

During development and testing of a ClaimCenter configuration, multiple developers can create administrative data
in their own ClaimCenter installations. Administrative data includes users, groups, roles and so forth. You combine
this data into a single production database at the end of the development cycle.
If you ever want to transfer data from one database to another with the export and import utilities, the two databases
must have different public ID prefixes. Set the public ID prefix by modifying the value of the following parameter
in config.xml:

<param name="PublicIDPrefix" value="cc"/>

ClaimCenter appends this public ID prefix to each administrative entity created in an individual ClaimCenter
configuration. Thus, the public ID format becomes the following:

{PublicIDPrefix}:{ID}

If you have multiple developers, you must coordinate the public ID prefix so that no public ID prefixes overlap. For
example, each engineer can use their initials or computer names as a public id prefix.
You can use the same prefix for multiple development and testing databases if you do not ever transfer data between
them.

Constructing a CSV File for Import

You can only import data for an entity type that already exists in the Guidewire data model. Each CSV-formatted file
you import must have a heading that defines what the file contains and how to interpret it. The following example
illustrates a very simple import file:

1: ADDRESS
2: type,data-set,entityid,addresstype,addressline1,createuser
3: Address,0,ab:1001,home,1253 Paloma Ave.,import_tools
4: Address,0,ab:1002,business,325 S. Lake Ave.,import_tools

The import_tools command distinguishes between two types of information in an import file:
• Heading information
• Data information.
ClaimCenter treats any line that contains the string entityid as a heading.
ClaimCenter considers as data any line:
• Without an entityid string
• With comma delimited values
• With a value in its third comma-delimited field
In the example shown, the import_tools command treats line 2 as a heading and lines 3 – 4 as data. The
import_tools command ignores line 1. If the command encounters a data line before a heading line, it returns an
error.

296 chapter 18 Importing and Exporting Administrative Data

 System Administration Guide 9.0.5

IMPORTANT Guidewire supports using the import_tools command to import administrative data only.

Constructing a Heading Line in CSV-formatted Files

Every CSV-formatted file that you import into ClaimCenter must have a heading line. The heading line initializes
the import for a particular entity object in the data model. A heading consists of comma-separated fields. The first
three fields must be, in order:
• type
• data-set
• entityid
All subsequent fields must refer to columns, typelists, foreign keys, and joinarrays on the entity.
For example, a file importing into the Address entity has a heading that appears as:

type,data-set,entityid,addresstype,addressline1,createuser

The following fields follow the three required fields (type, data-set, and entityid):
• addresstype – Represents a typelist
• addressline1 – Represents a column
You do not have to specify all fields in the entity within the import file. You must specify at least the required fields.
You can determine which fields ClaimCenter requires by viewing the entity description in the ClaimCenter Data
Dictionary.
Use lowercase to specify fields, including arrays. In this example, specify AddressLine1 in the data model as
addressline1 in the import file.
To specify a foreign key, use the foreign key name without the concluding ID. In this example of a Person import:

1: type,data-set,entityid,firstname,lastname,primaryaddress,workphone,primaryphone,
taxid,vendortype,specialtytype
2: Person,0,demo_sample:1,Ray,Newton,demo_sample:4000,818-446-1206,work,,,
3: Person,0,demo_sample:2,Stan,Newton,demo_sample:4002,818-446-1206,work,,,
4: Person,0,demo_sample:3,Harry,Shapiro,demo_sample:1004,818-252-2546,work,,,
5: Person,0,demo_sample:4,Bo,Simpson,demo_sample:1003,619-275-2346,work,,,
6: Person,0,demo_sample:5,Jane,Collins,demo_sample:4003,213-457-6378,work,,,
7: Person,0,demo_sample:6,John,Dempsey,demo_sample:1006,213-475-9465,work,,,

The primaryaddress field is a foreign key to the Address entity. It appears as PrimaryAddressID in the
ClaimCenter Data Dictionary but as primaryaddress in the import data.
If you specify a field in the heading that is not a recognizable column, typelist, foreign key or array, the import
program silently ignores the column and any associated data. In the following example, the import ignores the %$zed
heading field and the somedata value in line 3:

1: ADDRESS
2: type,data-set,entityid,addresstype,addressline1,createuser, %$zed
3: Address,0,ab:1001,home,1253 Paloma Ave.,import_tools, somedata
4: Address,0,ab:1002,business,325 S. Lake Ave.,import_tools,

Constructing Data Lines in CSV-formatted Files

Every CSV-formatted file that you import into ClaimCenter must have a heading line, followed by one or more data
lines. The import_tool identifies data lines by scanning the file for lines with the following characteristics:
• The line does not contain the three required heading fields.
• The line contains comma-delimited values.
• The line contains a third field that is non-empty.

Constructing a CSV File for Import 297

 System Administration Guide 9.0.5

Each data line represents a single instance of a data model entity.

Data Line - Field 1

The first field in any data line must be an entity name or an entity subtype name.

1: Policy
2: type,data-set,entityid,account,corepolicynumber,policytype,producttype,productversion,
systemofrecorddate,,,,,,,,,,,
3: Policy,0,ds:1,ds:1,34-123436-CORE,wc,wc_workerscomp,1,1/1/2002,,,,,,,,,,,
4: Policy,0,ds:2,ds:1,25-123436-CORE,bop,bop_businessowners,1,1/1/2002,,,,,,,,,,,
5: Policy,0,ds:3,ds:3,54-123456-CORE,personalauto,pa_personalauto,1,1/1/2002,,,,,,,,,,,
6: Policy,0,ds:4,ds:4,25-708090-CORE,bop,bop_businessowners,1,1/1/2002,,,,,,,,,,,
7: Policy,0,ds:5,ds:2,98-456789-CORE,bop,bop_businessowners,1,1/1/2002,,,,,,,,,,,
8: Policy,0,ds:6,ds:1,20-123436-CORE,businessauto,ba_businessauto,1,1/1/2002,,,,,,,,,,,
9: Policy,0,ds:7,ds:1,50-123436-CORE,umbrella,u_umbrella,1,1/1/2002,,,,,,,,,,,
...

In lines 3 - 9, the entity name Policy appears in the first field as required. The capitalization of an entity or subtype
name must be identical to that used in the ClaimCenter Data Dictionary. For example, to create a RevisionAnswer
data line the entry name would be invalid if you specified it as revisionanswer.

Data Line - Field 2

The second field in a data line is the value of the highest-numbered data-set of which the imported object is part.

2: type,data-set,entityid,account,corepolicynumber,policytype,producttype,productversion,
systemofrecorddate,,,,,,,,,,,
3: Policy,0,ds:1,ds:1,34-123436-CORE,wc,wc_workerscomp,1,1/1/2002,,,,,,,,,,,

ClaimCenter orders data-sets 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. It is possible to request a particular data-set while converting CSV to XML. By default,
ClaimCenter requests data-set 10240. ClaimCenter assumes that data-set 10240 includes every data-set that it is
possible to create.
You can leave the second field blank, in which case ClaimCenter always includes this object in the import regardless
of the requested data-set.

Data Line - Field 3

The third field in any data line must be the public ID for that particular data object. This field is mandatory. For
example, ds:2 is the public ID of the Policy on line 4.

Foreign Key and Column Data

The import_tools command imports both column and typelist data values from the CSV file. In the previous
example, the policytype column has a value of wc in line 3 and a value of bop in line 4. You represent foreign key
data by a string in one of two formats:
publicID
or
entity_id:identity_source
If there is more than one : (colon), the import ignores everything after the second : (colon).

1 ADDRESS
2 type,data-set,entityid,addresstype,addressline1,createuser
3 Address,0,ab:1001,home,1253 Paloma Ave.,import_tools
4 Address,0,ab:1002,business,325 S. Lake Ave.,import_tools
6
7 PERSON
8 type,data-set,entityid,firstname,lastname,primaryaddress,inaddressbook,loadrelatedcontacts,
referred,contactaddresses
9 Person,0,ab:2001,John,Foo,ab:1002,true,true,true,ContactAddress|address[ab:10001,ab:1002]

298 chapter 18 Importing and Exporting Administrative Data

 System Administration Guide 9.0.5

10 Person,0,ab:2002,Paul,Bar,ab:1002,false,false,false,ContactAddress|address[ab:10001]
11 Person,0,ab:2003,David,Goo,,false,true,false,,

In the previous example, the primaryaddress on line 9 is a foreign key to the Address specified on line 4.
If ClaimCenter cannot resolve a foreign key reference and does not require the foreign key, ClaimCenter imports the
data, sets the foreign key field to null, and reports an error. If ClaimCenter does require the foreign key, then
ClaimCenter reports an error and does not import that data.

Simple Array Data

You specify simple array data, referencing a single foreign key by using the following format:

arraykey|foreignkey[publicID,publicID,...]

In the PERSON example (line 9), the arraykey value is the array key on the parent entity (Person). The foreignkey
is the foreign key name of the array without the ID. ContactAddress is the array key and address is the foreign key
name. The public ID values [publicID,publicID,...] correspond to public IDs that are referenced by the foreign
key.
In this format, the arraykey is optional. However, you might want to retain it for readability.

Complex Array Data

You might need to specify more complex arrays that have a mixture of data types. If you specify arrays that contain
a mixture of columns, foreign key data, or typelists, use a different format. The basic format of these complex array
entries appear as follows:

[ [array_entry];[array_entry]; ...]

Enclose each array_entry in brackets. Separate multiple entries with semicolons. Enclose all completed entries in a
second set of brackets. Each array_entry is made up of comma-separated [type|value] pairs as follows:

[[[type|value],[type|value]];[[type|value],[type|value]]]

The type is the name of a column, typelist, or foreign key, as in a heading line. The value is the column value,
typelist typecode, or a foreign key. In the following sample, there are three array_entry specifications, the first
and last array_entry specifications appear in bold:

Group
type,data-set,entityid,users
Group,0,demo_sample:27,[[[user|demo_sample:101],
[loadfactor|50],[loadfactortype|loadfactorview]];[[user|demo_sample:102],
[loadfactor|100],[loadfactortype|loadfactoradmin]];
[[user|demo_sample:103],[loadfactor|50],[loadfactortype|loadfactorview]]]

Construct an XML File for Import

About this task
To create a properly formatted XML file of administrative data for import, Guidewire recommends that you perform
the following sequence of steps:

Procedure
1. First, export the current administrative data as an XML file by using the functionality available on the Export
Data screen available to ClaimCenter administrators. This screen provides the ability to export various types of
administrative data in XML format.

Construct an XML File for Import 299

 System Administration Guide 9.0.5

2. Modify the file to suit your business needs, carefully preserving the XML formatting for administrative data.
3. Regenerate the XSD files by using the following command in the ClaimCenter installation directory:

gwb genImportAdminDataXsd

It is important to regenerate the XSD files every time that you modify the data model.
4. Re-import the modified file by using either the import_tools command or the Export Data screen available to
ClaimCenter administrators. This screen provides the ability to import administrative data in XML format into
ClaimCenter.

Next steps
See also
• “Importing and Exporting Administrative Data from ClaimCenter” on page 303
• “Constructing the XML for the Administrative Data Import File” on page 300
• “Import Tools Command” on page 417

Constructing the XML for the Administrative Data Import File

The ClaimCenter/build/xsd/cc_import.xsd file defines the XML schema used for import and export of
administrative data. This file further references information in two other XSD files in the same directory:
• cc_entities.xsd
• cc_typelists.xsd
You can use any schema-aware XML editor to help format information properly according to these XSD definitions.
You generate these XSD files by entering the following command in a command prompt open in the ClaimCenter
installation folder:

gwb genImportAdminDataXsd

Regenerate the XSD files any time you modify the data model. These files are likely to change as you configure the
data model.
The following XML example shows the default activity pattern 30 Day Diary from the ClaimCenter administrative
export file.

<?xml version="1.0"?>
<import xmlns="http://guidewire.com/pc/exim/import" version="p5.86.a12.309.46"
usePeriodicFlushes="true">
<ActivityPattern public-id="sample_pattern:19">
<ActivityClass>task</ActivityClass>
<AutomatedOnly>false</AutomatedOnly>
<Category>reminder</Category>
<Code>30_day_diary</Code>
<Command/>
<Description/>
<Description_L10N_ARRAY/>
<DocumentTemplate/>
<EmailTemplate/>
<EscBusCalLocPath/>
<EscalationBusCalTag/>
<EscalationDays/>
<EscalationHours/>
<EscalationInclDays/>
<EscalationStartPt/>
<Mandatory>false</Mandatory>
<PatternLevel>All</PatternLevel>
<Priority>normal</Priority>
<Recurring>true</Recurring>
<ShortSubject/>
<ShortSubject_L10N_ARRAY/>
<Subject>30 day diary</Subject>

300 chapter 18 Importing and Exporting Administrative Data

 System Administration Guide 9.0.5

<Subject_L10N_ARRAY/>
<TargetBusCalLocPath/>
<TargetBusCalTag/>
<TargetDays>30</TargetDays>
<TargetHours/>
<TargetIncludeDays>elapsed</TargetIncludeDays>
<TargetStartPoint>activitycreation</TargetStartPoint>
<Type>general</Type>
</ActivityPattern>
</import>

You can:
• Modify any existing entry in the administrative export file and re-import the file.
• Add additional entries by using the existing entries as a model and re-import the file.

Foreign Key References

Within an XML-formatted administrative data import file, it is common to have references between objects in the
file. For example, a user object can reference the group of which it is a member. As the group definition is elsewhere
in the XML file, or perhaps the definition exists elsewhere, the user definition refers to this group with a foreign key.
The foreign key is the object’s public ID. For example, the XML file can contain:

<User publicID="demo_sample:100"> … </User>

…
<Group publicID="demo_sample:200">
…
<Users>
<GroupUser>
<User publicID="demo_sample:100" />
…
</GroupUser>
</Users>
</Group>

In this example, the user demo_sample:100 is a member of group demo_sample:200.

It is possible to reference an item within a single XML file before you define the item. For example, you can refer to
supervisor of a user before you define the supervisor in the file. This enables you to define all groups first.
ClaimCenter reports errors only if a referenced object still does not exist after reading the entire file.

Validating the Import XSD File

It is important to regenerate the ClaimCenter XSD files after you modify the data model. These files are likely to
change as you configure the data model. You generate these XSD files by opening a command prompt in the
ClaimCenter installation directory and entering the following command:

gwb genImportAdminDataXsd

You can validate the XML of your import file against a cc_import.xsd file by using the following code:

uses java.io.File
uses java.io.FileInputStream
uses javax.xml.validation.SchemaFactory
uses javax.xml.XMLConstants
uses javax.xml.parsers.SAXParserFactory
uses org.xml.sax.helpers.DefaultHandler
uses gw.testharness.TestBase

// Provide the correct directory of the cc_import.xsd

var schemaFile = new File("cc_import.xsd")
TestBase.assertTrue(schemaFile + " Should exists", schemaFile.exists());
var factory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
var schema = factory.newSchema(schemaFile)
var spf = SAXParserFactory.newInstance()
spf.setSchema(schema)
spf.Validating = true

Constructing the XML for the Administrative Data Import File 301
 System Administration Guide 9.0.5

spf.NamespaceAware = true
var parser = spf.newSAXParser();
var fis = new FileInputStream("myImportFile.xml")
parser.parse(fis, new DefaultHandler())

Using Tools to Import Administrative Data

Guidewire provides the import_tools command for importing new or updated administrative data into existing
tables in the ClaimCenter database. ClaimCenter reads the import data from a comma-separated values (CSV) file or
an XML file.

IMPORTANT ClaimCenter supports this command for importing administrative data, but not for importing other
types of data. Instead, use staging tables or APIs other than the ImportToolsAPI API to import non-administrative
types of data into ClaimCenter.

ClaimCenter uses the public ID of each object in the data import to determine if an object with that public ID
already exists in the database. See “Administrative Data and the ClaimCenter Data Model” on page 295 for a
discussion of public IDs
During import, if ClaimCenter finds a match in entity public IDs, it does the following:
• If there is no difference between the import record and the database record, ClaimCenter ignores the import
record.
• If there are differences between the two records, ClaimCenter overwrites any existing database record values
with the values from the import file. ClaimCenter does not throw concurrent data change exception if the
imported records overwrite existing records in the database.
• If there are null entries for a record in the import file, ClaimCenter nulls out those values in the record in the
database.

IMPORTANT Guidewire supports using the import_tools command to import administrative data only.

See also
• “Import Tools Command” on page 417

Import Administrative Data Using Import Tools

Before you begin
The MaximumFileUploadSize parameter in file config.xml must be larger than the size of any file that you attempt
to import. The MaximumFileUploadSize parameter value is in megabytes (MB). In the base configuration, the
default value of MaximumFileUploadSize is 20 MB.

Procedure
1. Create a CSV or XML file describing the data, by using one of the following methods:
• Create the XML or CSV file manually.
• Export the current administrative data as an XML file from ClaimCenter and modify the file.
2. Import the CSV or XML file by using the import_tools command:

import_tools -password password -import fileName

To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.

302 chapter 18 Importing and Exporting Administrative Data

 System Administration Guide 9.0.5

The -import option requires that you provide the name of the file to import (fileName). There are a number
of other options that you can set as well.

Next steps
See also
• “Constructing a CSV File for Import” on page 296
• “Construct an XML File for Import” on page 299
• “Import Tools Command” on page 417

Importing and Exporting Administrative Data from ClaimCenter

You can import and export administrative data directly from ClaimCenter by using functionality that is available to
ClaimCenter administrators. It is only possible to import and export XML-formatted administrative data through the
ClaimCenter interface.

About Importing ClaimCenter Administrative Data

You can import administrative data directly from within ClaimCenter by using the Import Data screen available to
ClaimCenter administrators. To access this screen, navigate to the following location in ClaimCenter:
Administration→Utilities→Import Data
You can import XML-formatted administrative data only.
During the import, ClaimCenter looks for existing data objects that have public IDs that match those of the data
objects being imported. ClaimCenter notifies you if it determines there are public ID matches. You can then chose to
do one of the following:
• Overwrite all existing data with the imported data
• Discard updates to any existing data and keep the existing data
• Interactively resolve each data conflict on a case-by-case basis

Importing Arrays
ClaimCenter handles arrays differently depending on whether it is importing an owned array or a virtual array:
• Owned array – If an entity owns the array, ClaimCenter notifies you of the differences between the imported
data and any existing data. However, you do not have the choice of resolving the array elements. ClaimCenter
only gives you the option to delete the current array and replace all of the contents of the imported array.
• Virtual array – It is not possible replace the contents of a virtual array with those of an imported array as it is
not possible to delete a virtual array.

Import Administrative Data into ClaimCenter

Procedure
1. Log into Guidewire ClaimCenter as a user with the viewadmin and soapadmin permissions.
2. Select the Administration tab.
3. In the left-hand navigation pane, expand Utilities→Import Data.
4. Click Browse... to search for the XML file containing data to import.
5. Click Finish to import data from the file.

Importing and Exporting Administrative Data from ClaimCenter 303

 System Administration Guide 9.0.5

Next steps
During an import, ClaimCenter does not run validation rules. However ClaimCenter does run pre-update rules. For
this reason, run user exception and group exception batch processing after you import administrative data.

About Exporting ClaimCenter Administrative Data

You can export administrative data directly from within ClaimCenter by using the Export Data screen available to
ClaimCenter administrators. To access this screen, navigate to the following location in ClaimCenter:
Administration→Utilities→Export Data
It is possible to export the following data sets independently:
• Admin
• Authority Limit Profiles
• Business Weeks
• Catastrophes
• Coverage Verifications
• Exchange Rates
• Holidays
• ICD Codes
• Large Loss Thresholds
• Metric Limits
• Questions
• Regions
• Reinsurance Thresholds
• Roles (contains role privileges as well)
• Service Metric Limits
• Special Handling
• Users and Groups
• Vendor Service Details
• Vendor Service Tree
• Workload Classifications

IMPORTANT If a particular data set is not on the export list, you cannot export it by using this function.

During export or import of users and groups, ClaimCenter also exports or imports any entities referred to by any
User or UserRole object through a foreign key or array.
You can export XML-formatted administrative data only.

Export Administrative Data from ClaimCenter

Procedure
1. Log into Guidewire ClaimCenter as a user with the viewadmin and soapadmin permissions.
2. Select the Administration tab.
3. In the left-hand navigation pane, expand Utilities→Export Data.
4. Select the data set to export.
5. Click Export to download the XML file.

304 chapter 18 Importing and Exporting Administrative Data

 System Administration Guide 9.0.5

Understanding Roles and Permissions

A permission (or privilege) is a granular task or ability to see or do something within ClaimCenter. A role is a
named collection of permissions, and, typically, maps to a job function or job title.
ClaimCenter stores role information in file roles.csv and permission information in file roleprivileges.csv.
Within Guidewire Studio Project window, these two files exist in the following location:
configuration→config→import→gen
ClaimCenter loads the contents of these two files into the database upon initial database upgrade, at first server
startup after installation. See “About the import Directory” on page 292 for details on how ClaimCenter works with
the files in the gen directory.
See also
• “About Adding Admin Data after Initial Server Startup” on page 294
• Application Guide

Role Definitions
File roles.csv contains a list of ClaimCenter roles, along with a human-readable name and description for each
role. Within this file, set the name and description fields to whatever is useful in uniquely identifying the role.
ClaimCenter reads the file, starting with the first row that contains the entityid identifier and imports the data into
the database.
The following code samples are examples of role definition entries:

Roles,
type,data-set,entityid,description,name,carrierinternalrole,roletype
Role,0,superuser,Superuser with full permissions,Superuser,true,user
Role,0,underwriter_supervisor,Base permissions for a supervisor,Underwriting Supervisor,true,user
Role,0,underwriter,Permissions for underwriter,Underwriter,true,user
Role,0,underwriter_asst,Permissions for underwriter assistant,Underwriter Assistant,true,user
Role,0,processor,Permissions for processor,Processor,true,user
,,,,,,

Role Permission Definitions

File roleprivileges.csv contains the mappings that link roles to a set of permissions. ClaimCenter reads the file
starting with the first row that contains the entityid identifier and imports the data into the database.
The following code samples are examples of permission definition entries:

type,data-set,entityid,permission,role
RolePrivilege,0,default_data:2,abview,adjuster
RolePrivilege,0,default_data:3,abviewsearch,adjuster
RolePrivilege,0,default_data:4,actcreate,adjuster
RolePrivilege,0,default_data:5,actcreateclsd,adjuster
RolePrivilege,0,default_data:6,actown,adjuster
RolePrivilege,0,default_data:7,actqueuenext,adjuster
,,,,

Each row in file roleprivileges.csv maps a single permission to a role. Each role has multiple permissions and
thus multiple rows. For example, the abview entry grants permission to view the address book to the adjuster role.
The ClaimCenter Security Dictionary provides a full list of role permission, along with a brief description of each. It
also provides a list of the correspondences between roles and permissions.

Understanding Roles and Permissions 305

 System Administration Guide 9.0.5

Understanding Authority Limits and Authority Limit Profiles

An authority limit profile is a named collection of authority limits. An authority limit provides limits or restrictions
on the types of transactions a user can make. It can also determine whether these new transactions require approval
from someone with greater authority.
ClaimCenter stores information on authority limits and authority limit profiles in file authority-limits.csv.
Within Guidewire Studio, this file exists in the following location:
configuration→config→import→gen
ClaimCenter loads the contents of this file into the database upon initial database upgrade, at first server startup after
installation. See “About the import Directory” on page 292 for details on how ClaimCenter works with the files in
the gen directory.

IMPORTANT It is not possible to add additional administrative data through this mechanism after the initial
database upgrade. ClaimCenter loads the administrative data contained in the gen folder only if starting from an
empty (non-upgraded) database.

See also
• “Ways to Import Administrative Data” on page 291
• Application Guide

The Authority Limit Definition File

File authority-limits.csv consists of two sets of data:
• AuthorityLimitProfile rows
• AuthorityLimit rows
Each authority limit profile definition contains a human-readable name and description for each role. Within the
profile definition, set the name and description fields to whatever is useful in uniquely identifying the profile.
In authority-limits.csv:
• ClaimCenter reads the file, starting with the first row that contains an entityid identifier and imports that data
into the database as profile data.
• ClaimCenter continues reading the file until finding the second entityid identifier, at which point, ClaimCenter
imports the remaining data into the database as authority limit data.
For example:

Authority Limit Profiles,,,,,,,,,

type,data-set,entityid,name,description,,,,,
AuthorityLimitProfile,0,default_data:1,Adjuster,Adjuster default authority,,,,,
AuthorityLimitProfile,0,default_data:2,Claims Supervisor,Claims supervisor default authority,,,,,
AuthorityLimitProfile,0,default_data:3,Regional Supervisor,Regional supervisor default authority,,,,,
type,data-set,entityid,user,profile,claim,limittype,coveragetype,costtype,limitamount

AuthorityLimit,0,default_data:1,,default_data:1,,ctr,,,15000
AuthorityLimit,0,default_data:2,,default_data:1,,cptd,,,15000
AuthorityLimit,0,default_data:4,,default_data:2,,ctr,,,25000
AuthorityLimit,0,default_data:5,,default_data:2,,cptd,,,25000
AuthorityLimit,0,default_data:7,,default_data:3,,ctr,,,100000
AuthorityLimit,0,default_data:8,,default_data:3,,cptd,,,100000
...

The definitions in this example give the Adjuster profile (default_data:1) a $15,000 limit for total claim total
reserves (ctr) for general liability coverage.
Consult the ClaimCenter Data Dictionary for information on the AuthorityLimitType typelist, which contains the
possible limit type codes (for example, ctr). The costtype and coveragetype fields similarly contain code values.
You need not specify a costtype or coveragetype. You can, as these samples illustrate, simply leave these value
empty.
306 chapter 18 Importing and Exporting Administrative Data
 System Administration Guide 9.0.5

Importing Additional ICD Codes

ClaimCenter includes ICD-10-CM (International Classification of Diseases, Tenth Revision, Clinical Modification)
codes as reference data in file icd10_2013.xml. You can find this file in the following location in the Studio Project
window:
configuration→config→referencedata
The U.S. Centers for Disease Control and Prevention releases a revised set of codes annually. You can access the
latest set of ICD codes directly from the CDC website:

http://www.cdc.gov/nchs/icd/icd10cm.htm

To import new ICD codes, do one of the following:

• Use the XML-formatted file available from the CDC to import new ICD codes directly into ClaimCenter.
• Use the “Import New ICD Codes” on page 307 procedure to convert codes in PDF format to CSV format,
suitable for importing into ClaimCenter.
Note: You need Adobe Acrobat Professional or a similar application to save PDF files in a different format.
See also
• Application Guide

Import New ICD Codes

About this task
The Centers for Medicare and Medicaid Services (CMS) agency of the U.S. Department of Health and Human
Services (HHS) provides lists of the invalid, updated, and new ICD codes in separate PDF files from their website:

http://www.cms.hhs.gov/icd9ProviderDiagnosticCodes/07_summarytables.asp

Procedure
1. Open the PDF file of new codes.
2. If using Adobe Acrobat Professional, export the file to RTF (Rich Text Format). Alternatively, you can copy
the data into an RTF, page by page.
3. You may want to convert all the text to uppercase so that the data looks consistent with older codes. However,
this step is optional.
4. Copy the tables from the RTF into Microsoft Excel.
5. Set the code column to text data type, otherwise ClaimCenter truncates all leading and trailing zeros.
6. The column format needs to be as follows to load correctly into the ICDCode table:

type,data-set,entityid,bodysystem,code,codedesc,chronic,expirydate,availabilitydate

7. Use the following values:

Key Value
type ICDCode

data-set 0

entityid icd:xxxx
This is the unique ID for the table. Check the last row in the existing ICD CSV in ClaimCenter/ cc/
config/referencedata and increment by 1 for each row. You can use the Microsoft Excel auto-
increment functionality to create entity IDs beyond the first one.

Importing Additional ICD Codes 307

 System Administration Guide 9.0.5

Key Value
bodysystem Add the numeric value that corresponds to the range the ICD code falls into. Review the ICDBodySy
stem typelist for code ranges.

code Information from the CMS website.

codedesc Information from the CMS website.
chronic Leave blank.
expirydate Leave blank.
availabilitydate Add the date on which the code became available, such as 10/1/2015. Replicate for all rows of
data.

8. Save this worksheet as a CSV file in ClaimCenter/configuration/config/referencedata.

9. Open a command prompt to ClaimCenter/admin/bin.
10. Run the following command to import the CSV file.

import_tools -password password -import ClaimCenter/configuration/config/referencedata/fileName

You must supply a password (for the logon user). Enter the file name of the file to import (fileName).

Update ICD Code Descriptions

About this task
Use the following procedure to update revised diagnosis code titles directly in Guidewire ClaimCenter.

Procedure
1. Open the PDF file of revised diagnosis code titles. ClaimCenter stores the code title as the diagnosis
description.
2. Log in to ClaimCenter as a user with the following permissions:
• View Admin
• View reference data
• Edit reference data
3. Navigate to the Administration tab.
4. Click Business Settings→ICD Codes.
5. For each code listed in the PDF, enter the code in the Code field.
6. Click Search.
7. Click the ICD Code value.
8. Click Edit.
9. Copy the description from the PDF and paste it into the Description field in ClaimCenter.
10. Click Update.
11. Repeat steps 5 through 11 until you have reached the end of the PDF.

Expire Invalid ICD Codes

About this task
Use the following procedure to expire (retire) invalid ICD codes directly in Guidewire ClaimCenter.

308 chapter 18 Importing and Exporting Administrative Data

 System Administration Guide 9.0.5

Procedure
1. Open the PDF file of invalid diagnosis codes.
2. Log in to ClaimCenter as a user with permissions View Admin, View reference data, and Edit reference data.
3. Click the Administration tab.
4. Click Business Settings→ICD Codes.
5. For each code listed in the PDF, enter the code in the Code field.
6. Click Search.
7. Click the ICD Code value.
8. Click Edit.
9. Set the Expires On date.
10. Click Update.
11. Repeat steps 5 through 10 until you have reached the end of the PDF.

Importing Security Zone Data

In the base default configuration, Guidewire provides a single security zone named Default Security Zone.
ClaimCenter imports this default security zone as part of the administration data import into an empty database at
initial server startup.
It is possible to add additional security zones to ClaimCenter in the following ways.

Security Zones screen Define new security zones using the Security Zones screen in the ClaimCenterAdministration tab. See
the Application Guide for details.
File security-zones.xml Define additional security zones in file security-zones.xml. ClaimCenter loads this data as part of
the administration data load into an empty database at initial server startup. See “Understanding
the Security Zones File” on page 309 for more information.
Export/import of data Import new security zone data using the export and import functionality accessible in the
ClaimCenterAdministration tab. See “Import Security Zones” on page 310 for more information.

Understanding the Security Zones File

Besides importing the default security zone at initial server startup, ClaimCenter also loads any additional security
zone data defined in file security-zones.xml. The use of this file is optional. You cannot use this mechanism to
load security zone data after the initial server startup populates the database with data.
You access file security-config.xml in Guidewire Studio Project window, in the following location:
configuration→config→Security
In the base configuration, file security-zones.xml provides only the top-level <import> XML element. To be
useful, you must add one or more <SecurityZone> subelements. There is no limit to the number of
<SecurityZone> elements that can exist in security-zone.xml.
The <SecurityZone> element has the following syntax.

<SecurityZone public-id="… ">

<Description>Some meaningful description…</Description>
<Name>Some meaningful name…</Name>
</SecurityZone>

The attributes and subelements of <SecurityZone> have the following meanings.

Importing Security Zone Data 309

 System Administration Guide 9.0.5

Element Attribute Required Description

SecurityZone public-id Yes Internal identifier for the security zone. Guidewire recommends that you make the
value of this attribute meaningful for your organization. See “Public ID Prefix” on page
295 for more information on public IDs.
Name Yes External-facing name for the security zone. This name is visible in the ClaimCenter user
interface.
Description No Description of the security zone, which, if provided, is externally facing in the
ClaimCenter user interface.

See also
• For information on ClaimCenter import of administration data at initial server startup, see “About the import
Directory” on page 292.

View the XSD for Security Zones

About this task
There is no separate XSD for security-zones.xml. Instead, view the relevant XSD information in the generated
cc_entities.xsd file.

Procedure
1. Open a command prompt and navigate to the ClaimCenter installation directory
2. Run the following command:

gwb genImportAdminDataXsd

3. In the file system, navigate to the following location in the ClaimCenter installation directory:

build/xsd

4. Open file cc_entities.xsd.

5. Search for SecurityZoneXSDType.

Import Security Zones

Procedure
1. Within Guidewire ClaimCenter, navigate to the following location:
Administration→Utilities→Export Data
2. Select Admin from the Data to Export drop-down list, then click Export.
3. Open the resulting file (admin.xml) for editing.
4. Review the file for existing security zones (<SecurityZone public-id="...">).
Pay particular attention to the public-id value for each existing security zone. Any security zone that you
add to this file must have a unique public-id value. See “Public ID Prefix” on page 295 for more information
on public IDs.
5. Add unique entries for each security zone to import.
For example:

<SecurityZone public-id="cc:236">
<Description>Some meaningful description…</Description>

310 chapter 18 Importing and Exporting Administrative Data

 System Administration Guide 9.0.5

<Name>Some meaningful name…</Name>

</SecurityZone>

This example sets the public-id value to cc:236. Chose a public ID value that makes business sense for your
organization.
6. After saving the file, navigate to the following location in ClaimCenter:
Administration→Utilities→Import Data
7. Browse to find your modified file and click Next.
If there are conflicts between the administrative data in the import file and the existing administrative data,
ClaimCenter provides a mechanism for conflict resolution. You can chose to do one of the following:
• Overwrite all existing data with the imported data
• Discard updates to any existing data and keep the existing data
• Interactively resolve each data conflict on a case-by-case basis
8. After resolving all data conflicts, click Finish.

Result
You can now view and use the updated set of security zones in the Administration Security Zones screen without server
restart.

Next steps
See also
• “Construct an XML File for Import” on page 299
• “About Exporting ClaimCenter Administrative Data” on page 304
• “About Importing ClaimCenter Administrative Data ” on page 303

About Importing Zone Data

ClaimCenter provides a collection of zone data files for various localities with small sets of zone data that you can
load for development and testing purposes. The zone data files are in the following location in the Studio Project
window.
configuration→config→geodata
Within the geodata folder, ClaimCenter stores the zone information in country-specific zone-config.xml files, with
each file in its own specific country folder. For example, the zone-config.xml file that configures address-related
information in Australia is in the following location in the Studio Project window.
configuration→config→geodata→AU
Guidewire provides the US-Locations.txt and similar files for testing purposes to support autofill and
autocomplete when users enter addresses. This data is provided on an as-is basis regarding data content. For
example, the provided zone data files are not complete and may not include recent changes.
Also, the formatting of individual data items in these files might not conform to your internal standards or the
standards of third-party vendors that you use. For example, the names of streets and cities are formatted with mixed
case letters but your standards may require all upper case letters.
The US-Locations.txt file contains information that does not conform to United States Postal Service (USPS)
standards for bulk mailings. You can edit the US-Locations.txt file to conform to your particular address
standards, and then import that version of the file.

About Importing Zone Data 311

 System Administration Guide 9.0.5

Importing a Zone Data File

To import zone data, use the zone_import command. The zone_import command imports data in CSV format from
specified files into database staging tables for zone data. It is only possible to import zone data for a single country
at a time. The zone data files that you import must contain zone data for a single country only. To load zone data for
multiple countries, use the command multiple times with different, country-specific zone data files each time.
After you use the zone_import command to import zone data, set the ClaimCenter server run level to MAINTENANCE.
Then, move the data from the staging tables to the production tables by using the table_import command. See
“Table Import Command” on page 430 for more information on the table_import command. Finally, set the
ClaimCenter server run level back to MULTIUSER.
Guidewire expects that you import address zone data upon first installing ClaimCenter, and then at infrequent
intervals thereafter as you receive data updates.

Import a Zone Data File

Procedure
1. Start the ClaimCenter server.
2. Clear the zone data staging tables.
If you have multiple countries defined, you can include the -country countryCode option to clear staging
zone data only for the country you want to load:
zone_import -password password -clearstaging [-country countrycode]
To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.
3. Load the zone data file into the staging tables:
zone_import -password password -country countrycode -import filename
4. Clear existing zone data in production. Perform this step if zone data already exists for the country whose data
you intend to load.
zone_import -password password [-country countrycode] -clearproduction
5. Set the ClaimCenter server run level to MAINTENANCE:
system_tools -password password -maintenance
6. Load zone data from the staging tables into production:
table_import -server url -password password -integritycheckandload -zonedataonly
7. Set the server run level back to MULTIUSER:
system_tools -password password -multiuser

Next steps
See also
• For information on using the zone_import command, see “Zone Import Command” on page 434.
• For information on using the table_import command, see “Table Import Command” on page 430.
• For more information on database staging tables, see the Integration Guide.
• For information on the web service ZoneImportAPI that also imports zone data, see the Integration Guide.

Importing Custom Zone Data Files

You can create your own zone data files, in CSV format. The import tool uses configuration information from zone-
config.xml files for specific countries to determine which data fields to import and what each field represents for

312 chapter 18 Importing and Exporting Administrative Data

 System Administration Guide 9.0.5

each country. ClaimCenter stores the zone-config.xml files for base-configuration countries in country-specific
folders. Navigate to the following location in the Studio Project window to view these files:
configuration→config→geodata
For example, Guidewire provides zone configuration data for France in file zone-config.xml in the following
location:
configuration→config→geodata→FR
Each country-specific zone-config.xml file must have a single top-level <Zones> element for that country.
Underneath each <Zones> element are <Zone> elements that define the zone fields to import from zone data files for
that country. For each field, the fileColumn attribute indicates the position of the field within lines of the files.
The following example XML code from a zone-config.xml file defines the fields to import from zone data files for
the United States. The example code specifies for United States zone data files that the third field in the comma-
separated values of each line of corresponds to a city.

<Zones countryCode="US">
...
<Zone code="city" fileColumn="3" granularity="2">
...

See also
• For complete information about zone-config.xml, including a description of its XML elements and attributes,
see the Globalization Guide.

About Importing Zone Data 313

 System Administration Guide 9.0.5

314 chapter 18 Importing and Exporting Administrative Data

chapter 19

Free-text Batch Load Command

The free-text batch load command loads the Guidewire Solr Extension, a full-text search engine, with index
documents for all claim contacts in your ClaimCenter application database. Index documents are XML documents
that contain a subset of the information from claim contacts in ClaimCenter. The Guidewire Solr Extension indexes
the documents after it receives them from the free-text batch load command.
Note: The free-text batch load command runs on the host where the Guidewire Solr Extension resides. The
command is located in the /opt/gwsolr/cc/solr/claimcontact_active/conf directory, not the ClaimCenter/
admin/bin directory.
See also
• Installation Guide
• Configuration Guide

When to Run the Free-text Batch Load Command

Generally, ClaimCenter updates the Guidewire Solr Extension whenever someone changes a claim contact and that
change affects index documents stored there. In response, the Guidewire Solr Extension incrementally indexes the
changed information. Occasionally, you need to load the Guidewire Solr Extension and have it build new indexes
based on the newly loaded information.
Run the free-text batch load command whenever any of the following occur:
• Claim contacts are bulk loaded into the ClaimCenter application database.
• Indexes become corrupted in the Guidewire Solr Extension, as reported by the Guidewire Solr Extension web
application.
• Changes are made to the metadata definitions of entities and relationships in the policy graph, and these changes
affect index documents stored in the Guidewire Solr Extension.
• Changes are made to attribute definitions in schema.xml.
• Changes are made to the mapping (claimcontact-search-config.xml or custom mappers) that affect already
indexed contacts.

Free-text Batch Load Command 315

 System Administration Guide 9.0.5

• Your instance of ClaimCenter is upgraded to a later version, and the upgrade changes metadata definitions for
index documents stored in the Guidewire Solr Extension.
Do not run the free-text batch load command if you configured free-text search for embedded operation. Whenever
the Guidewire Solr Extension runs in embedded mode, use the Server Tools Batch Process Info screen to execute the
Solr Data Import batch process instead. If you run the batch load command with embedded operation, ClaimCenter
limits the number of index items to 10,000.
See also
• “Batch Process Info” on page 349

Prerequisites for Running the Free-text Batch Load Command

Before you run the free-text batch load command for the first time, you must modify the following files:
• data-config.xml – Specifies for the batch load command the location of the collated and compiled index
documents for the Guidewire Solr Extension to load. It also specifies the fields the index documents contain.
• batchload.sh/batchload.bat – Specifies the batchload-config.xml configuration file to use for your
database brand.
• batchload-config.xml – Specifies the SQL Select statement that extracts policies from the ClaimCenter
application database. Specifies the URL for the Guidewire Solr Extension. Specifies a working directory, and
specifies a sort binary.
Each time before you run the free-text batch load command, suspend the CCSolrMessageTransport message
destination from the Event Messages page on the Administration tab. Suspending the message destination prevents
ClaimCenter from sending updated index documents to the Guidewire Solr Extension if users modify claim contacts
while the free-text batch load command runs.

Guidewire recommends that you take a backup of the current index before running each free-text batch load
command. This backup provides a snapshot of the index that you can restore if the batch load does not complete
successfully. For information about how to perform a backup, see the Solr documentation on the following web site:

https://archive.apache.org/dist/lucene/solr/ref-guide/apache-solr-ref-guide-4.10.pdf

Run the Free-text Batch Load Command

About this task
You run the free-text batch load command on the host on which the Guidewire Solr Extension resides. Run the
command only if you configured free-text search for external operation.

Procedure
1. In ClaimCenter, suspend the CCSolrMessageTransport message destination.
2. Shut down and restart the Guidewire Solr Extension.
Shutting down the Guidewire Solr Extension forces it to pick up any changes to data-config.xml.
3. Navigate to the following directory in your Solr installation:

/opt/gwsolr/cc/solr/claimcontact_active/conf

4. Run the batchload command.

5. After the command finishes, examine the status response to verify that your load succeeded.
A problem-free load gives the same positive number for Total Rows Fetched and Total Documents Processed.
6. In ClaimCenter, resume the CCSolrMessageTransport message destination.

316 chapter 19 Free-text Batch Load Command

 System Administration Guide 9.0.5

Recovering from Solr Batch Load Errors

The free-text batch load command queries the ClaimCenter database for data and then locally processes the
information intensively on disk. The command eventually produces an XML file with index documents ready for the
Guidewire Solr Extension. In the last step, the command tells the Guidewire Solr Extension to load the index
documents.
The batch load command can fail in the last step and end without loading any index documents. For example, an
error in file data-config.xml can cause the load to fail. In such cases, you do not need to run the entire batch load
command again. Instead, you can invoke the Guidewire Solr Extension directly to complete its portion of the batch
load process by using the following URL:

http://host:8983/cc-gwsolr/cc_claimcontact_active/dataimport?command=full-import&entity=claimcontact

Clean-up Tasks after Running the Free-text Batch Load Command

Each time after you run the free-text batch load command, you must do all of the following:
• Resume the CCSolrMessageTransport message destination from the Event Messages page on the Administration
tab.
Resuming the message destination lets ClaimCenter send updated claim contact data to the Guidewire Solr
Extension for incremental indexing.
• Consider deleting files from the workDir directory.

Free-text Batch Load Command and Native SQL

The free-text batch load command extracts all claim contact data from the ClaimCenter application database by
using native SQL. The SQL Select statement that the batch load command uses is defined in configuration file
batchload-config.xml. The SQL code embedded in the configuration file is suitable for all brands of database.
The file is located on the host on which the Guidewire Solr Extension resides, in the following directory:
opt/gwsolr/cc/solr/claimcontact_active/conf

Run the Free-text Batch Load Command 317

 System Administration Guide 9.0.5

318 chapter 19 Free-text Batch Load Command

chapter 20

Production Data Fix Tool

This topic describes a tightly constrained system for updating data on a running production server other than through
PCF pages or web services. Guidewire calls this mechanism the Production Data Fix tool.

WARNING Only use the Production Data Fix tool under extraordinary conditions, with great caution, and upon
advice of Guidewire Support. Before registering a data change on a production server, register and run the data
change on a development server. Guidewire recommends multiple people review and test the code and the
results before attempting the data change on a production server.

Overview of the Production Data Fix Tool

In typical conditions, ClaimCenter data changes in the database using the following techniques:
• Users change data through the user interface, defined by PCF pages
• External systems change data through specific integrations exposed as web services
There may be a need to change production data in a way that had not been predicted enough to define PCF pages or
web services for the situation. In typical cases, you can write a new web service or other integration to satisfy your
integration need. However, in rare cases there may not be an opportunity to bring your production server down for
this improvement to the application.
ClaimCenter provides a tightly constrained system for updating data on a running production server. Guidewire calls
this mechanism the Production Data Fix Tool.

WARNING Only use the Production Data Fix tool under extraordinary conditions, with great caution, and upon
advice of Guidewire Support. Before registering a data change on a production server, register and run the data
change on a development server. Guidewire recommends multiple people review and test the code and the
results before attempting the data change on a production server.

Separation of Permissions
To decrease security risks, the Production Data Fix tool separates its action into separate tasks, each of which has
different permissions and entry points.

Production Data Fix Tool 319

 System Administration Guide 9.0.5

Permission Code Description

Execute a data change admindatachangeexec Permission to execute the data change code.
Register a data change wsdatachangeedit Permission to register a data change Gosu program.
Use one of the following methods to register data change code:
• The data_change command prompt tool
• The DataChangeAPI WS-I web service
View a data change admindatachangeview Permission to view the Data Change screen.

By having multiple different paths and multiple different roles, there is no single point of attack.

IMPORTANT Guidewire recommends that you force separation of responsibilities into two different ClaimCenter
users. Give each user either the wsdatachangeedit permission (to register data change code) or the
admindatachangeexecd permission (to execute the code), but not both permissions.

Preserving Results
ClaimCenter captures the results of script execution. This increases accountability and makes debugging easier.

Replay Prevention
To prevent replay attacks, the Production Data Fix tool runs each registered script a maximum of one time. If you
need to run it again, you must first re-register the script and create a new change control reference.

The Data Change Screen

Administrative users with the admindatachangeview permission can view a special ClaimCenter Data Change
administration screen that displays information about data change operations. To access this page, navigate to the
following location in Guidewire ClaimCenter:
Administration→Utilities→Data Change
See also
• “Writing Gosu Data Change Code” on page 321
• “Registering Data Change Code” on page 321
• “Run Gosu Data Change Code” on page 323

Typical Use of the Production Data Fix Tool

There are several steps in using the Production Data Fix tool. The following list describes these steps.

Task For more information

Writing and testing the Gosu database code “Writing Gosu Data Change Code” on page 321
Registering the Gosu database code, either through the use of a system tool “Registering Data Change Code” on page 321
or through web services
Running the Gosu database code “Run Gosu Data Change Code” on page 323

320 chapter 20 Production Data Fix Tool

 System Administration Guide 9.0.5

See also
• “Logging Data Change Operations” on page 324

Writing Gosu Data Change Code

The first stop in using the Production Data Fix tool is to write Gosu code that does the following:
• Correctly and safely makes only necessary changes to the production data
• Persists the changes to the database

WARNING Carefully test your data change code. Guidewire strongly recommends that multiple people review
and approve the code for safety and correctness before proceeding.

To persist changes to the database, use the gw.Transaction.Transaction class and its method runWithNewBundle.
You pass the method a block that runs code. If the block does not throw an exception, ClaimCenter persists any data
changes from your Gosu block to the database. If the block throws an exception, no changes persist to the database.
Design your data change code to minimize the number of entity instances you change. Too many changes in entity
data increases the chance of memory issues or concurrent data exceptions.
Save your Gosu code to a local file that ends in .gsp.
See also
• Gosu Reference Guide

Registering Data Change Code

There are two ways to register your data change code
• Through the data_change command prompt tool
• Through the DataChangeAPI web service
The data change registration details vary between these two variants.
In all cases, before proceeding you must have:
• Data change code in the form of a Gosu script that you have already tested in your development environment.
• A human-readable description for your data change.
• A unique reference ID that you create to represent this data change.

IMPORTANT If you need to re-run a successful data change, you must first re-register the script with a new
reference ID. This is requirement preserves the integrity of the results log.

See also
• “Writing Gosu Data Change Code” on page 321

Register a Data Change Using a Command Prompt

About this task

The command prompt tool data_change works by calling the DataChangeAPI web service on a running
ClaimCenter server.

Typical Use of the Production Data Fix Tool 321

 System Administration Guide 9.0.5

WARNING Before registering a data change on a production server, register and run the data change on a
development server first. Guidewire recommends multiple people review and test the code and the results
before attempting the data change on a production server.

Procedure
1. Ensure that the ClaimCenter application server is running.
2. Open a command prompt and navigate to the following location in the ClaimCenter installation:

admin/bin

3. Run the following command:

data_change –description DESCRIP –edit REFID –gosu PATH –server SERVERURL –user USER –password PW

To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.
For example:

data_change –description "Fix Employee Name"

–edit REFID_1234 –gosu c:\ClaimCenter\datachange\gosudatachange_REFID1234.gsp
–server http://TESTINGSERVER:8080/cc –user su –password gw

Result
The script outputs results such as:

Running data_change.gsp
Connecting as su to URL http://localhost:8080/cc/ws/gw/webservice/systemTools/DataChangeAPI
Edit change ref=REFID1234 publicId=cc:1

Next steps
See also
• “Data Change Command Tool Reference” on page 324

Register a Data Change Using a Web Service

About this task

WARNING Before registering a data change on a production server, register and run the data change on a
development server first. Guidewire recommends multiple people review and test the code and the results
before attempting the data change on a production server.

Procedure
1. Call the DataChangeAPI web service method updateDataChangeGosu.
2. Pass the method the following arguments as String objects:
• The reference ID
• A human-readable description
• The Gosu code to run
For example:

322 chapter 20 Production Data Fix Tool

 System Administration Guide 9.0.5

var gosuScript = "gw.transaction.Transaction.runWithNewBundle(\ bundle -> {

print(""DATA CHANGE!"") })"

var publicID = datachangeAPI.updateDataChangeGosu("REFID_1234",

"Fix for Issue 1234 regarding missing Employee ID", gosuScript)

Result
The method call returns the public ID of the new DataChange entity instance.

Next steps
See also
• “Register a Data Change Using a Command Prompt” on page 321
• “Data Change Command Tool Reference” on page 324

Run Gosu Data Change Code

Before you begin
Before executing data change code, confirm that someone created and registered a data change. You must know the
reference ID for the registered data change.

About this task

WARNING Only use the Production Data Fix tool under extraordinary conditions, with great caution, and upon
advice of Guidewire Support. Before registering a data change on a production server, register and run the data
change on a development server first. Guidewire recommends multiple people review and test the code and the
results before attempting the data change on a production server.

Procedure
1. Log into your ClaimCenter development environment as an administrator with the admindatachangeview
permission.
2. Select the Administration tab.
3. Expand Utilities→Data Change.
4. In the list of data changes, use the Reference column to find the data change request by its reference ID.
5. Click on the data change row in that list.
The screen shows the Gosu code for that data change.
6. Review the Gosu code to confirm it is what you expect.
7. Click Execute.
During code execution, ClaimCenter does not display the results immediately in the Result pane. Instead, the
status of Executing shows in the list of data changes.
8. After a few seconds, click Reload on the screen to view the current status and results.
• If the change is successful, ClaimCenter confirms the success in a message that uses your reference ID:
• If the change was not successful, ClaimCenter shows any compile errors or exceptions in the user interface
in the Result pane.
9. Confirm your changes in the database and check your logging results from the change.
10. If the data change appears safe in your development environment, carefully register and run the data change
on the production server.

Typical Use of the Production Data Fix Tool 323

 System Administration Guide 9.0.5

Next steps
See also
• “Writing Gosu Data Change Code” on page 321

Logging Data Change Operations

Use data change Gosu APIs to configure logging within data change code. These APIs generate logging information
that users can see in human-readable output in data change user interface.

Logging Entity Field-level Changes

To log entity field-level changes, call DataChange.util.setDetailResultWriting(bundle). The logging
information includes information about added objects, deleted objects, and field-level changes on every object. For
updated properties, the logging information includes each field value before the change and after the change.

Logging Arbitrary Text Data

To log arbitrary text data, call DataChange.util.ResultsWriter. That property returns an appender, which is an
object that implements the interface java.lang.Appendable. That object has several method signatures of the
append method. The simplest method signature takes a CharSequence object, such as a standard String object.

Example Logging Code

The following sample code uses the setDetailResultWriting method and the ResultsWriter property to create
log messages.

gw.transaction.Transaction.runWithNewBundle(\ bundle -> {

// For demonstration, get a User object and make minor data change to the first name
var u = gw.api.database.Query.make(User).select().first()
bundle.add(u)
u.Contact.FirstName = u.Contact.FirstName + "SUFFIX"

// Determine what you want to write to the data change log

var msg = "For PublicID '${u.PublicID}' User.DisplayName is now '${u.DisplayName}'!"

// To log arbitrary text in Data Change UI, get a results writer (type is java.lang.Appender)
var rw = DataChange.util.ResultsWriter
rw.append("Add arbitrary log message here\n")

// enable detailed logging of each property value before and after our change
DataChange.util.setDetailResultWriting(bundle)

// for testing in Studio Scratchpad, also print to standard console

// print("To console: " + msg)

})

To test and debug your code in Studio Scratchpad, you may want to print to the console using the standard print
statement. Also, add one more argument to the runWithNewBundle method to represent a user name. For example,
pass the String value "su" to create your writable bundle as the super user.

Data Change Command Tool Reference

ClaimCenter provides a tightly constrained system for updating data on a running production server. Guidewire calls
this mechanism the Production Data Fix tool. The Production Data Fix tool uses either the data_change command
option, or, the DataChangeAPI web service to make changes to the production data.
Because the data_change command allows arbitrary execution of data, Guidewire strongly recommends that you
carefully control the ability to create and run code on a production server. The user who runs this command must
have permission wsdatachangeedit.

324 chapter 20 Production Data Fix Tool

 System Administration Guide 9.0.5

WARNING Only use the Production Data Fix tool under extraordinary conditions, with great caution, and upon
advice of Guidewire Support. Before registering a data change on a production server, register and run the data
change on a development server. Guidewire recommends multiple people review and test the code and the
results before attempting the data change on a production server.

data_change -help
data_change -password password [-server url] [-user user] {
-edit refID -gosu filepath [-description desc] |
-discard refID |
-status refID |
-result refID }

See also
• For a description of how and when to use the data_change command to change data on a running production
server, see “Production Data Fix Tool” on page 319.
• For a description of how to use the DataChangeAPI web service, see “Data Change Web Service Reference” on
page 325.
• For specifics of the data_change command options, see “Data Change Options” on page 415.

Data Change Web Service Reference

To register a data change, or to check status on a data change operation, use the following methods on the
DataChangeAPI web service.

DataChangeAPI method Description

updateDataChangeGosu Use to register a data change.

Pass the method the following arguments as String objects:
• The reference ID
• A human-readable description
• The Gosu code to run
The method returns the public ID of the new DataChange entity instance.
Note the following:
• If the data change succeeds with no compile errors, you cannot edit the data change Gosu code.
You must re-register the script with a new reference ID to make changes to the code.
• If the data change was never run, or had compile errors, you can update (edit) and rerun Gosu
code with the same reference ID.
discardDataChange Use to discard a data change that you already registered.
Pass the method a data change reference ID as a String object. You cannot discard a data change
that was already run.
getDataChangeResult Use to review the result of a data change that you already registered.
Pass the method a data change reference ID. The method returns a String object that represents
the results in the DataChange entity instance. If running the data change code generated parse
errors, the results include the errors.
getDataChangeStatus Use to view the status of a data change that you already registered.
Pass the method a data change reference ID. The method returns a DataChangeStatus typecode.
Valid values include:
• Open
• Discarded
• Executing
• Failed

Data Change Web Service Reference 325

 System Administration Guide 9.0.5

DataChangeAPI method Description

• Completed

See also
• “Overview of the Production Data Fix Tool” on page 319
• “Typical Use of the Production Data Fix Tool” on page 320
• “Data Change Command Tool Reference” on page 324
• Integration Guide

326 chapter 20 Production Data Fix Tool

part 6

Business Rules Administration

System Administration Guide 9.0.5
chapter 21

Administering Business Rules

This topic provides information relevant to administering ClaimCenter business rules.

See also
• “Business Rules Import and Export” on page 337

Business Rules in Guidewire ClaimCenter

ClaimCenter provides a management tool that business analysts and rule administrators use to do the following:
• Add, modify, and delete activity business rules
• Manage the process of testing and deploying business rules
• Manage the import and export of business rules between development, test, and production ClaimCenter servers
You access and manage business rules for activities in Guidewire ClaimCenter in the following location:
Administration→Business Settings → Business Rules→Activity Rules
ClaimCenter business rules, managed from and within ClaimCenter, are distinct from Gosu rules, managed through
ClaimCenter Studio.
See also
•
• Application Guide
• Rules Guide

Business Rule Roles and Permissions

In the base configuration, ClaimCenter provides the following user permissions for use with activity business rules.

Permission Code Provides ability to…

Approve Rule activityruleapprove Promote a business rule to Approved status.

Administering Business Rules 329

 System Administration Guide 9.0.5

Permission Code Provides ability to…

Deploy Rule activityruledeploy Deploy approved business rules.
Edit Rule activityruleedit Perform the following business rule edit operations:
• Create, clone, edit, delete
• Revert a rule to a specific rule version
• Enable or disable a business rule
• Promote a business rule to Staged status
Import Rule activityruleimport Import business rules into ClaimCenter.
View Rule activityruleview View the Business Rules screens.

ClaimCenter provides the following user roles for use with business rules.

Activity Rules Admin All permissions related activity rules

Activity Rules Editor Edit and View permissions for activity rules
Activity Rules Viewer View the Business Rules screens only

Business Rule Configuration Parameters

ClaimCenter provides the following parameters in file config.xml to manage the deployment and configuration of
business rules:
• BizRulesEnabled
• BizRulesDeploymentEnabled
• BizRulesDeploymentId
• BizRulesImportBootstrapRules
• BizRulesLeafSearchNumOfHops

IMPORTANT If you are running ClaimCenter business rules on a production server, you must set
BizRulesDeploymentEnabled to true and provide a value for BizRulesDeploymentId.

See also
• Configuration Guide

Business Rule Production Server Configuration

If you use ClaimCenter business rules in a production environment, you must do the following:
• Set configuration parameter BizRulesDeploymentEnabled to true.
• Set configuration parameter BizRulesDeploymentId to the server ID of the production server importing the
business rules.
You set the server ID in the <registry> element in file config.xml, for example:

<registry roles="batch, workqueue, scheduler, messaging, startable, special, ui">

<server serverid= "server_id" roles="batch,workqueue"/>
</registry>

Set the value of server_id to the value of BizRulesDeploymentId.

330 chapter 21 Administering Business Rules

 System Administration Guide 9.0.5

See also
• “Understanding the Configuration Registry Element” on page 46
• Configuration Guide

Business Rule Versioning

ClaimCenter associates a version number and a status with each individual business rule. You see this information in
the Business Rules screen, in the Version field. ClaimCenter manages the information in the Version field, you cannot
change it yourself. If you have multiple versions of a rule, the Version field becomes a drop-down list, from which
you can select a specific version of a rule to view.
Each version number starts at 0 and increments by 1 for each deployed version of the business rules. If you edit a
business rule, ClaimCenter adds a plus sign (+) to the version number of the rule that you are editing, for example,
0+. Along with the version number, each business rule shows its state in parenthesis next to the version number, for
example 0+ (Draft). Each version of a business rule is always in one of the following states:
• Draft
• Staged
• Approved
At the creation of a new rule version, ClaimCenter generates a work-in-progress rule with an initial status of Draft.
This draft rule contains the same data values as the parent rule version from which it was made.
The work-in-progress rule must go through the three states of Draft, Staged, and Approved before it is possible to
deploy the new rule version. After these three stages are complete, and after you deploy the rule, ClaimCenter
assigns an updated version number to the rule. This version of the rule becomes the latest running version of the rule
that ClaimCenter evaluates at runtime.
The version of a rule that ClaimCenter evaluates at runtime contains the word Evaluated after the version number.
The Evaluated version of a rule is always the latest iteration of a rule that can run in a specific environment.

Rules for Deleting a Business Rule Version

ClaimCenter associates a version number and a status (state) with each individual business rule. Whether it is
possible to delete any given version of a rule depends on the state of the business rule. The following table lists the
rules for deleting a rule version.

Rule version state Rule deletion action

Deployed It is not possible delete a rule version after its deployment
Approved or Staged Clicking Delete deletes all rule versions down to the last deployed rule version.
Draft – Direct parent deployed Clicking Delete Draft deletes all rule versions down to the last deployed rule version.
Draft – Rule previously staged or Clicking Delete Draft deletes the immediate draft version of the rule. After deleting the draft
approved version of the rule, it then becomes possible to delete the staged and approved versions of
the rule.

Business Rule Deployment

In a production ClaimCenter cluster, Guidewire requires that you deploy a rule before ClaimCenter can evaluate the
business logic of the rule. Thus, to deploy a business rule is to make that version of the business rule active within
ClaimCenter.
Before deployment, ClaimCenter creates a work-in-progress version of the rule. At rule deployment, ClaimCenter
assigns a version number to the rule.

Business Rule Versioning 331

 System Administration Guide 9.0.5

A rule must go through the following states before you can deploy the rule:
• Draft
• Staged
• Approved
A rule must be in the approved state before it is possible to deploy the rule. Approving a rule does not deploy the
rule. You must actively deploy a rule before ClaimCenter evaluates that rule at runtime.
Rule deployment is distinct from rule import. On completing a rule import, you must deploy any new approved rule
versions before ClaimCenter can evaluate the rules.
In general, Guidewire recommends that you use separate cluster environments for each of the following in working
with ClaimCenter business rules:
• Development
• Test
• Production
Typically, you deploy a rule version in a production environment only. In a production environment, you must also
set configuration parameter BizRulesDeplymentEnabled to true.
See also
• “Business Rule Versioning” on page 331
• “Business Rule State” on page 332

Business Rule State

At initial creation, all business rules are in the Draft state. As you begin the process of reviewing, evaluating, and
updating a business rules, its state can vary and progress.
The Guidewire ClaimCenter business rules have the following sequence of states.

Draft ClaimCenter assigns a status of Draft after you save the initial version of the rule. A rule reverts to Draft status
whenever the rule undergoes any type of editing. It is not possible export a rule in the Draft state.
Staged You manually move a rule in the Draft state to the Staged state, after you complete rule editing. Typically, this is the
point in the rule lifecycle that you export the rule from the development environment and import the rule into the
testing environment.
Approved You manually move a rule from the Staged state to the Approved state, usually in the testing environment after you
complete the rule evaluation phase. Typically, this is the point in the rule lifecycle that you export the rule from the
testing environment and import it into the development environment.
Deployed You manually move a rule from the Approved state to the Deployed state. Typically, this occurs after you import the
rule into the production environment.

The following diagram describes the various states associated with a business rule, as it is created, edited, and
deployed in development and production environments.

332 chapter 21 Administering Business Rules

 System Administration Guide 9.0.5

Business Rules States

Development Testing Production

Test, Reject Rule

Staged Approved
Draft

Create/Edit Rule

Test, Import Rule Deploy

Import
Promote to
Rule
Test, Approved
Promote to Edit
Business Staged
Analyst

Approved Deployed

Export Back to
Implementation Staged Development
Specialist Export Rule and
Testing*

Staged Approved
Export Business Rule Business Rule
Rule

* Export deployed rules from Production and import back to Development and Testing to keep all environments in sync.

Business Rule Lifecycle

Whenever you deploy a rule in the production server, Guidewire recommends that you export the rule from the
production server and import it back to the development and testing servers. Always make changes on the
development server and move the rule to testing then to production. If you always export the deployed rule from
production back to development, the version number and rule status on development stays synchronized with the
production server.
For example, you create a new rule; the version is 0+. The version stays the same as you move it from development
to testing, and then to production. Whenever you deploy the rule on the production server, the version number
increases to 1. You export the rule from production back to the development server. Now on both development and
production servers, the rule version is 1. On the development, you make changes to version 1. Whenever you import
the rule through testing to production and deploy it, the rule version becomes 2.
The following table shows how rule version and status change as you export and import it from development,
testing, and production servers.

Action Development Testing Production

1. Create a new rule. 0+ (Draft)
2. Edit rule and save it. Repeat several times. 0+ (Draft)
3. Rule is ready for testing. Promote to Staged status. 0+ (Staged)

Business Rule Lifecycle 333

 System Administration Guide 9.0.5

Action Development Testing Production

4. Export rule and import to testing server. 0+ (Staged)
5. Rule passes testing. Promote to Approved status. 0+ (Approved)
6. Export rule and import to production server. 0+ (Approved)
7. Deploy the rule. The version number increases from 0 to 1. 1 (Evaluated)
8. Export rule and import back to development and testing servers. 1 1
9. Edit rule. 1+ (Draft)
10. Ready for testing, promote to Staged. 1+ (Staged)
11. Export and import to testing server. 1+ (Staged)
12. Testing passed. Promoted to Approved. 1+ (Approved)
13. Export and import to production. 1+ (Approved)
14. Deploy. The version number increases from 1 to 2. 2 (Evaluated)
15. Export rule and import back to development and testing servers. 2 2

Guidewire does not require that you move the rule back to development before making changes. However, if you do
not export a deployed rule back to the development server, the version number on the development server does not
correspond to the version on production. For example, if you never export the rule back to development, the version
number stays at 0+ on the development server, and increases each time you deploy it on production.
The following table shows rule version and status change for the same rule, except that you do not export the rule
from production to development.

Action Development Testing Production

1. Create a new rule. 0+ (Draft)
2. Edit rule and save it. Repeat several times. 0+ (Draft)
3. Rule is ready for testing. Promote to Staged status. 0+ (Staged)
4. Export rule and import to testing server. 0+ (Staged)
5. Rule passes testing. Promote to Approved status. 0+ (Approved)
6. Export rule and import to production server. 0+ (Approved)
7. Deploy the rule. The version number increases from 0 to 1. 1 (Evaluated)
8. Rule requires updates. On development server, edit rule and save. Repeat 0+ (Draft)
several times.
9. Ready for testing, promote to Staged. 0+ (Staged)
10. Export and import to testing server. 0+ (Staged)
11. Testing passed. Promoted to Approved. 0+ (Approved)
12. Export and import to production. The version number increases because 1+ (Approved)
the rule version currently on the production server is 1 (Evaluated). The
rule being imported has changes built on top of that version, so the
version becomes 1+. If changes to the rule have also been made on
production server, you must resolve the conflict manually on import.
13. Deploy. The version number increases from 1 to 2. 2 (Evaluated)

334 chapter 21 Administering Business Rules

 System Administration Guide 9.0.5

Business Rule Logging

ClaimCenter writes audit information to the console log and to the ClaimCenter log file whenever a rule evaluation
triggers a business rule. Unless specified otherwise, ClaimCenter writes the business rule information at the log
INFO level for the following logging categories and subcategories:

BizRules
BizRules.Audit
BizRules.Autocomplete
BizRules.Compiler
BizRules.ContextHelp
BizRules.Export
BizRules.Import
BizRules.UI
BizRule.Validation

The business rule information that ClaimCenter logs includes the following:
• The rule context
• The rule ID
• Whether the rule condition evaluates to true or false
• The rule action parameters as a list of name-value pairs, which is empty if the condition evaluates to false
See also
• “Application Logging” on page 25
• “Set Log Level” on page 357

Invalid Business Rules

Invalid Rules during Server Start
If business rules exist in the database, ClaimCenter validates these rules during the start of the application server. If
ClaimCenter finds an invalid rule, it generates an error message in the application log similar to the following:

ERROR BizRules.Validation Rule Test Rule has validation error: Could not resolve symbol
for : SomeActivity

Guidewire recommends that you review the application log after starting the application server to determine if
ClaimCenter reports any rule as invalid.

Invalid Rules during Rule Execution

How ClaimCenter treats an invalid rule depends on the rule state and the server mode.

Rule state Server mode Action

Draft Non-Production ClaimCenter skips the execution of the invalid rule and continues with rule
execution.
Staged, Approved,or Non-Production ClaimCenter generates an exception and stops rule execution.
Deployed
Deployed Production ClaimCenter generates an exception and stops rule execution.

Business Rule Logging 335

 System Administration Guide 9.0.5

336 chapter 21 Administering Business Rules

chapter 22

Business Rules Import and Export

You transfer rules between different server environments by exporting the rules from one server environment and
importing the rules into the other server environment. Typically, one or more appointed Rules Administrators
manage the export and import of business rules between different ClaimCenter server environments.

Overview of Business Rule Export and Import

The following flow is a typical business rule development lifecycle:
• Create and develop the draft business rules on a development server.
• Export the business rules to a testing server that replicates the production environment and stage the rules.
• After testing, approve the rules on the staging server.
• Export the business rules to the actual production server and deploy the rules there.
You use the import and export of business rules to move rules between the multiple servers.
During import, ClaimCenter only brings in rules that are new or have changes on top of existing versions. The
version number increases whenever you deploy the rule.
Whenever importing rules from one server environment to another, ClaimCenter takes one of the following actions
for each rule:

ClaimCenter Action
Imports the rule ClaimCenter imports the rule if any of the following are true:
• The rule for import is new and does not exist in the importing server environment.
• The rule for import is an update to an existing rule in the importing server environment.
Does not import ClaimCenter does not import the rule into the importing server environment if any of the following are true:
the rule • If there is no difference between the existing rule and the rule for import.
• If the existing rule is already an update of the rule for import.
Raises a conflict ClaimCenter raises a conflict if it cannot automatically decide whether to import the rule. This can happen
for example, if the existing rule and the rule for import both have updates that conflict.

Business Rules Import and Export 337

 System Administration Guide 9.0.5

ClaimCenter Action
As a concrete example, suppose that you update the rule on the testing server. Then you independently
update the rule on the development server. You export the rule from the development server and import it
into the testing server. The testing server raises a conflict while trying to import the rule. Within
ClaimCenter, you must choose whether to keep the existing rule or take the importing rule.
This type of rule conflict can occur also if you update or customize a default business rule and Guidewire
later provides an updated version of that rule in an upgrade. In that case, you must choose either to keep
one or the other of the updated rules or manage the merge of the two rules.

Rule export does not export utility functions, context objects, or other changes to the business rules plugin. You
must propagate changes to Gosu functions or context objects on the development server to the testing and
production servers.

About Rule Version Conflicts

During the rule import operation, ClaimCenter raises a rule conflict issue if there is a mismatch in rule versions for
any given rule between:
• The existing rule version as defined in the application database
• The importing rule version
The Rule Administrator resolves all rule import conflicts manually through the following business rules screens:
• Import/Export Status screen
• Complete Import screen
• Compare Rules screen
To access the Import/Export Status screen, navigate to the following location in Guidewire ClaimCenter:
Administration→Business Settings→Business Rules→Import/Export Status
The other screens open from the Import/Export Status screen.

Business Rule Import Failure

If, for some reason, ClaimCenter detects an error with a rule import operation, it sets the Status value for that import
operation to Failure in the Import/Export Status screen. Click the Failure link to open the Rule Import/Export Failure Reason
screen for more information on the reason for the import failure.

Source and Target Data Models and Rule Export and Import
The business rules data model in the source and target systems must match. Otherwise, the rule import into the target
system fails. Ensure that the business rules data model of the source and target systems is the same before exporting
any business rule. If necessary:
• Modify the business rules data model of one system so that it matches the business rules data model of the other
system.
• Regenerate the business rules export file.
• Repeat the business rules import operation.

Export Business Rules from Guidewire ClaimCenter

About this task
It is possible to export business rules from ClaimCenter in multiple ways from the Activity Rules screen. To export a
rules, it must be in one of the following states: Staged, Approved, or Deployed. It is not possible export a rule in the
Draft state.

338 chapter 22 Business Rules Import and Export

 System Administration Guide 9.0.5

Procedure
1. Log into Guidewire ClaimCenter using an administrative account.
2. Navigate to the following screen:
Administration→Business Settings→Business Rules→Activity Rules
3. From the More drop-down list, chose one of the following options:

Export Exports only the selected business rules. ClaimCenter exports the selected rules from the currently active
Selected screen only.
Export All Exports all business rules visible on all pages. ClaimCenter does not export rules hidden because of filters.
Nor does ClaimCenter export rules in the Draft state that have never been deployed. If a rule is in the
Draft state and has one or more previously deployed versions, ClaimCenter exports the last deployed
version.

Selecting one of these options opens the Import/Export Status screen.

Next steps
See also
• “Import Business Rules into Guidewire ClaimCenter” on page 339
• “The Import/Export Status Screen” on page 340

Import Business Rules into Guidewire ClaimCenter

Before you begin
You can only import a business rule into Guidewire ClaimCenter that was previously exported from Guidewire
ClaimCenter.

Procedure
1. Log into Guidewire ClaimCenter using an administrative account.
2. Navigate to the following administrative screen:
Administration→Business Settings→Business Rules
3. Choose one of the following options:

Import rules from… Import option

Activity Rules screen From the More drop-down list, select Import from File.
Import/Export Status screen Click Import from File.

Selecting one of these options opens the Import/Export Status screen.

Next steps
See also
• “Export Business Rules from Guidewire ClaimCenter” on page 338
• “The Import/Export Status Screen” on page 340
• “About the Business Rules Export File” on page 340

Overview of Business Rule Export and Import 339

 System Administration Guide 9.0.5

The Import/Export Status Screen

After you begin the import or export of business rules, ClaimCenter opens the Import/Export Status screen
automatically. This screen shows progress and status information for each import or export session initiated by any
ClaimCenter rule administrator. To update the information on this screen, click Refresh.
You can also initiate a rule import operation from this screen by clicking Import from File.

The Imports Table

The Imports summary table contains information about each rule import operation, including the following:
• The user who initiated the import operation
• The start time of the import operation
• The source file for the import operation
• The status of the import operation
• A Review button if there are no rule conflicts in this import operation
• A Complete Import button if this import operation generated rule conflicts between the import and existing rules

The Exports Table

The Exports summary table contains information about each rule export operation, including the following:
• The user who initiated the export operation
• The start time of the export operation
• The number of rules in the export file
• A Cancel button that is visible only during the export operation
• A Download button that becomes visible after the export operation completes
See also
• “About the Business Rules Export File” on page 340
• “The Review Import/Complete Import Screens” on page 340

About the Business Rules Export File

The Import/Export Status business rule screen shows the progress of a business rules export operation. After export
completes, click Download to save exported rules to the file system.
ClaimCenter writes the rules for export to a file with a .gwrules extension. This file is in binary format. It is not
possible to view or edit this file outside of Guidewire ClaimCenter. The primary use for this file is to provide the
ability to export business rules from one ClaimCenter server environment and import those rules into another
ClaimCenter server environment.
See also
• “Export Business Rules from Guidewire ClaimCenter” on page 338
• “Import Business Rules into Guidewire ClaimCenter” on page 339
• “The Compare Rules Screen” on page 342

The Review Import/Complete Import Screens

The business rules Import/Export Status screen displays information about the import of each business rule import
operation. The functionality changes on the screen depending on whether a rule conflict exists in an import
operation.

340 chapter 22 Business Rules Import and Export

 System Administration Guide 9.0.5

Rule Functionality
conflicts?
No If there are no issues to resolve for a given rule import operation, ClaimCenter displays a Review button in the
Imports table for that rule. Clicking Review opens the Review Import screen.

Yes If there are pending rule conflicts to resolve for a given rule import operation, ClaimCenter displays a Complete
Import button in the Imports table for that rule. Clicking Complete Import opens the Complete Import screen.

The Review Import and Complete Import screens are identical except that the functionality changes depending on
whether you are reviewing a rule import operation or resolving a rule import conflict.
The Review Import / Complete Import screen consists of the following distinct sections:
• “The Rule Import Disposition Table” on page 341
• “The Rule Import Manage Synchronization Table” on page 341
To access the business rules Import/Export Status screen, navigate to the following location within Guidewire
ClaimCenter:
Administration→Business Settings→Business Rules→Import/Export Status

The Rule Import Disposition Table

Clicking Review or Complete Import in the business rules Export Status screen opens either the Review Import or the
Complete Import screen for that rule import operation. These two screens are identical in layout. At the top of the
screen is Disposition table that provides summary information about the rules in the rule import file. The following
list describes the various columns in the table.

Column Description
Outstanding The subcategories under Outstanding have the following meanings:
• New Rule – Number of rules in the import file that have no equivalent on the importing server.
• New Version – Number of rules in the import file that are newer versions of rules on the importing server.
• Rule Deployment – Number of rules being imported that have a deployed version.
• Version Conflict – Number of rules for which there are version conflicts between the importing rules and
the existing rules on the importing server.
Note: If there are no rule conflicts for a given import operation, all subcategories for that operation display
zero (0).
Imported Number of rules ClaimCenter imported from the import file.
Discarded Number of rules discarded by user action.
Applied Edited Number of rules that the Rule Administrator edited and saved.
No Change Number of rules that require no additional action. These rules exist in the importing server already and do
not require updating. For example, the rule in the import file is an earlier version of the rule version on the
importing server.

To access the Import/Export Status screen, navigate to the following location in Guidewire ClaimCenter:
Administration→Business Settings→Business Rules→Import/Export Status

The Rule Import Manage Synchronization Table

Clicking Review or Complete Import in the Import/Export Status screen opens either the Review Import or the Complete
Import screen for that rule import operation. These two screens are identical in layout. At the bottom of the screen is
Manage Synchronization table that provides summary information about each rule in the rule import operation.

The Review Import/Complete Import Screens 341

 System Administration Guide 9.0.5

If you undertake an action to resolve a rule import conflict, you must save and apply your change. See “Resolve
Rule Import Conflicts” on page 343 for details.
The following list describes the various columns in the table.

Column Description
Rule Name Name of the rule. ClaimCenter adds a warning next to the rule name if the importing rule name duplicates the
name of a differently configured rule on the importing server.
Status Current status of the rule. Some examples are:
• New Rule – This rule does not exist on the importing server.
• New Rule Version – This version of the rule does not exist on the importing server.
• No Change – The existing rule is a more updated version of the importing rule.
• Rule Deployment – The existing version of the rule needs deployment to match the rule version of the importing
rule.
• Versions conflict – There are conflicts between the existing and importing versions of the rule that you must
manage manually.
Depending on the rule status, it is possible for the list of possible actions in the Available Actions column to change.
Available If there is no import conflicts with the given rule, there are no actions available in this column.
Actions If there is a conflict between the importing and existing rule versions, the following actions are available:
• Existing Version – Keep the existing rule on the importing server and discard the imported rule.
• Importing Version – Keep the importing rule version and discard the existing rule version on the importing
server.
• Compare – Click to open the Compare Rules screen. Use this screen to compare the two rules side-by-side to
view their similarities and differences and determine the course of action to take.
Existing The version of the rule that exists in the importing server. Click to access a read-only view of the rule.
Version

Importing The version of the rule in the import file. Click to access a read-only view of the rule.
Version

To access the Import/Export Status screen, navigate to the following location in Guidewire ClaimCenter:
Administration→Business Settings→Business Rules→Import/Export Status

Business Rule Validation Errors

If there is at least one rule validation error in the business rules Complete Import screen, ClaimCenter inserts an
exclamation icon (!) to the immediate left of the name of the invalid rule. If you hover the cursor over the icon,
ClaimCenter shows additional information in the tooltip message.
ClaimCenter shows … to the immediate left of the rule name if the validation work queue has not yet run and there
are pending validations.

The Compare Rules Screen

ClaimCenter opens the Compare Rules screen if you click a Compare link in Complete Import screen. The Compare link
appears if there is a conflict between an existing rule and a rule that you are importing.
The Compare Rules screen creates a side-by-side table view to make it easier to compare the details of the two rules.
ClaimCenter highlights the fields that are different between the two rule definitions.
After you review each of the rules, choose one of the following actions.

342 chapter 22 Business Rules Import and Export

 System Administration Guide 9.0.5

Keep Existing Chose to retain the currently existing rule and discard the importing rule. If you select this option, ClaimCenter
Version reopens the Complete Import screen with the Existing Version radio button selected for the rule under Available
Actions.

Replace with Chose to accept the importing rule and discard the existing rule. If you select this option, ClaimCenter reopens
Importing the Complete Import screen with the Importing Version radio button selected for the rule under Available Actions.
Version

Edit Select one of the following from the Edit drop-down list to modify either the existing or importing rule:
• Existing Version
• Importing Version
If you choose to edit a rule version, ClaimCenter opens the rule in edit mode. Editing a rule creates a new Draft
version of the rule.
If you save the edited rule, it becomes the resolved rule version for import completion. After making this update,
you can no longer select either the importing or existing rule in the Complete Import screen. The status of the rule
in the Complete Import screen changes to Edited Version. If you select the rule and apply your change, the Applied
Edited field increments by one (1).
ClaimCenter disables the edit functionality if the existing rule version is in Draft mode.

See also
• “Resolve Rule Import Conflicts” on page 343

Resolve Rule Import Conflicts

About this task
To resolve rule version conflicts that occurs during a rule import process, perform the following sequence of steps.

Procedure
1. Navigate to the following location in Guidewire ClaimCenter:
Administration→Business Settings→Business Rules→Import/Export Status
2. For each rule import that has a status other than Completed, click Complete Import.
The Complete Import screen opens.
3. Review each rule that shows an import conflict in the Complete Import screen. Do one of the following:
a. Click the Existing Version or the Importing Version link to see the details for that rule version.
b. Click the Compare link to open the Compare Rules screen in which you can view the two rule versions in a
side-by-side table.
4. (Optional) After reviewing the two rules in the Compare Rules screen, do one of the following:
• Click Keep Existing Version to accept the existing rule on the import server with no change.
• Click Replace with Importing Version to accept the import rule with no change.
• Select an Edit option to open an editable view of either the existing or importing version of the rule.
• Note: ClaimCenter disables the edit functionality if the existing rule version is in Draft mode.
5. (Optional) Make your edits the Compare Rules screen, then click Save Edited Version.
If you edit either of the rule versions in the Compare Rules screen, that version of the rule becomes the resolved
version of the rule. Thereafter, you cannot ever use the importing or existing version of the rule to resolve the
rule conflict.
ClaimCenter reopens the Complete Import screen.

Resolve Rule Import Conflicts 343

 System Administration Guide 9.0.5

6. In the Complete Import screen, select the resolution type by selecting a radio button in the Available Actions cell
for the rule of interest. Your choices are:
• Use the existing rule version.
• Use the importing rule version.
• Use the new, edited, version of the rule.
7. Select the rule for update by selecting the checkbox to the left of the rule name.
8. Save and apply your changes by clicking one of the following function buttons:

Import Selected Enabled if you select one or more rules. It must be possible to import these rules.
Discard Selected Enabled if you select one or more rules.
Import All Remaining Enabled if there are no remaining unresolved conflicts. It must be possible to import these rules.
Discard All Remaining Enabled if you select one or more rules.

9. Repeat these steps as necessary to resolve all rule conflicts in the rule import operation.

Next steps
See also
• “The Compare Rules Screen” on page 342

Automatic Import of Business Rules at Server Startup

After the initial ClaimCenter installation, the database is empty of data. The first time that you start the ClaimCenter
application server after installation, ClaimCenter upgrades the database and populates it with data. As part of this
initial database upgrade, it is possible to automatically load data from the following Studio Project folder into the
ClaimCenter database:
configuration→config→import→bizrules
Folder bizrules contains the default business rules that Guidewire supplies as part of the ClaimCenter base
configuration. Configuration parameter BizRulesImportBootstrapRules in config.xml controls whether
ClaimCenter imports the business rules in folder bizrules automatically at initial server start, if you have an empty
database.

IMPORTANT Guidewire recommends that you set this parameter to true in an environment in which you plan to
do initial rule review or rule development only.

See also
• “Business Rules Import at Initial Server Startup” on page 293

Import ClaimCenter Business Rules at Server Startup

About this task
You import the default business rules once, on the development server only.

Procedure
1. Set configuration parameter BizRulesImportBootstrapRules in config.xml to true.
2. With an empty database, start the ClaimCenter application server.
ClaimCenter populates the database with the bootstrap business rules that exist in the following location in
ClaimCenter Studio:
configuration→config→import→bizrules

344 chapter 22 Business Rules Import and Export

 System Administration Guide 9.0.5

3. Reset configuration parameter BizRulesImportBootstrapRules to false.

Next steps
Thereafter, manage your business rules using the standard rule import and export process, discarding any further use
of the default rules in the bizrules folder.
See also
• “About the import Directory” on page 292
• Configuration Guide

Correct Duplicate BizRuleDeploymentId Values

About this task
If you attempt to import a set of business rules that has a BizRulesDeploymentId value that is the same as the
current ClaimCenter cluster, the rule import fails. This happens, for example, if a development cluster has the same
BizRulesDeploymentId value as the production cluster into which you are importing the files. To avoid this
scenario, Guidewire recommends that each ClaimCenter sever cluster have its own unique value for
BizRulesDeploymentId.
Note: You set the value of BizRulesDeploymentId in config.xml.
Correcting this issue is a multi-step process:

Procedure
1. Temporarily, start the application server with the value of BizRulesDeploymentEnabled set to false.
In this case, ClaimCenter ignores the value of BizRulesDeploymentId and import validation does not stop the
import of the file.
2. After the rule import succeeds, restart the application server with the value of BizRulesDeploymentEnabled
set to true.

Next steps
See also
• Configuration Guide

Correct Duplicate BizRuleDeploymentId Values 345

 System Administration Guide 9.0.5

346 chapter 22 Business Rules Import and Export

part 7

Administration Tools
System Administration Guide 9.0.5
chapter 23

Server Tools

Guidewire provides server tools to assist you with certain server and database administration tasks.
See also
• “Internal Tools” on page 411

Accessing the Server Tools

You must have the internaltools permission to access the Server Tools screens. In the base configuration, the
Superuser role has this permission by default. If the value of parameter EnableInternalDebugTools in config.xml
is true and the server is running in development mode, all users have access to the Server Tools screens.
To access the Server Tools screens, press ALT+SHIFT+T on any ClaimCenter screen after you log into the application.
See also
• “Server Modes” on page 57

Batch Process Info

Use the Server Tools Batch Process Info screen to view information about ClaimCenter batch processes, including
writer threads for work queues. Use the drop-down on the Batch Process Info screen to filter the batch process list.
This drop-down contains the following options.

Any Shows all batch processing types.

Schedulable Shows batch prossing types marked as Schedulable in the BatchProcesstype typelist. You define a schedule for
batch processes, including writer processes for work queues, in file scheduler-config.xml.
Runnable Shows batch procesing types marked as APIRunable in the BatchProcesstype typelist. It is possible to run these
types of batch processes using APIs.

From this screen, you can perform the following actions.

Server Tools 349

 System Administration Guide 9.0.5

Refresh Click to update the information in the Processes table.

Download Click to download some of the information on this screen as a HTML report. See “Download a Batch Process
History Report” on page 351 for details.
Suspend Stops the batch processing scheduler that triggers the execution of the batch processes. After stopping the
Scheduler scheduled, you can restart it using this same button.

The Batch Process Info screen contains the following areas or tabs that contain batch process information.

Processes Lists all the available batch processing types along with information about each individual batch process. It is also
possible to run certain actions on a selected batch processing type from this screen. See “Processes Table Columns”
on page 350 for more information.
Chart Shows the execution time in seconds and the number of operations performed by the batch process over time in a
graphical format.
History Shows records of past runs of the selected batch process in tabular form.

Note: It is possible to run writers for work queues either from the Work Queue info screen or from the Batch Process
Info screen.
See also
• “Administering Batch Processing” on page 85
• “Work Queues and Batch Processes, a Reference” on page 103
• “Processes Table Columns” on page 350
• “Chart and History Tabs” on page 351
• “Work Queue Info” on page 352

Processes Table Columns

The Processes area of the Server Tools Batch Process Info screen contains a number of columns. The column labels
have the following meaning:

Column Description
Batch Process Name of the batch processing type.
Description Description of the batch processing type.
Action Actions that you can perform on the selected batch processing type. These actions include:
• Run – Runs a batch process. The Run button is active for all batch process types that belong to the Batch
ProcessTypeUsage category UIRunnable.
• Stop – Stops an actively running batch process.
• Download History – Downloads a batch process history report for the selected batch process in HTML
format. See “Download a Batch Process History Report” on page 351 for more information.
You cannot start multiple runs of non-exclusive custom batch processes from the Batch Process Info screen.
Instead, you must use the maintenance_tools command to start multiple runs of non-exclusive custom
batch processes.
Last Run Date on which this batch processing type last run.
Last Run Status Completion status from the last run of this batch processing type.
Next Scheduled Run Date of the next scheduled run for this batch processing type.
Schedule Scheduling actions that you can perform on the selected batch processing type. These actions include:
• Stop – Disables the scheduled runs for the selected batch processing type.
• Start – Enables the scheduled runs for the selected batch processing type.

350 chapter 23 Server Tools

 System Administration Guide 9.0.5

Column Description
Cron-S M H DOM M Column header stands for seconds, minutes, hours, days of month, month, and day of week.
DOW

See also
• See “Work Queues and Batch Processes, a Reference” on page 103 to determine if it is possible to run multiple
instances of a batch processing type.
• See “Maintenance Tools Command” on page 418 for details of how to start multiple batch processes of the same
type.
• See the Integration Guide for a discussion of the meaning of the Exclusive property on a batch process.

Chart and History Tabs

The Server Tools Batch Process Info screen contains Chart and History tabs at the bottom of the screen. Select a batch
processing type to view its chart or history.
The Chart tab shows the execution time in seconds and the number of operations performed by the batch process
over time in a graphical format. The History tab includes a table of records of past runs of the selected batch process
in tabular form.
The History table includes the following information:

Column Description
Start Requested The time at which ClaimCenter received the request to start the process.

Started The time that a batch process started.

Completed The time that a batch process completed.
Scheduled Yes indicates that the start request was the result of the regular execution of a schedule. No indicates that a
user made the request manually.
Server Server on which the start request was made. The server on which the request was made is not necessarily the
server on which ClaimCenter executed the batch process.
Description Optional description.
Ops For batch processes that are work queue writers, the value of Ops (operations) is the number of work items
that the work queue processed. This number includes work items that failed.
Failed For batch processes that are work queue writers, the value of Failed is a counter that ClaimCenter increments
each time work item processing encounters an exception.
It is possible for a work queue to attempt to process a failed work item multiple times. Therefore, the Failed and
Ops numbers do not necessarily match the total number of work items.

Failure Reason For batch processes that are work queue writers, Failure Reason is the reason that a work item failed processing.

See also
• “The Work Queue Scheduler” on page 93

Download a Batch Process History Report

Procedure
1. Navigate to the Server Tools Batch Process Info page.
2. Select a batch process in the Processes table.
3. Click Download History in the Actions column of the row for that particular batch process.

Batch Process Info 351

 System Administration Guide 9.0.5

4. Select the date rage for the records that you want to download.
5. Click Complete Download.
6. Select the location for the local file download and click OK.
7. Unzip the download file into a local directory.
8. Find and double-click index.html to open the report.

Next steps
See also
• “Batch Process Info” on page 349
• “Maintenance Tools Command” on page 418

Work Queue Info

Use the Server Tools Work Queue Info screen to control and view information associated with work queues. From this
screen, you can track work queues as they process information. Each work queue has both a writer and one or more
workers. You can run the writer to add a batch to the work queue, and you can monitor the progress of the workers
processing the batch.
The Work Queue Info screen contains multiple tables that contain work queue information. These tables include:
• “Work Queue Table Columns” on page 352 table
• “Item Statistics Tabs and Columns” on page 353 table
Besides the work queue information available on the Work Queue Info screen, it is possible to download a number of
specialized reports from this screen as well.
Note: It is possible to run writers for work queues either from the Work Queue info screen or from the Batch Process
Info screen.
See also
• “Work Queues and Batch Processes, a Reference” on page 103
• “Work Queue Table Columns” on page 352
• “Item Statistics Tabs and Columns” on page 353
• “Work Queue Reports” on page 355
• “Batch Process Info” on page 349

Work Queue Table Columns

The Work Queue area of the Server Tools Work Queue Info screen includes a table containing information and
functionality related to work queues. The table column headings have the following meaning:

Column Description
Work Queue Name of the work queue.
Available Number of work items available for processing.
Checked Out Number of work items checked out by workers.
Failed Number of work items that failed during processing.
Executors Running Number of workers processing the work queue.

Cluster-wide State Work queue status, for example, started or stopped.

Writer Status Status of the writers.

352 chapter 23 Server Tools

 System Administration Guide 9.0.5

Column Description
Actions Actions that you can perform on the selected work queue. These actions include:
• Run Writer – Launches the writer to write work items for the work queue.
• Notify – Wakes workers by notifying the executor that there are items to process.
• Stop – Stops the selected work queue.
• Restart – Restarts the selected work queue.
• Download History – Downloads the historical instrumentation data for the work queue, in CSV format.

See also
• See “Worker Task Management” on page 99 for a discussion of the executor function.
• See “The Work Queue History Report” on page 357 for more information on the work queue history report.

Item Statistics Tabs and Columns

The Item Statistics area of the Server Tools Work Queue Info screen provides information on work items related to the
work queue selected in Work Queue table. This region has three tabs the contain a number of tables.

Tab For more information

By Writers “The By Writers Tab” on page 353
By Executors “The By Executors Tab” on page 354

Work Item “The Work Items Tab” on page 354

The By Writers Tab

The By Writers tab on the Server tools Work Queue Info screen contains item counts generated by the writer associated
with the work queue selected in the Work Queue table. Each row represents one wake period for the writer. These
table column headers have the following meanings.

Column Description
Process ID ID for the writer process.
Item Creation Time Time at which the writer woke and began writing work items. The first item in the table for a queue has a
creation time that matches the queue’s current Last Execution Time for the Writer value.
Server Name of the server running the work queue.
Scheduled Yes indicates that the start request was the result of the regular execution of a schedule. No indicates that a
user made the request manually.
Number of Items Total work items in the queue regardless of status.
Worker End Time Time at which the last worker completed the last item in the work queue.
Execution Time Time, in minutes, since the start of the process (the execution time so far).
Available Total number of available items in the queue.
Checked Out Number of items checked out by workers for processing.
Succeeded Number of items that completed successfully.
Failed Number of items that failed.

Work Queue Info 353

 System Administration Guide 9.0.5

The By Executors Tab

The By Executors tab on the Server Tools Work Queue Info screen lists active executors. The table column headers have
the following meanings:

Column Description
Hostname Server on which the executor is running.
Max. Number of Workers Maximum number of workers available to the executor.

Processed Items Number of items processed by the workers.

Exceptions Number of exceptions encountered during processing.
Failed items Number of work items that failed processing.
Status Status of the executor, for example, running.
Started Timestamp of the start of the executor.
Up For Length of time since the start of the executor.

Under the By Executors tab is a By tasks tab. The By tasks columns have the following meanings:

Column Description
ID The unique identifier of the task.
Writer The identifier of the writer process.
Success Whether the worker succeeded in the processing of the work items.
Checked out items The number of work items the worker checked out.
Processed items The number of work items the worker processed.
Exceptions The number of exceptions, if any, encountered during item processing.
Orphans Reclaimed The number of orphaned work items the worker adopted for processing.

Failed items The number of work items that failed.

Skipped items The number of items that the process skipped.
Started Timestamp of the start of the task.
Ended Timestamp of the end of completion of the task.
Active Whether the task is still active.
Consecutive Errors If processing resulted in exceptions, the number of consecutive work items found that resulted in
exceptions during processing by the worker.

The Work Items Tab

The Work Items tab on the Server Tools Work Queue Info screen lists work items. The table column headers have the
following meanings.

Column Description
ID Unique identifier of the work item.
Create time Timestamp of the work item creation time.

Update time Timestamp of the last update to the work item.

Available at Timestamp of when the work item is available processing. This value is null for failed work items.

354 chapter 23 Server Tools

 System Administration Guide 9.0.5

Column Description
Server Server that processed the work item.
Writer Writer that created the work item.
Attempts How many attempts a worker has made to process the item.
Activity ID ID of the activity involved. This field is only visible if you select the Activity Escalation work queue.
Subject Subject of the activity involved. This field is only visible if you select the Activity Escalation work queue.

ClaimCenter shows data on this screen during the active execution of database checks only.

Work Queue Reports

Use the Server Tools Work Queue Info screen to generate and download multiple report types of work queue data. You
can use the data from these reports to calculate different kinds of secondary data, for example, work queue
efficiency.

The Work Queue Report

The Work Queue report available from the Server Tools Work Queue Info screen contains the following linked HTML
files:
• Files that include a summary of the work queues
• Files that include detailed information for specific work queues
The report provides data for each worker by thread and by host, such as:
• How long since the start of the worker
• How many items the worker processed
• Throughput (items processed per minute of execution) per thread and per host
• Start and end times for the worker
• Last wake up time
• Items processed for each thread (cumulative, average, and maximum)
• Uptime (cumulative, average, and maximum)
• Execution time (cumulative, average, and maximum)
For each report, you can specify the following:
• The maximum number of writer runs, executors, and batches for each worker
• The number of hours for which to generate item distribution data in the report
Note: Internally, Guidewire sets the allowable maximum number of writer runs to show in the report at 150.

The Work Queue Runs View

The Work Queue report available from the Server Tools Work Queue Info screen includes a view called Work Queue
Runs. This view shows work queue statistics organized by writer run, including how long it took the writer to
produce work items and how long the workers processed those items. The view can be confusing if the writer is run
repeatedly before finishing the work items produced by the previous run.

Work Queue Info 355

 System Administration Guide 9.0.5

See also
• “Work Queue Reports” on page 355
• “Download a Work Queue Report” on page 356

Download a Work Queue Report

Procedure
1. Navigate to the Server Tools Work Queue Info page.
2. Click Download on the top-level menu.
3. Specify the parameters for the report.
4. Click Complete Download.
5. Select the location for the local file download and click OK.
6. Unzip the download file and double-click index.html to open the Work Queue report.
7. Click the Work Queue Runs link at the bottom of the Work Queue report to open the Queue Runs view.

Next steps
See also
• “Work Queue Reports” on page 355
• “The Work Queue Report” on page 355

The Work Queue Raw Data Report

The Work Queue Raw Data report available from the Server Tools Work Queue Info screen is a set of CSV-formatted
files. There is one CSV file for each work queue. The files contain time-sliced raw data from the ProcessHistory
and InstrumentedWorkerTask tables.
You can perform analysis of this data in third-party tools such as Microsoft Excel.
See also
• “Work Queue Reports” on page 355
• “The Work Queue Raw Data Report” on page 356

Download the Work Queue Raw Data Report

Procedure
1. Navigate to the Server Tools Work Queue Info page.
2. Click Download Raw Data on the top-level menu.
3. Select the date range for the records that you want to download.
4. Click Complete Download.
5. Select the location for the local file download and click OK.
6. Unzip the download file and open the work queue instrumentation reports individually.

356 chapter 23 Server Tools

 System Administration Guide 9.0.5

Next steps
See also
• “Work Queue Reports” on page 355

The Work Queue History Report

The Server Tools Work Queue Info screen includes the ability to download information on the history of a particular
work queue. The report, in CSV format, includes the following information:
• Process ID
• Writer start and end times
• Duration
• Failures by workers
You can clear the instrumentation data for all work queues by running the Work Queue Instrumentation Purge
process.
See also
• “Work Queue Reports” on page 355
• “Download the Work Queue History Report” on page 357
• “Work Queue Instrumentation Purge Batch Processing” on page 129

Download the Work Queue History Report

Procedure
1. Navigate to the Server Tools Work Queue Info page.
2. Select a work queue in the Work Queue table.
3. Click Download History in the Actions column of the row for that particular work queue.
4. Select the date range for the records that you want to download.
5. Click Complete Download.
6. Select the location for the local file download and click OK.
7. Unzip the download file and open the work queue history report.

Next steps
See also
• “Work Queue Reports” on page 355
• “The Work Queue History Report” on page 357

About Work Queue Efficiency

The Server Tools Work Queue Info screen provides a wide variety of data, along with types of multiple work queue
reports. It is possible to use this information to generate additional types of data. For example, the Work Queue
report contains information on the processing time for each item (Item Processing Time). Using this data, you can
calculate the efficiency of a work queue by dividing the work item processing time by the total active time of a
worker.

Set Log Level

Use the Server Tools Set Log Level screen to set a specific logging level for the different logging categories. The
logging levels that you specify in the Set Log Level screen persist until you change them or restart the server.
Work Queue Info 357
 System Administration Guide 9.0.5

The Logger drop-down presents the following types of logging categories:

Type Description
Guidewire Guidewire provides a number of default ClaimCenter logging categories. You can also see the list of
default Guidewire logging categories by running the system_tools command from a command prompt and adding
the -loggercats option.
Guidewire Guidewire provides a number of logging categories that apply to Guidewire internal classes. These logging
internal classes categories start with com.guidewire.*. These logging categories generally look like a fully qualified class
path.
Third-party Guidewire applications integrate with certain types of third-party software. The manufactures of this
software software provide their own logging categories. These logging categories start with org.*, for example, org.a
pache.* or org.eclipse.*. These logging categories generally look like a fully qualified class path.

Making Logging Level Changes Permanent

To make your log level settings permanent, you must edit file logging.properties and set the log level there.
Access this file from the Project window in Studio by navigating to configuration→config→logging, and then opening
logging.properties.
In the default ClaimCenter configuration, file logging.properties does not contain a unique logger definition for
each Guidewire logger. To add additional loggers to this file, see “Adding Loggers to the Logging Properties File”
on page 27.
Note: Some log4j loggers do not appear on the Set Log Level screen until actually used. This is a standard log4j
behavior.

Setting Logging Levels Through System Tools

It is also possible to set a logging level through the following system tools command.

system_tools -updatelogginglevel logger level

To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user su (in
the base configuration) and you must supply that user’s password.
To use this command, you must supply the name of a specific logger category (logger) and the new logging level
(level) for that logger. Use the system_tools -loggercats command option to see a list of valid ClaimCenter
logger categories.
You must refresh the Server Tools Set Log Level screen after using the system_tools command to see your changes
reflected in that screen.
See also
• “Application Logging” on page 25
• “The Logging Properties File” on page 26
• “System Tools Command” on page 422

View Logs
The Server Tools View Logs screen contains the following items:

Field Purpose
Log File Use to select the log file to view.
Filter Use to display the log file lines that contain the specified word or words.

358 chapter 23 Server Tools

 System Administration Guide 9.0.5

Field Purpose
Max Lines to Display Use to set the maximum number of lines to show on the screen.

By default, ClaimCenter writes log files to tmp/gwlogs/ClaimCenter/logs/. To specify a different location in

which the View Logs screen checks for log files, specify a different value for property guidewire.logDirectory in
file logging.properties.
See also
• “Application Logging” on page 25
• “The Log Files Directory and the View Logs Screen” on page 27

Info Pages
The Server Tools Info Pages provide information to help manage a ClaimCenter server and database. Guidewire
intends these screens for use by Guidewire Support, Integration Engineers, Database Administrators, and System
Administrators to diagnose existing and potential database-related performance problems. You can also use these
screens to review the results of a load operation.

Configuration
The Server Tools Configuration screen lists the values of the configuration parameters in your ClaimCenter
environment. This screen also includes a Download button. Click Download to download a copy of the following
configuration files:
• config.xml
• messaging-config.xml
• scheduler-config.xml
• work-queue.xml
You can find these files in the config folder within the downloaded ZIP file. The ZIP file also includes a current
directory, which includes the in-memory state of config.xml and work-queue.xml parameters on the server.
Guidewire makes the in-memory state available because it is possible to change certain configuration parameters
using a web service or JMX APIs after server startup.

Archive Info
Use the Server Tools Archive Info screen to view information about any archiving processing taken by ClaimCenter.
Note: the value of configuration parameter ArchiveEnabled must be true before you can view the Archive Info
screen.
On the Archive Info screen, you can take the following actions.

Refresh Click to update the information on the Archive Info screen. Clicking the Refresh button also refreshes the IArchi
veSource plugin.

Download Click to download archive information to an HTML report. This report is a summary of the information shown
on the Archive Info screen.
View Progress Click to open the Work Queue Info screen. From this screen you can view the progress of the Archive work queue.
You can also start an unscheduled run of the archive work queue from the Work Queue Info screen. For more
information, see “Work Queue Info” on page 352.
Export Upgrade Click to download and save a .dat file that contains information on the database version for a specific archive
Info operation.

Info Pages 359

 System Administration Guide 9.0.5

Import Upgrade Click to upload a .dat file that you previously exported. You must browse for a file (click Browse) to upload
Info before the Import Upgrade Info button becomes active.
Browse... Click to open a standard file picker dialog.

The Archive Info screen contains the following tables.

Overview The Overview table includes the following:

• The number of entities that ClaimCenter archived
• The number of items that the archiving process skipped or excluded
• The number of items that failed the archiving process
The screen information divides the excluded items into the following categories:
• Items that ClaimCenter excluded from archiving due to business logic
• Items that ClaimCenter excluded from archiving due to a failure
Click Reset to set the total number of items excluded to zero.
Archive The Archive Source Information table indicates the last refresh time of the Archive Info screen and the IArchiveSour
Source ce plugin. The Archive Source Information also shows the availability of the store, retrieve and delete services.
Information ClaimCenter derives these values from the following variables in Gosu class ArchiveSource:
• storeStatus
• retrieveStatus
• deleteStatus
Possible values for these services include:
• Available – The service is available.
• Failure – The last archive, restore, or delete operation failed.
• Manually – A user has manually flagged the service as unavailable.
• Not configured – The service is not yet configured.
• Not enabled – Archiving is not yet enabled.
• Not started – Archiving is not yet started.
• Queue – The service is not available. ClaimCenter, however, allows the queueing of user requests.
Archive As its name suggests, the Archive Summary by Datamodel Version table shows archiving information organized by
Summary by data model version. For each database version, the table shows the following:
Data Model • The number of entities ClaimCenter succeeded in archiving.
Version
• The number entities that ClaimCenter did not archive due to business logic.
• The number of entities that ClaimCenter did not succeed in archiving due to a failure.
Each excluded category has a Reset button to set the count of excluded entities back to zero.
Click a specific version to view additional archive information for that data model version. See “The Archive
Summary by Data Model Version Table” on page 360 for more information.

See also
• “Configuring Archive Logging Operations” on page 40
• Application Guide

The Archive Summary by Data Model Version Table

The Server Tools Archive Info screen contains an Archive Summary by Data Model Version table. This area organizes
archive data by data model version. Clicking a specific data model version link opens an Archive Summary for Data
Model (n, n, n, n, n) screen.
On the Archive Summary screen, you can do the following.

Reset counts Click Reset to set the value of Excluded or Failed items back to zero.

360 chapter 23 Server Tools

 System Administration Guide 9.0.5

Filter the information by Set a value for Begin Time and End Time, then click View.
time period
Review archived items Select the Archived tab to view a list of items archived with this data model version and for the
specified time period.
Review skipped, excluded, Select the appropriate tab to view the reason that archiving process skipped or excluded an item
and failed items from archiving, or the reason the items failed the archiving process. For each reason, you can click
Reset All Items to reset the count to zero.

Domain Graph Info

The Server Tools Domain Graph Info screen includes the following tabs:
• Graphs
• Warnings

IMPORTANT Guidewire strongly recommends that you review the Warnings tab for possible issues every time you
change the data model.

The Graphs Tab

The Graphs tab of the Server Tools Domain Graph Info screen contains the following items:
• A DOT formatted version of the archive domain graph. The DOT format is a means of showing object
relationships in plain text.
• A Download button, which if clicked, generates a ZIP file that contains the text version of the archive domain
graph and the means to view the graph visually.

The Warnings Tab

The Warnings tab of the Server Tools Domain Graph Info screen shows non-fatal violations of the archive domain graph
that ClaimCenter detected while starting the server. ClaimCenter provides warnings for these situations rather than
preventing the server from starting because it is possible to prevent the erroneous situation through business logic.
The server also performs other graph checks while starting. If these checks fail, the server does not start. Because
the server does not start, you cannot use the Archive Graph Info screen to view errors detected by these checks. Instead,
the server reports the error in the application log and prints the archive domain graph in DOT notation.
See also
• Configuration Guide

Consistency Checks
Use the Server Tools Consistency Checks screen to view and run consistency checks on the ClaimCenter database.
The screen consists of two tabs:
• Run consistency checks
• View consistency checks definitions
The Server Tools Consistency Checks screen executes the Database Consistency Check batch process. See “Database
Consistency Check Batch Processing” on page 113 for more information.

Info Pages 361

 System Administration Guide 9.0.5

Note: If the server running a database consistency check fails for some reason, ClaimCenter provides for a graceful
recovery. After the server becomes operational again, ClaimCenter starts the check at the place it last left off and
completes the check.

The Run Consistency Checks Tab

The Run Consistency Checks tab on the Server Tools Consistency Checks Info screen manages the process of running
database consistency check batch processing. From this screen, you can:
• Start, stop, pause, restart, or cancel consistency check batch processing.
• Set the tables or table groups on which to run the consistency checks.
• Set the number of workers to use in the batch processing.
• Set the type of consistency checks to run.
• Review the results of each consistency check batch processing in tabular format.
The Run Consistency Check tab contains the following items.

Item Action
Download all Click to download the consistency check results for all selected consistency check runs in the results table.
selected See “Run a Consistency Check from ClaimCenter” on page 364 for information on how to run a consistency
check.
Delete Click to delete the results of prior consistency check runs for those rows with a check mark in the results
table.
Refresh Click to update the information on the screen while processing is active.
Run Consistency Click to submit a batch processing job to perform one or more database consistency checks. This action
Checks executes the Database Consistency Check batch process. See “Database Consistency Check Batch
Processing” on page 113 for more information.
This button is not available if the Database Consistency Check work queue is not active,
See also
• “Run a Consistency Check from ClaimCenter” on page 364
• “Run a Consistency Check Using System Tools” on page 365
Pause/Resume Click to pause a currently executing batch processing job. During a pause in processing, ClaimCenter
Consistency changes the button label to Resume. Clicking the button resumes processing execution. If this button is not
Checks visible, click the Refresh button.
Cancel Consistency Click to cancel all currently executing batch processes. ClaimCenter displays this button only if there is a
Checks currently executing consistency check.
All tables Click to select All tables (default) to run consistency check against all database tables.
Specify tables If you select Specify tables, ClaimCenter opens a table picker from which you can select the database tables
Specify table against which the consistency checks run. You must select at least one table.
groups If you select Specify table groups, ClaimCenter opens a table groups picker from which you can select the
table groups against which the consistency checks run. You must select at least table group.
Change Click to change the number of workers used to execute the consistency check. Enter a positive integer
value. If you change the number of workers in an active work queue, ClaimCenter stops the existing work
queue and restarts it with the new number of workers.
This button is not available if the Database Consistency Check work queue is not active,
Check all types? Click to select Specify Types to see the list of available check types from which you can make a selection of

The Consistency Checks Results Table

After completing a consistency check, the results table columns have the following meanings.

362 chapter 23 Server Tools

 System Administration Guide 9.0.5

Column Description
Download Click the Download icon to download a ConsistencyCheckRundate.zip file that contains the set of database
reports generated by this consistency check run.
Download Errors Click the Download Errors icon to download a ConsistencyCheckRunErrorsOnlyRunDate.zip file that contains
the consistency check log file and stack trace. ClaimCenter displays this column only if there are SQL errors in
the database consistency check.
See “Correct a Consistency Check SQL Failure” on page 365 for more information.
View Click the View icon to open a pop-up from which you can view the same reports contained in the Consistency
CheckRundate.zip file, after you supply your user credentials. ClaimCenter displays this column in test and
development mode only. The column is not visible in production mode.
Delete Click the Delete icon to remove a consistency check row from the table.
Rerun Rerun a consistency check that has a SQL error. ClaimCenter displays this button only if there are SQL errors in
the database consistency check. See “Correct a Consistency Check SQL Failure” on page 365 for more
information.
Description List of tables against which the consistency checks ran.
With Errors Number of errors encountered by the consistency checks run.
Total Checks Total number of consistency checks that ran.
Not started Number of consistency checks that have not yet started in the current consistency checks run. Click the Refresh
button to update this data during a currently executing check run.
In progress Number of actively executing consistency checks at any given moment.
Finished Number of consistency checks that completed in this run.
Start time Time at which this set of consistency checks started.
End time Time at which this set of consistency checks ended.
Duration Length of time that this set of consistency checks took to run.
Version Database version, listing (in order):
• Application major version
• Application minor version
• Platform major version
• Platform minor version
• Data model version
See “Understanding Guidewire Software Versioning” on page 395.
ID Identifier (ID) of the stored results of this consistency check run.

If the consistency checks results table lists multiple check runs, use the check box next to a table row to select a
consistency check run for further action.
See also
• “The View Consistency Checks Definitions Tab” on page 363
• “Run a Consistency Check from ClaimCenter” on page 364
• “Run a Consistency Check Using System Tools” on page 365
• “Correct a Consistency Check SQL Failure” on page 365

The View Consistency Checks Definitions Tab

The View consistency checks definitions tab on the Server Tools Consistency Checks Info screen provides information on
the consistency checks available for each database table. In this tab, you can undertake the following actions.

Consistency Checks 363

 System Administration Guide 9.0.5

Action Description
Download Click Download to download a ZIP file that contains a set of linked HTML files that describe the consistency
consistency check checks that Guidewire provides in the ClaimCenter base configuration.
information
Search by table Search by table name to find the consistency checks related to a specified table. Most consistency checks
name operate on the specified table, but some checks, such as typelist table checks, operate on other tables as
well.
To search, enter a complete or partial table name in the Table name fragment field and click Search. The results
of the search show in a table that lists the table name, the consistency check name, and a description of
the consistency check.
To clear the results of the search, click Reset.
Filter by check Filter the list of consistency check types to see a list of all tables for which that consistency check is
type available.
View SQL query Review the SQL query used to generate a given database consistency check. First, select a consistency
check, then:
• Select the Command tab at the bottom of the screen to view the SQL command of the consistency
check. The SQL command retrieves a count of rows that violate the consistency check.
• Select the Query to identify rows tab at the bottom of the screen (if available) to view the SQL query used
to identify rows that violate the consistency check. SQL queries to identify rows that violate consistency
checks are not available for all check types.

See also
• “The Run Consistency Checks Tab” on page 362
• “Run a Consistency Check from ClaimCenter” on page 364
• “Run a Consistency Check Using System Tools” on page 365
• “Correct a Consistency Check SQL Failure” on page 365

Run a Consistency Check from ClaimCenter

Procedure
1. Navigate to the Server Tools Consistency Checks screen.
2. Select the Run Consistency Checks tab.
3. (Optional) Specify any, or all, of the following items:
• Description that ClaimCenter prepends to the standard description of the tables and checks in the
consistency check reports.
• Tables or table groups on which to run the consistency checks.
• Number of workers to use in executing the consistency check.
• Type of consistency check to run.
4. Click Run Consistency Checks.
5. After the batch process completes, select one of the following in the summary table:

Download arrow Downloads a Zip file that contains the full set of consistency check reports.
Download Errors arrow Downloads a Zip file that contains only the consistency checks that contain SQL errors.

View icon Opens a pop-up window from which you can view the full set of consistency check reports.

6. If you downloaded the consistency check file to your local system, unzip the file into its own directory.
7. Locate the index.html file and double-click it to open it in a browser.

364 chapter 23 Server Tools

 System Administration Guide 9.0.5

8. In file index.html, do the following:

• Click a table name to view all consistency checks related to that table.
• Click a check name to view all tables that the consistency check runs against.

Next steps
See also
• “The Run Consistency Checks Tab” on page 362
• “The View Consistency Checks Definitions Tab” on page 363
• “Run a Consistency Check Using System Tools” on page 365
• Installation Guide

Run a Consistency Check Using System Tools

Procedure
1. Open a command prompt.
2. Navigate to the following location in the ClaimCenter installation:

admin/bin

3. Run the system tools command with the -checkdbconsistency option:

system_tools -password password -checkdbconsistency [...]

You must supply a value for password. You can optionally supply additional parameters for the -
checkdbconsistency option.

Next steps
See also
• “System Tools Command” on page 422
• “The Run Consistency Checks Tab” on page 362
• “The View Consistency Checks Definitions Tab” on page 363
• “Run a Consistency Check from ClaimCenter” on page 364

Correct a Consistency Check SQL Failure

Before you begin

If a database consistency check fails due to a SQL error, ClaimCenter adds the following icons to the Server Tools
Consistency Checks screen:
• Download Errors
• Rerun

Procedure
1. In the ClaimCenter Server Tools Consistency Checks screen, click Download Errors next to the check that
generated the error.
2. Open the error report:
a. Click the number in the With Errors column.
b. On the details report that opens, click Details.

Consistency Checks 365

 System Administration Guide 9.0.5

c. Review the SQL query that generated the error.

d. Correct any identified errors.
The listed table name indicates the object against which the consistency check ran. The check name
indicates which consistency check actually generated the error.
3. In the ClaimCenter Server Tools Consistency Checks screen, click Rerun next to the consistency check that
generated the SQL error.

Next steps
See also
• “The Run Consistency Checks Tab” on page 362
• “The View Consistency Checks Definitions Tab” on page 363
• “Run a Consistency Check from ClaimCenter” on page 364
• “Run a Consistency Check Using System Tools” on page 365

Consistency Check Frequency

Guidewire recommends that you run all database consistency checks periodically during implementation and during
the stabilization period before going into live production. Running the consistency checks during the implementation
and stabilization phases frequently helps to discover issues with application configuration.

Upgrade
Guidewire recommends that you run all consistency checks before and after a database upgrade. Running these
checks before and after a database upgrade helps to verify the validity of the data and identify potential issues.
See also
• “Run a Consistency Check from ClaimCenter” on page 364
• “Run a Consistency Check Using System Tools” on page 365

Database Table Info

The Server Tools Database Table Info screen provides a way to access information about the tables used to store the
ClaimCenter data model. The screen contains the following buttons:

Verify Click to have ClaimCenter compare the database schema with the schema defined in the data model
metadata files. ClaimCenter shows any errors that it finds on the screen.
Download Database Click to download the results of the database schema verification. If there were no errors, the report
Schema Verification is empty.
Errors

Download Database Table Click to download a ZIP file containing a number reports that document each table in the ClaimCenter
Info data model.

See also
• “Database Table Info Reports” on page 366
• “Understanding the Database Table Info Reports” on page 368
• “View the Database Table Info Reports” on page 368

Database Table Info Reports

The Server Tools→Info Pages→Database Table Info screen provides the following reports.

366 chapter 23 Server Tools

 System Administration Guide 9.0.5

Screen Description
All Tables Provides information about all ClaimCenter tables.
Guidewire Version Lists schema version and build information for ClaimCenter.
Indexes by Table Lists the indexes on a table and provides information about the associated key
columns.
Spatial Indexes Provides information about the spatial indexes.
Primary Key Constraints by Table Lists the primary key constraints on tables and provides information about the fields
that reference the keys.
Foreign Key Constraints by Table Lists the foreign key constraints on tables and provides information about the tables
referenced by the keys.
Typekey Columns by Typelist Lists the referencing typekey columns for each typelist.
Number of columns and min/max row lengths Displays the number of columns and categories of columns and the minimum and
maximum row length in each table. Overly large row lengths in a database can lead to
inefficiencies in data queries.
Possibly Redundant Backing FK Indexes Lists foreign key indexes that may be redundant, including information about whether
the index is unique and if it is an extension.
Indexes with Shared Prefixes Lists indexes that share multiple leading key columns. It is possible to use this
information to find redundant indexes.
Indexes with the Same Key Columns Lists indexes that have the same key columns.
Indexes without a Description Lists indexes that do not have a description.
Indexed Views Lists any indexed views and the view definitions.
Event Paths from Tables to Listening Objects Shows paths from event-generating entities to non-event-generating entities. Each
row in the table contains a non-event-generating entity E, along with one of the paths
from an event-generating entity to E. ClaimCenter uses each path to generate a query
to find the event-generating entity instances that reference an instance of the non-
event-generating entity.
Event Paths to Listening Tables Shows the same paths as those in the Event Paths from Tables to Listening Objects report,
but the entities in the second column are the event-generating entities. Each entry in
the table contains an event-generating entity E, along with a path from E to a non-
event-generating entity.
Instrumentation Queries Lists the queries that ClaimCenter executes against the database while building the
data the comprises the download reports.

ClaimCenter copies table-specific information from each report category to the individual report for the respective
table, excepting the All Tables and Instrumentation Queries reports.

Database Table Info 367

 System Administration Guide 9.0.5

Understanding the Database Table Info Reports

The report information that you download from the Server Tools Info Pages→Database Table Info screen consists of the
following categories of information:
• Summary reports with links to detailed table reports
• Copies of specific configuration files.

Configuration Files
The download ZIP file contains several directories of configuration files:
• The config directory contains a number of ClaimCenter configuration files as defined at server startup.
• The current directory contains the in-memory state of the batch-process-config.xml, config.xml, and
work-queue.xml parameters on the server. Guidewire makes the in-memory state available because it is possible
to change certain configuration parameters using a web service or JMX APIs after server startup.

View the Database Table Info Reports

Procedure
1. Log into Guidewire ClaimCenter using an administrative account.
2. Navigate to the Server Tools Info Pages Database Table Info screen.
3. Click Download Database Table Info.
4. Save the download ZIP file.
5. Unzip the ZIP to a local directory.
6. Find and double-click file index.html to view a table of contents for the downloaded reports in a browser
window.
7. Do one of the following:
• Click a report type to open that report.
• Click config_files on the table of contents page to access copies of certain metadata configuration files.

Database Parameters
The Server Tools Database Parameters screen displays information about the database configuration. You can view the
information on-screen, or you can download a set of linked HTML reports that contain the same information.
To download and access the HTML reports, click Download Database Parameters Info, unzip the resulting file, and click
index.html.
To view the information on-screen, select a view type from the View drop-down list. Depending on the database type,
the View list contains the following items.

View Lists
Database and Driver Versions of the database and its associated driver.
Database Connection Pool Settings Connection pool settings as configured in database-config.xml if using
ClaimCenter to manage the connection pool. See “The dbcp-connection-pool
Database Configuration Element” on page 225 for more information on these
parameters.
If you use the application server to manage the connection pool, then this
screen does not show connection pool parameters. Instead, tune the
connection pool by using the Administrative Console of the application server.
Database Connection Properties Properties related to the database connection.

368 chapter 23 Server Tools

 System Administration Guide 9.0.5

View Lists
Guidewire Database Config Guidewire-specific database configuration parameters. The table lists the <data
base> element attributes specified in file database-config.xml or lists the
default value if file database-config.xml does not specify a value.
Guidewire Database Config Statistics Settings Guidewire-specific database configuration parameters related to statistics
gathering.
Guidewire Database Upgrade Configuration Guidewire-specific database configuration parameters related to upgrade as
defined by the <upgrade> element in file database-config.xml.
Guidewire Version Information about this specific version of ClaimCenter.
Linguistic Search Options Options defined for linguistic searching in ClaimCenter. See the Globalization
Guide for more information.
Linguistic Search Oracle Functions and Java Source Oracle functions, and Java source, for linguistic searching.

Oracle DB Options and Features Oracle database options.

Oracle DBA Auto Tasks Automated tasks defined for the Oracle database.
Oracle DBA Scheduler Jobs Scheduled jobs for the Oracle database.
Oracle NLS Instance Params Oracle database NLS (National Language Support) options.
Oracle NLS Session Params Oracle database NLS (National Language Support) options.
Oracle Patch History Patches applied to this Oracle database.
Oracle Permanent NLS DB Params Oracle database NLS (National Language Support) options.
Oracle Registry Oracle registry values.
Oracle Session Init Params Initial parameters of the Oracle session for the current connection with
ClaimCenter.
Oracle SGA Summary Info Information about the Oracle System Global Area (SGA) shared memory.
Oracle State of Current Instance Information on the current Oracle instance connected to ClaimCenter.
Oracle System Statistics Information on Oracle database statistics.
Queries Executed to Build Download SQL queries used to generate the information in the HTML download reports.
SQL Server Database Options Options set on the SQL Server database, such as auto create statistics and
auto update statistics, the recovery model, collation, and so forth.

SQL Server Server Global Server Settings Global server settings for the SQL Server instance.
SQL Server Server Instance Attributes and Values Attributes and values for the SQL Server instance connected to ClaimCenter.
SQL Server Session Properties Properties of the SQL Server session for the current connection with
ClaimCenter.
Summary of Queries Executed to Build Download Number of queries used, and the execution time, to generate the information
in the HTML download reports.

Database Storage
The Server Tools Database Storage Information screen provides information about the space and memory taken up by
the database on the ClaimCenter server. You can both view and download database storage information from this
screen.
The following tables lists the filtering options for the database storage information:

Info Pages 369

 System Administration Guide 9.0.5

Option Available Description

Include Estimation of Compression Oracle If checked, you need to also select the compression level for estimating
Savings for Tables and Indexes SQL Server savings.
Select Compression Level for Estimating Oracle Only available if you chose to include estimation of compression savings in
Savings SQL Server the database storage information. Options include:
• Oracle – Advanced
• SQL Server – Screen, Row
Collect Index Physical Stats for all tables SQL Server If you select Yes, then ClaimCenter includes statistics on all tables in the
database.
If you select Specify tables, ClaimCenter includes statistics only on the
database tables that you select.
Select Mode for Collecting Index SQL Server Options include:
Physical Stats • None
• Detailed
• Limited
• Sampled

After setting the desired filtering options, chose one of the following:
• To see the database storage information on the current ClaimCenter screen, click Display Database Storage Info.
• To download the database storage information to view later, click Download Database Storage Info.
After you click Display Database Storage Info, the screen shows information at the bottom of the screen, along with a
drop-down that you can use to filter the information.

IMPORTANT Guidewire recommends that you download and save the database storage information immediately
before and after an upgrade or other significant database change. This information sets a point of reference that you
can provide to Guidewire Support if requested.

Oracle Database Options

To filter the information in the Server Tools Database Storage Information screen, select one of the following options
from the Storage Set to Display drop-down filter:

Storage Set to Description

Display
Guidewire Version Guidewire product-specific information such as application and platform version.
Indexes Alloc Space Space allocation of each index on a table, in megabytes.
Oracle LOBs Alloc Space allocation information for Large Object Blocks (LOBs), sorted by LOB name.
Space

Oracle User LOBs Space allocation information similar to that shown for Oracle LOBs Alloc Space, sorted by table name.
Queries Executed to List of SQL queries used to generate the data. The data includes the SQL used to generate the query and
Build Download other information such as the number of rows returned the time it took for the query to run.
Summary of Queries Simple summary of the number of queries involved in generating the data and the total database time
Executed to Build that the queries took to execute.
Download

Table Alloc Space + Size in megabytes for each table in the database.
Estimated Advanced
Compression Settings

370 chapter 23 Server Tools

 System Administration Guide 9.0.5

Storage Set to Description

Display
The information that you see depends on the filter options that you set:
• If you select the Include Estimation of Compression Savings for Tables and Indexes option, ClaimCenter
modifies the storage set name to indicate that fact and provides the requested information.
• If you do not select the Include Estimation of Compression Savings for Tables and Indexes option, you see only
Table Alloc Space as the storage set name. ClaimCenter does not show compression estimation savings
information.
Tablespace Space Size of each tablespace in megabytes, along with information on how much of the space is in use or is
free space.
Tablespaces List of each tablespace in the database along with related information.
User Indexes Information on each user index in the database, selectable by index name.
User Tables Information on each user table in the database, selectable by table name.

SQL Server Database Options

To filter the information in the Server Tools Database Storage Information screen, select one of the following options
from the Storage Set to Display drop-down filter:

Storage Set to Description

Display
Data Spaces Lists the filegroups taken up by the data and the amount of space taken and
allocated by ClaimCenter.
Database Space Details about the amount of disk spaced taken up by the database.
Guidewire Version Guidewire product-specific information such as application and platform version. See
“Understanding Guidewire Software Versioning” on page 395.
Index Physical Statistics + Estimated Lists the statistics about indexes on the physical table. Includes information such as
Database Compression Savings for Page minimum, average, and maximum record size. To change which tables and indexes
Level Components the Index Physical Statistics filter shows, select a new index.
The information that you see depends on the filter options that you set:
• If you select the Include Estimation of Compression Savings for Tables and Indexes option,
ClaimCenter modifies the storage set name to indicate that fact and provides the
requested information.
• If you do not select the Include Estimation of Compression Savings for Tables and Indexes
option, you see only Index Physical Statistics as the storage set name. ClaimCenter
does not show compression estimation savings information.
Index Usage Stats Information on the usage of an index on a table, selectable by table name.
Indexes with High Fragmentation Display average percentage of fragmentation for indexes in the database.
Queries Executed to Build Download List of SQL queries used to generate the data. The data includes the SQL used to
generate the query and other information such as the number of rows returned the
time it took for the query to run.
Summary of Queries Executed to Build Simple summary of the number of queries involved in generating the data and the
Download total database time that the queries took to execute.
Tables and Indexes Lists paging and allocation type of a table and its indexes. To change which table the
Tables and Indexes filter shows, select a new table.

TempDB Summary Shows paging information for the database.

Database Storage 371

 System Administration Guide 9.0.5

Data Distribution
Use the Server Tools Data Distribution screen to a run batch processing job that generates data on the distribution of
various items in the database. You can then view this information on-screen or download a set of reports that details
this information.
There are multiple categories of data distribution reports.

Comparison The report shows data for the various items selected for inclusion in any of the comparison reports. It also
reports shows the individual row count for the data, as of that date. The intent of this report is to provide a way to
visualize data growth. The download ZIP file contains an HTML report plus separate CSV reports. The HTML
report contains distinct columns representing the data from each report used for comparison.
Combined The report combines information from multiple runs. The intent of the report is to provide a way to create
reports smaller reports that require less generation time and then combine the information into one report. The
download ZIP file contains an HTML report that contains information on each of the previous reports combined
into this report plus tables that contain the combined data.

It is also possible to start the data distribution batch process (DataDistribution) directly from the command
prompt by using a maintenance_tools command option.
• “Generate and View a Data Distribution Report” on page 372
• “Download Comparison and Combined Data Distribution Reports” on page 372
• “Maintenance Tools Command” on page 418

Generate and View a Data Distribution Report

Procedure
1. Navigate to the Server Tools Info Pages and select Data Distribution.
2. Select from the available options listed under Data Distribution Batch Job Parameters.
3. Click Submit Data Distribution Batch Job.
4. After the batch job completes, select one of the following in the summary table:

Download arrow Downloads an DataDistribution.zip file that contains the set of database reports.

View icon Open a pop-up window from which you can view the same reports contained in the DataDistributio
n.zip file, after you supply your user credentials.

5. If downloaded the report to your local system, unzip the download Zip file into its own directory.
6. Locate the index.html file and double-click it to open it in a browser.
7. Use the links on the screen to navigate through the distribution reports.

Next steps
See also
• “Data Distribution” on page 372
• “Download Comparison and Combined Data Distribution Reports” on page 372

Download Comparison and Combined Data Distribution Reports

Before you begin

To create either a comparison or a combined data distribution report, two or more data distribution reports and their
output must exist in the database.

372 chapter 23 Server Tools

 System Administration Guide 9.0.5

Procedure
1. Navigate to the Server Tools Info Pages→Data Distribution screen.
2. In the summary table, select (check) at least two of the generated reports.
ClaimCenter enables the following download buttons:
• Download Comparison Zip File
• Download Combined Zip File
3. Click the appropriate button.

Database Statistics
The Server Tools Database Catalog Statistics Information screen provides reports about out-of-date statistics in the
database indexes, histograms, staging tables, and ClaimCenter application tables. This screen is not available with
the development-only QuickStart database.
The Database Statistics screen contains the following tabs.

Tab Description
Database Statistics Use to generate and download database statistics reports for the entire database or for specific tables. See
Information “Generate and Download a Database Statistics Report” on page 374.
Execution History Use to view information about individual database statistics reports and take action with respect to each
report. See “Working with Database Statistics Reports” on page 374.
Oracle Statistics Use to work with Oracle database preferences for database table statistics. This tab is only available after
Preferences you set the useoraclestatspreferences attribute to true and perform an application upgrade.
See “Using Oracle AutoTask for Statistics Generation” on page 287 for more information.

Database Statistics Generation

Batch processing type Database Statistics (DBStats) generates the data available on Database Catalog Statistics
Information screen.

Development Mode
In development mode, it is possible to run Database Statistics batch processing in any of the following ways:
• From a command prompt, using the -updatestatistics option of the system_tools command
• From the Execution History tab of the Server Tools Database Statistics screen
• As a scheduled batch process

Info Pages 373

 System Administration Guide 9.0.5

Production Mode
In production mode, it is possible to run Database Statistics batch processing in the following ways only:
• From a command prompt, using the -updatestatistics option of the system_tools command.
• As a scheduled batch process

Oracle AutoTask
For Oracle databases, it is possible to use the Oracle Autotask infrastructure to manage the collection of database
table statistics. To use Oracle AutoTask, do the following:
• Disable any scheduled runs of DBStats batch processing.
• Set attribute useoraclestatspreferences attribute on the <databasestatistics> element in file database-
config.xml to true.
You must use either Oracle AutoTask or DBStats batch processing to manage the collection of database statistics.
Do not attempt to use both methods simultaneously.
See also
• “Understanding Database Statistics” on page 279
• “Managing Database Statistics using System Tools” on page 282
• “Using Oracle AutoTask for Statistics Generation” on page 287
• “Generate and Download a Database Statistics Report” on page 374
• “Working with Database Statistics Reports” on page 374
• “System Tools Command” on page 422

Working with Database Statistics Reports

To access the Database Catalog Statistics Information screens, click Info Pages→Database Statistics in the left-hand
navigation pane of the Server Tools screen. Depending on the database type, you can access the following tabs from
this screen:

Tab For more information

Database Statistics Info “Generate and Download a Database Statistics Report” on page 374
Execution History “The Execution History Tab” on page 375
Oracle Statistics Preferences “The Oracle Statistics Preferences Tab” on page 375

Generate and Download a Database Statistics Report

About this task

Use the Server Tools Database Statistics screen to generate database statistics about how the ClaimCenter application
and data model interact with the physical database.

Procedure
1. Log into Guidewire ClaimCenter using an administrative account.
2. Navigate to the Server Tools Info Pages→Database Catalog Statistics Information screen.
3. Select one of the following values for the View database catalogs statistics on all tables option:

Yes View statistics data for all database tables. This selection can take a few seconds to complete, depending on the
size of your database.

374 chapter 23 Server Tools

 System Administration Guide 9.0.5

No View statistics data for the selected tables only. If you select this option and do not select any tables, ClaimCenter
shows statistics data from the database metadata only.

4. Click Download.
5. Save the report ZIP file to a local directory.
6. Unzip the file.
7. Double-click file index.html to open the HTML report summary.
8. Use the report links to navigate through the various database statistics reports.

Next steps
See also
• “Generate and Download a Database Statistics Report” on page 374
• “Working with Database Statistics Reports” on page 374

The Execution History Tab

The Execution History tab of the Server Tools Database Statistics screen lists information about each run of the batch
process that updates database statics. This information includes the following:
• Date and time of the start and stop of the database statistics generation
• Type of database statistics generation, either full or incremental
• Description of the particular database statistics generation
From this screen, you can also perform the following actions.

Action Description
Refresh Update the contents of the summary table.
Run Incremental Statistics Generate incremental database statistics. This action updates database statistics for tables exceeding
the change threshold only. This functionality is available in development mode only.
Run Full Statistics Generate full database statistics. This functionality is available in development mode only.
Download Click the download arrow to download the data from this report.
Delete Click the trash can icon to delete this data row from the summary table.

The Oracle Statistics Preferences Tab

The Oracle Statistics Preferences tab presents information about the table statistics preferences set for the Oracle
database. To view this information, navigate to the following location in Guidewire ClaimCenter:
Server Tools Info Pages→Database Statistics screen, Oracle Statistics Preferences tab
To be able to view the Oracle Statistics Preferences tab:
• The database is Oracle.
• Attribute useoraclestatspreferences on the databasestatistics element in file database-config.xml is
set to true.
Note: You must perform an upgrade (either full or rolling) after setting attribute useoraclestatspreferences to
true in order for the change to the useoraclestatspreferences attribute to become effective.

Actual and Configured Table Preferences

To configure database statistics in BillingCenter, one sets statistics options in file database-configl.xml, either at
the global database level, or, at the individual table level. To be clear, you set statistics options in database-
configl.xml, which BillingCenter then uses to set the actual table statistics preferences during the upgrade.

Database Statistics 375

 System Administration Guide 9.0.5

It is also possible to set table statistics preferences directly in the Oracle database by executing the following
command:

DBMS_STATS.SET_TABLE_PREFS

If you set table statistics preferences directly, the actual table statistic preferences no longer match the configured
table statistics preferences. During a database upgrade, BillingCenter ignores any actual table statistics preferences
and sets table statistics preferences to those defined in the new database-config.xml file. The information
provided on the Oracle Statistics Preferences tab provides a mechanism to capture direct changes made to the table
statistics preferences that are lost during a database upgrade

Button Actions
The following list describes the actions of the individual button in the Oracle Statistics Preferences tab.

Button Action
Refresh Refreshes the table information on the screen.
Download Downloads the database-config table statistics options as a JSON file.
Reapply Config Reapplies the table statistics options configured in file database-config.xml to the database,
discarding any preferences set outside the application. As you initiate this process,
BillingCenter inserts an entry into the application log and then inserts another entry at the
end of the process.
Generate Config to Match Actual Generates an XML file that details the table statistics preferences actually in use in the
database.
Dev Mode only (Drop-down) Selects that environment in which to generate the table statistics.

You can also filter the list of tables using the drop-down at the right of the tab.

Oracle Statspack
The Server Tools Oracle Statspack screen provides a means to download HTML reports based on any two Oracle
database statspack snapshots from the same instance start-up time. You create statspack snapshots by using a tool
such as SQL*Plus or SQL Developer. Also, Oracle provides a script called spauto.sql that you can modify and run
to automate statspack snapshot gathering.
The Server Tools Oracle Statspack screen is available only if the database server is Oracle. For ClaimCenter to display
statspack information, you must also:
• Install the statspack package in your Oracle database (spcreate.sql).
• Grant SELECT privileges on all the PERFTEST tables to the ClaimCenter database user.
If you do not install the statspack or fail to grant the correct permission, ClaimCenter displays an error message on
the screen. You cannot select any snapshots on the screen either. Refer to the Oracle documentation for statspack
installation instructions.

Guidewire Recommendations
Guidewire recommends the following with regards to Oracle statspack snapshots:
• Collect statspack snapshots at regular intervals if you do not have a license for Oracle AWR.
• Collect the snapshots at level 7 or higher to collect execution plan and segment statistics.
• Regularly purge statspack snapshots older than a certain period.

376 chapter 23 Server Tools

 System Administration Guide 9.0.5

Guidewire recommends that you use the Guidewire AWR tool, rather than Oracle Statspack, if you have a license
for the following:
• Oracle Diagnostics package
• Tuning package
If you do not have these licenses, Guidewire recommends that you acquire the two licenses.
See also
• “Oracle AWR” on page 377

Oracle AWR
The Server Tools Oracle AWR Information screen is available only if the database server is Oracle. Use the Oracle AWR
Information screen to generate a set of Guidewire performance reports using AWR snapshots that you define in the
database. The Guidewire AWR reports provide a view of the database activity that contains more detailed
information than the Oracle Standard AWR report available with the Oracle database.
The Guidewire AWR reports provide the following additional information:
• Messaging analysis
• Concurrent batch processes
• Distributed worker activity
• Database statistics
The Guidewire AWR reports require that you have a license for the following:
• Oracle Diagnostics package
• Tuning package, if you select either Probe in Memory SQL Monitoring or Probe on Disk SQL Monitoring
Refer to the Oracle documentation for details.
See also
• “Oracle Statspack” on page 376
• “Download an Oracle AWR Unused Indexes Report” on page 379

Generate Guidewire AWR Reports

About this task

Use the Server Tools Oracle AWR Information screen to generate a set of performance reports using AWR snapshots
that you define in the database.

Procedure
1. Log into Guidewire ClaimCenter using an administrative account.
2. Navigate to the Server Tools Info Pages→Oracle AWR Information screen.
3. Set the options for the report.
See “Automatic Generation of Oracle Standard AWR Reports” on page 379 for a discussion of the Include
native Oracle report option.
4. Select two database snapshots from the list at the bottom of the screen.
Each snapshot must share the same Oracle instance startup time.
5. Click Generate Perf Report.
6. After ClaimCenter completes generating the report, select one of the following:

Download arrow Downloads an AWRReport.zip file that contains the set of database reports.

Info Pages 377

 System Administration Guide 9.0.5

View icon Open a pop-up window from which you can view the same reports contained in the AWRReport.zip
file, after you supply your user credentials.

Generate Guidewire AWR Reports Using System Tools

Before you begin

Generating a Guidewire AWR report using system tools requires that you know the ID of two database snapshots.

Procedure
1. Open a command prompt.
2. Navigate to the following location in the ClaimCenter installation:

admin/bin

3. Enter the following command to generate a list of database snapshot IDs:

system_tools -password password -oraListSnaps numSnaps

You must enter a value for password. You must limit the list of snapshots by entering a value for numSnaps.
4. Enter the following command to generate the Guidewire AWR report:

system_tools -password password -oraPerfReport beginSnapshotID endSnapshotID

To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user
su (in the base configuration) and you must supply that user’s password.
You must enter the IDs of two database snapshots.

Result
The system_tools -oraPerfReport command option reports the process ID of the process generating the
performance report. You can check on the status of this process using the -processstatus option of the
maintenance_tools command.

Next steps
See also
• “System Tools Command” on page 422

Generate Oracle Standard AWR Reports Using a SQL Script

About this task

Guidewire provides a SQL script that you can execute against the database server to generate the Oracle Standard
AWR reports.

Procedure
1. Log into Guidewire ClaimCenter using an administrative account.
2. Navigate to the Server Tools Info Pages→Oracle AWR Information screen.
3. Generate and download an AWRReport.zip file as described in “Generate Guidewire AWR Reports” on page
377.
4. Extract the contents of the AWRReport.zip file to a local directory.

378 chapter 23 Server Tools

 System Administration Guide 9.0.5

5. Navigate to the following directory:

AWRInfo→sqlscripts
6. Execute the following script against the database server:

oraclescripts.sql

Executing this script creates an Oracle Standard AWR report.

Automatic Generation of Oracle Standard AWR Reports

Guidewire provides the means to generate an Oracle Standard AWR report automatically as you generate a
Guidewire AWR report. To do so, ensure that you include report option Include native Oracle AWR report in the list of
options against which to run the report. The ClaimCenter base configuration sets (checks) this option by default.
To generate a report with this option, the Oracle database user must have EXECUTE privilege for database package
DBMS_WORKLOAD_REPOSITORY. If the database user does not have the required privilege, ClaimCenter does not
generate a report and prints a message to the application log.
If the required privilege does not exist for the database user, do one of the following:
• Request that the database administrator grant the required privilege and rerun the report from Oracle AWR screen.
• Manually execute script oraclescripts.sql from the database server.
See also
• “Generate Oracle Standard AWR Reports Using a SQL Script” on page 378

Oracle AWR Unused Indexes Information

The Server Tools Oracle AWR Unused Indexes Information screen provides the means to generate and download a report
that contains information on the following types of indexes:
• Indexes that have no logical or physical reads
• Indexes that are not found in query plans
The Oracle AWR Unused Indexes Information screen is available only if the database server is Oracle.
See also
• “Oracle AWR” on page 377

Download an Oracle AWR Unused Indexes Report

About this task

The Server Tools Oracle AWR Unused Indexes Information report contains information on indexes that have no logical or
physical reads or indexes that are not found in query plans.

Procedure
1. Log into Guidewire ClaimCenter using an administrative command.
2. Navigate to the Server Tools Info Pages→Oracle AWR Unused Indexes Information screen.
3. Set the options for the report.
4. Select two database snapshots from the list at the bottom of the screen.
Guidewire recommends that you select snapshots that have a wide range.
5. Click Download.
6. In the download dialog, set the download location.
7. Click OK to download and save the report.

Oracle AWR 379

 System Administration Guide 9.0.5

8. Open the downloaded ZIP file and click index.html to open the index to the linked set of report files.

Oracle Outlines
The Server Tools Oracle Outlines screen is only available if the database server is Oracle. The screen contains
information on any Oracle outlines defined in the ClaimCenter Oracle database. Oracle defines an outline as a
collection of hints associated with a specific SQL statement, used to provide SQL execution plan stability. Consult
the Oracle documentation on how to write and use Oracle Outlines.
The Oracle Outlines summary table contains the following information:

Name Name of the Oracle outline. Click to open the Outline Details screen. This screen contains the SQL hints used to
define the outline.
Category Optional name used to group stored outlines.
Used Whether the Oracle database has ever used this particular outline.
Time Stamp Date and time of the last use of this outline.

Version Oracle database version.

SQL SQL query text that creates the database outline.
Signature Unique identifier for this outline.
Compatible Whether the stored outline is compatible with this database version.

Enabled Whether Oracle enables this outline in the database.

Note: Oracle AWR contains a column that indicates if ClaimCenter used an Oracle Outline for a given SQL
statement.
See also
• “Oracle AWR” on page 377
• “View an Oracle Outlines Report” on page 380

View an Oracle Outlines Report

About this task

The Server tools Oracle Outlines screen contains information on any Oracle Outlines defined in the Oracle database.

Procedure
1. Log into Guidewire ClaimCenter using an administrative command.
2. Navigate to the Server Tools Info Pages→Oracle Outlines screen.
3. Click Download.
4. In the download dialog, set the download location.
5. Click OK to download and save the report.
6. Open the downloaded ZIP file and click Outlines.html to open the report.

380 chapter 23 Server Tools

 System Administration Guide 9.0.5

Next steps
See also
• “Oracle Outlines” on page 380

SQL Server DMV Snapshot

The Server Tools SQL Server DMV Snapshot screen is available only if the database server is SQL Server. Use this
screen to generate and download performance reports using SQL Server Dynamic Management Views.
It is also possible to generate a SQL Server DMV report using the -mssqlPerRpt option of the system_tools
command.
See also
• “System Tools Command” on page 422

Generate SQL Server DMV Snapshot Report

Procedure
1. Log into Guidewire ClaimCenter using an administrative report.
2. In the left-hand navigation pane, navigate to Server tools Info Pages→SQL Server DMV Snapshot.
3. (Optional) Select Include Database Statistics if you want to include database statistics information in the report.
4. Click Generate Perf Report.
This action launches an internal batch process that gathers performance data and creates the report.
5. After the batch process completes, select one of the following in the summary table:

Download arrow Downloads an DMVReport.zip file that contains the set of database reports.

View icon Open a pop-up window from which you can view the same reports contained in the DMVReport.zip
file.

6. After you download the DMVReport.zip file, unzip the file into its own directory.
7. Locate file index.html and double-click it to open it in a browser.
8. Use the links on the screen to navigate through the distribution reports.

Microsoft JDBC Driver Logging

The Server Tools Microsoft JDBC Driver Logging screen is available only if the database server is SQL Server. Use this
screen to specify the following:
• The logging level for the Microsoft JDBC driver. Be cautious setting the logging level, as detailed logging can
slow the system significantly.
• The logging format, either Simple, for a more readable format, or XML for XML output, usually parsed by another
system.
• The log file location, adding special components that ClaimCenter replaces at runtime. For example, use %u to
append a unique number to each log to avoid conflicts.
If you have already enabled logging through database-config.xml or from previous use of this screen, use this
screen to make additional changes to reset the logging level. After clicking Set Logging Level, ClaimCenter flushes
and closes any existing logging files before beginning the new trace. If you choose OFF as the logging level,
ClaimCenter disables any current logging as well as flushing and closing any existing logging files.
The ability to control logging of the Microsoft JDBC driver through ClaimCenter only works if using the internal
connection pool, not if using an external JNDI data source connection pool.

Info Pages 381

 System Administration Guide 9.0.5

Note: Using this screen is a better option if tracing a particular operation, in order to minimize system impact and
size of the trace file.
See also
• Installation Guide

Load History
The Server Tools Load History Information screen displays information about specific ClaimCenter database operations.
For example, loading data into the staging tables impacts the loader history information on this screen.
On this screen:
• Click Refresh to reload and update the table data.
• Click Edit to make the Description field for each load history writable.
The load history summary table contains the following information:

Download Click the Download arrow to download a LoadHistoryInfo.zip file that contains a set of HTML reports. The
reports consist of a summary table and a set of links to individual reports that load different views of the
database operation data onto the screen. These are the same reports that are available by clicking the View
icon.
View Click the View icon to view the on-screen Load History Detail report for the selected database operation. The
detail view consists of a summary table and a set of tabs that load different views of the database operation
data onto the screen. These are the same reports that are available for download by clicking the Download
icon.
Delete Click the trash can icon to remove the data for this database operation.
Load Operation Type of database operation. This can be, for example, any of the following:
Type • Database table load operations
• Staging table clearing operations
• Database statistics generation operations
Start Time Start date and time of the database operation.
End time Completion date and time of the database operation.
Duration Length of time, in seconds, to complete the operation.
Error Count Number of reported errors for this database operation..
Calling User Name of user who initiated this database operation.
Description Click Edit to make the Description field for each database operation row writable. Click Update after entering
text to save your work and update the field.

See also
• “View a Load History Report” on page 382
• “The Load History Detail Report” on page 383

View a Load History Report

Procedure
1. Log into Guidewire ClaimCenter using an administrative account.
2. Navigate to the Server Tools Load History Information screen.
3. For the database load operation that interests you, select one of the following in the summary table:

Download arrow Downloads a LoadHistoryInfo.zip file that contains the set of database reports.

382 chapter 23 Server Tools

 System Administration Guide 9.0.5

View icon Opens a new screen that displays the Load History Detail report. See “The Load History Detail Report” on
page 383 for details.

4. If you downloaded the report file, unzip the file into its own directory.
5. Locate the index.html file and double-click it to open it in a browser.
6. Use the links on the screen to navigate through the linked reports.

The Load History Detail Report

The Server Tools Load History detail report contains a summary table for the selected database operation. As with the
main Load History Information table, the report summary view lists information about the type of database operation,
the user who initiated the operation, and similar information.
Underneath the report summary table is a set of tabs, each of which loads a different view of the load operation data
onto the screen. The following list describes these tabs.

Parameters Lists the values of the configuration parameters used in generating the data for the database operations
reports.
Steps Lists the individual steps in the data load operation. Click a step to view detail data about that step.
Row Counts Lists information about database tables impacted by the data load. Use the information on this screen to
quickly assess whether the amount of data loaded by operation was the amount that you expected the
operation to load.
Integrity Checks Lists the integrity checks that ClaimCenter ran against each affected database table before the data load
operation.
Inserts Lists the results of the SQL INSERT_INTO queries that ClaimCenter ran against the affected database tables.
Callbacks Lists the operations that ClaimCenter executes before and after a staging table load operation.
Statistics Lists the SQL commands used to generate database statistics.
Commands

Parameter Modification
The following table describes how to set the database parameter values.

Parameter How to set

allowRefsToExistingNonAdminRows Use the table_import -allreferencesallowed command prompt option.

clearErrorTable Use the table_import -clearerror command prompt option.

parallelism Modify file database-config.xml.
populateExclusionTable Use the table_import -populateexclusion command prompt option.
updateDBStatisticsWithEstimates Use the table_import -estimateorastats command prompt option.

See also
• “Load History” on page 382
• “The Load History Detail Report” on page 383
• “Import Tools Options” on page 417
• Integration Guide

Load History 383

 System Administration Guide 9.0.5

Load Integrity Checks

The Server Tools Load Integrity Checks screen reports on the SQL integrity checks that run as a database load
operation executes. For each integrity check, the screen lists the SQL query that the check performs, along with a
description of the integrity check.
This screen has two tabs.

View by Staging Table This tab lists the set of integrity checks that ClaimCenter executes against a specific staging table. Use
the Staging Table drop-down to select the table of interest.
View by Load Error This tab lists the set of tables against which ClaimCenter runs a particular integrity check. Use the Load
type Error Type drop-down to select a specific integrity check.

In both tabs, you are able to set the value of Allow Non Admin References to true. If you do, ClaimCenter checks foreign
key references to administrative tables on load, such as users and groups. In the base configuration, Guidewire
disables these references by default.
See also
• Integration Guide

Load Errors
The Server Tools Load Errors screen displays errors generated by failed integrity checks. You can use this screen to
drill down through a table name to the specific error generated by a load operation. Errors relate to a particular
staging table row. For each error, the Load Errors screen shows:
• The table
• The row number
• The logical unit of work ID (LUWID)
• The error message
• The data integrity check query that failed.
In some cases, ClaimCenter cannot identify or store a single LUWID for the error. For example, this might happen
for some types of invalid ClaimCenter financials imports.

Runtime Environment Info

The Server Tools Runtime Environment Info screen lists information about the runtime environment for ClaimCenter.
This information includes Guidewire platform and ClaimCenter build information, system properties, and
environment variables.

Safe Persisting Order

The Server Tools Safe Persisting Order screen provides information on the following:
• The order in which ClaimCenter writes object data to the database during a bundle commit.
• The order in which ClaimCenter runs the Preupdate rules on a set of objects.
The screen contains a table with columns that show the following:

Column Description
Entity Entity name
Order Entity ranking order
Table Entity database table name
Preupdate Whether the entity triggers a Preupdate rule set

384 chapter 23 Server Tools

 System Administration Guide 9.0.5

To see only those objects affected by Preupdate rules, select With rules only from the drop-down filter.

Bundle Commits to the Database

ClaimCenter uses the defined object ordering in every bundle write to the database for insert, write, or delete
operations. Thus, during a commit to the database of a bundle containing multiple objects, ClaimCenter writes the
objects to the database in the order listed in the table Order column.

Preupdate Rules
In running the rules in the Preupdate rule set, ClaimCenter first computes the set of objects on which to run the
Preupdate rules. ClaimCenter then runs the Preupdate rules for this set of objects as determined by the order listed in
the table Order column.

Loaded Gosu Classes

Guidewire no longer supports the Server Tools Loaded Gosu Classes screen.

Serialization Info
The Server Tools Serialization Info screen (under Info Pages) shows, for any specific server in the cluster, the entire set
of Java objects (classes) deserialized by that server instance. This screen contains an optional filter (Including listed in
the serialization whitelist classes) that filters the list of classes:
• Checking this box means that the list of class names includes the names of all Java classes encountered and
deserialized by the local server. This list includes the names of classes that exist in the serialization white
(permitted) list as well.
• Un-checking this box means that the list of class names includes only the names of classes encountered and
deserialized that are not on the serialization white list. Guidewire recommends that you add these classes to the
serialization whitelist. After you complete your whitelisting of Java classes, the class listing will be empty.

Enabling Object Deserialization

Configuration parameter SerializationWhitelistEnabled in config.xml determines whether ClaimCenter
permits only those Java classes placed on a serialization whitelist to be deserialized. Before you enable the use of the
whitelist, ensure that you first add any additional types needed due to customizations. Primarily, this is due to
creating batch processes that accept custom objects as arguments. Such objects must be serialized if the batch
process is invoked from a server other than the server with the batch role. If you do not add these objects to the
whitelist, it is possible that the related services that uses them to not function properly.
See also
• Configuration Guide

The Black and White Serialization Lists

In Guidewire Studio, you can access the serialization black list and white lists in the following location:
configuration→config→security
To blacklist a Java class, add an entry in serialization-blacklist.lst in that folder. To whitelist a Java class,
add an entry in serialization-whitelist.lst in that folder.
In making entries in these files, use the following syntax:
• Place a # symbol at the beginning of a line to indicate that the line is a comment.
• Use a separate line for each class or package name, for example, gw.api.myPackage.*.
• Do not place the * separator in the middle of a class or package name. For example, do not do the following:

#Incorrect example
gw.api.*.myClass

Info Pages 385

 System Administration Guide 9.0.5

• Use blank lines and leading spaces as desired to enhance readability of the file.

Management Beans
Note: The Management Beans screen is accessible to users with the soapadmin permission only.
The Server Tools Management Beans screen lists ClaimCenter management beans, which are ClaimCenter objects that
represent different resources. Click the name of a resource to open the Guidewire Managed Bean Properties screen for
the selected resource.
The Bean Properties screen most often contains a MBean Property table that lists the properties associated with the
selected resource bean. Property values are either read-only or editable. Guidewire marks the editable properties
with a small blue triangle in the upper left-hand corner of the Value field. Click anywhere in an editable field to make
that field editable. After modifying a field, you can either save your work or cancel your changes by clicking Save or
Cancel.
A few Bean Properties screens also contain an Operation table that lists available operations associated with this
resource bean. Click Execute to execute a selected operation. The Result field shows the result of the operation.

Startable Services
The Server Tools Startable Services screen contains summary information on all of the startable plugin services in the
ClaimCenter cluster. A startable plugin is a special type of ClaimCenter plugin. At runtime, ClaimCenter creates a
background process, or service, for each startable plugin. The summary table provides the following information for
each service.

Name Name of the plugin service.

Status Current status of the service.

Host One of the following:

• Name of the host on which the plugin service is running.
• Distributed, if cluster configuration allows the startable plugin services to run on all cluster members.
Action Available actions, either starting or stopping a selected service.

See also
• Integration Guide

Cluster Members and Components

The Server Tools Cluster Members screens provide information on the server cluster installation. The screen consists
of the following areas:
• This Application Instance
• Application Server Instances
• Components tab
• History tab
From this screen you can also schedule (or cancel) a planned shutdown of a specific server in the ClaimCenter
cluster.

386 chapter 23 Server Tools

 System Administration Guide 9.0.5

See also
• “The Cluster Components Screen” on page 391
• “Download a Server Component Report” on page 392
• “Schedule a Planned Cluster Member Shutdown” on page 392

Cluster Members – This Application Server Instance

The Server Tools Cluster Members (This Application Server Instance) screen provides the following information about the
local server instance from which you access the screen.

Host Name of the machine on which this ClaimCenter server instance is running.
Server ID Name for this server instance. You specify the server ID by either adding an entry for this cluster member in the <
registry> element in config.xml, or, by setting a JVM option at server startup. If you do not specify a server ID,
ClaimCenter uses the host (machine) name as the server ID.
UUID Universally Unique ID for this server machine. ClaimCenter randomly generates a UUID for each machine at each
machine startup.
Server Roles List of server roles assigned to this ClaimCenter server.

See also
• “Understanding the Configuration Registry Element” on page 46
• “Server Roles” on page 141

About Planned Server Shutdowns

The Server Tools Cluster Members screen provides the ability to start a planned or scheduled shutdown of a specific
server in the ClaimCenter cluster. This action affects only the server on which you start or stop the scheduled
shutdown. The Actions column of the Application Server Instances table contains a button that toggles between Start
planned shutdown and Cancel planned shutdown, depending on whether a server shutdown is currently scheduled.

Scheduling a Server Shutdown

Clicking Start planned shutdown opens the Schedule Planned Shutdown screen. From this screen, you can set the details
of the planned server shutdown. In this screen, you need to set the following items:

Banner text Choose the text of the banner message to show on the ClaimCenter screen to warn
users of the server shutdown. The banner message occurs immediately as you
schedule the shutdown and contains a countdown to the time of the scheduled
shutdown. You can choose from several listed messages or create your own custom
message.
Shutdown date and time Set the date and time of the server shutdown.
Action to take with respect to running Decide how to handle any currently running batch processes
batch processes

After you initiate a scheduled shutdown, ClaimCenter does the following on the affected server:
• It does not start any new batch processes.
• It manages the stopping of any currently running batch processes depending on the setting for Terminate Batch
Processes field.
• It requests that all work queues and message destinations stop processing immediately.
• It completes the transmission of any current messages without starting any new message transmissions.
• It completes the processing of any current work items without beginning work on any new work items.

Cluster Members and Components 387

 System Administration Guide 9.0.5

After you click OK in the Schedule Planned Shutdown confirmation dialog, ClaimCenter reopens the Cluster Members
screen. In this screen, you now see the following:
• The Actions entry for the affected server contains a Cancel planned shutdown button.
• The Planned Shutdown entry for the affected server provides information about the planned shutdown.
• The screen contains a banner with the chosen shutdown message and a countdown timer to the server shutdown
date and time.

Shutdown Message Details

You have several choices for shutdown messages in the Schedule Planned Shutdown screen. If you do not elect to
create a custom message, you can select one of several default messages. ClaimCenter stores these messages as
display keys in file display.properties.

Web.TabBar.SystemAlertBar.PlannedShutdown.RollingUp Rolling upgrade in progress, please save your work and log out
gradeMessage to redirect to a new server.
Web.TabBar.SystemAlertBar.PlannedShutdown.ScaleInMe Please save your work and log out to re-direct to the new
ssage server.

After you initiate a planned shutdown, ClaimCenter stores only the current time and the shutdown time in the
database. It stores other information, such as the shutdown message itself, in a single-threaded atomic reference in
memory. ClaimCenter clears this message reference under the following conditions:
• At the restart of the shutdown ClaimCenter server
• At the cancellation of the planned server shutdown

Terminating Running Batch Processes

The Schedule Planned Shutdown screen contains a Terminate Batch Processes checkbox. ClaimCenter terminates the
running batch processes differently depending how you set this field.

Terminate Batch Processes Result

Checked ClaimCenter sets a flag on all currently running batch processes (including workqueue writers)
assigned to this server to terminate their operation. To the extent that the batch process logic
permits, the process attempts to stop as gracefully and as safely as possibly.
Unchecked ClaimCenter does not instruct the currently running batch processes on this server to terminate
prematurely. All batch processes assigned to this server continue until completed, regardless of
how long it takes to complete the work.

In either case, ClaimCenter does not show a Planned Shutdown status of ready on the Cluster Members screen until all
the affected processes have stopped on the server.
Note: Batch processes run as non-daemon threads. As such, it is not possible for the server to perform a graceful
shutdown if any batch processes are still running on the server at the time of the shutdown.

Using System Tools to Schedule a Shutdown

It is also possible to initiate a scheduled shutdown of a server using either the SystemToolsAPI web service or its
associated system_tools command prompt option. For example, the system_tools command uses the following
syntax:
system_tools -user user -password password -scheduleshutdown serverId [-
terminatebatchprocesses -shutdowndelay minutes]
If you include the -terminatebatchprocess command option, the shutdown process is the same as if you checked
the Terminate Batch Processes checkbox in the Schedule Planned Shutdown screen.

388 chapter 23 Server Tools

 System Administration Guide 9.0.5

For more information on the use of the system_tools command, see “System Tools Command” on page 422. For
information on the use of the SystemToolsAPI web service, see the ClaimCenter Integration Guide.

Cluster Members – Application Server Instances

The Server Tools Cluster Members (Application Server Instances) table provides the information about individual server
instances recognized by the cluster. To update this information, click Refresh Cluster Members. A review of this
information is one way to determine if a cluster member has become unreachable, and therefore, missing from the
list.
This screen provides the following information.

Server ID Name for each ClaimCenter server in the cluster.

Status Status of each server instance n the cluster.
Host Name of the machine on which each ClaimCenter server is running.
User Sessions Number of user sessions active on each server instance in the cluster.
Run Level Run level for each server instance in the cluster.
Version Version information for each application installation. ClaimCenter provides the version information in the
following format:
Guidewire build.customer build (n,n,n,n,n)
These numbers have the following meaning:
• Guidewire build – Guidewire application version, for example, 9.0.0 or 9.0.1.
• Customer build– Custom label, defined in file customer-version.properties. If not defined, this field is
empty.
• (n,n,n,n,n) – Numbers that have the following meaning:
◦ Platform major version
◦ Platform minor version
◦ Application major version
◦ Application minor version
◦ Data model version
See “Understanding Guidewire Software Versioning” on page 395 for more information.
Server Roles Specific roles assigned to each server instance in the cluster.
Server Started Date and time at which this server instance started.
Connection Date and time this cluster member first started.
Started

Last Update Date and time of the last update on this server instance.
Planned Date and time of any planned shutdown of a cluster member.
Shutdown

Actions Action button to manage a planned shutdown of a cluster server instance. The button label is either Start
Planned Shutdown or Cancel Planned Shutdown.
You can also initiate a server shutdown using the administrative system_toools command option -schedul
eshutdown. See “System Tools Command” on page 422 for details.

Cluster Members and Components 389

 System Administration Guide 9.0.5

See also
• “The Cluster Components Screen” on page 391
• “Schedule a Planned Cluster Member Shutdown” on page 392

Cluster Members – Components Tab

The Server Tools Cluster Members – Components tab provides information on the components running on the server
that you select in the Cluster Members (Application Server Instances) table. These components, with the exception of the
work queues, are all singleton components. You can view all components, or, filter the list to see only those
components of a specific type.
The Components table provides the following information about the components running on the selected server.

Type Type of component, one of the following:

• Batch Process
• Message Destination
• Startable Service
• System
• Work Queue
Name Name of component. This name is the work queue name, or, the message destination name, for example.
Started Date and start time for each component.
State State of the component, for example, Assigned.
Retry Date and time of the deadline in which to complete the failover process.
Failover If a lease manager detects the expiration of a component lease owned by another cluster member, the first lease
manager starts a failover process for this lease. This failover process is not instantaneous. It is possible that during
the failover process the cluster member performing the failover itself might fail, or lose database connection, or
encounter other potential problems.
To be able to handle this situation gracefully, the cluster member starting the failover gives itself a deadline to
complete the failover process. If the current failover process does not finish by the specified timestamp, some
other cluster member needs to start the failover process for the same component lease.
See “Automatic Failover of a Component Lease” on page 161 for a description of how ClaimCenter calculates this
timestamp.

You can view similar information to that of the Components table on the Cluster Components screen.

Cluster Members – History Tab

The Server Tools Cluster Members – History tab provides information on the history of the server that you select in the
Cluster Members (Application Server Instances) table.
The History table provides the following information for the selected server.

Host Name of the machine on which the ClaimCenter server is running.

UUID Universally Unique ID for this server machine. ClaimCenter randomly generates a UUID for each machine at
each machine startup.
Env Environment for this ClaimCenter server.
Last Run Level Run level for this ClaimCenter server at the point it stopped

Server Roles Specific roles assigned to this server instance.

Server Started Date and time at which this server started.
Server Stopped Date and time at which this server stopped.

390 chapter 23 Server Tools

 System Administration Guide 9.0.5

The Cluster Components Screen

The Server Tools Cluster Components screen provides the following information.

Type Type of component to show in the table, one of the following:

• All types
• Batch Process
• Message Destination
• Startable Service
Name Name of component. This name is the work queue name, or, the message destination name, for example.
State State of the component, for example, Assigned, meaning that there is a server that has the lease to run this
component.
Start Requested Date and time that the server received the component start request.

Started Date and start time of the component.

Owner Server ID of the ClaimCenter server on which the component runs.
Lease Date and time at which the component lease expires. See “Cluster Member Shutdown” on page 146 for more
Expiration information on component leasing.
Stopped Stop date and time of the server instance on which the component is running, due to one of the following
reasons:
• Server instance stopped as intended
• Server instance failed due to lost power or network connection and automatic recovery failed or is still in
progress
Actions ClaimCenter shows a Complete Failover button if a component lease expires and a custom failover plugin
implementation instructs ClaimCenter not to perform an automatic failover.
See “Cluster Member Shutdown” on page 146 for more information.
Terminate Date and time at which the server instance received a terminate request for this component.
Requested

Transfer Date and time at which the server instance received a request to transfer this component to another server
Requested instance.
Transfer Target Server ID of the server to which the transfer request was made.
Retry Failover Date and time of the deadline in which to complete the failover process.
If a lease manager detects the expiration of a component lease owned by another cluster member, the first
lease manager starts a failover process for this lease. This failover process is not instantaneous. It is possible
that during the failover process the cluster member performing the failover itself might fail, or lose database
connection, or encounter other potential problems.
To be able to handle this situation gracefully, the cluster member starting the failover gives itself a deadline to
complete the failover process. If the current failover process does not finish by the specified timestamp, some
other cluster member needs to start the failover process for the same component lease.
See “Automatic Failover of a Component Lease” on page 161 for a description of how ClaimCenter calculates
this timestamp.

You can view similar information to that of the Components table on the Cluster Members screen, the Components tab.

Available Actions on this Screen

The following list describes the actions that you can take in Cluster Members screen.

Cluster Members and Components 391

 System Administration Guide 9.0.5

Action Description
Download cluster server Click Download to download an HTML report of the cluster components and component history.
report See “Download a Server Component Report” on page 392 for details.
Filter by component type Select a component type from the Types drop-down list to filter the information by a specific
component type.
Filter by component state Select a component state from the State drop-down list to filter the information by a specific
component state.
Filter by component Click Filter by Component to open a Select Components screen. In this screen, you can select
individual components of all available types to show in the component table.
Refresh the component Click Refresh to update the server component information in the table.
information
Review component history Click the name of a component to open a component history detail screen.
detail

Download a Server Component Report

Procedure
1. Log into Guidewire ClaimCenter using an administrative account.
2. Navigate to the Server Tools Cluster→Components screen.
3. Click Download to open the Specify Record Limits for this Report screen.
4. Enter the maximum number of days to include in the generated component history report.
5. Click Complete Download to generate a ZIP file that contains the actual report.
6. Save the download file to your local machine.
7. Extract the Zip file to a local directory.
8. Search for and double-click file index.html to open the report in a web browser.
9. Click the Component History link for the component history report.

Schedule a Planned Cluster Member Shutdown

About this task
You schedule a planned shutdown of a cluster member from the Server Tools Cluster Members screen.
Note: It is also possible to initiate a planned server shutdown using the administrative system_toools -
scheduleshutdown command option. See “System Tools Command” on page 422 for details.

Procedure
1. Navigate to the Server Tools Cluster Members screen.
2. Find the table row that corresponds to the cluster member for which you want to schedule a shutdown.
3. If necessary, scroll the screen all the way to the right until you see the Actions column.
4. Click Start Planned Shutdown.
5. In the Schedule Planned Shutdown screen, select the message that you want to show to the application user about
the planned shutdown.
Select one of the provided messages, or, enter custom text in the provided field.
6. Select the date and time of the planned shutdown.

392 chapter 23 Server Tools

 System Administration Guide 9.0.5

7. Decide how you want ClaimCenter to handle the currently running batch processes (including work queue
writers) on the server.
See “About Planned Server Shutdowns” on page 387 for more information on the option.
8. Click Schedule Shutdown.

Result
After you schedule the shutdown, the Cluster Members screen shows the following for your selected cluster member:
• The Planned Shutdown column shows the date and time that you initiated the planned shutdown. It also shows the
date and time of the actual planned shutdown.
• The Actions column shows a Cancel Planned Shutdown button. To cancel a planned server shutdown, click Cancel
Planned Shutdown.
All ClaimCenter screens, for all users logged into the affected cluster member, display a banner indicating the date
and time of the planned shutdown and your selected message.

Upgrade and Versions

The Server Tools Upgrade and Versions screen displays information about any upgrade process that is run on this
server.
Note: Some functionality on the Upgrade and Versions screens is visible only if configuration parameter
ClusteringEnabled is set to true in config.xml.
Guidewire divides this screen into the following areas:
• A row of buttons that control upgrade functionality, not all of which are visible at all times.
• A summary table that contains upgrade information for this particular application server.

The Upgrade and Versions Screen Summary Table

The upgrade summary table contains the following information.

Version Version information for each application installation. ClaimCenter provides the version information in the
following format:
Guidewire build.customer build (n,n,n,n,n)
These numbers have the following meaning:
• Guidewire build – Guidewire application version, for example, 9.0.0.
• Customer build– Custom label, defined in file customer-version.properties. If not defined, this field is
empty.
• (n,n,n,n,n) – Numbers that have the following meaning:
◦ Platform major version
◦ Platform minor version
◦ Application major version
◦ Application minor version
◦ Data model version
See “Understanding Guidewire Software Versioning” on page 395 for more information.
Status Status of each upgrade, for example, new schema or upgraded.
Type Type of each upgrade, for example, install or full.
Start Time Date and time of the beginning of the upgrade.
End Time Date and time of the completion of the upgrade.
Duration Length of time that the upgrade process took. Time is shown as both the total number of seconds involved and
the time for just the database upgrade portion of the upgrade.

Upgrade and Versions 393

 System Administration Guide 9.0.5

Deferred Execution status of the Deferred Upgrade Tasks batch process. See “Deferred Upgrade Tasks Batch Processing”
Upgrade Tasks on page 115 for details.
Status

View Details Click the View icon to open a pop-up from which you can view the same reports contained in the UpgradeInfo.
zip file.
See “View an Upgrade Report” on page 395 for more information.
Download Click the Download arrow to download an UpgradeInfo.zip file that contains a set of HTML reports describing
Details various aspects of the upgrade process.
See “View an Upgrade Report” on page 395 for more information.
Remove Detail Click the trash can icon to remove this row of data.
Data

The Upgrade and Versions Screen Buttons

The top of the Upgrade and Versions screen contains a number of buttons that initiate specific upgrade actions. Not all
buttons are visible at all times. Individual buttons become visible depending on various aspects of the cluster and its
members.
The Upgrade and Versions screen contains the following buttons that initiate upgrade-related actions.

Refresh Click to update the information on this screen.

Start Rolling Upgrade Click to open a Start Rolling Upgrade screen from which you can initiate a rolling upgrade for this
cluster. Before you can start the upgrade, you must actively affirm that you have taken certain pre-
upgrade steps by selecting the check box next to each pre-upgrade step.
See “Performing a Rolling Upgrade” on page 174 for details.
Rolling Upgrade Complete Click to notify ClaimCenter that the in-progress rolling upgrade is now complete. The rolling
upgrade is complete after you have restarted all cluster members with the new target
configuration. Without this notification, ClaimCenter prevents cluster members with the old
configuration from starting up again.
Initiate Backout Click to attempt to stop an in-progress rolling upgrade and initiate a backout of the new target
configuration. The attempt to stop and backout the rolling upgrade may or may not succeed,
depending at what point in the rolling upgrade that the request to stop occurs.
If a backout of the rolling upgrade is possible, ClaimCenter opens a series of confirmation screens
to assist you in correcting issues related to backing out the new configuration.
Start Full Upgrade Click to open a Start Full Upgrade screen. Clicking Yes on this screen sets a flag in the database that
you intend to start a full database upgrade. You must set this database flag before deploying your
new configuration to members of the cluster.
If you do not set this flag, ClaimCenter refuses to start and refuses to alter the database. After you
complete the full upgrade, ClaimCenter deletes this flag from the database. You must set the flag
again before starting a new full upgrade.
Note: You can also initiate a full ClaimCenter upgrade using the administrative system_toools
command option -startfullupgrade. See “System Tools Command” on page 422 for details.
Cancel Full Upgrade Click to attempt to cancel an in-progress full upgrade. If ClaimCenter determines that it is safe to
cancel the upgrade, it does so.

See also
• “Review Profiler Upgrade Information” on page 406

The Upgrade Report

The Server Tools Upgrade and Version screen contains the means to view details of a specific upgrade or download the
data for local viewing. The downloadable upgrade information contains the following set of linked reports:

394 chapter 23 Server Tools

 System Administration Guide 9.0.5

Upgrade Instance Lists information on various upgrade statistics.

It is also to possible to download Guidewire Profiler data by clicking the Raw Profiler Data link at the bottom of
the Upgrade Instance screen.
Database Lists information on various database parameters, including the database connection pool settings, the
Parameters database configuration settings, and similar information.

See also
• “Upgrade and Versions” on page 393
• “Understanding Data Model Updates” on page 260

View an Upgrade Report

Procedure
1. Navigate to the Server Tools Upgrade and Versions screen.
2. For the upgrade process that interests you, click one of the following:

Download Details arrow Downloads a Zip file that contains various types of upgrade information.

View Details icon Open a pop-up window from which you can view the upgrade reports.

3. If you downloaded the report file, unzip the file into its own directory.
4. Locate file index.html and double-click it to open it in a browser.
5. Use the links on the screen to navigate through the linked reports.

Understanding Guidewire Software Versioning

Guidewire application versioning is a way to label a particular snapshot of a Guidewire application. It is a string
label that Guidewire applies to its software. You see this version number primarily in Server Tools, in the Cluster
Members screen and the Upgrade and Versions screens.
Guidewire manages software versioning through internal classes that provide the following information:
• Guidewire application name and version
• Guidewire module name and version
ClaimCenter writes version information to the application log at ClaimCenter start.

Application Version Numbering

Both the Server Tools Cluster Members screen and the Upgrade and Versions screens show the ClaimCenter application
version as the following sequence of numbers:

A.B (a,b,c,d,e)

These numbers have the following meaning:

Version # Meaning
A Guidewire application version plus the application release build version, for example, 9.0.0.905.
B Custom version label
a Platform major version
b Platform minor version
c Application major version

The Upgrade Report 395

 System Administration Guide 9.0.5

Version # Meaning
d Application minor version
e Data model version number

The following example illustrates these concepts.

9.0.0.905.20161017 (6,22,11,45,175)

Notice that:
• 9.0.0.905 is the application version number (9.0.0) plus the application release build version number (905).
• 20161017 is a custom label that you define in file customer-version.properties. In this case, the label
indicates the date of a ClaimCenter configuration upgrade. If not defined, this field is empty.
• 175 is an upgrade version number that you define in file extensions.properties.

WARNING In a production environment, Guidewire requires that you increment the data model 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.

See also
• “File customer-version.properties” on page 396
• “Create a Custom Version Label File” on page 397
• “Deploy a Custom Version Label File on Tomcat” on page 397
• Configuration Guide

File customer-version.properties
Use file customer-version.properties to define a custom build version number. If you create this file and
populate it correctly, ClaimCenter appends your custom version number to the Guidewire software version label.
Most commonly, you use a custom build number to label and track a configuration deployment that you undertake as
a rolling upgrade.
File customer-version.properties contains the following single property:

customer.build

The following example illustrates how to use this property:

customer.build=20160914-PCF-upgrade

ClaimCenter does not contain file customer-version.properties in the base configuration. Instead, you must
create this file and place it in a location that ClaimCenter recognizes.
See also
• “Understanding Guidewire Software Versioning” on page 395
• “Create a Custom Version Label File” on page 397
• “Deploy a Custom Version Label File on Tomcat” on page 397

396 chapter 23 Server Tools

 System Administration Guide 9.0.5

Create a Custom Version Label File

About this task

Guidewire recommends that you place any customer-version.properties file that you create in the res directory.

Procedure
1. In the Studio Project window, expand configuration→res.
2. Select res and right-click to open the context menu.
3. Select New→File.
4. Name the file customer-version.properties.
5. Enter a value for customer.build, for example:

customer.build=20160914-PCF-upgrade

6. Save your work.

Next steps
See also
• “Understanding Guidewire Software Versioning” on page 395
• “File customer-version.properties” on page 396
• “Deploy a Custom Version Label File on Tomcat” on page 397

Deploy a Custom Version Label File on Tomcat

Before you begin

Before starting this procedure, ensure that you complete all steps in “Create a Custom Version Label File” on page
397.

Procedure
1. Create a Tomcat WAR file:
a. Open a command prompt in the ClaimCenter installation directory.
b. Execute the following command:

gwb warTomcatDBcp

ClaimCenter adds file customer-version.properties to the following JAR file in the generated WAR
file:

WEB-INF/lib/configuration.jar

2. Deploy the WAR file to the application server.

Result
After starting the server, the Server Tools Upgrade and Versions screen shows the custom version label, appended to
the standard application version number.

Understanding Guidewire Software Versioning 397

 System Administration Guide 9.0.5

Next steps
See also
• “Understanding Guidewire Software Versioning” on page 395
• “File customer-version.properties” on page 396
• “Create a Custom Version Label File” on page 397

Cache Info
The Server Tools Cache Info screen provides information in both table and chart form of ClaimCenter server cache
information. Guidewire recommends that you use this information to help you monitor how well the cache is
performing.
See also
•
• “Server Cache Tuning Parameters” on page 71
• Configuration Guide

The Cache Summary View

The Server Tools Cache Summary view on the Cache Info screen includes the following information:

Max Cache Space (KB) Maximum amount of space to allot to the global cache.

Stale Time (mins) Maximum time allowed for an object to be in the cache without a database refresh.
Page Loaded at Date and time of the last refresh of the data on this screen.

Available Actions on this Screen

From the Cache Info screen, you can do the following:

Edit Click Edit to enter different values for Maximum Cache Space and Stale Time. If you change these parameters from
the Cache Summary view, the values you specify apply only to the ClaimCenter server to which you are connected.
If you restart the server, your changes are lost. For your changes to persist, edit the their values in file config.x
ml.

Refresh Click Refresh to update the information shown on this screen. This action also updates the date and time values
shown for the Page Loaded at field.
Download Click Download to download a CSV-formatted file containing detailed cache information. See also “Understanding
the Cache Data Report” on page 399.
Clear Global Click Clear Global Cache to clear the cache of all entities. Note, however that the cache always contains some
Cache objects to support an active server.

Cache Summary Graphs

The Cache Summary screen provides the following graphs.

Graph Description
Cache Size The memory used by the cache over time.
Hits and Misses (Stacked) The number of cache hits (an object was found in the cache) and misses (object was not found
in the cache) and the miss percentage.
Type of Cache Misses The number of cache misses caused by ClaimCenter evicting an object because the cache was
full and the number of missed caused by ClaimCenter evicting an object due to reaping.

398 chapter 23 Server Tools

 System Administration Guide 9.0.5

Graph Description
This graph is not visible if configuration parameter GlobalCacheDetailedStats in config.xm
l is set to false.

Evict Information Information about cache evictions over time, including:

• Number of times no entry was found to evict when cache was full
• Number of evictions within active time when cache was full
• Number of evictions when cache was full
• Number of evictions due to reaping
This graph is not visible if configuration parameter GlobalCacheDetailedStats in config.xm
l is set to false.

Current Age Distribution The number of objects of various ages in the cache.
Current Cache Contents for Age All The percentage of types of objects present in the cache for all ages.

See also
• Configuration Guide

The Historical Performance View

Note: For the Historical Performance screen to be visible, configuration parameter GlobalCacheDetailedStats in
file config.xml must be set to true.
The Server Tools Historical Performance view on the Cache Info screen provides the following graphs:

Graph Description
Space Retained Memory used by the cache over the past couple days. The time shown is a much
longer period than the cache size graph on the Cache Summary tab, which only displays
the past 15 minutes.
In this case, the x-axis represents the average values for each time period during each
of the past eight days. This is to allow for comparison of cache behaviors against
hourly trends.
Hits and Misses (stacked) Number of hits (object was found in the cache) and misses (object was not found in
the cache) and the miss percentage over the past day and past seven days.
Miss % The percentage of cache read attempts in which the object was not found in the
cache over the past day and the past seven days.
Number of Misses because item was evicted The number of misses over the past day and the past seven days due to ClaimCenter
when cache was full having evicted an object from the cache because the cache was full.

The Cache Details View

The Server Tools Cache Details view on the Cache Info screen includes graphs of the following:

Graph Description
Age Distribution by time A number of graphs that show the age distribution of objects in the cache. The Cache Details tab
shows age distributions for zero to 30 minutes ago.
Current Cache Contents by age A number of graphs that show the percentage of types of objects in the cache over time.

Understanding the Cache Data Report

Clicking Download on the Server Tools Cache Info screen downloads a CSV-formatted file containing information on
the current state of the server cache.
Cache Info 399
 System Administration Guide 9.0.5

In looking at the cache data provided in the downloaded report, Guidewire recommends that you first calculate the
cache miss ratio around the time of the performance degradation. The cache miss ratio is the ratio of (misses) /
(misses + hits).
The cache miss ratio is a useful metric in that it normalizes the cache values. For example, suppose that you have the
following hit and miss cache values that you use to calculate each individual cache miss ratio.

Timestamp # cache misses # cache hits Cache miss ratio

Time 1 12345 2345 12345 / (12345 + 2345) = 0.8404
Time 2 1234 23456 1234 / (1234 + 23456) = 0.4998

The calculation of the cache miss ratio enables you to compare the data in way that is not possible by simply
examining the raw data.

High Miss Ratio

If the miss ratio is high, it is very likely that the performance issue involves the cache. Thus, you need to look at the
reasons for the cache misses, especially the following:
• Number of misses because item was evicted when cache was full
• Number of misses because item was evicted due to reaping
If the number of misses is high due to the cache being full, you can try increasing the size of the cache and
observing the result. Keep in mind, however, that the cache uses the heap. Thus, increasing the size of the cache can
potentially reduce the amount of heap memory available for other computations.
If the number of cache misses is high due to reaping, you can try increasing the reaping time and observing the
result. Another approach would be to examine ways to reduce the time since the last access of the cache objects. For
example, how long does it take to reuse objects that have already been fetched from the database? Is it possible to
hold onto the objects without having to fetch the objects again from the database?

Cache Misses and Hits

The cache miss count and the cache miss ratio are probably the most important data points in the download cache
data report. Essentially, the more cache hits the better, as it means the cache was able to service that many requests.
Each cache miss is expensive. It means that the looked-for object was not in the cache. Regardless of the hit count, a
high miss count can indicate a problem with the cache. Keep in mind, however, that the miss count is relative. A
cache miss can occur simply because it is the first time a request is made to the cache for an object. Thus, the object
is not in the cache. A cache miss can also occur as the sought-after object may have already been evicted from the
cache. The downloaded cache report provides data on the various reasons for object eviction from the cache.
Using the assumption that there is a constant cost for each cache miss, it is possible to compare the miss counts
directly. The cost of a cache hit is essentially zero, or very, very small compared with the cost of a cache miss. A
cache miss may take a 10 millisecond trip to the database to access the data whereas a cache hit is essentially zero
time.

Guidewire Profiler
The Server Tools Guidewire Profiler screen provides access to a set of tools that are useful in gathering and analyzing
information on the runtime behavior and performance of Guidewire ClaimCenter. The Profiler records the time
spent in specific processing areas done by the application code, as well as the configured rules and PCF screens. Use
of this information can help narrow down issues to the potentially problematic components such as PCF screens,
rules, code sections, or workflows.

400 chapter 23 Server Tools

 System Administration Guide 9.0.5

Profiler code is useful, for example, to record the following types of operations and information:
• SQL statements that ClaimCenter is executing
• Parameters passed to those SQL statements
• Row counts
• Name of the currently executing rule
Guidewire recommends that you exercise care in using this feature. Storing too much information can cause the
Profiler screen to become too cluttered, require more space for storage and, for long-running processes, hold on to too
much memory at runtime.
Note: Guidewire Profiler does not collect memory usage statistics. You can use a third-party tool to gather memory
usage and garbage collection information.
See also
• “Server Memory Management” on page 73

Guidewire Profiler Concepts

There are several concepts that are important to an understanding of how to configure application profiling. The
following list describes these concepts.

Concept Description For more information

Entry point Refers to the type of interactions that you select to profile. “Profiler Entry Points” on page 401
Profiler tag Alias for a piece of code to profile in the Guidewire application. “Profiler Tags” on page 407
Profiler frame Contains information on a specific invocation of profiled code. “Profiler Frames” on page 407
Profiler stack Stores profiling information for a specific thread. “Profiler Stacks” on page 407

See also
• “Guidewire Profiler” on page 400
• “Guidewire Profiler Analysis” on page 404

Profiler Entry Points

The Server Tools Guidewire Profiler collects profile data based on the type of interaction with the application that
you request to be profiled. Guidewire refers to the different types of possible interactions as entry points, with the
entry point type indicating the type of request or action that initiated application processing. The following list
describes the various entry point types that you can access from the Guidewire Profiler Configuration screen.

Entry point Description

Web Application user interface in which you can perform tasks and actions. Clicking around in the Guidewire
application in a browser potentially causes rules, web services, messages, and similar items to trigger.
See “Web Session Profiling” on page 402 for more information.
Batch process Batch processes wake up at regular intervals, and can execute large queries. See “Administering Batch
Processing” on page 85.
Work queue Long running processes that pick up work to be done from a queue. These processes are typically
distributed across several servers. See “Administering Batch Processing” on page 85.
Message destination Process that delivers messages to one or more destinations. See the Integration Guide.
Web service SOAP requests received by ClaimCenter. See the Integration Guide.

Guidewire Profiler 401

 System Administration Guide 9.0.5

Entry point Description

Startable service Plugin implementations that ClaimCenter initializes at server startup and de-initializes at server
shutdown. For example, it is possible to register a plugin implementation as a listener on a JMS queue.
See the Integration Guide.

Except for Web entry points, Guidewire Profiler stores configuration information in the database. This information
is visible to all ClaimCenter servers in the cluster. For a change in configuration to a batch process, work queue, or
message destination to take effect, you need to restart that batch process, work queue, or message destination. Any
change in configuration can take some time to propagate through the cluster. Also, it may take up to the cache stale
time for a configuration change to become visible.
The next time profiling starts for a given entry point, Guidewire Profiler checks whether profiling is enabled for that
entry point. If profiling is enabled, Guidewire Profiler records the profiling data in the form of a profiler stack. The
Profiler records multiple stacks if the initial thread spawns more threads and the developer profiles the spawned
threads. Except for Web profiling, ClaimCenter persists this data database, making it possible to retrieve the data
later.
See also
• “Web Session Profiling” on page 402
• “ClaimCenter Application Profiling” on page 403
• “Guidewire Profiler Analysis” on page 404
• “Ways to View a Guidewire Profiler Analysis Reports” on page 405

Web Session Profiling

After you enable web profiling in Guidewire Profiler, ClaimCenter records all subsequent round-trips to the server
as a separate profiler stack. Unlike other types of entry points, ClaimCenter does not persist the stacks from Web
requests to the database. Instead, ClaimCenter stores the stacks from web requests in the user session.
In using web profiling, Guidewire recommends the following:
• Enable the web profiler only as absolutely needed as it degrades performance.
• Start the profiler from the ClaimCenter application screen that you want to profile.
• Log out of the application after you have analyzed or downloaded the profiler data to free the memory used by
the profiler.
It is only possible to enable profiling for web entry points for the current session.

Enable Web Profiling

Procedure
1. Navigate to the Server Tools Guidewire Profiler screen.
2. Select the profiling options that you want to use for this profiling session.
3. Restart the associated batch process, work queue, or message destination, if appropriate.
4. Click Enable Web Profiling for this Session.
This action returns you to the application screen from which you started.
5. Exercise the application screens that you want to profile.
6. Press ALT+SHIFT+P to return to Guidewire Profiler.
7. Click Disable Web Profiling to end the current Web profiling session.
This action generates the Web Profiler screen.

402 chapter 23 Server Tools

 System Administration Guide 9.0.5

Next steps
See also
• To understand the various web profile tracing options, see “Profiler Trace Options” on page 403.
• To understand the Web Profiler screen, see “Guidewire Profiler Analysis” on page 404.
• To download and save this snapshot of application profiling data, see “View Uploaded Profiler Reports” on page
406.

ClaimCenter Application Profiling

You enable application profiling in the Server Tools Guidewire Profiler→Configuration screen. On the Configuration
screen, directly below the Web Profiler area, is an area labeled Entry Point Configuration. This area contains a set of
buttons that you click to enable the other types of entry points profiling. These buttons are:
• Enable Profiling For Batch Process
• Enable Profiling For Work Queue
• Enable Profiling For Message Destination
• Enable Profiling For Web Service
• Enable Profiling For Startable Service
Clicking the button for an entry point opens a secondary screen in which you select the specific item to profile.
For example, to enable application profiling for message destinations:
• Click Enable Profiling for Message Destinations. This action opens a screen in which you can select the specific
message destination to profile.
• Select a specific message destination and click OK to return to the Configuration screen.
ClaimCenter then adds a message destination row to the Entry Point Configuration table, with a different column for
each profile trace option. If a trace option is available for the chosen entry point, ClaimCenter places an icon in the
table cell for that option. Initially, ClaimCenter disables all of the available trace options, marking the table cell with
a red X. It is necessary to click the icon to enable the option. This action changes the icon to a green check mark.
For each entry point row, ClaimCenter also adds an Edit Configuration button at the right-hand end of the row. This
button provides an alternative way to enable tracing options, as well as a way to disable tracing for this entry point.
If you disable an application profile entry type, ClaimCenter removes the row for that entry point from the Entry Point
Configuration table.
See also
• “Profiler Entry Points” on page 401
• “Profiler Trace Options” on page 403
• “Web Session Profiling” on page 402
• “Guidewire Profiler Analysis” on page 404

Profiler Trace Options

It is possible to enable different types of trace options in the Server Tools Guidewire Profiler→Configuration screen for
the various types of entry points. These options are quite expensive to compute. Guidewire recommends that you
narrow down your performance issues first before trying these options.
The exact number and type of tracking options available for profiling depend on the following:
• The application server’s operating system
• The application server’s database type
• The chosen entry point

Guidewire Profiler 403

 System Administration Guide 9.0.5

To enable a specific profiling option, select or check the box next it. The following list describes the types trace
options that are available in Guidewire Profiler.

Trace option Description

Individual Stacks Available for work queue entry points only. If checked, this tracing option stores one stack for
each work item and does not roll up the data.
Use caution with the Individual Stacks option as the amount of data to store could be
unbounded. The Individual Stacks option is recommended for use if there are only a few items in
the queue.
Stack Trace Tracking Captures the Java stack trace and the PCF trace at the point at which a query executes.
Use caution with this tracing option as it can be very performance intensive. As a general rule,
Guidewire recommends that you do not enable this tracing option unless there are very
specific reasons to use it.
Query Optimizer Tracing (Oracle) This trace indicates how the database arrived at a specific execution path. This creates
a trace file on the database server.
High Resolution Clock (Microsoft Windows) This tracing option uses the Microsoft Windows 100 nanosecond clock.
Extended Query Tracing This trace tracks the parse-execute-fetch actions of a SQL statement. If executing against an
Oracle database, this tracing option also tracks any wait times associated with the SQL
statement, including what the cause of the wait.
This stack trace creates a trace file on the database server.
Diff DBMS Instrumentation (Oracle) Enable this option to capture the DBMS counters at the beginning of the profiling
Counters session and to include analysis of the differences in the DBMS-specific report.
DBMS Instrumentation Capture (Oracle) The Profiler generates a DBMS report if an action exceeds the threshold value set by
Threshold for each Action (millis) this option. This tracing option is available only if you first enable Diff DBMS Instrumentation
Counters tracing. Click Edit Configuration and select Edit DBMS Instrumentation Capture Threshold (millis)
to edit the default value of 0.

See also
• “Profiler Entry Points” on page 401
• “Web Session Profiling” on page 402
• “ClaimCenter Application Profiling” on page 403
• “Guidewire Profiler Analysis” on page 404

Guidewire Profiler Analysis

After you disable the current application profiling session, ClaimCenter generates a Profiler Analysis screen, or, in the
case of Web profiling, a Web Profiler screen.
The Profiler Analysis screen of the Guidewire Profiler contains the following regions:
• Profiler Source – Lists each profiler run in the current user session. To see the results for a particular run, select
it from the Name list.
• Profiler Results – Provides a means to view different views of the profiler data for the selected run. Selecting a
different view type updates the screen data to reflect your choice.

View Type Result

Stack Queries Lists the queries that were executed by each stack. The first list shows the stacks in the profiled session. The
second shows the queries executed in that stack. More details can be obtained by clicking on each tab.
Aggregated Queries Lists all queries executed as part of the profiled session and some statistics about them, including number
of times executed, average time, and more.

404 chapter 23 Server Tools

 System Administration Guide 9.0.5

View Type Result

Search by Query Searches the session for a query. This view enables you to determine the source of a particular query. Paste
in a query, for example from the AWR report, and click Search.
Elapsed Lists each frame in chronological order within its stack along with the time in seconds between when
ClaimCenter pushed and then popped the frame.
Chrono Lists each frame in chronological order within its stack along with the time in seconds between ClaimCenter
creating the stack and pushing the frame. See the Rules Guide.
Group Frames Lists frames in each stack aggregated by tag and presented in order of total aggregate time on the stack.
Group Stacks Presents data similar to that presented in the Group Frames view, except Guidewire Profiler aggregates the
frames across all stacks in the session instead of by stack.
Stacks Grouped Lists the stacks in the profiling session grouped by name, along with timing information on each stack
group.
Rule Execution Lists rules that fired during the session. If no rules fired during the session, the Profiler Result region contains
the message “No profiler stacks found”.

See also
• “Guidewire Profiler” on page 400
• “View Uploaded Profiler Reports” on page 406
• Rules Guide

Save a Profiler Analysis Report

About this task
This procedure creates a .gwprof file that you can download and store outside of Guidewire Profiler. To view the
contents of this file, you must upload the .gwprof file back into Guidewire Profiler.

Procedure
1. Navigate to the Server Tools Guidewire Profiler→Profiler Analysis→Profiler Analysis screen.
2. Select the profiler entry point, for example, Batch Processes.
3. In the Profiler Source area at the top of the screen, select the report that interests you.
4. In the Profiler Result area, select a value from the View Type drop-down list.
5. Click Download.
6. In the dialog that opens, select Save File and click OK.

Next steps
See also
• “View Uploaded Profiler Reports” on page 406

Ways to View a Guidewire Profiler Analysis Reports

It is possible to view Guidewire Profiler analysis reports in any of the following ways.

View type For more information

View current report in Profiler Analysis screen “Guidewire Profiler Analysis” on page 404
Search for historical report and view in Profiler Analysis screen “View Historical Profiler Reports” on page 406

Guidewire Profiler 405

 System Administration Guide 9.0.5

View type For more information

Upload historical report and view in Profiler Analysis screen “View Uploaded Profiler Reports” on page 406

See also
• “Guidewire Profiler” on page 400

View Historical Profiler Reports

Procedure
1. Navigate to the Server Tools Guidewire Profiler→Profiler Analysis→By Time Range screen.
2. Click Search.
The screen shows two calendar date pickers.
3. Enter a start and stop date in which to search for existing profiler analysis reports.
ClaimCenter prints the results of the search to the screen:
• If ClaimCenter finds no existing profiler reports that occurred within the specified time frame, it prints a
message to that effect.
• If ClaimCenter does find one or more profiler reports that occurred within the specified time frame, it lists
the reports.
4. In the Profiler Source area at the top of the screen, select the report that interests you.
5. In the Profiler Result area, select a value from the View Type drop-down list.

View Uploaded Profiler Reports

Before you begin

The file to upload must be a file with a .gwprof extension downloaded previously from Guidewire ClaimCenter.

Procedure
1. Navigate to the Server Tools Guidewire Profiler→Profiler Analysis→Saved File screen.
2. In the Restore Snapshot field, browse to find a .gwprof file for upload.
3. Click OK.

Result
The saved profiler data loads in the Saved File screen. which then becomes the Profiler Analysis screen. If you navigate
away from this screen, Guidewire Profiler deletes the uploaded data from the screen.

Next steps
See also
• “Save a Profiler Analysis Report” on page 405

Review Profiler Upgrade Information

About this task
The Guidewire Profiler Upgrade screen provides profiler analysis of upgrade operation on the ClaimCenter server.
The Upgrade screen provides information on the database upgrade at initial server start and all subsequent upgrade
operations.

406 chapter 23 Server Tools

 System Administration Guide 9.0.5

Procedure
1. Navigate to the Server Tools Guidewire Profiler→Profiler Analysis→Upgrade screen.
2. In the Profiler Source area at the top of the screen, select the report that interests you.
3. In the Profiler Result area, select a value from the View Type drop-down list.

Next steps
See also
• “Upgrade and Versions” on page 393
• “Guidewire Profiler” on page 400
• “Guidewire Profiler Analysis” on page 404

Profiler Tags
Profiler tags represents sections of code that Guidewire Profiler can profile. A profiler tag is an alias for a piece of
code in the Guidewire application for which you want to gather performance information.
The code represents profiler tags by instances of the gw.api.profiler.ProfilerTag class. The constructor for the
ProfilerTag takes a String parameter defining the ProfilerTag name.
Always create a static final ProfilerTag object and preserve it. If you attempt to create more than one instance of
the same ProfilerTag object, ClaimCenter generates a warning message in the application log that is similar to the
following:

WARN Duplicate tag name: tag_name

Profiler Frames
A profiler frame contains information corresponding to a specific invocation of profiled code, such as its start and
finish times.
In each Profiler session:
• Whenever the code calls push on the profiler stack, Guidewire Profiler creates a profiler frame and pushes the
frame onto the stack.
• Whenever the code calls pop on the profiler stack, Guidewire Profiler removes the profiler frame from the stack.
The Profiler continues to stores the frame information, however, so as to make the information available for
future examination.
The code represents Profiler frames by instances of gw.api.profiler.ProfilerFrame.
See also
• “Understanding Properties and Counters on a Frame” on page 408

Profiler Stacks
A profiler stack stores profiling information for a specific thread. A profiler stack implements the standard push and
pop functionality of a stack. The push and pop actions correspond to the beginning and end, respectively, of a piece
of code represented by a profiler tag. Thus, at any time, the current contents of the profiler stack reflect all profiler
tags whose code ClaimCenter is currently executing. The code represents Profiler stacks by instances of
gw.api.profiler.ProfilerStack.
If a profiler stack has been initialized for the current thread, the call to Profiler.push(ProfilerTag.MYTAG)
pushes a new frame with tag MYTAG on to that profiler stack. Otherwise, the call has no effect.
Similarly, Profiler.pop(frame) is just a pass-through to calling pop on the profiler stack of the current thread.

Guidewire Profiler 407

 System Administration Guide 9.0.5

Using Custom Profile Tags with Guidewire Profiler

It is possible to profile custom code in the Server Tools Guidewire Profiler by creating your own custom profile tags.
To define a custom Profiler tag, create a globally-accessible Gosu class using the Java-based CCProfilerTag class
as a model. Guidewire recommends that you add all custom profiler tags to this Gosu class.
The following sample code illustrates how to create a custom Gosu class for custom profiler tags.

package gw.profiler

uses gw.api.profiler.ProfilerTag

class MyProfilerTags {
public static final var MY_TEST_TAG1 = new ProfilerTag("MyTestProfiler1")
public static final var MY_TEST_TAG2 = new ProfilerTag("MyTestProfiler2")
public static final var MY_TEST_TAG3 = new ProfilerTag("MyTestProfiler3")
//..

private construct() {
// Do not instantiate}
}
}

To profile a block of custom code, use the following pattern to push and pop profiling information onto the profiler
stack.

uses gw.api.profile.Profiler
...

ProfilerFrame frame = Profiler.push(ProfilerTag.MY_TEST_TAG1)

try {
// CODE TO PROFILE
} finally {
Profiler.pop(frame)
}

See also
• “Understanding Properties and Counters on a Frame” on page 408

Profiling Spawned Threads

Some processes spread their workload across multiple threads. If you want to use Guidewire Profiler to profile these
threads, use the following pattern:

gw.api.profiler.Profiler.createPotentiallyProfiledRunnable(ProfilerTag entryPointTag,
String entryPointDetail, GWRunnable block)

This generates a new Runnable object that executes the given block. This Runnable object profiles the block if the
calling thread is also being profiled. If this is the case:
• The Profiler associates the stack for that thread with the stack of the calling thread.
• The Profiler persists that thread along with the stack of the calling thread.
See the Javadoc for the Profiler.createPotentiallyProfiledRunnable method for more details.

Understanding Properties and Counters on a Frame

Guidewire profiler frames can hold custom properties and counters that provide more information about system
events. Consider the following example:

uses gw.api.profiler.Profiler
uses gw.api.profiler.ProfilerTag

public class MyProfilerTags {

408 chapter 23 Server Tools

 System Administration Guide 9.0.5

public static var paramValue : String

public static var ctrValue : Integer

var frame = Profiler.push(MyProfilerTags.myProfilerTag)

public function profileCode() {

public static var myProfilerTag: ProfilerTag = new ProfilerTag("MY_TAG")

try {

//Some paramter value, set by method code...

var param = "some parameter value"

//Some counter value, set by method code

var ctr = 5

frame.setPropertyValue("PARAMETER", param)
frame.setCounterValue("COUNTER", ctr)

} finally {

Profiler.pop(frame)

After the sample code pops a profiler frame off the stack, the frame contains information about the calculated values
of PARAMETER and COUNTER. The Server Tools Profiler Analysis screen then shows these values as well.
See also
• “Guidewire Profiler” on page 400
• “Guidewire Profiler Analysis” on page 404
• “Using Custom Profile Tags with Guidewire Profiler” on page 408

Understanding the Guidewire Profiler API

You can use the ProfilerAPI web service to configure the profiler from an external system. In addition to enabling
and disabling profiling for the various entry points, you can enable Web profiling on all subsequent sessions. This
API does not provide the ability to profile a specific session or to profile active sessions.
See also
• Integration Guide

Profiler-related Configuration Parameters

Guidewire provides several profiler-related configuration parameters in config.xml. The first two configuration
parameters in the list refer to SQL Server databases only.

Parameter For more information

IdentifyQueryBuilderViaComments Configuration Guide

IdentifyORMLayerViaComments Configuration Guide

ProfilerDataPurgeDaysOld Configuration Guide

See also
• “Guidewire Profiler” on page 400
• Gosu Reference Guide

Guidewire Profiler 409

 System Administration Guide 9.0.5

JProfiler
JProfiler is a third-party tool available from ej-technologies. It is a Java profiler for use with CPU, memory, and
thread profiling. Consult the ej-technologies product documentation for details on how to use JProfiler.

Metro Reports
The Server Tools Metro Reports page tracks the Metropolitan Reporting Bureau reports that ClaimCenter is
processing. This is a cumulative reporting showing all the reports and their current status. You can filter the list of
reports by date, status, and step. You can also use this page to resume the processing of reports.

410 chapter 23 Server Tools

chapter 24

Internal Tools

Guidewire provides internal tools to assist you with certain administrative tasks.

WARNING Guidewire does not support the use the tools found in the Internal Tools screens. Guidewire provides
these tools for use during development only. Guidewire does not support the use of these tools in a production
environment. Use these tools at your own risk.

See also
• “Server Tools” on page 349

Accessing the Internal Tools

The server must be in development mode and you must have the internaltools permission to access the Internal
Tools screens. In the base configuration, the Superuser role has this permission by default.
To access the Internal Tools screens, press ALT+SHIFT+T on any ClaimCenter screen after you log into the application
as a user with the necessary role permission.
See also
• “Server Modes” on page 57

Reload
The Reload screen is useful while you develop a configuration. From this screen you can reload key configuration
files into a running ClaimCenter installation. You can choose from the following options:

Option Description
Reload PCF Files Verifies and reloads all PCF files. If there are errors in the PCF files, ClaimCenter writes the errors to the
log.
Verify All PCF Files Verifies the PCF files without reloading them.
Reload Web Templates Reloads the entire ClaimCenter user interface including the config/web/templates directory.

Internal Tools 411

 System Administration Guide 9.0.5

Option Description
Reload Workflow Engine Reloads the Workflow engine.

Reload Display Names Reloads label definitions only from the display_languageCode.properties file for the locale.

CC Sample Data
The CC Sample Data screen is for loading sample data into ClaimCenter for development purposes only. Guidewire
does not support this tool for a production environment.
See also
• Installation Guide

412 chapter 24 Internal Tools

chapter 25

Command Prompt Tools

ClaimCenter includes a number of administrative tools as command prompt tools that you can use for help with
administrative tasks on your ClaimCenter server.
Note: For tools that build ClaimCenter, see the Installation Guide.

Administration Tools Overview

ClaimCenter provides a set of tools that you can use to perform administrative tasks directly from a command
prompt. Typically, these commands are meant to run on an administrator’s workstation. The tools are all found in the
ClaimCenter/admin/bin directory, unless otherwise noted. These tools all execute against a running ClaimCenter
instance.
There are *.bat and *.sh versions of each administration tool to support installations on Windows and UNIX
systems, respectively. You can only use these tools if the ClaimCenter server is actively running.

ClaimCenter Command Prompt Tools Summary

The following list provides a summary of the ClaimCenter administration tools available from a command prompt.

Tool Description
“Data Change Command” on page Provides a mechanism for making changes to code on a running production server.
415
WARNING Only use the data_change command under extraordinary conditions,
with great caution, and upon advice of Guidewire Support. Before registering a
data change on a production server, register and run the data change on a
development server. Guidewire recommends multiple people review and test the
code and the results before attempting the data change on a production server.

“FNOL Mapper Command” on page Integration tool that imports FNOL reports, which are initial claim reports, from a
416 standard XML-based file format called ACORD XML. See the Integration Guide for details.
“Import Tools Command” on page Set of utilities for loading XML-formatted data into ClaimCenter.
417

Command Prompt Tools 413

 System Administration Guide 9.0.5

Tool Description
“Maintenance Tools Command” on Set of utilities for performing maintenance operations on the server (for example,
page 418 running escalation/exception rules, calculating statistics, and more.)
“Messaging Tools Command” on Provides a set of utilities for managing integration event messages (for example, retrying
page 420 a message, skipping a message, purging the message table, and more).
“System Tools Command” on page Provides a set of utilities for controlling the server (for example, pinging the server,
422 bringing the server in and out of maintenance mode, updating database statistics, and
more.)
“Table Import Command” on page Used for importing tables into the database.
430
“Template Tools Command” on Helps in converting between template versions.
page 432
“Workflow Tools Command” on Allows you to manage user workflows in the system.
page 434
“Zone Import Command” on page Loads zone data from a file to a staging table.
434

Accessing Administration Tool Help

To access help for any of the ClaimCenter command prompt tools, enter -help after the tool name. For example,
enter the following at the command prompt to generate a list of command options with a description of each option
for the import_tools administrative tool:

import_tools -help

Administration Tools Default User

To run the ClaimCenter command prompt tools, you must supply a user name and password for a user with
administrative privileges. If you do not supply a value for the -user parameter, the command defaults to user su (in
the base configuration) and you must supply that user’s password.

Administrative Tool Command Syntax

The administrative tools command descriptions use the following command syntax.

tool_name Bold font indicates that this is the actual command name, for example, import_tools.
-option All command options start with a minus sign (-). Command options are either mandatory or optional. See the
following discussion.
| An upright bar indicates a Boolean OR. For example, A | B | C means A or B or C.
{ ... } A set of curly braces indicates a set of mutually exclusive choices. You must one chose (and only one) item from a
set of choices. For example, { A | B | C } indicates you must choose either A or B or C, but not more than of
one the listed options.
arguments Specifies the arguments required by a tool option such as a file name or directory, for example, import_tools ...
-import file.

... A series of dots after the argument indicates that you can enter multiple items of the same type. For example, -i
mport file ... indicates that you can enter multiple file names (file) after the -import argument.

[ ... ] A set of square brackets indicates that the argument is optional. For example, [-user] indicates that the
command permits you to set a user value (-user), but does not require that you set this value.

414 chapter 25 Command Prompt Tools

 System Administration Guide 9.0.5

In contrast, an argument not enclosed in square brackets indicates that an argument is mandatory. For example,
for all the administrative commands, the -password argument is mandatory. Thus, the command syntax does not
surround the -password argument by square brackets as the argument is mandatory.

Data Change Command

ClaimCenter provides a tightly constrained system for updating data on a running production server. Guidewire calls
this mechanism the Production Data Fix tool. The Production Data Fix tool uses either the data_change command
option, or, the DataChangeAPI web service to make changes to the production data.
Because the data_change command allows arbitrary execution of data, Guidewire strongly recommends that you
carefully control the ability to create and run code on a production server. The user who runs this command must
have permission wsdatachangeedit.

WARNING Only use the Production Data Fix tool under extraordinary conditions, with great caution, and upon
advice of Guidewire Support. Before registering a data change on a production server, register and run the data
change on a development server. Guidewire recommends multiple people review and test the code and the
results before attempting the data change on a production server.

data_change -help
data_change -password password [-server url] [-user user] {
-edit refID -gosu filepath [-description desc] |
-discard refID |
-status refID |
-result refID }

See also
• For a description of how and when to use the data_change command to change data on a running production
server, see “Production Data Fix Tool” on page 319.
• For a description of how to use the DataChangeAPI web service, see “Data Change Web Service Reference” on
page 325.

Data Change Options

You can use any of the following options with the data_change command. You must always supply the -password
option.

WARNING Only use the Production Data Fix tool under extraordinary conditions, with great caution, and upon
advice of Guidewire Support. Before registering a data change on a production server, register and run the data
change on a development server. Guidewire recommends multiple people review and test the code and the
results before attempting the data change on a production server.

Option Description
-description desc Human-readable description (desc) of the change. Include this option with the edit option. For
testing, the description is optional. For production use, include the description. Put quotes around
the description to permit space characters in the description.
-discard refID Instruction to discard a data change that you already registered. You must supply a data change
reference ID (refID). You cannot discard a data change that was already run.
-edit refID Instruction to create a new data change or edit an existing data change. You must supply a unique
reference ID (refID) for this data change.
If the data change succeeded with no compile errors, you cannot edit it. You must re-register the
script with a new reference ID.
If the data change was never run, or had compile errors, you can update (edit) the Gosu code with
the same reference ID.

Data Change Command 415

 System Administration Guide 9.0.5

Option Description
If you use the edit option, you must:
• Include the -gosu option to include your Gosu data change code
• Include the -description argument to provide a description
-gosu filepath Full path name (filepath) to a Gosu script. You must include this option with the edit argument.
You can use a full path name, or a relative path that is relative to the current working directory.
-password password Password (password) to use to connect to the server. ClaimCenter requires the password.
-result refID Result of a data change that you already registered. You must supply a data change reference ID (re
fID). If a user attempted to run it and there were parse errors, the results include the errors.

-server url Specifies the ClaimCenter host server URL. Include the port number and web application name, for
example:
http://servername:8080/cc

-status refID Status of a data change that you already registered. You must supply a data change reference ID (re
fID). This option prints the status of the data change, which is one of the following:
• Open
• Discarded
• Executing
• Failed
• Completed
-user user User (user) to use to run this process.

FNOL Mapper Command

fnol_mapper -help
fnol_mapper -password password [-server url] [-user user] [-D name=value]
-input filename [-mapper filename] [-resultfile filename]

The fnol_mapper command accepts first notice of loss (FNOL) claim data in an XML file. A mapping class file
contains a series of directives to transform the incoming FNOL data into a ClaimCenter Claim object. Then,
ClaimCenter imports the object.
The fnol_mapper command calls the ClaimAPI.importClaimFromXML method. See the Gosu documentation for
details. Generate Gosu documentation by opening in a command prompt in the ClaimCenter installation directory
and running the command gwb gosudoc.
See also
• Integration Guide
• Gosu Reference Guide

FNOL Mapper Options

You can use any of the following options with the fnol_mapper command. You must always supply the -password
option.

Option Description
-input filename Name of XML input file. This command option is mandatory.
-mapper classname Name of XML mapper class that contains directives to transform FNOL data into a Claim object. By
default, fnol_mapper knows how to map from ACORD format.
-password password Password (password) to use to connect to the server. ClaimCenter requires the password.

416 chapter 25 Command Prompt Tools

 System Administration Guide 9.0.5

Option Description
-resultfile filename Name of the file to dump XML output. By default, fnol_mapper outputs to stdout.

-server url Specifies the ClaimCenter host server URL. Include the port number and web application name, for
example:
http://serverName:8080/cc

-user user User (user) to use to run this process. This command option is mandatory.

Import Tools Command

import_tools -help
import_tools -password password [-server url] [-user user] {
-import filename1, filename2 ... [-charset charset] [-dataset dataset]
[-ignore_all_errors] [-ignore_null_violations]
[ { -output_csv filename | -output_xml filename } ] | -privileges }

The import_tools command imports new or updated data into existing tables in the ClaimCenter database. You can
only import data for valid entities or their subtypes. ClaimCenter supports this command for importing
administrative data but not for importing other data into ClaimCenter. Instead, use staging tables or APIs other than
the ImportToolsAPI to import non-administrative types of data into ClaimCenter.
Note: ClaimCenter does not fire any events related to the data you add or modify through this command.
ClaimCenter does not throw concurrent data change exceptions if the imported records overwrite existing records
in the database.
Data that you import into ClaimCenter through the use of import_tools is immediately available. You do not need
to restart the ClaimCenter server for the changes to take effect.

IMPORTANT Guidewire supports using the import_tools command to import administrative data only.

IMPORTANT The MaximumFileUploadSize parameter in config.xml must exceed the size of any file that you
attempt to import. The MaximumFileUploadSize parameter value is in megabytes (MB). The base configuration
default value of MaximumFileUploadSize is 20 MB.

See also
• “Ways to Import Administrative Data” on page 291
• “About the import Directory” on page 292
• “Using Tools to Import Administrative Data” on page 302
• Integration Guide

Import Tools Options

You can use any of the following options with the import_tools command. You must always supply the -password
option.

Option Description
-charset charset Character set encoding (charset) for the files to import.If this option is null, ClaimCenter
sets the default character encoding to UTF-8. See also “Character Set Encoding for File
Import” on page 294.
-dataset integer Integer value (integer) representing the dataset to import from a CSV-formatted file, for
example:
RolePrivilege,0,default_data:2,abview,adjuster

Import Tools Command 417

 System Administration Guide 9.0.5

Option Description
ClaimCenter orders datasets by inclusion. The number of the smallest dataset is always 0.
Thus, dataset 0 is a subset of dataset 1, and dataset 1 is a subset of dataset 2, and so forth.
To import all data, set this value to -1.
-ignore_all_errors Causes the tool to ignore any errors in a CSV-formatted input file.
-ignore_null_violations Causes the tool to ignore violations of null constraints in a CSV-formatted input file.
-import filename1, filename Imports administrative data from one or more CSV (comma-separated values data) files or
2, ... XML files.
It is possible to provide a list of file names in a separate file. To do so, create a file that
contains a comma-separated list of files names. Prefix an @ character to the name of the
list file, for example:
-import @files.lst
To convert data using the -output_csv or -output_xml options, provide only a single file
name.
-output_csv filename If used with the -import option, outputs comma-separated values to the specified file and
then stops processing. ClaimCenter imports no data into the server. Use this option to
convert XML input files to CSV-formatted output files.
-output_xml filename If used with the -import option, outputs XML to the specified file and then stops
processing. ClaimCenter imports no data into the server. Use this option to convert CSV
input files to XML-formatted output files.
-password password Password to use to connect to the server. ClaimCenter requires the password value.
-privileges Adds the role privileges contained in file roleprivileges.csv in the Studio modules/conf
iguration/config/import/gen folder to those roles that already exist in the database.
See also “About Adding Admin Data after Initial Server Startup” on page 294.
-server url Specifies the ClaimCenter host server URL. Include the port number and web application
name, for example:
http://servername:8080/cc

-user user User to use to run this process.

Maintenance Tools Command

maintenance_tools -help
maintenance_tools -password password [-server url] [-user user] {
-changesubtypepublicid id -changesubtypetargettype type |
-forceall |
-markforpurge { -claims n1, n2... | -file filename } [-purgefromaggregatelimits] |
-processstatus process |
-rebuildagglimits { -claims n1, n2... | -file filename | -policies } |
-restore { -claims claimnumber | -file filename }
-scheduleforarchive { -claims n1, n2... |-file filename } |
-startprocess process [-args arg1 arg2 ...] |
-terminateprocess process |
-whenstats }

The maintenance_tools command starts, terminates, or retrieves the status of a ClaimCenter process. For a list of
processes that the maintenance_tools command can start, see “The Work Queue Scheduler” on page 93.

Maintenance Tools Options

You can use any of the following options with the maintenance_tools command. You must always supply the -
password option.

418 chapter 25 Command Prompt Tools

 System Administration Guide 9.0.5

Option Description
-args arg1 arg2 ... Arguments to use while starting a process. Use only with -startprocess.
If you have multiple arguments, separate each one with a space. The
command does not validate the provided arguments.
To use arguments with custom batch processes, see the Integration Guide,
especially the following method:
ProcessesPlugin.createBatchProcess(type, args)

-changesubtypepublicid ID Public ID of the contact whose subtype you want to change. You must also
set the following option if using this option:
-changesubtypetargettype

-changesubtypetargettype type Target type to which to change the contact. You must also set the following
option if using this option:
-changesubtypepublicid

-claims n1, n2, n3, ... Comma-separated list of one or more claim numbers (n1, ...). Several
other options use -claims to select the claims on which to operate.
It is not possible to combine this option with either the -file or -policie
s options.

-file filepath Path (filepath) to a CSV-formatted file containing a comma-separated list

of claim numbers. Several other options use -file to select the claims on
which to operate.
It is not possible to combine this option with either the -claims or -polic
ies options.

-forceall If true:
• Instructs the -rebuildagglimits command option to mark all
aggregate limits in the database as invalid.
• Starts the AggLimitCalc work queue to rebuild the aggregate limits
asynchronously.
-markforpurge -claims n1, n2, n3, ... Marks the claims identified by claim number (n1, ...) for purge. See also
“Understanding Claim Purging” on page 273.
-markforpurge -file Marks the claims identified in -file for purge. See also “Understanding
Claim Purging” on page 273.
-password password Password (password) to use to connect to the server. ClaimCenter requires
the password.
-policies n1, n2, n3, ... Comma-separated list of one or more policy numbers (n1, ...). The rebu
ildagglimits command option uses -policies to select the policies on
which to operate.
It is not possible to combine this option with either the -claims or -file
options.
-processstatus process Returns the status of a batch process. For the process value, specify a valid
process name or a process ID.
For work queues, this option returns the status of the writer process. It
does not check whether additional work items remain in the work queue.
Thus, it is possible for the process status to report completion after the
writer finishes adding items to the work queue while the work queue
contains unprocessed work items.
-purgefromaggregatgelimit Use this option with the -markforpurge option to determines whether to
purge claims that are part of an aggregate limit. A value of true means
purge the claims. A value of false means do not purge the claims.

Maintenance Tools Command 419

 System Administration Guide 9.0.5

Option Description
-rebuildagglimits Rebuilds the aggregate limits on policy periods for policies identified by -p
olicies, or the policy periods that contain claims identified by -claims or
-file.
Guidewire recommends that you increase the number of workers used for
this process. See “Aggregate Limit Calculations Batch Processing” on page
104 for details.
-restore -claims claimnumber Restores one or a group of claims from the archive, with the supplied
comment.
To restore a single claim, type:
maintenance_tools -restore comment -claims claimnumber -use
r user -password password
To restore a group of claims, use the same options, but replace claimnumbe
r with a file name. This ASCII file must contain a list of claim numbers,
separated by new lines.
-restore -file filename Restores a group of claims from the archive, with the supplied comment.
This option uses the following format:
maintenance_tools -restore comment -file filename -user use
r -password password
The ASCII file specified by filename must contain a list of claim numbers,
separated by new lines.
-scheduleforarchive -claims claimNumber1, Flags an individual claim or comma-delimited list of claims for archiving. A
claimNumber2... separate process later archives claims flagged by this process. See the
Integration Guide.
-scheduleforarchive -file filename Flags multiple claims for archiving. The file contains a list of claim numbers
to schedule for archiving. A separate process later archives claims flagged
by this process. See the Integration Guide.
-server url Specifies the ClaimCenter host server URL. Include the port number and
web application name, for example:
http://serverName:8080/cc

-startprocess process -args... Starts a new batch process. For the process value, specify a valid process
code. See also -args.
For a list of batch process codes, including work queue writer processes,
see “Work Queues and Batch Processes, a Reference” on page 103.
-terminateprocess process Terminates a batch process. For the process value, specify a valid process
name or a process ID.
It is not possible to terminate single phase processes using this option.
Single phase processes run in a single transaction. Thus, there is no
convenient place to terminate the process. See “Work Queues and Batch
Processes, a Reference” on page 103 to determine if it is possible to
terminate a process.
-user user User (user) to use to run this process.
-whenstats Reports the last time ClaimCenter calculated statistics on the server.

Messaging Tools Command

messaging_tools -help
messaging_tools -password password [-server url] [-user user] {
-config destinationID |
-purge date |
-restart -destination destinationID [-wait wait] [-retries retries] [-initial initial]

420 chapter 25 Command Prompt Tools

 System Administration Guide 9.0.5

[-backoff backoff] [-poll poll] [-threads threads] [-chunk chunk] |

-resume destination destinationID |
-resync -destination destinationID -claim claimID |
-retry messageID |
-retrydest destinationID |
-skip messageID |
-statistics destinationID |
-suspend destinationID }

You use the messaging_tools command to manage a message destination from the command prompt. To do so,
you must know the message destination ID. The person who creates the message destination assigns this ID. You
create and configure message environments and destinations in file messaging-config.xml. Access messaging-
config.xml in Guidewire Studio at the following location:
configuration→config→Messaging

Messaging Tools Options

You can use any of the following options with the messaging_tools command. You must always supply the -
password option.

Option Description
-claim claimID Use to specify the claim ID (claimID) of the claim to re-synchronize. See. -resync.
-config -destination destinationID Returns the configuration for a message destination.
-destination destinationID Specifies a message destination (destinationID).
-password password Password (password) to use to connect to the server. ClaimCenter requires the
password.
-purge date Deletes completed messages that are older than a specified date. The purge tool
deletes messages in Acked, ErrorCleared, Skipped or ErrorRetried state with
send time before the specified date. The date format is mm/dd/YYYY.
If the purge tool succeeds in removing these messages without error, it reports Me
ssage table purged.
Since the number and size of messages can be very large, periodically use this
command option to purge old messages to avoid the database from growing
unnecessarily.
-restart -destination destinationID Restarts the messaging destination with new configuration settings:
-wait wait • destinationID – The destination ID of the destination to restart.
-retries retries • wait – the number of seconds to wait for the shutdown before forcing it.
-initial initial • retries – The number of automatic retries to attempt before suspending the
-backoff backoff messaging destination.
-poll poll • initial – The amount of time in milliseconds after a retryable error to retry
sending a message.
-threads threads
• backoff – The amount to increase the time between retries, specified as a
-chunk chunk
multiplier of the time previously attempted. For example, if the last retry time
attempted was 5 minutes, and backoff is set to 2, ClaimCenter attempts the
next retry in 10 minutes.
• poll – Each messaging destination pulls messages from the database (from the
send queue) in batches of messages on the batch server. The application does
not query again until pollinterval amount of time passes. After the current
round of sending, the messaging destination sleeps for the reminder of the poll
interval. If the current round of sending takes longer than the poll interval,
then the thread does not sleep at all and continues to the next round of
querying and sending. See the Integration Guide for details on how the polling
interval works. If your performance issues primarily relate to many messages
for each primary object for each destination, then the polling interval is the
most important messaging performance setting.
Messaging Tools Command 421
 System Administration Guide 9.0.5

Option Description
• threads – To send messages associated with a primary object, ClaimCenter can
create multiple sender threads for each messaging destination to distribute the
workload. These are threads that actually call the messaging plugins to send
the messages. Use the -threads option to configure the number of sender
threads for safe-ordered messages. ClaimCenter ignores this setting for non-
safe-ordered messages, as ClaimCenter uses one thread for each destination
for these types of messages. If your performance issues primarily relate to
many messages but few messages per claim for each destination, then this is
the most important messaging performance setting. For more information, see
the Integration Guide.
• chunk – number of messages to read in a chunk.
-resume -destination destinationID Resumes the operation of the specified message destination.
-resync -destination destinationID Resynchronizes a claim with specified ID against a specific message destination.
-claim claimID Use -destination and -claim to specify the destination and claim.

-retry messageID Attempts to resend a message that failed. The message must be a candidate for
retrying. A message is a candidate for retry if the error at the destination system is
temporary and the message destination does not have an automatic retry
mechanism. For instance, the message is a candidate for retry if the destination
contains a locked record and refuses the update.
-retrydest destinationID Retries all retryable messages for a message destination.
-server url Specifies the ClaimCenter host server URL. Include the port number and web
application name, for example:
http://serverName:8080/cc

-skip messageID Skips a message with the specified ID. If you mark a message as skipped, then
ClaimCenter stops trying to resend the message. After you skip a message, you can
not retry it.
-statistics destinationID Prints the statistics for the specified destination.
-suspend destinationID Suspends a message destination. Use this command option if the destination
system is going to be shut down or to halt sending while ClaimCenter processes a
daily batch file.
-user user User (user) to use to run this process.

System Tools Command

system_tools -help
system_tools -password password [-server url] [-user user] {
-cancelshutdown serverId |
-cancelupdatestats |
-checkdbconsistency [-tableselection tblSelection -checkTypeSelection checkTypeSelection] |
-completefailedfailover type componentId |
-components |
-daemons |
-dbcatstats [regularTables stagingTables typelistTables] |
-getdbccstate |
-getdbstatisticsstatements |
-getincrementaldbstatisticsstatements |
-getPerfReport ID |
-getupdatestatsstate |
-listPerfReports [number] |
-loggercats |
-maintenance |
-mssqlPerfRpt [numTopQueries numHotObjects collectStatistics] |
-multiuser |
-nodefailed serverId [-evenifincluster -filepath filepath] |
-nodes |

422 chapter 25 Command Prompt Tools

 System Administration Guide 9.0.5

-oraListSnaps numstats |
-oraPerfReport beginSnapshotID endSnapshotID probeVDollarTables |
-ping |
-recalcchecksums |
-reloadloggingconfig |
-requestcomponenttransfer type componentId targetOwner |
-scheduleshutdown serverId [-terminatebatchprocesses | -shutdowndelay minutes] |
-sessioninfo |
-startfullupgrade |
-updatelogginglevel loggername logginglevel |
-updatestatistics description update |
-verifyconfig filepath |
-verifydbschema |
-version }

See also
• “Managing Database Statistics using System Tools” on page 282
• “Database Statistics Batch Processing” on page 114
• Integration Guide

System Tools Options

You can use any of the following options with the system_tools command. You must always supply the -password
option.

Option Description
-cancelshutdown serverId Cancels the planned shutdown of the server specified by serv
erId.

-cancelupdatestats Cancels the process that is updating database statistics if

running. Use the following option to verify the process state:
-getupdatestatsstate

-checkdbconsistency Checks the consistency of data in the database. The -checkdb

consistency option runs consistency checks as an
asynchronous batch process. ClaimCenter provides this option
so that you can schedule consistency checks to run during a
time period of low activity on the database server.
The -checkdbconsistency option has two optional
arguments:
• tblSelection
• checkTypeSelection
Specify the tblSelection argument as one of the following:
• all – Run consistency checks on all tables.
• tableName – The name of a single table on which to run
checks.
• tg.tableGroupName – The name of a table group. Use the
<database> element in database-config.xml to define
table groups. For more information, see the Installation
Guide.
• @fileName – A file name with one or more valid table
names or table group names entered in comma-separated
values (CSV) format. Prefix table group names with tg.,
such as tg.MyTableGroup. You can combine table groups
and individual table names in the same file.

System Tools Command 423

 System Administration Guide 9.0.5

Option Description
Specify the checkTypeSelection argument as one of the
following:
• all – Run all consistency checks on the specified tables.
• checkName – The typecode of a single consistency check to
run.
• @fileName – The name of a file with one or more valid
consistency check names entered in comma-separated
values (CSV) format.
If you specify one optional argument, you must specify both.
To run consistency checks from ClaimCenter, use the Server
Tools Consistency Checks→Info Page screen, described in
“Consistency Checks” on page 361.
For more information, see “Database Consistency Checks” on
page 262.
-completefailedfailover type componentId Manually completes component failover for a failed
component. You must supply the component type (type) and
component ID (componentId).
-components Provides information about the components that exist on
each ClaimCenter server in the cluster. The report contains the
following information for each component:
• Component type
• Component code
• Component state
• Component start date and time
• Server ID of the server instance on which the component
exists
• Component ID
The report information is similar, but not identical, to the
cluster information available from the Server Tools Cluster
Members and Cluster Components screens. See “Cluster Members
and Components” on page 386 for information on these
screens.
-daemons Sets the server to the daemons run level. For information
about the various run levels, see “Server Run Levels” on page
59.
-dbcatstats Used with no arguments, the option returns a ZIP file of
database catalog statistics info for all the tables in the
database.
The -dbcatstats option takes the following optional
arguments:
• regularTables
• stagingTables
• typelistTables
This option, used with three arguments, returns a ZIP file of
database catalog statistics info for the specified tables.
Specify each of the arguments as one of the following:
• all/none – Select all/none tables of this type, or
• <tableName> – The name of a single table of this type, or
• @<fileName> – The name of a file with one or more valid
table names of this type entered in comma-separated
values (CSV) format.

424 chapter 25 Command Prompt Tools

 System Administration Guide 9.0.5

Option Description
For example, -dbcatstats none none all returns database
catalog statistics information for all the typelist tables. You
must specify either no arguments or all three arguments if
you use this command option.
You can specify the target destination for the database catalog
statistics ZIP file by adding the –filepath filepath option. If
you do not provide a path, ClaimCenter uses the current
directory.
This process can take a long time, and it is possible for the
connection to time out. If the connection times out while
running this command option, try reducing the number of
tables on which to gather statistics by using the arguments
listed previously.
For information about configuring database statistics
generation, see “Understanding Database Statistics” on page
279.
-evenifincluster [-filepath filepath] Consider the cluster member as failed even if it is still in the
cluster. Use only with the -nodefailed option.
The -filepath parameter sets the location (filepath) for an
optional report.
IMPORTANT This command option overrides an important
safety check on the server. Use this command option in
certain defined circumstances only. See -nodefailed for
details.
-getdbccstate Returns the status of any currently executing database
consistency checks, for example, Processing or Completed.
-getdbstatisticsstatements Retrieves the list of SQL statements to update database
statistics and prints the list to the console. See
“Understanding Database Statistics” on page 279.
-getincrementaldbstatisticsstatements Retrieves the list of SQL statements to update database
statistics for tables exceeding the change threshold. Prints the
list to the console.
The incrementalupdatethresholdpercent attribute of the <
databasestatistics> element in database-config.xml
defines the change threshold. See “Understanding Database
Statistics” on page 279.
-getPerfReport ID Downloads the performance report with the specified ID. You
can retrieve a list of available performance report IDs by
running the -listPerfReports command option.
-getupdatestatsstate Returns the state of the process running the statistics update.
-listPerfReports number Lists IDs and other information for available database
performance reports. You can specify an optional integer (num
ber) to specify the number of available downloads to list,
ordered starting with the most recent. If unspecified or 0, this
command lists all available downloads.
The list shows the ID of the report and the status, indicating if
the performance report batch job succeeded, failed, or is still
running. The list also includes the start and end times of the
batch job and the description of the batch run.
You can use the ID of the performance report to download the
report with the -getPerfReport ID option.
-loggercats Displays the available logging categories.

System Tools Command 425

 System Administration Guide 9.0.5

Option Description
-maintenance Sets the server to the maintenance run level. For information
about the various run levels, see “Server Run Levels” on page
59.
-mssqlPerfRpt numTopQueries numHotObjects Generates a SQL Server DMV (Dynamic Management Views)
collectStatistics performance report using the MSDMReport batch process. This
command option has the following arguments:
• numTopQueries
• numHotObjects
• collectStatistics
Replace numTopQueries and numHotObjects with integer
values for the number of top queries and hot objects to
report.
Replace collectStatistics with true or false to specify
whether ClaimCenter gathers database statistics while
generating the DMV report.
You must specify all three arguments or none. If you do not
specify any arguments, ClaimCenter uses defaults of 400 top
queries, 400 hot objects, and does collect statistics.
-multiuser Sets the server to the multiuser run level. For information
about the various run levels, see “Server Run Levels” on page
59.
-nodefailed serverId Releases any tasks owned by the ClaimCenter server specified
by serverId. Only use this command option if the server
referenced by serverId has already been stopped or
otherwise shutdown.
See also the -evenifincluster option.
IMPORTANT You must ensure that the server referenced by se
rverId is actually stopped if using the -evenifincluster
option. ClaimCenter does not prevent you from using this
option if the server is still running. However, this option
overrides an important safety check on the server. It can
produce unexpected and possibly negative results if the
server is running.
Use the -evenifincluster option only if both of the
following are true:
• The server in question is no longer running.
• The standard operation of the -nodefailed command
failed due to the server retaining its cluster membership.
-nodes Provides information about each ClaimCenter server in the
cluster. The report contains the following information on each
cluster member:
• ID of this cluster server
• Whether the server instance is actively in the cluster
• Server run level
• Time the server instance started
• Time at which ClaimCenter last updated the server
instance
• Number of user sessions active on the server instance
• Whether a planned shutdown is in progress
• Time of the planned shutdown
• Whether background tasks are still active on the server

426 chapter 25 Command Prompt Tools

 System Administration Guide 9.0.5

Option Description
The report information is similar, but not identical, to the
cluster information available from the Server Tools Cluster
Members screen. See “Cluster Members and Components” on
page 386 for information on that screen.
-oraListSnaps numSnaps Lists numSnaps number of available Oracle AWR snapshot IDs,
starting with the most recent snapshot. You can generate
performance reports using the -oraPerfReport option with
these available beginning and ending snapshot IDs.
-oraPerfReport beginSnapshotID endSnapshotID Generates a Guidewire AWR performance report using the Or
probeVDollarTables aAWRReport batch process. This command option has the
following arguments:
• beginSnapshotID
• endSnapshotID
• probeVDollarTables
Specify the beginning and ending snapshot IDs and whether
to probe VDollar tables. The two snapshots must share the
same Oracle instance startup time.
The third argument can also specify a file by prefixing the file
name with an @ sign, for example, @filename.properties.
Optionally, you can prefix the file name with the path to the
file, if the file is not in the current directory. This file is a
standard properties file with the following property names
(default value in parenthesis):
• probleVDollarTables (false)
• capturePeekedBindVariables (false)
• searchQueriesMultipleHistoricPlans (false)
• searchQueriesBeginSnapOnly (true)
• searchQueriesEndSnapOnly (true)
• includeInstrumentationMetadata (false)
• outputRawData (false)
• includeDatabaseStatistics (true)
• probeSqlMonitor (true)
• capturePeakedBindVariablesFromAWR (false)
• genCallsToAshScripts (false)
You must spell and capitalize each property as shown or
ClaimCenter ignores the property. If you specify a property,
you must set value of that property to either true or false. If
you do not specify a property, ClaimCenter uses the default
value for that property.
The -oraPerfReport option reports the process ID of the
process generating the performance report. You can check on
the status of this process using the following command:
maintenance_tools -processstatus processID
View the performance report on the Info Page. See “Oracle
AWR” on page 377.
-password password Password (password) to use to connect to the server.
ClaimCenter requires the password.

System Tools Command 427

 System Administration Guide 9.0.5

Option Description
-ping Pings the server to check if its active. The returned message
indicates the server run level. The possible responses are:
• MULTIUSER
• DAEMONS
• MAINTENANCE
• STARTING
For information about functionality available at various run
levels, see “Server Modes” on page 57.
-recalcchecksums Recalculates file checksums that ClaimCenter uses for
clustered configuration verification.
-reloadloggingconfig Directs the server to reload the logging configuration file.
-requestcomponenttransfer type componentId Requests transfer of ownership of a component of the
targetOwner specified type (type) and ID (componentId) to the specified
ClaimCenter server (targetOwner).
Use the -components command option to determine the
component information to enter.
The -requestcomponenttransfer command option fails if the
component cannot be successfully stopped or the current
owning server is unable to process the request.
-scheduleshutdown serverId Schedules the planned shutdown of the server specified by se
[-terminatebatchprocesses rverId. Use with the following optional options:

-shutdowndelay minutes] • -terminatebatchprocesses – Determines how the

shutdown process handles the batch processes (including
work queue writers) currently running on the server. See
“About Planned Server Shutdowns” on page 387 for
information on this command option.
• -shutdowndelay minutes – Server shuts down in the
number of minutes specified by minutes.
It is also possible to schedule a server shutdown in the
following ways:
• From the Server Tools Cluster Members screen. See “Cluster
Members and Components” on page 386 for information.
• Through the SystemToolsAPI web service. See the
ClaimCenter Integration Guide for information.
-shutdowndelay minutes Server shuts down in the number of minutes specified by minu
tes. Use with the -scheduleshutdown option only.

-server url Specifies the ClaimCenter host server URL. Include the port
number and web application name, for example:
http://serverName:8080/cc

-sessioninfo Returns the session information of the server.

-startfullupgrade Starts the process of full application upgrade for the entire
cluster of server members. You must shut down all cluster
members and deploy a new WAR/EAR file to each one before
attempting the upgrade.
See the ClaimCenter upgrade documentation for details of the
ClaimCenter application upgrade process.
See the Upgrade Guide for more information.
-terminatebatchprocesses Immediately terminates all running batch processes on the
specified server. Use with the -scheduleshutdown option
only.

428 chapter 25 Command Prompt Tools

 System Administration Guide 9.0.5

Option Description
-updatelogginglevel logger level Sets the logging level of logger with the given name. For the
root logger, specify RootLogger for the logger name.
-updatestatistics description update Launches the Update Statistics batch process to update
database statistics.
It is possible to specify an optional text description (descript
ion) for this batch process execution. ClaimCenter shows the
text of the description on the Execution History tab of the
Database Statistics info page.
Specify one of the following values for update:
• true – Update database statistics for tables exceeding the
change threshold only. Guidewire defines this change
threshold through the incrementalupdatethresholdperc
ent attribute of the <databasestatistics> element in da
tabase-config.xml.
• false – Generate full database statistics.
IMPORTANT Updating database statistics can take a long time
on a large database. Only collect statistics if there are
significant changes to data, such as after a major upgrade,
after using the table_import -integritycheckandload or z
one_import commands, or if there are performance issues.
See also
• “Understanding Database Statistics” on page 279
• “Database Statistics Batch Processing” on page 114
• “Database Statistics” on page 373
-user user User (user) to use to run this process.
-verifyconfig filepath Compares the following two server configurations:
1. The new or target server configuration contained in a
WAR/EAR file pointed to by the filepath parameter.
2. The existing server configuration of the cluster member
on which you run the system_tools command.
The tool provides an on-screen report that contains
information about the feasibility of a configuration upgrade
for the server instances in the cluster. For example, the tool
provides the following types of information:
• Configurations are different – Requires a full ClaimCenter
server upgrade.
• Configurations are identical – No upgrade is necessary.
• Configurations are compatible – Guidewire permits a
rolling upgrade.
If a rolling update is not possible, the command lists the
incompatible or missing files.
If a rolling update is in progress, there are two possible
configurations active in the cluster. Each individual server
instance is using either the source configuration or the target
configuration.
The -verifyconfig command option checks for both
configurations on the server instances on which you run the
command and reports which of the configurations is active on
this cluster member. If neither configuration is active, the
command reports that a rolling update is in progress and that
it is not possible to verify the configuration at this time.

System Tools Command 429

 System Administration Guide 9.0.5

Option Description
-verifydbschema Verifies that the data model matches the underlying physical
database.
-version Returns the running server version, the database schema
version, and configuration version.

Table Import Command

table_import -help
table_import -password password [-server url] [-user user] {
-clearerror |
-clearexclusion |
-clearstaging |
-deleteexcluded [-batch] |
-encryptstagingtbls [-batch] |
-getLoadHistoryReport reportID [-filepath filepath] |
-integritycheck [-allreferencesallowed] [-batch] [-clearerror]
[-numthreadsintegritychecking num ] [-populateexclusion] |
-integritycheckandload [-allreferencesallowed] [-batch] [-clearerror] [-estimateorastats]
[-numthreadsintegritychecking num ] [-populateexclusion] [-zonedataonly] |
-listLoadHistoryReports numReports |
-populateexclusion [-batch] |
-updatedatebasestatistics [-batch] [-integritycheckandload] }

The table_import command loads data from staging tables into ClaimCenter. Most of the options for this
command require the server to be at the MAINTENANCE run level. Before you use those command options, use the
system_tools -maintenance command option to set the server run level to MAINTENANCE. Use the system_tools
-multiuser command option to set the server run level to MULTIUSER after the table import command completes.
It is not possible to use the system_tools -terminateprocess command option to terminate the table_import
command.
See also
• “Load History” on page 382
• “System Tools Command” on page 422
• “The loader Database Configuration Element” on page 231
• Integration Guide

Table Import Options

You can use any of the following options with the table_import command. You must always supply the -password
option.

Option Description
-allreferencesallowed Allows references to existing non-administrative rows in all operational
tables. If there are rows in staging tables for CheckGroup or CheckPortion,
you must use this command option.
This option only applies with the following command options:
-integritycheck
-integritycheckandload
This option corresponds to the Boolean parameter allowRefsToExistingN
onAdminRows that the integrity check methods of the TableImportAPI web
service use. Guidewire recommends that you use this option or the
equivalent API parameter, set to true only if absolutely necessary. For
example, use it in the rare case that a policy period overlap exists between
the existing operational data and the data to load.

430 chapter 25 Command Prompt Tools

 System Administration Guide 9.0.5

Option Description
This option can cause performance degradation during the check and load
process, which would noticeably slow down the loading of staging table.
See also “The Load History Detail Report” on page 383.
-batch Runs the table_import command in a batch process. This option only
applies with the following command options:
-deleteexcluded
-encryptstagingtbls
-integritycheck
-integritycheckandload
-populateexclusion
-updatedatabasestatistics
You can run table_import in a batch process from any node in a
ClaimCenter cluster. However, table import batch processing must run
physically on a server designated as a batch server. Therefore, in running
the command, provide the URL of a batch server and also provide the user
credentials for that batch server.
-clearerror Clears the error table.
See also “The Load History Detail Report” on page 383.
-clearexclusion Clears the exclusion table.
-clearstaging Clears the staging tables. Requires the server to be at the MAINTENANCE run
level.
-deleteexcluded Deletes rows from staging tables based on contents of exclusion table.
-encryptstagingtbls Instructs ClaimCenter to use the current encryption plugin implementation
to encrypt those columns in the staging table marked for encryption. See
also the Integration Guide.
-estimateorastats Executes queries for row counts on production tables and sets the
database statistics. If you do not use this option, the import command uses
information in database statistics to report approximate row counts. Use
the -estimateorastats option only to load production tables that are
empty or have very few rows. Used with the -integritycheckandload
command option.
This command option applies only to Oracle databases.
-filepath filepath Path to target directory in which to download a report. Use with the -getL
oadHistoryReport command option.

-getLoadHistoryReport reportID Downloads a compressed Zip version of the load history report as specified
by the value of reportID. Does not require the server to be at the MAINTEN
ANCE run level. Use the -listLoadHistoryReports option to determine
the ID to use. Use the optional -filepath parameter to specify the target
directory for the download.
-integritycheck Validates the contents of the staging tables. You can optionally specify:
-allreferencesallowed
-clearerror
-numthreadsintegritychecking
-populateexclusion

-integritycheckandload Validates the contents of the staging tables and populate operational
tables. You can optionally specify one of the following command options as
well:
-allreferencesallowed
-clearerror

Table Import Command 431

 System Administration Guide 9.0.5

Option Description
-estimateorastats
-numthreadsintegritychecking
-populateexclusion
-zonedataonly

-listLoadHistoryReports [numReports] Lists the most recent load history reports. Optional parameter numReports
is the number of reports to list:
• If you supply a positive integer for numReports, then ClaimCenter lists
that number of most recent reports.
• If you do not supply a value for numReports, then ClaimCenter lists all
available reports.
Does not require the server to be at the MAINTENANCE run level.
-messagesinks sinks, ... Deprecated. This option does nothing.
-numthreadsintegritychecking num Specifies the number of threads that ClaimCenter is to use in running
database table integrity checks. The value of num has the following
meaning:
• Not specified – ClaimCenter assumes the number of threads to be one,
no multithreading.
• 1 – No multithreading, the default.
• 2 - 100 – ClaimCenter runs the database integrity checks with the
number of specified threads.
• > 100 – ClaimCenter throws an exception.
This option only applies with the following command options:
-integritycheck
-integritycheckandload
Note: This value overrides any value set for attribute num-threads-inte
grity-checking on the database <loader> element in database-config
.xml. See “The loader Database Configuration Element” on page 231.

-password password Password (password) to use to connect to the server. ClaimCenter requires
the password.
-populateexclusion Populate the exclusion table with rows to exclude.
See “The Load History Detail Report” on page 383.
-server url Specifies a ClaimCenter server URL. Include the port number and web
application name, for example:
http://serverName:8080/cc
If running the table import command in a batch process, see -batch for
more information.
-updatedatabasestatistics Updates the database statistics on the staging tables. Run the table import
command with this option after populating the staging tables, but before
using the -integritycheck or -integritycheckandload options.
See “The Load History Detail Report” on page 383.
-user user Specifies the user to use to run this process.
-zonedataonly Sets the import to load zone data only. Used with the -integritycheckan
dload command option.

Template Tools Command

template_tools -help
template_tools -password password [-server url] [-user user] {

432 chapter 25 Command Prompt Tools

 System Administration Guide 9.0.5

-convert_dir directory |
-convert_file filename [working_dir directory] |
-import_dir objectsfile fieldsfile directory [working_dir directory] |
-import_files objectsfile fieldsfile outfile |
-list_all_templates |
-list_doc_template |
-list_email_templates |
-list_note_templates |
-validate_all_doc_templates |
-validate_all_email_templates |
-validate_all_note_templates |
-validate_all_templates |
-validate_doc_templates templateID |
-validate_email_templates templateID |
-validate_note_templates templateID }

The template_tools command contains options to list, manage, and validate document, email, and note templates.
See also
• Integration Guide

Template Tools Options

You can use any of the following options with the template_tools command. You must always supply the -
password option.

Option Description
-convert_dir directory Converts all templates in the specified directory to the new format.
-convert_file filename Converts the specified template to the new format.
-import_dir objectsfile fieldsfile directory Imports context objects and form fields from the provided CSV-
formatted files into all the templates in the specified directory. This
option has the following arguments:
• objectsfile – File containing the context objects for import, in CSV
format.
• fieldsfile – File containing the fields for import, in CSV format.
• directory– Directory that contains the templates to update.
-import_files objectsfile fieldsfile outfile Imports context objects and form fields from the provided CSV-
formatted files into the specified template descriptor file (outfile).
This option has the following arguments:
• objectsfile – File containing the context objects for import, in CSV
format.
• fieldsfile – File containing the fields for import, in CSV format.
• outfile – Template descriptor file to update.
-list_all_templates Lists all templates available for validation, includes document, email,
and note templates.
-list_doc_templates Lists the document templates available for validation.
-list_email_templates Lists the email templates available for validation.
-list_note_templates Lists the note templates available for validation.
-password password Password (password) to use to connect to the server. ClaimCenter
requires the password.
-server url Specifies the ClaimCenter host server URL. Include the port number and
web application name, for example:
http://serverName:8080/cc

-user user User (user) to use to run this process.

Template Tools Command 433

 System Administration Guide 9.0.5

Option Description
-validate_all_doc_templates Validates all document templates.
-validate_all_email_templates Validates all email templates.
-validate_all_note_templates Validates all note templates.
-validate_all_templates Validates all document, email, and note templates.
-validate_doc_template templateID Validates the specified document template with template ID of templat
eID.

-validate_email_template templateID Validates the specified email template with template ID of templateID.
-validate_note_template templateID Validates the specified note template with template ID of templateID.
-working_dir directory Specifies a directory for use as the root (working directory) for relative
paths.

Workflow Tools Command

workflow_tools -help
workflow_tools -password password [-server url] [-user user] {
-complete workflowID |
-resume workflowID |
-resume_all |
-suspend workflowID }

You can also control workflows using the WorkflowAPI web service. See the Integration Guide.

Workflow Tools Options

You can use any of the following options with the workflow_tools command. You must always supply the -
password option.

Option Description
-complete workflowID Completes running workflow for the specified workflow (workflowID).

-password password Password (password) to use to connect to the server. ClaimCenter requires the password.
-resume workflowID Resume named workflow (workflowID) in the error or suspended state.
-resume_all Resume all workflows in the error or suspended state.
-server url Specifies the ClaimCenter host server URL. Include the port number and web application name, for
example:
http://serverName:8080/cc

-suspend workflowID Suspend the named workflow (workflowID).

-user user User (user) to use to run this process.

Zone Import Command

zone_import -help
zone_import -password password [-server url] [-user user] {
-import filename -country country [-clearstaging] [-charset charset] |
-clearproduction [-country country] |
-clearstaging [-country country] }

434 chapter 25 Command Prompt Tools

 System Administration Guide 9.0.5

The zone_import command imports data in CSV format from specified files into database staging tables for zone
data. It is only possible to import zone data for a single country at a time. The zone data files that you import must
contain zone data for a single country only. To load zone data for multiple countries, use the command multiple
times with different, country-specific zone data files each time.
Guidewire expects that you import address zone data upon first installing ClaimCenter, and then at infrequent
intervals thereafter as you receive data updates.
See also
• For a discussion of zone data, importing a zone data file, and working with custom zone data files, see “About
Importing Zone Data” on page 311.
• For more information on database staging tables, see the Integration Guide.
• For information on the web service ZoneImportAPI that also imports zone data, see the Integration Guide.

Zone Import Options

You can use any of the following options with the zone_import command. You must always supply the -password
option.

Option Description
-charset charset Character set encoding of the zone data file. The default is UTF-8.
-clearproduction Clears zone data from the production tables. Optionally, specify the -country option to clear data
for only one country.
-clearstaging Clears zone data from the staging tables. Optionally, specify the -country option to clear data for
only one country.
-country countrycode Used with -import, -clearproduction, and -clearstaging command options:
• If used with the -import option, -country specifies the country of the zone data in the import
file.
• If used with either the -clearproduction or -clearstaging options, -country specifies the
country of the zone data to clear from the tables.
-import filename Imports zone data from the specified file (filename). You must set a value for the -country
option.
If you include the optional -clearstaging option, ClaimCenter clears the data in the staging
tables for the specified country before importing the data from the import file.
-password password Password (password) to use to connect to the server. ClaimCenter requires the password.
-server url Specifies the ClaimCenter host server URL. Include the port number and web application name,
for example:
http://serverName:8080/cc

-user user User (user) to use to run this process.

Zone Import Command 435

 System Administration Guide 9.0.5

436 chapter 25 Command Prompt Tools