Event consumption

Event consumption allows you to receive the events from customer endpoints and use these events in Sterling Intelligent Promising.

The event volume that is generated by inventory changes or snapshot reaches millions on single day that largely depends on the number of system nodes and items. The volume increases based on the number of inventories, reservations, snapshot requests, and configuration adjustments. To support large number of event data sets effectively, the events are structured in a specific format to maximize the delivery efficiency like file compaction and optimization of events to files ratio. The event consumers might receive similar events for the same item if they were adjusted in the same time frame. It is to keep track of the event state prior to data processing in downstream systems.

Event processing timestamp comparison

When consuming availability type events such as node and network availability, the event consumer should consider the freshness of the data by observing the timestamps on the event payload.

An availability event may look like as follows.
{
   "type": "productAvailability.v2",
   "datacontenttype": "application/json",
   "id": "2a8d36a3-485b-3fc0-bd15-d530625a6ec5",
   "specversion": "1.0",
   "time": "2021-03-10T00:00:00.288Z",
   "data": {
     "computeTs": "2021-03-10T00:00:00.097Z",
     "productId": "ITEM01",
     "deliveryMethod": "SHP",
     "shipNode": "STORE01",
     "currentAvailability": {
        "toTs": "2021-04-01T00:00:00.000Z",
        "availableQuantity": 30,
        "consumedSafetyQuantity": 0,
        "fulfillmentAllowed": true,
        "reservedQuantity": 0,
        "shortageQuantity": 0,
        "thresholdLevel": 0
        }
     }
}
In this event payload, there are two timestamp attributes of interest:
  • time
    The time denotes when the event was published which may be later than the computeTs attribute.
  • computeTs
    This denotes the time when the availability was calculated. This is influence by actions, which includes supply or demand adjustments, fulfillment options, and reservation creations.
It is recommended for the event consumer to observe the computeTs attribute when determining whether an event should be process or skipped. If downstream system already have a newer computeTs, then it will not be necessary to process any events that have an earlier computeTs therefore can be discarded.

Consider the following sequence of events for ITEM01:

  1. time: T5, computeTs: T3, availableQuantity: 10
  2. time: T6, computeTs: T5, availableQuantity: 9
  3. time: T7, computeTs: T1, availableQuantity: 12

Given that the consumer already processed T6 as the computeTS with 9 availableQuantity. The event, which received at T7 should be discarded because the computeTs is T1, which is an older record.