はじめに
Power Appsの各種関数で一部委任対象外のものがあります。
今回は引っかかりやすい(と思う)Distinct関数についてです。さらっと。
Distinctって委任できないの!?警告が出ないから気が付かなかったわ!
どうすればいいのかしら??
委任について
委任についてはPower Appsの中でも最大の調整課題です。
この機能があるおかげでアプリが極端に重くなるや落ちることを抑えれる反面、どうしようもない機能制限もあります。(データソースによって変わる)
委任については今までもたくさんの記事が出ているので本記事では概要は割愛しますが、
ポイントとしては主に以下かと思います。
・委任対象の関数を使ってデータを取得する場合は正しい結果にならない場合がある(以下設定値を超えるデータ量の場合)
・委任できない場合およびコレクションなどに入れるとき返される件数(データ行の制限)は既定で500、最大で2000件(設定>全般で調整可能)
・委任可能な関数でもデータソースにより対応が異なる(SPOではSearchやINは委任対象外など)
※ギャラリーに委任可能で式でデータソースを直接指定している場合は100件ずつ取ってくるので2000件以上取れます。
主には一覧表示のフィルター処理に影響する部分ですね。
サンプルレベルやチームレベルのアプリであればそれほど影響は大きくないですが、本格的に運用するアプリだとデータ量も大規模となり、この仕様がネックとなる場面が多くあります。有償版のDataverseであればおおむね対応できるのですが、SPOリスト(MicrosoftLists)を使う場合などはある程度制約がかかります。
委任対象外か対象かは各データソースの一覧のページで確認する必要があります。
このあたりは出来る範囲で調整し、仕様とデータソースとうまく付き合っていくしかないですね。
NOTE最近の海外有識者の投稿で、GraphAPIを使ってSearch Queryでこの委任問題(含む検索)を回避する超絶技も紹介されています。
ただ、こちらの実装はかなり高度、かつ他の部分の影響(デプロイ調整や運用保守の観点、反映までの時間)などもあるので、取り入れるかは要検討と思います。
Distinct
本題のDistinctですが、これは委任対象外の関数です。
Distinct関数についての公式リファレンスではちゃんと記載されていますが、
上記紹介した「キャンバス アプリでの委任について」では、触れられていませんので気づきにくいです!
以下はよくあるケースのサンプルです。実はこの場合、Distinctは委任対象外なので500~2000までの最初のレコードを取得した結果からのDistinctになるので、データ件数が上記を超えた場合に正しい結果が返ってきません。
しかも通常は委任対象外の処理を書いている場合は下に青い線と警告表示が出てくれるのですが、
Distinctの場合は出てくれません。これがさらに気づきにくい点です。
- データソースに対してある項目でDistinctして結果をドロップダウンに指定する
- ギャラリーではドロップダウンの値でフィルターする
NOTE例えばデータ行の制限が500の場合に、501件目に次の区分(区分その2)があったとしても取得されず、結果に含まれません。
警告が出るのはいやだけど、出ないけどダメなのはもっと困るね!
実際に動作を確認したい場合は、でータ行の制限を500→10などに調整して、
それ以上あるデータソースに対してDisticntをしてみるとわかりやすいと思います。
データ行を調整して確認
以下サンプルでデータ行の制限を調整して確認してみます。
委任が効く場合はデータソース側でDistinctしてくれた結果がデータ行の制限に収まるなら問題ないはずです。
・ドロップダウンにはメインリストの区分(社員、BP、個人)をDistinctで設定
・メインリストはレコード数15件
①データ行の制限を既定の500で確認
ちゃんと取れますね。
②データ行の制限を5に変更して確認
では上記を5件に調整して確認します。
変更後の確認はいったん保存して編集画面を開きなおすか、以下よりデータソースを最新化して変更を反映させます。
変更後にデータソースを最新の情報に更新して反映
上記のように最初(特に指定していないのでID順)の5件までにある中からDistinctされた結果がプルダウンに入っています。
そのため社員しかないですね。
データ行の制限を最大の2000まで上げておけばメインデータが2000未満なら問題ないですが、
それ以上になるとプルダウンには入ってこない可能性が発生することになります。
解消策
Distinctの委任対象外はデータソース問わずなのでDataverseだとしても発生します。
なのでこれと言ってありませんが、代替え案としては、
- データソースからのDistinctはやめてドロップダウン用のマスタを別に作って使う
- データ量が2000を超えないなら最大2000までにしておいて使う
- どうにかしてデータソースから2000以上のデータをコレクションに取得してDistinctを行う
などでしょうか。基本は①の対応が良いのかと思います。
①のデメリットとしてはメインのデータソースの選択肢が増えるのならこちらも併せて調整が必要という点でしょうか。
また、メインのデータソースに存在するものだけ表示する制御は出来ない(マスタにある分を表示)点がDisticntと挙動が異なります。
②はそもそもデータ量がそもそもそれほど増えない場合ですね。500よりは2000にしていた方が良いと思います。
③はApp起動時に2000以上のデータをコレクションに順次追加するカスタムを行いそれをDistinctする感じです。
TIPS③は自分でやったことないのでイメージですが2000件だったらまだあるかもなので再度取ってきて追加するなど?ループがうまくいかない場合はAutomate側でやるとか最近のGraphAPI使うなど?今後アップデート予定のユーザー定義関数で再起処理が可能になればこの辺も楽にできるようになるかもですね。
後から対応するよりは最初にやっておいたほうがいいな。
制限とはうまく付き合っていけばいいんだな
おまけ
Distinctですが、以前は戻り値が「Result」でした。が、少し前のアップデートでValueに変わっています。
よくあるプロパティになったのでわかりやすくなったのですが、以前のアプリを開いた場合は勝手にForAllで中身が調整されています。
(同等の結果となるような処置が自動で適用されていて、他で参照しているプロパティがResultなのでValue→ResultにForAllで変換してくれている)
上記のためエラーとなることはないのですが、余計なForAll入っていて気持ちわるい(パフォーマンスも少し影響するんじゃ?)と思う場合は、ForAll消してResult→Valueに自分で調整すれば解消します。
おわりに
今回はDisticntの委任対象外に注意!という内容でした。
お仕事でもよくあるケースなので、みなさん引っかかるよなーと思い記事にしました。
その他にも委任対象外の関数はいろいろとあるので、それらともうまく付き合っていきましょう。それでは。
※それぞれの関数リファレンスには記載があるのでそちらでもチェックしましょう。
この記事は役に立ちましたか?
もし参考になりましたら、下記のボタンで教えてください。
コメント