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.