はじめに
今回は、実際に私がフローを作成したときに稼働を止めないために行った応急処置的なやり方の紹介となります🙇♂️
現状、SalesforceはIT経験が少なくても扱える良ツールではあるものの、ガバナ制限のチェックだったりはユーザ側で考えておかないと後々面倒なことになるのです。
本記事は、私同様に初歩的なミスをしたアドミンや、駆け出しアドミンに向けた内容となりますが、何かしら助けになれば幸いです。
フローのガバナ制限とは？
ユーザみんなが使えるように、サーバ側リソースが独占されないようにしている利用制限のことです！
制限は使用する要素や実行時間などが対象で、これはトランザクション単位で行われており、フロー上で制限対象となるような要素を組み込んだループ処理を実行した場合、実行数が多かったり時間がかかる場合は大体エラーで終わってしまいます。
※実行時間は10秒ほどが限界です。
また、トランザクションがガバナ制限に引っかかると、障害コネクタパスが定義されていてもトランザクション全体をロールバックします。
詳しくは下記の公式ヘルプをご確認ください！
ガバナ制限はトランザクション単位
こちらも下記の公式ヘルプからご確認ください！
もし、トランザクションという言葉の意味がよくわからない場合はお手数ですがググっていただくか、下記記事を読んでイメージをつけていただければ！
処置例
前提
それでは本題に入ります。
例えば、下記のimg1のようなフローがあったとします。
念のため説明です！
上記のフローでは、まず「SaaSアカウントの取得」というレコード取得の要素を実行しています。取得すると110個のレコードが入ったコレクションのため、ループは110回、つまり中のレコード取得は110回実行となります。
これを実行すると、img2、3のようなエラーが表示されます。
img3のエラーは、ガバナ制限によるもので、100回を超えるSOQLのクエリ実行がある場合に発生します、、、
もし、これが納期直前に考慮漏れとして発覚した場合、考慮した上で処理を変更するのってしんどくないですか？
大規模なデータ処理だった場合とかもう、、、
ってことで、この窮地を脱するために、画面要素を使った一時停止でトランザクションを分ける案が活きてくると思うんです！！！
★公式ヘルプにも書いてるんですがね、、、
対応
それではどのように変更したのかです。
img4をご覧ください。
ループのレコード取得の要素以降に、割り当て要素、決定要素、画面要素を追加したのがわかるかと思います。
こうすることで、脳筋プレイとなりますが、ループ単位でのSOQLクエリの実行回数以下で、トランザクションを分けられて無事ガバナ制限を回避できます。今回は60回ループで切るように設定しています。
img5、6をご覧ください。
このように問題なく実行が完了したことがわかります。
もし、画面要素を使う場合は、img5のように状況を表示することで利用者側への多少の精神負荷を減少できると思います。
※それでもだるいことに変わりないが、、、
さいごに
今回紹介した方法は、あくまで応急処置的なものであり、今後も格納データの規模や、処理対象となるデータ量が拡大していくようなフローの場合、手間が増えていく一方のため、恒久的な解決策にはなりません。
しかし、その一方でデータ量が特別多くなく、今後も増えることはない場合は今回の対応以上のことは必要ないと思います。
そのため、他に良い解決策が見つかり次第、対応をしたほうがいいです。
何かしら助けになれましたら幸いです🙇♂️