モニターでキャンバス アプリをデバッグする

  • [アーティクル]

規定では、すべてのキャンバス アプリでモニターを使用できます。 モニターを使用すると、Power Apps Studio でのオーサリング体験中にキャンバスアプリで発生するイベントを追跡できます、またはモニターを使用して、公開されたバージョンのキャンバス アプリをデバッグできます。 詳細情報: モニターの概要

キャンバス アプリでモニターを開始する方法

アプリを作成するときにモニターを開くには

  1.  Power Apps にサインインします。

  2.  新しいアプリを作成するか 既存のアプリを編集 します。

  3. 左側のペインで、 詳細ツール を選択します。

  4.  モニターを開く を選択します。

    モニターを開く

このアクションは、新しいブラウザ タブでモニターを開き、既存の Power Apps Studio セッションに接続します。

モニター - 開いている

現在のモニタリング セッションを次のように示す通知が スタジオ セッション として上部に表示されます。

ヒント

モニターはアプリに影響を与えません。 モニターは、テスト環境または運用環境の任意のアプリで使用できます。

公開されたアプリのモニターを開く

モニターを使用して、公開済みアプリを Web プレーヤーでデバッグすることもできます。

公開されたアプリのモニターを開くには

  1.  Power Apps にサインインします。

  2. 左側のペインで、 アプリを選択します。

  3. 一覧からアプリを選択します。

  4. メニューから  モニター  を選択します。 あるいは、 その他のコマンド  (...) を選択してから、 モニター を選択することもできます。

    公開されたアプリのモニターを開く

  5. 公開されたアプリの再生 を選択します。

    公開アプリを再生する

このアクションは、新しいブラウザ タブで公開アプリを開き、現在のモニターセッションに接続します。 アプリが Web プレーヤーに読み込まれると、公開されたアプリを操作すると、すぐにモニターにイベントが表示されます。

モニターには、現在開いているモニタリング セッションがアプリの公開バージョン用であるという通知も表示されます。

公開されたアプリ セッション

Power Apps モバイルで実行されているアプリの場合 (プレビュー)

上記の手順に従いますが、公開されたアプリを再生する の代わりに モニターリンクをコピー 選択します。 デバイスにコピーしたリンクを使用して、公開されたアプリの監視対象セッションを開きます。 ブラウザーではなく、Power Apps モバイル を使用してリンクを開いているか確認します。

注意

モニターリンクをコピー は https://make.preview.powerapps.com で利用可能です

監視リンクのコピー。

設定: 公開されたアプリのデバッグ

公開されたアプリのモニターでソース式を表示する場合は、アプリで式を公開するための設定をオンにする必要があります。 この設定は、従来の開発でデバッグ ファイルを生成するのと似ています。 アプリでのソース式の公開はオプションです。 この設定がオフの場合でも、アプリで発生しているイベントを確認することはできますが、これらのイベントを特定の式や数式にマッピングすることはできません。

この設定を有効にするには、ファイル > 設定に移動し、公開されたアプリをデバッグするをオンにします。

注意

この設定を有効にすると、すべてのユーザーのアプリのパフォーマンスに悪影響を及ぼします。 悪影響を最小限に抑えるために、公開されたアプリをデバッグするときにソース式を表示する必要がなくなったらすぐに、この設定を無効にします。

公開されたアプリのデバッグ

モニターでイベントを表示する

アプリからイベントを表示するには、Power Apps Studio でアプリを再生します。 モニターは、発生中のイベントの表を特定の詳細とともに表示します。

発生時にイベントを表示する

例: モニターでキャンバス アプリを使用する

この例では、Northwind サンプル ソリューション に含まれる  Northwind サンプル ソリューション を使用します。

Northwind サンプル ソリューション  は、サンプル データを Microsoft Dataverse にロードするキャンバス アプリです。 新しいアプリを作成するか、または既存のアプリを代わりに編集することもできます。

背景

アプリがデプロイされ、アプリの初期バージョンでパフォーマンスが低下するシナリオを考えてみます。 アプリはまた、明確なパターンのないエラーを断続的に生成します。 アプリでのデータの読み込みはほとんどの場合成功しますが、失敗することもあります。

モニターにチェックを入れると、期待どおりのデータ操作が表示されます。 ただし、HTTP ステータス コード 429 の応答もいくつか表示されます。これは、特定の時間枠でリクエストが多すぎることを示しています。

このようなイベントを選択すると、"レート制限を超えました。 XX 秒後に再試行してください。" というエラーが表示されます。

シナリオの例 - エラー 429

分析

リクエストが抑制されている理由を理解するには、問題をさらに分析する必要があります。 監視では、 createRow 呼び出しごとに、 ProgressCount.Text プロパティからのそれぞれ異なるエンティティに対する  getRows 要求がいくつかあることがわかります。 これらのエンティティは、アプリが行を作成するエンティティではありません。  ProgressCount.Text  式は、次の図に示すように、数式はモニターに表示されます。

エラー 429 - 式

追加されたレコードごとに、式が再評価され、 CountRows がいくつかのエンティティで呼び出されます。 この動作により、ログで  getRows  になります、なぜなら CountRows  は Dataverse に委任されていないからです。レコードを追加する単一要求ごとに、各エンティティの行をカウントする 12 の追加要求を作成している可能性があります。

これらの余分なリクエストは断続的にエラーを引き起こします。Dataverseプラットフォームはサービスへのリクエストを抑制しているからです。 これは、全体的なパフォーマンスの問題も説明しています。

次の手順

モニターでの共同作業によるデバッグ

関連項目

高度なモニタリング
モニターでモデル駆動型アプリをデバッグする

注意

ドキュメントの言語設定についてお聞かせください。 簡単な調査を行います。 (この調査は英語です)

この調査には約 7 分かかります。 個人データは収集されません (プライバシー ステートメント)。