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
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
Procedure
- In Studio, select Run/Debug Configurations dialog box. . Studio opens the
- In the left pane, click Server.
-
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 withci-test
.
- If the VM Options field already contains an
- Click OK.
Results
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
ci-test
environment, you
can use Swagger UI to view the Test Util API.Procedure
-
Start ClaimCenter using the
ci-test
environment. -
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/
- The format of the URL is
-
In the text field at the top of the Swagger UI interface, enter the following
URL:
<applicationURL>/rest/test-util/v1/swagger.json
- 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 Developer 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.
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.)
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.
Policy locations
The following code block creates a policy location.
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.
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.
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.
- If you have not already done so, configure Studio to start ClaimCenter using the
ci-test
environment.- In Studio, select Run/Debug Configurations dialog box. . Studio opens the
- In the left pane, click Server.
- Add the following to the end of the VM Options field: -Dgw.cc.env=ci-test
- Click OK.
- Start ClaimCenter from Studio by selecting Server. and selecting
- In Postman, start a new request by clicking the + to the right of the
Launchpad tab.
- On the Authorization tab, select Basic Auth using user su and password gw.
- Enter the following call, but do not click Send yet:
- POST
http://localhost:8080/cc/rest/test-util/v1/policies
- POST
- Specify the request payload.
- In the first row of tabs (the one that starts with Params), click Body.
- In the row of radio buttons, select raw.
- At the end of the row of radio buttons, change the drop-down list value from Text to JSON.
- Paste the text in the Sample policy payload into the text field underneath the radio buttons.
- 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.