ポータル アプリ

完了

Power Apps ポータルを実装する主なメリットは、社外向けの Web サイトで Microsoft Dataverse のデータを簡単に表示して操作することができるという点です。

Power Apps ポータルは、社内外の対象ユーザーと対話ができるように設計されています。

ポータル アプリの機能

Power Apps ポータルは、Dataverse 上に構築されています。 このアーキテクチャには重大なメリットがあります。 Power Apps のモデル駆動型アプリの差別化機能はすべて、Power Apps ポータルに含まれている機能です。次のような機能があります。

  • 一元化された管理
  • Common Data Model
  • ロールとアクセス許可
  • フォームとビュー
  • ビジネス ルール
  • 宣言型ワークフローとアクション
  • プラグイン アーキテクチャ
  • 他のサービスとの統合
  • Dataverse の拡張性
  • 監査

Power Apps ポータルは、すべてのコンテンツを Dataverse に保存したまま、すぐに使用できる完全なコンテンツ管理システムを提供します。 その結果、Power Apps ポータル スタジオを使用してコンテンツを編集することができます。また、ポータル管理アプリを使用してコンテンツを直接編集することもできます。 さらに、堅牢な Dataverse セキュリティ モデルを使用して、コンテンツを保護することができます。

Power Apps ポータルの機能を示す図。

メモ

ポータルを使用するには、環境内で Dataverse データベースを使用して、いくつかの主要なコンポーネントをインストールし、構成する必要があります。 Microsoft Dynamics 365 アプリがインストールされていない環境にポータルを一から作成することはできますが、テンプレート (顧客セルフサービス、従業員セルフサービス、パートナー、およびコミュニティ ポータル) は、Microsoft Dynamics 365 アプリに依存しています。

ポータル アーキテクチャ

Power Apps ポータルは、Dataverse のデータと直接トランザクションを行います。 データのリストとフォームを作成できます。 Power Apps ポータルでは、モデル駆動型のビューとフォームを使用する組み込みコンポーネントが用意されています。 次の図に示すように、ポータルはカスタマイズおよび拡張ができます。

Power Apps ポータル アーキテクチャの図。

Power Apps ポータルは、内部および外部の対象ユーザーに対してより安全な方法で Dataverse ソリューションを提供します。 ポータルの閲覧者は、匿名ユーザーまたは認証済みユーザーとしてポータルにアクセスできます。

Dataverse 用の Power Apps ポータル アーキテクチャの図。

Dataverse データの公開

以下のセクションでは、Dataverse のデータを公開するためのいくつかの方法について説明します。

ポータルのユース ケース

次の場合にポータル アプリの使用を検討します。

  • Dataverse を使用することで外部ユーザーおよび内部ユーザーとの対話がより安全になる
  • 顧客サービスのコミュニティ サイトまたはセルフサービス サイト
  • Dataverse データ上の CRUD
  • リソースや予算が限られている、ビジネス ユーザー、コーディングなしの構成要件
  • 応答性の高い設計、およびすべてのデバイスとブラウザーからコンテンツにアクセスできる
  • 多言語の実装
  • シングル サインオン

次の場合は注意が必要です。

  • ほとんどのデータが外部 (非 Dataverse) システムに存在している
  • ドキュメント管理、インデックス作成、検索に関して要件が厳しい。
  • ポータルへのトラフィックが非常に多いエンドユーザーのボリュームが大きい。
  • 支払の処理やオンライン ストアの管理など、e コマースの要件を満たす必要がある。
  • Power Apps のライセンスを持つユーザーが直接アクセスする方が適切なユース ケース。

認証

Power Apps ポータルは、認証ユーザーおよび非認証ユーザーが利用できます。 ソリューション アーキテクトは、認証済みのアクセスが使用されるかどうか、および Microsoft Azure B2C、Microsoft Entra ID、または別の ID プロバイダーを通じてユーザーが認証される方法を把握しておく必要があります。

重要

認証にはローカルに保存したアカウントの使用を避ける必要があります。

実装の考慮事項

ポータル アプリを実装する場合、ソリューション アーキテクトは次の重要な要因を考慮する必要があります。

  • 空のテンプレートまたは Dynamics 365 テンプレートが使用されるか
  • テンプレートから要件へのギャップ
  • Liquid テンプレートの高度なスキルを持つリソースを必要とするポータル ページはどれか
  • 認証済みユーザーがアクセスを必要とするのはどのデータか

デプロイに関する考慮事項

ビューやフォームなどのポータル資産はソリューションにパッケージ化できますが、ほとんどのポータル構成は多数のテーブル上にデータとして格納されます。 構成移行ツールは、開発から、テスト、実稼働へと移行する場合の作業の一部を軽減するのに役立ちます。

参考資料