API連携の見積もりを依頼する前に、業務データが作成されてから最終更新されるまでの流れを整理しましょう。「WebサイトとERPをつなぐ」だけでは、対象データ、方向、失敗時の対応が決まりません。
接続先と管理責任を確認する
各システムの名称、契約プラン、API資料、業務担当者を一覧にします。必要なAPIが契約範囲に含まれるか、検証環境を用意できるかも確認してください。一般の依頼資料にパスワードや本番トークンを記載せず、実装時に管理されたアクセス方法を決めます。
商品在庫はERP、注文の初回受付はECなど、データの正本を決めます。項目ごとに管理元が違う場合も、そのルールを明記します。双方向連携では、競合時の優先順位がないと正しい更新を上書きする可能性があります。
項目対応表と具体例を作る
受注連携の例なら、外部注文ID、明細ID、商品コード、数量、単位、通貨、状態、日時を対応させます。必須項目、許容値、文字数、空欄の意味も必要です。「未確認」と「値を削除する指示」は区別します。
正常な注文、一部キャンセル、未登録の商品コードを含む匿名化データを用意します。項目名だけでは見えない前提が分かります。注文を修正した後も、同じ取引を識別できるルールにしましょう。
同期のタイミングを決める
- どの業務イベントで送信するか。
- 受信側が許容できる遅延はどれくらいか。
- 変更・キャンセル・削除をどう表すか。
- 更新が順番通りに届かない場合にどうするか。
- 利用制限や定期メンテナンスがあるか。
配信仕様や制限は、接続先の最新資料で確認します。「すぐに反映」ではなく、測定できる条件と例外の通知方法を決めると検収がしやすくなります。
復旧も開発範囲に含める
自動再試行できるエラーと、人の修正が必要なエラーを分けます。同じ処理を再送しても注文が増えないよう、元データの識別子と重複判定のルールを持たせます。
運用担当者が失敗したデータ、理由、安全な再実行方法を確認できるようにします。ログは識別子と状態を中心にし、不要な機密データの複製を避けます。通知を受けて対応する担当も指定します。
検収シナリオの例
- 正常データが正しい宛先へ一度だけ登録される。
- 必須項目の不足が確認可能なエラーになる。
- 一時停止後も注文を重複させずに復旧する。
- 後から届くキャンセルが合意したルールで反映される。
- 照合結果から欠落や不一致を発見できる。