イベント
イベントをサブスクライブし、 IBM Cloud® Object Storage (COS) エンドポイントまたは Webhook エンドポイントにパブリッシュされたイベントを表示することができます。 これらのエンドポイントは、非構造化データに対して柔軟でコスト効率が高く、スケーラブルです。
重要: Inventory service は、プッシュ・メカニズムをリアルタイムで実行するためのものではありません。 これは、在庫 API を直接呼び出さないマーケットプレイスに時々プッシュするために使用できます。 また、アカウンティングおよび監査の目的で使用することもできます。
イベント特性
イベントは、IBM® Cloud Object Storage と Webhooks を通して配信することができます。 詳しくは、 Webhook と COS の比較分析を参照してください。
- イベントメッセージとイベントトリガー
- すべてのアイテム関連の変更は、可用性の計算につながり、イベント・メッセージをトリガーします。 アイテム関連の変更の例としては、構成変更 (安全在庫の更新、フルフィルメント・オプション、親子関係の変更など)、トランザクション関連の変更、分配グループの同期などの一括アクションなどがあります。
- Sync Supply および Sync Demand PUT API 要求の場合、 Inventory Visibility は、データが最新であるかどうか、およびイベントをトリガーする必要があるかどうかを知るために、レコードの最新の
sourceTs値に依存します。sourceTsが指定されていない場合は、API 呼び出しのタイム・スタンプが使用されます。 最後に同期が発生した時刻より前のsourceTsが API 要求に含まれている場合、同期は無視され、イベントはトリガーされません。 - イベント・メッセージは、 inventory service からエンドポイントに少なくとも 1 回送信されます。 場合によっては、メッセージが複数回送信されることがあります。 そのため、さまざまな理由で、時々イベント・メッセージが重複していることに気付く場合があります。 データを処理する際には、重複するすべてのイベント・メッセージを削除する必要があります。
| トランザクション | ノート | 発生した最小イベント数 | 発生した最大イベント数 | 詳細情報 |
|---|---|---|---|---|
| 予約の作成 | Inventory Visibilityでオーダー予約を開きます。 | 2 ( PICK-1 & SHIP-1 ) | 2 ( PICK-1 & SHIP-1 ) | - |
オーダーの作成と reservationId |
予約は、 rsvr_demand Inventory Visibilityで作成されます。 |
2 ( PICK-1 & SHIP-1 ) | 4 ( PICK-2 & SHIP-2 ) | - |
| 注文のスケジュール | rsvr_demand は、スケジュールされた需要に変換されます。 |
0 | 4 ( PICK-2 & SHIP-2 ) | その時点でのワークロード・パターンに応じて、変更は集約されるか集約されないかのいずれかになります。 |
| 注文のリリース | ( for_demandタイプの) 一時予約が作成されました。 スケジュールされた需要は、割り振られた需要に変換されます。 |
0 | 4 ( PICK-2 & SHIP-2 ) | ワークロード・パターンに応じて、変更は集約されるか、集約されないかのいずれかになります。 |
| 出荷の確認 | 供給が削減されます。 需要が減少します。 | 0 | 4 ( PICK-2 & SHIP-2 ) | その時点でのワークロード・パターンに応じて、変更は集約されるか集約されないかのいずれかになります。 |
イベント配信
イベントは、 IBM Cloud Object Storage とウェブフックを通じて配信できます。 イベントを設定する際に、主な違いを理解してください。
詳細については 、「イベントの統合」 を参照してください。
Sterling Intelligent
Promisingの'Inventory serviceは、新しいイベントフォーマットのWebhooksにイベントを受信する機能を提供します。 各 POST リクエストで 1 つのイベントを送信する代わりに、イベントの JSON 配列を受け取ることができます。 この機能は以下のイベントで利用できる：