2 者間でデータを共有するためのバッチ (オフライン) プロセスを設計するためのベスト プラクティスを説明している書籍やドキュメントはありますか?
春のバッチ サイトで役立つ情報をいくつか見つけましたが、それは非常に低レベルです: バッチ処理の戦略とバッチの原則のガイドライン.
バッチには多くの考慮事項があります。次に例を示します。
- データ転送方法 (例: ファイル)
- 両者間の制御プロトコル
- エラー処理
- ファイルの命名規則 (転送にファイルを使用する場合)
- 両当事者間の締め切り時間を同期する
- 等
設計が現場のベスト プラクティスに従っていることを確認する、信頼できるドキュメントまたはチェックリストがあればよいでしょう。
アップデート：
出くわしたら、このセクションに回答を追加します。
一般的なバッチ/オフライン処理情報
このセクションは、@ user1813068 の回答から抜粋したものです。
このリンクとこのリンクで、パートナー間の統合とデータ同期のアプローチを説明するいくつかのアーキテクチャ設計パターンを見つけることができます。
このウィキペディアのページには、アーキテクチャ パターンの高レベルの概要も記載されており、データ統合のパターンが含まれています:アーキテクチャ パターン.
本Data Integration Blueprint and Modelingも非常に優れています。
データファイル
このセクションの内容のほとんどはここから来ています: source
フラット ファイル交換にヘッダーとフッターを使用することは、ベスト プラクティスと見なされます。フラット ファイルはヘッダーとフッターなしで交換でき、ファイルの名前はヘッダーと同じ情報の一部を概説することができます。区切りファイルを使用する場合、フィールド リスト ヘッダーは常に必要です。
ヘッダー
システム間でデータを交換する場合、送信されるデータの種類を受信側が正確に知ることが非常に重要です。これを確実にする 1 つの方法は、データの内容とその処理方法に関する適切な情報を含むヘッダー行を提供することです。
フラット ファイルを操作する場合、ファイル名自体を使用して、ファイルの内容を受信側に通知することもできます。ただし、ヘッダー行は、使用可能なすべてのオプションをより適切にサポートします。
API を使用する場合、これらのヘッダー フィールドは同様の方法で提供できます。実装は、API サービスの開発者によって決定されます。
ヘッダーが含まれている場合、ヘッダーは単一のデータ セットで構成され、常にファイルの最初のデータである必要があります。
フッター
ファイルベースのフォーマットを使用する場合、処理するデータが残っていないことを示すフッターが提供される場合があります。
処理時に、フッター行の後にあるデータは無視する必要があります。また、データを作成する場合、フッター行以降のデータは無視されることに注意してください。
データ形式
区切りファイル
事実上の業界標準は区切りファイルです。
カンマ区切り (CSV、またはカンマ区切り値) ファイルは通常、二重引用符 (") を使用してデータをカプセル化する必要があります。二重引用符は、バックスラッシュ () または二重二重引用符 ("") を使用してエスケープする必要があります。 to the inconsistencies in CSV implementation, it is recommended to use tabs as a delimiter, with no encapsulation. この場合、タブ文字をデータから削除する必要があります. 通常、区切りファイルは XML ファイルの処理が高速です.
XML ファイル
業界には、XML ファイルを好む人がいます。XML はネストされたデータをサポートしているため、より明確な情報表現が可能です。多くの企業は、この形式のサポートを制限しているか、まったくサポートしていないため、お勧めしません。
エンコーディング
UTF-8 エンコーディング
すべてのシステム間で最大限の互換性を確保するために、すべてのデータを UTF-8 でエンコードする必要があります。
日時
混乱を避けるために、すべての日付と時刻のフィールドに UTC 時刻を使用することをお勧めします。
その他のベスト プラクティス: EDI スケジューリングとファイル転送