Connettività del modello semantico con l'endpoint XMLA
Le aree di lavoro power BI Premium, Premium per utente e Power BI Embedded usano un endpoint XMLA per supportare la connettività open platform da applicazioni e strumenti client Microsoft e di terze parti.
Endpoint XMLA
Le aree di lavoro usano il protocollo XML for Analysis (XMLA) per le comunicazioni tra applicazioni client e il motore che gestisce le aree di lavoro di Power BI e i modelli semantici. Queste comunicazioni sono attraverso i cosiddetti endpoint XMLA. XMLA è il protocollo di comunicazione usato dal motore di Microsoft Analysis Services, che esegue 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à di sola lettura tramite l'endpoint è abilitata per il carico di lavoro Modelli semantici in una capacità. Con le applicazioni e gli strumenti di visualizzazione dei dati di sola lettura possono eseguire query su dati del modello semantico, metadati, eventi e schema.
Le operazioni di lettura/scrittura tramite l'endpoint possono essere abilitate. La lettura/scrittura offre una gestione più semantica dei modelli, governance, modellazione semantica avanzata, debug e monitoraggio. Se abilitata, i modelli semantici hanno maggiore parità con azure Analysis Services e sql Server Analysis Services strumenti e processi di modellazione tabulari di livello aziendale.
Proprietà del server Analysis Services
Power BI Premium supporta molte proprietà del server 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 a utente singolo: 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 utente singolo includono strumenti di sviluppo, script di amministrazione e processi automatizzati. Queste applicazioni possono eseguire attività come la modellazione dei dati e le attività amministrative che modificano i metadati di un modello semantico, un'operazione di backup o ripristino o attivano un aggiornamento dati. L'account utente o l'identità dell'app usata dall'applicazione client 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 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 di 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.
Applicazioni client e strumenti
Applicazioni e strumenti comuni usati con Azure Analysis Services e SQL Server Analysis Services ora supportati dai modelli semantici Power BI Premium:
Microsoft Excel : le tabelle pivot di Excel sono uno degli strumenti più comuni usati per riepilogare, analizzare, esplorare e presentare i dati di riepilogo dai modelli semantici di Power BI. La sola lettura è necessaria per le operazioni di query. Richiede 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 le estensioni dei progetti di Analysis Services. Richiede l'estensione versione 2.9.14 o successiva per distribuire modelli tabulari in un'area di lavoro Premium. Il modello deve essere a livello di compatibilità 1500 o superiore per la distribuzione. Richiede la 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 scripting dei metadati del modello semantico usando il linguaggio TMSL (Tabular Model Scripting Language ). Richiede la sola lettura per le operazioni di query. Richiede la lettura/scrittura per i metadati di scripting. Richiede SSMS versione 18.9 o successiva. Scaricare SSMS.
SQL Server Profiler : SQL Server Profiler viene installato con SSMS, consente di tracciare e eseguire il debug di eventi del modello semantico. Anche se ufficialmente deprecato per SQL Server, Profiler è ancora incluso in SSMS e rimane supportato per Analysis Services e Power BI. Richiede SQL Server Profiler versione 18.9 o successiva. Gli utenti devono specificare il modello semantico (catalogo iniziale) durante la connessione con l'endpoint XMLA. Per altre informazioni, vedere SQL Server Profiler per Analysis Services.
Distribuzione guidata di Analysis Services: installato con SSMS, questo strumento fornisce la distribuzione di progetti di modelli tabulari creati da Visual Studio nelle aree di lavoro Analysis Services e Premium. Può essere eseguito in modo interattivo o dalla riga di comando per l'automazione. È necessario scrivere in lettura XMLA. Per altre informazioni, vedere Distribuzione guidata Analysis Services.
Cmdlet di PowerShell: usare i cmdlet di Analysis Services per automatizzare le attività di gestione semantica dei modelli, ad esempio le operazioni di aggiornamento. Richiede la lettura/scrittura XMLA. Richiede la versione 21.1.18256 o successiva del modulo SqlServer PowerShell. I cmdlet di Azure Analysis Services nel modulo Az.AnalysisServices non sono supportati per i modelli semantici di Power BI. Per altre informazioni, vedere Informazioni di riferimento su PowerShell per Analysis Services.
Power BI Generatore report: strumento per la creazione di report impaginati. Creare una definizione del report che specifica i dati da recuperare, dove ottenerli e come visualizzarli. È possibile visualizzare in anteprima il report in Generatore report e quindi pubblicare il report nella servizio Power BI. Richiede la sola lettura XMLA. Per altre informazioni, vedere Power BI Generatore report.
Editor tabulare: strumento open source per la creazione, la gestione e la gestione di modelli tabulari tramite un editor intuitivo e leggero. Una visualizzazione gerarchica mostra tutti gli oggetti nel modello tabulare. Organizza gli oggetti visualizzando cartelle con supporto per la modifica delle proprietà a selezione multipla e l'evidenziazione della sintassi DAX. Richiede xmlA di sola lettura per le operazioni di query. Richiede la lettura/scrittura per le operazioni sui 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 xmlA di sola lettura per le operazioni di query. Per altre informazioni, vedere daxstudio.org.
ALM Toolkit : uno strumento di confronto dello schema open source per i modelli semantici di Power BI, più spesso usato per scenari di gestione del ciclo di vita delle applicazioni (ALM). Eseguire la distribuzione in ambienti e conservare i dati cronologici degli aggiornamenti incrementali. Diff e unire file di metadati, rami e repository. Riutilizzare definizioni comuni tra modelli semantici. Richiede la sola lettura per le operazioni di query. Richiede la lettura/scrittura per le operazioni sui metadati. Per altre informazioni, vedere alm-toolkit.com.
Terze parti : include applicazioni e strumenti di visualizzazione dei dati client che possono connettersi, eseguire query e usare modelli semantici nelle aree di lavoro Premium. La maggior parte degli strumenti richiede le versioni più recenti delle librerie client MSOLAP, ma alcune possono usare ADOMD. L'endpoint XMLA di sola lettura o di lettura-scrittura dipende dalle operazioni.
Librerie client
Le applicazioni client e gli strumenti 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, SQL Server Management Studio (SSMS) e l'estensione dei progetti di Analysis Services per Visual Studio installano tutte e tre le librerie client e le aggiornano insieme agli aggiornamenti regolari delle applicazioni e delle estensioni. Gli sviluppatori possono usare le librerie client per compilare applicazioni personalizzate. In alcuni casi, in particolare con applicazioni di terze parti, se non installate con l'applicazione, potrebbe essere necessario installare versioni più recenti delle librerie client. Le librerie client vengono aggiornate mensilmente. Per altre informazioni, vedere Librerie client per la connessione ad Analysis Services.
Ottimizzare i modelli semantici per le operazioni di scrittura abilitando modelli di grandi dimensioni
Quando si usa l'endpoint XMLA per la gestione semantica dei modelli con operazioni di scrittura, è consigliabile abilitare il modello semantico per i modelli di grandi dimensioni. In questo modo si riduce il sovraccarico delle operazioni di scrittura, che possono renderle notevolmente più veloci. Per i modelli semantici 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 XMLA read-write
Per impostazione predefinita, i carichi di lavoro del modello semantico Premium o Premium per utente hanno l'impostazione della proprietà dell'endpoint XMLA abilitata per la sola lettura. Ciò significa che le applicazioni possono eseguire query solo su un modello semantico. Affinché le applicazioni eseguano operazioni di scrittura, la proprietà Endpoint XMLA deve essere abilitata per la lettura/scrittura.
Per abilitare la lettura/scrittura per una capacità Premium
Selezionare Impostazioni> Amministrazione portale.
Nel portale di Amministrazione selezionare Capacity settings Power BI Premium capacity name (Impostazioni>capacità Power BI Premium).>
Espandere Carichi di lavoro. Nell'impostazione Endpoint XMLA selezionare Lettura scrittura. L'impostazione endpoint XMLA si applica a tutte le aree di lavoro e a tutti i modelli semantici assegnati alla capacità.
Per abilitare la lettura/scrittura per Premium per utente
- Selezionare Impostazioni> Amministrazione portale.
- Nel Portale di amministrazione selezionare Premium per utente.
- Espandere Impostazioni del 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à hanno un 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 se fosse un nome del server Analysis Services. Ad esempio:
powerbi://api.powerbi.com/v1.0/contoso.com/Sales Workspace.
Gli utenti con UPN nello stesso tenant (non B2B) possono sostituire il nome del tenant con myorg. Ad esempio:
powerbi://api.powerbi.com/v1.0/myorg/Sales Workspace.
Gli utenti B2B devono specificare l'UPN dell'organizzazione nel nome del tenant. Ad esempio:
powerbi://api.powerbi.com/v1.0/fabrikam.com/Sales Workspace.
Per determinare il nome di dominio primario e l'ID di un tenant di Power BI, accedere al portale di Azure, selezionare Microsoft Entra ID dal menu principale e quindi prendere nota delle informazioni nella pagina Panoramica di Microsoft Entra. Per altre informazioni, vedere Trovare l'ID tenant di Microsoft Entra e il nome di dominio primario.
Nota
Connessione a un L'area di lavoro personale tramite l'endpoint XMLA non è attualmente supportata.
Per ottenere l'URL di connessione dell'area di lavoro
Nell'area di lavoro Impostazioni Area di lavoropremium >Connessione selezionare Copia.>
Requisiti di connessione
Catalogo iniziale
Con alcuni strumenti, ad esempio SQL Server Profiler, è necessario specificare un catalogo iniziale, ovvero il modello semantico (database) a cui connettersi nell'area di lavoro. Nella finestra di dialogo da Connessione a server selezionare Opzioni> Connessione proprietà> Connessione al database, immettere il nome del modello semantico.
Nomi duplicati dell'area di lavoro
Le aree di lavoro nella convalida di Power BI impediscono 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 ObjectIDGuid. È possibile copiare ObjectIDGuid dall'ID oggetto dell'area di lavoro nell'URL. Aggiungere l'objectID all'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, aggiungere il GUID del modello semantico al nome del modello semantico. È possibile ottenere sia il nome del modello semantico che il GUID quando si è connessi all'area di lavoro in SSMS.
Ritardo nei modelli semantici visualizzati
Quando ci si connette a un'area di lavoro, le modifiche apportate ai modelli semantici nuovi, eliminati e rinominati possono richiedere fino a pochi minuti.
Modelli semantici non supportati
I modelli semantici seguenti non sono accessibili tramite 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 nelle aree di lavoro.
- Modelli semantici con push dei dati usando l'API REST.
- Modelli semantici in Area di lavoro personale.
- Modelli semantici della cartella di lavoro di Excel.
Alias server/area di lavoro
Gli alias dei nomi del server, supportati in Azure Analysis Services, non sono supportati per le aree di lavoro Premium.
Sicurezza
Oltre alla proprietà Endpoint XMLA abilitata per la lettura/scrittura dall'amministratore della capacità, l'impostazione a livello di tenant Consenti endpoint XMLA e Analizza in Excel con modelli semantici locali deve essere abilitata nel portale di amministrazione. Se è necessario generare i 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 = disabilitato | Consenti endpoint XMLA e Analizza in Excel con modelli semantici locali = abilitato |
|---|---|---|
| Gli utenti possono usare modelli semantici in Excel usando una connessione dinamica = disabilitata | XMLA non consentito, Analizza in Excel non consentito, AIXL per i modelli semantici locali non consentiti | XMLA consentito, Analizza in Excel non consentito, AIXL per i modelli semantici locali consentiti |
| Gli utenti possono usare modelli semantici in Excel usando una connessione dinamica = abilitata | XMLA non consentito, Analizza in Excel consentito, AIXL per i modelli semantici locali non consentiti | XMLA consentito, Analizza in Excel consentito, AIXL per i modelli semantici locali consentiti |
L'accesso tramite l'endpoint XMLA rispetta l'appartenenza al gruppo di sicurezza impostata a livello di area di lavoro/app.
I collaboratori dell'area di lavoro e versioni successive hanno autorizzazioni per il modello semantico di scrittura, che sono in effetti uguali agli amministratori del database di Analysis Services. Possono distribuire nuovi modelli semantici da Visual Studio ed eseguire script TMSL in SSMS.
Gli utenti con autorizzazioni build semantic model sono equivalenti ai lettori di database di Analysis Services. Possono connettersi e esplorare modelli semantici per l'utilizzo e la visualizzazione dei dati. Le regole di sicurezza a livello di riga vengono rispettate e non possono visualizzare i metadati interni del modello semantico.
Le operazioni che richiedono autorizzazioni di amministratore del server Analysis Services (anziché amministratore del database) in generale non sono supportate.
Rappresentazione
La rappresentazione dell'utente tramite la proprietà EffectiveUserName stringa di connessione è supportata durante la connessione 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 lettura e compilazione per il modello semantico a cui è connesso. Se l'account non dispone delle autorizzazioni lettura e compilazione, Power BI non può rappresentare l'account utente. La connessione avrà esito negativo e verrà restituito un errore.
È anche possibile eseguire la rappresentazione specificando uno o più ruoli dell'area di lavoro nella proprietà Roles stringa di connessione. Con la proprietà Roles è possibile testare il downgrade dei membri del ruolo con autorizzazioni di scrittura per le 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 effetti uguale 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 o un utente non trovato.
Ruoli del modello
Con l'endpoint XMLA, i ruoli, l'appartenenza ai ruoli, la sicurezza a livello di riga 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 la sicurezza a livello di riga e ols. Usare il modello di sicurezza di Power BI per controllare le autorizzazioni oltre la sicurezza a livello di riga e OLS.
Per i progetti di modello tabulare creati in Visual Studio, i ruoli possono essere definiti usando Gestione ruoli nella finestra di progettazione 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 viene specificata nella servizio Power BI. SSMS può essere usato anche per creare e gestire ruoli. Nella maggior parte dei casi, le definizioni degli oggetti ruolo possono essere create tramite TMSL per creare o modificare l'oggetto Roles. Gli script TMSL possono essere eseguiti in SSMS o con il cmdlet di PowerShell Invoke-ASCmd .
Quando si lavora con i 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 lettura. Altre autorizzazioni vengono concesse usando il modello di sicurezza di Power BI.
- Le entità servizio non funzionano con la sicurezza a livello di riga e OLS e non possono essere aggiunte come membri del ruolo del modello.
- L'autorizzazione di compilazione per un modello semantico è necessaria per l'accesso in lettura tramite l'endpoint XMLA, indipendentemente dall'esistenza di 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. Al contrario, le credenziali possono essere impostate nella pagina delle impostazioni del modello semantico nel servizio Power BI.
Entità servizio
Le entità servizio sono una registrazione dell'app Microsoft Entra creata all'interno del tenant per eseguire operazioni automatiche a livello di risorsa e servizio. Si tratta di un tipo univoco di identità utente con nome dell'app, ID applicazione, ID tenant e segreto client o certificato per una password. Power BI Premium usa la stessa funzionalità dell'entità servizio di Power BI Embedded.
Le entità servizio possono essere usate con l'endpoint XMLA per automatizzare le attività di gestione semantica dei modelli, ad esempio le aree di lavoro di provisioning, la distribuzione di modelli e l'aggiornamento semantico del modello 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 equivale alla distribuzione in un server di Azure o SQL Server Analysis Services. Le uniche differenze sono nella proprietà Server di distribuzione specificata per il progetto e il modo in cui vengono specificate le credenziali dell'origine dati in modo che le operazioni di elaborazione possano importare dati da 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 si specifica la proprietà Server di distribuzione, è possibile distribuire il progetto.
Quando viene distribuito per la prima volta, viene creato un modello semantico nell'area di lavoro usando i metadati del file model.bim. Come parte dell'operazione di distribuzione, dopo la creazione del modello semantico nell'area di lavoro dai metadati del modello, l'elaborazione per caricare i dati nel modello semantico dalle origini dati avrà esito negativo.
L'elaborazione non riesce perché, a differenza della distribuzione in un'istanza di Azure o SQL Server Analysis Server, in cui vengono richieste le credenziali dell'origine dati come parte dell'operazione di distribuzione, quando si esegue la distribuzione in un'origine dati premium non è possibile specificare le credenziali dell'origine dati come parte dell'operazione di distribuzione. Al contrario, dopo aver completato la distribuzione dei metadati e aver creato il modello semantico, le credenziali dell'origine dati vengono quindi specificate nel servizio Power BI nelle impostazioni del modello semantico. Nell'area di lavoro selezionare Modelli semantici> Impostazioni> Credenziali origine dati>Modifica credenziali.
Quando si specificano le credenziali dell'origine dati, è possibile aggiornare il modello semantico nel servizio Power BI, configurare l'aggiornamento pianificato o elaborare (aggiornamento) da SQL Server Management Studio per caricare i dati nel modello semantico.
Viene osservata la proprietà opzione di elaborazione della distribuzione specificata nel progetto in Visual Studio. Tuttavia, se un'origine dati non dispone di credenziali specificate nella servizio Power BI, anche se la distribuzione dei metadati ha esito positivo, l'elaborazione avrà esito negativo. È possibile impostare la proprietà su Non elaborare, impedendo qualsiasi tentativo di elaborazione come parte della distribuzione. È possibile impostare di nuovo la proprietà su Default perché una volta specificate le credenziali dell'origine dati nelle impostazioni dell'origine dati per il nuovo modello semantico, l'elaborazione come parte delle successive operazioni di distribuzione avrà esito positivo.
Connettersi a SSMS
L'uso di SSMS per connettersi a un'area di lavoro è simile alla connessione a un server di Azure o SQL Server Analysis Services. L'unica differenza consiste nel specificare l'URL dell'area di lavoro nel nome del server ed è necessario usare Active Directory - Universale con l'autenticazione MFA .
Connessione a un'area di lavoro tramite SSMS
In SQL Server Management Studio selezionare Connessione> Connessione su Server.
In Tipo di server selezionare Analysis Services. In Nome server immettere l'URL dell'area di lavoro. In Autenticazione selezionare Active Directory - Universale con MFA e quindi in Nome utente immettere l'ID utente dell'organizzazione.
Quando si è connessi, l'area di lavoro viene visualizzata come server Analysis Services e i modelli semantici nell'area di lavoro vengono visualizzati come database.
Per altre informazioni sull'uso di SSMS per lo script dei metadati, vedere:
Aggiornamento semantico del modello
L'endpoint XMLA consente un'ampia gamma di scenari per funzionalità di aggiornamento con granularità fine usando SSMS, automazione con PowerShell, Automazione di Azure e Funzioni di Azure tramite TOM. Ad esempio, è possibile aggiornare determinate partizioni cronologiche di aggiornamento incrementale senza dover ricaricare tutti i dati cronologici.
A differenza della configurazione dell'aggiornamento nella servizio Power BI, le operazioni di aggiornamento tramite l'endpoint XMLA non sono limitate a 48 aggiornamenti al giorno e il timeout dell'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 visualizzate 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 offrono visibilità sui metadati del modello semantico, sulla derivazione e sull'utilizzo 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 del database. Alcune DMV, ad esempio, non sono accessibili perché richiedono autorizzazioni di amministratore del server Analysis Services.
Modelli semantici creati da Power BI Desktop
Metadati avanzati
Le operazioni di scrittura XMLA sui 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
A questo punto, un'operazione di scrittura su un modello semantico creato in Power BI Desktop impedisce il download come file PBIX. Assicurarsi di conservare il file PBIX originale.
dichiarazione dell'origine dati
Quando ci si connette alle origini dati e si eseguono query sui dati, Power BI Desktop usa espressioni M di Power Query come dichiarazioni di origine dati inline. Sebbene sia supportato nelle 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. Gli strumenti di modellazione dei dati di Analysis Services, ad esempio Visual Studio, creano metadati usando dichiarazioni di origine dati strutturata o del provider . Con l'endpoint XMLA, Premium supporta anche origini dati strutturate e provider, ma non come parte delle dichiarazioni di origine 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ò connettersi a un modello semantico di Power BI Premium usando una connessione dinamica. Usando una connessione dinamica, i dati non devono essere replicati in locale, semplificando l'utilizzo dei modelli semantici da parte degli utenti. 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 per consentire agli utenti di connettersi in tempo reale ai modelli semantici. Questo metodo offre un'esperienza di individuazione migliorata che mostra il livello di verifica dell'autenticità dei modelli semantici. Gli utenti non devono trovare e tenere traccia degli URL dell'area di lavoro. 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 un nome di area di lavoro Power BI Premium come URL, selezionare Connessione live e quindi in Strumento di navigazione selezionare un modello semantico. In questo caso, Power BI Desktop usa l'endpoint XMLA per connettersi in tempo reale al modello semantico come se fosse un modello di dati di Analysis Services.
Le organizzazioni con report esistenti connessi in tempo reale ai modelli di dati di Analysis Services e intendono eseguire la migrazione ai modelli semantici Premium devono modificare solo l'URL del nome del server in Trasformare le impostazioni dell'origine dati>.
Log di audit
Quando le applicazioni si connettono a un'area di lavoro, l'accesso tramite endpoint XMLA viene registrato nei log di controllo di Power BI con le operazioni seguenti:
| Nome descrittivo dell'operazione | Nome operazione |
|---|---|
| Connessione al modello semantico di Power BI da un'applicazione esterna | Connessione FromExternalApplication |
| Aggiornamento del modello semantico di Power BI richiesto da un'applicazione esterna | RefreshDatasetFromExternalApplication |
| Creazione di un modello semantico di Power BI 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.
Contenuto correlato
Per altre informazioni relative a questo articolo, vedere:
Commenti e suggerimenti
In arrivo: Nel corso del 2024 verranno ritirati i problemi di GitHub come meccanismo di feedback per il contenuto e verranno sostituiti con un nuovo sistema di feedback. Per altre informazioni, vedi: https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per