Netværksmulighed for datasæt med XMLA-slutpunktet
Power BI Premium-, Premium Pr. bruger- og Power BI Embedded-arbejdsområder understøtter forbindelse til åbne platforme fra Microsoft og klientprogrammer og værktøjer fra tredjepart ved hjælp af et XMLA-slutpunkt.
Hvad er et XMLA-slutpunkt?
Arbejdsområder bruger XML for Analysis (XMLA) til kommunikation mellem klientprogrammer og det program, som administrerer dine Power BI arbejdsområder og datasæt. Denne kommunikation sker via det, der ofte kaldes XMLA-slutpunkter. XMLA er den samme kommunikationsprotokol, der bruges af Microsoft Analysis Services-programmet, som under overfladen udfører semantisk modellering, styring, livscyklus og dataadministration i Power BI. Data, der sendes via XMLA-protokollen, er fuldt krypteret.
Som standard er skrivebeskyttet netværksmulighed ved hjælp af slutpunktet aktiveret for arbejdsbelastningen for datasæt i en kapacitet. Med skrivebeskyttet netværksmulighed kan datavisualiseringsprogrammer og -værktøjer forespørge datasætmodeldata, metadata, hændelser og skemaer. Læse-/skrive handlinger, der bruger slutpunktet, kan aktiveres, hvilket giver yderligere administration af datasæt, styring, avanceret semantisk modellering, fejlfinding og overvågning. Når læse-/skrive-funktionalitet er aktiveret, har datasæt mere paritet med Azure Analysis Services og SQL Server Analysis Services tabelmodelleringsværktøjer og -processer i virksomhedsklasse.
Vilkår for anvendelse
Brugen af XMLA-slutpunktet er underlagt følgende:
Enkeltbrugerprogram – Programmet bruger en enkelt brugerkonto eller appidentitet til at få adgang Power BI datasæt via XMLA-slutpunktet. De typiske eksempler er udviklerværktøjer, administratorscripts og automatiserede processer til udførelse af datamodellering og administrative opgaver, f.eks. ændring af metadata for et datasæt, udførelse af sikkerhedskopiering eller gendannelse eller udløsning af en opdatering af data. Den brugerkonto eller app-identitet, som klientprogrammet bruger til at få adgang til et datasæt, skal have en gyldig licens til Premium Per User (PPU), medmindre datasættet er placeret i en Premium kapacitet.
Multibrugerprogram – Programmet giver flere brugere adgang til et Power BI datasæt. Det kan f.eks. være et program på det midterste niveau, der integrerer et datasæt i en forretningsløsning og får adgang til datasættet på vegne af virksomhedens brugere.
- I Premium PPU (Per User) skal programmet kræve, at hver bruger logger på for at Power BI. Programmet bruger hver brugers adgangstoken til at få adgang til datasæt. Programmet har ikke tilladelse til at bruge en tjenestekonto eller en anden appidentitet til at udføre opgaver på vegne af brugerne. Hver enkelt bruger skal bruge sin Power BI-konto til at åbne rapporter, få adgang til datasæt og udføre forespørgsler.
- I Premium arbejdsområder kan programmet bruge en tjenestekonto eller et app-id på vegne af slutbrugerne, uden at hver enkelt bruger skal logge på for at Power BI.
Datamodellerings- og administrationsværktøjer
Nedenfor er nogle af de mest almindelige værktøjer, der bruges Azure Analysis Services datasæt og SQL Server Analysis Services og understøttes nu Premium datasæt:
Visual Studio med Analysis Services-projekter – også kendt som SQL Server Data Tools eller blot SSDT, er et modeloprettelsesværktøj i virksomhedsklasse til oprettelse af tabellariske Analysis Services-modeller. Analysis Services-projektudvidelser understøttes i alle Visual Studio 2017-udgaver og nyere udgaver, herunder den gratis Community-udgave. Udvidelsesversion 2.9.14 eller nyere er påkrævet for at udrulle tabellariske modeller i et Premium-arbejdsområde. Når du udruller, skal modellen være på kompatibilitetsniveauet 1500 eller højere. Læse-/skriveadgang til XMLA er påkrævet til arbejdsbelastningen for datasæt. Du kan få mere at vide under Værktøjer til Analysis Services.
SQL Server Management Studio (SSMS) – understøtter DAX-, MDX- og XMLA-forespørgsler. Udfør detaljerede opdateringshandlinger og scripting af metadata for datasæt ved hjælp af TMSL (Tabular Model Scripting Language). Skrivebeskyttet adgang er påkrævet til forespørgselshandlinger. Læse-/skriveadgang er påkrævet til scripting af metadata. Kræver SQL Server Management Studio-version 18.8 eller nyere. Download her.
SQL Server Profiler – Dette værktøj installeres sammen med SSMS og gør det muligt at spore og foretage fejlfinding af datasæthændelser. Profiler frarådes officielt til SQL Server, men er fortsat inkluderet i SSMS, og det understøttes stadig af hensyn til Analysis Services-Power BI. Kræver SQL Server Profiler version 18.8 eller nyere. Brugeren skal angive datasættet (detoprindelige katalog),når der oprettes forbindelse til XMLA-slutpunktet. Du kan få mere at vide under SQL Server Profiler for Analysis Services.
Analysis Services af installation – Dette værktøj er installeret med SSMS og sørger for udrulning af Visual Studio forfattede tabelmodelprojekter til Analysis Services og Premium arbejdsområder. Det kan køres interaktivt eller automatiseret fra kommandolinjen. Læse-/skriveadgang til XMLA er påkrævet. Du kan få mere at vide under Analysis Services-installationsguide.
PowerShell-cmdletter – Analysis Services-cmdlet'er kan bruges til at automatisere styring af datasæt, f. eks. opdateringshandlinger. Læse-/skriveadgang til XMLA er påkrævet. Version 21.1.18221 eller en nyere version af modulet SqlServer-PowerShell er påkrævet. Azure Analysis Services-cmdlet'er i modulet Az.AnalysisServices understøttes ikke for Power BI datasæt. Du kan få mere at vide under Analysis Services PowerShell-reference.
Power BI Report Builder – Et værktøj, der bruges til at oprette sideinddelte rapporter. Opret en rapportdefinition, der angiver, hvilke data der skal hentes, hvor du kan få dem, og hvordan de skal vises. Du kan få vist et eksempel på rapporten i Report Builder og derefter publicere den i Power BI-tjenesten. Skrivebeskyttet adgang til XMLA er påkrævet. Du kan få mere at vide under Power BI Report Builder.
Tabular Editor – Et værktøj med åben kildekode til oprettelse, vedligeholdelse og administration af tabellariske modeller ved hjælp af en intuitiv, letvægtseditor. En hierarkisk visning viser alle objekter i din tabellariske model. Objekter organiseres efter visningsmapper med understøttelse af egenskabsredigering med flere valg og fremhævning af DAX-syntaks. Skrivebeskyttet adgang til XMLA er påkrævet til forespørgselshandlinger. Læse-/skriveadgang er påkrævet til metadatahandlinger. Du kan få mere at vide under tabulareditor.github.io.
DAX Studio – Et værktøj med åben kildekode til DAX-oprettelse, -diagnosticering, -justering af ydeevne og analyse. Funktionerne omfatter objektgennemsyn, integreret sporing, udspecificering af udførelse af forespørgsler med detaljeret statistik, fremhævning og formatering af DAX-syntaks. Skrivebeskyttet adgang til XMLA er påkrævet til forespørgselshandlinger. Du kan få mere at vide under daxstudio.org.
ALM Toolkit – Et værktøj til skemasammenligning med åben kildekode til Power BI-datasæt, der oftest bruges til ALM-scenarier (Application Lifecycle Management). Udfør udrulning på tværs af miljøer, og bevar historiske data med trinvis opdatering. Sammenlign og flet metadatafiler, forgreninger og lagre. Genbrug fælles definitioner på datasæt. Skrivebeskyttet adgang er påkrævet til forespørgselshandlinger. Læse-/skriveadgang er påkrævet til metadatahandlinger. Du kan få mere at vide under alm-toolkit.com.
Microsoft Excel – Excel-pivottabeller er et af de mest almindelige værktøjer, der bruges til at opsummere, analysere, udforske og præsentere oversigtsdata fra Power BI-datasæt. Skrivebeskyttet adgang er påkrævet til forespørgselshandlinger. Klik og Kør-versionen af Office 16.0.11326.10000 eller nyere er påkrævet.
Tredjepart – Omfatter programmer og værktøjer til visualisering af klientdata, der kan oprette forbindelse til, forespørge om og forbruge datasæt Premium arbejdsområder. De fleste værktøjer kræver de nyeste versioner af MSOLAP-klientbiblioteker, men nogle bruger muligvis ADOMD. XMLA-slutpunkter er skrivebeskyttet eller i læse-/skrivetilstand afhængigt af handlingerne.
Klientbiblioteker
Klientprogrammer kommunikerer ikke direkte med XMLA-slutpunktet. De bruger i stedet klient biblioteker som abstraktionslag. Dette er de samme klientbiblioteker, som programmer bruger til at oprette forbindelse til Azure Analysis Services og SQL Server Analysis Services. Microsoft-programmer, f.eks. Excel, SSMS (SQL Server Management Studio) og Analysis Services-projektudvidelse til Visual Studio, installerer alle tre klientbiblioteker og opdaterer dem sammen med regelmæssige opdateringer af programmer og udvidelser. Udviklere kan også bruge klientbibliotekerne til at bygge brugerdefinerede programmer. I nogle tilfælde og især i forbindelse med tredjepartsprogrammer kan det være nødvendigt at installere nyere versioner af klientbibliotekerne, hvis de ikke installeres sammen med programmet. Klientbiblioteker opdateres hver måned. Du kan få mere at vide under Klientbiblioteker for oprettelse af forbindelse til Analysis Services.
Optimer datasæt for skrivehandlinger ved at aktivere store modeller
Når du bruger XMLA-slutpunktet til administration af datasæt med skrivehandlinger, anbefales det, at du aktiverer datasættet til store modeller. Dette reducerer forbruget af skrivehandlinger, hvilket kan gøre dem betydeligt hurtigere. For datasæt på over 1 GB (efter komprimering) kan forskellen være væsentlig. Du kan få mere at vide under Store modeller i Power BI Premium.
Aktivér læse/skriveadgang til XMLA
Som standard er XMLA-slutpunktets egenskabsindstilling aktiveret til skrivebeskyttet adgang for en Premium-kapacitet. Det betyder, at programmer kun kan forespørge et datasæt. Hvis programmer skal kunne udføre skrivehandlinger, skal XMLA-slutpunktets egenskabsindstilling være aktiveret til læse-/skriveadgang. XMLA-slutpunktets egenskabsindstilling for en kapacitet er konfigureret i arbejdsbelastningen for datasæt. Indstillingen for XMLA-slutpunktet gælder for alle arbejdsområder og datasæt, der er tildelt til kapaciteten.
Sådan aktiverer du læse/skrive-adgang for en kapacitet
Vælg Kapacitetsindstillinger > Power BI Premium > kapacitetsnavn på administrationsportalen.
Udvid Arbejdsbelastninger. Vælg Læsning og skrivning i indstillingen XMLA-slutpunkt.

Opret forbindelse til et Premium-arbejdsområde
Arbejdsområder, der er tildelt til en kapacitet, har en forbindelsesstreng i URL-format som dette,
powerbi://api.powerbi.com/v1.0/[tenant name]/[workspace name].
Programmer, der opretter forbindelse til arbejdsområdet, bruger URL-adressen, som om den var et Analysis Services-servernavn. F.eks.
powerbi://api.powerbi.com/v1.0/contoso.com/Sales Workspace.
Brugere med UPN'er i den samme lejer (ikke B2B) kan erstatte lejernavnet med myorg. For eksempel
powerbi://api.powerbi.com/v1.0/myorg/Sales Workspace.
B2B-brugere skal angive deres organisations UPN i lejernavnet. F.eks.
powerbi://api.powerbi.com/v1.0/fabrikam.com/Sales Workspace.
Bemærk
Log på Azure Portal for at bestemme det primære domænenavn og id for en Power BI-lejer, vælg Azure Active Directory i hovedmenuen, og notere oplysningerne på siden Azure Active Directory oversigt. Du kan finde flere oplysninger under Find Microsoft Azure AD lejer-id og det primære domænenavn.
Sådan henter du URL-adressen til arbejdsområdet
Under Indstillinger > Premium > Forbindelse til arbejdsområde i arbejdsområdet skal du vælge Kopiér.

Forbindelseskrav
Oprindeligt katalog
Ved nogle værktøjer, f. eks SQL Server Profiler, skal du angive et oprindeligt katalog, som er det datasæt (den database), der skal oprettes forbindelse til i arbejdsområdet. I dialogboksen Opret forbindelse til server skal du vælge Indstillinger > Egenskaber for forbindelse > Opret forbindelse til database og angive navnet på datasættet.

Identiske navne på arbejdsområder
Nye arbejdsområder (oprettet ved hjælp af den nye arbejdsområdeoplevelse) i Power BI pålægger validering for ikke at tillade oprettelse eller omdøbning af arbejdsområder med identiske navne. Arbejdsområder, der ikke er migreret, kan resultere i identiske navne. Når du opretter forbindelse til et arbejdsområde med det samme navn som et andet arbejdsområde, kan du få følgende fejl:
Der kan ikke oprettes forbindelse til powerbi://api.powerbi.com/v1.0/ [lejernavn]/[navn på arbejdsområde].
Hvis du vil undgå denne fejl, skal du ud over navnet på arbejdsområdet angive ObjectIDGuid, som kan kopieres fra arbejdsområdets objectID til URL-adressen. Føj objectID til URL-adressen til forbindelsen. F.eks.
'powerbi://api.powerbi.com/v1.0/myorg/Contoso Sales – 9d83d204-82a9-4b36-98f2-a40099093830'.
Duplikeret navn på datasæt
Når du opretter forbindelse til et datasæt med samme navn som et andet datasæt i det samme arbejdsområde, kan du føje datasættets GUID til datasættets navn. Du kan hente både datasættets navn og GUID, når du har forbindelse til arbejdsområdet i SSMS.
Forsinkelse i visning af datasæt
Når du opretter forbindelse til et arbejdsområde, kan der gå nogle minutter, inden ændringer i nye, slettede og omdøbte datasæt vises.
Ikke-understøttede datasæt
Følgende datasæt er ikke tilgængelige for XMLA-slutpunkter. Disse datasæt vises ikke under arbejdsområdet i SQL Server Management Studio eller i andre værktøjer:
- Datasæt, der er baseret på en direkte forbindelse til Azure Analysis Services eller SQL Server Analysis Services.
- Datasæt, der er baseret på en direkte forbindelse til et Power BI-datasæt i et andet arbejdsområde. Du kan få mere at vide under Introduktion til datasæt på tværs af arbejdsområder.
- Datasæt med pushdata ved hjælp af REST-API'en.
- Datasæt for Excel-projektmapper.
Alias for server/arbejdsområde
Servernavnaliasser, der understøttes Azure Analysis Services understøttes ikke for Premium arbejdsområder.
Sikkerhed
Ud over den egenskab for XMLA-slutpunktet, der aktiveres til læse-/skrivetilstand af kapacitetsadministratoren, skal indstillingen Tillad XMLA-slutpunkter og Analysér i Excel med datasæt i det lokale miljø på lejerniveau være aktiveret på administrationsportalen. Hvis du har brug for at generere Analysér i Excel-filer (AIXL), der opretter forbindelse til XMLA-slutpunktet, skal indstillingen Tillad direkte forbindelser på lejerniveau også være aktiveret. Disse indstillinger er begge aktiveret som standard.
Tillad XMLA-slutpunkter og Analysér i Excel med datasæt i det lokale miljø er en indstilling for integration.
I følgende tabel beskrives konsekvenserne af indstillingen Eksportér data for XMLA og Analysér i Excel (AIXL):
| Indstilling | Tillad XMLA-slutpunkter og Analysér i Excel med datasæt i det lokale miljø = deaktiveret | Tillad XMLA-slutpunkter og Analysér i Excel datasæt i det lokale miljø = aktiveret |
|---|---|---|
| Tillad, at direkte forbindelser må skifte = deaktiveret | XMLA fjernet fra, Analysér i et Excel, der ikke er tilladt, AIXL for datasæt i det miljø, der ikke er tilladt | Tilladt XMLA, Analysér Excel tilladt, AIXL for datasæt i det miljø, det er tilladt |
| Tillad, at direkte forbindelser skifter = aktiveret | XMLA er ikke tilladt, Analysér i Excel tilladt, AIXL for datasæt i det miljø, hvor det ikke er tilladt | Tilladt XMLA, Analysér Excel tilladt, AIXL for datasæt i det miljø, det er tilladt |
Tillad direkte forbindelser er en indstilling for eksport og deling.
Adgang via XMLA-slutpunktet overholder det medlemskab af sikkerhedsgrupper, der er angivet på arbejdsområde-/appniveau.
Bidragsydere i arbejdsområder og derover har skriveadgang til datasættet og svarer derfor til Analysis Services-databaseadministratorer. De kan udrulle nye datasæt fra Visual Studio og udføre TMSL-scripts i SSMS.
Handlinger, der kræver administratortilladelser til Analysis Services-serveren (i stedet for databaseadministrator), f.eks. serverniveausporinger og brugerrelation ved hjælp af egenskaben EffectiveUserName for forbindelsesstrenge, understøttes ikke i Premium-arbejdsområder på nuværende tidspunkt.
Andre brugere, der har tilladelsen Opret til et datasæt, svarer til Analysis Services-databaselæsere. De kan oprette forbindelse til og gennemse datasæt med henblik på dataforbrug og visualisering. Regler for sikkerhed på rækkeniveau overholdes, og de kan ikke se de interne metadata for datasæt.
Modelroller
Med XMLA-slutpunktet kan roller defineres for et datasæt, rollemedlemskab kan defineres for brugere af Microsoft Azure Active Directory (AAD), og der kan defineres sikkerhedsfiltre på rækkeniveau (RLS). Modelroller i Power BI bruges kun til sikkerhed på rækkeniveau. Brug Power BI-sikkerhedsmodellen til at styre tilladelser ud over sikkerhed på rækkeniveau.
I forbindelse med tabelmodelprojekter, der er Visual Studio, kan roller defineres ved hjælp af Rolleadministrator i modeldesigneren. Du kan definere roller for datasæt i Power BI ved at bruge SQL Server Management Studio til at oprette rolleobjekter og definere rolleegenskaber. I de fleste tilfælde kan rolleobjektdefinitioner scriptes ved hjælp af TMSL for at oprette eller ændre objektet Roller. TMSL-scripts kan udføres i SQL Server Management Studio eller med PowerShell-cmdletten Invoke-ASCmd.
Følgende begrænsninger gælder, når der arbejdes med datasætroller via XMLA-slutpunktet:
- Den eneste tilladelse for en rolle, der kan angives for datasæt, er læsetilladelse. Der tildeles andre tilladelser ved hjælp af Power BI-sikkerhedsmodellen.
- Tjeneste principaler, som kræver tilladelser som medlem af arbejdsområdet eller administrator, kan ikke føjes til roller.
- Oprettelsestilladelse til et datasæt er påkrævet for at få læseadgang via XMLA-slutpunktet, uanset om der findes datasætroller.
- Egenskaben "Roles=" for forbindelsesstrengen kan bruges til at teste rollemedlemmer med skriverettigheder til læsetilladelser. Medlemskontoen skal stadig være medlem af den relevante RLS-rolle. Dette er anderledes end at bruge Repræsentation med SQL Server Analysis Services eller Azure Analysis Services hvor RLS-rollemedlemskab antages, hvis kontoen er serveradministrator. I Premium arbejdsområder, hvor der ikke er nogen serveradministrator, skal kontoen tilhøre en rolle, for at RLS kan anvendes.
Du kan få mere at vide under Roller i tabelmodeller.
Angivelse af datakildens legitimationsoplysninger
De metadata, der er angivet via XMLA-slutpunktet, kan oprette forbindelse til datakilder, men kan ikke angive legitimationsoplysninger for datakilder. I stedet kan du angive legitimationsoplysninger på dataindstillingssiden i Power BI-tjenesten.
Tjenesteprincipaler
Tjenesteprincipaler er en appregistrering i Azure Active Directory, som du opretter i din lejer for at udføre uovervågede handlinger på ressource- og tjenesteniveau. De er en unik type af brugeridentitet med et appnavn, applikations-id, lejer-id og klienthemmelighed eller certifikat som adgangskode. Power BI Premium bruger den samme funktionalitet til tjenesteprincipaler som Power BI Embedded.
Tjeneste principaler kan også bruges med XMLA-slutpunktet til at automatisere administrationsopgaver for datasæt, f.eks. klargøring af arbejdsområder, udrulning af modeller og opdatering af datasæt med:
- PowerShell
- Azure Automation
- Azure Logic Apps
- Brugerdefinerede klientapplikationer
Se Automatiser opgaver for arbejdsområder og datasæt i Premium med tjenesteprincipaler, hvis du vil vide mere.
Udrul modelprojekter fra Visual Studio (SSDT)
Installation af et tabelmodelprojekt i et Visual Studio et Premium arbejdsområde er stort set det samme som at udrulle til en Azure- eller SQL Server Analysis Services server. De eneste forskelle er i egenskaben Installationsserver, der er angivet for projektet, og den måde legitimationsoplysninger til datakilden angives på, så behandlingshandlinger kan importere data fra datakilder til det nye datasæt i arbejdsområdet.
Hvis du vil installere et tabellarisk modelprojekt, der er oprettet i Visual Studio, skal du først angive URL-adressen til arbejdsområdeforbindelsen i egenskaben Installationsserver for projektet. Højreklik på projektet > Egenskaber i Løsningsoversigt i Visual Studio. Indsæt URL-adressen til arbejdsområdeforbindelsen i egenskaben Server.

Når egenskaben Installationsserver er angivet, kan projektet udrulles.
Når et projektet er udrullet første gang, oprettes der et datasæt i arbejdsområdet ved hjælp af metadata fra model.bim. Som en del af udrulningshandlingen, kan behandling med henblik på indlæsning af data i datasættet fra datakilder ikke udføres, efter at datasættet er blevet oprettet i arbejdsområdet fra modelmetadata.
Behandlingen mislykkes, eftersom legitimationsoplysninger ikke kan angives som en del af udrulninghandlingen, når der udrulles til en Premium-arbejdsområdedatakilde. Dette er ikke tilfældet, når der udrulles til en Azure- eller SQL Server Analysis Server-instans, hvor der anmodes om legitimationsoplysninger som en del af udrulningshandlingen. I stedet angives legitimationsoplysninger for datakilden i Power BI Service i datasætindstillingerne, efter at metadataene er udrullet, og datasættet er oprettet. Vælg Datasæt > Indstillinger > Legitimationsoplysninger for datakilde > Rediger legitimationsoplysninger i arbejdsområdet.

Når der er angivet legitimationsoplysninger for datakilden, kan du opdatere datasættet i Power BI-tjenesten, konfigurere den planlagte opdatering eller proces (opdatering) fra SQL Server Management Studio for at indlæse data i datasættet.
Der tages højde for egenskaben Behandlingsindstilling for udrulningen, der er angivet i projektet i Visual Studio. Men hvis en datakilde endnu ikke har fået angivet legitimationsoplysninger i Power BI-tjenesten, mislykkes behandlingen, selv hvis udrulningen af metadata lykkes. Du kan angive egenskaben til Behandl ikke, hvilket forhindrer et forsøg på at udføre behandling som en del af udrulningen, men du kan angive egenskaben til Standard igen, eftersom behandlingen udføres som en del af de efterfølgende udrulningshandlinger, fordi legitimationsoplysningerne for datakilden er angivet i indstillingerne for datakilden for det nye datasæt.
Opret forbindelse med SSMS
Brug af SSMS til at oprette forbindelse til et arbejdsområde svarer til at oprette forbindelse til en Azure- eller SQL Server Analysis Services-server. Den eneste forskel er, at du angiver URL-adressen til arbejdsområdet i servernavnet, og at du skal bruge godkendelse af typen Active Directory – Universal med MFA.
Opret forbindelse til et arbejdsområde ved hjælp af SSMS
Vælg Opret forbindelse > Opret forbindelse til server i SQL Server Management Studio.
Vælg Analysis Services i Servertype. Angiv URL-adressen til arbejdsområdet i Servernavn. Vælg Active Directory - Universal with MFA Support under Godkendelse, og angiv derefter dit organisationsbruger-id i Brugernavn.

Når forbindelsen er oprettet, vises arbejdsområdet som en Analysis Services-server, og datasæt i arbejdsområdet vises som databaser.

Du kan få mere at vide om, hvordan du bruger SSMS til at scripte metadata, under Opret Analysis Services-scripts og TMSL (Tabular Model Scripting Language).
Opdatering af datasæt
XMLA-slutpunktet giver mulighed for en lang række scenarier for detaljerede opdateringsfunktioner med SSMS, automatisering med PowerShell, Azure Automationog Azure Functions ved hjælp af TOM. Du kan f. eks. opdatere bestemte historiske partitioner med trinvis opdatering uden at skulle indlæse alle historiske data igen.
I modsætning til konfiguration af opdatering i Power BI-tjenesten er opdateringshandlinger via XMLA-slutpunktet er ikke begrænset til 48 opdateringer pr. dag, og timeout for den planlagte opdatering er ikke pålagt.
Dato, klokkeslæt og status for datasætopdateringshandlinger, der omfatter en skrivetransaktion via XMLA-slutpunktet, registreres og vises i opdateringshistorikken for datasættet.
Dynamic Management-visninger (DMV'er)
Analysis Services-DMV'er aktiverer synlighed for metadata for datasæt, dataafstamning og ressourcebrug. DMV'er, der er tilgængelige for forespørgsler i Power BI via XMLA-slutpunktet, er begrænset til dem, der kræver databaseadministratortilladelser. Nogle DMV'er er f. eks. ikke tilgængelige, fordi de kræver administratortilladelser til Analysis Services-server.
Datasæt, der er oprettet i Power BI Desktop
Forbedrede metadata
XMLA-skrivehandlinger i datasæt, der er forfattet Power BI Desktop og publiceret i et Premium arbejdsområde, kræver udvidede metadata. Du kan få mere at vide under Forbedrede metadata for datasæt.
Forsigtigt
På nuværende tidspunkt forhindrer en skrivehandling i et datasæt, der er oprettet i Power BI Desktop, datasættet i at blive downloadet tilbage som en PBIX-fil. Sørg for at beholde den oprindelige PBIX-fil.
Datakildeerklæring
Når du opretter forbindelse til datakilder og forespørger data, bruger Power BI Desktop Power Query-M-udtryk som indbyggede datakildeerklæringer. Når det understøttes Premium arbejdsområder, Power Query understøttes de indbyggede datakildeerklæringer i M ikke af Azure Analysis Services eller SQL Server Analysis Services. I stedet opretter Analysis Services-værktøjer til datamodellering, f.eks. Visual Studio, metadata ved hjælp af strukturerede datakildeerklæringer og/eller provider datakildeerklæringer. Med XMLA-slutpunktet understøtter Premium også strukturerede datakilder og providerdatakilder, men ikke som en del af Power Query indbyggede M-datakildeerklæringer i Power BI Desktop modeller. Du kan få mere at vide under Om providere.
Power BI Desktop i tilstanden for liveforbindelse
Power BI Desktop kan oprette forbindelse til et Power BI Premium-datasæt ved hjælp af en liveforbindelse. Når du bruger en liveforbindelse, skal dataene ikke replikeres lokalt, hvilket gør det nemmere for brugerne at bruge semantiske modeller. Der er to måder, som brugerne kan oprette forbindelse på:
Ved at vælge Power BI-datasæt og derefter vælge et datasæt for at oprette en rapport. Dette er den anbefalede måde for brugerne at oprette en liveforbindelse til datasæt på. Denne metode giver en forbedret oplevelse i forbindelse med at finde godkendelsesniveauet for datasættene. Brugerne behøver ikke at finde og holde styr på URL-adresser til arbejdsområdet. For at finde et datasæt skal brugerne blot skrive navnet på datasættet eller rulle ned for at finde det datasæt, de leder efter.

Den anden måde, som brugerne kan bruge til at oprette en liveforbindelse på, er ved hjælp af Hent data > Analysis Services, ved at angive navnet på et Power BI Premium-arbejdsområde som en URL-adresse og vælge Opret liveforbindelse. Til sidst skal de vælge et datasæt i Navigator. I dette tilfælde bruger Power BI Desktop XMLA-slutpunktet til at oprette liveforbindelse til datasættet, som om det var en Analysis Services-datamodel.

Organisationer, som har eksisterende rapporter med direkte forbindelse til Analysis Services datamodeller, der er planlagt til at blive overført til Premium-datasæt, skal kun ændre URL-adressen for servernavnet i Transformér indstillinger for > datakilde.
Overvågningslogge
Når programmer opretter forbindelse til et arbejdsområde, logføres adgang via XMLA-slutpunkter i Power BI-overvågningslogge med følgende handlinger:
| Brugervenligt handlingsnavn | Handlingsnavn |
|---|---|
| Der er oprettet forbindelse til Power BI-datasæt fra et eksternt program | ConnectFromExternalApplication |
| Der er anmodet om opdatering af Power BI-datasæt fra et eksternt program | RefreshDatasetFromExternalApplication |
| Der er oprettet et Power BI-datasæt fra et eksternt program | CreateDatasetFromExternalApplication |
| Power BI-datasæt er redigeret fra et eksternt program | EditDatasetFromExternalApplication |
| Power BI-datasæt er slettet fra et eksternt program | DeleteDatasetFromExternalApplication |
Du kan få mere at vide under Overvågning af Power BI.
Se også
Har du flere spørgsmål? Prøv at spørge Power BI-community'et