ACSのデータ連携では、送受信の方法だけでなく、項目の意味、照合、更新、失敗時の再処理を設計します。APIなら常に即時で正確、差分なら常に最適というわけではありません。必要な更新時点とデータ量、契約、既存システムに合わせて選びましょう。
連携の前に正本とデータ定義を決める
顧客や注文のどちらをどの単位で送るか、どのシステムの値を正本とするかを決めます。同名の金額でも税込・税別、取消前後、期間等が異なる場合があります。識別子、型、日時、文字コード、空欄、削除、再送の扱いを仕様に残します。特定のECやCRMが標準で接続済みとは考えず、必要な連携や自社実装の範囲を確認してください。
Transfer fileとLoad fileを分ける
Transfer fileはファイルの取得・送信、存在確認、一覧等を扱います。Load fileは構造を定義して一時的にデータを読み込むもので、それだけではデータベースへの恒久的な更新になりません。後続の照合や更新処理を含めて設計します。サンプルファイルは構造設定に使われ、そのサンプル自体を取り込むものではない点にも注意します。
ファイルの正常と異常を定義する
Load fileではCSV等の平坦な構造を扱い、列、区切り、型、日時、数値、空値、エラー処理等を確認します。列の不一致や欠落、型違いを、無条件の既定値で埋めてよいとは限りません。正常、重複、空ファイル、壊れた値の例で試し、取込み、拒否、更新の件数を照合してください。ファイルが転送できたことを、データ更新の成功と同じに扱わないようにします。
APIの用途と認証・契約を確認する
ACSのAPIはRESTとJSONを使い、プロフィール、購読、独自リソース、トランザクション、ワークフロー等の連携を案内しています。Adobe側の利用設定と認証、権限、契約上の規模の制約を確認します。要求を受け付けた応答と、後続処理が完了したことは区別してください。秘密情報をコードや共有資料へ直書きせず、開発担当者が適切に管理します。
全件・差分と再実行の条件を合わせる
差分には、前回のどこまでを処理済みとするか、遅れて届く更新、削除、同じ情報の再送をどう扱うかという設計が必要です。全件方式も、件数や更新方法によっては運用しやすい場合があります。失敗したファイルを再送したときに二重登録や送信が起きないか、部分成功をどう検知するかを試します。方式名だけで採用せず、回復できる手順まで決めます。
保存と監視を運用へ組み込む
転送後の元ファイル削除、ACS内の履歴保存、SFTPの容量等を確認します。Transfer fileには履歴のサイズや件数を管理する設定がありますが、契約全体の容量管理を不要にするものではありません。処理の開始・終了、受信・拒否・更新の件数、認証や転送の失敗を記録し、通知先と再実行の判断を決めてください。出力先のアクセスと保持期間も管理します。
連携工程ごとの確認
| 工程 | 役割 | 検証 |
|---|---|---|
| 転送 | ファイルの送受信 | 存在、件数、接続、保存 |
| 読込み | 構造に沿う一時データ | 列、型、空値、拒否 |
| 照合と更新 | 既存データへ反映 | 識別、重複、更新件数 |
| API | 対応機能の呼出し | 認証、応答、後続の結果 |
| 運用 | 回復と監視 | 再実行、容量、通知、保持 |
導入前の確認事項
- 項目・識別子・正本・更新を定義した
- 転送、一時読込み、恒久更新を分けた
- 異常データと再実行を試した
- 認証・契約・保存・監視を確認した
公式資料・関連記事
関連記事：ACSのデータモデル｜顧客・購読とリソース拡張、ACSのWorkflow｜設計・実行と停止時の確認、ACSのTransactional Messaging｜種類と設計。
運用設計や確認項目の整理は、現在の業務と対象URLを添えて株式会社AOへご相談ください。
公式資料の確認日：2026年11月2日。記入例や手順は編集上の提案で、導入成果を保証するものではありません。
コメント