キャンバス アプリの実行フェーズ、データの呼び出しフロ、およびパフォーマンス監視を理解する

ユーザーがキャンバス アプリを開くと、次のいくつかの段階を経て、ユーザーインターフェースを表示します。 アプリが読み込まれている間、SharePoint、Microsoft Dataverse、SQL Server (オンプレミスの)、Azure SQL データベース (オンライン)、Excel、Oracle などの データ ソース— に接続します。

この記事では、実行のさまざまなフェーズ、アプリがデータソースに接続する方法、およびパフォーマンス監視に使用できるツールについて説明します。

キャンバス アプリの実行フェーズ

キャンバス アプリは、ユーザーにインターフェースを表示する前に、実行の次のフェーズを通過します :

1. ユーザーを認証します : 初めてのユーザーに、アプリが必要とする接続で使用する認証情報を使ってサインインするよう促します。 そのユーザーが再びアプリを開くと、組織のセキュリティ ポリシーによっては、資格情報の入力が再び求められる場合があります。

2. メタデータの取得 : アプリを実行している Power Apps プラットフォームのバージョンやメタデータを取得する必要があるソースなどのメタデータを取得します。

3. アプリの初期化 : OnStart プロパティで指定されているタスクを実行します。

4. 画面のレンダリング : アプリがデータを入力するコントロールで最初の画面をレンダリングします。 ユーザーが他の画面を開くと、アプリは同じプロセスを使用してその画面を表示します。

キャンバス アプリのデータ呼び出しフロー

キャンバス アプリからのデータ呼び出しは、OData プロトコルを介してコネクタを使用し、表形式のデータ ソースにデータを送信します。OData は、バックエンド レイヤーへのフローを要求して、ターゲット データ ソースに接続し、クライアントのデータを取得するか、データをデータ ソースにコミットします。 API を有効にするアクション ベースのコネクタも同じように機能します。

OData と API 要求がキャンバス アプリでどのように移動するかを理解することで、キャンバス アプリのパフォーマンスやバックエンド データ ソースの最適化に役立ちます。

このセクションでは、さまざまなデータ ソースタイプのキャンバス アプリでデータ呼び出しがどのように流れるかについて学習します。

オンライン データソースを使用したデータ コール フロー

次の図は、キャンバスアプリ (左側) の一般的なデータ リクエストがサーバー側のレイヤーを移動し、ターゲット データ ソース (右側) に到達する方法を示しており、クライアントにデータを返しています。

前述の図の各レイヤーは、リクエストを処理する際に、高速に実行される場合もありますが、オーバーヘッドが発生する場合もあります。 多くのアプリでは、2 つの特定のスポットで一般的に顕著なオーバー ヘッドが示される可能性があります。

• バックエンド データ ソース リクエストの処理中。

• クライアント - 要求を送信している間や、—受信したデータをヒープメモリ上で操作している間に、関連する JavaScript 関数を実行して、画面に表示するデータを処理します。

オンプレミスのデータ ゲートウェイを使用したデータ呼び出しフロー

キャンバス アプリが SQL サーバーのようなオンプレミスの データ ソースに接続する場合は、オンプレミスの データ ゲートウェイ という別のレイヤーが必要です。 このゲートウェイは、オンプレミスのデータソースにアクセスするために必須となります。 プロトコルを OData プロトコル要求から SQL データ操作言語 (DML) ステートメントに変換する役割を果たします。

次の図では、オンプレミスのデータ ゲートウェイを配置してデータ要求を処理する場所と方法を示しています。

アプリがオンプレミスのデータソースを使用する場合は、データゲートウェイの場所や仕様もデータ呼び出しのパフォーマンスに影響します。

Microsoft Dataverse とのデータ フロー

Microsoft Dataverse をデータ ソースとして使用する場合、データ要求は、Azure API Management を経由せずに、—環境インスタンスに直接送信されます。 そのため、データ呼び出しのパフォーマンスは、他のデータソースと比較して高速になります。 このアプリは、新しいキャンバスアプリを作成する際、規定で Microsoft Dataverse に接続されています。

このように、データの呼び出しがどのように移動するかという高度な概念を理解した上で、アプリのパフォーマンスを確認する詳細な作業に入ることができます。 簡潔に言えば、パフォーマンスのオーバーヘッドは—クライアント、API 管理、コネクタ、オンプレミスのデータ ゲートウェイ、バックエンド データ ソースなど、どの階層でも発生する可能性があります。

パフォーマンスの測定

Power Apps 監視ツール

ブラウザーの開発者ツールを使用してパフォーマンスを確認できる一方で、Power Apps サブセットは Power Apps への監視ツールの一連の呼び出しのみを確認できます。

Power Apps 監視ツールは、データ ソースへの実際の送信内容と要求が送信され、サーバーから応答が返されるときのタイムスタンプを追跡するのに役立ちます。

監視ツールの詳細については、モニターでキャンバス アプリをデバッグするの記事を参照してください。

クライアント側でメモリ不足を測定する

メモリ消費をグラフィカルに確認するには、ブラウザーの開発者ツールを使用してメモリのプロファイルを作成します。 ヒープ サイズ、ドキュメント、ノード、リスナーを視覚化します。 Microsoft Edge (Chromium) 開発ツールの概要 に記載されているように、ブラウザを使用してアプリのパフォーマンスをプロファイリングします。 JS ヒープのメモリしきい値を超えるシナリオを確認してください。 詳細情報 : メモリの問題を修正する

次の手順

小規模データ ペイロード

参照

Power Apps の問題のトラブルシューティング

注意

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

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