Codegen config file syntax

Codegen config files can have up to two top-level properties: a types property and a wizardStepIds property. All of the information related to LOB-specific endpoints is under the types property.

The types property

The visualized version of a product contains a set of APD types. In this context, an APD type is a line (such as PALine), a coverable (such as PAVehicle), or some other type of object that stores information relevant to the policy (such as PADriver).

Codegen config files can have a top-level types property followed by one or more APD types. For example, the base configuration codegen config file for Personal Auto includes the following:

types:
  PADriver:
    ...
  PALine:
    ...
  PAPolicyDriverMVR:
    ...
  PAVehicle:
    ...

For each type, and for fields in the type, you can specify one or more overrides.

Overrides at the type level

The following properties can be listed after a type under the types property.

autonumber

For collection types, this specifies the field to use when sorting members of the collection. This overrides the collection's default sorting, if any.

Syntax

autonumber: <fieldName>

Examples from a Personal Auto codegen config file

For example, in the base configuration Personal Auto product, every PAVehicle on a given policy is assigned a sequential integer value in the VehicleNumber field. When a collection of PAVehicles is retrieved, the collection ought to be sorted based on these sequential integers. To specify this, the codegen config file contains the following:

types:
  PAVehicle:
    autonumber: VehicleNumber

canDelete, canPatch, canPost, and canSplit

By default, PolicyCenter creates endpoints that let callers DELETE, PATCH, and POST instances of each type. Where relevant, callers can also split instances of the type.

The following properties disable the DELETE method, the PATCH method, the POST method, and/or the POST /split business action endpoint for this type. You can specify any or all of these in any combination.

Syntax

canDelete: false
canPatch: false
canPost: false
canSplit: false

Examples from a Workers' Compensation codegen config file

types:
  WCEmployee:
    canSplit: false
  WCJurisdiction:
    canDelete: false
    canPatch: false
    canPost: false

identifier

In most cases, a type's id field maps to the data model entity's PublicID field. In the base configuration, the values of these take the form of "pc:<alphanumeric-string>", such as "pc:Sp2FxL1061-Q_W8Bvtkj5".

For some types, the id value comes from a field other than PublicID. For example, in Commercial Auto, IDs for the CABAJurisdiction type come from the State field. Instances of this type do not have ID values that are PublicID values, such as "pc:Sp2FxL1061-Q_W8Bvtkj5". Rather, their ID values are codes from the State typelist, such as "CA", "NY", or "WY".

In a codegen config file, you can use the identifier property to specify a data model entity field other than PublicID that the id property must map to.

Syntax

identifier: <fieldName>

Examples from a Commercial Auto codegen config file

types:
  CABAJurisdiction:
    identifier: State

nameOverride

By default, the name of a type is mapped to the same name in the installed product. The nameOverride property specifies a different name in the installed product to map the visualized product's type to. The primary use cases for nameOverride are the following:

PolicyLine entities that do not follow the <LinePrefix>Line naming convention expected by APD.
Coverable or exposure entities that don’t start with the exact line prefix. For example, the PersonalVehicle entity in the base configuration PersonalAuto product does not start with PA (see example below).
Coverable or exposure entities that have names that aren’t legal in APD. The most common reason for this is names that are too long.

Syntax

nameOverride: <installedProductTypeName>

Examples from a Personal Auto codegen config file

For example, in the base configuration, the APD type PALine corresponds to the installed product's PersonalAutoLine. To resolve this mismatch, the codegen config file contains the following:

types:
  PALine:
    nameOverride: PersonalAutoLine

You can also specify name overrides at the field level. For more information, see Overrides at the fields level.

oneToOne

A one-to-one relationship is a relationship that two data model entities have. One acts as the parent, and the other as the child. For the parent, each instance may have an association with up to one instance of the child entity. For the child, each instance must be associated with exactly one parent.

Every APD type maps to a data model entity. In some cases, an APD type maps to an entity that is the child in a one-to-one relationship. In the codegen config file, you can specify that an APD type is a one-to-one child by using the oneToOne property. This must be set to the name of the property on the parent data model entity that points to the data model child.

Syntax

oneToOne: <propertyOnDataModelParentThatPointsToDataModelChild>

Note that the codegen config process considers the "parent data model entity" to be the data model entity that is referenced by the parent APD type of the given APD type. For example, the IMSignPart APD type has a parent named IMLine. The IMLine APD type maps to the InlandMarineLine data model entity. Therefore, if you specify a oneToOne property on the IMSignPart APD type, the codegen config process looks for the property referenced by the oneToOne on the InlandMarineLine data model entity.

Examples from an Inland Marine codegen config file

For example, for the Inland Marine product, the InlandMarineLine and IMSignPart data model entities have a one-to-one relationship. Every InlandMarineLine instance can have at most one IMSignPart instance, and every IMSignPart instance must be attached to an InlandMarineLine instance.

To define this relationship for the purposes of codegen config, you can add the oneToOne property to the child APD type (IMSignPart). It must identify the name of the property on the parent data model entity (InlandMarineLine) that points to the data model child. In this case, the name of the property is also IMSignPart. The codegen config file looks like this:

type:
  IMSignPart:
    oneToOne: IMSignPart

toCreateAndAdd

By default, whenever an instance of a type is added to a line, PolicyCenter simply creates a new instance of the type and adds it to the line. No additional properties are set on the instance and no additional actions are taken. However, for some types, additional actions may be required. Typically, these actions are executed by a method declared in the <LineName>Enhancement Gosu enhancement.

For example, when a vehicle is added to a Personal Auto line, the following additional actions are needed:

The vehicle's type must default to Passenger/Light Truck.
The garage location must default to the first available PolicyLocation.
Coverages, conditions, and exclusions for the vehicle must be created.
The vehicle must be given a vehicle number based on the number of other vehicles on the line.

These actions are executed by a createAndAddVehicle method on the PersonalAutoLineEnhancement Gosu enhancement.

When the codegen config process generates LOB-specific endpoints, the default behavior for each type is to simply create a new instance of the type and add it to the line. If there is a special enhancement method that you want to use instead, you can specify this method using the toCreateAndAdd property in the codegen config file.

Syntax

toCreateAndAdd: <MethodNameFromTheGosuLineEnhancement>

Examples from a Personal Auto codegen config file

types:
  PAVehicle:
    toCreateAndAdd: createAndAddVehicle

toRemove

By default, whenever an instance of a type is removed from a line, PolicyCenter simply removes the instance from the line. No additional actions are taken. However, for some types, additional actions may be required. Typically, these actions are executed by a method declared on the <LineName>Enhancement Gosu enhancement.

For example, when a vehicle is removed from a Personal Auto line, the following additional actions are needed:

The remaining vehicles must be renumbered to prevent any gaps in vehicle numbering.

These actions are executed by a removeVehicle method on the PersonalAutoLineEnhancement Gosu enhancement.

When the codegen config process generates LOB-specific endpoints, the default behavior for each type is to simply remove the instance. If there is a special enhancement method that you want to use instead, you can specify this method using the toRemove property in the codegen config file.

Syntax

toRemove: <MethodNameFromTheGosuLineEnhancement>

Examples from a Personal Auto codegen config file

types:
  PAVehicle:
    toRemove: removeVehicle

resourceName

This overrides the default resource name. Use this override when the resource name differs from the nameOverride name.

Syntax

resourceName: <resourceName>

Examples from a Workers' Compensation codegen config file

types:
  WCEmployee:
    nameOverride: WCCoveredEmployeeBase
    resourceName: WCCoveredEmployee

Overrides at the fields level

The following properties can be listed after the fields property for a given type.

createOnly

By default, the value for a field can be specified in both POSTs and PATCHes. To restrict a field to being specified in POSTs only, you can set the field's createOnly property to true.

Syntax

createOnly: true

Examples from a Workers' Compensation codegen config file

In a Workers' Compensation product, the WCEmployee type has two fields that can be specified when the WCEmployee is created, but not when it is PATCHed. These fields are Location and SpecialCov. To enforce this, the codegen config file contains the following.

types:
  WCEmployee:
    fields:
      Location:
        createOnly: true
      SpecialCov:
        createOnly: true

getterProperty

Defines the getter method in the mapper if it is different from the default property getter for the field.

Syntax

getterProperty: <getterProperty>

Example from a test codegen config file

types: 
  SampleTestCoverable: 
    fields: 
      RiskClassResourceField: 
        customType: Resource 
        mapperHandling: 
          getterProperty: RestV1_RiskClassResourceField

ignored

This prevents the field from being exposed to Cloud API.

Syntax

ignored: true

Examples from a Workers' Compensation codegen config file

types:
  WCWaiverOfSubro:
    fields:
      IfAnyExposure:
        ignored: true
      NumEmployees:
        ignored: true

mapperHandling

Provides parent level settings for mapper handling.

Example from a test codegen config file

types: 
  SampleTestCoverable: 
    fields: 
      RiskClassResourceField: 
        customType: Resource 
        mapperHandling: 
          getterProperty: RestV1_RiskClassResourceField

nameOverride

Use nameOverride when the name in the APD model doesn’t match the name in the entity. This can happen when the entity’s field name isn’t allowed in APD so it had to be changed in the APD model. Field names that aren't allowed in APD include names that are too long, start with a lowercase letter, or are reserved words in APD such as “Type” or “Use.” Another common use case is to map an APD model field name that was changed or truncated back to the field name on the installed product

Syntax

nameOverride: <installedProductFieldName>

Examples from a Personal Auto codegen config file

For example, in the base configuration, the PAVehicle type's Year field corresponds to the installed product PersonalVehicle coverable's ModelYear field. What this example is doing is mapping the APD field name back to the entity model.

types:
  PAVehicle:
    fields:
      Year:
        nameOverride: ModelYear

You can use nameOverride to resolve naming conflicts. For example, if an LOB has a field and an exposure with the same name, this can cause unexpected results. Use nameOverride to override the schema field name to resolve these types of conflicts.

You can also specify name overrides at the type level. For more information, see Overrides at the type level.

The nameOverride property should be used only for Cloud Retrofit. For APD Adoption, use schemaPropertyName.

nullable

This prevents the caller from specifying a null value for the field in a request object.

Syntax

nullable: false

Examples from a Workers' Compensation codegen config file

types:
  WCEmployee:
    fields:
      IfAnyExposure:
        nullable: false

readOnly

By default, the value for a field can be specified in POSTs and PATCHes. To prevent a field from being specified in either case, you can set the field's readOnly property to true.

Syntax

readOnly: true

Example from a test codegen config file

types: 
  SampleTestCoverable: 
    fields: 
      LineField: 
        # do not generate property in updater 
        readOnly: true

requiredForCreate

This overrides the default requiredForCreate value.

Setting this to true prevents the caller from omitting the value in a POST request.
Setting this to false allows the caller to omit the value in a POST request.

Syntax

requiredForCreate: <Boolean>

Examples from a Personal Auto codegen config file

types:
  PAVehicle:
    fields:
      GarageLocation:
        requiredForCreate: false

schemaHandling

This property provides a parent level for settings related to schema handling.

Example from a test codegen config file

types: 
  SampleTestCoverable: 
    fields: 
      RiskClassResourceField: 
        schemaHandling: 
          schemaPropertyName: anotherRiskClassResourceField

schemaPropertyName

Use schemaPropertyName in the following cases:

The field name conflicts with a graph property name generated for an array of child coverables and exposures. You need to rename the property to ensure the names are unique.
The field name conflicts with some other built-in property, such as the address properties automatically added to any location-based coverable.
You don’t like the name in the APD model and would prefer a different name in the schema (for example, because the APD name has constraints that schema names don’t, so maybe you want a longer name).

Syntax

schemaPropertyName: <propertyname>

Example from a test codegen config file

types: 
  SampleTestCoverable: 
    fields: 
      RiskClassResourceField: 
        schemaHandling: 
          schemaPropertyName: anotherRiskClassResourceField

setterProperty

Use this property for the setter method in the updater when it is different from the default property setter for the field.

Syntax

setterProperty: <propertyID>

Example from a test codegen config file

types: 
  SampleTestCoverable: 
    fields: 
      RiskClassResourceField: 
        updaterHandling: 
          setterProperty: RestV1_RiskClassResourceField

updaterHandling

The parent level settings for updater handling.

Example from a test codegen config file

types: 
  SampleTestCoverable: 
    fields: 
      RiskClassResourceField: 
        updaterHandling: 
          setterProperty: RestV1_RiskClassResourceField

Overrides at the fields level - APD adoption EA

Important: This functionality is available only to customers who have signed up for our Early Access (EA) program. Talk to your Guidewire representative to learn more about our eligibility criteria for EA programs. Note that EA capabilities may or may not become part of our future offerings.

The following properties can be listed after the fields property for a given type. The properties in this section are for use only with the APD "Other" field type.

create

A create expression for the updater.

Syntax

create: <create-expression>

Example from a test codegen config file

types: 
  SampleTestCoverable: 
    fields: 
      RiskClassRefField: 
        updaterHandling: 
          create: SampleTestCoverable.RestV1_DefaultRiskClass()

customType

As of this release, possible values are Resource and ClassCode.

When Resource is specified, the following default behavior occurs:

The schema will use only resourceType configs
The mapper will have a ResourceReference and try to evaluate the property as xxx.RestV1_AsEffDatedReference (if the other field is an EffDated entity), or xxx.RestV1_AsReference (if the other field is not an EffDated entity but it is a KeyableBean entity)

When ClassCode is specified, the following default behavior occurs (where XXX is the product line prefix, such as PA or WC):

An empty XXXClassCodeReference schema, mapper, and updater are created for the field.
A default XXXClassCodeJsonValueResolver is created in the updater. The resolver will attempt to resolve the class code by ID.
The default path for the resolver is gw.rest.core.pc.policyperiod.v1.XXXClassCodeJsonValueResolver. You can override this path using the valueTypeResolver property described below.

Syntax

customType: <customType>

Example from a test codegen config file

types: 
  SampleTestCoverable: 
    fields: 
      ClassCodeField: 
        customType: ClassCode 
      LineField: 
        customType: Resource

extensions

Additional settings defined for the x-gw-extensions schema property, such as filterable and sortable properties.

Example from a test codegen config file

types: 
  SampleTestCoverable: 
    fields: 
      RiskClassStringField: 
        schemaHandling: 
          extensions: 
            filterable: false 
            sortable: false

format

This defines the format settings for the field. This field needs to be overridden only in cases where the format is not supported in APD and you want to make the field a scalar type in the schema.

Syntax

format: "string"

Example from a test codegen config file

types: 
  SampleTestCoverable: 
    fields: 
      LineField: 
        format: date-time

mapperRef

Use this override when the mapper reference is different from the schemaDefinition.

Syntax

mapperRef: <mapperRef>

Example from a test codegen config file

IndustryCodeField: 
  schemaDefinition: ReferenceTableEntry
  mapperHandling: 
      mapperRef: IndustryCode

resourceType

Defines the resourceType settings for the field. This is applied when customType is set as Resource. If the customType is Resource and this field is not defined, the system will try to use the actual entity type as the resourceType.

Syntax

resourceType: <resourceType>

Example from a test codegen config file

types: 
  SampleTestCoverable: 
    fields: 
      RiskClassResourceField: 
        customType: Resource
        schemaHandling: 
          resourceType: RiskClass

schemaDefinition

For use when the field is a reference property. If the referenced schema is found in the core schema, no additional schema is created. If it's not found in the core schema, an empty schema will be generated so it can be extended with an extension file.

Syntax

schemaDefinition: <schemaDefinition>

Example from a test codegen config file

types: 
  SampleTestCoverable: 
    fields: 
      IndustryCodeField: 
        schemaDefinition: ReferenceTableEntry

type

The type settings for the field. This needs to be overridden only in cases where the field is not an APD supported format but you want to make it a scalar type in the schema.

Syntax

type: <datatype>

Example from a test codegen config file

types: 
  SampleTestCoverable: 
    fields: 
      RiskClassStringField: 
        schemaHandling: 
          type: string

updaterRef

Use this override when the updater reference is different from the schemaDefinition.

Syntax

updaterRef: <updater-reference>

Example from a test codegen config file

types: 
  SampleTestCoverable: 
    fields: 
      RiskClassRefField: 
        schemaDefinition: RiskClassReference 
        updaterHandling: 
          # using different updater from schemaDefinition 
          updaterRef: RiskClassReferenceForUpdater

valueTypeResolver

The full path of the JSON value resolver for the field if it is referencing another entity.

Syntax

valueTypeResolver: <full-path-to-resolver>

Example from a test codegen config file

types: 
  SampleTestCoverable: 
    fields: 
      RiskClassResourceField: 
        updaterHandling: 
          valueTypeResolver: gw.rest.core.pc.policyperiod.v1.location.RiskClassJsonValueResolver
          valueTypeResolverConfigs: 
            setById: true

valueTypeResolverConfigs

Available to provide additional optional configs for the JSON value resolver.

Example from a test codegen config file

types: 
  SampleTestCoverable: 
    fields: 
      RiskClassResourceField: 
        updaterHandling: 
          valueTypeResolver: gw.rest.core.pc.policyperiod.v1.location.RiskClassJsonValueResolver
          valueTypeResolverConfigs: 
            setById: true

The wizardStepIds override

A codegen config file can also have a wizardStepIds element. This element is used to support highlighting of fields in the PolicyCenter user interface for circumstances when the field’s value triggers a warning or error from the validation rules.

This element does not have an impact on the behavior of LOB-specific endpoints.

Example codegen config file

The following is the codegen config file in the base configuration for the Personal Auto product. It has multiple type-level and field-level overrides. There are additional examples for other products in the modules\configuration\config\integration\apis\installedlobs directory.

types:
  PADriver:
    nameOverride: VehicleDriver
    fields:
      PolicyDriver:
        createOnly: true
  PALine:
    nameOverride: PersonalAutoLine
  PAPolicyDriverMVR:
    nameOverride: PolicyDriverMVR
    # PolicyDriverMVRs are managed implicitly via requests to retrieve 
    #   an MVR on individual drivers and are read-only
    canDelete: false
    canPatch: false
    canPost: false
  PAVehicle:
    nameOverride: PersonalVehicle
    fields:
      GarageLocation:
        requiredForCreate: false
      Year:
        nameOverride: ModelYear
    autonumber: VehicleNumber
    toCreateAndAdd: createAndAddVehicle
    toRemove: removeVehicle
wizardStepIds: false