Power BI 埋め込みを使用してスケーラブルなマルチテナント アプリケーションを開発する

この記事では、最高レベルのスケーラビリティ、パフォーマンス、セキュリティを実現しながら、Power BI コンテンツを埋め込むマルチテナント アプリケーションを開発する方法について説明します。 "サービス プリンシパル プロファイル" を使用してアプリケーションを設計および実装することで、対象ユーザーである 100,000 人以上のユーザーにレポートを配信できる、数万人の顧客テナントで構成されたマルチテナント ソリューションを作成して管理できます。

"サービス プリンシパル プロファイル" は、Power BI で組織のコンテンツをより簡単に管理し、容量をより効率的に使用できるようにする機能です。 ただし、サービス プリンシパル プロファイルを使用すると、アプリケーションの設計が複雑になることがあります。 したがって、大きな規模を達成する必要がある場合にだけ使用する必要があります。 サービス プリンシパル プロファイルは、多数のワークスペースがあり、アプリケーション ユーザーが 1,000 人を超えている場合に使用することをお勧めします。

注意

サービス プリンシパル プロファイルを使用する価値は、スケーリングの必要性が高まるにつれて、また、最高レベルのセキュリティとテナントの分離を実現する必要性に応じて増加します。

Power BI の埋め込みは、"組織向け埋め込み" と "顧客向け埋め込み" という 2 つの異なる埋め込みシナリオを使用して実現できます。

組織向け埋め込みシナリオは、アプリケーションの対象ユーザーが "内部" ユーザーで構成されている場合に適用されます。 内部ユーザーには組織アカウントがあり、Microsoft Entra ID で認証する必要があります。 このシナリオでは、Power BI はサービスとしてのソフトウェア (SaaS) です。 これは "ユーザー所有データ" と呼ばれることもあります。

顧客向け埋め込みシナリオは、アプリケーションの対象ユーザーが "外部" ユーザーで構成されている場合に適用されます。 そのアプリケーションでユーザーの認証を行います。 Power BI コンテンツにアクセスするために、このアプリケーションは埋め込み ID (Microsoft Entra サービス プリンシパルまたはマスター ユーザー アカウント) に依存して、Microsoft Entra で認証します。 このシナリオでは、Power BI はサービスとしてのプラットフォーム (PaaS) です。 これは "アプリ所有データ" と呼ばれることもあります。

注意

重要なこととして、サービス プリンシパル プロファイル機能は "顧客向け埋め込み" シナリオで使用するために設計されたものであることを理解しておいてください。 それは、このシナリオにより、ISV とエンタープライズ組織が多数のユーザーと多数の顧客テナントに対して、より大規模に埋め込むことができるからです。

マルチテナント アプリケーション開発

Microsoft Entra に慣れている場合は、テナントという単語が Microsoft Entra テナントを連想させるかも知れません。 ただし、Power BI コンテンツを埋め込むマルチテナント ソリューションを構築するコンテキストでは、テナントの概念が異なります。 このコンテキストでは、Power BI コンテンツを埋め込む各顧客に代わって、"顧客向け埋め込み" シナリオを使用してアプリケーションで "顧客テナント"が作成されます。 通常は、1 つの Power BI ワークスペースを作成して各顧客テナントをプロビジョニングします。

スケーラブルなマルチテナント ソリューションを作成するには、新しい顧客テナントの作成を自動化できる必要があります。 新しい顧客テナントのプロビジョニングには、通常、Power BI REST API を使用して新しい Power BI ワークスペースを作成するコードの記述、Power BI Desktop (.pbix) ファイルのインポートによるセマンティック モデルの作成、データ ソース パラメーターの更新、データ ソース資格情報の設定、およびスケジュールされたセマンティック モデルの更新の設定が含まれます。 次の図は、レポートやセマンティック モデルなどの Power BI 項目をワークスペースに追加して、顧客テナントを設定する方法を示しています。

"顧客向け埋め込み" シナリオを使用するアプリケーションを開発する場合は、Power BI REST API 呼び出しを行うために埋め込み ID を使用できます。これは、マスター ユーザー アカウントまたはサービス プリンシパルのいずれかです。 運用アプリケーションにはサービス プリンシパルを使用することをお勧めします。 これは最高のセキュリティを提供します。このため、Microsoft Entra が推奨するアプローチです。 また、より優れた自動化とスケールをサポートし、管理オーバーヘッドが軽減されます。 ただし、セットアップと管理には Power BI 管理者権限が必要です。

サービス プリンシパルを使用すると、ユーザーが多要素認証 (MFA) を使用してサインインする必要がある環境での認証エラーなど、マスター ユーザー アカウントに関連する一般的な問題を回避できます。 サービス プリンシパルを使用することは、"顧客向け埋め込み" シナリオが、SaaS の発想ではなく PaaS の発想を使用して Power BI コンテンツを埋め込むことに基づいているという考え方にも一致します。

1,000 ワークスペースの制限

"顧客向け埋め込み" シナリオを実装するマルチテナント環境を設計する場合は、埋め込み ID に 1,000 個を超えるワークスペースへのアクセスを許可できないことを考慮してください。 Power BI サービスでは、REST API 呼び出しを行うときのパフォーマンス向上のために、この制限が適用されます。 この制限の理由は、Power BI で各 ID のセキュリティ関連メタデータがどのように維持されるかに関連しています。

Power BI では、ID でアクセスできるワークスペースとワークスペース項目を追跡するためにメタデータが使用されます。 実際には、Power BI では、認証サブシステム内の ID ごとに個別のアクセス制御リスト (ACL) を保持する必要があります。 ID で REST API 呼び出しを行ってワークスペースにアクセスする場合、それが承認されていることを確認するために、Power BI によって ID の ACL に対してセキュリティ チェックが行われます。 ターゲット ワークスペースが ACL 内にあるかどうかを判断するのにかかる時間は、ワークスペースの数が増えるにつれて指数関数的に増加します。

注意

Power BI では、1,000 ワークスペースという制限がコードを通して適用されることはありません。 そうしようと思えば、1,000 個を超えるワークスペースに埋め込み ID を追加しても、REST API 呼び出しは正常に実行されます。 ただし、アプリケーションは "サポート対象外" の状態に移行するため、Microsoft サポートに支援を求めようとした場合に影響を受ける可能性があります。

2 つのマルチテナント アプリケーションがそれぞれ 1 つのサービス プリンシパルを使用するように設定されているシナリオについて考えてみます。 ここで、最初のアプリケーションで 990 個のワークスペースを作成し、2 番目のアプリケーションで 1,010 個のワークスペースを作成したとします。 サポートの観点から見ると、最初のアプリケーションはサポート対象の境界内にありますが、2 番目のアプリケーションはそうではありません。

次に、これら 2 つのアプリケーションを純粋にパフォーマンスの観点から比較してみましょう。 それほど大きな違いはありません。なぜなら、両方のサービス プリンシパルの ACL で、パフォーマンスがある程度低下するポイントまで ACL のメタデータの増加が許可されているためです。

重要な観察事項は次のとおりです。サービス プリンシパルによって作成されたワークスペースの数は、パフォーマンスとスケーラビリティに直接影響します。 100 個のワークスペースのメンバーであるサービス プリンシパルの場合、1,000 個のワークスペースのメンバーであるサービス プリンシパルよりも高速に REST API 呼び出しが実行されます。 同様に、10 個のワークスペースのみのメンバーであるサービス プリンシパルの場合、100 個のワークスペースのメンバーであるサービス プリンシパルよりも高速に REST API 呼び出しが実行されます。

重要

パフォーマンスとスケーラビリティの観点からは、サービス プリンシパルがメンバーであるワークスペースの最適な数は "1 つだけ" です。

セマンティック モデルとデータ ソース資格情報の分離を管理する

マルチテナント アプリケーションを設計する際のもう 1 つの重要な側面は、顧客のテナントを分離することです。 ある顧客テナントのユーザーに、別の顧客テナントに属するデータが表示されないことが重要です。 したがって、セマンティック モデルの所有権とデータ ソース資格情報を管理する方法を理解する必要があります。

セマンティック モデルの所有権

各 Power BI セマンティック モデルには 1 人の所有者が存在し、それはユーザー アカウントまたはサービス プリンシパルにすることができます。 スケジュールされた更新を設定し、セマンティック モデル パラメーターを設定するには、セマンティック モデルの所有権が必要です。

ヒント

Power BI サービスでは、セマンティック モデルの設定を開くことで、セマンティック モデルの所有者を特定できます。

必要に応じて、セマンティック モデルの所有権を別のユーザー アカウントまたはサービス プリンシパルに譲渡できます。 これは Power BI サービスで、または REST API の TakeOver 操作を使用して行うことができます。 サービス プリンシパルを使用して新しいセマンティック モデルを作成するために Power BI Desktop ファイルをインポートすると、サービス プリンシパルがセマンティック モデルの所有者として自動的に設定されます。

データ ソース資格情報

セマンティック モデルをその基になるデータ ソースに接続するには、セマンティック モデルの所有者がデータ ソースの資格情報を設定する必要があります。 データ ソース資格情報は、Power BI によって暗号化され、キャッシュされます。 その時点から、Power BI でそれらの資格情報を使用して、データを更新するとき (インポートのストレージ テーブルの場合)、またはパススルー クエリを実行するとき (DirectQuery ストレージ テーブルの場合) に、基になるデータ ソースで認証が行われます。

新しい顧客テナントをプロビジョニングするときに、一般的な設計パターンを適用することをお勧めします。 サービス プリンシパルの ID を使用して、一連の REST API 呼び出しを実行できます。

1. 新しいワークスペースを作成します。
2. 新しいワークスペースを専用の容量に関連付けます。
3. セマンティック モデル作成するために、Power BI Desktop ファイルをインポートします。
4. そのセマンティック モデルのセマンティック モデル ソース資格情報を設定します。

これらの REST API 呼び出しが完了すると、サービス プリンシパルは新しいワークスペースの管理者になり、セマンティック モデルとデータ ソース資格情報の所有者になります。

重要

セマンティック モデルのデータ ソース資格情報はワークスペース レベルにスコープが設定されているという一般的な誤解があります。 そうではありません。 データ ソース資格情報はサービス プリンシパル (またはユーザー アカウント) にスコープが設定され、そのスコープは Microsoft Entra テナント内のすべての Power BI ワークスペースにまで拡張されます。

サービス プリンシパルを使用すると、次の図に示すように、顧客テナント間の異なるワークスペース内のセマンティック モデルによって共有されるデータ ソース資格情報を作成できます。

データ ソース資格情報が、異なる顧客テナントに属するセマンティック モデルによって共有されている場合、顧客テナントは完全には分離されません。

サービス プリンシパル プロファイルより前の設計戦略

サービス プリンシパル プロファイル機能を使用できるようになる前の設計戦略を理解することは、この機能の必要性を理解するのに役立ちます。 そうなる前は、開発者は次の 3 つの設計戦略のいずれかを使用してマルチテナント アプリケーションを構築していました。

• 単一サービス プリンシパル
• サービス プリンシパル プール
• ワークスペースごとに 1 つのサービス プリンシパル

これらの設計戦略には、それぞれ長所と短所があります。

単一サービス プリンシパルの設計戦略では、Microsoft Entra アプリの登録を 1 回限り作成する必要があります。 そのため、Microsoft Entra アプリの登録を追加作成する必要がなく、他の 2 つの設計戦略よりも管理オーバーヘッドが少なくなります。 また、この戦略は、REST API 呼び出しを行うときにサービス プリンシパル間で呼び出しコンテキストを切り替える追加のコードを記述する必要がないため、最も簡単に設定できます。 ただし、この設計戦略の問題点は、スケーリングされないということです。 サポートされるのは、最大 1,000 個のワークスペースまで拡張できる 1 個のマルチテナント環境のみです。 また、サービス プリンシパルに多数のワークスペースへのアクセスが許可されるため、パフォーマンスは確実に低下します。 単一のサービス プリンシパルが、すべての顧客テナントのすべてのセマンティック モデルとすべてのデータ資格情報の所有者になるため、顧客テナントの分離にも問題があります。

サービス プリンシパル プールの設計戦略は、1,000 ワークスペースという制限を回避するために一般的に使用されます。 これにより、適切な数のサービス プリンシパルをプールに追加することで、アプリケーションで任意の数のワークスペースにスケーリングできます。 たとえば、5 つのサービス プリンシパルからなるプールを使用すると、最大 5,000 個までワークスペースをスケールアップでき、80 個のサービス プリンシパルからなるプールを使用すると、最大 80,000 個までワークスペースをスケールアップできる、というようになります。 ただし、この戦略は多数のワークスペースへのスケーリングが可能ですが、いくつかの欠点があります。 最初に、REST API 呼び出しを行うときにサービス プリンシパル間でコンテキスト切り替えができるように、追加のコードを記述し、メタデータを格納する必要があります。 次に、プール内のサービス プリンシパルの数を増やす必要がある場合は常に Microsoft Entra アプリの登録を作成する必要があるため、より多くの管理作業が必要になります。

さらに、サービス プリンシパル プールの戦略では、サービス プリンシパルを数百個のワークスペースのメンバーにできるため、パフォーマンスのための最適化はされていません。 また、サービス プリンシパルが顧客テナント間で共有されるセマンティック モデルとデータ資格情報の所有者になる可能性があるため、顧客テナント分離の観点から見て理想的ではありません。

ワークスペースごとに 1 つのサービス プリンシパルという設計戦略では、顧客テナントごとにサービス プリンシパルを作成する必要があります。 理論的な観点からは、これは最適なソリューションを提供する戦略です。REST API 呼び出しのパフォーマンスを最適化しながら、ワークスペース レベルでセマンティック モデルとデータ ソース資格情報を真に分離できるからです。 ただし、理論的に最も効果的なものが必ずしも実際に最適とは限りません。 これは、顧客テナントごとにサービス プリンシパルを作成するという要件は、多くの組織にとって実用的ではないからです。 これは、一部の組織に正式な承認プロセスが存在するか、Microsoft Entra アプリの登録を作成するために過剰な管理を伴うためです。 これらの理由により、カスタム アプリケーションに対して、Microsoft Entra アプリ登録の作成に必要な権限をオンデマンドで、かつソリューションに必要な自動化された方法で付与できなくなる可能性があります。

あまり一般的なシナリオではありませんが、カスタム アプリケーションに適切なアクセス許可が付与されている場合は、Microsoft Graph API を使用して、必要に応じて Microsoft Entra アプリの登録を作成できます。 ただし、カスタム アプリケーションは、Microsoft Entra アプリの登録ごとに何らかの方法で認証資格情報を追跡する必要があるため、開発とデプロイが複雑になることがよくあります。 また、個々のサービス プリンシパルのアクセス トークンを認証して取得する必要がある場合は常に、これらの資格情報へのアクセス権を取得する必要があります。

サービス プリンシパル プロファイル

サービス プリンシパル プロファイルは、Power BI で組織のコンテンツをより簡単に管理し、容量をより効率的に使用できるようにするために設計された機能です。 開発者の労力とオーバーヘッドを最小限に抑えて 3 つの特定の課題に対処するのに役立ちます。 次のような課題があります。

• 多数のワークスペースにスケーリングする。
• REST API 呼び出しのパフォーマンスを最適化する。
• 顧客テナント レベルでセマンティック モデルとデータ ソース資格情報を分離する。

サービス プリンシパル プロファイルを使用してマルチテナント アプリケーションを設計する場合、関連する弱点を回避しながら、(前のセクションで説明した) 3 つの設計戦略の長所を活用できます。

サービス プリンシパル プロファイルは、Power BI のコンテキスト内で作成されるローカル アカウントです。 サービス プリンシパルで Profiles REST API 操作を使用して、新しいサービス プリンシパル プロファイルを作成できます。 サービス プリンシパルを使用すると、次の図に示すように、カスタム アプリケーション用の独自のサービス プリンシパル プロファイルのセットを作成し、管理できます。

サービス プリンシパルと、それによって作成されたサービス プリンシパル プロファイルの間には、常に親子関係があります。 スタンドアロン エンティティとしてサービス プリンシパル プロファイルを作成することはできません。 代わりに、特定のサービス プリンシパルを使用してサービス プリンシパル プロファイルを作成し、そのサービス プリンシパルがプロファイルの親として機能します。 さらに、サービス プリンシパル プロファイルは、ユーザー アカウントやその他のサービス プリンシパルには表示されません。 サービス プリンシパル プロファイルは、それを作成したサービス プリンシパルでのみ表示および使用できます。

サービス プリンシパル プロファイルが Microsoft Entra に認識されない

サービス プリンシパル自体とその基になる Microsoft Entra アプリの登録は Microsoft Entra には認識されていますが、サービス プリンシパル プロファイルについては Microsoft Entra ID は何も認識していません。 これは、サービス プリンシパル プロファイルは Power BI によって作成され、Power BI のセキュリティと承認を制御する Power BI サービス サブシステムにのみ存在するためです。

サービス プリンシパル プロファイルが Microsoft Entra ID に認識されないという事実には、利点と欠点の両方があります。 主な利点は、"顧客向け埋め込み" シナリオのアプリケーションでサービス プリンシパル プロファイルを作成するために、特別な Microsoft Entra アクセス許可が不要な点です。 これはまた、アプリケーションで Microsoft Entra とは別のローカル ID のセットを作成して管理できることを意味します。

ただし、欠点もあります。 サービス プリンシパル プロファイルは Microsoft Entra では認識されないため、Microsoft Entra グループにサービス プリンシパル プロファイルを追加して、ワークスペースへのアクセスを暗黙的に許可することはできません。 また、Azure SQL Database や Azure Synapse Analytics などの外部データ ソースは、データベースに接続するときにサービス プリンシパル プロファイルを ID として認識できません。 そのため、各顧客テナントに固有の認証資格情報がある個別のサービス プリンシパルを使用してこれらのデータ ソースに接続する必要がある場合は、ワークスペースごとに 1 つのサービス プリンシパルという設計戦略 (各顧客テナントのサービス プリンシパルを作成する) の方が適している可能性があります。

最上級のセキュリティ プリンシパルであるサービス プリンシパル プロファイル

サービス プリンシパル プロファイルは Microsoft Entra では認識されませんが、Power BI ではそれらが最上級のセキュリティ プリンシパルとして認識されます。 ユーザー アカウントやサービス プリンシパルと同様に、ワークスペース ロールにサービス プリンシパル プロファイルを (管理者またはメンバーとして) 追加できます。 セマンティック モデルの所有者とデータ ソース資格情報の所有者にすることもできます。 このような理由から、新しい顧客テナントごとに新しいサービス プリンシパル プロファイルを作成することをお勧めします。

ヒント

サービス プリンシパル プロファイルを使用して "顧客向け埋め込み" シナリオのアプリケーションを開発する場合は、1 つの Microsoft Entra アプリ登録を作成するだけで、アプリケーションに 1 つのサービス プリンシパルを提供できます。 このアプローチでは、アプリケーションを運用環境にデプロイした後、継続的に追加の Microsoft Entra アプリ登録を作成する必要がある他のマルチテナント設計戦略と比較して、管理オーバーヘッドが大幅に削減されます。

REST API 呼び出しをサービス プリンシパル プロファイルとして実行

アプリケーションでサービス プリンシパル プロファイルの ID を使用して、REST API 呼び出しを実行できます。 つまり、一連の REST API 呼び出しを実行して、新しい顧客テナントをプロビジョニングし、設定できます。

1. サービス プリンシパル プロファイルで新しいワークスペースが作成されると、Power BI によってそのプロファイルがワークスペース管理者として自動的に追加されます。
2. サービス プリンシパル プロファイルで Power BI Desktop ファイルをインポートしてセマンティック モデルを作成すると、Power BI によってそのプロファイルがセマンティック モデルの所有者として設定されます。
3. サービス プリンシパル プロファイルでデータ ソース資格情報を設定すると、Power BI によってそのプロファイルがデータ ソース資格情報の所有者として設定されます。

サービス プリンシパルには Power BI 内の ID があり、それはプロファイルの ID とは別の ID であることを理解しておくことが重要です。 これにより、開発者としての選択肢が提供されます。 REST API 呼び出しは、サービス プリンシパル プロファイルの ID を使用して実行できます。 または、プロファイルなしで REST API 呼び出しを実行することもできます。その場合、親サービス プリンシパルの ID が使用されます。

サービス プリンシパル プロファイルを作成、表示、または削除する場合は、REST API 呼び出しを親サービス プリンシパルとして実行することをお勧めします。 他のすべての REST API 呼び出しの実行には、サービス プリンシパル プロファイルを使用する必要があります。 これらの他の呼び出しを使用して、ワークスペースの作成、Power BI Desktop ファイルのインポート、セマンティック モデル パラメーターの更新、データ ソース資格情報の設定を行うことができます。 また、ワークスペース項目のメタデータを取得し、埋め込みトークンを生成することもできます。

例として、Contoso という名前の顧客用に顧客テナントを設定する必要がある場合を考えてみましょう。 最初の手順では、REST API 呼び出しを行って、表示名を Contoso に設定したサービス プリンシパル プロファイルを作成します。 この呼び出しは、サービス プリンシパルの ID を使用して行われます。 残りすべてのセットアップ手順では、サービス プリンシパル プロファイルを使用して以下のタスクを実行します。

1. ワークスペースを作成します。
2. ワークスペースを容量に関連付けます。
3. Power BI Desktop ファイルをインポートします。
4. セマンティック モデルのパラメーターを設定します。
5. データ ソースの資格情報を設定します。
6. スケジュールされたデータ更新を設定します。

ワークスペースとそのコンテンツへのアクセスは、顧客テナントの作成に使用されたサービス プリンシパル プロファイルの ID を使用して行う必要があります。このことを理解しておくことが重要です。 また、親サービス プリンシパルはワークスペースまたはそのコンテンツにアクセスする必要がないことを理解することも重要です。

ヒント

注意: REST API 呼び出しを行うときは、サービス プリンシパルを使用してサービス プリンシパル プロファイルを作成および管理し、サービス プリンシパル プロファイルを使用して Power BI コンテンツの作成、設定、アクセスを行います。

Profiles REST API 操作を使用する

Profiles REST API 操作グループは、サービス プリンシパル プロファイルを作成および管理する操作で構成されています。

• Create Profile
• Delete Profile
• Get Profile
• Get Profiles
• Update Profile

サービス プリンシパル プロファイルを作成する

サービス プリンシパル プロファイルを作成するには、Create Profile REST API 操作を使用します。 新しいテナントの表示名を指定するには、要求本文で displayName プロパティを設定する必要があります。 この値は、サービス プリンシパルが所有するすべてのプロファイルで一意である必要があります。 その表示名を持つ別のプロファイルがサービス プリンシパルに既に存在する場合、呼び出しは失敗します。

呼び出しが成功すると、id プロパティが返されます。これはプロファイルを表す GUID です。 サービス プリンシパル プロファイルを使用するアプリケーションを開発する場合は、プロファイルの表示名とその ID 値をカスタム データベースに格納することをお勧めします。 そうすることで、アプリケーションで ID を簡単に取得できます。

Power BI .NET SDK を使用してプログラミングする場合は、新しいプロファイルを表す ServicePrincipalProfile オブジェクトを返す Profiles.CreateProfile メソッドを使用できます。 これにより、id プロパティ値を簡単に特定できます。

サービス プリンシパル プロファイルを作成し、ワークスペースへのアクセスを許可する例を次に示します。

// Create a service principal profile
string profileName = "Contoso";

var createRequest = new CreateOrUpdateProfileRequest(profileName);
var profile = pbiClient.Profiles.CreateProfile(createRequest);

// Retrieve the ID of the new profile
Guid profileId = profile.Id;

// Grant workspace access
var groupUser = new GroupUser {
    GroupUserAccessRight = "Admin",
    PrincipalType = "App",
    Identifier = ServicePrincipalId,
    Profile = new ServicePrincipalProfile {
        Id = profileId
    }
};

pbiClient.Groups.AddGroupUser(workspaceId, groupUser);

Power BI サービスのワークスペースの [アクセス] ペインで、セキュリティ プリンシパルを含め、どの ID にアクセス許可があるかを確認できます。

サービス プリンシパル プロファイルを削除する

サービス プリンシパル プロファイルを削除するには、Delete Profile REST API 操作を使用します。 この操作は、親サービス プリンシパルによってのみ呼び出すことができます。

Power BI .NET SDK を使用してプログラミングする場合は、Profiles.DeleteProfile メソッドを使用できます。

すべてのサービス プリンシパル プロファイルを取得する

呼び出し元のサービス プリンシパルに属するサービス プリンシパル プロファイルの一覧を取得するには、Get Profiles REST API 操作を使用します。 この操作により、各サービス プリンシパル プロファイルの id および displayName プロパティを含む JSON ペイロードが返されます。

Power BI .NET SDK を使用してプログラミングする場合は、Profiles.GetProfiles メソッドを使用できます。

サービス プリンシパル プロファイルを使用して REST API 呼び出しを実行する

サービス プリンシパル プロファイルを使用して REST API 呼び出しを行う場合、2 つの要件があります。

• Authorization ヘッダーで親サービス プリンシパルのアクセス トークンを渡す必要があります。
• サービス プリンシパル プロファイルの ID を値に持つ X-PowerBI-profile-id という名前のヘッダーを含める必要があります。

Power BI .NET SDK を使用している場合は、サービス プリンシパル プロファイルの ID を渡すことによって、X-PowerBI-profile-id ヘッダーの値を明示的に設定できます。

// Create the Power BI client
var tokenCredentials = new TokenCredentials(GetACcessToken(). "Bearer");
var uriPowerBiServiceApiRoot = new Uri(uriPowerBiServiceApiRoot);
var pbiClient = new PowerBIClient(uriPowerBiServiceApiRoot, tokenCredentials);

// Add X-PowerBI-profile-id header for service principal profile
string profileId = "11111111-1111-1111-1111-111111111111";
pbiClient.HttpClient.DefaultRequestHeaders.Add("X-PowerBI-profile-id", profileId);

// Retrieve workspaces by using the identity of service principal profile
var workspaces = pbiClient.Groups.GetGroups();

上記の例に示したように、X-PowerBI-profile-id ヘッダーを PowerBIClient オブジェクトに追加すると、Groups.GetGroups などのメソッドを簡単に呼び出して、それらがサービス プリンシパル プロファイルを使用して実行されるようにすることができます。

PowerBIClient オブジェクトの X-PowerBI-profile-id ヘッダーを設定するよりも便利な方法があります。 プロファイルの ID をコンストラクターに渡すことによって、オブジェクトを初期化できます。

// Create the Power BI client
string profileId = "11111111-1111-1111-1111-111111111111";

var tokenCredentials = new TokenCredentials(GetACcessToken(). "Bearer");
var uriPowerBiServiceApiRoot = new Uri(uriPowerBiServiceApiRoot);
var pbiClient = new PowerBiClient(uriPowerBiServiceApiRoot, tokenCredentials, profileId);

マルチテナント アプリケーションをプログラミングするときは、親サービス プリンシパルとしての呼び出しの実行とサービス プリンシパル プロファイルとしての呼び出しの実行を切り替える必要がある可能性があります。 コンテキスト切り替えを管理する便利な方法は、PowerBIClient オブジェクトを格納するクラス レベルの変数を宣言することです。 その後、変数に正しいオブジェクトを設定するヘルパー メソッドを作成できます。

// Class-level variable that stores the PowerBIClient object
private PowerBIClient pbiClient;

// Helper method that sets the correct PowerBIClient object
private void SetCallingContext(string profileId = "") {

    if (profileId.Equals("")) {
        pbiClient = GetPowerBIClient();    
    }
    else {
        pbiClient = GetPowerBIClientForProfile(new Guid(profileId));
    }
}

サービス プリンシパル プロファイルを作成または管理する必要がある場合は、パラメーターなしで SetCallingContext メソッドを呼び出すことができます。 この方法で、サービス プリンシパルの ID を使用してプロファイルを作成および管理できます。

// Always create and manage profiles as the service principal
SetCallingContext();

// Create a service principal profile
string profileName = "Contoso";

var createRequest = new CreateOrUpdateProfileRequest(profileName);
var profile = pbiClient.Profiles.CreateProfile(createRequest);

新しい顧客テナントのワークスペースを作成して設定する必要がある場合は、そのコードをサービス プリンシパル プロファイルとして実行する必要があります。 したがって、プロファイルの ID を渡して SetCallingContext メソッドを呼び出す必要があります。 この方法で、サービス プリンシパル プロファイルの ID を使用してワークスペースを作成できます。

// Always create and set up workspaces as a service principal profile
string profileId = "11111111-1111-1111-1111-111111111111";
SetCallingContext(profileId);

// Create a workspace
GroupCreationRequest request = new GroupCreationRequest(workspaceName);
Group workspace = pbiClient.Groups.CreateGroup(request);

特定のサービス プリンシパル プロファイルを使用してワークスペースを作成および構成したら、引き続き同じプロファイルを使用してワークスペースのコンテンツを作成および設定する必要があります。 セットアップを完了するために SetCallingContext メソッドを呼び出す必要はありません。

開発者向けサンプル

AppOwnsDataMultiTenant という名前のサンプル アプリケーションをダウンロードすることをお勧めします。

このサンプル アプリケーションは、.NET 6 と ASP.NET を使用して開発されたもので、この記事で説明されているガイダンスと推奨事項を適用する方法を示しています。 このコードを確認して、サービス プリンシパル プロファイルを使用して "顧客向け埋め込み" シナリオを実装するマルチテナント アプリケーションを開発する方法を学習できます。

関連するコンテンツ

この記事に関する詳細については、次のリソースを参照してください。

• Power BI Embedded でのマルチテナント アプリ用のサービス プリンシパル プロファイル
• マルチカスタマー アプリケーションをサービス プリンシパル プロファイル モデルに移行する
• Profiles Power BI REST API 操作グループ
• • AppOwnsDataMultiTenant サンプル アプリケーション
• 疑問がある場合 Power BI コミュニティで質問してみてください。
• Power BI チームへのご提案は、 Power BI を改善するためのアイデアをお寄せください