Guidewire Best Practices Exam study guide

Avoid using internal path for your classes

com.guidewire.* should be avoided. These can always be potentially changed or replaced during an upgrade.

When referencing typecodes, use the static property on the typelist class instead of the string representation

Use TC_TYPECODE instead of "typecode", example: LossCause.TC_REAREND instead of "rearend"

Use the text for logical operators instead of the symbols

Use "and","or", and "not" instead of "&&", "||", and "!"

Code placement

1) Avoid placing code within the CODE tab of a PCF. Create a UI helper class instead

2) Avoid extending entity enhancements with code supporting UI operations

Avoid using deprecated classes and methods

Guidewire will eventually remove deprecated classes and methods.

Turn on and run Studio Inspections

These analyze configuration resources

Use whitespace effectively

Add spaces around operators
Do not add spaces between parentheses and operators
Indent logical blocks of code by two spaces only
Add a blank line after code blocks
Add two blank lines after methods, including the last method in a class

Comments and Annotations

Document new classes and functions with Javadoc-style comments
Use single-line comments within functions and methods when you need to clarify the intent of the code
Use GoseDoc annotations which are included when generating GosuDoc

"Upgrade-Safe" naming conventions: Add the suffix _Ext to

Columns added to existing entities
Typecodes added to existing typelists
The name of custom entities
The name of custom typelists
New PCF files
Script parameters

Package naming conventions

Use the format customer.application.featurecategory.feature
Customer - company name abbreviation
Application- InsuranceSuite application code (pc, bc, cc, suite)
Feature Category - major feature (delinquency, configuration, integration)
Feature - feature (rating, catastrophe, authentication)
Example: si.suite.integration.authentication

Class naming conventions

Use UpperCamelCase
Do not add _Ext to classes within customer package spaces

Function naming conventions

Use lowerCamelCase
Use a verb that describes that the function is doing i.e. verifyAddress
Do not add _Ext suffix to private functions or enhancements in customer package spaces

Variable naming conventions

Member variable names use lowerCamelCase with a leading underscore i.e. _pluginCallbackHandler
Local variable names use lowerCamelCase short names that describe the purpose i.e. latestPolicyRevision

Display key naming conventions

Add suffix _Ext too all new display keys
Do not modify automatically generated display keys

Logging is

The process of recording application actions and state to a secondary interface

Logging is used for

Application maintenance and troubleshooting
Creating statistics relating to application usage
Auditing by capturing significant events

Typical events to log are

Success / Failure - a transaction or action has succeeded or failed
Recovery - a system went down or connection failed, retried, and recovered
Identification - any large functional areas such as integration, rating, reinsurance, and rules

Logging components - Logger

has a category and level, sends content to an Appender

Logging components - Appender

is an output destination (server console or rolling file)

Logging components - Layout

defines the format of the content sent to an appender

Logging Level - Trace

Description: Fine-grained informational events
When to use: Log method entry and exit

Logging Level - Debug

Description: Detailed informational events
When to use: Log important steps and calculations for diagnosing problems

Logging Level - Info

Description: Coarse-grained informational messages of progress
When to use: Log the occurrence or result of an important event

Logging Level - Warn

Description: Indicate a potential problem
When to use: The user experience has not been affected

Logging Level - Error

Description - Indicate definite problems
When to use: The user experience has been affected

There are 2 ways to initialize a logger in Gosu

Integration: PLLoggerCategory.INTEGRATION
Plugin: PLLoggerCategory.PLUGIN

Use sub-level of existing logging category to maintain structure.

Example: PLUGIN.MotorVehicleRecord

static var _motorVehiclePluginLogger = LoggerFactory.getLogger(PLLoggerCategory.PLUGIN."MotorVehicleRecord")

Logging Format should be

a standard format to simplify analysis of large logs

Guarded Logging should be used

To test log level before logging costly messages (those with expensive expressions)

Typically used with the DEBUG level
Format is - if (_logger.DebugEnabled) { }
Not required for parameterized expressions lacking expensive operations, as in:

var hello = "Hello"
var world = "world"
_logger.debug("{}, {}!", hello, world)

Logging: Exception Messages

Logged at the ERROR level when user interface is affected
Not all exceptions are errors - if they are expected, log at WARN or INFO level
Pass the exception object as the second argument

Logging Guidelines

Log with enough information to explain the state of the application and what was happening
Excessive logging results in large logs with potential performance risk
Insufficient logging results in logs that lack utility

Use care with:
Data that is protected by legal, regulatory, or contractual obligations
Personally Identifiable Information (PII) - do not log PII at all!

Guidewire Query API General Best Practices

Use the property reference (EntityType#Property) for type-safe access to the properties on the query entity type
Use the property reference to filter query results, join to another entity type, order rows in the result set, or to specify a column for a row query
Use query.contains() after other query.compare() operations against indexed columns for better performance against large data sets

Guidewire Query API - Denormalized columns improve performance of

Ends with searches
Case-insensitive searches

Guidewire Query API Anti-Patterns - Bring back only the data you need by

Avoid filtering query results in memory
Avoid filtering query results in the application server
Perform filtering in the database
Avoid the use of where(), first(), last(), firstWhere(), and lastWhere()

Guidewire Query API Anti-Patterns - use dot notation with care because

accessing foreign keys or array fields retrieve additional entities into memory

Guidewire Query API Anti-Patterns - Check for existence of an entity when the number of results is not important by

Verifying the results of a targeted query are not empty
Avoiding hasMatch(), countWhere(), and select().Count

Guidewire Query API Anti-Patterns - When a count is necessary, let the database count the entities and

Avoid countWhere()
Avoid counting collections
Avoid iterating over entities from the database to count them
Avoid counting entities before accessing them
Avoid countWhere() and select().Count

Guidewire Query API Anti-Patterns - Avoid queries to check for new or changed entities, instead

Use Boolean methods getChangedFields, getAddedArrayElements, getChangedArrayElements,
and getRemovedArrayElements
Use specialized methods that test for new or changed entities when available
(Claim.PolicyChanged)

Guidewire Query API Anti-Patterns - Avoid queries to access new or changed entities by

Use Boolean methods getChanged, isFieldChanged, isArrayElementAddedOrRemoved, and isArrayElementChanged
Check the Gosu API for specialized methods on entities

Guidewire Query API Advanced Concepts - Entity queries

should be used unless performance is not adequate

Guidewire Query API Advanced Concepts - Row queries

Use a single database query on the main entity and related entities to return only the data columns you select from the database
Allow you to use only the values contained the query results
Filter the rows returned from the database using query.compare
Involve more code maintenance and should only be used when performance issues are encountered with an entity query
Support database aggregate functions (Avg, Count, Min, Max, Sum)

Guidewire Bundle Management - General information for Bundles

A bundle is an in-memory container for entity instances representing rows in the database
Bundles are read via queries or foreign key and array accessors
Caching at the local and global level improves performance of bundleso Bundles can be read-only or writable

Guidewire Bundle Management - A Current bundle is created by the application and is

Read-only or writeable
Contains entity instances available to current code context

Guidewire Bundle Management - A New bundle is created in code and is

Writeable
Code determines the contents

Guidewire Bundle Management - Bundle commits are

Transactional - all entities are committed, or the entire bundle is rolled back
Automatic when processed by the application in rules, workflows, and some plugins (depends on the underlying code)
Manual bundle processing (managed by your code) required for:
Web services and batch processes that make database changes
Modification to entities returned by queries
Certain plugins
User interface changes when the UI is in read-only mode

Guidewire Bundle Management - Gosu syntax for bundles: Using getCurrent() or newBundle() for

Entities require an explicit commit
New entities must be created with the syntax var myEntity = new MyEntity(bundle)

Guidewire Bundle Management - Gosu syntax for bundles: Using runWithNewBundle ( \ bundle -> {}) with a code block for

Entities are automatically committed
New entities are automatically added to the bundle
Options to create with or without a specified user

Guidewire Bundle Management - Gosu syntax for bundles: Adding entities to a bundle uses

myEntity = myBundle.add(myEntity)

Guidewire Bundle Management - Gosu syntax for bundles: Entities referenced by accessors on entities already in a writable bundle

are also writable

Guidewire Bundle Management - Gosu syntax for bundles: Determine changes/original values in a bundle by using

myEntity.Changed
myEntity.isFieldChanged(Entity#FieldName)
myEntity.getOriginalValue(Entity#FieldName)

Guidewire Bundle Management - Gosu syntax for bundles: Mass updates

Use paging with regular commits for mass updates (for example, in batch processing)
Setting the page size: resultObject.setPageSize(1000)
Bundle or chunk size:
"for (entities in com.google.common.collect.Iterables.partition(resultObject, 250)) {}
Use ScriptParameters to determine the optimal Page/Chunk size

UI Performance Best Practices
3 examples of expensive expressions are

Multi-step dot paths - exposure.Claim.Catastrophe.ClaimsHistory
Array expansion - User.MemberGroups*.DisplayName
Collection methods - allMatch(cond)

UI Performance Best Practices
3 examples of problematic expression usage in the UI are

Called on multiple properties of a single widget
Called on multiple widgets in the same PCF
Solution - create a PCF-level variable that evaluated the expensive expression once

UI Performance Best Practices
Test for visibility or editability of a widget based on permissions by

Examining role privileges directly to determine the user's role uses a collection method in the background and performs poorly
Using application permission keys (perm.System.editobfuscatedusercontact) performs well
Extending the SystemPermissionType typelist with new permissions is a best practice

ListView Performance Best Practices
Using View Entities can

Improve performance for viewing data in a list view
Include data from related entities via a path from the primary entity to a related entity
Be subtyped

ListView Performance Best Practices
Array-backed list view features:

Full set of data reloaded when list view rendered and when paging, sorting, and filtering
Paging, sorting, and filtering are enabled when editing
Example - an array field

ListView Performance Best Practices
Query-backed list view features:

Only the first page of data is loaded when the list view is rendered
Query is rerun and the first page of data is loaded when paging, sorting, and filtering
Paging, sorting, and filtering are disabled when editing
Examples - a query processor field, a finder method, a query builder result

ListView Performance Best Practices
Add columns to list views backed by view entities by

extending the view entity

ListView Performance Best Practices
Reference the display name of an entity in list views to display the object's name

Referencing the object retrieves the entire object
Example - Claim.AssignedUser.DisplayName instead of Claim.AssignedUser
Follow this best practice when the list view is not editable

Post On Change and Client Reflection Best Practices
PostOnChange

Define on triggering widget from PostOnChange tab
Assign value with onChange variableo Avoid using with ListViews

Post On Change and Client Reflection Best Practices
Reflection

Involves both a listening and a triggering widget (there can be more than one of each)
Define on listening widget from Reflection tab
Reflect changes on triggering widget(s)
Can set these properties on listening widget: Available, Custom, InputMask, and ValueRange
Editable and Visible CANNOT be changed
Use with ListViews

GUnit Testing - A GUnit is

Guidewire unit testing framework, used to configure and run repeatable tests of Gosu code

GUnit Testing - GUnits 3 Facts

Available in Studio and can be run from Studio
Can be automated as part of Continuous Integration
Cannot test the User Interface or Gosu Rules

GUnit Testing - Test Classes

Names must end with Test
Extend gw.api.test.XXServerTestClassBase or gw.api.test.XXUnitTestClassBase
Can include beforeMethod/afterMethod methods that run before or after each test method is invoked
Can include beforeClass/afterClass methods that run as test class is loaded or after all tests are executed
Are best organized in packages based on testing needs
Can be created to be reused for repeated functions or data generation

GUnit Testing - Test Methods

Names must be lower camel case, have names that start with test, and describe the test being executed
Set up test data using entity builders and variables
Test and verify results using assert statements
Include annotations (optional)

GUnit Testing - Test annotations are

strings that begin with @ and provide metadata about a Gosu element

Example:
uses gw.xml.ws.annotation.WsiWebService

@WsiWebService()

GUnit Testing - There are two types of test annotations

Server runtime annotations appear before the class definition and indicate how the test
interacts with the Guidewire server
Environmental annotations provide additional test functionality and override default system behavior

GUnit Testing - For code usability you should create

Test helper classes or functions

GUnit Testing - When executing a GUnit test, do so by

Package or Class

GUnit Testing - 4 characteristics of effective unit tests are

Readable - speeds up developer productivity
Accurate - predictable and repeatable
Fast - long-running tests slow development and are abandoned
Independent - can be reliably run in isolation from other tests to identify root cause of a problem

Guidewire Profiler is used to

Investigate performance problems in the production environment
Help find and diagnose problems with database queries, rules, and other Gosu code
Detect problems early by developers

Guidewire Profiler
Web profiler can

Be used for core product user interface performance analysis
Capture current user session in which web profiler enabled
Capture one set of results from receipt of a request through sending response while enabled
Save the web profile in user session (gone when user logs out)
Track where time is spent on server:
Guidewire application code
Response time of calls to database, external services, and so on

Guidewire Profiler
Web profiler cannot

Track Browser time, Network latency or Consumed web services

Guidewire Profiler
Entry-point profiler is used for integration-related performance analysis on

Batch processes
Work queues
Message destinations
REST operations
Web services
Startableplugins

Guidewire Profiler
Entry-point profiler captures

All runs of targeted components across all nodes
Displays separate results for each call/run on each node
Saves results in database

Guidewire Profiler is accessed 2 ways

Navigate to Server Tools (Alt+Shift+T), select Profiler from left pane
Popup from an application screen (Alt+Shift+P)

Guidewire Profiler
Before capturing a profile you must first do these 2 things

Clear the application cache to force queries to go to the database
Enable stack traces to show the widget or code where queries originate (impossible to pinpoint root causes otherwise)

Guidewire Profiler - Web Profile terms

Frame is single invocation of a profiled section of code
Stack is single server round trip that includes multiple frames
Profile is a single Profiler session that includes multiple stacks

Guidewire Profiler - Web Profile Analysis terms

Offset - chronological order of stackso Elapsed Time - execution time
Own Time - time that is unaccounted for, indicates the need for code tags
Show Queries - shows query aggregated view (default)
Find Frames - used to find frames based on text search
Query Details - SQL, Raw SQL, Basic, Stack Trace, Filtered Stack Trace, PCF Stack Trace
PCF Stack Trace - shows PCF widgets related to the SQL

Guidewire Profiler - Web Profile Analysis Guidelines

Limit each Profile to a narrow focus of interactions
Look beyond timings (the H2 database is fast and not always reflective of a production environment)
Focus on anti-patterns, poorly written, or multiple execution of queries
Test thoroughly using a representative data set to simulate scaling

Guidewire Profiler - Entry Point Profiles and Profile Tags
Profiling custom Gosu code requires these two things

Creating custom profiler tags
Adding the tags to the custom code

Guidewire Profiler - Entry Point Profiles and Profile Tags
Profiler Tags

Are defined in a separate class as public static final variables
Improve the ability to analyze performance issues

Guidewire Profiler - Entry Point Profiles and Profile Tags
Use the Profiler.push("profiler_tag") to

push a frame onto the stack to begin profiling

Guidewire Profiler - Entry Point Profiles and Profile Tags
Use the Profiler.pop(some_frame) to

pop a frame off the stack to end profiling

Source Code Control Key Concepts
Git:

Is a distributed version control system (DVCS)
Stores links to previous versions of unchanged files
Provides each developer with a full copy of the entire history of the project

Source Code Control Key Concepts
Git:

Most operations in Git are performed locally, supporting offline use

Source Code Control Key Concepts
Git:

Commits represent a complete snapshot of all the files in a project

Source Code Control Key Concepts
Branches in Git:

Are floating pointers to given stream of commits
Are inexpensive to create, so they are created all the time

Source Code Control Key Concepts
Merge in Git:

A merge integrates changes between branches -
Merge is a non-destructive operation that does not alter existing commits
Adds new commit to branch history
Use on shared branches (master, develop, release)

Source Code Control Key Concepts
Rebase in Git:

A rebase integrates changes between branches -
Creates new commits for each commit in your branch up to common ancestor of branch you are rebasing into
Rewrites history of your branch up to common ancestor
Use only on branches that are not shared (user story, defect)

Source Code Control Key Concepts
Bitbucket Server:

Is used as the remote code repository for Git
Facilitates code reviews by means of pull requests
Supports various Git development workflows
Can automatically propagate merge changes from earlier to later branches

Source Code Control Key Concepts
User story development with Git - Clone, Checkout, Stage, Commit, Push:

Clone remote repository to duplicate it on your local repository (Fetch to retrieve latest changes to existing local repository)
Checkout the files in your working directory to create a local branch off develop
Stage changes locally - use task-level commits as work is completed
▪ Git status command displays both staged and unstaged changes
▪ Git add command to add files to commit to staging area
Commit changes added to staging area to create a new snapshot of the project (stores modified and added files and a point to previous version of unmodified files)
Push user story branch back to origin (the remote repository)

Source Code Control Key Concepts
Branching Strategy - Branch: Production

Description: Contains code currently in production
Naming convention: master
Created: Start of new implementation
Deleted: n/a

Source Code Control Key Concepts
Branching Strategy - Branch: Product Release

Description: Contains changes for new Guidewire product versions
Naming convention: gw-releases
Created: Off master at beginning of project
Deleted: n/a

Source Code Control Key Concepts
Branching Strategy - Branch: Mainline

Description: Contains code across all releases
Naming convention: develop
Created: At beginning of project
Deleted:

Source Code Control Key Concepts
Branching Strategy - Branch: User Story

Description: Create off develop to deliver a user story
Naming convention: user/{user_id}/{US_id}
Created: When development begins
Deleted: When story accepted

Source Code Control Key Concepts
Branching Strategy - Branch: Defect

Description: Create off develop or a release branch for changes to address a defect
Naming convention: user/{user_id}/{DE_id}
Created: When work starts on defect
Deleted: When defect tested and closed

Source Code Control Key Concepts
Branching Strategy - Branch: Release

Description: Support parallel development, used to stabilize current release
Naming convention: release/r-{release number}
Created: When feature complete or at start of stabilization
Deleted:

Source Code Control Key Concepts
Branching Strategy - Branch: Phased Release

Description: Used for multi-phase releases
Naming convention: release/r-0-{phase_number}
Created: Off release branch for parallel development
Deleted:

Source Code Control Key Concepts
Branching Strategy - Branch: Hotfix

Description: Critical system error requiring emergency fix to production code
Naming convention: hotfix/identifier
Created: Off master and merged back to master
Deleted:

Source Code Control Key Concepts
Branching best practices

Use version control repositories to track software changes
Define a mainline branch for the latest project code
Create user story and defect branches to isolate changes
Break stories into development tasks to support task-level merges
Integrate changes on user story and defect branches frequently
Verify changes on user story and defect branches before merging
Create release branches to stabilize release features
Integrate changes on release branches into mainline immediately
Use automated builds to verify health of mainline and release branches
Use tools to support branching strategy