Connettività del modello semantico con l'endpoint XMLA

Le aree di lavoro di Power BI Premium, Premium per utente e Power BI Embedded usano un endpoint XMLA per supportare la connettività open-platform da strumenti e applicazioni client di Microsoft e di terzi.

Endpoint XMLA

Le aree di lavoro usano il protocollo XML for Analysis (XMLA) per le comunicazioni tra le applicazioni client e il motore che gestisce i modelli semantici e le aree di lavoro di Power BI. Queste comunicazioni avvengono attraverso endpoint comunemente chiamati endpoint XMLA. XMLA è il protocollo di comunicazione usato dal motore di Microsoft Analysis Services che esegue in la modellazione semantica, la governance, il ciclo di vita e la gestione dei dati di Power BI. I dati inviati tramite il protocollo XMLA sono completamente crittografati.

Per impostazione predefinita, la connettività in sola lettura con l'uso dell'endpoint è abilitata per il Carico di lavoro dei modelli semantici in una capacità. Con la sola lettura, gli strumenti e le applicazioni di visualizzazione dei dati possono eseguire query sui dati del modello, sui metadati, sugli eventi e sullo schema del modello semantico.

È possibile abilitare operazioni di lettura-scrittura con l'uso dell'endpoint. La lettura/scrittura migliora la gestione, la governance, la modellazione semantica avanzata, il debug e il monitoraggi dei modelli semantici. Quando è abilitata, i modelli semantici hanno maggiore parità con gli strumenti e i processi di modellazione tabulare a livello aziendale di Azure Analysis Services e SQL Server Analysis Services.

Proprietà del server Analysis Services

Power BI Premium supporta numerose proprietà del server di Analysis Services. Per esaminare queste proprietà, fare riferimento alle proprietà del server in Analysis Services.

Condizioni per l'utilizzo

L'uso dell'endpoint XMLA è soggetto a:

Applicazione singolo utente: l'applicazione usa un singolo account utente o un'identità dell'app per accedere a un modello semantico di Power BI tramite l'endpoint XMLA. Esempi di applicazioni a singolo utente includono strumenti di sviluppo, script di amministrazione e processi automatizzati. Queste applicazioni possono eseguire attività come la modellazione dei dati e attività amministrative che modificano i metadati di un modello semantico, un'operazione di backup o ripristino o attivano un aggiornamento dei dati. L'account utente o l'identità dell'app che l'applicazione client usa per accedere a un modello semantico deve avere una licenza Premium per utente (PPU) valida, a meno che il modello semantico non risieda in una capacità Premium.

Applicazione multiutente: l'applicazione fornisce a più utenti l'accesso a un modello semantico di Power BI. Ad esempio, un'applicazione di livello intermedio che integra un modello semantico in una soluzione aziendale e che accede al modello semantico per conto degli utenti aziendali.

• Aree di lavoro Premium per utente (PPU): l'applicazione deve richiedere a ogni utente di accedere a Power BI. Per ogni utente, l'applicazione usa un token di accesso per accedere ai modelli semantici. L'applicazione non può usare un account del servizio o un'altra identità dell'app per eseguire attività per conto di singoli utenti. Ogni utente deve avere un proprio account Power BI per l'apertura dei report, l'accesso ai modelli semantici e l'esecuzione di query.
• Per le aree di lavoro Premium, l'applicazione può usare un account del servizio o un'identità dell'app per conto degli utenti finali senza richiedere a ogni utente di accedere a Power BI.

Strumenti e applicazioni client

Strumenti e applicazioni comuni usati con Azure Analysis Services e SQL Server Analysis Services che ora sono supportati dai modelli semantici di Power BI Premium:

Microsoft Excel: le tabelle pivot di Excel sono uno degli strumenti più comuni usati per riepilogare, analizzare, esplorare e presentare dati di riepilogo dai modelli semantici di Power BI. La sola lettura è necessaria per le operazioni di query. È richiesta la versione A portata di clic di Office 16.0.13612.10000 o successiva.

Visual Studio con progetti di Analysis Services: noto come SQL Server Data Tools (SSDT). SSDT è uno strumento di creazione di modelli di livello aziendale per i modelli tabulari di Analysis Services. Tutte le edizioni di Visual Studio 2017 e versioni successive, inclusa l'edizione Community gratuita, supportano estensioni di progetti di Analysis Services. Richiede la versione dell'estensione 2.9.14 o successiva per la distribuzione di modelli tabulari in un'area di lavoro Premium. Il modello deve avere un livello di compatibilità 1500 o superiore per la distribuzione. Richiede lettura/scrittura XMLA nel carico di lavoro dei modelli semantici. Per altre informazioni, vedere Strumenti per Analysis Services.

SQL Server Management Studio (SSMS): supporta query DAX, MDX e XMLA. Eseguire operazioni di aggiornamento con granularità fine e script dei metadati di modelli semantici usando il linguaggio Tabular Model Scripting Language (TMSL). Richiede sola lettura per operazioni di query. Richiede lettura-scrittura per metadati di scripting. Richiede SSMS versione 18.9 o successiva. Scaricare SSMS.

SQL Server Profiler: SQL Server Profiler viene installato con SSMS e consente il tracciamento e il debug di eventi di modelli semantici. Anche se è stato deprecato ufficialmente per SQL Server, Profiler è ancora incluso in SSMS ed è ancora supportato per Analysis Services e Power BI. Richiede la versione di SQL Server Profiler 18.9 o successiva. Quando ci si connette all'endpoint XMLA, gli utenti devono specificare il modello semantico (catalogo iniziale). Per altre informazioni, vedere SQL Server Profiler per Analysis Services.

Distribuzione guidata di Analysis Services: installato con SSMS, questo strumento consente di distribuire progetti di modelli tabulari creati in Visual Studio nelle aree di lavoro di Analysis Services e Premium. Può essere eseguito in modo interattivo o dalla riga di comando per l'automazione. È richiesta la lettura/scrittura XMLA. Per altre informazioni, vedere Distribuzione guidata Analysis Services.

Cmdlet di PowerShell: usare i cmdlet di Analysis Services per automatizzare le attività di gestione di modelli semantici, ad esempio operazioni di aggiornamento. Richiede lettura/scrittura XMLA. Richiede la versione 21.1.18256 o successiva del modulo PowerShell SqlServer. I cmdlet di Azure Analysis Services nel modulo Az.AnalysisServices non sono supportati per modelli semantici di Power BI. Per altre informazioni, vedere Guida di riferimento a PowerShell per Analysis Services.

Power BI Report Builder: uno strumento per la creazione di report impaginati. Creare una definizione di report che specifica i dati da recuperare, dove recuperarli e come visualizzarli. È possibile visualizzare in anteprima il report in Report Builder e quindi pubblicarlo nel servizio Power BI. Richiede sola lettura XMLA. Per altre informazioni, vedere Power BI Report Builder.

Tabular Editor: strumento open source per la creazione, la manutenzione e la gestione dei modelli tabulari con un editor semplice e intuitivo. Una visualizzazione gerarchica mostra tutti gli oggetti del modello tabulare. Organizza gli oggetti per cartelle di visualizzazione con supporto per la modifica di proprietà a selezione multipla ed evidenziazione della sintassi DAX. Richiede sola lettura XMLA per operazioni di query. Richiede lettura-scrittura per operazioni di metadati. Per altre informazioni, vedere tabulareditor.github.io.

DAX Studio: un ottimo strumento open source per la creazione, la diagnosi, l'ottimizzazione delle prestazioni e l'analisi DAX. Le funzionalità includono esplorazione di oggetti, traccia integrata, suddivisioni dell'esecuzione di query con statistiche dettagliate, evidenziazione e formattazione della sintassi DAX. Richiede sola lettura XMLA per operazioni di query. Per altre informazioni, vedere daxstudio.org.

Toolkit ALM: uno strumento open source per il confronto degli schemi per modelli semantici di Power BI, usato più spesso per gli scenari di Application Lifecycle Management (ALM). Eseguire la distribuzione in ambienti e conservare i dati cronologici degli aggiornamenti incrementali. Confrontare e unire i file di metadati, i rami e i repository. Riutilizzare le definizioni comuni tra i modelli semantici. Richiede sola lettura per operazioni di query. Richiede lettura-scrittura per operazioni di metadati. Per altre informazioni, vedere alm-toolkit.com.

Terzi: include strumenti e applicazioni di visualizzazione di dati client che possono connettersi, eseguire query e usare modelli semantici in aree di lavoro Premium. La maggior parte degli strumenti richiede le versioni più recenti delle librerie client MSOLAP, ma alcuni possono usare ADOMD. L'endpoint XMLA di sola lettura o lettura-scrittura varia a seconda delle operazioni.

Librerie client

Gli strumenti e le applicazioni client non comunicano direttamente con l'endpoint XMLA. Usano invece librerie client come livello di astrazione. Si tratta delle stesse librerie client usate dalle applicazioni per connettersi ad Azure Analysis Services e SQL Server Analysis Services. Le applicazioni Microsoft come Excel e SQL Server Management Studio (SSMS), e l'estensione di progetti Analysis Services per Visual Studio installano tutte e tre le librerie client e le aggiornano con gli aggiornamenti periodici delle applicazioni e delle estensioni. Gli sviluppatori possono usare le librerie client anche per creare applicazioni personalizzate. In alcuni casi, in particolare con applicazioni di terzi, potrebbe essere necessario installare versioni più recenti delle librerie client, se non sono state installate con l'applicazione. Le librerie client vengono aggiornate ogni mese. Per altre informazioni, vedere Librerie client per la connessione ad Azure Analysis Services.

Ottimizzare i modelli semantici per operazioni di scrittura abilitando modelli di grandi dimensioni

Quando si usa l'endpoint XMLA per la gestione di modelli semantici con operazioni di scrittura, è consigliabile abilitare il modello semantico per modelli di grandi dimensioni. In questo modo si riduce il sovraccarico delle operazioni di scrittura, rendendole notevolmente più veloci. Per i modelli semantici con dimensioni superiori a 1 GB (dopo la compressione), la differenza può essere significativa. Per altre informazioni, vedere Modelli di grandi dimensioni in Power BI Premium.

Abilitare la lettura/scrittura XMLA

Per impostazione predefinita, i carichi di lavoro dei modelli semantici con capacità Premium o Premium per utente hanno l'impostazione della proprietà dell'endpoint XMLA abilitata per la sola lettura. Ciò implica che le applicazioni possono eseguire query solo su un modello sematico. Per consentire alle applicazioni di eseguire operazioni di scrittura, è necessario che la proprietà dell'endpoint XMLA sia abilitata per la lettura/scrittura.

Per abilitare la lettura-scrittura per una capacità Premium

1. Selezionare Impostazioni>Portale di amministrazione.

2. Nel portale di amministrazione, selezionare Impostazioni capacità>Power BI Premium> nome della capacità.

3. Espandere Carichi di lavoro. Nell'impostazione Endpoint XMLA selezionare Lettura/Scrittura. L'impostazione dell'endpoint XMLA si applica a tutte le aree di lavoro e modelli semantici assegnati alla capacità.

   

Per abilitare la lettura-scrittura per Premium per utente

1. Selezionare Impostazioni>Portale di amministrazione.
2. Nel Portale di amministrazione selezionare Premium per utente.
3. Espandere Impostazioni carico di lavoro modello semantico. Nell'impostazione Endpoint XMLA selezionare Lettura/Scrittura.

Connessione a un'area di lavoro Premium

Le aree di lavoro assegnate a una capacità includono una stringa di connessione in formato URL. Ad esempio:

powerbi://api.powerbi.com/v1.0/[tenant name]/[workspace name].

Le applicazioni che si connettono all'area di lavoro usano l'URL come nome del server di Analysis Services. Ad esempio:

powerbi://api.powerbi.com/v1.0/contoso.com/Sales Workspace.

Nota

La connessione a La mia area di lavoro usando l'endpoint XMLA attualmente non è supportata.

Utenti B2B e guest

Quando gli utenti accedono a un'area di lavoro nel tenant della Home, la sezione nome tenant nell'URL può essere sostituita da myorg. Ad esempio:

powerbi://api.powerbi.com/v1.0/myorg/Sales Workspace.

Quando gli utenti B2B\guest accedono alle aree di lavoro con un tenant diverso, il nome del tenant deve essere specificato nell'URL dell'origine dati. Ad esempio, quando un utente contoso.com viene invitato al tenant fabrikam.com e ha concesso l'autorizzazione a "Area di lavoro vendite", deve usare questo URL per connettersi:

powerbi://api.powerbi.com/v1.0/fabrikam.com/Sales Workspace.

Per determinare il nome di dominio primario e l'ID di un tenant, accedere al portale di Azure, selezionare Microsoft Entra ID dal menu principale e quindi prendere nota delle informazioni nella pagina di panoramica di Microsoft Entra. Per altre informazioni, vedere Trovare l'ID tenant di Microsoft Entra e il nome di dominio primario.

Per ottenere l'URL di connessione dell'area di lavoro

Nell'area di lavoro in Impostazioni>Premium>Connessione all'area di lavoro selezionare Copia.

Requisiti di connessione

Catalogo iniziale

Con alcuni strumenti, ad esempio SQL Server Profiler, è necessario specificare un Catalogo iniziale, vale a dire il modello semantico (database) a cui connettersi nell'area di lavoro. Nella finestra di dialogo Connetti al server, selezionare Opzioni>Proprietà connessione>Connetti al database e immettere il nome del modello semantico.

Nomi di area di lavoro duplicati

Aree di lavoro nella convalida di Power BI impedisce la creazione o la ridenominazione delle aree di lavoro con nomi duplicati. Quando ci si connette a un'area di lavoro con lo stesso nome di un'altra area di lavoro, è possibile che venga visualizzato il messaggio seguente:

Impossibile connettersi a powerbi://api.powerbi.com/v1.0/[tenant name]/[workspace name].

Per risolvere il problema, oltre al nome dell'area di lavoro specificare l'ObjectIDGuid. È possibile copiare l'ObjectIDGuid dall'objectID dell'area di lavoro nell'URL. Aggiungere objectID alla fine dell'URL di connessione. Ad esempio:

powerbi://api.powerbi.com/v1.0/myorg/Contoso Sales - 9d83d204-82a9-4b36-98f2-a40099093830.

Nome del modello semantico duplicato

Per connettersi a un modello semantico con lo stesso nome di un altro modello semantico nella stessa area di lavoro, accodare il GUID del modello semantico al nome del modello semantico. È possibile ottenere il nome e il GUID del modello semantico quando si è connessi all'area di lavoro in SSMS.

Ritardo nei modelli semantici visualizzati

Quando ci si connette a un'area di lavoro, la visualizzazione delle modifiche dei modelli semantici nuovi, eliminati e rinominati può richiedere alcuni minuti.

Modelli semantici non supportati

I modelli semantici seguenti non sono accessibili usando l'endpoint XMLA. Questi modelli semantici non verranno visualizzati nell'area di lavoro in SSMS o in altri strumenti:

• Modelli semantici basati su una connessione dinamica a un modello di Azure Analysis Services o SQL Server Analysis Services.
• Modelli semantici basati su una connessione dinamica a un modello semantico di Power BI in un'altra area di lavoro. Per altre informazioni, vedere Introduzione ai modelli semantici tra aree di lavoro.
• Modelli semantici con dati push usando l'API REST.
• Modelli semantici in La mia area di lavoro.
• Modelli semantici della cartella di lavoro di Excel.

Alias di server/aree di lavoro

Gli alias dei nomi di server, supportati in Azure Analysis Services, non sono supportati per le aree di lavoro Premium.

Sicurezza

Oltre alla proprietà dell'endpoint XMLA abilitata per la lettura-scrittura dall'amministratore della capacità, è necessario abilitare l'impostazione a livello di tenant Consenti endpoint XMLA e Analizza in Excel con modelli semantici locali nel portale di amministrazione. Se è necessario generare file Analizza in Excel (AIXL) che si connettono all'endpoint XMLA, è necessario abilitare anche l'impostazione a livello di tenant Gli utenti possono usare modelli semantici in Excel usando una connessione dinamica. Queste impostazioni sono entrambe abilitate per impostazione predefinita.

Consenti endpoint XMLA e Analizza in Excel con modelli semantici locali è un'impostazione di integrazione.

Gli utenti possono usare modelli semantici in Excel usando una connessione dinamica è un'impostazione di esportazione e condivisione.

La tabella seguente descrive le implicazioni di entrambe le impostazioni:

Impostazione	Consenti endpoint XMLA e Analizza in Excel con modelli semantici locali = disabilitata	Consenti endpoint XMLA e Analizza in Excel con modelli semantici locali = abilitata
Gli utenti possono usare modelli semantici in Excel usando una connessione dinamica = disabilitata	XMLA: non consentito Analizza in Excel: non consentito	XMLA: consentito Analizza in Excel: non consentito
Gli utenti possono usare modelli semantici in Excel usando una connessione dinamica = abilitata	XMLA: non consentito Analizza in Excel: consentito	XMLA: consentito Analizza in Excel: consentito

L'accesso tramite l'endpoint XMLA rispetta l'appartenenza a gruppi di sicurezza impostati a livello di area di lavoro o app.

I collaboratori dell'area di lavoro e ruoli superiori hanno autorizzazioni per la scrittura del modello semantico che in realtà sono uguali a quelle degli amministratori del database di Analysis Services. Possono distribuire nuovi modelli semantici da Visual Studio ed eseguire script TMSL in SSMS.

Gli altri utenti che dispongono di autorizzazioni per la creazione del modello semantico sono equivalenti ai lettori del database di Analysis Services. Possono connettersi ai modelli semantici e visualizzarli per l'uso e la visualizzazione dei dati. Le regole di sicurezza a livello di riga (RLS) vengono rispettate e non consentono la visualizzazione di metadati interni del modello semantico.

Le operazioni che richiedono autorizzazioni di amministratore del server di Analysis Services (anziché amministratore del database) in generale non sono supportate.

Rappresentazione

La rappresentazione dell'utente tramite la proprietà della stringa di connessione EffectiveUserName è supportata quando ci si connette a modelli semantici dell'area di lavoro Premium. L'account specificato in EffectiveUserName deve trovarsi nell'ID Microsoft Entra del tenant e deve disporre delle autorizzazioni sia per la lettura che per la compilazione per il modello semantico a cui è connesso. Se l'account non dispone delle autorizzazioni per la lettura e la compilazione, Power BI non può rappresentare l'account utente. L'esito della connessione sarà negativo e verrà restituito un errore.

È possibile eseguire la rappresentazione anche specificando uno o più ruoli dell'area di lavoro nella proprietà della stringa di connessione Ruoli. Con la proprietà Ruoli è possibile testare il downgrade dei membri del ruolo da autorizzazioni di scrittura ad autorizzazioni di lettura. Le autorizzazioni del ruolo seguenti si applicano a seconda dell'account dell'utente connesso:

• Se l'utente che esegue la rappresentazione è un amministratore dell'area di lavoro, che in realtà corrisponde a un amministratore del server in Analysis Services, non deve essere membro di uno dei ruoli specificati.

• Se l'utente che esegue la rappresentazione non è un amministratore dell'area di lavoro, deve appartenere a uno o più ruoli specificati; in caso contrario, viene restituito un errore di tipo di autorizzazione.

Ruoli del modello

Con l'endpoint XMLA, i ruoli, l'appartenenza ai ruoli, la sicurezza a livello di riga (RLS) e la sicurezza a livello di oggetto (OLS) possono essere definiti per gli utenti nell'ID Microsoft Entra del tenant. I ruoli del modello in Power BI vengono usati solo per RLS e OLS. Usare il modello di sicurezza di Power BI per controllare le autorizzazioni oltre RLS e OLS.

Per i progetti di modelli tabulari creati in Visual Studio, i ruoli possono essere definiti tramite Gestione ruoli nella finestra di progettazione dei modelli. Per i modelli semantici in Power BI, i ruoli possono essere definiti in Power BI Desktop prima della pubblicazione nel servizio. L'appartenenza al ruolo è specificata nel servizio Power BI. È possibile anche usare SSMS per creare e gestire ruoli. Nella maggior parte dei casi, le definizioni degli oggetti ruolo possono essere inserite in script usando TMSL per creare o modificare l'oggetto Ruoli. Gli script TMSL possono essere eseguiti in SSMS o con il cmdlet di PowerShell Invoke-ASCmd.

Quando si usano ruoli tramite l'endpoint XMLA, si applicano le limitazioni seguenti:

• L'unica autorizzazione per un ruolo che può essere impostata per i modelli semantici è l'autorizzazione per la lettura. Le altre autorizzazioni vengono concesse usando il modello di sicurezza di Power BI.
• Le entità servizio non funzionano con RLS e OLS, e non possono essere aggiunte come membri del ruolo del modello.
• L'accesso per la compilazione per un modello semantico è necessario per l'accesso in lettura tramite l'endpoint XMLA, indipendentemente dall'esistenza dei ruoli del modello semantico.

Impostazione delle credenziali dell'origine dati

I metadati specificati tramite l'endpoint XMLA possono creare connessioni alle origini dati, ma non possono impostare le credenziali dell'origine dati. È possibile invece impostare le credenziali nella pagina delle impostazioni del modello semantico nel servizio Power BI.

Entità servizio

Le entità servizio sono una registrazioni dell'app Microsoft Entra create all'interno del tenant per eseguire operazioni a livello di servizio e di risorsa senza intervento dell'utente. Sono un tipo univoco di identità utente con nome app, ID applicazione, ID tenant e segreto client o certificato per una password. Power BI Premium usa la stessa funzionalità per le entità servizio di Power BI Embedded.

È possibile usare entità servizio con l'endpoint XMLA per automatizzare le attività di gestione del modello semantico, ad esempio il provisioning delle aree di lavoro, la distribuzione di modelli e l'aggiornamento del modello semantico con:

• PowerShell
• Azure Automation
• App per la logica di azure
• Applicazioni client personalizzate

Per altre informazioni, vedere Automatizzare le attività dell'area di lavoro Premium e del modello semantico con entità servizio.

Distribuire progetti di modello da Visual Studio (SSDT)

La distribuzione di un progetto di modello tabulare in Visual Studio in un'area di lavoro Premium è molto simile alla distribuzione in un server di Azure o SQL Server Analysis Services. Le uniche differenze consistono nella proprietà Server di distribuzione specificata per il progetto e nella modalità con cui vengono specificate le credenziali dell'origine dati in modo che le operazioni di elaborazione possano importare dati dalle origini dati nel nuovo modello semantico nell'area di lavoro.

Per distribuire un progetto di modello tabulare creato in Visual Studio, impostare l'URL di connessione dell'area di lavoro nella proprietà Server di distribuzione del progetto. In Visual Studio, in Esplora soluzioni, fare clic con il pulsante destro del mouse sul progetto >Proprietà. Nella proprietà Server incollare l'URL di connessione dell'area di lavoro.

Quando la proprietà Server di distribuzione è specificata, è possibile distribuire il progetto.

Quando viene distribuito per la prima volta, viene creato un modello semantico nell'area di lavoro usando i metadati di model.bim. Nell'ambito dell'operazione di distribuzione, dopo che il modello semantico è stato creato nell'area di lavoro dai metadati del modello, l'elaborazione per caricare i dati nel modello semantico dalle origini dati non riesce.

L'elaborazione non riesce perché, a differenza di quando si esegue la distribuzione in un'istanza di Azure o SQL Server Analysis Server, in cui le credenziali dell'origine dati vengono richieste come parte dell'operazione di distribuzione, quando si esegue la distribuzione in un'area di lavoro Premium le credenziali dell'origine dati non possono essere specificate durante l'operazione di distribuzione. Dopo la distribuzione dei metadati e la creazione del modello semantico, invece, le credenziali dell'origine dati vengono specificate nel servizio Power BI nelle impostazioni del modello semantico. Nell'area di lavoro, selezionare Modelli semantici>Impostazioni>Credenziali origine dati>Modifica credenziali.

Quando vengono specificate le credenziali dell'origine dati, è possibile aggiornare il modello semantico nel servizio Power BI, configurare l'aggiornamento pianificato o eseguire l'elaborazione (aggiornamento) da SQL Server Management Studio per caricare i dati nel modello semantico.

Viene applicata la proprietà Opzione di elaborazione della distribuzione specificata nel progetto in Visual Studio. Tuttavia, se non sono state ancora specificate le credenziali per un'origine dati nel servizio Power BI, anche se la distribuzione dei metadati riesce, l'elaborazione non riuscirà. È possibile impostare la proprietà su Non elaborare, impedendo qualsiasi tentativo di elaborazione come parte della distribuzione. È possibile impostare la proprietà su nuovamente su Impostazione predefinita, poiché dopo aver specificato le credenziali dell'origine dati nelle impostazioni dell'origine dati per il nuovo modello semantico, l'elaborazione come parte delle successive operazioni di distribuzione riuscirà.

Connettersi a SSMS

L'uso di SSMS per connettersi a un'area di lavoro è analogo alla connessione a un server di Azure o SQL Server Analysis Services. L'unica differenza è rappresentata dall'impostazione dell'URL dell'area di lavoro nel nome del server e dalla necessità di usare l'autenticazione Active Directory - Universale con supporto MFA.

Connettersi a un'area di lavoro usando SSMS

1. In SQL Server Management Studio selezionare Connetti>Connetti al server.

2. In Tipo di server selezionare Analysis Services. In Nome server immettere l'URL dell'area di lavoro. In Autenticazione selezionare Active Directory - Universale con supporto MFA e quindi in Nome utente immettere l'ID utente dell'organizzazione.

   

Una volta connessi, l'area di lavoro viene mostrata come server di Analysis Services e i modelli semantici nell'area di lavoro sono mostrati come database.

Per altre informazioni sull'uso di SSMS per i metadati di script, vedere:

• Creare script per Analysis Services
• Tabular Model Scripting Language (TMSL)

Aggiornamento del modello semantico

L'endpoint XMLA offre un'ampia gamma di scenari per le funzionalità di aggiornamento con granularità fine che usano SSMS, l'automazione con PowerShell, Automazione di Azure e Funzioni di Azure con TOM. Ad esempio, è possibile aggiornare alcune determinate partizioni storiche di aggiornamento incrementale senza dover ricaricare tutti i dati storici.

A differenza della configurazione dell'aggiornamento nel servizio Power BI, le operazioni di aggiornamento tramite l'endpoint XMLA non sono limitate a 48 aggiornamenti al giorno e il timeout di aggiornamento pianificato non viene imposto.

La data, l'ora e lo stato per le operazioni di aggiornamento del modello semantico che includono una transazione di scrittura tramite l'endpoint XMLA vengono registrate e mostrate nella cronologia di aggiornamento del modello semantico.

Nota

Le operazioni di aggiornamento eseguite dall'endpoint XMLA non aggiornano automaticamente le cache dei riquadri. Le cache dei riquadri vengono aggiornate solo quando un utente accede al report.

Viste a gestione dinamica (DMV)

Le DMV di Analysis Services garantiscono la visibilità dei metadati del modello semantico, la derivazione e l'uso delle risorse. Le DMV disponibili per l'esecuzione di query in Power BI tramite l'endpoint XMLA sono limitate al massimo a quelle che richiedono autorizzazioni di amministratore di database. Alcune DMV, ad esempio, non sono accessibili poiché richiedono le autorizzazioni di amministratore del server di Analysis Services.

Modelli semantici creati in Power BI Desktop

Metadati avanzati

Le operazioni di scrittura XMLA nei modelli semantici creati in Power BI Desktop e pubblicati in un'area di lavoro Premium richiedono metadati avanzati. Per altre informazioni, vedere Metadati avanzati del modello semantico.

Attenzione

Attualmente, un'operazione di scrittura in un modello semantico creato in Power BI Desktop non ne consente un nuovo download come file PBIX. Assicurarsi di conservare il file PBIX originale.

dichiarazione origine dati

Quando si stabilisce una connessione alle origini dati e si esegue una query sui dati, Power BI Desktop usa le espressioni Power Query M come dichiarazioni di origini dati inline. Anche se è supportata in aree di lavoro Premium, la dichiarazione dell'origine dati inline di Power Query M non è supportata da Azure Analysis Services o SQL Server Analysis Services. Al contrario, gli strumenti di modellazione dei dati di Analysis Services come Visual Studio creano metadati usando dichiarazioni di origine dati strutturate o provider. Con l'endpoint XMLA, Premium supporta anche origini dati strutturate e provider, ma non come parte delle dichiarazioni di origini dati inline di Power Query M nei modelli di Power BI Desktop. Per altre informazioni, vedere Informazioni sui provider.

Power BI Desktop in modalità connessione dinamica

Power BI Desktop può collegarsi a un modello semantico di Power BI Premium usando una connessione dinamica. Quando si usa una connessione dinamica, non è necessario replicare i dati in locale e ciò facilita agli utenti l'uso dei modelli semantici. Gli utenti possono connettersi in due modi:

• Selezionare Modelli semantici di Power BI e quindi selezionare un modello semantico per creare un report. Questo è il modo consigliato agli utenti per la connessione dinamica ai modelli semantici. Questo metodo offre un'esperienza di individuazione migliorata mostrando il livello di approvazione dei modelli semantici. Non è necessario che gli utenti trovino gli URL dell'area di lavoro e ne tengano traccia. Per trovare un modello semantico, gli utenti digitano semplicemente il nome del modello semantico o scorrono per trovare il modello semantico che cercano.

  

• Usando Recupera dati>Analysis Services, specificare il nome di un'area di lavoro di Power BI Premium come URL, selezionare Connessione dinamica e quindi selezionare un modello semantico nello strumento di navigazione. In questo caso, Power BI Desktop usa l'endpoint XMLA perl la connessione dinamica al modello semantico come se fosse un modello di dati di Analysis Services.

  

Le organizzazioni con report esistenti connessi in modo dinamico a modelli di dati di Analysis Services che intendono eseguire la migrazione a modelli semantici Premium devono solo modificare l'URL del nome del server in Trasforma dati>Impostazioni origine dati.

Log di audit

Quando le applicazioni si connettono a un'area di lavoro, l'accesso tramite gli endpoint XMLA viene registrato nei log di controllo di Power BI con le operazioni seguenti:

Nome descrittivo dell'operazione	Nome operazione
Connesso al modello semantico di Power BI da un'applicazione esterna	ConnectFromExternalApplication
Aggiornamento del modello semantico di Power BI richiesto da un'applicazione esterna	RefreshDatasetFromExternalApplication
Modello semantico di Power BI creato da un'applicazione esterna	CreateDatasetFromExternalApplication
Modello semantico di Power BI modificato da un'applicazione esterna	EditDatasetFromExternalApplication
Modello semantico di Power BI eliminato da un'applicazione esterna	DeleteDatasetFromExternalApplication

Per altre informazioni, vedere Controllo di Power BI.

Considerazioni e limitazioni

I modelli semantici predefiniti di Power BI non possono essere modificati usando l'endpoint XMLA.

Contenuto correlato

Per altre informazioni relative a questo articolo, vedere:

• Scenari di utilizzo di Power BI: gestione avanzata dei modelli di dati
• Domande? Contattare la community di Power BI
• inviare suggerimenti, Contribuire con idee per migliorare Power BI