スケジュールトリガーフローで大量処理
kazunii
{{getTime(record.UpdatedTime)}}
はじめに
「定期的にレコードを更新したい」や、「定期的に対象者にメールを送信したい」などを、お客様からの要望をよく聞きます。
しかも対象とするレコード件数が大量な場合、フローの処理は正しく組めていても、ガバナ制限にかかってしまい、動作しない場合もあります。
フローで実装するのではなく、更新情報を外部で計算して、データローダで投入するなど、運用でカバーすることを提案する場合もあります。今回は、フローの「スケジュールフロートリガー」を利用して、大量の更新や処理を行うためのアイディアをお伝えします。
スケジュールトリガーフローについて
私の、スケジュールトリガーのイメージは、「定期的にフローを実行する」です。
定期的にフローを実行させることができるので、設定の幅が広がりますね。
同じような機能で、レコードトリガーの「スケジュール済みパス」が、ありますが、その動作には違いがありますので、この後に軽く触れようと思います。
スケジュールトリガーフローの実行頻度
フローが最初に実行される日時（開始日と開始時刻）を指定します。その日時を基に、次回以降にフローが実行されるスケジュールが決まります。
# | 頻度 | 説明 |
1 | １回のみ | 開始日時の１回だけ実行されます 定期的には実行されない |
2 | 毎日 | 毎日実行されます 最初に実行された開始時刻と、同じ時刻に実行されます |
3 | 毎週 | 毎週実行されます 最初に実行された日時と同じ曜日と、同じ時刻に実行されます |
「スケジュールトリガーフロー」と「スケジュール済みパス」の違い
どちらの機能にも共通する動作は、「レコードの保存と同時に処理は実行されずに、今後実行される」と言う点です。２つの機能の動作の大きな違いとしては、「処理が実行されるレコードの決め方」に、違いがあります。
「スケジュール済みパス」は、レコードが保存された時に、後日処理の実行が必要な場合は、実行予定がスケジュールされます。
「スケジュールトリガーフロー」は、定期的に処理が必要なレコードを検索し、ヒットしたレコードに対して処理を実行します。
どちらで実装した方が良いのかは、いつも悩むところです。
お客様の要件や、ガバナ制限との掛け合わせで、どちらにするのかを決めるのが良いと思います。
大量にデータを処理するには
スケジュールトリガーフローを利用して、大量のデータ処理を行う方法をお伝えします。
対象レコードの取得方法
対象のレコードを取得する方法は２つあります。# | レコードの取得方法 |
1 | 開始時に取得 開始条件の中で、処理対象のレコードを検索するオブジェクトと、検索条件を指定します。  |
2 | フローの中で取得 フロー要素の「レコードを取得」を利用して、処理対象のレコードを検索します。  |
理由としては、処理対象のレコードとして抽出されたレコードを、１件ずつ処理できるからです。
まず「２．フローの中で取得」で、取得したレコードはコレクション変数として取り扱うので、ループを利用してコレクションからレコードを取り出しながら、処理を行う必要があります。
一方、「１．開始時に取得」と、取得したレコードが複数あっても、フローの中では１件ずつ処理を行えます。
取得したレコードの情報が、グローバル変数「$Record」に格納され、１件ずつ処理が行われます。
また、その処理が終わると、次のレコードの情報がグローバル変数「$Record」にセットされ、ループを利用しなくても複数件のレコードの処理の実行を行うことが可能です。
さらに、「１．開始時に取得」と、１レコードずつにそれぞれに処理が行われるため、大量レコードの処理を行っても、一部のガバナ制限を回避することができます。
ただし、たくさんあるガバナ制限の一部を回避するだけですので、想定されるレコード件数で入念なテストを行う必要はあると思います。
ご参考：フローの機能に関する考慮事項（外部サイト）
試しに、「１．開始時に取得」の方法で、各レコードの値を基にして、それぞれ異なる値を更新するフローを作って、１万件程度のレコード更新を行ってみましたが、エラーも出ずに、レコードが更新されました。
おわりに
スケジュールフロートリガーは、有効化すると「スケジュール済みジョブ」に登録されます。
一方、レコードトリガーフローの「スケジュール済みパス」は、「時間ベースのワークフロー」に登録されて実行されます。
それぞののスケジュールにも、ガバナ制限が設けられているので実装するにあたっては、入念な調査を行い、どの方法で実装するのかを判断するをオススメします。（入念なテストもお忘れなく♪）
皆さまの、何かの気付きになれば幸いです。
ご活用ください。