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
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.
- 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