Creating Policy descendant endpoints

Policies created during the First Notice of Loss (FNOL) process exist under two paths: the verified policy endpoints confirmed by the PAS that use Policy as the parent resource— /claims/{claimId}/policy ; /claims/{claimId}/policy/vehicle-risk-units — and unverified policy endpoints not confirmed by the PAS that use UnverifiedPolicies as a root resource-- /unverified-policies/{policyId}; /unverified-policies/{policyId}/vehicle-risk-units. Verified policies are read-only and allow only GET operations, while unverified policies are editable and permit GET/PATCH/POST operations, such as /coverages:

Policy as a parent to the custom resource

The entity must use Policy or a descendant of Policy as its parent, regardless of how distant the ancestor. Endpoints that use Policy or descendant of policy employ the ClaimCenter-specific behavior and configuration.

REST endpoint generator variances for Policy endpoints

  • All descendants of Policy use query-backed retrieval. You cannot select a Java stream to retrieve collections.
  • Policy entities always use the claim integration graph.

Therefore, the REST endpoint generator does not prompt for query or stream-backed resources, or adding the entity to an integration graph.

Configuring variances for glue and impl classes for Policy endpoints

Policy endpoints create and change the same series of files as standard endpoints but vary in logic for how the endpoint interacts with the application.

  • The apiconfig file generates extra entities for the verified and unverified policy resources. For example,
      mapper: CustomPolicyEntityExt
      updater: CustomPolicyEntityExt
  • There are four “impl” files that define implementation details for the verified and unverified policy resources.
    • Two <collection> file Gosu files that defines required behaviors for working with collections for verified and unverified policy resources. For example:
      • <collectionResource>
      • Unverified<collectionResource>
    • Two <element> file Gosu files that define required behaviors for working with elements for verified and unverified policy resource. For example:
      • <elementResource>
      • Unverified<elementResource>
    See respective sections below for variances and coding details

Configuring variances for the apiconfig file

The REST endpoint generator automatically changes the apiconfig file to map Policy element and collection resources for both verified and unverified policy resources to the respective Resource Gosu.

Guidewire recommends a default sort order for your verified and unverified collection resources to supply a consistent, deterministic response payload. Decide the object by which the response payload orders its collection by defining the default sort order. For example:

  - customDescription
  mapper: CustomPEntityExt
  updater: CustomPEntityExt
  - customDescription

Configuring variance for Policy resource files

Policy endpoint impl files for verified and unverified policies variances are as follows:

Verified resource files

  • Verified and unverified element resources do not include delete methods. You cannot delete verified policies or child object on verified policies, and Guidewire does not offer deletion of unverified policies at this time.

Unverified resource files

  • Unverified Policy element resource files generate an additional operation finishCreate(data,batchUpdateMap) to reserve Ids for additional beans created by the Policy resource. See The finish create operation for more information.
  • Unverified Policy collection resource files generate an additional property getter get Policy(): Policy to connect the path from policy descendants to the Policy resource. See the policy getter for mor information.

The policy getter

In the Unverified<collectionResource> file, the policy getter connects the path from the policy descendant to the policy.

For example, if your endpoint has a Foreign Key to of Grandchild_Ext, which then has a foreign key Child_Ext, to which has a foreign key to Policy with this.Parent.Element.Policy.

The following code illustrates this:

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

The finishCreate operation

In the Unverified<elementResource>, the finishCreate operation reserves Ids for any additional objects resulting from the creation of the Policy endpoint.

Creating an unverified policy requires composite requests to execute subsrequests for claim and policy creation. Composite request reserve Id values so that these Ids can be provided in subresponses and committed to the database. For example, a subrequest of POST /claims returns a response for with a reserved Id.

However, the composite API does not reserve Ids for inline objects create in composite response payloads. For example, the framework API assigns an Id for the /unverified-policies/policyId/vehicleRiskUnitsendpoint, but not the inline child object vehicle. Subrequests rely on the finishCreate operation to reserve Ids for an inline object.

If the updater or schema files for your risk unit endpoint contain custom inline objects of which you want to reserve an Id, implement the finishCreate operation.

For example, your risk unit schema or mapper contains the inline object framing, and you want to reserve an Id from the framing object in response payloads.

The following code illustrates this:

override function finishCreate(data : DataEnvelope, batchUpdateMap : BatchUpdateMap) {
  super.finishCreate(data, batchUpdateMap)
  var riskUnit = this.Element