委任の警告、制限、および委任できない関数
Power Apps では、アプリの作成者の支援になるように、委任がいつ発生しているかを理解できるビジュアルが使用されています。 メーカー ポータルにも、委任が不可能な場合に返されデータ量を増やすことができる、ユーザーが調整可能な設定が 1 つあります。
委任の警告
次の図に示すように、Power Apps では、委任できない関数を使用すると、青の下線と黄色い三角の警告が表示されます。
これにより、委任が行われないことが視覚的に示され、データの一部が表示されない可能性があることがわかります。 この視覚インジケーターについては、理解する必要のある重要な事柄がいくつかあります。
Power Apps ではお使いのデータ ソースのサイズにかかわらず、この警告が表示されます。 データ ソースに少しの項目しかなく、技術的に委任が問題を引き起こしていない場合でも、警告は表示されます。 最初の 500 項目は既定で返され、ローカルで処理されることを思い出してください。 警告は、式が委任されないと常に表示されます。
警告のインジケーターでは、委任が発生した最初のもののみが処理されます。 上のスクリーンショットで、下線が引かれている "FirstName" のフィールドのみが青であることに注目してください。 これは、これが委任を引き起こした最初の項目であるためです。 このシナリオでは、"LastName" でも委任が発生します。 これは、本当の問題である Search 関数にではなく、FirstName と LastName の違いに問題があり、それをトラブルシューティングする必要があるという混乱を招きます。 このような混乱が発生した場合、式を並べ替えてください。 これにより、どちらのフィールドが前でも問題が表示されるかどうかを検証できます。
この視覚インジケーターは、Maker Potal でアプリを作成しているときにのみ表示されます。 ユーザーがアプリを実行している場合、ユーザーに委任が起こっていないという通知はなく、結果の一部しか表示されない場合があります。 アプリおよびビルドをデザインする際は次の点に注意してください。
委任を使用できないときに返されるレコード数を変更する
何らかの理由により数式をデータ ソースに委任できない場合、Power Apps は既定で最初の 500 のレコードをデータ ソースから受け取り、続いてその数式をローカルで処理します。 Power Apps では、この制限を 1 から 2000 に調整できます。 この制限は詳細設定で調整できます。
メーカー ポータルで、左上隅のファイルを選択します。
最も左側のメニューで、設定を選択します。
アプリ設定で 詳細設定を選択します。
委任できないクエリのデータ行の制限を 1 から 2000 の任意の値に設定します。
制限を設定したら、左上の矢印を選択して変更を保存し、Maker Potal に戻ります。
この制限を調整する理由は主に 2 つあります。
レコード数が 500 では足りないが、2000 未満では十分なデータを操作しているときに、制限を上げたい場合。 たとえば、顧客リストがあり、その顧客数が 1000 を超えることがないとわかっている場合、委任を無視して、常に 1000 のレコードすべてが返されるようにアプリをデザインできます。
テストで役立つように制限を 1 または 10 に減らす場合。 アプリで問題を起こしているのが委任できない関数であるかどうかが不確実なシナリオでは、制限を下げてテストしてください。 この制限を 1 に設定し、ギャラリーにレコードが 1 つしか表示されない場合、委任できない関数であったことがわかります。 この設定により、早くトラブルシューティングができるようになります。
委任できない関数
前のユニットでは、委任できる関数と、さまざまなデータ ソースへの関連について学習しました。 そのユニットでは扱っていない、その他のすべての関数では委任ができません。 委任がサポートされていない主な関数は次のとおりです。
First、FirstN、Last、LastN
Choices
Concat
Collect、ClearCollect (これらの関数はどちらも委任の警告を返しませんが、委任不可です)
CountIf、RemoveIf、UpdateIf
GroupBy、Ungroup
これらの関数はすべて委任可能なわけではありません。 したがって、これらを式に追加すると、前の例のとおり、以前は委任可能であった関数が委任不可になる場合があります。
部分的にサポートされた、委任可能な関数
下のテーブル シェーピングの関数は、部分的に委任可能と見なされます。 つまり、引数の式は委任できます。 ただし、これらの関数の出力は、委任されていないレコードの制限の対象になります。
AddColumns
DropColumns
ShowColumns
RenameColumns
よくあるパターンとしては、データベース用語で一般に Join と呼ばれる、1 つのテーブルから別のテーブルに情報を統合する AddColumns と LookUp を使用することです。 以下にその例を示します。
AddColumns( Products, "Supplier Name", LookUp( Suppliers,
Suppliers.ID = Product.SupplierID ).Name )
Products および Suppliers が潜在的に委任可能なデータ ソースであり、LookUp 関数が委任可能なカテゴリ内にあっても、AddColumns 関数は部分的な委任可能性を持ちます。 したがって、この式全体の結果は、Products データ ソースの最初のセグメントに制約されたままになります。
LookUp 関数とその関連データ ソースを使用すると委任が可能になり、膨大なデータセット全体での Suppliers の発見が容易になりますが、注意点もあります。 LookUp では、Products の初期レコードごとにデータ ソースへの個別のクエリが必要となり、その結果、ネットワーク活動が増加します。 ただし、Suppliers データセットが比較的小さく安定している場合は、アプリ内でデータ ソースをキャッシュするという代替アプローチもあります。 アプリの初期化中に Collect 呼び出しを使用 (開始画面で OnVisible を使用) すると、その後の LookUp 操作をキャッシュされたデータ ソース内で直接行うことができ、ネットワーク チャターが緩和されます。