Template Gen Config Files

When you perform Cloud Retrofit with APD App, you must ensure that the configuration files are set correctly in order for the lines to be generated successfully.

The following are examples of configurations you might need to add to a template gen config file because the information can't automatically be inferred from the data model:

  • Define entities to treat as coverables in the APD model in cases where the entity doesn't already implement the Coverable interface, but has child coverables or exposures
  • Define entities to treat as exposures in the APD model
  • Specify which columns correspond to auto-number sequences, and the auto-number columns themselves
  • Identify fields as splittable

Examples of defaults you might want to change include:

  • Mark fields as ignored that you don't want to appear in the APD model (such as internally-managed values)
  • Ignore some subtypes in cases where a root type is shared across LOBs
  • Override field names in cases where the name is illegal in APD (such as "Type" or "Use") or you want a clearer name in the APD model (for example, the name contains cryptic abbreviations).

File names and locations

Template gen config files are located in the modules\configuration\config\apd\model\generate\json folder, and are typically named using the following format:

template_gen_config.<lob-prefix>.yaml

The lob-prefix is the code for the line that is found in the InstalledPolicyLine typelist, lowercased. For example, the template config file for PersonalAuto would be named template_gen_config.pa.yaml.

Each template gen config file can have up to three top-level properties: lineCode, languages, and types.

The languages property

This property specifies an array of language codes to include languages for, from the LanguageType typelist. By default, all languages configured in the LanguageType typelist are included, with the exception of "EDG" languages. Therefore, you need to specify this property only in one of the following two scenarios:

  • You want to exclude languages that exist in LanguageType that haven't actually been localized.
  • You want to include the EDG languages.

Example

languages: 
  - en_US
  - ja
  - fr_CA

The lineCode property

This property is the only required property in the YAML file. It specifies the LOB that the configuration applies to. This value can be one of the following:

  • All: Indicates that the template gen config file contains a cross-line configuration.
  • <code-identifier>: The PolicyLinePattern code identifier of the LOB.

This example is for configurations that apply to multiple lines:

lineCode: All

Here is an example for a template config file that applies to the PersonalAutoLine:

lineCode: PersonalAutoLine

Note that if an LOB name is overridden in the codegen config file, the lineCode is the override name. For example, the preceding LOB could have an entry in the codegen config file as follows:

PALine:
 nameOverride: PersonalAutoLine

The types property

The types property contains a map of type configuration. The keys can be concrete type names, supertype names, or interface/delegate names. The following properties can be applied to a type under the types property.

autoNumberColumn

For entities that are auto-numbered, this field specifies the auto-number column. Specifying a value will cause the entity to be marked as auto-numbered in the APD model. The auto-number column itself will not appear in the APD model (its existence is implied by the auto-number flag, so it's not explicitly modeled), and the associated schema property will be read-only in generated APIs. If no value is specified, codegen assumes a value of "SequenceNumber."

Example

types:
 PersonalVehicle:
   autoNumberColumn: VehicleNumber

fields

A map of field configurations for this type. The keys in the object should correspond to the property names on the associated type. For more information on field-level configurations, see The types property fields below.

handling

Use this property for entities that do not implement a coverable or modifiable. Possible values are coverable, exposure, or location.

  • coverable: Treat this entity as a Coverable in the APD model. Use this handling value for entities with children that need to be included in the APD model but that aren't themselves Coverables.
  • exposure: Treat this entity as an Exposure in the APD model. Use this handling value for leaf entities that have no children and aren't Coverables.
  • location: Treat this entity as a Location-Based Coverable in the APD model.

If handling is not specified, default logic will be used to try to automatically determine how to handle the entity. The following logic will be used:

  • Entities that implement the Coverable delegate will be treated as coverables.
  • Entities that subtype the AddlInterestDetail entity will be treated as exposures.
  • Entities that implement the LineSpecificLocation delegate will be treated as locations.

If none of the preceding can be determined, handling must be specified for the type. Entities with no configured handling, and that aren't automatically detected as a coverable, exposure, or location-based coverable, will not be included in the resulting APD template.

Example

lineCode: PersonalAutoLine
types:
 VehicleDriver:
   handling: exposure

ignored

There are cases where you want to exclude an entity from the APD model. For example, you might want to exclude some subtypes from consideration when a supertype is shared across LOBs and only some subtypes apply to some LOBs. To exclude an entity, set ignored to true.

If a type is marked as ignored then:

  • Child array and one-to-one properties that are exactly of the ignored type will be ignored when determining which child properties are Coverables or Exposures.
  • Unhandled one-to-one or array properties of exactly the ignored type will not be reported as unknown properties.
  • Any subtypes of exactly the ignored type will be excluded when flatting a coverable or exposure property into its subtypes.

The most common use cases for ignoring types are the following:

  • You want to suppress warnings about unhandled array or one-to-one properties, in cases where the type really ought to be excluded entirely.
  • You want to exclude specific subtypes of a base Coverable or Exposure type.

Example

lineCode: WorkersCompLine
types:
 WCFedCoveredEmployee:
   ignored: true

parentAutoNumberSequenceColumn

When an entity is auto-numbered, a foreign key to AutoNumberSequence is automatically added to the parent of that entity. A given entity can have multiple auto-numbered children, so it needs to know which foreign keys go with which children. The parentAutoNumberSequenceColumn property identifies the column on the entity parent that contains that key.

In the following example, for the PersonalVehicle entity this is set to PersonalVehicleAutoNumberSeq, which is the name of the foreign key property on PersonalAutoLine that is used to auto-number vehicles.

Example

lineCode: PersonalAutoLine
types:
 PersonalVehicle:
   autoNumberColumn: VehicleNumber
   parentAutoNumberSequenceColumn: PersonalVehicleAutoNumberSeq

typeName

Use this property to override the type name inferred for a coverable or exposure.

By default, if the entity name starts with the LOB prefix, the type name used in the APD model is the name of the entity without the prefix. If the entity does not start with the LOB prefix, the entire entity name is used. This property can be used to override the name in the APD model.

Example

lineCode: PersonalAutoLine
types:
 VehicleDriver:
   typeName: Driver

other type fields

If you use the default configuration for JSON template generation for Businessowners, Commercial Property, and Workers' Compensation and are converting these LOBs into Guidewire Cloud, then you must modify your existing codegen configuration file. You must add the other type APD field configurations so that you can generate the corresponding schema/mapper/updater properties with the correct settings. After you make the changes shown below, you must run the API codegen again.

When converting an OOTB product to APD, there are elements that APD cannot support, such as class code and risk class. In these cases, the output JSON template for APD conversion generates fields of type other. Fields of type other are displayed in the APD product model, but are not used in APD.

If the OOTB product already supports other field types, when generating or re-generating LOB-specific endpoints for the lines/coverables with these fields, the correct codegen configuration is required so that the code can handle these fields and produce schema/mapper/updater JSON files.

Fields of type other cannot be added using APD.

bop_codegen_config_ext-1.0.yaml
types:
  BOPBuilding:
    fields:
      ClassCode:
        customType: ClassCode
  ...
...
cp_codegen_config_ext-1.0.yaml
types:
  CPBuilding:
    fields:
      ClassCode:
        customType: ClassCode
        updaterHandling:
          valueTypeResolver: gw.rest.ext.pc.policyperiod.cp.v1.building.CPClassCodeJsonValueResolver
  ...
...
wc_codegen_config_ext-1.0.yaml
types:
  WCEmployee:
    fields:
      ClassCode:
        createOnly: true
        customType: ClassCode
        requiredForCreate: true
  WCLine:
    fields:
      GoverningClass:
        customType: ClassCode
        readOnly: true
  WCWaiverOfSubro:
    fields:
      ClassCode:
        customType: ClassCode
  ...
...

The types property fields

Possible values for field properties are fieldName, ignored and split.

fieldName

Use this property to override the field name in the APD model.

By default the field name is the entity property name. The primary reason for overriding the field name is for cases where the name is an illegal identifier in APD. For example, you might need to change a field named Use to VehicleUse or Type to EmployeeType. You can also use this property in cases where you want to change a cryptically-named property to something more human readable.

Example

WCWaiverOfSubro:
  handling: exposure
  fields:
    Type:
      fieldName: WaiverType

ignored

Set ignored to true to exclude a field from the APD model in the following cases:
  • The field is an implementation detail or internal bookkeeping, and does not represent a meaningful business value.
  • The field represents something that cannot be modeled in APD, for example an effective-dated foreign key to something other than PolicyLocation or PolicyContactRole.
If a field is not modeled in APD, it cannot be managed in APD. Furthermore:
  • When you generate code, the field is untouched in the eti file as only the pieces managed by APD are updated.
  • You must manually add the field to Cloud APIs.

Example

lineCode: BOPLine
types:
  BusinessOwnersLine:
    fields:
      ViewBundledCoverages:
        ignored: true

split

Setting split to true will mark a field as SplitByRatingPeriods in the generated template. This value cannot be inferred automatically, so you must set it explicitly for any splittable fields, such as fields on Workers Comp employees or General Liability exposures.

Example

lineCode: GLLine
types:
  GLExposure:
    fields:
      AuditedBasis:
        split: true