Identifying Changed Records

Identifying Changed Records

When an application that uses delta subscriptions receives a message, that message can either be a new record or an update to an existing record. AMPS offers two strategies for an application to tell whether the record is a new record or an existing record and identify which record has changed if the message is an update to an existing record.

The two basic approaches are as follows:

1. By default, each message delivered through a delta subscription contains a SowKey header field. This field is the identifier that AMPS assigns to track a distinct record in the SOW. If the application has previously received a SowKey with that value, then the new message is an update to the record with that SowKey value. If the application has not previously received a SowKey with that value, then the new message contains a new record.

2. Delta messages can also contain the key fields from the SOW in the body of the message. This is controlled by the send_keys option on the subscription, which is always enabled as of AMPS 4.0. With this approach, the application parses the body of the message to find the key. If the application has previously received the key, then the message is an update to that existing record. Otherwise, the message contains a new record.

In either case, AMPS delivers the information the application needs to determine if the record is new or changed. The application chooses how to interpret that information, and what actions to take based on the changes to the record.

AMPS also supports out-of-focus notification for delta subscriptions, as described in Out-of-Focus (OOF) messages. If your application needs to know when a record is deleted, expires, or no longer matches a subscription, you can use out-of-focus messages to be notified.

Conflated Subscriptions and Delta Subscribe

AMPS provides subscription conflation on delta subscriptions. When conflation is enabled, each delta message during the conflation interval is merged into the conflated message. The message that is delivered is the merge of all of the deltas that arrived during the conflation interval.

Since AMPS combines successive delta messages into a single update, a delta subscription that uses conflation may receive values that are identical to the previous values. For example, consider the following record in a SOW that uses /id as the key:

{
    "id": 99,
    "status":"open",
    "notes":"none",
    "xref":82
}

Assume that the following updates to the record are published during the conflation interval:

{"id": 99, "status":"questioned", "notes":"none", "xref":82}
{"id": 99, "status":"questioned", "notes":"jcarlo hold", "xref":82}
{"id": 99, "status":"cleared", "notes":"none", "xref":82}
{"id": 99, "status":"open", "notes":"none", "xref":82}

At the end of the conflation interval, the subscription will receive the delta message:

{
    "id": 99,
    "status":"open",
    "notes":"none"
}

The /id field is included because that field is the key of the SOW, and all of the delta messages produced during the conflation interval contained that key. The /status and /notes fields are included because there were changes to these values during the conflation interval. The delta messages produced during the conflation interval contained changed values, so the merged update contains those fields and the state of the values at the end of the conflation interval. The /xref field is not included, because none of the delta messages produced during the conflation interval contained that field.