LoginSignup
1
0

Power Automate子フローを利用するシーンがあります。
子フローは、Power Automateのアクションをひとまとめにして実行できる非常に利便性の高いテクニックです。

子フローのメリット

メリットを列挙すると

  • 再利用しやすい - 一度作成した子フローを、複数のフローで再利用できる
  • 保守しやすい - 子フローで実行している処理は、その子フローの更新だけで、その子フローを利用している全てのフローに変更が反映される
  • 可読性 - 結果的に親フロー、子フローがシンプルになるため、フローが見やすい
  • モジュール化 - フローを機能別に分割でき、開発・テストが用意

こういった点が挙げられます。
自動化するための開発の効率化という観点で、子フローの利用は欠かせません。

しかしながら、子フローを使う上で気をつけたい部分があります。
それは再試行ポリシーです。

再試行ポリシー

Power Automate のこの機能を使用して、アクションが失敗した場合に自動的に再試行するポリシーを設定することができます。 既定では、4 回再試行するように設定されていますが、必要に応じて変更できます。

再試行ポリシー Microsoft learn

  • アクションの[設定]タブから再試行ポリシーは設定できます
    image.png

Power Automateのアクションが失敗した際に、既定では4回処理を試みます。
HTTP 要求カスタム コネクタの動作でも一回の処理で確実に成功するわけではありません。

この再試行ポリシーが適用されることにより、成功するまで、トライアンドエラーを実行してくれているという親切な設計ですね。

ですが、この親切な設計によって泥沼にハマることもあるのです・・・💦

失敗する子フローの例

今回は検証用に下記の子フローを作成します。

image.png

  1. 起動時にメール アドレスを受け取る
  2. Outlookでメールを送信
  3. データ操作で、結果をオブジェクトにする(本来的には不要)
  4. JSON の解析(エラーを発生させるポイント)

上記のフローは、活用のシーンが想像できませんが・・・。

実際に作成するときは、子フローを配置するソリューションが必要になります。

ソリューションの解説は、Microsoft learnに譲ります。

子フローの作成

子フローを作成してみましょう。
クラウドフローを選択して、フローを追加します。

スクリーンショット 2024-06-16 103913.png

子フローの作成では、まずフローを手動でトリガーするを選択します。
ここで、Power Automateを書いていきましょう。

スクリーンショット 2024-06-16 104112.png

  1. フローを手動でトリガーするでメールアドレスを受け取ります
  2. (1)で受け取ったアドレスにメールの送信 (V2)します
  3. エラー用にJSONを作成します
  4. JSON の解析でエラーを発生させます
  5. 子フローを終了させます

image.png

ここで(3)の部分で、オブジェクトを作成し、本来的にJSON の解析でstring型と解釈される値をintegerと書き換えることによって、エラーを仕込みます。

Schema
{
    "type": "object",
    "properties": {
        "Datetime": {
            "type": "string"
        },
        "Address": {
            "type": "integer" // 本来はstring
        }
    }
}

接続の編集

子フローを利用する際には、実行のみのユーザーの設定が必要です。
コチラで編集をクリックすると、各コネクタで使用する接続が選択できます。

image.png

子フローとして利用する際、実行専用のユーザーによって提供されましたの設定では、利用できません。
ユーザー独自の接続の指定が求められます。

image.png

言ってしまえば、コチラで指定される名義によって処理が実行されるということですね。
今回のように、メールの送信のみを目的にしている場合、他者名義の接続を指定すれば、接続元のメールアドレスからメールが送信されます。

  1. 新しい接続参照で接続を変えると
    スクリーンショット 2024-06-16 110142.png
  2. 接続参照ソリューションに追加され
    スクリーンショット 2024-06-16 110209.png
    スクリーンショット 2024-06-16 110214.png
  3. メールの送信元を、この接続から実行でき
    スクリーンショット 2024-06-16 110245.png
  4. 実行するユーザーに問わず、この接続からメールが送信される
    image.png

送信元のみ変えたいというときに使える一つのTipsです。
さて、設定が完了したことから、親フローの作成に移ります。

親フローの作成

さて、親フローの作成に移ります。

  1. 作成メールアドレスを指定(ここでは自分のアドレス)
  2. 子フローメールアドレスを渡して実行

といったシナリオで進めてみましょう。

  1. 子フローの呼び出しは、アクションの追加でランタイム組み込みからFlowsを追加
    スクリーンショット 2024-06-16 111014.png
  2. 子フローの実行
    スクリーンショット 2024-06-16 111039.png
  3. 子フローを選択し、必要なパラメーターを指定します
    スクリーンショット 2024-06-16 111050.png

実行すると、大久保さんからメールが来ます。

スクリーンショット 2024-06-16 111144.png

エラーが発生!

子フローは単体でエラーを発生するものになっています。
そうすると、親フローは中々完了せず、再度子フローを試すことになります。

スクリーンショット 2024-06-16 111327.png

ここで再試行ポリシーが適用されているわけですね。

結果的に4回も大久保さんからメールが来てしまいました。

image.png

再試行の履歴から、子フローを複数回呼び出していることがわかります。

スクリーンショット 2024-06-16 111653.png

親フローの実行は10分以上かかることになりました。

image.png

複数のフローが絡んでいると更に複雑に!

子フローのメリットは再利用性です。
例えば同じ処理を、

  • SharePoint Listsに項目が作成されたとき
  • 毎日何時に定期的に

複数のフローから呼び出した場合、さらにエラーの原因がわかりづらくなることにも・・・。
なかなか恐ろしいですね。

しかしながら、自動化のために、同じ自動化するフローを書いて疲弊する・・・は間違いなく本末転倒です。
子フロー活用はその打開策なので、ぜひ使ってみてくださいね。

失敗を未然に防ぐには!!!

持論ですが、失敗を未然に防ぐ方法は、失敗例をあらかじめ蓄積して覚えることだと思います!
Qiitaで失敗談をShareすることによって、同じトラブルに見舞われることを防ぎたい!!と心から思っていますので、ShareまたはLGTMをぜひぜひお願いします🐟

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0