気ままに勉強会_20230805_Power Apps&Power Automater連携あれこれ
31K Views
August 05, 23
スライド概要
気ままに勉強会に登壇させていただいた際の資料です。
Power AppsとPower Automateの連携についてあれこれ、おすすめや注意点、Tipsなどをまとまた感じの資料です。
関連スライド
各ページのテキスト
Power Appsと Power Automateの 連携あれこれ 気ままに勉強会 2023/08/05：ヨウセイ
はじめに 本内容は初学者～中級者の方や設計検討される方向けの内容 です。 アプリからフローへ処理を連携するパターンについて、 よく利用されるSharePointリスト（Microsoft Lists）を ベースに通常のM365ライセンスの範囲を前提とした内容と なります。 知っていることも多くあるかと思いますが、ひとつでもご参 考になれば幸いです。
自己紹介 ヨウセイ 一般職からSPO・C＃系へ。からPower Platform技術者へ。 主にシステム開発や技術支援をやっています。得意分野は以下です。 Power Automate Power Apps キャンバスアプリ モデル駆動型アプリ Dataverse Power Pages Power Automate for Desktop SharePoint • BLOG：Power Apps Tips ログ (youseibubu.com) • Twitter：https://twitter.com /youseibubu • Qiita：https://qiita.com /youseibubu
【JPPGB】ゲーム作成コンテスト #0 – connpass パチスロアプリで、大賞とデザイン賞をいただきました！ • BLOG：Po wer Apps Tips ログ (yo useibubu.com)
Power Appsと Power Automate の連携あれこれ
アジェンタ • アプリからフローへ連携するパターンについて • フローからアプリへ返す（または返さない） • アプリへのJSON配列の応答（有償、M365ライセンス）
アプリからフローへ 連携するパターン
アプリからフローへ連携するケース どういうときに連携するのか アプリでは実装が出来ない、またはやっかいな処理やフローの方がス マートに実装できる場合など 例） ・Excel（テーブル）、CSVなどのファイル解析 ・ファイルの作成（エクセル、PDF、CSVなど） ・メールやTeams投稿 （出来るけどフローの方がスマート、実行履歴も残る） ・ユーザーの権限ではできない操作（管理者で動くフローで行う） ・フローがメインで呼び出すUIとしてアプリを使用、などなど
アプリからフローへ連携するパターン ① アプリからフローを呼び出して実行 ② アプリでデータソースを更新、更新をトリガーにフローを実行 間接的な連携の イメージ アプリを使わないケースで、SPOリストのビューにボタンを追加してそこからフローを呼び 出すなどの方法もありますが、今回はアプリを使用する前提なので割愛します。
アプリからフローへ連携するパターン 従来まで（といっても2年位前）は、以下2パターンでした。 フローの各コネクタ の接続 フロー（トリガー）の種類 連携パターン インスタントフロー （手動・アプリなど） ① アプリからフロー呼び出し Power Apps トリガー アプリ実行者 自動化したフロー （作成時・更新時など） ② データソース更新トリガー SPOのアイテム作成・更新時トリ ガーなど フロー作成者
アプリからフローへ連携するパターン 2年ほど前からPower AppsV2トリガーが使えるようになっています！ フローの各コネクタ の接続 フロー（トリガー）の種類 連携パターン インスタントフロー （手動・アプリなど） ①‐1 アプリからフロー呼び出し Power Apps トリガー アプリ実行者 自動化したフロー （作成時・更新時など） ② データソース更新トリガー SPOのアイテム作成・更新時トリ ガーなど フロー作成者 アプリ実行者 インスタントフロー （手動・アプリなど） ①‐2 アプリからフロー呼び出し Power Apps V2トリガー OR フロー作成者
V2はした～の方にあるので 気づいてない人もいるはず 早く上に移動してほしい。
アプリからフローへ連携するパターン 例として以下のような要件のシステムを作る場合を、 １．Power Appsトリガーで作る場合、２．SPO更新時トリガーで作る場合、 ３．Power AppsV2トリガーで作る場合の順で説明します。 要件 アイテムごとに権限を設定 （作成者と承認者のみ投稿など） 承認アクションで承認 完了メールを送信 （出来れば共有メールボックスから送りたい） 申請時 権限設定 承認 SPOリストのアイテム単位の権限設定は大規模なリストでは推奨され てません。上記はその点をクリアできる前提での要件となります。 SharePoint の制限 – Service Descriptions | Microsoft Docs メール
Power Apps トリガーの場合 アプリ実行者の接続で動く 一般ユーザーが実行すると、アイテムの権限設定が行えずエラーになります。（リス ト管理者レベルの強いアクセス許可レベルが必要なため）承認は問題なし。 メールは自分としてならOK、共有メールボックスは送信するアクセス許可が必要です。 要件 結果 アイテムごとに権限を設 定 設定する 権限が必要 承認アクション 問題なし 完了メールを送信 共有メールボックス 送信できる 権限が必要 アプリ実行者 として送信 自分として なら問題なし 申請時 一般ユーザーへ の付与はあまり 一般的ではない 権限設定 承認 メール
アプリからフローへ連携するパターン フローの各コネク タの接続 フロー（トリガー）の種類 連携パターン インスタントフロー （手動・アプリなど） ①‐1 Power Apps トリガー 自動化したフロー （作成時・更新時など） ② フロー作成者 SPOのアイテム作成・ 自分（リスト管理者）でテストしているときは問 更新時トリガーなど アプリ実行者 ポイント 自分の権限の範囲の処 理までなので内容によ り実行できない。 題なく動作するけど、共有したらほかの人たちは インスタントフロー （手動・アプリなど） エラーになっちゃうんだけど。。のパターン アプリ実行者 ①‐2 強い権限が必要な処理（権限変更や共有メール利 Power Apps V2トリ OR ガー 用など）がない場合は問題なし。 フロー作成者
アイテム更新時トリガーの場合 フロー作成者の接続で動く フローは作成者（リストの管理者権限あり）で動作しますので権限設定は問題なし。 承認アクションは要求元を指定する必要あり（それでも作成者名が残る） メールは共有メールボックスへ作成者のアクセス許可を付与すればOK。 実行者としてメール送信は現実的ではない。 要件 更新トリガー 結果 アイテムごとに権限を設 定 設定する 権限あり 承認アクション 送信者に作成 者名が残る 完了メールを送信 共有メールボックス 作成者に権限 があればOK そのユーザーと アプリ実行者 としては基本 は無理 送信するアクセ アプリ実行者 として送信 申請時 して代理メール ス許可が必要 現実的ではない ①権限設定 ②承認 ③メール だけど・・
アイテム更新時トリガーの場合 フロー作成者の接続で動く 承認アクションの作成者が残る件はたなさんのブログがとてもわかりやすいです。 ※要求元に依頼者を入れればOKだが、フロー作成者の名前が残る 承認依頼メールに表示される要求者と作成者と要求対象 者とは？ | たなの覚え書き (tana-techlog.net)
アイテム更新時トリガーの場合 フロー作成者の接続で動く 共有メールボックスを使わないメール送信の場合だと、メールのFROMがフロー作成 者になります。こちらと承認アクションで作成者として名前が残る件は、以下のよう な対応を取られることが多いかと思います。 １．システムアカウント的なユーザーを用意してフローなどの作成者にする ２．メールについては共有メールボックスを使用する、承認アクションはそのまま １のシステムアカウント的なユーザーを用意するのは（M365ライセンスは必要ですが） 作成者が退職・不在になった場合の調整が不要、上記のメール送信者や承認の作成者もシ ステムアカウント表示なのでむしろ良い。というメリットがあります。
アイテム更新時トリガーの場合 フロー作成者の接続で動く だけど、ネックがあります。ポーリングトリガーなのでタイムラグが発生します。 SPOの場合はM365ライセンスは5分間隔です。※有償ライセンスだと1分 要は5分に一回見に行って実行します。そのため平均で2，3分という感じです。 タイムラグがネックになる処理にはデメリットですね。 要件 アイテムごとに権限 を設定 承認アクション 完了メールを送信 更新トリガー 影響 その間他ユーザーにアイテムが 表示されてしまうため厳密なレ ベルのデータだとNG。 →アプリ側でも見えないように 合わせて調整が必要になる。 最長5分程度なら通常は問題な いと思われる。 ①権限設定 ②承認 ③メール 平均2，3分
ポーリング・Webhook ・ポーリング：コネクタ、ライセンスに応じた間隔でチェックして実行する ・Webhook：すぐ動く →２つの見分け方と間隔はコードのプレビューから トリガーのコードのプレ ビューを開く Dataverseのトリ Recurrenceがあればポー ガーの場合、 リング Recurrenceはない この場合、5分 →すぐ動く ※有償だと1分になっている
ポーリング・Webhook 軽く見た範囲では以下の感じでした。 コネクタ トリガー 種類 M365 有償 SPO 作成時、更新時 ポーリング 5分 1分 OneDrive ファイル作成時で確 認 ポーリング 5分 1分 Forms 新しい応答が送信さ れるときで確認 Webhook - - Office 365 Outlook 新しいメールが届い たときV3で確認 Webhook - - Dataverse 行が追加、変更、ま たは削除された場合 Webhook - - Attantion ポーリングトリガーはオフにして オンにしたら、その間の分を一気 に実行しちゃう罠があります。 →コピーして前のは削除するなど の対応で回避 その他、実行履歴のチェック間隔からもポーリングの間隔が見て取れる。 ※一部Twitterなどは実際は1時間だったりする様子。 Power Automate のトリガー、ポーリングか Webhook か どっちなの？ – idea.toString(); Otaさんがまんま書かれてい たのでご参考に
アプリからフローへ連携するパターン フロー（トリガー）の種類 連携パターン インスタントフロー （手動・アプリなど） ①‐1 Power Apps トリガー 自動化したフロー （作成時・更新時など） ② SPOのアイテム作成・ 更新時トリガーなど フローの各コネク タの接続 アプリ実行者 フロー作成者 ポイント 自分の権限の範囲の処 理までなので内容によ り実行できない。 作成者（管理者）とし て動作させたい場合に 有効 タイムラグがネックの 場合がある アプリ実行者 タイムラグがネックでない、作成者名が出ても（システムアカウント用 インスタントフロー （手動・アプリなど） ①‐2 Power Apps V2トリ OR 意などで）問題なければOK ガー フロー作成者 その他はアプリ側に結果は返せない点や、トリガー条件で無駄な呼び出 しをしないなど実装を注意など
Power Apps V2トリガーの場合 これらをカバーできるのがV2トリガー！ V2トリガーでは使用する接続を選択できます（実行ユーザーOR作成者の接続） パラメータもわかりやすく、使い勝手も従来版より断然よい テキスト、数値、日付、ファイルなどの種類がある パラメータを任意にする、ドロップダウンにするなども可 アプリ実行者の接続で動く OR フロー作成者の接続で動く
Power Apps V2トリガーの場合 V2トリガーで使用する接続を選択 ※アプリから呼び出すフ ローの場合、アプリ共有 時に自動で実行専用アク セス許可が付くので、こ の画面でのアクセス許可 設定は不要 右下の実行済みのユーザー 使用しているコネク ＞編集から タの接続が表示 無印版だとこれ自体が ないので設定不可
Power Apps V2トリガーの場合 コネクタ単位ごとに実行専用のユーザーの接続（要はアプリ実行者）を 使うか、この接続（作成者が使える接続）を使うのかを選択可能です。 アプリ実行者の接続で動く OR フロー作成者の接続で動く
Power Apps V2トリガーの場合 アプリ実行者の接続で動く OR 今回の場合はSPO権限設定は作成者、承認アクションは 実行ユーザー、メールは共有メールボックスなら作成者、 フロー作成者の接続で動く アプリ実行者として送信なら実行ユーザーにする。 しかもタイムラグはなし！ 要件 アイテムごとに 権限を設定 結果 フロー作成者 申請時 承認アクション アプリ実行者 完了メールを送信 共有メールボックス フロー作成者 アプリ実行者 として送信 タイムラグなく 権限設定 承認 適したユーザー アプリ実行者 で各操作が可能 メール
アプリからフローへ連携するパターン フロー（トリガー）の種類 連携パターン インスタントフロー （手動・アプリなど） ①‐1 Power Apps トリガー 自動化したフロー （作成時・更新時など） インスタントフロー （手動・アプリなど） ② SPOのアイテム作成・ 更新時トリガーなど ①‐2 Power Apps V2トリ ガー フローの各コネク タの接続 アプリ実行者 フロー作成者 アプリ実行者 OR フロー作成者 ポイント 自分の権限の範囲の処 理までなので内容によ り実行できない。 作成者（管理者）とし て動作させたい場合に 有効 タイムラグがネックの 場合がある タイムラグなく処理 に応じて実行者、作 成者を指定できる。
アプリからフローへ連携するパターン フロー（トリガー）の種類 連携パターン インスタントフロー （手動・アプリなど） ①‐1 Power Apps トリガー アプリから呼び出すな フローの各コネク タの接続 アプリ実行者 らV2がベスト。 無印版は不要。 自動化したフロー （作成時・更新時など） SPO更新トリガーもタ ② SPOのアイテム作成・ 更新時トリガーなど フロー作成者 イムラグ、管理者操作 がネックでなければ問 インスタントフロー 題なし。 （手動・アプリなど） ①‐2 Power Apps V2トリ ガー アプリ実行者 OR フロー作成者 ポイント 自分の権限の範囲の処 理までなので内容によ り実行できない。 作成者（管理者）とし て動作させたい場合に 有効 タイムラグがネックの 場合がある タイムラグなく処理 に応じて実行者、作 成者を指定できる。
アプリからフローへ連携するパターン フロー（トリガー）の種類 連携パターン インスタントフロー （手動・アプリなど） ①‐1 Power Apps トリガー V2のデメリット・・ アプリとフローが接続 自動化したフロー しているので、どちら （作成時・更新時など） も共有しないとコピー ② SPOのアイテム作成・ 更新時トリガーなど フローの各コネク タの接続 ポイント 自分の権限の範囲の処 アプリとフローが独立し、構成がシンプ 理までなので内容によ アプリ実行者 ルになる点では②のメリットある り実行できない。 フロー作成者 作成者（管理者）とし て動作させたい場合に 有効 タイムラグがネックの 場合がある 不可や別環境インポー ト時に調整必要な場合 インスタントフロー があるなど？くらい？ （手動・アプリなど） ①‐2 Power Apps V2トリ ガー アプリ実行者 OR フロー作成者 タイムラグなく処理 に応じて実行者、作 成者を指定できる。
APIコール数はだれのもの？ Power Appsトリガーはアプリ実行者ですね。 SPO更新トリガーはフロー作成者となります。（アプリ関係ないし） じゃあ、Power AppsV2トリガーで作成者で動かしていたら？ →以前はてっきり作成者にかかるのかと思ってたんですが、よく考えたらコネク タ以外のアクションは実行者ですよね。作成者を使っている部分だけがそっちに いくのか？などよくわからずでしたが、公式を見るとどうやらアプリから呼び出 した場合はどうあれアプリ実行者に全部かかってくるようです。 ※この辺は中身見えないし移行期間ということもあり不明確。将来変わる可能性 もあるかもですのでご参考までに
APIコール数はだれのもの？ Power Automate ライセンスに関してよく寄せられる質問 - Power Platform | Microsoft Learn 自動化フローおよび予定フローは、 フローを開始するユーザーやフロー 内で接続に使用されているアカウン トに関係なく、常にフロー所有者の コンテキストで実行されます。 イン スタント フロー (ボタン、ハイブ リッド トリガー) は、フローが使用 する接続に関係なく、ユーザーが呼 び出すコンテキストで実行されます。 ・・・てことはアプリ実行者ってこ とだよねと解釈してます。
ライセンスは必要です。 Power AppsV2トリガーで作成者の接続を使えば、SPOやExcelOnlineなどのライセ ンス（プレミアムコネクタもしかり）がないユーザーでも使えるのでは？ と思われるかもしれませんがそれは出来ません。 アプリにはフローとの接続情報が定義されていて、 アプリ初回起動時にはフロー内で使用する コネクタの接続認証が表示されます。 ライセンスを持っていないとこの時点で アプリを利用することが出来ません。 ソリューションの子フローを使う場合は認証は聞かれないという のもありますが、他の人が恩恵受けるコネクタ使う場合などは使 えたとしてもライセンスが必要
ちなみにDataverseは・・ Dataverseの場合は先ほど触れたとおり、更新時トリガーでもすぐに動くのでタイムラ グはありません。実行するユーザーや行フィルター、対象列なども指定でき、モデル駆 動型と組み合わせての使用も多くよく使います。 すぐ動く、対象の列、 フィルター条件、実行 ユーザーの指定なども可 能でSPOと比較して使い やすい SPOは対象列の指定は不可（フロー内で判定は可 Dataverseを実行者か管理者、所 能）、トリガーの条件に式を指定すればフィル 有者のどれで行うかを設定できる ターはおおむね可能 （他コネクタの指定は不可） ポーリングトリガーである。
アプリからフローへ連携するパターン まとめ • フローでないと出来ない、スマートな場合にお願いする • ①アプリから実行、②更新トリガーで間接的に実行するパターンあり。 • アプリから実行する場合、基本はアプリ実行者の接続で動作する。 • 更新トリガーの場合はフロー作成者の接続で動作する。 • ポーリングトリガーがあり、SPOは通常5分、有償1分の間隔 • Power AppsV2トリガーなら接続を選択できる、タイムラグもないの でオススメです。
フローからアプリへ結果を 返す（または返さない）
Power Apps V2トリガー Power Apps V2トリガーベースで説明します。 アプリからフローを呼び出し方法や、実行後に結果（なにかしらの値）を返す、 または返さない方が良いパターンなどについて。 ① フロー起動 権限設定 ② 各処理を実行する 承認 ④ 成否を確認や 結果を使った処理を ③‐1 行うなど 処理結果を返す メール ③‐2 処理結果を返さ ない場合は終わり
フローを呼び出す Power Appsから呼び出すのはざっくり以下のような感じです。 フローを作成します。 ・フローをPowerApps V2トリガー で作成する。 ・パラメータを定義する。 （パラメータが不要な場合は空でOK） →例ではすべて必須項目で型は テキスト、メール、数値
フローを呼び出す Power Appsにフローを追加し、ボタンクリック処理などにフロー呼び出しを実装 ボタンのOnSelectなどにフローの実行を実装 フロー名.Run([パラメーター１][,パラメーター2…]を順番に定義) オプション（任意）のパラメータは必須項目の後に {オプション1名:オプション1,…}という感じで定義します。 サイドペインのフローアイコン から、作成したフローを追加 アプリ開発者が所有者のフロー （ここから新規作成も可能） （接続含め）を追加できる
フローを呼び出す ボタンをクリックすればフローが実行されます。 ・ボタンクリックのタイミングですぐに フローが実行 ・アプリからパラメータが渡されている
フローを呼び出す 呼び出し出来なかった場合（ランタイムエラーが発生） フロー内のコネクタを追加や 変更した、パラメータを変更 した場合にアプリが持ってい る定義と異なるためエラーと なることが多い。 その場合は、フローを最新の 情報に更新することで解消
フローから結果を返す さきほどのサンプルでは呼び出しのみで結果は返却していません。 結果をアプリ側で受け取る場合は、フロー側でPower Appsへ応答アクションを追加 する必要があります。 フロー側は実行のみで結果は アプリへ返してない実装
フローから結果を返す フロー側でPower Appsへ応答アクションを追加します。組み込みから応答で検索 →「PowerApps または Flowに応答する」 （有償だと「応答」も使える） トリガーと同様の 設定イメージ
フローから結果を返す アプリ側は戻り値を使った実装が可能です。通常は変数に入れます。 フローの実行を変数に指定する →戻り値が変数に格納される。 それを使ったNotify表示など可能 フローを変更したら都度、 最新の情報に更新をして動 作確認する
フローから結果を返す 注意点：フロー側で応答を実装しておらず、ただフローを変数に指定しても呼び出し が成功したかの結果（True）しか返ってきません。 またフローの結果は待たないのですぐに次に進みます。なので意味がないです。 フロー側に応答アクションが入っていない場合は、 アプリは呼び出した後結果を待ちません （何も返ってこないので） 呼び出しに成功したらTrueを返してすぐ次に行きます。
フローから結果を返す：エラー判定 フロー内でなにかしらエラーがあり応答アクションがスキップで実行されない場合は ランタイムエラー（500系エラー）になります。以下のようなアラートが出ます。 このままだとおっかないので、エラー判定を入れたほうが良いです。
フローから結果を返す：エラー判定 IsBlankOrError()で判定し、エラーか空だったらエラーアラートを出す、 それ以外は正常完了メッセージを出す例 If(IsBlankOrError(flowResult), Notify("フローがエラーで終了しました。管理者へ連絡してください。",NotificationType.Error), Notify(flowResult.msg,NotificationType.Success); ); フロー内でエラーが出たことをユーザー に知らせれる。 フローのエラーハンドルはフロー側で 実施しメールで連絡などで対応する。
フローから結果を返す：エラー判定 フローのエラー判定（あくまでサンプルです。）簡単にやるならスコープ全囲み Result（スコープ）で結果も取れるのでそこからエラー解析も可能（ネスト部分は取 れないのでちゃんとやるならちゃんと実装する） とりあえずスコー プで全部囲んで 実行条件の構成な どでエラーがあっ たか判定する。 エラー時は管理者へメール送信 アプリへは失敗で返す
フローから結果を返す：エラー判定 エラー判定してその結果を返す場合は、戻り値は空やエラーではないので、その判定 を追加する必要がある。 この例ではシンプルにしていますが、アプリ 側にも正確なメッセージを出したい場合など は、別のパラメータ（成功OR失敗）を追加 して判定に使うなど調整
フローから結果を返す：タイムアウト 注意点：アプリからのフロー呼び出しの結果を待つ場合タイムアウトがあります！ タイムアウトは２分です。システムで決まっていて変更できません。 そのため時間がかかることが予想される処理の場合はそもそも待たない方がよいです。 ※タイムアウトはしてもフロー処理自体は成功しているケースもある。 このフローの例でも承認を待機するアクションがあるので 待たない方が良いです。（2分では返ってこない） その他、多めのデータのインポートなども同様です。 タイムアウト：アプリがフローの 結果を待つのは2分までです！ 承認が完了するまで待機するので 返ってこずにアプリ側の待機がタイ ムアウトする →フロー自体は正常に進んでいる
フローから結果を返す：エラー判定 タイムアウトまたはエラーで判定するならさきほどの実装でOK タイムアウトかエラーかをそれぞれ判断するなら空ORエラーが返ってきたらタイムア ウト、エラー判定が返ってきたらエラー、それ以外は成功。などの調整をします。 タイムアウトの場合は応答のアクションが行われないので、 IsBlankOrErrorがエラーとなり判断が可能。 その他のエラーの場合はエラー情報を返すようにして判断。
フローから結果を返す：タイムアウト タイムアウトが想定される処理の場合は最初からフローへ値を返さない処理にする →結果はフロー側でメールなどで通知する。（必要に応じて） →アプリ側は実行した旨の情報Notifyを出すなどにする。 フロー側では結果を アプリ側は実行した アプリへ返さない。 旨をNotifyする
フローから結果を返す、返さない まとめ • アプリからフローを呼び出してアプリへ結果を返せる。 「PowerApps または Flowに応答する」※有償は「応答」も • アプリ側では変数で結果を受け取り利用する。 • フロー側に応答アクションがないとアプリは結果を待たないので注意。 • 結果からエラーやタイムアウトなどの判定を行おう。 • フロー側でエラー判定も（最低限でも）。 • アプリ側がフローの応答を待つのは2分まで！タイムアウトがある。 • 時間がかかる処理は最初から待たないでおこう。
アプリへのJSON配列の応答 応答（有償）/ JSON文字列（通常）
アプリへのJSON配列の応答 有償ライセンスの「応答」 有償ライセンスを持っている場合は「応答」アクションが使用できます。 このアクションの場合は、配列などJSON形式でアプリへ返すことが可能です。 アプリ側では戻ってきた値をそのままコレクションに指定すればコレクションとして 使用が可能です。（カスタムコネクタ使うのと同じイメージ） 渡したいJSONデータ を本文に指定する ※以前は通常ライセ ンスでも使えていた が現在はPREMIUM ★アプリ側で定義を読 み取るためJSONス キーマが必要
アプリへのJSON配列の応答 有償ライセンスの「応答」 アプリ側では戻ってきた値をそのままコレクションに指定すればコレクションとして 使用が可能です。（カスタムコネクタ使うのと同じイメージ） コレクションをデー コレクションとして そのまま使える タテーブルで表示
アプリへのJSON配列の応答 通常ライセンスの応答 Power Apps またはFlowに応答するアクションの場合は、JSON配列などのデータ構 造のままの返却は対応していません。送る場合は文字列での応答となります。 文字列で結果を返却 outputs('表内に存在する行 を一覧表示')?['body/value'] データ構造の 文字列で返ってくるのでそのままコ 種類はない レクションとしては使用不可
アプリへのJSON配列の応答 通常ライセンスの応答 以前までは、ここから自力のJSON解析をする場合は、IsMatchを使うなどでカスタマ イズしてコレクション化する必要がありました。（知見必要、工数かかる、テストも しっかりなどいろいろと面倒） 現在はプレビューまで来ている【ParseJSON関数】を使うことで解析してコレク ション化することが比較的容易にできるようになっています。 プレビュー機能でオンにする ※最近暗黙的な型の推測にも対応し たのでより使いやすくなっている （明示的に型指定も可能） Power Apps の ParseJSON 関数 - Power Platform | Microsoft Learn
アプリへのJSON配列の応答 通常ライセンスの応答 フローからの戻り値（JSON文字列）を ParseJSON関数で囲い、テーブル化してコ ClearCollect(JSONCOL, Table( ParseJSON(<JSON文字列>))); レクションへ格納 →型指定していないデータとして、Value 列に格納される。 この時点でForAllで型指定して通常のコ レクションとして使用も可能。 またはこの状態で使用して、暗黙的な 型指定で使用 OR 個別に型指定して使 用することも可能
アプリへのJSON配列の応答 通常ライセンスの応答 ギャラリーのItemsにJSONCOLを使用 それぞれ、ThisItem.Value.列名 で指定が可能。 データ型はUntypedObjectとなるが、暗黙的にテキスト と判定される。型指定も可能。 ※データソースにPatchする場合などは型指定する テキストの場合は以下のように型指定 Text(ThisItem.Value.列名)
アプリへのJSON配列の応答 通常ライセンスの応答 M365ライセンスの範囲でもJSON文字列 を返して、アプリ側でParseJSONすれば やり取りが可能です。
その他いろいろな連携パターン • アプリから表示データをフローへ送りファイル生成 （時間かかる場合はメールなどで送付、すぐなら配置先URL返却も※DL用のURLも作れる） • アプリでメインリストを更新して、その後に管理者用リストにログを追加 （フロー作成者で動作するV2トリガーや更新時トリガーで可能） • アプリからExcelをアップしてフローで解析、抽出してデータを登録する （解析時の一時ファイルはフロー作成者で動かして、ユーザーが見えないライブラリに配置 して終わったら削除なども可能） • AADの従業員IDなど普通にとれない属性をフローで取ってきて使う ( ユーザー プロフィールの取得 ( V2) で明示的に指定すれば取れる） • ・・・・・
アプリ・フローのJSONデータ連携デモ 以前作成した人材スキル管理アプリのCSVインポート機能で ParseJSON関数を使った連携をしています。 CSV取込みなどは • アプリからCSVファイルをフローへ連携 ループを極力使わな • フローでCSVファイルを解析しJSON化、アプリへJSON文字列で返却 い実装に。APIコール • アプリでParseJSON関数でParseしてPatchで 登録 数の制限に収まる範 囲に調整しましょう。 制限事項と構成 - Power フローへ ※フローでの 登録も可能 CSVを アップ JSOＮ解析して SPOへ登録 CSVをJSON化して アプリへ返却 Automate | Microsoft Learn 要求の制限と割り当て - Power Platform | Microsoft Learn
アプリ・フローのJSONデータ連携デモ こちらの実装は以前Qiitaへ投稿していますので、気になる方はご参考ください。 【ワンランク上のPower Apps】 CSVインポート その③ Automate で解析・Appsで登録編 ＆プログレス表示 - Qiita
アプリ・フローのAPIコール数の制限 CSV取込みなどはループを極力使わない実装に。APIコール数の制限に収まる範囲に調整しましょう。 今は移行期間で通常ライセンスで1万/日まで、将来的には6千/日の予定 要求の制限と割り当て - Power Platform | Microsoft Learn 制限事項と構成 - Power Automate | Microsoft Learn
全体のまとめ ① アプリからフローへの連携は方法によって違いがある。 →V２トリガーが便利です。 ② フローからアプリへ結果を返せる。 →エラー判定やタイムアウトに気を付けよう。 ③ フローからJSONを返してアプリでParseも出来るよ。 ご清聴ありがとうございました。