はじめに
PowerApps ポータルで試したことを備忘録として残していきたいと思います。
今回はポータル画面からのクラウドフローの実行についてです。
ポータル画面から送信したあとにクラウドフローを実行することは良くあります。この場合、送信したレコードの作成・更新のタイミングをトリガーとするクラウドフローを作成することが多いと思います。しかし、レコードの更新のタイミングは目的のポータル画面以外の場合もあるのでステータスなどの属性を見て処理する必要がありクラウドフローが複雑化してしまう課題がありました。
このようなことを避けシンプルに特定のポータル画面で送信したタイミングだけで特定のクラウドフローを動かしクラウドフローを分割管理するのが今回の方法です。クラウドフローが複雑化している場合に有効なテクニックになります。
方法
特定のポータル画面の送信時に値を更新する属性を作成してその属性を現在時刻で更新することでクラウドフローを動かすという考え方です。複数の画面がある場合、画面の数だけ属性を定義し対応するクラウドフローを作成します。
- 該当ポータル画面の送信時間を記録する属性をテーブルに定義する
- 該当ポータル画面の基本フォームのメタ情報に定義したテーブルを追加して「保存時に値を設定する」を有効にして「種類」を「今日の日付」に設定する
- 対応するクラウドフローの開始条件を以下のようにする
| 項目 | 設定 |
|---|---|
| テーブル名 | 該当テーブル名 |
| 列を選択する | 送信時間を記録する属性 |
| 行のフィルター | 送信時間を記録する属性 ne null |
行のフィルターは開始条件の設定の「トリガーの条件」に書き方は少し変わりますが記載することも可能です。この方法を使うと行のフィルターに設定している場合は、条件に該当しない場合でもクラウドフローが起動しすぐに終了するような動作をしますが、トリガーの条件に記載すると起動自体を抑制できるのでクォータ消費の抑制ができます。
@not(equals(triggerOutputs()?['body/送信時間を記録する属性'], null))
おわりに
今回は特定のポータル画面から特定のクラウドフローは実行する小技の紹介でした。ただ、たまにテーブル更新を１つのクラウドフローにしたい言われる場合ありこの場合はこの小技は使えません。クラウドフローは複雑になると保守性が悪くなるためできる限り小分けにする方が良いと思ってますが実際に保守する方の希望なので対応していますが、なかなかこのあたりは説明しても伝わらないことが多いです。