目的

システム開発において、結構な頻度で定期的に処理する必要が出てくると思います。
例えば、メール配信、他のシステムとのデータの同期、日時集計処理、データアーカイブなど用途も様々です。
OutSystemsにおいてこのようなバッチ処理を定期的に実行する実装例挙げます。

環境

OutSystems O11
Service Studio Version 11.54.37

OutSystemsでのバッチ処理

主にTimerという機能を用いて実装します。

Timer

タイマーは、スケジュールされた時間に定期的にロジックを実行できるようにするOutSystemsツールです。
ServiceStudioの右側のProcessタブで作成管理することができます。
TimerからはServerActionを呼び出し実行することができます。
Timerは日次、月次の定期的に実行をスケジュールすることができます。そのほかにもService手動での実行や、UIやAPIを経由しての実行ができます。

Timer実装の留意点

Timerの制限事項

タイムアウト時間:20分
エラー時の再実行数:3回
1サーバ当たりの並列実行数:3

Timerのタイムアウト対策

バッチ処理は一般的に長時間リソースを占有する負荷のかかる処理をシステムのオフピークに実施します。ここで気になるのはタイムアウト時間です。すべての処理をタイムアウト時間内で完了させることは保証できません。
公式のTimerのベストプラクティスとして、一度の処理はタイムアウト時間内で正常させ、Timer内でTimerを再実行させる方法があります。
1度のTimer実行で処理が終わらないことを考慮して、Timerを安全に終了し再実行するために処理終了時間を設定します。処理のループ内で処理終了時間を経過しているかを判定し、経過している場合は処理を中断しTimerの再実行をスケジュールします。

再実行のための進捗管理

上記の通りTimerを再実行することにより対象のすべてのデータの処理完了を担保します。そのため、処理が完了しているか明確な条件を定義する必要があります。

処理のループ

一度の処理のループは進捗の管理をしやすい単位を考慮して決定します。さらに1度のループでTimerのタイムアウト時間を超過しないように、十分処理時間の小さな単位をループさせる必要があります。

例外処理

例外が発生した場合、データをロールバックする必要があるのか、今までの処理分はコミットするのかを判断し処理を実装します。また、例外によるTimerの再実行をするのか、そのまま処理を終了するのかを判断し処理を決定します。例外が発生した旨と調査のための情報をログに残したり、システム管理者や運用担当者にメールを送るなどの処理を入れる必要があるかもしれません。

ログ

バッチ処理の失敗時の調査のために、最低限失敗した箇所、失敗した理由をログに残しておく必要があります。ただし、バッチ処理は大量のデータを処理する必要があるため、レコード単位で成功したことをログに残してしまうとログに大量のデータがたまってしまい、問題になることがあります。どのようなログがあれば対応が可能かをよく検討する必要があります。

実装例