Develop a Connector to Support Checkpoints

Interviews that use Oracle Integration or generic provider connections can save checkpoints during the interview. Such interviews can also be resumed using a previously saved checkpoint.

In Policy Modeling, the interview author selects which interview screens will generate checkpoints when submitted.

Data connectors need to implement two operations to support checkpoints:

SetCheckpoint operation

Request

The SetCheckpoint request has three parts:

  • The query parameters. These are defined in the integration system (for example, Oracle Integration), then passed as URL parameters when the SetCheckpoint request is made. This is the same as how query parameters work with the Load operation.

  • The checkpoint ID. This is the ID associated with the checkpoint data. This is not generated by Intelligent Advisor so will be blank unless supplied by the web service connector in the response of a previous SetCheckpoint response sent during the same interview session. Note that if an interview session is resumed via a GetCheckpoint request, any checkpoint ID returned in the GetCheckpoint response will not be sent with any subsequent SetCheckpoint requests in the same interview session. This is consistent with other Intelligent Advisor data connectors.

  • The checkpoint data. This is Base 64 encoded serialized interview session data.

Request schema:

{
    "name": "request",
    "properties":
    {
        "checkpoint":
        {
            "type" : "object",
            "properties" : {
                "checkpoint-id" : { "type" : "text" },
                "checkpoint-data" : { "type" : "text"}
            }
        },
    }
}

Sample request payload:

{
    "checkpoint" : {
        "checkpoint-id" : "13",
        "checkpoint-data" : "UEsDBBQACAgIAOR6NEg...AAAAA=="
    }
}

Response

The SetCheckpoint response contains a single item:

  • The checkpoint ID. This is the ID associated with the checkpoint data. If populated, this ID will be used in subsequent set checkpoint requests from this interview session. This is useful information for the integration to keep only one copy of a single interview session's data. Populating the checkpoint ID is optional, if the system being integrated does not support this, null can be returned for the checkpoint ID.

Response schema:

{
    "name": "response",
    "properties":
    {
        "checkpoint-id" : { "type" : "text" }
    }
}

Sample response payload:

{
    "checkpoint-id" : "13"
}

GetCheckpoint Operation

Request

Query parameters will be passed as URL parameters. These are defined in the integration system (such as Oracle Integration), then passed as URL parameters when the GetCheckpoint request is made. This is the same as how query parameters work with the Load operation.

The GetCheckpoint request does not send any data in the message body.

Request schema:

{
  "name": "request",
  "properties": {}
}

Response

The GetCheckpoint response consists of two parts:

  • The checkpoint ID. This will only be populated if a value for it was passed in the response of a previous SetCheckpoint request. Otherwise it will be null.

  • The checkpoint data. This is Base 64 encoded serialized interview session data.

Response schema:

{
    "name": "response",
    "properties":
    {
        "checkpoint":
        {
            "type" : "object",
            "properties" : {
                "checkpoint-id" : { "type" : "text" },
                "checkpoint-data" : { "type" : "text"}
            }
        },
    }
}

Sample response payload:

{
    "checkpoint" : {
        "checkpoint-id" : "13",
        "checkpoint-data" : "UEsDBBQACAgIAOR6NEg...AAAAA=="
    }
}
Related Topics