Guidewire Practice Exam 2024/2025 Questions with 100% complete verified solutions (study, Exams of Business Administration

Download Guidewire Practice Exam 2024/2025 Questions with 100% complete verified solutions (study and more Exams Business Administration in PDF only on Docsity!

Guidewire Practice Exam 2024/2025 Questions with

100% complete verified solutions (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 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 Verifying that denormalized search column values match their associated column values Verifying that there are consistent relationships between parent and child objects NOTE: Customers cannot create new application-specific checks Database Consistency Checks Potential consequences of database consistency check failures: Application performance may degrade Errors may be introduced into financial data Upgrade problems may be multiplied Archive/purge may fail Searches may return incorrect results Database Consistency Checks When to run database consistency checks: Frequently during development and testing to identify problems early Monthly in heavily used QA environments and on a recent copy of production in a lower environment Archiving Key Concepts Entities are included in the archive domain graph when: The Extractable delegate is implemented The entity has a foreign key relationship with an entity in the archive domain graph Archiving Key Concepts Entities added to the domain graph need a foreign key relationship with an entity inside the graph. The foreign key relationship must take one of these forms:

The foreign key can be from the new entity to the owner entity: ▪ Owner can have an array of the new entity ▪ Owner can have a one-to-one or edge foreign key to the new entity The foreign key can be from the owner entity to the new entity with the archivingOwner property in the foreign key set to Source Archiving Key Concepts During startup the application verifies that all domain graph requirements are met 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