Checksums for PATCHes and business action POSTs

For operations that have a request payload, checksums can be specified in the request payload. This applies to PATCHes and to most POSTs that execute business actions. (If a business action POST does not allow a request payload, you can still specify a checksum. But, you must do this in the request header. For more information, see Checksums for DELETEs.)

The checksum property is a child of the data property and a sibling of the attributes property. It uses the following syntax:

"checksum": "<value>"

For example, the following payload is for a PATCH to an activity. The payload specifies a new attribute value (setting priority to urgent) and a checksum value (7a0d9677f11e246bbe3c124889219c50).

{
  "data": {
    "attributes": {
      "priority": {
        "code": "urgent"
      }
    },
    "checksum": "7a0d9677f11e246bbe3c124889219c50"
  }
}

Checksums can be specified on the root resource and on any included resource. Specifying a checksum for any one resource does not require you to specify checksums for the others. For example:

  • You could specify a checksum for only the root resource.
  • You could specify a checksum for only one of the included resources.
  • You could specify a checksum for the root resource and some of the included resources, but not all of the included resources.

Tutorial: PATCH an activity using checksums

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

In this tutorial, you will attempt to PATCH an activity twice. Both PATCHes will include a checksum value. The first PATCH will succeed, and the second will fail.

Note: This tutorial only applies to ClaimCenter and PolicyCenter. For a BillingCenter tutorial, see Tutorial: PATCH an account using checksums.

Tutorial steps

  1. In Postman, start a new request by clicking the + to the right of the Launchpad tab.
  2. On the Authorization tab, select Basic Auth using user aapplegate and password gw.
  3. Query for the actvity you're going to patch for your respective InsuranceSuite application:
    • ClaimCenter: The sample data includes one "Get police report" activity, which can be PATCHed because it is an open activity on an open claim. Query for that activity by entering the following call and clicking Send:

      GET http://localhost:8080/cc/rest/common/v1/activities?filter=subject:sw:Get%20police%20report

    • PolicyCenter: The sample data includes one "Review risk information" activity for Alice Applegate. Query for that activity by entering the following call and clicking Send:

      GET http://localhost:8180/pc/rest/common/v1/activities?filter=subject:sw:Review%20risk

  4. Note the ID, subject, and checksum of the first activity returned in the response payload. (These values are referred to in later steps as "<ActivityID>", "<originalSubject>", and "<originalChecksum>".)
  5. Open a second request tab. Right-click the first tab and select Duplicate Tab.
  6. Change the operation to PATCH and enter the following URL for your respective InsuranceSuite application, but do not click Send yet:
    • ClaimCenter: PATCH http://localhost:8080/cc/rest/common/v1/activities/<ActivityID>
    • PolicyCenter: PATCH http://localhost:8180/pc/rest/common/v1/activities/<ActivityID>
  7. 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 following into the text field underneath the radio buttons. For subject, specify the original subject with an additional "-1". 
      {
  "data": {
    "attributes": {
      "subject" : "<originalSubject>-1"
    },
    "checksum": "<originalChecksum>"
  }
}
  8. Click Send. The checksum value in the payload matches the checksum value for the activity stored in your respective InsuranceSuite application. This means that the PATCH is successful, and the response payload will appear below the request payload.
  9. Click Send a second time. Now, the checksum value in the payload does not match the checksum value for the activity calculated by the InsuranceSuite application. This means that the second PATCH is unsuccessful, and an error message appears.

Tutorial: PATCH an account using checksums

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 attempt to modify an account twice. Both attempts will include a checksum value. The first attempt will succeed, and the second will fail.

Note: This tutorial only applies to BillingCenter. For a tutorial that applies to ClaimCenter and PolicyCenter, see Tutorial: PATCH an activity using checksums

Tutorial steps

  1. In Postman, start a new request by clicking the + to the right of the Launchpad tab.
  2. On the Authorization tab, select Basic Auth using user su and password gw.
  3. The sample data includes one sample account called "Standard Account." Query for that account by entering the following call and clicking Send:

    GET http://localhost:8580/bc/rest/billing/v1/accounts?filter=accountNumber:eq:Standard%20Account

  4. For the account in the response payload, note the checksum (checksum). (This value is later referred to in later steps as "<OriginalChecksum>".)
  5. Open a second request tab. Right-click the first tab and select Duplicate Tab.
  6. Change the operation to POST and enter the following URL, but do not click Send yet:

    PATCH http://localhost:8580/bc/rest/billingv1/accounts/<AccountId>

  7. 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 following into the text field underneath the radio buttons. For the account name, specify the original account name with an additional "-1". 
    {
  "data": {
    "attributes": {
      "accountName": "Standard Account -1"
    },
    "checksum": "<OriginalChecksum>"
  }
}
  8. Click Send. The checksum value in the payload matches the checksum value for the activity stored in BillingCenter. This means that the PATCH is successful, and the response payload will appear below the request payload.
  9. Click Send a second time. Now, the checksum value in the payload does not match the checksum value for the activity calculated by BillingCenter. This means that the second PATCH is unsuccessful, and an error message appears.

Tutorial: Assign an activity using checksums

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 attempt to execute a business action (assigning an activity) twice. Both attempts will include a checksum value. The first attempt will succeed, and the second will fail.

Note: This tutorial only applies to ClaimCenter and PolicyCenter.

Tutorial steps

  1. In Postman, start a new request by clicking the + to the right of the Launchpad tab.
  2. On the Authorization tab, select Basic Auth using user aapplegate and password gw.
  3. Query for the actvity you're going to assign for your respective InsuranceSuite application:
    • ClaimCenter: The sample data includes one "Get police report" activity, which can be PATCHed because it is an open activity on an open claim. Query for that activity by entering the following call and clicking Send:

      GET http://localhost:8080/cc/rest/common/v1/activities?filter=subject:sw:Get%20police%20report

    • PolicyCenter: The sample data includes one "Review risk information" activity for Alice Applegate. Query for that activity by entering the following call and clicking Send:

      GET http://localhost:8180/pc/rest/common/v1/activities?filter=subject:sw:Review%20risk

  4. Note the ID and checksum of the first activity returned in the response payload. (These values are referred to in later steps as "<ActivityID>", and "<originalChecksum>".)
  5. Open a second request tab. Right-click the first tab and select Duplicate Tab.
  6. Change the operation to POST and enter the following URL for your respective InsuranceSuite application, but do not click Send yet:
    • ClaimCenter: POST http://localhost:8080/cc/rest/common/v1/activities/<ActivityID>/assign
    • PolicyCenter: POST http://localhost:8180/pc/rest/common/v1/activities/<ActivityID>/assign
  7. The POST /{activityId}/assign endpoint requires a request payload that specifies how the assignment is to be done. 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 following into the text field underneath the radio buttons. For subject, specify the original subject with an additional "-1". 
      {
  "data": {
    "attributes": {
        "autoAssign": true
    },
    "checksum": "<originalChecksum>"
  }
}
  8. Click Send. The checksum value in the payload matches the checksum value for the activity stored in the InsuranceSuite application. This means that the POST /assign is successful, and the response payload will appear below the request payload.
  9. Click Send a second time. Now, the checksum value in the payload does not match the checksum value for the activity calculated by the InsuranceSuite application. (The successful POST /assign from the previous step will have modified the checksum value.) This means that the second POST /assign is unsuccessful, and an error message appears.