Initial Download
The TFT Router may encounter an error within a specific event of the event array. In this case, the TFT Router SHOULD acknowledge the last successful event with a new download POST, and then issue a second error POST indicating the error. The error POST in this case SHOULD contain the optional sequence number of the event that has the error. Here is an example of steps that could lead to this scenario:
- The TFT Router sends a download POST for 1000 events.
- The TSS sends 1000 events, sequence numbers 1200-2199.
- The sequence 1700 has a malformed TFN (e.g. 3 chars), due to a TSS code error.
- The TFT Router recognizes the error and sends a download POST with an ack of 1699. This tells the TSS to remove events 1200-1699 from the Event Queue since those events were successfully consumed by the TFT Router.
- The TSS removes events 1200-1699 from the Event Queue and responds with a normal successful response, since it does not know there is any issue yet.
- The TFT Router sends an error POST (permanent) with the offending sequence of 1700.
- The TSS responds with a permanent error response since it cannot recover.
- A manual process must ensue at this point to fix the issue and restore the connection.
Here is a concrete example of the above steps, where the first download POST acknowledges the last successful event sequence number and the next error POST indicates the error encountered, along with the offending sequence number (the two sequence numbers are likely to always be side-by-side).
POST /tft-download HTTP/1.0
Content-Type: application/json
Content-Length: <num>
{
"id":"user",
"pwd":"password",
"ack":1699, // The last successfully consumed sequence number.
"max":0 // 0 since the TFT Router knows an error POST is next
}
// The above POST is the download POST, not the error POST.
// The TSSRegistry response will have no events since the POST has
// a max of 0. The remaining field must still be accurate.
// Here’s the example response to the above download POST:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/plain;charset=ISO-8859-1
Content-Length: <num>
Date: Tue, 13 Jan 2015 16:38:00 GMT
Connection: close
{
"events":[], // empty since the POST “max” was 0 above.
"remaining":500 //e.g. there are still 500 events in the Event Queue
}
// The TFT Router then sends the error POST:
POST /tft-download-error HTTP/1.0
Content-Type: application/json
Content-Length: <num>
{
"id":"user",
"pwd":"password",
"error":"permanent",
"sequence": 1700, // Optional field, the event with the issue.
"message": "The TFN has only 3 chars (800)." // just an example
}
// The TSSRegistry responds with a permanent error acknowledging
// the above error POST:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/plain;charset=ISO-8859-1
Content-Length: <num>
Date: Tue, 13 Jan 2015 16:38:01 GMT
Connection: close
{
"error": "permanent",
"message": "Acknowledging the TFT Router error POST." // for example
}
Disclaimer: Any images in this article are intended to be used as a guide for educational purposes only and they may differ slightly from the Production Environment.
The above example also shows that the download POST is acknowledging the last successful event (sequence 1699) and the error POST indicates the error and provides the optional “sequence” field used to explicitly inform the TSSRegistry™ which event is being questioned (sequence 1700).
It should be noted that if the TFT Router chooses to not send the first download POST and instead simply sends the error POST, then the TSS still considers it a permanent failure (and responds) but does not remove any event from the Event Queue. The TSS only removes events from the Event Queue in response to a download POST -- if there is no download POST, then no events are removed.