1.9K Views
June 27, 24
スライド概要
Power Platform 中級編 #0 で登壇した際の資料です。
https://power-dojo.connpass.com/event/319771/
===AIによる要約===
このセッションでは、Power Automateの「設定」とは何か、設定のタブの見方や役割、各種設定項目の説明、セキュリティ保護機能やトリガー条件の制限方法などについて学ぶことができました。フローをより簡潔に作成するコツや、フロー作成上のトラブルシューティング方法も紹介されており、初心者から上級者まで幅広く学ぶことができるセッションでした。
Power Automateの 「設定」について学んでみよう • コルネ • Microsoft MVP for Business Applications
自己紹介 ◼ Name コルネ ◼ Microsoft MVP Business Applications ◼ Who am I ? Power Appsでゲーム作成している人 今年はフュージョン開発の布教を目指したいと思っています ◼ X(Twitter) @koruneko32767 ◼ Blog コルネの進捗や備忘録が記されたなにか ◼ YouTube Korune Ch. コルネ ◼ connpass Japan Power Platform Game Builders 業務改善検討会 Japan Power Platform Dev User Group 2
Agenda • Power Automateの「設定」とは? • セキュリティ • トリガーの条件 • コンカレンシー制御 • 再試行ポリシー • 追跡対象プロパティ 3
「設定」とは?
設定はどこで設定・確認できるか Power Automateの設定は各アクションやトリガーの 「設定」タブから確認・設定することができます。 普段アクションやトリガーの設定値を入力している箇所は 「パラメーター」になります。 「設定」の内容を理解し活用することで、フローをより簡潔に 作成することができるようになったり、できないと思っていたこと も実はできる可能性があったりしますので、是非理解して活 用してみましょう! 公式ドキュメントに全然情報が見当たらないのなんとかなら ないですかね? 5
セキュリティ
実行履歴にセキュリティ情報を表示させないようにする 個人情報や機密情報を取得するような場合、「セキュリティの観点から実行履歴にそれらの情報を表示させたくない!」 というような場合があるかと思います。 そのような場合、「セキュリティで保護された入力」や「セキュリティで保護された出力」が役に立ちます。 7
実行履歴にセキュリティ情報を表示させないようにする 入力、もしくは出力をセキュリティで保護することで実行履歴では、「セキュリティ構成のため、コンテンツは表示されまん。」と 表示されるようになります。 これにより実行履歴から誤って本来権限のない人などに情報が漏洩してしまうことを避けることができます。 例えば、Azure Key Vaultに設定したキー情報などを利用する際に是非利用したい機能ですね。 セキュリティで保護された情報を後続のアクションで利用した場合、そのアクションでも情報が表示されなくなります。 8
トリガーの条件
トリガーの条件を制限する 「特定のファイルが作成・更新されたときだけトリガーしたい」や「特定のステータスとなったもののみトリガーしたい」などのように、 もともとのトリガーとは別に追加でフローが実行される条件を設定したい。というような場合があるかと思います。 上記を行いたい場合、よくトリガーのあとに条件アクションを設定して条件に合わない場合はフローを終了させる。という作成 方法が見られますが、これでは無駄にフローがトリガーされてしまう関係上無駄な実行履歴が溜まってしまい、実行履歴が みにくくなってしまいます。 10
トリガーの条件を制限する トリガーの条件を設定したい場合は、「トリガーの条件」が役に立ちます。 トリガーの条件にはPower Automateの関数式を設定することができます。 つまりトリガーによって得られる結果の他にも現在の時間によってトリガーするかの条件も設定できるということですね。 ここで設定した式の結果が`true`になった場合のみトリガーするようになります。 現在、トリガーの条件に式を入力する際に式の入力補助はありません。 したがってトリガーの条件に式を設定したい場合は、アクションを追加してそこで式を一度作成した後こちらにコピペするのが おすすめです。 こちらに式を入力する際は先頭に`@`を付与します。 11
コンカレンシー制御
ループ処理の実行を高速化する Power Automateで配列を利用しようとすると「Apply to each」というアクションが追加されループ処理となります。 「Apply to each」は基本的に作成者が特に意図せずともフロー側が自動で追加してくれますが、これが追加されることで 困ることは実行速度が遅いということです。 これを改善するための方法の1つとして「コンカレンシー制御」をオンにして並列実行を有効化する方法があります。 参考に 1~500 までの数を含む配列をApply to eachで処理した際のそれぞれの実行時間を記載しておきます。 実行速度 オフ 多重度 1 多重度 20 多重度 50 16秒 16秒 3秒 3秒 ※「コンカレンシー制御」をオンにして並列処理を設定すると処理が並列に実行されることになるので、処理の順番がバラバ ラになってしまう可能性があります。 こちらの設定は処理の実行順序を気にする必要がない場合のみ利用しましょう。 13
フローの同時実行を制限する 「コンカレンシー制御」ですがApply to eachだけでなくトリガーにも設定することが可能です。 トリガーの設定にて例えば「コンカレンシー制御」の多重度を1に設定することで対象のフローは同時に1つまでしか実行され なくなります。 画像のように前のフローが完了するまで他のフローは「Waiting」となり実行が待機されていることがわかります。 この機能は例えば、データを2重に登録させたくない場合などに利用することができますね。 14
再試行ポリシー
アクションが失敗した際にアクションが再実行されるようにする Power Automateにはアクションが失敗した場合に自動的に再実行を試みる機能があります。 こちらの機能は「再試行ポリシー」と呼ばれ、既定では4回再試行するように設定されています。 再試行ポリシーは全部で4種類存在します。 再試行ポリシー 説明 既定値 再試行ポリシーをサポートするコネクタの場合、「既定値」の再試行ポリシーが使用されます。 ほとんどのアクションやトリガーの再試行ポリシーは「指数間隔」ポリシーが利用され、一部のアクションやトリガーでは 「固定間隔」ポリシーが利用されます。 なし 再試行が行われません。 指数間隔 再試行を行う間隔として、ランダムな間隔だけ待機します。このランダムな間隔は、指数関数的に増加する範囲か ら選ばれます。 固定間隔 指定した間隔の待機時間経過後に再試行を実行します。 16
補足: 429エラー(Too Many Requests)に対する再試行ポリシーの設定 各コネクタには独自の調整制限が存在します。 これはリソースの使い過ぎを防ぐために各サービスがリクエスト数が閾値を超えるような過剰な要求が行われた場合にHTTP 状態コード「429 Too Many Requests」を返すような調整制限の設計にしているからです。 429エラーが発生した場合はリクエスト制限が解除されるまで待機した後に再度実行を行うのが一般的です。 呼び出しているAPIによっては”Retry-After”を返してくれるものもあり、こちらがレスポンスとともに返された場合 は、”Retry-After”で指定された時間待機してから新しいリクエストを送信することが推奨されます。 しかしこれをPower Automateで実装しようとした場合は、「Do Until」や「Delay」アクションを組み合わせて独自で429 エラーに対処する必要性があります。 これを独自で各フローに実装するのは大変な労力がかかりますので、手軽にやるのであれば「再試行ポリシー」がおすすめで す。 ただし「再試行ポリシー」ではスロットリング制限がかかった状態でもあるにも関わらずに再度アクションを実行してしまい、更に 制限の時間が延長されてしまう恐れがある点にご留意ください。 参考: コネクタの調整 17
追跡対象プロパティ
変数の値を自己参照する Power Automateにて変数の値を自己参照しようとすると「変数の自己参照はできない。」という旨のエラーが表示されま せす。 これを回避する方法として、別の変数を用意したり、現在の値を作成アクションなどに一時的に格納してその値を参照して 利用したりする方法がとられることがあります。 しかし「追跡対象プロパティ」を活用することで1つの変数で完結することができるようになります。 「追跡対象のプロパティ」は対象のアクションに追加のプロパティを設定する目的で利用されます。 設定を行う際は Key : Value のペアで設定することになり、 Value で関数を設定する際は先頭に「@」をつけて設定しま す。 自分自身の値を取得したい場合は`@action()`関数を利用します。 入力の値を取得したい場合は`@action()?[‘inputs’]`となります。 出力の値を取得したい場合は`@action()?[‘outputs’]`となります。 その後それぞれの未加工結果に従って欲しい値を設定します。 19
変数の値を自己参照する 実際に「変数を初期化する」アクションで設定された変数の値を「変数の設定」アクションで参照するには以下のように設定 します。(今回は変数の初期化で得られた値に 10 加算しています) 変数を初期化する 追跡対象プロパティ self @action()?['inputs']?['variables']?[0]?['value'] 変数の設定 Value add(actions('変数を初期化する')?['trackedProperties']?['self'], 10) 「追跡対象プロパティ」に設定した値は`actions(‘<アクション名>’)?[‘trackedProperties’]`で参照することができます。 今回ですと「追跡対象プロパティ」には”self”というキーを設定しているので上記の式で参照することで”self”の値を取得し ています。 「追跡対象プロパティ」で設定した値は動的な値にはでてこないので注意しましょう。 20
その他の利用例 「追跡プロパティ」にて対象のアクションの結果をフォーマットした結果や対象のアクションが実行された時間を設定する。 などの利用方法が考えられます。 例えば作成アクションで現在時刻を取得して、それをフォーマットした結果を追加のプロパティとして設定する。 のような利用ができます。 21
まとめ Power Automateの設定を理解し活用することで、フローをより簡潔に作成することができるようになったりすることがわかっ てもらえたかな?と思います。 今まではできないと思っていたことが実はできる可能性があったり、このやり方でしかできないと思っていたやり方が実は他のや り方でも実現できたりすることがわかってもらえたら幸いです。 皆さんも是非「設定」プロパティを理解して活用してみましょう! Thank You! 22
イベント開催します! Japan Power Platform Dev User Groupの記念すべき第一回イベントを 7/20(土) 14:00~ 開催します! 今回は以下についてお話します。 • コミュニティの概要説明とこれからに関して • プロ開発者 × 市民開発者 によるフュージョン開発の可能性 について 参加はオンラインとなります。 詳しくは https://jppdevug.connpass.com/event/323665/ をご確認ください。 23