まず結論から。稼働開始後に起きる API と EDI の連携トラブル対応は、壊れた連携をできるだけ速く直すことではない。悪化させないことだ。私が見てきた最も高くついたミスは、元の障害が原因ではなかった。誰かがパニックになり、すべてを再送し、在庫を手で修正し、インターフェースを再起動したことが原因だった。追跡可能な障害が、誰にも突き合わせできない混乱になったのだ。だから何かに触れる前に、障害を分類すること。メッセージは届かなかったのか。届いたのに処理されなかったのか。処理されたのに確認が返らなかったのか。それとも 3 つのシステムがそれぞれ自分の数値こそ正しいと主張しているのか。分類を間違えれば、その後の手順はすべて間違う。私はこの落とし穴を 3 つの異なる倉庫で 3 回、同じ筋書きで見てきた。

最初の話は昨秋、カリフォルニア州オンタリオ郊外の家庭用品のサードパーティ倉庫でのことだ。稼働開始から 3 週目のある火曜日の朝、小売業者から 400 件を超える注文が倉庫に届いていないと報告があった。当番の担当者はインターフェースが落ちたと思い込み、2 回再起動した。何も変わらなかった。確認すると、小売業者は注文を送信しており、当社のゲートウェイも受信していたが、商品コードの末尾を小売業者が知らせずに変更していたため、注文検証で止まっていた。何も壊れていなかった。両者とも、相手は何も変えていないと思い込んでいただけだった。旧コードを一時的にマッピングして出荷を動かし、その後、正式な通知プロセスでコード変更を通した。それ以来、私はシステムログの前に変更ログを確認している。

2 つ目の話はもっと痛い。シカゴ近郊の小型家電倉庫は、稼働開始後の最初の 1 か月、在庫が 1 日に 100 単位以上ずれ続け、高くなったり低くなったりし、1 週間誰もパターンを見つけられなかった。原因は 2 つの問題の重なりだった。小売業者のシステムが返品受領を 2 回送っており、当社側に冪等性のチェックがなかったため、同じ返品が 2 回計上された。さらに、循環棚卸の調整が WMS に直接入力され、小売業者へ送り返されることはなかった。各々が自分の数値を編集し続け、差は広がる一方だった。解決策は巧妙なものではなかった。業務文書番号で再送メッセージをすべて重複排除し、在庫調整はすべてインターフェース経由で行い、誰かが数量を変えて立ち去ることを許さないこと。その 2 行はそれ以来、私の稼働開始夜のチェックリストに載っている。

API/EDI の障害：まず分類し、それから動く

分類は 4 つの文でできる。ログファイルを開く前に、障害をそのいずれかに当てはめること。1 つ目、メッセージが届かなかった。送信されなかった、誤ったエンドポイントに送られた、証明書の有効期限切れ、ネットワーク障害。2 つ目、届いたのに処理されなかった。検証、マッピング、欠落フィールドで止まっている。3 つ目、処理されたのに確認が返らなかった。業務文書は作成されたが、確認が戻らず、送信者は届いていないと思い込んで再送した。4 つ目、みんなの意見が食い違う。注文、出荷、在庫のシステムが異なる定義を使っているため、それぞれ単独では正しく見える。

10 分の分類で、どんな問題かも分からずに数千行のログを探す 4 時間を節約できる。そして 1 つのルール。証拠なしに本番インターフェースを再起動してはいけない。再起動は処理中のメッセージの状態を消し去り、追跡できたはずの手がかりを、もう追跡できない手がかりに変えてしまう。

稼働後の問題の多くは、選定時に植え付けられている。誰がマスタデータを所有し、誰が最初に例外を検出するのかを誰も明確にしなかったときだ。そうした判断を見直すなら、API と EDI の選定比較は、見落とした責任を運用合意書に書き込むための有用な参考資料になる。

API/EDI メッセージ追跡：議論する前にメッセージを見つける

私のメッセージ追跡手順は 5 つのステップで、この順序で機能する。ステップ 1、業務文書番号を持って送信者のシステムに行き、送信記録を確認する。送信されたか、どのエンドポイントへか、どんな応答コードが返ってきたか。ステップ 2、自社のゲートウェイの受信記録を確認し、元のメッセージが保存されたことを確認する。ステップ 3、元のメッセージを検証する。形式の問題か、エンコーディングの問題か、業務ルールが阻んでいるのか。ステップ 4、業務処理ログを読み、正確にどこで止まったか、システムエラーで止まったのか手動保留で止まったのかを確認する。ステップ 5、確認記録を確認する。確認は送信されたか、相手は受け入れたか。

直感に反する点はここだ。成功応答は業務上の成功を意味しない。多くのインターフェースは、注文が作成されたとか在庫が正しく差し引かれたと言うためではなく、「受信した」と言うためだけに 200 を返す。かつて 2 つのチームが 2 日間、互いに 200 のログを振りかざしながら、注文がミドルウェアのキューに滞留しているのを見たことがある。応答コードだけではなく、業務文書のステータスで判断すること。応答コードが証明するのは、伝送が壊れなかったことだけだ。業務が正しく行われたことは証明しない。

もう 1 つの典型的な失敗。チームはテスト環境でハッピーパスだけをテストし、再送、順序が入れ替わったメッセージ、空のフィールドを一度もテストしなかった。その 3 つは、稼働開始夜のチェックリストに別々のテストとして載せるべきだ。再送は冪等性をテストし、順序が入れ替わったメッセージは文書の状態遷移をテストし、空のフィールドは、システムが大きな声でエラーを出すか、文書を黙って破棄するかをテストする。黙って破棄されるのが 3 つの中で最悪だ。エラーなら少なくとも誰かに知らせるが、黙って破棄されると、顧客から苦情が来たときに初めて発覚する。

滞留注文：このチェックリストを 1 つずつこなす

注文が滞留したとき、API と EDI の連携トラブル対応は 1 つのルールから始まる。その日をしのぐために手作業で注文を作成してはいけない。手作業の注文は今日の出荷を解決し、明日は重複か欠落の突き合わせ問題を確実に生む。代わりにこのチェックリストをこなし、すべての項目について「送ったと思う」ではなく、ログエントリや文書ステータスといった証拠を求めること。文書番号は送信者のシステムに存在するか。メッセージはゲートウェイに到達したか。検証を通過したか。商品コードとロケーションコードはマッピングされたか。在庫は十分か。文書は手動保留にかかっているか。

根本原因が見つかったら、修復の順序が重要だ。まず出荷を守り、次にデータを直し、責任の議論は最後にする。マッピングの問題なら、正式な変更が通る間、今日の出荷を守るために一時的なマッピングを入れる。在庫不足なら、注文を解放する前に、不足が本物か古い在庫データによるものかを確認する。データの遅れなら突き合わせ、本物の不足なら不足対応プロセスが必要で、注文を無理に通しても誰の得にもならない。1 件を直したら、同じバッチの残りも同じ原因を共有していないか確認する。

手作業の回避策がスケールしない理由を計算してみよう。仮に 1 日に 400 件の注文が滞留し、1 件あたり手作業の確認と対応に 8 分かかるとする。それは 3,200 分、50 時間を超え、2 人が残業しても終わらない。滞留注文がある量を超えたら、正しい対応は人を増やすことではなく、連携とプロセスを一括で直すことだ。人を増やすと、システムの問題が労働力の問題に変わり、ますます高くつくだけだ。

在庫の不一致：3 ステップの突き合わせ

在庫の不一致については、API と EDI の連携トラブル対応は 3 つのステップに集約される。ステップ 1、合計を突き合わせる。WMS の手持数量、相手システムの手持数量、両者が最後に合意した数量を並べ、差の大きさと最初に現れた日付を明示する。ステップ 2、流れを突き合わせる。基準日から今日まで、入荷、出荷、返品、調整を 4 つの別カテゴリーとして比較し、累積差が合計差と等しくなるカテゴリーを見つける。ステップ 3、文書を突き合わせる。差が最大のカテゴリーを取り、数件の取引をサンプリングし、重複、欠落、定義の違いがないか 1 件ずつ確認する。

定義の違いは最も見落とされやすい原因だ。一方は輸送中在庫を手持として数え、他方は数えないかもしれない。誰も間違っていなくても数値は食い違う。両者が同じものを数えていないからだ。突き合わせる前に、手持、利用可能、輸送中の意味を書き出し、両者に合意させること。合意した定義がなければ、突き合わせは各々が正しいと主張して終わる。

最後の運用ルール。インターフェースは稼働開始日で完成しない。最初の 30 日間が最もリスクが高い期間で、相手は知らせずにコードを変更したり、証明書をローテーションしたり、送信頻度を変えたりするかもしれない。私の今のやり方は、最初の 1 か月は毎週の突き合わせに加え、有効期限の 2 週間前に証明書をローテーションすることだ。インターフェースの運用は、こうした地味なルーティンを守ることで勝ち取る。

Lin Xiao（WMS導入コンサルタント）著

英語版からの翻訳。内容に相違がある場合は英語版を優先します。