Power Automate
で子フロー
を利用するシーンがあります。
子フローは、Power Automate
のアクションをひとまとめにして実行できる非常に利便性の高いテクニックです。
子フローのメリット
メリットを列挙すると
- 再利用しやすい - 一度作成した子フローを、複数のフローで再利用できる
- 保守しやすい - 子フローで実行している処理は、その子フローの更新だけで、その子フローを利用している全てのフローに変更が反映される
- 可読性 - 結果的に親フロー、子フローがシンプルになるため、フローが見やすい
- モジュール化 - フローを機能別に分割でき、開発・テストが用意
こういった点が挙げられます。
自動化するための開発の効率化という観点で、子フローの利用は欠かせません。
しかしながら、子フローを使う上で気をつけたい部分があります。
それは再試行ポリシーです。
再試行ポリシー
Power Automate のこの機能を使用して、アクションが失敗した場合に自動的に再試行するポリシーを設定することができます。 既定では、4 回再試行するように設定されていますが、必要に応じて変更できます。
Power Automateのアクションが失敗した際に、既定では4回処理を試みます。
HTTP 要求
やカスタム コネクタ
の動作でも一回の処理で確実に成功するわけではありません。
この再試行ポリシー
が適用されることにより、成功
するまで、トライアンドエラーを実行してくれているという親切な設計ですね。
ですが、この親切な設計によって泥沼にハマることもあるのです・・・💦
失敗する子フローの例
今回は検証用に下記の子フローを作成します。
- 起動時に
メール アドレス
を受け取る -
Outlook
でメールを送信 -
データ操作
で、結果をオブジェクトにする(本来的には不要) -
JSON の解析
(エラーを発生させるポイント)
上記のフローは、活用のシーンが想像できませんが・・・。
実際に作成するときは、子フローを配置するソリューションが必要になります。
ソリューションの解説は、Microsoft learnに譲ります。
子フローの作成
子フロー
を作成してみましょう。
クラウドフロー
を選択して、フロー
を追加します。
子フローの作成
では、まずフローを手動でトリガーする
を選択します。
ここで、Power Automateを書いていきましょう。
-
フローを手動でトリガーする
でメールアドレスを受け取ります - (1)で受け取ったアドレスに
メールの送信 (V2)
します - エラー用に
JSONを作成
します -
JSON の解析
でエラーを発生させます - 子フローを終了させます
ここで(3)の部分で、オブジェクトを作成し、本来的にJSON の解析でstring
型と解釈される値をinteger
と書き換えることによって、エラーを仕込みます。
{
"type": "object",
"properties": {
"Datetime": {
"type": "string"
},
"Address": {
"type": "integer" // 本来はstring
}
}
}
接続の編集
子フロー
を利用する際には、実行のみのユーザー
の設定が必要です。
コチラで編集
をクリックすると、各コネクタで使用する接続が選択できます。
子フローとして利用する際、実行専用のユーザーによって提供されました
の設定では、利用できません。
ユーザー独自の接続の指定が求められます。
言ってしまえば、コチラで指定される名義によって処理が実行される
ということですね。
今回のように、メールの送信
のみを目的にしている場合、他者名義の接続を指定すれば、接続元のメールアドレスからメールが送信されます。
送信元のみ変えたいというときに使える一つのTipsです。
さて、設定が完了したことから、親フロー
の作成に移ります。
親フローの作成
さて、親フロー
の作成に移ります。
-
作成
でメールアドレス
を指定(ここでは自分のアドレス) -
子フロー
にメールアドレス
を渡して実行
といったシナリオで進めてみましょう。
実行すると、大久保さんからメールが来ます。
エラーが発生!
子フロー
は単体でエラーを発生するものになっています。
そうすると、親フロー
は中々完了せず、再度子フロー
を試すことになります。
ここで再試行ポリシーが適用されているわけですね。
結果的に4回も大久保さんからメールが来てしまいました。
再試行の履歴
から、子フローを複数回呼び出していることがわかります。
親フローの実行は10分以上かかることになりました。
複数のフローが絡んでいると更に複雑に!
子フロー
のメリットは再利用性です。
例えば同じ処理を、
SharePoint Listsに項目が作成されたとき
毎日何時に定期的に
複数のフローから呼び出した場合、さらにエラーの原因がわかりづらくなることにも・・・。
なかなか恐ろしいですね。
しかしながら、自動化のために、同じ自動化するフローを書いて疲弊する・・・は間違いなく本末転倒です。
子フロー
活用はその打開策なので、ぜひ使ってみてくださいね。
失敗を未然に防ぐには!!!
持論ですが、失敗を未然に防ぐ方法は、失敗例をあらかじめ蓄積して覚えることだと思います!
Qiitaで失敗談をShareすることによって、同じトラブルに見舞われることを防ぎたい!!と心から思っていますので、ShareまたはLGTMをぜひぜひお願いします🐟