The Test Util API

To create a claim, you must have information from a Policy Administration System. In some situations, you may also need information from an external user management system or contact management system. However, during development, your instance of ClaimCenter may not have access to any of these systems.

To facilitate development, Cloud API includes a Test Util API. The Test Util API is an API that provides functionality to facilitate testing during development. You can use the Test Util API to:

  • Create and search for test policies
  • Create and search for test contacts and test user roles
  • Create and search for test users
Warning: The Test Util API is intended for use in a development environment only. Do not use the Test Util API on a production system.

Viewing Test Util API information

The Test Util API is available only when the ClaimCenter environment is set to ci-test. The environment can be set only during start-up. For more information on how to start ClaimCenter in a given environment, refer to the System Administration Guide.

Set the ClaimCenter environment in Studio

About this task

In Studio, you can specify an environment for ClaimCenter to use whenever it is started from Studio.

Procedure

  1. In Studio, select Run > Edit Configurations. Studio opens the Run/Debug Configurations dialog box.
  2. In the left pane, click Server.
  3. Add the following to the end of the VM Options field: -Dgw.cc.env=ci-test
    • If the VM Options field already contains an env setting, replace the existing setting with ci-test.
  4. Click OK.

Results

Whenever the server is started from Studio, it will be started using the ci-test environment. This includes:
  • Starting the server from the Run menu.
  • Starting the server using the Run tools in the upper right corner of the Studio user interface.

View the Test Util API in Swagger UI

About this task

Once ClaimCenter has been started using the ci-test environment, you can use Swagger UI to view the Test Util API.

Procedure

  1. Start ClaimCenter using the ci-test environment.
  2. In a web browser, enter the URL for Swagger UI. This loads the Swagger UI tool.
    • The format of the URL is <applicationURL>/resources/swagger-ui/
    • For example, for a local instance of ClaimCenter, use: http://localhost:8080/cc/resources/swaggerui/
  3. In the text field at the top of the Swagger UI interface, enter the following URL:
    • <applicationURL>/rest/test-util/v1/swagger.json
  4. Click Explore.

Creating test policy data

The TestSupportPolicyPlugin class

At the beginning of the FNOL process, the user or service that is executing FNOL must identify the relevant policy. Once identified, ClaimCenter copies information about that policy to its own policy graph. These processes are referred to as policy search and policy retrieval. The details for how to execute these processes are specified by the IPolicySearchAdapter plugin.

The base configuration includes an implementation of the IPolicySearchAdapter plugin that points to a Gosu class named TestSupportPolicyPlugin. This implementation is used only when ClaimCenter is started in the ci-test environment.

The Test Util endpoints

In the base configuration, none of the API roles provide access to the endpoints in the Test Util API. Therefore, the only user who can create test policies is the super user su, who inherently has access to all endpoints.

You can configure the existing API roles to extend access to these endpoints to other users. For more information on configuring API roles, see the Cloud API Authentication Guide.

Creating test policies

You can use the /test-util/v1/policies endpoint to create test policies. When you execute this endpoint, the system APIs take the data specified in the payload and add it to the data in the TestSupportPolicyPlugin class. This allows you to reference test policies and their data in later calls that create claims and claim data.

There is no minimum data needed to create a test policy. If you create a policy with an empty request payload, the policy will have the following attributes:

  • The policy currency will be set to the ClaimCenter default currency.
  • The effective date will be set to the current date.
  • The expiration date will be set to one year from the current date.
  • The policy will be an unverified policy.

You can use the policies in the sample data as models for how to build test policies. To do this, identify the claim ID of a claim whose policy is an appropriate model. Then, execute a GET on any of the endpoints starting with /claims/{claimId}/policy to view how to structure data in a JSON payload. For a complete description of the data that can be specified in the request payload, refer to Swagger UI.

Use a unique policy number for each policy

When creating a test policy, the system APIs do not require that the policy number be unique from any existing policy numbers. However, if there are two or more policies with the same policy number, you will not be able to create a claim using that policy number. This is because the system API that creates claims will find multiple policies and will not be able to identify which policy to use.

Examples of test policy data

The following sections provide examples of some of the more frequently used fields. To access these examples compiled into a single payload, see Sample policy payload.

Common scalar fields

The following code block creates a policy that is effective from January 1, 2020 to January 1, 2021. Its policy number is FNOL-POLICY, and it is a verified policy.

{
  "data": {
    "attributes": {
      "effectiveDate": "2020-01-01T07:00:00.000Z",
      "expirationDate": "2021-01-01T07:00:00.000Z",
      "policyNumber": "FNOL-POLICY",
      "verifiedPolicy": true
    }
  }
}

Common typekey fields

The following code block creates a personal auto policy that is in force. (In other words, the policy has not been canceled.)

{
  "data": {
    "attributes": {
      "policyType": {
        "code": "PersonalAuto"
      },
      "status": {
        "code": "inforce"
      }
  }
}

Policy contacts

The following code block creates a policy where the insured is a person named Ray Newton who lives at 287 Kensington Rd. #1A, South Pasadena, CA. The ID in the Policy Administration for this contact is ab:0001-1.

When creating test policies, policy contacts are specified using request inclusion. For more information on this approach, see Request inclusion.

{
  "data": {
    "attributes": {
      "policyContacts": [
        {
          "contact": {
            "refid": "rayNewton"
          },
          "roles": [
            {
              "code": "insured"
            }
          ]
        }
      ]
    }
  },
  "included": {
    "Contact": [
      {
        "attributes": {
          "firstName": "Ray",
          "lastName": "Newton",
          "primaryAddress": {
            "addressLine1": "287 Kensington Rd. #1A",
            "city": "South Pasadena",
            "country": "US",
            "postalCode": "91145",
            "state": {
              "code": "CA"
            }
          },
          "subtype": {
            "code": "Person"
          },
          "policySystemId": "ab:0001-1"
        },
        "method": "post",
        "refid": "rayNewton",
        "uri": "/test-util/v1/contacts"
      }

    ]
  }
}

Policy locations

The following code block creates a policy location.

{
  "data": {
    "attributes": {
      "policyLocations": [
        {
          "address": {
            "addressLine1": "287 Kensington Rd. #1A",
            "city": "South Pasadena",
            "postalCode": "91145",
            "state": {
              "code": "CA"
            }
          }
        }
      ]
    }
  }
}

Policy-level coverages

The following code block creates a policy-level coverage. Note that the coverage has a coverage type (a typekey field), and two currency amount fields. A policy can also contain risk unit coverages, which are shown in the next section.

{
  "data": {
    "attributes": {
      "policyCoverages": [
        {
          "coverageType": {
            "code": "PALiabilityCov"
          },
          "incidentLimit": {
            "amount": "30000.00",
            "currency": "usd"
          },
          "exposureLimit": {
            "amount": "15000.00",
            "currency": "usd"
          }
        }
      ]
    }
  }
}

Risk units

A risk unit is something on a policy to which coverages are attached, such as a vehicle or a building. The following code block creates a risk unit. There are different types of risk units, depending on the policy's product type. Because the other examples are from a personal auto policy, this example is a vehicle risk unit.

Risk units typically include risk unit coverages (such as Collision coverage on a vehicle). For each coverage, you must specify a coverageType, which must be set to a value from the coverageType typelist. The coverage can also have coverage terms (such as a deductible). If you include coverage terms, each coverage term must have a covTermPattern (set to a code from the covTermPattern typelist) and a covTermSubtype (set to a code from the covTerm typelist). Additional fields may be necessary based on the type of coverage term. For example, coverage terms that are financial amounts require a financialAmount field.

{
  "data": {
    "attributes": {
      "vehicleRiskUnits": [
        {
          "RUNumber": 1,
          "vehicle": {
            "licensePlate": "1HGJ465",
            "make": "Saturn",
            "model": "SL",
            "policySystemId": "pcveh:0001-1",
            "state": {
              "code": "CA"
            },
            "vin": "1GV234TV347463345",
            "year": 1997
          },
          "coverages": [
            {
              "coverageType": {
                "code": "PACollisionCov"
              },
              "covTerms": [
                {
                  "covTermPattern": {
                    "code": "PACollDeductible"
                  },
                  "covTermSubtype": "FinancialCovTerm",
                  "financialAmount": {
                    "amount": "500.00",
                    "currency": "usd"
                  }
                }
              ],
              "incidentLimit": {
                "amount": "15000.00",
                "currency": "usd"
              }
            }
          ]
        }
      ]
    }
  }
}

Tutorial: Creating a policy using the Test Util API

This tutorial assumes you have set up your environment with Postman and the correct sample data set. For more information, see Tutorial: Set up your Postman environment.

In this tutorial, you will add a policy to the policy data stored in the TestSupportPolicyPlugin class. You can then reference this policy when creating a new claim.

  1. If you have not already done so, configure Studio to start ClaimCenter using the ci-test environment.
    1. In Studio, select Run > Edit Configurations. Studio opens the Run/Debug Configurations dialog box.
    2. In the left pane, click Server.
    3. Add the following to the end of the VM Options field: -Dgw.cc.env=ci-test
    4. Click OK.
  2. Start ClaimCenter from Studio by selecting Run > Run and selecting Server.
  3. In Postman, start a new request by clicking the + to the right of the Launchpad tab.
    1. On the Authorization tab, select Basic Auth using user su and password gw.
  4. Enter the following call, but do not click Send yet:
    • POST http://localhost:8080/cc/rest/test-util/v1/policies
  5. Specify the request payload.
    1. In the first row of tabs (the one that starts with Params), click Body.
    2. In the row of radio buttons, select raw.
    3. At the end of the row of radio buttons, change the drop-down list value from Text to JSON.
    4. Paste the text in the Sample policy payload into the text field underneath the radio buttons.
  6. Click Send.

Checking your work

ClaimCenter does not show data related to policies that are not associated with a claim. Therefore, there is no independent way to check your work for this tutorial, other than confirming that you get a response code and then attempting to create a claim using the policy.

Creating test data for related objects

You can also use the Test Util API to create objects related to policies, such as contacts and specialist services. This may be useful when you want to test functionality during development and it is too cumbersome to create the required objects manually.