APIを選ぶ前にビジネスイベントを記述する
B2Bのチェックアウトには、合意済み価格、発注書、承認限度額、支払条件が関わる場合があります。まず1つのワークフローから始め、関係するシステムを明確にします。例えば、承認済みのバイヤーが注文を行い、財務システムがそれを記録し、倉庫がフルフィルメントのステータスを顧客ポータルに返す、といった流れです。
この記事は計画の一例を説明するものであり、完了したクライアントプロジェクトではありません。同じ準備はCRM、決済、予約の統合にも当てはまります。イベント、信頼できるデータ、そして成功した引き継ぎが何を意味するのかを特定してください。
統合の要件概要を準備する
- システムとアクセス: プラットフォーム、アカウントプラン、APIバージョン、ドキュメント、サンドボックスを明確にします。意図したエンドポイントと権限が利用可能であることを確認します。
- データの所有権: 顧客のアイデンティティ、価格、在庫、注文ステータス、支払状態をどのシステムが所有するかを決定します。個人データを除去した代表的なレコードを提供します。
- マッピング: 共有される識別子、必須フィールド、通貨、税処理、タイムゾーンを定義します。一致しない製品や顧客をどう扱うべきかを記録します。
- 例外: キャンセル、部分的なフルフィルメント、支払失敗、価格変更、ダウンストリームシステムの利用不可を含めます。
- 運用: 誰が失敗をレビューし、転送を再実行でき、修正を承認するかを決定します。
通知は繰り返されたり遅れて届いたりする可能性があると想定する
Webhookの処理には、明確な再試行と重複処理のポリシーが必要です。具体的なプラットフォームの一例として、Stripeは署名検証、重複イベント、非同期処理について次のドキュメントで説明しています。 Webhookガイド。支払通知は認証され、プロバイダーの契約に従って処理されるべきです。他のプラットフォームには独自の配信と再試行のルールがあります。個別に確認してください。
受け入れの例: サンドボックス注文を送信し、そのイベントを2回配信してから、受信システムを一時的に無効にします。注文が1回だけ作成され、失敗した転送が可視化され、リプレイで復旧できることを検証してください。また、顧客が他社の価格設定や注文を閲覧できないことも確認してください。
最初のリリースに何を含めるかを合意する
現実的な最初のスコープは、1つの注文タイプ、1つの倉庫、定義された一連の状態をサポートするものかもしれません。追加の調査が必要な場合は、過去データの移行、サプライヤーのオンボーディング、異例の価格設定ルールを分離します。初期段階で何を手動とするか、そしてその統合が作業を削減できるかどうかをチームがどのように測定するかを合意します。
引き継ぎには、フィールドマッピング、セットアップ手順、モニタリング、再実行手順、そしてプラットフォームアップグレードの所有者の明確化を含めるべきです。保守条件は、システムと合意されたエンゲージメントによって異なります。詳しくは次をご覧ください。 API開発と統合, ワークフロー自動化 と eコマース開発.
