Sviluppare applicazioni multi-tenancy scalabili con incorporamento di Power BI

Questo articolo descrive come sviluppare un'applicazione multi-tenancy che incorpora il contenuto di Power BI, ottenendo al contempo i livelli più elevati di scalabilità, prestazioni e sicurezza. Progettando e implementando un'applicazione con i profili dell'entità servizio, è possibile creare e gestire una soluzione multi-tenancy che comprende decine di migliaia di tenant dei clienti che possono recapitare report a oltre 100.000 utenti destinatari.

I profili dell'entità servizio sono una funzionalità che semplifica la gestione dei contenuti dell'organizzazione in Power BI e consente di usare le capacità in modo più efficiente. Tuttavia, l'uso dei profili dell'entità servizio può aggiungere complessità alla progettazione dell'applicazione. Pertanto, è consigliabile usarli solo quando è necessario ottenere una scalabilità significativa. È consigliabile usare i profili dell'entità servizio quando sono presenti più aree di lavoro e più di 1.000 utenti dell'applicazione.

È possibile ottenere l'incorporamento di Power BI usando due diversi scenari di incorporamento: Incorporamento per l'organizzazione e Incorporamento per il cliente.

Lo scenario di incorporamento per l'organizzazione si applica quando il gruppo di destinatari dell'applicazione comprende utenti interni. Gli utenti interni hanno account aziendali e devono eseguire l'autenticazione con Microsoft Entra ID. In questo scenario, Power BI viene fornito come Software as a Service (SaaS). Viene talvolta definito I dati sono di proprietà dell'utente.

Lo scenario di incorporamento per il cliente si applica quando il gruppo di destinatari dell'applicazione comprende utenti esterni. L'applicazione è responsabile dell'autenticazione degli utenti. Per accedere al contenuto di Power BI, l'applicazione si basa su un'identità di incorporamento (entità servizio di Microsoft Entra o account utente master) per l'autenticazione con Microsoft Entra. In questo scenario, Power BI viene fornito come piattaforma distribuita come servizio (PaaS). Viene talvolta definito I dati sono di proprietà dell'app.

Sviluppo di applicazioni multi-tenancy

Se si ha familiarità con Microsoft Entra, la parola tenant potrebbe portare a pensare a un tenant di Microsoft Entra. Tuttavia, il concetto di tenant è diverso nel contesto della creazione di una soluzione multi-tenancy che incorpora il contenuto di Power BI. In questo contesto viene creato un tenant del cliente per conto di ogni cliente per cui l'applicazione incorpora il contenuto di Power BI usando lo scenario di incorporamento per il cliente. In genere si effettua il provisioning di ogni tenant del cliente creando una singola area di lavoro di Power BI.

Per creare una soluzione multi-tenancy scalabile, è necessario essere in grado di automatizzare la creazione di nuovi tenant del cliente. Il provisioning di un nuovo tenant del cliente prevede in genere la scrittura di codice che usa l'API REST di Power BI per creare una nuova area di lavoro di Power BI, creare modelli semantici importando file di Power BI Desktop (con estensione pbix), aggiornare i parametri dell'origine dati, impostare le credenziali dell'origine dati e configurare l'aggiornamento pianificato del modello semantico. Il diagramma seguente illustra come aggiungere elementi di Power BI, ad esempio report e modelli semantici, alle aree di lavoro per configurare i tenant dei clienti.

Quando si sviluppa un'applicazione che usa lo scenario di incorporamento per il cliente, è possibile eseguire chiamate all'API REST di Power BI usando un'identità di incorporamento che sia un account utente master o un'entità servizio. È consigliabile usare un'entità servizio per le applicazioni di produzione. Offre la massima sicurezza e per questo motivo è l'approccio consigliato da Microsoft Entra. Supporta anche una maggiore automazione e scalabilità, a fronte di un sovraccarico di gestione inferiore. Tuttavia, richiede diritti di amministratore di Power BI per la configurazione e la gestione.

Usando un'entità servizio, è possibile evitare problemi comuni associati agli account utente master, ad esempio errori di autenticazione negli ambienti in cui gli utenti devono accedere usando l'autenticazione a più fattori (MFA). L'uso di un'entità servizio è coerente anche con l'idea che lo scenario di incorporamento per il cliente sia basato sull'incorporamento del contenuto di Power BI usando un approccio PaaS anziché SaaS.

Limite di 1.000 aree di lavoro

Quando si progetta un ambiente multi-tenancy che implementa lo scenario di incorporamento per il cliente, assicurarsi di considerare che all'identità di incorporamento non è possibile concedere l'accesso a più di 1.000 aree di lavoro. Il servizio Power BI impone questa limitazione per garantire prestazioni ottimali quando si effettuano chiamate all'API REST. Il motivo di questa limitazione è correlato al modo in cui Power BI gestisce i metadati relativi alla sicurezza per ogni identità.

Power BI usa i metadati per tenere traccia delle aree di lavoro e degli elementi dell'area di lavoro a cui un'identità può accedere. In effetti, Power BI deve mantenere un elenco di controllo di accesso (ACL) separato per ogni identità nel sottosistema di autorizzazione. Quando un'identità effettua una chiamata all'API REST per accedere a un'area di lavoro, Power BI deve eseguire un controllo di sicurezza dell'ACL dell'identità per assicurarsi che sia autorizzato. Il tempo necessario per determinare se l'area di lavoro di destinazione si trova all'interno dell'elenco di controllo di accesso aumenta in modo esponenziale man mano che aumenta il numero di aree di lavoro.

Si consideri uno scenario in cui sono state configurate due applicazioni multi-tenant per l'uso di una singola entità servizio. Si consideri ora che la prima applicazione ha creato 990 aree di lavoro mentre la seconda applicazione ha creato 1.010 aree di lavoro. Dal punto di vista del supporto, la prima applicazione si trova entro i limiti supportati, mentre la seconda non lo è.

Confrontare ora queste due applicazioni esclusivamente dal punto di vista delle prestazioni. Non c'è molta differenza perché gli elenchi di controllo di accesso per entrambe le entità servizio hanno consentito l'aumento dei metadati per gli ACL fino a un punto in cui le prestazioni peggiorano in qualche modo.

Ecco un'osservazione chiave: il numero di aree di lavoro create da un'entità servizio ha un impatto diretto sulle prestazioni e sulla scalabilità. Un'entità servizio membro di 100 aree di lavoro eseguirà chiamate all'API REST più velocemente rispetto a un'entità servizio membro di 1.000 aree di lavoro. Analogamente, un'entità servizio membro di sole 10 aree di lavoro eseguirà chiamate all'API REST più velocemente rispetto a un'entità servizio membro di 100 aree di lavoro.

Gestire l'isolamento per modelli semantici e credenziali dell'origine dati

Un altro aspetto importante durante la progettazione di un'applicazione multi-tenancy consiste nell'isolare i tenant dei clienti. È fondamentale che gli utenti di un tenant del cliente non visualizzino i dati appartenenti a un altro tenant del cliente. È quindi necessario comprendere come gestire la proprietà del modello semantico e le credenziali dell'origine dati.

Proprietà del modello semantico

Ogni modello semantico di Power BI ha un singolo proprietario, che può essere un account utente o un'entità servizio. La proprietà del modello semantico è necessaria per configurare l'aggiornamento pianificato e impostare i parametri del modello semantico.

Se necessario, è possibile trasferire la proprietà del modello semantico a un altro account utente o a un'entità servizio. A tale scopo, è possibile usare il servizio Power BI o l'operazione di TakeOver dell'API REST. Quando si importa un file di Power BI Desktop per creare un nuovo modello semantico usando un'entità servizio, l'entità servizio viene impostata automaticamente come proprietario del modello semantico.

Credenziali origine dati

Per connettere un modello semantico all'origine dati sottostante, il proprietario del modello semantico deve impostare le credenziali dell'origine dati. Le credenziali dell'origine dati vengono crittografate e memorizzate nella cache da Power BI. Da questo punto, Power BI usa queste credenziali per eseguire l'autenticazione con l'origine dati sottostante durante l'aggiornamento dei dati (per l'importazione delle tabelle di archiviazione) o l'esecuzione di query pass-through (per le tabelle di archiviazione DirectQuery).

È consigliabile applicare uno schema progettuale comune durante il provisioning di un nuovo tenant del cliente. È possibile eseguire una serie di chiamate all'API REST usando l'identità dell'entità servizio:

1. Creare una nuova area di lavoro.
2. Associare la nuova area di lavoro a una capacità dedicata.
3. Importare un file di Power BI Desktop per creare un modello semantico.
4. Impostare le credenziali dell'origine del modello semantico per il modello semantico.

Al termine di queste chiamate all'API REST, l'entità servizio sarà un amministratore della nuova area di lavoro e il proprietario del modello semantico e delle credenziali dell'origine dati.

È possibile che un'entità servizio crei credenziali dell'origine dati condivise dai modelli semantici in aree di lavoro diverse nei tenant dei clienti, come illustrato nel diagramma seguente.

Quando le credenziali dell'origine dati vengono condivise dai modelli semantici che appartengono a tenant di clienti diversi, i tenant del cliente non sono completamente isolati.

Progettare le strategie prima dei profili dell'entità servizio

Ottenere informazioni sulle strategie di progettazione prima che la funzionalità del profilo dell'entità servizio sia disponibile consente di apprezzare la necessità della funzionalità. In precedenza, gli sviluppatori creavano applicazioni multi-tenancy usando una delle tre strategie di progettazione seguenti:

• Entità servizio singola
• Pooling di entità servizio
• Un'entità servizio per area di lavoro

Ognuna di queste strategie di progettazione ha punti di forza e punti deboli.

La strategia di progettazione con singola entità servizio richiede un'unica creazione di una registrazione dell'app Microsoft Entra. Pertanto, comporta un sovraccarico amministrativo inferiore rispetto alle altre due strategie di progettazione perché non è necessario creare più registrazioni dell'app Microsoft Entra. Questa strategia è anche la più semplice da configurare perché non richiede la scrittura di codice aggiuntivo che cambia il contesto di chiamata tra le entità servizio quando si effettuano chiamate all'API REST. Tuttavia, un problema di questa strategia di progettazione è che non viene dimensionata. Supporta solo un ambiente multi-tenancy che può aumentare fino a 1.000 aree di lavoro. Inoltre, le prestazioni risultano ridotte perché all'entità servizio viene concesso l'accesso a un numero maggiore di aree di lavoro. C'è anche un problema di isolamento del tenant del cliente perché la singola entità servizio diventa il proprietario di ogni modello semantico e di tutte le credenziali dei dati in tutti i tenant dei clienti.

La strategia di progettazione pooling di entità servizio viene comunemente usata per evitare la limitazione di 1.000 aree di lavoro. Consente all'applicazione di passare a un numero qualsiasi di aree di lavoro aggiungendo il numero corretto di entità servizio al pool. Ad esempio, un pool di cinque entità servizio consente di passare fino a 5.000 aree di lavoro; un pool di 80 entità servizio consente di passare fino a 80.000 aree di lavoro e così via. Tuttavia, sebbene questa strategia possa essere dimensionata a un numero elevato di aree di lavoro, presenta diversi svantaggi. Prima di tutto, richiede la scrittura di codice aggiuntivo e l'archiviazione dei metadati per consentire il passaggio del contesto da un'entità servizio all'altra durante l'esecuzione di chiamate all'API REST. In secondo luogo, comporta un maggiore lavoro amministrativo perché è necessario creare registrazioni app di Microsoft Entra ogni volta che è necessario aumentare il numero di entità servizio nel pool.

Inoltre, la strategia di pooling delle entità servizio non è ottimizzata per le prestazioni perché consente alle entità servizio di diventare membro di centinaia di aree di lavoro. Non è ideale anche dal punto di vista dell'isolamento del tenant del cliente perché le entità servizio possono diventare proprietari di modelli semantici e di credenziali dei dati condivise tra i tenant dei clienti.

La strategia di progettazione un'entità servizio per area di lavoro implica la creazione di un'entità servizio per ogni tenant del cliente. Dal punto di vista teorico, questa strategia offre la soluzione migliore perché ottimizza le prestazioni delle chiamate all'API REST fornendo al tempo stesso un vero isolamento per i modelli semantici e le credenziali dell'origine dati a livello di area di lavoro. Tuttavia, ciò che funziona meglio in teoria non sempre funziona meglio nella pratica. Questo perché il requisito di creare un'entità servizio per ogni tenant del cliente è poco pratico per molte organizzazioni. Ciò è dovuto al fatto che alcune organizzazioni hanno processi di approvazione formali o comportano un'eccessiva burocrazia per creare registrazioni app di Microsoft Entra. Questi motivi possono rendere impossibile concedere a un'applicazione personalizzata l'autorità necessaria per creare registrazioni app di Microsoft Entra su richiesta e nel modo automatizzato richiesto dalla soluzione.

Negli scenari meno comuni in cui a un'applicazione personalizzata sono state concesse le autorizzazioni appropriate, può usare Microsoft API Graph per creare registrazioni app di Microsoft Entra su richiesta. Tuttavia, l'applicazione personalizzata è spesso complessa da sviluppare e distribuire perché deve in qualche modo tenere traccia delle credenziali di autenticazione per ogni registrazione app di Microsoft Entra. Deve anche ottenere l'accesso a tali credenziali ogni volta che deve eseguire l'autenticazione e acquisire i token di accesso per le singole entità servizio.

Profili di entità servizio

La funzionalità dei profili dell'entità servizio è progettata per semplificare la gestione dei contenuti dell'organizzazione in Power BI e consente di usare le capacità in modo più efficiente. Consente di affrontare tre sfide specifiche che comportano la quantità più bassa di lavoro e sovraccarico per lo sviluppatore. Queste sfide includono:

• Ridimensionamento in un numero elevato di aree di lavoro.
• Ottimizzazione delle prestazioni delle chiamate all'API REST.
• Isolamento dei modelli semantici e delle credenziali dell'origine dati a livello di tenant del cliente.

Quando si progetta un'applicazione multi-tenancy usando i profili dell'entità servizio, è possibile trarre vantaggio dai punti di forza delle tre strategie di progettazione (descritte nella sezione precedente), evitando al contempo i punti deboli associati.

I profili dell'entità servizio sono account locali creati nel contesto di Power BI. Un'entità servizio può usare l'operazione API REST Profiles per creare nuovi profili dell'entità servizio. Un'entità servizio può creare e gestire il proprio set di profili dell'entità servizio per un'applicazione personalizzata, come illustrato nel diagramma seguente.

Esiste sempre una relazione padre-figlio tra un'entità servizio e i profili dell'entità servizio creati. Non è possibile creare un profilo dell'entità servizio come entità autonoma. Al contrario, si crea un profilo dell'entità servizio usando un'entità servizio specifica e tale entità servizio funge da elemento padre del profilo. Inoltre, un profilo dell'entità servizio non è mai visibile agli account utente o ad altre entità servizio. Un profilo dell'entità servizio può essere visualizzato e usato solo dall'entità servizio che lo ha creato.

I profili dell'entità servizio non sono noti a Microsoft Entra

Sebbene l'entità servizio stessa e la registrazione app di Microsoft Entra sottostante sono note a Microsoft Entra, Microsoft Entra ID non conosce nulla sui profili dell'entità servizio. Ciò è dovuto al fatto che i profili dell'entità servizio vengono creati da Power BI ed esistono solo nel sottosistema del servizio Power BI che controlla la sicurezza e l'autorizzazione di Power BI.

Il fatto che i profili dell'entità servizio non siano noti a Microsoft Entra ID presenta vantaggi e svantaggi. Il vantaggio principale è che un'applicazione dello incorporamento per il cliente non necessita di autorizzazioni speciali di Microsoft Entra per creare profili dell'entità servizio. Significa anche che l'applicazione può creare e gestire un set di identità locali separate da Microsoft Entra.

Tuttavia, esistono anche svantaggi. Poiché i profili dell'entità servizio non sono noti a Microsoft Entra, non è possibile aggiungere un profilo dell'entità servizio a un gruppo Microsoft Entra per concedere l'accesso in modo implicito a un'area di lavoro. Inoltre, le origini dati esterne, ad esempio un database SQL di Azure o Azure Synapse Analytics, non possono riconoscere i profili dell'entità servizio come identità durante la connessione a un database. Pertanto, la strategia di progettazione un'entità servizio per area di lavoro (creazione di un'entità servizio per ogni tenant del cliente) potrebbe essere una scelta migliore quando è necessario connettersi a queste origini dati usando un'entità servizio separata con credenziali di autenticazione univoche per ogni tenant del cliente.

I profili dell'entità servizio sono entità di sicurezza di prima classe

Anche se i profili dell'entità servizio non sono noti a Microsoft Entra, Power BI li riconosce come entità di sicurezza di prima classe. Proprio come un account utente o un'entità servizio, è possibile aggiungere profili dell'entità servizio a un ruolo dell'area di lavoro (come amministratore o membro). È anche possibile impostarlo come proprietario di un modello semantico e proprietario delle credenziali dell'origine dati. Per questi motivi, la creazione di un nuovo profilo dell'entità servizio per ogni nuovo tenant del cliente è una procedura consigliata.

Eseguire chiamate all'API REST come profilo dell'entità servizio

L'applicazione può eseguire chiamate all'API REST usando l'identità di un profilo dell'entità servizio. Ciò significa che può eseguire una sequenza di chiamate all'API REST per effettuare il provisioning e configurare un nuovo tenant del cliente.

1. Quando un profilo dell'entità servizio crea una nuova area di lavoro, Power BI aggiunge automaticamente tale profilo come amministratore dell'area di lavoro.
2. Quando un profilo dell'entità servizio importa un file di Power BI Desktop per creare un modello semantico, Power BI imposta tale profilo come proprietario del modello semantico.
3. Quando un profilo dell'entità servizio imposta le credenziali dell'origine dati, Power BI imposta tale profilo come proprietario delle credenziali dell'origine dati.

È importante comprendere che un'entità servizio ha un'identità in Power BI separata e distinta dalle identità dei relativi profili. In questo modo è possibile scegliere come sviluppatore. È possibile eseguire chiamate all'API REST usando l'identità di un profilo dell'entità servizio. In alternativa, è possibile eseguire chiamate all'API REST senza un profilo, che usa l'identità dell'entità servizio padre.

È consigliabile eseguire chiamate all'API REST come entità servizio padre durante la creazione, la visualizzazione o l'eliminazione dei profili dell'entità servizio. È consigliabile usare il profilo dell'entità servizio per eseguire tutte le altre chiamate all'API REST. Queste altre chiamate possono creare aree di lavoro, importare file di Power BI Desktop, aggiornare i parametri del modello semantico e impostare le credenziali dell'origine dati. Possono anche recuperare i metadati degli elementi dell'area di lavoro e generare token di incorporamento.

Si consideri un esempio in cui è necessario configurare un tenant del cliente per un cliente denominato Contoso. Il primo passaggio esegue una chiamata all'API REST per creare un profilo dell'entità servizio con il nome visualizzato impostato su Contoso. Questa chiamata viene eseguita usando l'identità dell'entità servizio. Tutti i passaggi di configurazione rimanenti usano il profilo dell'entità servizio per completare le attività seguenti:

1. Creare un'area di lavoro.
2. Associare l'area di lavoro a una capacità.
3. Importare un file di Power BI Desktop.
4. Impostare i parametri del modello semantico.
5. Impostare le credenziali dell'origine dati.
6. Configurare l'aggiornamento pianificato dei dati.

È importante comprendere che l'accesso all'area di lavoro e il relativo contenuto devono essere eseguiti usando l'identità del profilo dell'entità servizio usato per creare il tenant del cliente. È anche importante comprendere che l'entità servizio padre non deve accedere all'area di lavoro o al relativo contenuto.

Usare le operazioni API REST per i profili

Il gruppo di operazioni API REST per i Profili comprendono operazioni che creano e gestiscono i profili dell'entità servizio:

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

Creare un profilo dell'entità servizio

Usare l'operazione Crea profilo dell'API REST per creare un profilo dell'entità servizio. È necessario impostare la proprietà displayName nel corpo della richiesta per specificare un nome visualizzato per il nuovo tenant. Il valore deve essere univoco in tutti i profili di proprietà dell'entità servizio. La chiamata avrà esito negativo se esiste già un altro profilo con tale nome visualizzato per l'entità servizio.

Una chiamata riuscita restituisce la proprietà id, ovvero un GUID che rappresenta il profilo. Quando si sviluppano applicazioni che usano i profili dell'entità servizio, è consigliabile archiviare i nomi visualizzati del profilo e i relativi valori ID in un database personalizzato. In questo modo, è semplice per l'applicazione recuperare gli ID.

Se si esegue la programmazione con Power BI .NET SDK, è possibile usare il metodo Profiles.CreateProfile, che restituisce un oggetto ServicePrincipalProfile che rappresenta il nuovo profilo. Semplifica la determinazione del valore della proprietà id.

Di seguito è riportato un esempio di creazione di un profilo dell'entità servizio e della concessione a questo dell'accesso all'area di lavoro.

// 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);

Nel servizio Power BI, nell'area di lavoro riquadro Accesso è possibile determinare quali identità, incluse le entità di sicurezza, hanno accesso.

Eliminazione del profilo dell'entità servizio

Usare l'operazione Elimina profilo dell'API REST per eliminare un profilo dell'entità servizio. Questa operazione può essere chiamata solo dall'entità servizio padre.

Se si esegue la programmazione con Power BI .NET SDK, è possibile usare il metodo Profiles.DeleteProfile.

Recuperare tutti i profili dell'entità servizio

Usare l'operazione Ottieni profili dell'API REST per recuperare un elenco di profili dell'entità servizio che appartengono all'entità servizio chiamante. Questa operazione restituisce un payload JSON che contiene le proprietà id e displayName di ogni profilo dell'entità servizio.

Se si esegue la programmazione con Power BI .NET SDK, è possibile usare il metodo Profiles.GetProfiles.

Eseguire chiamate all'API REST un profilo dell'entità servizio

È necessario rispettare due requisiti per effettuare chiamate all'API REST usando un profilo dell'entità servizio:

• Passare il token di accesso per l'entità servizio padre nell'intestazione Autorizzazione.
• Includere un'intestazione denominata X-PowerBI-profile-id con il valore dell'ID del profilo dell'entità servizio.

Se si usa Power BI .NET SDK, è possibile impostare il valore dell'intestazione X-PowerBI-profile-id in modo esplicito passando l'ID del profilo dell'entità servizio.

// 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();

Come illustrato nell'esempio precedente, dopo aver aggiunto l'intestazione X-PowerBI-profile-id all'oggetto PowerBIClient, è semplice richiamare metodi, ad esempio Groups.GetGroups, in modo che vengano eseguiti usando il profilo dell'entità servizio.

Esiste un modo più pratico per impostare l'intestazione X-PowerBI-profile-id per un oggetto PowerBIClient. È possibile inizializzare l'oggetto passando l'ID del profilo al costruttore.

// 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);

Quando si programma un'applicazione multi-tenancy, è probabile che sia necessario passare dall'esecuzione di chiamate come entità servizio padre all'esecuzione di chiamate come profilo dell'entità servizio. Un approccio utile per gestire il cambio di contesto consiste nel dichiarare una variabile a livello di classe che archivia l'oggetto PowerBIClient. È quindi possibile creare un metodo helper che imposta la variabile con l'oggetto corretto.

// 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));
    }
}

Quando è necessario creare o gestire un profilo dell'entità servizio, è possibile chiamare il metodo SetCallingContext senza parametri. In questo modo, è possibile creare e gestire i profili usando l'identità dell'entità servizio.

// 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);

Quando è necessario creare e configurare un'area di lavoro per un nuovo tenant del cliente, si vuole eseguire tale codice come profilo dell'entità servizio. Pertanto, è necessario chiamare il metodo SetCallingContext passando l'ID del profilo. In questo modo, è possibile creare l'area di lavoro usando l'identità del profilo dell'entità servizio.

// 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);

Dopo aver usato un profilo dell'entità servizio specifico per creare e configurare un'area di lavoro, è necessario continuare a usare lo stesso profilo per creare e configurare il contenuto dell'area di lavoro. Non è necessario richiamare il metodo SetCallingContext per completare la configurazione.

Esempio per gli sviluppatori

È consigliabile scaricare un'applicazione di esempio denominata AppOwnsDataMultiTenant.

Questa applicazione di esempio è stata sviluppata usando .NET 6 e ASP.NET e illustra come applicare le indicazioni e le raccomandazioni descritte in questo articolo. È possibile esaminare il codice per informazioni su come sviluppare un'applicazione multi-tenancy che implementa lo scenario di incorporamento per il cliente usando i profili dell'entità servizio.

Contenuto correlato

Per altre informazioni su questo articolo, consultare le risorse seguenti:

• Profili dell'entità servizio per le app multi-tenancy in Power BI Embedded
• Eseguire la migrazione di applicazioni multi-cliente al modello di profili dell'entità servizio
• Gruppo di operazioni API REST per i profili di Power BI
• • Applicazione di esempio AppOwnsDataMultiTenant
• Domande? Contattare la community di Power BI
• inviare suggerimenti, Contribuire con idee per migliorare Power BI