スクラッチ開発からパッケージソフト、クラウドサービスと企業内システムの主流は変われど、変わらず残り続けるのが他システムとのインターフェースです。
そして、どこまでリアルタイム連携が主流になっても残るのが、バッチインターフェースです。
コンサルティングファームでは、SAPやSalesforceの導入スキルを持つコンサルタントは募集していても、インターフェースやバッチの導入スキルを持つメンバーの募集はあまり見かけません。しかしファームがプライムコントラクタとしてプロジェクトを推進する場合、誰かがその領域を担当することが必要になります。
本記事では、バッチインターフェース設計の概要や注意点を紹介します。
インターフェースチームを担当することになったコンサルタントが、協力会社のエンジニアの支援を得つつもプロジェクトを推進できるよう、参考になればと思います。
バッチ処理とは
バッチ処理とは、一定量のデータをまとめて処理することです。
対義語はリアルタイム処理で、まとめてではなく都度処理を行うものを指します。
バッチ処理は、必ずしもバッチインターフェースを指すわけではありません。システム内での集計処理をまとめて行う場合はバッチ処理ですが、インターフェースではありません。集計したデータをデータウェアハウスなどの他システムに送信する場合は、インターフェースになります。
バッチインターフェース設計の概要
大きくはバッチ設計とインターフェース設計に分かれます。
インターフェース設計については、別記事を参照ください。
バッチ設計の主な項目は以下の通りです。
- 実行タイミング
- 実行制御、ジョブ制御
- トランザクション
- リカバリー
実行タイミング
バッチ処理の実行タイミングは大きく2つです。夜間や休日などユーザがシステムを利用しないタイミングと、日中含めた常時タイミングです。
大量データを扱うバッチ処理はサーバーに負荷を与えるため、ユーザの画面操作レスポンス等に影響を与える可能性があります。こうした影響を避けるには、夜間や休日に、オンライン停止や締め処理を行った後にバッチ処理を起動します。
それでは業務に支障をきたす場合は、日中のオンライン稼働中に30分などサイクルを決めてバッチ処理を行います。5分など短サイクルの処理が必要になる場合は、リアルタイム処理とどちらの設計が適切か検討を行います。
実行制御、ジョブ制御
バッチ処理の起動方法は、トリガー起動と時間起動の2種類があります。
トリガー起動とは、前提となる処理が完了したことや、受信ファイルの到着をトリガーに処理を開始するものです。
時間起動とは毎日2時や月初何日の3時など、決まった時間に処理を開始するものです。数が多く複雑な管理には、ジョブスケジューラを用います（ジョブ管理ツール比較記事はこちら）。
トランザクション
バッチ処理は複数のトランザクションを扱うため、適切なコミット単位を設定する必要があります。コミット単位を数万件にまとめると処理は速くなる一方で、処理が途中で異常終了した場合に、ロールバックされる件数も増えてしまいます。コミット単位を細かくすると、処理速度は落ちます。
また、エラーログの細かな出力も処理速度には影響を与えますが、次項のリカバリーにも関連するため、必要な情報はエラーログとして出力する考慮は必要です。
エラー処理設計の参考記事→運用を困らせないインターフェースのエラー処理とリカバリ設計
リカバリー
バッチ処理でエラーが発生すると、エラーデータを修正して再実行を行います。考慮したいポイントとしては、正常に処理できたデータは救う（エラーが発生したデータのみを再実行対象とする）こと、リカバリ運用を極力シンプルにすることです。
自システムのマスタデータ整備が問題でエラーが発生している場合は、マスタ更新後にエラーデータのみ再実行することが可能です。しかし、送信元システムにデータ修正の依頼が必要な場合は、エラー修正データのみの再送が可能かを確認が必要です。該当データのみの再送が可能であればよいですが、難しい場合は双方の運用の手間を考慮し、正常に処理されるデータも含めて、送信元から再送してもらうほうがシンプルな業務運用になります。