Profili entità servizio per app multi-tenancy in Power BI Embedded

  • Articolo

Questo articolo illustra in che modo un ISV o qualsiasi altro proprietario di app Power BI Embedded con molti clienti può usare i profili dell'entità servizio per eseguire il mapping e gestire i dati di ogni cliente come parte dell'incorporamento di Power BI per la soluzione clienti . I profili dell'entità servizio consentono all'ISV di creare applicazioni scalabili che consentono un migliore isolamento dei dati dei clienti e stabiliscono limiti di sicurezza più stretti tra i clienti. Questo articolo illustra i vantaggi e le limitazioni di questa soluzione.

Nota

Il tenant di parola in Power BI può talvolta fare riferimento a un tenant di Microsoft Entra. In questo articolo, tuttavia, viene usato il termine multi-tenancy per descrivere una soluzione in cui una singola istanza di un'applicazione software serve più clienti o organizzazioni (tenant) che richiedono la separazione fisica e logica dei dati. Ad esempio, il generatore di app Power BI può allocare un'area di lavoro separata per ognuno dei suoi clienti (o tenant) come illustrato di seguito. Questi clienti non sono necessariamente tenant Di Microsoft Entra, quindi non confondere il termine applicazione multi-tenant usata qui, con l'applicazione multi-tenant Microsoft Entra.

Un profilo dell'entità servizio è un profilo creato da un'entità servizio. L'app ISV chiama i API Power BI usando un profilo dell'entità servizio, come illustrato in questo articolo.

L'entità servizio applicazione ISV crea un profilo di Power BI diverso per ogni cliente o tenant. Quando un cliente visita l'app ISV, l'app usa il profilo corrispondente per generare un token di incorporamento che verrà usato per eseguire il rendering di un report nel browser.

L'uso dei profili dell'entità servizio consente all'app ISV di ospitare più clienti in un singolo tenant di Power BI. Ogni profilo rappresenta un cliente in Power BI. In altre parole, ogni profilo crea e gestisce il contenuto di Power BI per i dati di un cliente specifico.

Diagramma dei profili SP e della multi-tenancy.

Nota

Questo articolo è rivolto alle organizzazioni che vogliono configurare un'app multi-tenant usando i profili dell'entità servizio. Se l'organizzazione ha già un'app che supporta la multi-tenancy e si vuole eseguire la migrazione al modello di profilo dell'entità servizio, vedere Eseguire la migrazione al modello di profili dell'entità servizio.

La configurazione del contenuto di Power BI prevede i passaggi seguenti:

Tutti i passaggi precedenti possono essere completamente automatizzati usando le API REST di Power BI.

Prerequisiti

Prima di poter creare profili entità servizio, è necessario:

  • Configurare l'entità servizio seguendo i primi tre passaggi di Incorporare il contenuto di Power BI con l'entità servizio.
  • Da un account amministratore tenant di Power BI abilitare la creazione di profili nel tenant usando lo stesso gruppo di sicurezza usato al momento della creazione dell'entità servizio.

Screenshot dell'opzione Amministrazione portale.

Creare un profilo

I profili possono essere creati, aggiornati ed eliminati usando l'API REST Profili.

Ad esempio, per creare un profilo:

POST https://api.powerbi.com/v1.0/myorg/profiles HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJK…UUPA
Content-Type: application/json; charset=utf-8

{"displayName":"ContosoProfile"}

Un'entità servizio può anche chiamare l'API REST profili GET per ottenere un elenco dei relativi profili. Ad esempio:

GET https://api.powerbi.com/v1.0/myorg/profiles HTTP/1.1
Authorization: Bearer eyJ0eXA…UUPA

Autorizzazioni profilo

Qualsiasi API che concede a un utente l'autorizzazione per gli elementi di Power BI può anche concedere un'autorizzazione del profilo agli elementi di Power BI. Ad esempio, è possibile usare l'API Aggiungi utente gruppo per concedere a un profilo l'autorizzazione a un'area di lavoro.

I punti seguenti sono importanti per comprendere quando si usano i profili:

  • Un profilo appartiene all'entità servizio che lo ha creato e può essere usato solo da tale entità servizio.
  • Non è possibile modificare un proprietario del profilo dopo la creazione.
  • Un profilo non è un'identità autonoma. Richiede il token Microsoft Entra dell'entità servizio per chiamare le API REST di Power BI.

Le app ISV chiamano le API REST di Power BI fornendo il token Microsoft Entra dell'entità servizio nell'intestazione authorization e l'ID del profilo nell'intestazione X-PowerBI-Profile-Id . Ad esempio:

  GET https://api.powerbi.com/v1.0/myorg/groups HTTP/1.1
  Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUz.....SXBwasfg
  X-PowerBI-Profile-Id: 5f1aa5ed-5983-46b5-bd05-999581d361a5

Creare un'area di lavoro

Le aree di lavoro di Power BI vengono usate per ospitare elementi di Power BI, ad esempio report e modelli semantici.

Ogni profilo deve:

  • Creare almeno un'area di lavoro di Power BI

    POST https://api.powerbi.com/v1.0/myorg/groups HTTP/1.1
Authorization: Bearer eyJ0eXA…ZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "name": "ContosoWorkspace"
}

  • Concedere le autorizzazioni di accesso all'area di lavoro. Il profilo dell'entità servizio deve avere Amministrazione accesso all'area di lavoro.

  • Assegnare l'area di lavoro a una capacità

    POST https://api.powerbi.com/v1.0/myorg/groups/f313e682-c86b-422c-a3e2-b1a05426c4a3/AssignToCapacity HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJK…wNkZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "capacityId": "13f73071-d6d3-4d44-b9de-34590f3e3cf6"
}

Altre informazioni sulle aree di lavoro di Power BI.

Importare report e modelli semantici

Usare Power BI Desktop per preparare i report connessi ai dati o ai dati di esempio del cliente. È quindi possibile usare l'API di importazione per importare il contenuto nell'area di lavoro creata.

POST https://api.powerbi.com/v1.0/myorg/groups/f313e682-c86b-422c-a3e2-b1a05426c4a3/imports?datasetDisplayName=ContosoSales HTTP/1.1
Authorization: Bearer eyJ...kZUiIsg
Content-Type: multipart/form-data; boundary="8b071895-b380-4769-9c62-7e586d717ed7"
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306
Fiddler-Encoding: base64

LS04YjA3MTg5NS1iMzgwLTQ3...Tg2ZDcxN2VkNy0tDQo=

Usare i parametri del set di dati per creare un modello semantico in grado di connettersi a origini dati dei clienti diverse. Usare quindi l'API Parametri di aggiornamento per definire i dati dei clienti a cui si connette il modello semantico.

Impostare la connessione del modello semantico

Gli ISV in genere archiviano i dati dei clienti in uno dei due modi seguenti:

In entrambi i casi, è consigliabile usare modelli semantici a tenant singolo (un modello semantico per cliente) in Power BI.

Un database separato per ogni cliente

Se l'applicazione ISV ha un database separato per ogni cliente, creare modelli semantici a tenant singolo in Power BI. Fornire a ogni modello semantico i dettagli di connessione che puntano al database corrispondente. Usare uno dei metodi seguenti per evitare di creare più report identici con dettagli di connessione diversi:

  • Parametri del modello semantico: creare un modello semantico con parametri nei dettagli della connessione, ad esempio nome del server SQL, nome del database SQL. Importare quindi un report nell'area di lavoro di un cliente e modificare i parametri in modo che corrispondano ai dettagli del database del cliente.

  • Aggiornare l'API Origine dati: creare un file con estensione pbix che punta a un'origine dati con contenuto di esempio. Importare quindi il file con estensione pbix nell'area di lavoro di un cliente e modificare i dettagli della connessione usando l'API Aggiorna origine dati.

Un singolo database multi-tenant

Se l'applicazione ISV usa un database per tutti i clienti, separare i clienti in modelli semantici diversi in Power BI come indicato di seguito:

Creare un report usando parametri che recuperano solo i dati del cliente pertinente. Importare quindi un report nell'area di lavoro di un cliente e modificare i parametri per recuperare solo i dati del cliente pertinente.

Incorporare un report

Al termine dell'installazione, è possibile incorporare i report dei clienti e altri elementi nell'applicazione usando un token di incorporamento.

Quando un cliente visita l'applicazione, usare il profilo corrispondente per chiamare l'API GenerateToken. Usare il token di incorporamento generato per incorporare un report o altri elementi nel browser del cliente.

Per generare un token di incorporamento:

POST https://api.powerbi.com/v1.0/myorg/GenerateToken HTTP/1.1
Authorization: Bearer eyJ0eXAiOi…kZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "datasets": [
    {
      "id": "3b1c8f74-fbbe-45e0-bf9d-19fce69262e3"
    }
  ],
  "reports": [
    {
      "id": "3d474b89-f2d5-43a2-a436-d24a6eb2dc8f"
    }
  ]
}

Aspetti di progettazione

Prima di configurare una soluzione multi-tenant basata su profilo, è necessario tenere presenti i problemi seguenti:

Scalabilità

Separando i dati in modelli semantici separati per ogni cliente, è possibile ridurre al minimo la necessità di modelli semantici di grandi dimensioni. Quando la capacità viene sovraccaricata, può rimuovere i modelli semantici inutilizzati per liberare memoria per i modelli semantici attivi. Questa ottimizzazione è impossibile per un singolo modello semantico di grandi dimensioni. Usando più modelli semantici, è anche possibile separare i tenant in più capacità di Power BI, se necessario.

Senza profili, un'entità servizio è limitata a 1.000 aree di lavoro. Per superare questo limite, un'entità servizio può creare più profili, in cui ogni profilo può accedere/creare fino a 1.000 aree di lavoro. Con più profili, l'app ISV può isolare il contenuto di ogni cliente usando contenitori logici distinti.

Quando un profilo dell'entità servizio ha accesso a un'area di lavoro, è possibile rimuovere l'accesso dell'entità servizio padre all'area di lavoro per evitare problemi di scalabilità.

Anche con questi vantaggi, è consigliabile considerare la scalabilità potenziale dell'applicazione. Ad esempio, il numero di elementi dell'area di lavoro a cui un profilo può accedere è limitato. Oggi, un profilo ha gli stessi limiti di un utente normale. Se l'applicazione ISV consente agli utenti finali di salvare una copia personalizzata dei report incorporati, il profilo di un cliente avrà accesso a tutti i report creati di tutti gli utenti. Questo modello può infine superare il limite.

Automazione e complessità operativa

Con la separazione basata su profili di Power BI, potrebbe essere necessario gestire centinaia o migliaia di elementi. Di conseguenza, è importante definire i processi che si verificano spesso nella gestione del ciclo di vita dell'applicazione e assicurarsi di disporre del set corretto di strumenti per eseguire queste operazioni su larga scala. Alcune di queste operazioni includono:

  • Aggiunta di un nuovo tenant
  • Aggiornamento di un report per alcuni o tutti i tenant
  • Aggiornamento dello schema del modello semantico per alcuni o tutti i tenant
  • Personalizzazioni non pianificate per tenant specifici
  • Frequenza degli aggiornamenti del modello semantico

Ad esempio, la creazione di un profilo e un'area di lavoro per un nuovo tenant è un'attività comune, che può essere completamente automatizzata con l'API REST di Power BI.

Esigenze multi-geografiche

Il supporto multi-geografico per Power BI Embedded significa che gli ISV e le organizzazioni che creano applicazioni con Power BI Embedded per incorporare l'analisi nelle app possono ora distribuire i dati in aree diverse in tutto il mondo. Per supportare clienti diversi in aree diverse, assegnare l'area di lavoro del cliente a una capacità nell'area desiderata. Questa attività è un'operazione semplice che non comporta costi aggiuntivi. Tuttavia, se si hanno clienti che necessitano di dati provenienti da più aree, il profilo tenant deve duplicare tutti gli elementi in più aree di lavoro assegnate a capacità internazionali diverse. Questa duplicazione può aumentare sia la complessità dei costi che della gestione.

Per motivi di conformità, è comunque possibile creare più tenant di Power BI in aree diverse. Altre informazioni su multi-geo.

Efficienza dei costi

Gli sviluppatori di applicazioni che usano Power BI Embedded devono acquistare una capacità di Power BI Embedded. Il modello di separazione basato su profilo funziona bene con le capacità perché:

  • L'oggetto più piccolo che è possibile assegnare in modo indipendente a una capacità è un'area di lavoro , ad esempio non è possibile assegnare un report. Separando i clienti in base ai profili, si ottengono aree di lavoro diverse, una per cliente. In questo modo, si ottiene la massima flessibilità per gestire ogni cliente in base alle proprie esigenze di prestazioni e ottimizzare l'utilizzo della capacità aumentando o riducendo le prestazioni. Ad esempio, è possibile gestire clienti di grandi dimensioni ed essenziali con volumi elevati e volatilità in una capacità separata per garantire un livello coerente di servizio, raggruppando i clienti più piccoli in un'altra capacità per ottimizzare i costi.

  • La separazione delle aree di lavoro implica anche la separazione di modelli semantici tra tenant in modo che i modelli di dati si trovino in blocchi più piccoli, anziché in un singolo modello semantico di grandi dimensioni. Questi modelli più piccoli consentono di gestire in modo più efficiente l'utilizzo della memoria. I modelli semantici inutilizzati di piccole dimensioni possono essere rimossi dopo un periodo di inattività, per mantenere buone prestazioni.

Quando si acquista una capacità, prendere in considerazione il limite per il numero di aggiornamenti paralleli, in quanto i processi di aggiornamento potrebbero richiedere capacità aggiuntiva quando si dispone di più modelli semantici.

Sicurezza a livello di riga

Questo articolo illustra come usare i profili per creare un modello semantico separato per ogni cliente. In alternativa, le applicazioni ISV possono archiviare tutti i dati dei clienti in un modello semantico di grandi dimensioni e usare la sicurezza a livello di riga per proteggere i dati di ogni cliente. Questo approccio può essere utile per gli ISV che hanno relativamente pochi clienti e modelli semantici di piccole e medie dimensioni perché:

  • È disponibile un solo report e un modello semantico da gestire
  • Il processo di onboarding per i nuovi clienti può essere semplificato

Prima di usare la sicurezza a livello di riga, tuttavia, assicurarsi di comprendere le limitazioni. Tutti i dati per tutti i clienti si trovano in un modello semantico di Power BI di grandi dimensioni. Questo modello semantico viene eseguito in una singola capacità con scalabilità personalizzata e altre limitazioni.

Anche se si usano profili entità servizio per separare i dati dei clienti, è comunque possibile usare la sicurezza a livello di riga all'interno di un modello semantico di un singolo cliente per concedere a gruppi diversi l'accesso a parti diverse dei dati. Ad esempio, è possibile usare la sicurezza a livello di riga per impedire ai membri di un reparto di accedere ai dati di un altro reparto nella stessa organizzazione.

Considerazioni e limitazioni

  • I profili entità servizio sono supportati solo tramite l'API REST di Power BI e Power BI .NET SDK. I profili entità servizio non sono supportati in Power BI tramite l'endpoint XMLA o il modello a oggetti tabulare (TOM).
  • I profili dell'entità servizio non sono supportati con Azure Analysis Services (AAS) in modalità di connessione dinamica.

Limitazioni della capacità di Power BI

  • Ogni capacità può usare solo la memoria allocata e i core V, in base allo SKU acquistato. Per le dimensioni consigliate del modello semantico per ogni SKU, fare riferimento a modelli semantici Di grandi dimensioni Premium.
  • Per usare un modello semantico di dimensioni superiori a 10 GB, usare una capacità Premium e abilitare l'impostazione Modelli semantici di grandi dimensioni.
  • Per il numero di aggiornamenti che possono essere eseguiti simultaneamente su una capacità, fare riferimento alla gestione delle risorse e all'ottimizzazione.

Gestire le entità servizio

Modificare un'entità servizio

In Power BI un profilo appartiene all'entità servizio che l'ha creata. Ciò significa che un profilo non può essere condiviso con altre entità. Con questa limitazione, se si vuole modificare l'entità servizio per qualsiasi motivo, sarà necessario ricreare tutti i profili e fornire ai nuovi profili l'accesso alle aree di lavoro pertinenti. Spesso, l'applicazione ISV deve salvare un mapping tra un ID profilo e un ID cliente per selezionare il profilo corretto quando necessario. Se si modifica l'entità servizio e si ricreano i profili, verranno modificati anche gli ID e potrebbe essere necessario aggiornare il mapping nel database dell'applicazione ISV.

Eliminare un'entità servizio

Avviso

Prestare molta attenzione quando si elimina un'entità servizio. Non si vogliono perdere accidentalmente dati da tutti i profili associati.

Se si elimina l'entità servizio in Active Directory, tutti i relativi profili in Power BI verranno eliminati. Tuttavia, Power BI non eliminerà immediatamente il contenuto, in modo che l'amministratore del tenant possa comunque accedere alle aree di lavoro. Prestare attenzione quando si elimina un'entità servizio usata in un sistema di produzione, in particolare quando sono stati creati profili usando questa entità servizio in Power BI. Se si elimina un'entità servizio che ha creato profili, tenere presente che sarà necessario ricreare tutti i profili, fornire ai nuovi profili l'accesso alle aree di lavoro pertinenti e aggiornare gli ID profilo nel database dell'applicazione ISV.

Separazione dei dati

Quando i dati sono separati dai profili dell'entità servizio, un semplice mapping tra un profilo e un cliente impedisce a un cliente di visualizzare il contenuto di un altro cliente. L'uso di una singola entità servizio richiede che l'entità servizio abbia accesso a tutte le diverse aree di lavoro in tutti i profili.

Per aggiungere una separazione aggiuntiva, assegnare un'entità servizio separata a ogni tenant, anziché avere un'unica entità servizio accedere a più aree di lavoro usando profili diversi. L'assegnazione di entità servizio separate presenta diversi vantaggi, tra cui:

  • L'errore umano o una perdita di credenziali non causerà l'esposizione dei dati di più tenant.
  • La rotazione dei certificati può essere eseguita separatamente per ogni tenant.

Tuttavia, l'uso di più entità servizio include un costo di gestione elevato. Selezionare questo percorso solo se è necessaria la separazione aggiuntiva. Tenere presente che la configurazione dei dati da mostrare a un utente finale viene definita quando si genera il token di incorporamento, un processo di sola back-end che gli utenti finali non possono visualizzare o modificare. La richiesta di un token di incorporamento usando un profilo specifico del tenant genererà un token di incorporamento per tale profilo specifico, che consentirà la separazione dei clienti in consumo.

Un report, più modelli semantici

In genere, è disponibile un report e un modello semantico per ogni tenant. Se si hanno centinaia di report, si avranno centinaia di modelli semantici. In alcuni casi, è possibile avere un formato di report, con modelli semantici diversi, ad esempio parametri diversi o dettagli di connessione. Ogni volta che si dispone di una nuova versione del report, sarà necessario aggiornare tutti i report per tutti i tenant. Anche se è possibile automatizzare questa operazione, è più semplice gestire se si dispone di una sola copia del report. Creare un'area di lavoro contenente il report da incorporare. Durante un runtime di sessione, associare il report al modello semantico specifico del tenant. Per altre informazioni, vedere associazioni dinamiche.

Personalizzazione e creazione di contenuti

Quando si crea contenuto, considerare attentamente chi ha l'autorizzazione per modificarlo. Se si consentono a più utenti in ogni tenant di modificare, è facile superare le limitazioni del modello semantico. Se si decide di offrire agli utenti funzionalità di modifica, monitorare attentamente la generazione del contenuto e aumentare le prestazioni in base alle esigenze. Per lo stesso motivo, non è consigliabile usare questa funzionalità per la personalizzazione del contenuto, in cui ogni utente può apportare piccole modifiche a un report e salvarlo automaticamente. Se l'applicazione ISV consente la personalizzazione del contenuto, è consigliabile introdurre criteri di conservazione dell'area di lavoro per il contenuto specifico dell'utente. I criteri di conservazione semplificano l'eliminazione del contenuto quando gli utenti passano a una nuova posizione, lasciano l'azienda o smettono di usare la piattaforma.

Identità gestita dal sistema

Anziché un'entità servizio, è possibile usare un'identità gestita assegnata dall'utente o assegnata dalsistema per creare profili. Le identità gestite riducono la necessità di segreti e certificati.

Prestare attenzione quando si usa un'identità gestita dal sistema perché:

  • Se un'identità gestita assegnata dal sistema viene accidentalmente disattivata, si perderà l'accesso ai profili. Questa situazione è simile a un caso in cui un'entità servizio viene eliminata.
  • Un'identità gestita assegnata dal sistema è connessa a una risorsa in Azure (app Web). Se si elimina la risorsa, l'identità verrà eliminata.
  • L'uso di più risorse (app Web diverse in aree diverse) comporterà la gestione di più identità che devono essere gestite separatamente (ogni identità avrà profili propri).

A causa delle considerazioni precedenti, è consigliabile usare un'identità gestita assegnata dall'utente.

Esempio

Per un esempio di come usare i profili entità servizio per gestire un ambiente multi-tenant con l'incorporamento di Power BI e App-Owns-Data, scaricare il repository multi-tenant di dati proprietario dell'app da Power BI Dev Camp (sito di terze parti).

Contenuto correlato