次の方法で共有


REST API を使用してキャンバス アプリの機能を拡張する

Microsoft Power Platform では、REST API を使用して Power Apps のキャンバス アプリケーションの機能を拡張できます。 複雑なアルゴリズムや多くのデータソースを扱う場合、ロジックをキャンバス アプリから RESTful API に移行することは、Power Apps のキャンバス アプリケーション内の数式をシンプルに保つと同時に、より複雑な機能をサーバーサイドに移動するための良い選択です。 Power Platform カスタム コネクタを使用すると、キャンバス アプリで別のデータ ソースと同じように REST API を使用できます。

チップ

この記事では、REST API を使用して キャンバス アプリの機能を拡張する方法のシナリオ例と視覚的表現を提供します。 このソリューションは、さまざまなシナリオや業界で使用できる、一般化されたシナリオ アーキテクチャの例です。

アーキテクチャ ダイアグラム

REST API を使用して キャンバス アプリの機能を拡張するためのワークフローを示すアーキテクチャ図

Workflow

  1. キャンバス アプリ: Power Apps のキャンバス アプリ は、カスタム コネクタを使用して、Azure 関数が公開する操作にアクセスします。 ユーザーは Entra ID を使用してアプリケーションに対して認証を行い、データへのアクセスはユーザーがアクセスできるデータに制限されます。
  2. カスタム コネクタ: カスタム コネクタは、アプリケーションが REST API (この例では Azure 関数によって実装されている) から使用できる操作を記述します。 カスタム コネクタを使用することで、Power Apps のキャンバス アプリケーションは他のデータ ソースと同様にロジックを使用できます。
  3. Microsoft Entra ID アプリ: Azure 関数は、Microsoft Entra ID アプリを使用して保護されます。 2 番目の Microsoft Entra ID アプリが登録され、カスタム コネクターで構成されます。これによって Power Apps のキャンバス アプリが Azure Function 操作にアクセスできるようになります。
  4. Azure 関数: Azure 関数は、Azure Portal からカスタム コネクタをエクスポートするか、手動で構成することによって、Power Apps のキャンバス アプリケーションに公開される 1 つ以上の操作を提供する RESTful API を実装します。 Azure 関数は、Entra ID アプリ登録によって保護され、許可された発信者のみが保証されます。
  5. Azure Cosmos DB: Azure 関数は、Azure Cosmos DB、Azure SQL またはデータの管理に必要なその他のクラウド データ ストアを使用できます。 実際、この関数はロジックが複雑なため、Microsoft Dataverse でデータを処理できます。

コンポーネント

  • Power Platform 環境: In Store アプリのユーザー エクスペリエンスを実装する Power Apps などの Power Platform リソースが含まれます。 これらのリソースは、ある環境から別の環境へ (開発環境からテスト環境など) Dataverse ソリューションを使用して移動されます。
  • Power Apps: Power Apps は、ソリューションのユーザー エクスペリエンスを実装するために使用されます。 作成者は、Azure 関数の開発者が作成したカスタム コネクタをアプリケーション データ ソースとして使用してアプリケーションを構築できます。
  • カスタム コネクタ: Power Platform のカスタム コネクタは、RESTful API の操作とデータ構造を記述します。 これにより、 Power Apps キャンバス アプリケーションなどのリソースから API を簡単に使用できます。 Power Apps を使用すると、他のデータ ソースと同様に API を参照できます。

シナリオの詳細

Power Apps を使用すると、組織はカスタム ユーザー エクスペリエンスを作成でき、REST API を使用することで、ビジネス ロジックは一元化され、カスタム コネクタを使用してアプリケーションからアクセスされます。 このアプローチにより、Power Apps アプリケーションは複数のバックエンド サービスのインテグレーターとして機能し、すべてのソースからのデータとロジックを単一のビューとしてユーザーに提供することができます。 REST APIアプローチを使用すると、他の複数のシステムとの対話の複雑さをREST APIを実装するコンポーネントにシフトし、キャンバスアプリケーションの実装を簡素化すると同時に、同じユーザーエクスペリエンスを提供することもできます。

上記の例では、In Store アプリは Power Apps のキャンバス アプリケーションを使用して作成されています。 このアプリケーションを使用すると、店舗担当者は、品目が在庫切れになったときに、顧客へのバックオーダー通知要求をすばやく保存できます。 アプリケーションは、バックエンドの Azure Function 操作を記述するカスタム コネクタで構成された 1 つの操作 RecordBackorder を使用します。 この例では、Azure 関数が REST API の実装です。 このパターンを実装するには、RESTful サービスの作成を可能にする任意のテクノロジを使用できます。

このアーキテクチャは柔軟性を提供しますが、RESTful なサービスとデータ レイヤーを開発、維持するために、コードファーストの開発者の作業がさらに必要となります。 一般に、キャンバス アプリの数式が複雑になるにつれて、このタイプのアーキテクチャを検討する必要があります。 たとえば、1 つのビューを構築するために複数のデータソースが必要な場合、API レイヤーを使用することで、データ応答をサーバー サイドで整形し、より効率的にクライアントに配信できるため、パフォーマンスの高いエクスペリエンスを提供できます。 この中間層レイヤーを使用すると、サーバー側のキャッシュ レイヤーを追加して、アプリのより豊富なテレメトリを実装できます。

考慮事項

これらの考慮事項は、ワークロードの品質を向上させる一連の基本原則である Power Platform Well-Architected の柱を実行します。 詳細については、Microsoft Power Platform Well-Architected を参照してください。

信頼性

不必要な複雑さを回避するようにワークロードを設計する – カスタム コネクター経由で Power Apps アプリケーションから REST API アプローチを使用することで、不必要な複雑さを回避し、組織内の他のアプリケーションで使用できるようにロジックを集中化できます。 カスタム コネクタにより、Power Apps の作成者は他のデータソース操作と同様に RESTFul API からの操作を使用できるようになります。

回復力と可用性をテストする – ロジックを キャンバス アプリ から REST API に移行することで、API を使用するアプリとは別に API を個別にテストできるようになります。

正常性指標を測定して公開する – テレメトリーは、その正常性を追跡するために REST API コンポーネントからキャプチャする必要があります。 たとえば、Azure Monitor – Application Insights ログを使用すると、コンポーネントを適切に追跡できます。

セキュリティ

意図的なセグメンテーションと境界を作成する – アプリケーションのライフサイクル ステージをサポートするために、アプリケーションが別々の Power Platform 環境を使用し、適切なユーザーだけが各ステージにアクセスできるようにすることで、セグメンテーションのポリシーをサポートできます。 また、データの各段階を保護し、環境間で混在しないように、登録された Entra ID アプリを環境間で分離することも重要です。

オペレーショナル エクセレンス

安全な展開のプラクティスを採用する - パイプラインなどの自動展開プロセスを使用して、Power Apps アプリケーションへのあらゆる変更の展開を標準化します。 変更をテストした後にのみ、アプリケーションを運用環境に昇格させます。

展開の失敗を軽減する戦略の導入 – アプリケーションと REST API の依存関係により、どちらかのコンポーネントが更新された後にエラーが発生した場合、このロールアウトを緩和するテスト済みの戦略を確実に用意する必要があります。

パフォーマンス効率

パフォーマンス要件を満たす設計 – ソリューションのパフォーマンスとデータ量の要件を評価します。 評価には、データへのアクセス方法や、さまざまなデータソースを直接使用する Power Apps がデータソースとの交信頻度が過剰になっていないかの評価も含む必要があります。 これにより、各データ ストアに送信される個々の要求の待機時間により、パフォーマンスが低下する可能性があります。 たとえば、アプリケーションにデータ ソースの多数の行で動作するロジックがある場合、そのすべてのネットワーク トラフィックをバックエンドの Azure 関数に シフト できる可能性があります。 REST API との 対話 を 1 つに減らし、REST API は、より効果的に実行できる他の複数のデータ ソースとの対話を管理します。

ロジックの最適化 – キャンバス アプリのロジックが複雑になると、Azure Functions または同様のバックエンド RESTful API を実装することで、このロジックを再利用可能な集中型サービスにオフロードできます。 カスタム コネクタ機能を使用してこれらの RESTful API を記述すると、キャンバス アプリは構成済みの操作を他のデータ ソースと同様に使用できます。

パフォーマンスのテスト – API が作業完了時間の変化に影響を受ける場合、機能性やエラーのテストとともに、パフォーマンスのテストとベースラインの開発、そしてリリースサイクルの一部として評価することが重要です。

エクスペリエンスの最適化

効率を高める設計 – ユーザーが複数の個別のアプリケーションを操作することなく、1 つの Power Apps アプリケーションから複数のデータソースにアクセスできるアプリケーションは、ユーザーをより効率的にし、よりカスタム化されたビジュアル エクスペリエンスをうまく利用しています。

投稿者

Microsoft がこの記事を管理しています。 この記事を書いたのは、以下の寄稿者です。

作者代表: