イベント消費

イベント消費では、顧客のエンドポイントからイベントを受け取り、これらのイベントをSterling Intelligent Promisingで使用することができます。

インベントリの変更やスナップショットによって発生するイベント量は、システムノードとアイテムの数に大きく依存し、1日に数百万に達します。 インベントリ数、予約数、スナップショット要求数、コンフィギュレーション調整数に応じてボリュームは増加する。 大量のイベントデータセットを効率的にサポートするために、イベントは特定のフォーマットで構造化され、ファイルの圧縮やファイルに対するイベントの比率の最適化など、配信効率を最大化する。 イベント消費者は、同じ時間枠で調整された場合、同じアイテムの同じようなイベントを受け取るかもしれない。 これは、下流のシステムでデータを処理する前に、イベントの状態を追跡するためである。

イベント処理のタイムスタンプ比較

ノードやネットワークのアベイラビリティのようなアベイラビリティタイプのイベントを消費するとき、イベントコンシューマは、イベントペイロード上のタイムスタンプを観察することで、データの鮮度を考慮するべきである。

アベイラビリティ・イベントは以下のようになる。
{
   "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
        }
     }
}
このイベントペイロードには、2つのタイムスタンプ属性がある：
  • 時刻
    時刻はイベントが公開された時刻を表し、computeTs属性よりも後になるかもしれません。
  • computeTs
    これはアベイラビリティが計算された時間を示す。 これは、需給調整、フルフィルメント・オプション、予約作成などのアクションによって影響を受ける。
イベントを処理すべきかスキップすべきかを決定するとき、イベントコンシューマーはcomputeTs属性を観察することが推奨されます。 computeTs下流のシステムにすでに新しいバージョンが存在する場合、それより古い computeTs バージョンのイベントを処理する必要はないため、破棄しても構いません。

ITEM01について、次のような一連の流れを考えてみよう：

  1. 時間：T5, computeTs：T3, availableQuantity: 10
  2. 時間：T6, computeTs：T5、availableQuantity: 9
  3. 時間：T7, computeTs：T1、availableQuantity: 12

消費者はすでにT6をcomputeTSとして9つのavailableQuantityで処理している。 T7で受信したイベントは、computeTsがT1であり、古いレコードであるため、破棄されるべきである。