Incidents and risk units: Risk unit endpoints
After you have configured your incident and risk unit data model, you must generate endpoints for both the incident and the risk unit. The following section describes differences in the REST endpoint generator behavior when the target entity is a risk unit.
For an overview of the process of implementing custom incidents and risk units, see Incidents and risk units: Implementation overview.
For information on how to run the REST endpoint generator, see REST endpoint generator overview.
Differences in the generator prompts
The REST endpoint generator checks to see if the target entity is a
subtype of RiskUnit
. If it is, the REST endpoint generator
considers the entity to be a risk unit entity.
For risk unit endpoints:
- The endpoints are always added to the Claim API.
- The endpoints are always child endpoints (with
Policy
as the direct or indirect parent). - The collection is always backed by a Gosu query.
- The resource is always added to the claim integration graph.
Therefore:
- There is no prompt asking which API to add the endpoints to.
- There is no prompt asking if the endpoints are root resource endpoints.
- There is no prompt asking whether you want the endpoint to be stream-back or query-backed.
- There is no prompt asking if you want the entity to be added to an integration graph.
Also, when you specify the parent, the generator validates the parent is a descendant of
Policy
.
Differences in the generated files
Endpoints
Risk unit endpoints
Similar to the endpoints for base configuration risk units, the REST endpoint generator creates six endpoints for custom risk units:
- For verified policies:
- A collection GET and an element GET
- For unverified policies:
- A collection GET and an element GET
- A POST
- A PATCH
For example, suppose you generated endpoints for a custom policy descendant named
CustomRiskUnit_Ext
. The endpoints would be:
- Verified policies
- GET
/claim/v1/claims/{claimId}/policy/custom-risk-unit-ext
- GET
/claim/v1/claims/{claimId}/policy/custom-risk-unit-ext/{customRiskUnitExtId}
- GET
- Unverified policies
- GET
/claim/v1/unverified-policies/{policyId}/custom-risk-unit-ext
- GET
/claim/v1/unverified-policies/{policyId}/custom-risk-unit-ext/{customRiskUnitExtId}
- POST
/claim/v1/unverified-policies/{policyId}/custom-risk-unit-ext
- PATCH
/claim/v1/unverified-policies/{policyId}/custom-risk-unit-ext/{customRiskUnitExtId}
- GET
Coverage endpoints
The REST endpoint generator also creates six endpoints for coverages for the custom risk unit:
- For verified policies:
- A collection GET and an element GET
- For unverified policies:
- A collection GET and an element GET
- A POST
- A PATCH
For example, suppose you generated endpoints for a custom policy descendant named
CustomRiskUnit_Ext
. The coverage endpoints would be:
- Verified policies
- GET
/claim/v1/claims/{claimId}/policy/custom-risk-unit-ext/{customRiskUnitExtId}/coverages
- GET
/claim/v1/claims/{claimId}/policy/custom-risk-unit-ext/{customRiskUnitExtId}/coverages/{coverageId}
- GET
- Unverified policies
- GET
/claim/v1/unverified-policies/{policyId}/custom-risk-unit-ext/coverages
- GET
/claim/v1/unverified-policies/{policyId}/custom-risk-unit-ext/{customRiskUnitExtId}/coverages/{coverageId}
- POST
/claim/v1/unverified-policies/{policyId}/custom-risk-unit-ext/coverages/
- PATCH
/claim/v1/unverified-policies/{policyId}/custom-risk-unit-ext/{customRiskUnitExtId}/coverages/{coverageId}
- GET
Resources
Risk unit resources
Cloud API creates two sets of resources for each custom risk unit:
- One set is for verified policies. These resources are named as normal. For
example:
CustomRiskUnitExt
CustomRiskUnitsExt
- One set is for unverified policies. These resources are named with an
"Unverified" prefix. For example:
UnverifiedCustomRiskUnitExt
UnverifiedCustomRiskUnitsExt
These resources share a single set of schema, mapping, and updater files.
The generator also creates four impl files:
- Two of them are for the verified policy resources. For example:
- CustomRiskUnitExtResources.gs (the verified element resource file)
- CustomRiskUnitsExtResources.gs (the verified collection resource file)
- Two of them are for the unverified policy resources. For example:
- UnverifiedCustomRiskUnitExtResources.gs (the unverified element resource file)
- UnverifiedCustomRiskUnitsExtResources.gs (the unverified collection resource file)
Coverage resources
The REST endpoint generator does not generate new resources for the coverage
endpoints for custom risk units. All risk unit coverage endpoints use the same
RiskUnitCoverage
and
UnverifiedRiskUnitCoverage
resources and code, whether they are
coverage endpoints for base configuration risk units or custom risk units.
Schemas
The custom risk unit's schema
For standard entities, the REST endpoint generator makes only the following changes to the schema configuration files:
- It adds an
id
property to the API's schema extension file - It adds a mapper for the
id
property to the API's mapping extension file.
For risk units, the generator makes the following additional changes.
- In the schema extension file, it adds the following properties, as these are
standard entity model properties found on the
RiskUnit
supertype:RUNumber
(sortable and filterable)description
policySystemId
(filterable)
- In the mapper extension file, it adds mappers for the
RUNumber
,description
, andpolicySystemId
properties. - In the updater extension file, it adds updaters for the
RUNumber
anddescription
properties. (policySystemId
can only be set by the PAS integration code, and is therefore read-only from Cloud API.)
The Policy graph schema
The generator adds a <customRiskUnit>
property and an
associated coverages
property to the Policy graph in the claim
graph schema extension file. The coverages
property is also added
to the mapper and will order the coverages with
RiskUnitRestV1.CoveragesSorted
. You can optionally change the
code to use a different sort order.