Given the following code sample: gw.transaction.Transaction.runWithNewBundle(\newBundle - > { var targetCo = gw.api.database.Query.make(ABCompany) targetCo.compare(ABCompany#Name, Equals, " Acme Brick Co. " ) var company = targetCo.select().AtMostOneRow company.Notes = " some value " }, " su " ) What two items should be added or changed to follow best practices? (Select two)
Correct Answer: A,C
This scenario highlights critical aspects of Bundle Management and transaction handling in Guidewire. The first and most significant issue is the modification of the company entity. In Guidewire, entities retrieved via a Query are typically " read-only " in their initial state. To modify an existing entity within a transaction, it must be explicitly associated with the current bundle. The instruction company = newBundle.add(company) clones the entity into the newBundle, making it editable. Without this step, attempting to set company.Notes would result in a runtime exception because the object is not " in the bundle. " Secondly, although the snippet shows " su " , the best practice for runWithNewBundle is to always ensure a valid, non-null user is passed to provide the necessary security context for the transaction. In many development scenarios, hardcoding " su " (Super User) is considered a placeholder, and production-ready code should dynamically resolve the appropriate user or ensure the execution context is valid. Regarding the other options: Option B is incorrect because runWithNewBundle automatically handles the commit() operation at the end of the code block; manually calling it is redundant and can cause errors. Option E is a technical misunderstanding of the API, as the Query object (targetCo) is a tool used to find data and is never " added " to a database bundle. By following the pattern of adding the entity to the bundle and ensuring proper user context, the developer adheres to the core principles of Gosu Bundle Management and data integrity.
Question 27
Which logging statement follows best practice?
Correct Answer: D
In Guidewire InsuranceSuite, logging is a critical tool for production support, but it must be implemented with strict attention to performance and data privacy. Option D represents the gold standard for performance- conscious logging in Gosu. When a developer needs to log a message that involves a " really expensive operation " (such as a complex string concatenation, a database lookup, or a heavy calculation), they should always wrap the logging call in an if statement that checks if that specific log level is enabled. Without this check, the Gosu engine would execute someReallyExpensiveOperation() to construct the string argument even if the logging level is set to " Info " and the " Debug " message is ultimately discarded. This can lead to significant, unnecessary CPU overhead in production environments. Furthermore, other options violate key architectural principles. Option B is a significant security risk as it logs Personally Identifiable Information (PII) like address lines and cities; Guidewire Cloud standards strictly forbid logging PII to ensure compliance with privacy regulations like GDPR and CCPA. Option C contains a logical mismatch where the developer checks for InfoEnabled but attempts to log at a debug level. Option A is suboptimal because it passes e.Message as a string rather than passing the exception object itself, which prevents the logger from capturing the full stack trace. By following the pattern in Option D, developers ensure the application remains performant while providing necessary diagnostic data only when explicitly requested through configuration.
Question 28
Which two performance issues of Guidewire core products can be analyzed using the Guidewire Profiler? (Select two)
Correct Answer: A,B
The Guidewire Profiler is a diagnostic tool designed to help developers identify and resolve performance bottlenecks within the application. It captures detailed " stacks " of execution, showing exactly how much time is spent in Gosu logic, PCF rendering, and database queries. According to the System Health & Quality training, the Profiler is primarily triggered through specific entry points. The User Interface (Option A) is the most common entry point; by enabling the profiler for a specific web session, a developer can analyze the performance of individual PCF pages, identifying slow-loading widgets or inefficient page queries. Batch Processes (Option B) are the second critical entry point. Since batch jobs (like the Billing/Claims renewal cycles or escalation tasks) often process massive amounts of data, profiling them allows developers to see where the job is lagging-whether it is in the " find " logic or the " execution " logic. Options C and D are incorrect because the Profiler does not directly analyze the Database Index or the Data Warehouse as standalone entities. While the Profiler can show that a query is slow, determining why (such as a missing index) requires external database management tools or Guidewire's Database Health tools. Similarly, Client Reflection (Option E) is a UI behavior that occurs in the browser, whereas the Profiler tracks server-side execution. Mastering the use of the Profiler for UI and Batch processes is a fundamental skill for maintaining high system quality in production.
Question 29
There is a requirement for an additional filter on Desktop Activities. The filter requires a complex query. Which option will meet the requirement and follow best practices?
Correct Answer: C
In Guidewire InsuranceSuite, implementing filters on high-volume pages like Desktop Activities requires a deep understanding of performance and the Gosu Query API. When a business requirement involves a " complex query " -typically meaning logic that spans across multiple related entities or involves conditional logic that cannot be expressed in a simple ToolbarFilterOption-the best practice is to encapsulate that logic within a separate Gosu function. Using a function that utilizes a subselect clause is a preferred architectural pattern for complex filtering. A subselect allows the database engine to perform the filtering logic entirely at the SQL level (e.g., using an EXISTS or IN clause) without pulling large amounts of data into the application server ' s memory. This is significantly more efficient than retrieving a list of objects and then filtering them in Gosu (as suggested in Option A or B). In the context of PCF Configuration, the filter property of a ToolbarFilterOption or a Filter widget can call this function, which returns a Query object. By returning a Query instead of a list of results, the UI component can further optimize the database call with paging and sorting logic. Option B, which suggests using for loops and if statements, is a direct violation of performance standards as it would result in " N+1 " query problems and excessive memory consumption on the application tier. Therefore, leveraging the power of the Query API with subselects ensures that the application remains responsive even as the volume of activities grows.
Question 30
The following screenshot displays a segment of the menu items in the sidebar on a Guidewire application: [Financials, Notes, Documents, Plan of Action, Services, Litigation, History]. The business analysts have uncovered a requirement that the Documents, History, Litigation, and Notes pages should be grouped under a single heading, to be called Legal Records. What is the best practice for accomplishing this?
Correct Answer: B
In the Guidewire InsuranceSuite UI architecture, the organization of navigation elements is governed by the hierarchy of PCF Locations. A location represents a destination in the application, such as a Page, a Worksheet, or a Wizard. When requirements call for grouping multiple related pages into a logical, hierarchical structure within the sidebar or a tab set, the standard architectural component used is the Location Group. A Location Group acts as a container for other locations (Pages, Forwards, or even nested Location Groups). According to PCF Architecture best practices, creating a Location Group named " Legal Records " and nesting the Documents, History, Litigation, and Notes pages within it allows the UI engine to render them as sub-items under a single, expandable heading. This maintains a clean and organized sidebar, which is critical for usability as the complexity of an application grows. Once the Location Group is defined and added to the Sidebar PCF, the individual page references are removed from the top-level sidebar configuration to prevent redundancy. In contrast, Option A is incorrect because a " Screen " is a container for UI widgets (like DetailViews and ListViews) within a page, not a navigation location itself. Option C refers to user preferences, which do not change the underlying application configuration or satisfy structural business requirements. Option D describes a manual styling approach that does not leverage the built-in navigation framework; using indents and labels manually is not upgrade-safe and fails to provide the true modal navigation behavior (such as showing the group as " active " when any child page is selected) provided by a proper Location Group. Therefore, using a Location Group is the only verified best practice for grouping sidebar navigation items.
