次の方法で共有


ライブ モニターを使用したキャンバス アプリのデバッグ

ライブ モニターは、すべてのキャンバス アプリで既定で利用可能です。 ライブ モニターを使用すると、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プラットフォームはサービスへのリクエストを抑制しているからです。 これは、全体的なパフォーマンスの問題も説明しています。

次の手順

ライブ監視によるコラボレーション デバッグ

参照

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