Additional post-schema configuration

Endpoints created through the REST endpoint generator typically require some configuration beyond just the schema, mapping, and updater files. This section lists the additional configuration tasks.

Additional work for the incident endpoints

The apiconfig file

For custom incidents, the REST endpoint generator sets the default sort to description. This matches the sort order for base configuration incidents. If this is appropriate, no further configuration is needed.

The Claim graph file

In the Claim graph:

The default sort order for custom incidents is by description and then by restID.
The default sort order for assessment content items is the return value of the OrderedContentItemLine method on Incident.

If this is appropriate, no further configuration is needed.

The generator also adds a <customIncident> property to the Claim graph in the claim graph schema extension file. However, unlike most properties added to the Claim graph, you do not need to configure the path attribute. The generator is able to set the attribute on its own.

Authorization files

The REST endpoint generator adds entries to the relevant role.yaml files and the resource access files for the incident and, if needed, the assessment content items. Each set must be configured as needed. For more information, see Configuring authorization for generated endpoints.

Cloud API also supports additional accessible fields filters. These filters are used for entities that store third-party information that should not be accessible to all types of callers. These filters restrict access to a limited subset of fields based on the caller's business relationship with the entity.

Incidents often store third-party data, and producers often access incidents but should not have access to any third-party data stored in any incident. Therefore, for custom incidents, the REST endpoint generator adds an additional accessible fields filter for the element resource to the producerCodes_ext-1.0.access.yaml file. However, it does not add any reference to the element resource type in the restricted.accessiblefields.yaml file, which is the file that defines the set of fields the caller can access. If you do not modify this configuration, ClaimCenter throws an error any time you attempt to access the custom incident type.

If you want to limit access to some of the custom incident's fields based on the caller's business relationship to each specific incident, then you must add the custom incident type to the restricted.accessiblefields.yaml file.
If there is no need to limit access to any of the custom incident's fields based on the caller's business relationship to each specific incident, then you must remove the additional accessible fields filter from the producerCodes_ext-1.0.access.yaml file.

For more information on configuring these files, see Resource access files: additional accessible fields filters.

Additional work for the risk unit endpoints

The verified element resource file

In this file, no delete method gets generated. This is because for verified policies, you cannot delete policy descendants.

Cloud API also assumes that a CanViewException method would always return null. Therefore, no CanViewException method is generated.

The REST endpoint generator also adds a finishCreate method. When the risk unit references a damageable, then this method is used to configure behaviors related to reserving ids and checksum scopes. For more information, see Adding one-to-ones.

The verified collection resource file

In this file, no createMinimalChildElement method gets generated. This is because you cannot create descendants on a verified policy.

Cloud API also assumes that a CanViewException method would always return null. Therefore, no CanViewException method is generated.

The unverified element resource file

In this file, no delete method gets generated. This is because, as of this release, Cloud API does not support deleting policy descendants for unverified policies.

Cloud API also assumes that a CanViewException, CanEditException, and CanDeleteException method would always return null. Therefore, none of these methods are generated.

Similar to the verified element resource file, the REST endpoint generator also adds a finishCreate method. When the risk unit references a damageable, then this method is used to configure behaviors related to reserving ids and checksum scopes. For more information, see Adding one-to-ones.

The unverified collection resource file

Cloud API also assumes that a CanViewException and CanCreateException method would always return null. Therefore, none of these methods are generated.

Configure the Policy getter

In this file, there is an addition Policy getter. This method must be modified so that it contains the path from the resource to the Policy entity.

For example, suppose that you create a custom risk unit named CustomRiskUnit_Ext. This entity is a subtype of RiskUnit, and therefore it inherits from the supertype a foreign key named Policy that points to the policy. When you generate endpoints for CustomRiskUnit_Ext, the UnverifiedCustomRiskUnitsExtResources.gs class has a Policy getter. It would need to be set to the following:

private property get Policy() : Policy {
  return (this.Parent.Element.Policy)
  }
}

Configure the createMinimalChildElement method, if necessary

Unverified collection resource files have a generated createMinimalChildElement method. For example:

override function createMinimalChildElement(attributes : DataAttributes) :
                                 CustomRiskUnit_Ext {
  var riskUnit = getBundle().newBeanInstance(CustomRiskUnit_Ext.TYPE.get())
                                 as CustomRiskUnit_Ext
  this.Policy.addToRiskUnitsAndAssignRUNumber(riskUnit)
  return riskUnit
}

If the risk unit is a direct child of Policy, no further configuration is needed.

If the risk unit is not a direct child of Policy, you must add code to identify the parent object that has the foreign key to Policy. For example, suppose CustomRiskUnit_Ext is a direct child of PolicyLocation, which in turn is a child of Policy. The endpoint to GET a custom risk unit looks like this:

GET /claims/claimId/policy/locations/{locationId}/custom-risk-units-ext

In this case, you would need to add the following bold line of code to the method:

override function createMinimalChildElement(attributes : DataAttributes) :
                                 CustomRiskUnit_Ext {
  var riskUnit = getBundle().newBeanInstance(CustomRiskUnit_Ext.TYPE.get())
                                 as CustomRiskUnit_Ext
  riskUnit.PolicyLocation = this.Parent.Element
  this.Policy.addToRiskUnitsAndAssignRUNumber(riskUnit)
  return riskUnit
}

The apiconfig file

The default sort for the verified and unverified collections is automatically set to RUNumber. If this is appropriate, no further configuration is needed.

The Claim graph file

The generator adds a <customRiskUnit> property to the Policy graph in the claim graph schema extension file. As is the case with most properties added to the Claim graph, the path attribute must be configured manually. For more information on configuring paths in integration graphs, see Integration graphs.

Authorization files

The REST endpoint generator adds entries to the relevant role.yaml files and the resource access files for both the verified and unverified resources. Each set must be configured as needed. For more information, see Configuring authorization for generated endpoints.