Denne artikel indeholder svar på nogle af de mest almindelige spørgsmål om Fabric-værktøjerne til administration af livscyklus.
Livscyklusstyring har to dele, integration og udrulning. Se oversigten over Git-integration for at forstå, hvad integration er i Fabric. Du kan finde oplysninger om, hvilke udrulningspipelines der er i Fabric, i oversigten over udrulningspipelines.
Du kan få en kort forklaring på Git-integration i oversigten over Git-integration. Et flerlinjet eller formateret svar på spørgsmålet. Brug den ønskede Markdown-formatering, forudsat at du bevarer indrykningen på linjerne efter | Tegn.
Du kan få en kort forklaring af udrulningspipelines i oversigten over udrulningspipelines.
Du kan få oplysninger om licenser under Fabric-licenser.
Alle arbejdsområder skal tildeles til en Fabric-licens. Du kan dog bruge forskellige kapacitetstyper til forskellige arbejdsområder.
Du kan få oplysninger om kapacitetstyper under Kapacitet og SKU'er.
Bemærk
- Premium pr. bruger, EM og A-SKU'er fungerer kun med Power BI-elementer. Hvis du føjer andre Fabric-elementer til arbejdsområdet, skal du have en prøveversion, en P- eller F-SKU.
- Når du opretter et arbejdsområde med en Premium pr. bruger, er det kun andre brugere af Premium pr. bruger, der kan få adgang til arbejdsområdet og bruge dets indhold.
Tilladelsesmodellen for udrulningspipelines er beskrevet i afsnittet om tilladelser .
Hvis du vil konfigurere udrulningsregler i udrulningspipelines, skal du være ejer af den semantiske model.
Hvis arbejdsområdekapaciteten er på én geografisk placering, mens Azure DevOps-lageret er på en anden placering, kan Fabric-administratoren beslutte, om der skal aktiveres eksporter på tværs af geografiske områder. Du kan finde flere oplysninger under Brugere kan eksportere elementer til Git-lagre på andre geografiske placeringer.
Der kan være flere årsager til, at et element blev fjernet fra arbejdsområdet.
- Hvis elementet ikke blev bekræftet, og du valgte det i en fortrydelseshandling , fjernes elementet fra arbejdsområdet.
- Hvis elementet blev bekræftet, kan det blive fjernet, hvis du skifter forgrening, og elementet ikke findes i den nye forgrening.
Dette er nogle vigtige overvejelser, du skal være opmærksom på:
- Begrænsninger for udrulningsregel
- Understøttede datakilder til regler for dataflow og semantiske modeller
- Trinvis opdatering
- Automation* Udrulningspipelines kan ikke bruges til at udrulle elementer til et arbejdsområde, der er i et andet område.
Du kan enten tildele ét arbejdsområde til din pipeline og udrulle det på tværs af pipelinen eller tildele et andet arbejdsområde til hver pipelinefase. Du kan få flere oplysninger under Tildel et arbejdsområde til en udrulningspipeline.
Hvad kan jeg gøre, hvis jeg har et datasæt med DirectQuery- eller Composite Connectivity-tilstand, der bruger variationstabeller eller tabeller med automatisk dato/klokkeslæt?
Datasæt, der bruger DirectQuery- eller Sammensat forbindelsestilstand og har variations- eller automatisk dato-/klokkeslætstabeller , understøttes ikke i udrulningspipelines. Hvis installationen mislykkes, og du mener, at det skyldes, at du har et datasæt med en variationstabel, kan du søge efter variationsegenskaben i tabellens kolonner. Du kan bruge en af de metoder, der er angivet nedenfor, til at redigere din semantiske model, så den fungerer i udrulningspipelines.
I dit datasæt skal du i stedet for at bruge Tilstanden DirectQuery eller Sammensat bruge importtilstand .
Fjern tabellerne med automatisk dato/klokkeslæt fra din semantiske model. Hvis det er nødvendigt, skal du slette eventuelle resterende variationer fra alle kolonnerne i tabellerne. Sletning af en variation kan gøre brugeropskrevne målinger, beregnede kolonner og beregnede tabeller ugyldige. Brug kun denne metode, hvis du forstår, hvordan din semantiske modelmodel fungerer, da det kan medføre beskadigelse af data i dine visualiseringer.
Når du fastgør et felt til et dashboard, hvis feltet er baseret på et element, der ikke understøttes (et element, der ikke findes på denne liste , ikke understøttes) eller på et element, som du ikke har tilladelse til at installere, gengives feltet ikke efter udrulningen af dashboardet. Hvis du f.eks. opretter et felt ud fra en rapport, der er afhængig af en semantisk model, er du ikke administrator, når du udruller rapporten, får du vist en fejlmeddelelse. Men når du udruller dashboardet med feltet, får du ikke vist en fejlmeddelelse, udrulningen lykkes, men feltet viser ingen oplysninger.
Ejeren af en udrullet sideinddelt rapport er den bruger, der har installeret rapporten. Når du udruller en sideinddelt rapport for første gang, bliver du ejer af rapporten.
Hvis du udruller en sideinddelt rapport til en fase, der allerede indeholder en kopi af den sideinddelte rapport, overskriver du den forrige rapport og bliver dens ejer i stedet for den forrige ejer. I sådanne tilfælde skal du bruge legitimationsoplysninger til den underliggende datakilde, så dataene kan bruges i den sideinddelte rapport.
Underrapporter for sideinddelte rapporter gemmes i den samme mappe, som indeholder din sideinddelte rapport. Hvis du vil undgå gengivelsesproblemer, skal du vælge både den overordnede rapport og underrapporterne, når du bruger selektiv kopi til at kopiere en sideinddelt rapport med underrapporter.
Hvordan gør jeg oprette en udrulningsregel for en sideinddelt rapport med en semantisk Fabric-model?
Regler for sideinddelte rapporter kan oprettes, hvis du vil pege den sideinddelte rapport på den semantiske model i samme fase. Når du opretter en installationsregel for en sideinddelt rapport, skal du vælge en database og en server.
Hvis du angiver en installationsregel for en sideinddelt rapport, der ikke har en semantisk Fabric-model, skal du angive både serveren og databasen, da destinationsdatakilden er ekstern.
Sideinddelte rapporter, der bruger en semantisk Fabric-model, bruger dog en intern semantisk model. I sådanne tilfælde kan du ikke stole på datakildenavnet for at identificere den semantiske Fabric-model, du opretter forbindelse til. Datakildenavnet ændres ikke, når du opdaterer det i destinationsfasen, ved at oprette en datakilderegel eller ved at kalde API'en til opdatering af datakilden . Når du angiver en installationsregel, skal du bevare databaseformatet og erstatte det semantiske modelobjekt-id i databasefeltet. Da den semantiske model er intern, forbliver serveren den samme.
Database – Databaseformatet for en sideinddelt rapport med en semantisk Fabric-model er
sobe_wowvirtualserver-<dataset ID>
. F.eks.,sobe_wowvirtualserver-d51fd26e-9124-467f-919c-0c48a99a1d63
.<dataset ID>
Erstat med dit datasæts id. Du kan hente datasæt-id'et fra URL-adressen ved at vælge det GUID, der kommer efterdatasets/
og før den næste skråstreg.Server – Den server, der er vært for databasen. Bevar den eksisterende server, som den er.
Hvis du downloader RDL'en for den sideinddelte rapport efter en installation, opdateres den muligvis ikke med den nyeste version, som du kan se i Power BI-tjeneste.
Når du har et dataflow, der indeholder semantiske modeller, der er konfigureret med trinvis opdatering, kopieres eller overskrives opdateringspolitikken ikke under installationen. Når du har udrullet et dataflow, der indeholder en semantisk model med trinvis opdatering til en fase, der ikke indeholder dette dataflow, skal du konfigurere den igen i destinationsfasen, hvis du har en opdateringspolitik. Hvis du udruller et dataflow med trinvis opdatering til en fase, hvor det allerede er placeret, kopieres politikken for trinvis opdatering ikke. Hvis du i sådanne tilfælde vil opdatere opdateringspolitikken i destinationsfasen, skal du gøre det manuelt.
Udrulningspipelines viser ikke datasæt, der tilhører datamarts i pipelinefaserne. Når du udruller en datamart, installeres datasættet også. Du kan få vist din datamarts datasæt i arbejdsområdet i den fase, den befinder sig i.