Power Apps と Power Automate 連携 その② （フロー呼び出しとアプリへ返却）

はじめに

Power AppsとPower Automate(クラウドフロー)は仲良しなので、よく連携をしてシステムを構築します。
その②ではその際のアプリからフローを呼び出す、フローへの返却についての内容です。
先日開催されたMVPたなさん主催の気ままに勉強会 #63 に「Power Appsと Power Automateの連携あれこれ」で初登壇した際の資料のうち、この部分を記事に起こした内容となります。

資料は以下の記事にも記載しています。

【登壇資料】8/5 気ままに勉強会 #63 に「Power Appsと Power Automateの連携あれこれ」で初登壇しました！

前回の記事はこちら（登壇資料の「アプリからフローへ連携するパターンについて」にあたる内容です）

Power Apps と Power Automate 連携 その① （PowerAppsV2トリガーで接続変更）

アプリからフローを実行する

以下フローの呼び出しについて簡単に。記載はPower AppsV2トリガーを前提に記載しています。

Power Apps (V2)トリガーでフローを作成

・フローをPowerApps V2トリガーで作成する。
・パラメータを定義する。（パラメータが不要な場合は空でOK）   
    →例ではすべて必須項目で型は　テキスト、メール、数値

V2トリガーでフロー作成については、インスタント クラウド フローから Power Appsで検索または下の方に行くとあります。

パラメータなどの定義など、従来版トリガーとの違いについては、HIROさんのブログなどでも紹介されていますのでご参考に
新しくなった Power Apps トリガーの変更点について – MoreBeerMorePower (hatenablog.com)

アプリからフローを呼び出す

アプリ側からフローを呼び出すのは以下の感じです。
・サイドペインからフローを追加する。
・ボタンのOnSelectなどでフローを実行する

NOTE使えるフローはアプリ開発者が所有者であるフローになります。またフロー内で利用している接続も含めて権限が必要なので、フローを作った人が追加するのが良いです。※権限がないフローの場合はエラーがでます。

構文イメージ<フロー名>.Run([パラメーター１][,パラメーター2…]を順番に定義)
オプション（任意）のパラメータは必須項目の後に{オプション1名:オプション1,…}という感じで定義します。

ランタイムエラー

呼び出しが出来なかった場合は以下のように500系のエラーが発生します。
おおむね、フローのトリガーパラメータや接続などの変更を行った場合にアプリ側で保持している定義と異なるためおきます。フローの更新を行った場合は以下より「最新の情報に更新」をすることで大体解消します。

フローから結果を返却

上記までは呼び出しのみで結果は返していませんので、結果をアプリ側で受け取るにはフロー側にPower Appsへ応答するアクションを追加する必要があります。

PowerAppsまたはFlowに応答するアクション

有償版だと応答（要求）アクションが使えます。こちらだとJSON配列形式で返却するなども可能ですが、通常ライセンス（M365ライセンスなど）の場合は、「PowerApps または Flow に応答する」アクションを使います。
※いまだFlowになっているなー。もう修正されないのかもなーと思う。

以下の例ではテキスト側で「msg」という名のパラメータを作って戻しています。

アプリ側で変数で受け取る

アプリ側では以下のように戻り値を受け取る実装をします。
通常はUpdateContextやSetなどの変数に結果を入れます。変数の値に直接フロー呼び出しを指定するイメージです。
フローを変更した場合は最新の情報に更新をしてから試しましょう。

CodeUpdateContext({<変数名>:<フロー名>.Run([パラメーター１][,パラメーター2…])});
以下の例では<変数名>はflowResult

上記のように、戻ってきた値が変数に入ります。変数の中にフローで定義したパラメータ（上記ではmsg（テキスト型）)が入っているので、それを使ってNotiryを出すなどの処理が可能です。

注意点：フローから応答しない場合はアプリは結果を待たない

フローからの応答を待ちたい場合は、フロー側に応答アクションを入れるようにしましょう。

たまにフローを呼び出し後に成功Notifyを出しているが、上記の応答アクションを使っていないケースを見かけます。
フロー側に応答するアクションがないとアプリは結果を待たずに次のアクションへ進みます。
応答するアクションがない場合、変数にはフローを呼び出せたかどうかのTRUE,FALSEが入るだけですので、おおむね「TRUE]が入るだけです。なので変数に入れる意味はあまりありません。※呼び出せたかの判定はできるけど

エラー判定

フロー内でなにかしらエラーがあると通常応答アクションがスキップされて以下のようにランタイムエラー（500系）になります。そのままでも以下のようなアラートが出てくれますが、ユーザーライクではないのでアプリ側で判定を入れたほうが良いと思います。

アプリ側のエラー判定

変数をIsBlankOrErrorで判定して、エラーだったらエラー通知するなどの調整が出来ます。

エラー判定（フロー側）

フロー側で何もしない場合は上記のみでエラー（またはタイムアウト）時の判定が出来ます。
フロー側でもエラーハンドリングを行ってその結果（メッセージなど含めたいなど）を返して判定する場合は、フロー側でエラーハンドル、成功時、エラー時で返却する結果を変更します。

以下は簡単なエラーハンドル（Try、Catch）の例ですが、全体をスコープで囲ってあげて、その次に並列処理にして実行結果によって切り分けるイメージです。※この辺はまた別記事で紹介するかもです。

次項で載せているタイムアウトを考慮して、エラーかタイムアウトかも判定したい場合は
以下の例のようにそれぞれ判定すると良いと思います。
例）IsBlankOrErrorでエラーだったら（本来エラーでも結果を返しているが返ってきてないため）タイムアウトとみなす、結果が返ってきていて内容がERRORを示すならエラー、それ以外は成功。

注意点：タイムアウトは2分！

アプリからフローを呼び出して結果を待つ時間は2分までとなっています。これはシステムで決まっていて変更が出来ません（2023年8月時点）

そのため時間がかかることが予想される処理はそもそも結果を待つ実装にしない方がよいです。
以下のようなケースでは待たない方が良いと思います。

• 承認アクションがある　→承認の結果を待機しているので普通2分では終わらない
• 複数件（多め）の更新がある　→件数の上限がわからず結構な時間がかかる可能性があるなど

タイムアウトが想定される処理の場合は応答アクションを入れずに、呼び出したよ的なNotiryにしておいて、必要に応じてフロー側でメールやチャットで通知する。などの対応が良いと思います。

まとめ

おわりに

ということで今回は登壇資料のフローを呼び出す・返却するの部分を記事に書き起こした内容でした。
その他の内容については以前に記事にもしているので、資料と合わせてご参考いただければと思います。

通常ライセンスの応答アクションでJSON文字列を返却してParseJSON関数を使って使用するサンプル
【ワンランク上のPower Apps】 CSVインポート その③ Automateで解析・Appsで登録編 ＆プログレス表示 – Qiita

それでは。