こんにちは。システムソリューション営業本部の吾妻です。


Power Automateにおいて、大量データを対象にアクションを実行するようなクラウドフローを作成すると、「いつまで経ってもクラウドフローの実行が完了しない」ことが時々あります。

クラウドフローの中に定義したアクションからデータストアや外部サービスへの、過剰なリクエスト送信が原因で生じることが多いですが、それ以外にもいくつかの要因がいくつかあるようです。

そこで今回の記事では、クラウドフローの実行時間が延びる事象の原因について、ライセンス体系やフロー運用設計の観点からご紹介していきたいと思います。



あくまでも現時点での状況について公式資料をもとにまとめたものであり、今後サービスの内容は変更される可能性があります。

詳細は、ライセンスガイドなどの公式資料をご確認ください。

市民開発のPower Automateでよく見かける「429」エラーとは｜QESブログ
こんにちは。システムソリューション営業本部の吾妻です。 Power Automateクラウドフローを...
 

フローの処理が終わらない理由

クラウドフローの処理が「実行中」のまま成功も失敗もせずに残り続ける事象は、Power Platformのライセンス上の制限事項に抵触したことに対するペナルティのようなものです。「アクション要求数の制限（Power Platform 要求の制限）」などの制限によってクラウドフローの処理がいつまでも完了しないと、今度は「続けてスロットリングされたフロー」の制限によって、14日後にクラウドフローが無効化されます。つまり、クラウドフローを利用した処理を確実に実行完了させるためには、制限に抵触することがないように実装するほかないということになります。

各種の制限

クラウドフローはサービス間連携の機能なので、抵触し得る制限については サービスごと に把握しておく必要があります。

例えば、Dataverseテーブルに対して行を追加するようなクラウドフローであれば、①Power Automateの制限、②Dataverseコネクタの制限、③Dataverseの制限の3つを確認します。



以下の表に、主要な制限についてまとめます（せっかくなのでPower Appsなどについても載せておきます）。

Power Platform 要求の制限

パフォーマンスプロファイル判定

先程の表にある「Power Platform 要求の制限」については、ユーザーまたはフローライセンスをもとに決められている「パフォーマンスプロファイル」によって閾値が変わります。

以下の表に、パフォーマンスプロファイルおよび主要なライセンス、閾値の対応関係についてまとめます。24時間ごとの制限の閾値は、上段が移行期間の制限のものを、下段が実際の制限のものを示します。

ユーザー判定

Power Platform 要求の制限はユーザーまたはフローライセンスに依存することが分かりましたが、この時、ユーザーとは誰を指すのかについてもまとめておきます。

• フローに フローごとのライセンス がある場合
  
  • 常にフローごとの制限が適用される
  • 作成者/所有者/呼び出し元のユーザーの制限は無関係
    
    
• 自動化フローおよびスケジュールされたフロー
  
  • 常にフローの作成者/所有者の制限が適用される
  • 呼び出し元のユーザー/フローを開始したユーザーの制限は無関係
  • ソリューション内のフローであればAPI経由でフローの所有者を変更でき、所有者を変更すると、新しい所有者の制限が適用される
    
    
  • 自動化/スケジュールされたフローを別のユーザーと共有した場合は、共有されたユーザーがトリガーしても元の所有者の制限が適用される
    • ただし、共有されたユーザーがそのフローを利用して独自の新しいフローを作成すると、新しいユーザーの制限が適用される
      
      
• インスタント フロー
  
  • 呼び出し元のユーザーの制限が適用される
    
    
• フローの所有者がサービスプリンシパルの場合
  
  • ライセンスのないユーザー制限が適用される
    
    
• 親子フロー
  
  • 子フローは親フローの制限が適用される
  • 親フローが自動化されたフローの場合
    • 子フローには親フローの作成者/所有者の制限が適用される
      
      
  • 親フローが手動フローの場合
    • 子フローには親フローの呼び出し元ユーザーの制限が適用される
      
      
  • 子フローにフローごとのライセンスがある場合
    • 親フローの制限ではなく、フローごとの制限が適用される
      
      
  • 親フローにフローごとのライセンスがある場合
    • 親フローとすべての子フローに、フローごとの制限が適用される
      
      
• フローにプロセス ライセンスがある場合
  • フロー、フローのすべての子フロー、およびフローのコンテキスト内のフローに、プロセスプランの制限が適用される

サービス保護のAPI制限

現状の確認方法

現在消費しているリクエスト数は、Dataverse Web APIを呼び出した際の応答に含まれる、以下のヘッダーの値を確認します。Power Automateクラウドフローで、「行を一覧にする」などのアクションを利用している場合は、クラウドフローの実行履歴から出力（「クリックしてダウンロードします」リンク）を開くことで、値を見ることができます。

Dataverse検索のリクエスト

また、Dataverseにおける「サービス保護のAPI制限」では、Dataverseテーブルのレコードに対するCRUD処理に加えて、割り当てや共有も制限対象のAPI要求と見なされる一方で、Dataverse検索のAPI要求は対象外であり、別の制限（ユーザーごとに1秒あたり1リクエスト、各組織のリクエストは1分あたり150件）が適用されます。

解決策

ここまでご紹介してきたように、Power Automateクラウドフローの実行時間が延びるという結果を生じさせる可能性のある要因はいくつかあるため、それぞれの制限ごとに、設計の際に考慮しておくべき解決策をご説明します。

①Power Automateの制限

クラウドフローに配置したアクションからのアクセスに対する制約となる、Power Platform要求の制限では、5分ごと、1日ごとの枠の中でリクエスト数や同時接続数がチェックされるので、始業直後などの特定の時間帯や月末などの特定の日にアクセスを集中させないようにします。リアルタイム処理でどうしてもピークとそれ以外のリクエスト数に開きが出るようであれば、バッチ処理に変えることを検討します。

また、市民開発でフロー開発を行っているうちに、フローの所有者になるのが特定のユーザーに固定化されているようであれば、ユーザーの偏りを減らすために、サービスアカウントを用意して所有者を切り替えたり、フローライセンスを購入することも検討します。

②Dataverseコネクタの制限

コネクタごとの制限は、接続ごとに掛けられるので、フローの所有者を変更したり、実行専用ユーザーを設定したりすることによって、認証に使用されるユーザーを分けることを検討します。

③Dataverseの制限

Dataverseアクセスに対する制約となる、サービス保護のAPI制限でも、Power Platform要求の制限と同様に、特定の時間帯にリクエストが集中しないように設計する必要があります。また、リクエスト数を減らそうとしてバッチ要求を実装すると、今度は実行時間の制限に抵触する可能性があるため、そのトレードオフを運用の中で調整する必要はあるかもしれません。


いずれの制限についても、PoCの段階や、運用初期のシステムだとなかなか問題が顕在化しないことも多いので、これらの対策をシステムに組み込んでおくことを目指すことも大切ですが、どちらかというと、制限に抵触して想定通りに動かなくなったことを検知するための運用・監視体制や、即座に不具合を修正できる保守体制を準備しておくことが、現実的には重要かと考えています。

他のデータソースの場合

ちなみに、ここまでDataverseを例にご説明してきましたが、市民開発でのデータソースとしてよく利用されるSharePointにもAPI制限（SharePoint Onlineの調整）が定められているので、ドキュメントライブラリ／カスタムリストにデータを保管するクラウドフローを作成する場合には、Dataverseと同様、制限に抵触しないようにAPIを呼び出すようにクラウドフローを設計する必要があります。

まとめ

今回は、クラウドフローの実行時間が延びる事象の原因について、Power Platformライセンスに基づく制約に着目しつつご紹介しました。

弊社の Power Platform サポート＆アプリカタログサービス では、キャンバスアプリやクラウドフローの実装に対する技術サポートから、ガバナンス管理・ガイドライン策定のご支援までを含めた、幅広いメニューをご提供しています。

まずはお気軽にお問い合わせください。

Power Apps/Power Platform サポート＆アプリカタログサービス ｜ 株式会社QUICK E-Solutions
Power Apps/Power Platform サポート＆アプリカタログサービス｜QESは、日本経済新聞社グループNo.1のITプロ集団として、日本を代表する金融情報サービス会社、QUICKのシステムの開発･運用･保守を担うとともに、金融･証券、事業会社など幅広いお客様に様々なICTソリューションとオフィスソリューションを提供しています。