Download Guidewire Profiler and Source Code Control Concepts and more Exams Advanced Education in PDF only on Docsity!
GUIDEWIRE BEST PRACTICES EXAM STUDY
GUIDE COMPLETE EXAM UPDATE 2023
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
- 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
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)
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
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 - 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:
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 Source Code Control Key Concepts User Story Branch - verify changes before merging - Pull the latest changes from develop branch Run all automated unit tests for feature Run all executable specifications for feature (for behavior-driven development) Run critical automated tests against code on branch Conduct peer-review of changes Source Code Control Key Concepts Defect Branch - verify changes before merging - Pull the latest changes from release branch Run all automated unit tests for release Run all executable specifications for release (for behavior-driven development) Conduct peer-review of changes Ensure manual verification by quality analyst Source Code Control Key Concepts Verify changes after merging - Merge user story branch to develop, defect branch to release Perform automated build on destination branch Minimum steps for automated build scripts: ▪ Compile and generate deployment artifacts from tip of branch ▪ Run automated unit tests against tip of branch ▪ Run executable specifications against tip of branch (for behavior-driven development)
▪ Deploy artifacts to shared integration environment ▪ Run automated smoke tests on integration environment Mark build as failed for any error and notify team Fix failed builds immediately Database Design and Maintenance - Database schema validation detects when the data model and database schema are out of sync. Correct errors found by schema validation by creating a SQL script to remove orphaned columns or to perform other adjustments to the database. Guidewire advises that you contact Guidewire Support to either provide a script or review a script written by a DBA or developer to ensure correct resolution of the problem o REQUIRED for production databases o Strongly recommended for non-production databases Run schema validation during development to detect out-of-synch conditions between the data model & schema Run during product upgrades to identify problems with the database Database Consistency Checks - Database consistency checks verify the integrity of the data in the database Guidewire applications are responsible for ensuring database consistency Database consistency checks identify issues after they occur Database Consistency Checks Platform-level checks are generated from the data model and run against the database to ensure data consistency. Examples of these checks include: - Verifying that required columns on subtypes are populated Verifying that every value in a typekey column matches a value in the corresponding typelist Verifying that one-to-one relationships have at most one referring entity Database Consistency Checks - Application-specific checks Guidewire application developers provide hundreds of application-specific checks that are included with each product. A few examples of application-specific checks include - Verifying that a single address record is not shared between Contact records
Cloud Assurance: - Ensures the readiness of an implementation for Cloud deployment; includes Process, Standards, Expertise, Training and certification, and Assessments Applies to new Cloud implementations and upgrades to Guidewire cloud Continues after go-live and in production Sets foundation for product alignment and adherence to Guidewire standards Identifies issues that could impact performance Cloud Assurance Assessments (CAA): - Designed to maximize product alignment and minimize unnecessary customization Scheduled at regular intervals throughout implementation Build on prior assessments Evaluate product usage, solution design, and developed code for compliance against Guidewire Cloud Standards Issues are added to the Optimization Backlog and must be resolved before Cloud deployment Cloud Assurance - Optimization backlog: - Issues not compliant with standards Provides an approach to remediate the issue Prioritized with a deadline for resolution
