バッチ処理専用のレガシーERPとSaaSをどう連携しますか？

Question

IT Interview Practice · Accepted Answer

ERPのバッチ制限を尊重した、**非同期で復旧可能なデータ交換**を設計します。まず、業務上許容できる遅延と、各データエンティティをどのシステムが所有するかを合意します。1時間ごとのインポートを基盤にリアルタイム完了を約束してはいけません。

## アーキテクチャと責任主体

```text
[SaaS API/events] --> [Durable staging] --> [Mapping adapter]
                                               |
                                         [Batch files]
                                               |
                                         [ERP importer]
                                               |
[Status + reconciliation] <------------- [Result files]
```

販売連携の例では、SaaSが送信された注文要求を所有し、ERPが計上済みの会計伝票を所有します。識別子の対応を明示します。アダプターが状態、単位、項目の意味を変換し、ERP固有の慣習をSaaS側のワークフローへ広げないようにします。

## 各段階を復旧可能にする

送信元のプロトコルが許す場合、受領確認の前に受信した作業を永続化します。ポーリングが必要なら、永続的なチェックポイントと、境界のレコードを失わない重複取得または再実行規則を使います。バッチID、レコードID、スキーマバージョン、件数、チェックサムを保持します。対応していれば完成済みファイルをアトミックに公開し、そうでなければ別の完了マーカーを使います。

各レコードを、保留、送信済み、受け入れ、拒否の状態で追跡します。ファイル転送の成功は、業務レコードの計上完了を意味しません。ERPの結果を解析し、ファイル数だけでなく業務IDと金額を照合します。不正なレコードは理由と責任を持つ担当者を付けて隔離します。

## 結果が曖昧な障害を処理する

ERPがバッチを計上しても確認が失われた場合、無条件の再送は業務伝票を重複させる可能性があります。再試行前に、ERPがサポートする重複キー、または照会・照合機能を使います。どちらもなければ、結果が曖昧なレコードを止めて管理された照合を行います。アダプター側の台帳だけでは、ERPでのexactly-onceの効果は保証できません。

## 処理能力と運用

ピーク量や障害後の復旧も含め、1回のインポート時間枠で滞留分を処理できるか見積もります。バックプレッシャーを適用し、現実的な所要時間と保留状態を利用者に示します。最も古い保留の経過時間、拒否率、照合不一致を監視して通知します。中間ファイルを保護し、アクセスと保存期間の責任を定義します。

## 面接での評価点

整合性の境界と復旧手順を説明します。「キューを追加する」だけでは、意味の変換、部分受け入れ、再試行を重複排除できないERPの問題は解決しません。この設計は即時性と引き換えに互換性を得るため、その遅延を事業側に見えるようにする必要があります。

参考：[Microsoft：腐敗防止層](https://learn.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer)。

アーキテクチャと責任主体

各段階を復旧可能にする

結果が曖昧な障害を処理する

処理能力と運用

面接での評価点

関連する質問