予約
キャパシティの予約は主に「Promising」モジュールによって実行されますが、カスタムサービスカテゴリを管理するシステムインテグレーターにとって、このトランザクションの仕組みを理解することは極めて重要です。
キャパシティ予約の根本的な目的は、キャパシティ利用可能プールから対象ノードのキャパシティを確実に確保しておくことです。 この容量を保留することで、システムはそれ以降の予約および配送予定日のリクエストに動的に影響を与えます。 容量スロットが枯渇すると、Promisingエンジンは、納期やフルフィルメント遅延によるペナルティを最小限に抑えるため、自動的に次に利用可能なスロットを検出するか、あるいはまったく別の調達先へ切り替えます。
対応している予約タイプ
Capacityサービスは、運用上の複雑さの程度に応じて、2つの異なる予約メカニズムをサポートしています：
- 1件の予約
- 特定の1つの時間枠に対して容量を割り当てます。
- アトミックの一括予約
- 異なる路線にわたる複数の容量スロットを同時に予約できるようにします。 このAPIでは、厳格な「オール・オア・ナッシング」型のトランザクション動作が適用されます。 帯域幅の不足により、1行でも容量チェックに失敗した場合、トランザクション全体がロールバックされ、注文の完全な整合性が確保されます。
予約の基本属性
選択した予約タイプにかかわらず、API は以下の主要なパラメータを評価することで動作します：
- ノード
- 日時と時間帯
- 対象となる運用日および時間帯。
- リソース・プール ID
- 状況
- 現在のトランザクションの状態。例えば、「Open」、「Confirmed」、「In Progress」、「Completed」など。
- 数量
- 差し控えるべき比熱の単位。
- 参照
- ビジネス全体を識別するIDで、通常はカートIDや注文IDに類似しています。
- 線の参照
- 特定のカートまたは注文行に対応する、任意の識別子。
- 残り時間（分）
- ステータスが「Open」の場合にのみ適用されるオプションのパラメータです。 デフォルトではテナントレベルの設定が適用されますが、APIレベルで明示的に上書きすることができます。
キャパシティ状況のライフサイクルとバックログ管理
注文ステータスのライフサイクルを理解することは、注文処理の進捗状況を追跡するために不可欠です。
- オープン
- 注文管理システムでまだ正式に確定されていないカート予約に似ています。
- 確認済み
- 注文が正常に作成され、支払いが承認されたことを示します。
- 進行中
- このステータスは、注文がスケジューリング中であり、処理のためにフルフィルメントノードに割り当てられていることを示します。
- 完了
- 注文が正常に出荷されたことを示す最終段階です。
実際の業務は必ずしも完璧とは限らず、倉庫では予期せぬ人手不足や梱包伝票の紛失などが発生する可能性があります。 すでに過ぎた日付について、キャパシティ予約が「確定」または「処理中」のステータスのままである場合、キャパシティ・サービスはこれらのユニットをバックログ・キャパシティとして分類します。
ステータスの管理と変更ルール
キャパシティ状態の管理を改善するため、本システムではステータスを更新できるユーティリティAPIを提供しています：
- 予約ID別
- 単一の、独立した予約のステータスを変更します。
- 参照
- 同じカートまたは注文番号を共有するすべての予約を、同時に新しいステータスに移行できるようにします。
運用上の見積もりの正確性を確保するため、本システムでは、予約済みの容量数量を直接変更することはできません。 キャパシティ単位の調整が必要な場合は、元の予約を予約レコードを削除して明示的にキャンセルし、その後、同じ日付で再予約を行う必要があります。
注：IBM のOMS-SIP統合アダプターが有効になっている場合、キャパシティの状態は自動的に管理され、注文が標準的なフルフィルメントライフサイクルを通じて処理されるにつれて、シームレスに移行します。