Special use cases

Controlling the level at which the endpoints are generated

Starting in Hakuba, there is an application configuration parameter named RestAPIsGeneratingByPolicyLine. It is a Boolean parameter that controls the level at which endpoints are generated.

• true - PolicyCenter generates endpoints at the line level.
  • Endpoints are prefixed by the line code.
• false - PolicyCenter generates endpoints at the product level.
  • Endpoints are prefixed at the product code.

The default for this parameter is true. However, when an insurer moves from a pre-Hakuba release to Hakuba (or later), this parameter is set to false to preserve the original product-prefix-style generation.

Guidewire recommends all insurers eventually set this parameter to true, as this setting supports multi-line products. Insurers may need to modify existing products to ensure they continue to behave as expected.

Products whose line prefix is identical to the product prefix

If you have a mono-line product whose line has a prefix that is identical to the product prefix, no additional work is needed. The new behavior will be extracting the prefix from a different location (the line instead of the product). But if the prefix itself is the same, the LOB-specific endpoints generated for the line will also be the same.

Products whose line prefix is not identical to the product prefix

If you have a mono-line product whose line has a prefix that is not identical to the product prefix, then you must take additional steps to move the product to the new line-prefix-style generation.

The following instructions use the following abbreviations:

• <productcode> = the product abbreviation, all in lowercase letters
• <linecode> = the line prefix, all in lowercase letters

To modify the product, execute the following steps in a development environment with the current product.

1. Set the RestAPIsGeneratingByPolicyLine application configuration parameter to true.
2. In config/integration:
   • Rename all of the files that contain the product code so that _<productcode>_ is changed to _<linecode>_.
   • Within all of the file, change any reference of _<productcode>_ to _<linecode>_.
3. In config/integration/apis/installedlobs:
   • Rename <productcode>_ext-1.0.yaml to <linecode>_ext-1.0.yaml,
4. In gsrc/gw/rest/ext/pc/job/<productcode>/v1:
   1. Change the name of the directory path so that it is gsrc/gw/rest/ext/pc/job/<linecode>/v1.
   2. Rename Job<product-abbreviation>ExtApiHandler.gs to Job<linecode>ExtApiHandler.gs.
5. In gsrc/gw/rest/ext/pc/policy/<productcode>/v1:
   1. Change the name of the directory path so that it is gsrc/gw/rest/ext/pc/policy/<linecode>/v1.
   2. Rename Policy<product-abbreviation>ExtApiHandler.gs to Policy<linecode>ExtApiHandler.gs.
6. Drop the PolicyCenter database.
7. Restart PolicyCenter
8. Regenerate the LOB-specific endpoints for the product.
   • For more information, see Generating LOB-specific endpoints.

You can then include the product along with the other updated resources as part of the regular update process.

Implementing the ComplexSchedulePlugin plugin

The ComplexSchedulePlugin plugin is a part of the base configuration as of the Garmisch release (2023.02.0). The manner in which this plugin is implemented varies based on the insurer's original version of PolicyCenter and the original version of the SBT.

Development starts on Garmisch (or later)

If the development of the product started on a Garmisch (or later) instance of PolicyCenter using a Garmisch (or later) instance of the SBT, then there is an implementation of the ComplexSchedulePlugin plugin included with the base configuration. No additional work is required.

Updating both a pre-Garmisch PolicyCenter and pre-Garmisch SBT to Garmisch (or later)

If the development of the product started on a pre-Garmisch instance of PolicyCenter using a pre-Garmisch instance of the SBT, and both PolicyCenter and the SBT are updated to Garmisch (or later), then no additional work is required. An implementation of the ComplexSchedulePlugin plugin will be added to PolicyCenter during the update process.

Updating a pre-Garmisch PolicyCenter to Garmisch (or later) while using a pre-Garmisch SBT

If the development of the product started on a pre-Garmisch instance of PolicyCenter using a pre-Garmisch instance of the SBT, and only PolicyCenter is updated to Garmisch (or later), then some additional work is required to make the pre-Garmisch SBT compatible with Garmisch PolicyCenter. This additional work consists of the following:

3. In the Garmisch (or later) SBT, find the file from the list below that matches the SBT you are implementing. Replace the pre-Garmisch version of this file in your SBT with the Garmisch (or later) version from the downloaded SBT.

Differences between "product designer" scheduled items and SBT scheduled items

Once there is a suitable plugin implementation, the endpoints for SBT scheduled items work almost entirely the same as scheduled items in Product Designer/Advanced Product Designer products. There are two differences with endpoints for scheduled items in SBT products.

• They have two new scheduled item property types: additionalInsured and option. These properties have corresponding value properties on the ScheduledItemProperty schema definition.
• They can have a set of child /coverage endpoints. This is because scheduled items in an SBT product can have coverages attached to them. When the ComplexSchedulePlugin plugin identifies that a given coverable has at least one coverage that has scheduled items with child coverages, it generates the child /coverage endpoints. For example, for an SBT product, there could be an endpoint such as .../buildings/{buildingId}/coverages/{coverageId}/scheduled-items/{scheduledItemId}/coverages/{scheduledItemCoverageId}.

Products that started development prior to Hakuba (2023.06.0)

The manner in which LOB-specific endpoints are generated changed in the Hakuba (2023.06.0) release. If you developed or installed any products on a release prior to Hakuba, there are additional considerations for the pre-Hakuba products. For more information, see Products whose line prefix is not identical to the product prefix..

LOB-endpoint generation is initiated at the product level, but it is executed at the line level

When you generate LOB-specific endpoints, you initiate the generation at the product level.

However, by default, PolicyCenter generates LOB-specific endpoints at the line level. When the endpoints are generated, the endpoints are prefixed using the line code. If you generate LOB-specific endpoints for a multi-line product, the endpoints for each line will have their own prefix.

Lines shared across products

Lines that are used by multiple products must have the same line code, such as ba for a business auto line. This ensures that the same set of endpoints are used by products that share a given line.

If a given line is used by multiple products and you make a change to that line, you only need to regenerate the endpoints for any one of the products using this line. For example, suppose you have an Inland Marine line that is used by an Inland Marine product and a Commercial Package product. After generating endpoints for both products, you make a change to the Inland Marine line. You then regenerate the endpoints for the Inland Marine product. You do not also need to regenerate the endpoints for the Commercial Package product. The Commercial Package product will automatically have access to the regenerated Inland Marine line endpoints.

If a single line of business is used by multiple products, then either all of those products must be in visualized mode or all of them must be in installed mode. You cannot have a single line of business used by two or more products where some are in visualized mode and some are in installed mode.

Cloud API does not require a mono-line product for every LOB

Cloud API supports the ability to generate LOB-specific endpoints for a line of business, even when that line is used only by multi-line products. For example, suppose you have a Commercial Property Line that is used only by a multi-line Commercial Package product. When you generate LOB-specific endpoints for the Commercial Package product, Cloud API generates endpoints for the Commercial Property Line, even though this line is used only by multi-line products.

Other services or environments may require that you create a mono-line product for every line. For example, Guidewire APD Service may require you to create a mono-line Commercial Property package for the Commercial Property Line before you can add that line to a multi-line Commercial Package product. But this requirement is not enforced by Cloud API. Cloud API can generate endpoints for the Commercial Property Line using only the Commercial Property package.

The RestAPIsGeneratingByPolicyLine config parameter

There is an application configuration parameter named RestAPIsGeneratingByPolicyLine. It is a Boolean parameter that controls the level at which endpoints are generated.

• true - PolicyCenter generates endpoints at the line level.
  • Endpoints are prefixed by the line code.
  • This is the default.
• false - PolicyCenter generates endpoints at the product level.
  • Endpoints are prefixed at the product code.

Guidewire recommends against setting this parameter to true unless you are working with one or more products whose LOB-specific endpoints were generated in an instance of PolicyCenter prior to the Hakuba release (2023.06.0). For more information, see Products whose line prefix is not identical to the product prefix.