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
).
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. Installed product values
are case-insensitive, but APD type values are case-sensitive, and the case must
match.
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.
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
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
nameOverride
This specifies that this field in the visualized product maps to the given field in the installed product. Installed product values are case-insensitive, but APD type values are case-sensitive, and the case must match.
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.
To resolve this mismatch, the codegen config file contains the following:
types:
PAVehicle:
fields:
Year:
nameOverride: ModelYear
You can also specify name overrides at the type level. For more information, see Overrides at the type level.
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
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
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
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