MagentoとSAPの連携で、実際に壊れるのはどこか

MagentoとSAPの連携が壊れるとき、原因が接続レイヤーにあることはほとんどありません。壊れるのは、どの項目についてどちらのシステムが正を持つのか、そして両者が食い違ったときに何が起きるべきなのかを、誰も項目単位で決めていないからです。しかもそれが表面化するのは、たいていセール期間中の午前3時です。

Adobe CommerceとSAPの間でデータを受け渡すこと自体は、すでに解決済みの問題です。標準では解決されないのは、所有権、処理順序、失敗時の扱い、そして突合です。Bridziaは14年にわたりAdobe Commerceに取り組み、小売業のお客様向けに財務・在庫・倉庫の各モジュールをまたぐMagento-SAP連携を構築してきました。そして、ほぼすべてのプロジェクトで同じ失敗パターンが繰り返し現れます。本稿では、その内容と、設計段階で取り除く方法をまとめます。

在庫のずれ：店舗側と倉庫側が一致しなくなる

運用部門から「サイトには在庫4と表示されているが、倉庫にはない」という指摘が入ります。原因は別々の2つですが、1つの不具合として扱われがちです。

1つめは、SAPの在庫数はそのまま販売可能数ではないという点です。プラントや保管場所の非制限在庫は、店舗が顧客に約束してよい数量ではありません。両者の間には、未出荷の受注に対する引当、保留在庫や品質検査中の在庫、輸送中の在庫、そしてサプライチェーン部門が確保している安全在庫が挟まっています。生の数量をそのまま同期すれば、もともと販売対象ではなかった数字を公開することになります。

2つめは、両システムが在庫を減らすタイミングが違うという点です。Adobe Commerceは注文が入った時点で数量を引き当てます。SAPは通常、出荷伝票を転記して出庫が発生した時点で在庫を減らします。それが数時間後になることもあります。この間、両者の数字は正当に食い違っており、素朴な同期処理は正しい引当を古い倉庫側の数字で上書きしてしまいます。

設計で解決する方法は、販売可能数量を明示的な計算式として定義し、サプライチェーン部門と合意したうえでSAP側で算出することです。店舗側は1つの数字を受け取るだけで、独自の計算は一切行いません。差分を高頻度で配信しつつ、全件スナップショットをより長い周期で流し、すべてのメッセージに送信元のタイムスタンプまたは連番を付与して、順序が逆転したメッセージは適用せずに破棄します。そのうえで、販売可能在庫がゼロのときに購入を止めるのか、取り寄せ注文として受けるのかを構築前に決めます。SAPではこの2つはまったく別の受注フローになるからです。

価格：SAPが価格を持ち、店舗が販促を持つ

一般的な構成では、価格の正はSAPが持ち、一方でマーケティング部門はSAPが関知しない販促価格を必要とします。これは、両方のシステムが同じ項目に書き込みを始めた瞬間に破綻し、価格が誰にも説明できない周期で2つの値の間を行き来するようになります。

価格は1つの値ではありません。少なくとも3つです。SAPが持つ基本価格、購入者が目にする販促価格（Magentoのカタログルール、カートルール、階層価格、顧客グループ別価格）、そして受注時に実際に請求される価格です。この3つを分けておけば、競合そのものが消えます。SAPは基本価格の属性にのみ書き込みます。Magentoのルールエンジンはその上にすべてを積み上げ、決して書き戻しません。受注データは請求どおりの明細単価と合計金額を持ち、SAPは条件レコードから再計算するのではなくそれを受け入れます。財務部門が再検証を求める場合は、許容差と、その範囲を外れた明細の処理フローを事前に合意してください。そうしないと、販促が絡む注文がすべて手作業の例外処理になります。

この話の地味な半分は端数処理です。小数精度、丸め方向、税計算の順序（明細単位か伝票単位か）が異なる2つのシステムは、いずれ1セント違う合計金額を生み出します。そして財務モジュールでは、1セントの差で伝票が却下されるには十分です。精度、丸め、課税基準はアーキテクチャ設計の段階で確定させ、その後、考えうる最悪のカートで検証してください。税率の異なる商品にまたがるパーセント割引に、割引済みの送料明細を重ねたものです。

受注連携の欠落：片方のシステムにしか存在しない注文

注文が入り、SAPへの送信が失敗します。分かりやすいほうは簡単です。明確なエラー、通知、再送。危険なのは、成否が判然としないケースです。SAPが伝票をすでに作成した後にリクエストがタイムアウトした場合、注文は向こう側に存在しているのに、店舗側はそれを知りません。そこで何も考えずに再送すれば、受注伝票が2件になり、それが出荷2件と請求2件になり、3週間後に財務部門が手作業でほどくことになります。

ここでは冪等性は任意ではありません。すべての注文に安定した外部参照番号——通常はMagentoの採番ID——を付けて送信し、SAP側は伝票を作成する前にその参照番号を持つ伝票の有無を確認します。すでに存在すれば、2件目を作らずにその伝票番号を返します。こうして再送は構造的に安全になり、だからこそ積極的に再送できるようになります。

同じくらい重要なのは、決済処理のリクエストの中で注文を送信しないことです。注文を確定するのと同じデータベーストランザクションでアウトボックスに書き込み、送信はワーカーに任せます。これで購入手続きはERPの稼働状況に依存しなくなり、すべての注文が明示的な状態を持ちます。送信待ち、送信済み、伝票番号つきで受領確認済み、あるいは理由つきで失敗。「まだSAPに入っていない注文はどれか」に1つのクエリで答えられないなら、それは連携の設計ではなく、ただの願望です。

障害を悪化させる再送処理

再送のロジックは、防いだのとほぼ同じ数の障害を引き起こします。被害の大半は2つのパターンによるものです。1つは即時・固定間隔の再送ループで、キューが詰まった瞬間に短いインタフェース障害を自作自演のサービス停止へと変えます。もう1つは、決して成功しないメッセージを無限に再送するパターンで、処理不能なデータをキューの先頭に居座らせ、その後ろのすべてを止めます。

そうではなく、失敗を分類してください。ネットワークのタイムアウト、ロック競合、一時的なインタフェース停止は再送可能です。ジッターを加えた指数バックオフと、明確な試行回数の上限を設けます。得意先マスタの不在、無効な品目、締め切られた転記期間といった検証エラーは、何度やってもまったく同じように失敗するので、生データと実際のエラーメッセージを保持するデッドレターキューへ振り分け、担当者に通知します。さらにサーキットブレーカーを入れて、明らかに停止しているインタフェースからキューが手を引き、復旧時には制御された速度で流し込むようにします。順序が意味を持つ箇所——多くの場合は全体の一列ではなくエンティティ単位——では順序を保証し、取消が取消対象の注文を追い越すことがないようにします。

マスタデータ：相手側に存在しないレコード

却下される注文の大半は、連携の問題という衣装をまとったマスタデータの問題です。Magentoで作成されたものの、その販売組織向けにSAPで拡張されていない商品。対応する得意先マスタのない顧客。店舗は単品で売っているのに販売単位が12個入りケースになっている単位の不一致。伝票タイプに紐づいていない配送方法。

所有権はシステム単位ではなく、オブジェクト単位で決めてください。実務上は、品目マスタ、基本価格、在庫、顧客の与信・請求上の識別情報はSAPが持ちます。商品説明、画像、カテゴリ、SEO情報、レビュー、売り場づくりはMagentoが持ちます。そして、それを実際に強制します。夜間のERP連携が手書きの商品説明とメタディスクリプションを黙って上書きするのは、この分野で最も士気を削ぐ不具合です。実際の作業成果を静かに破壊し、SEO担当者が気づくのは数週間後だからです。

明示的なマッピングテーブルを、安定した識別子をキーとして持ってください。SKUの文字列一致で済ませてはいけません。SKUは改称も大文字小文字の変更もされるからです。片側にしか存在しないレコードをどう扱うかも決めます。黙って読み飛ばすのか、レポートに載せるのか、販売停止にするのか。ここを誤ったときのコストは会計処理だけにとどまりません。EC Intelligenceで構築するセグメンテーション、カゴ落ちフロー、サイト内パーソナライズは、連携が生成したデータをそのまま受け継ぎます。中途半端に同期された注文は、誤った顧客生涯価値の数字や的外れな施策として再び表に出てきます。

連携頻度：バッチかニアリアルタイムかは、1つの決定ではない

この連携はリアルタイムであるべきかバッチであるべきか、という問いの立て方が間違っています。答えはオブジェクトごとに違うからです。

イベント駆動にするもの

受注、キャンセル、出荷・ステータスの変更、そして回転の速い商品の在庫移動。ここでの遅延コストは、売り越しと問い合わせ件数という形で表れます。

スケジュール実行にするもの

商品マスタの全件、在庫の全件スナップショット、価格表のロード、請求書、クレジットメモ。こうした一括処理をイベントのふりをさせると、ERPがまったく想定していない夜間の時間帯に数万件のメッセージが発生します。

ニアリアルタイムにはコストがあり、それを払うのはERP側のチームです。インタフェースのスループット、テーブルロック、バッチジョブの実行枠という形で支払われます。何かを設計する前に、想定件数を先方と合意してください。数万SKUの価格を深夜に書き換えるキャンペーンは、受注送信と同じ処理能力を奪い合うメッセージの嵐ではなく、制御されたバッチとして届く必要があります。

突合：ほとんどの連携が作らない仕組み

どんな連携も必ずずれます。それを前提として、否定するのではなく検知の仕組みを作ってください。実用的な出発点は、稼働中のカタログ全体について販売可能在庫と基本価格を毎晩比較し、合意した許容差の内側であれば自動補正、外側であれば通知する差分処理です。加えて、両システムの件数と金額を比較し、ERP伝票のない店舗側の注文と、その逆を一覧にする日次の受注チェックを用意します。

出力は、担当者が名指しで決まっている短いレポートでなければなりません。ログファイルをもう1本増やすことではありません。普段は空のレポートだからこそ、空でないときに気づかれます。

負荷がかかったときにだけ現れる失敗

ここまでの内容はすべて通常の取引量では成立し、そして例外なく通常の取引量でしかテストされません。興味深い失敗が現れるのはキャンペーン中です。ワーカーが処理する速さよりキューが積み上がる速さが上回り、在庫更新が一括の価格反映の後ろで待たされます。店舗だけでなく連携そのものを負荷テストし、処理能力が不足したときに何を切り捨てるのかを事前に決めてください。多くの場合、在庫更新の頻度が受注送信に譲ります。

これと表裏一体の規律が、ERPをリクエストの経路から外しておくことです。カート投入、購入手続き、注文確定のいずれにも、自社で制御できないシステムの応答を待つ処理があってはいけません。BridziaはGuardian MalaysiaのAdobe Commerceプラットフォームを8年以上にわたり運用しており、サイト刷新ではパフォーマンスを200%改善し、売上を10%押し上げました。この水準の表示速度は、顧客の動線上で同期的にERPを呼び出す設計とは両立しません。

マーケットプレイスはもう1層の同期を追加します。Shopee、Lazada、TikTok Shopがそれぞれ独自の在庫と受注の状態を持つからです。それを解決するために存在するのが、Bridzia自社開発のマーケットプレイス同期技術WOW Syncです。店舗在庫や倉庫在庫とどう噛み合うのかは、過去のプロジェクト事例で紹介しています。

耐えられるかどうかを実際に決めるもの

項目単位の所有権を、合意して文書化すること。販売可能在庫の計算式は1つだけ、算出場所も1か所。1つの価格項目に書き込むのは1つのシステムだけ。安定した外部参照番号をキーとする冪等な受注送信。再送可能なものと最終的な失敗に分類された再送処理と、誰かが監視するデッドレターキュー。オブジェクトごとに選んだ連携頻度。最初の1か月がひどい結果になってから追加するのではなく、初日から動いている突合処理。

どれも華やかではありませんし、そのすべてがUATの段階よりアーキテクチャ設計の段階で決めるほうが安く済みます。連携は、Adobe Commerce構築のなかで、注文が流れ始めた後にもっとも変更しにくい部分です。

Bridziaはクアラルンプールを拠点に、アジア各地の小売・FMCGブランド向けにAdobe Commerce（Magento）プラットフォームを構築・運用しており、これまでに100件を超えるプロジェクトを手がけてきました。SAP連携を計画中の方、あるいは既存の連携がずれ続ける理由を突き止めたい方は、お問い合わせください。