Denne artikel giver svar på nogle af de mest almindelige spørgsmål om Fabric-livscyklusstyringsværktøjerne.
Generelle spørgsmål
Hvad er livscyklusstyring i Microsoft Fabric?
Livscyklusstyring har to dele, integration og udrulning. For at forstå, hvad integration er i Fabric, se the Git integration overview. For at forstå, hvad deployment pipelines er i Fabric, se oversigten over deployment pipelines.
Hvad er Git-integration?
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.
Hvad er udrulningspipelines?
Du kan få en kort forklaring af udrulningspipelines i oversigten over udrulningspipelines.
Licensspørgsmål
Hvilke licenser er nødvendige for at arbejde med livscyklusstyring?
For information om licenser, se Fabric licenses.
Hvilken type kapacitet har jeg brug for?
Alle arbejdsområder skal tildeles 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
- PPU-, EM- og A-SKU'er virker kun med Power BI-produkter. Hvis du tilføjer andre Fabric-elementer til arbejdsområdet, skal du bruge en prøve-, 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.
Tilladelser
Hvad er tilladelsesmodellen for udrulningspipelines?
Tilladelsesmodellen for udrulningspipelines er beskrevet i afsnittet om tilladelser .
Hvilke tilladelser skal jeg bruge for at konfigurere udrulningsregler?
Hvis du vil konfigurere udrulningsregler i udrulningspipelines, skal du være ejer af den semantiske model.
Spørgsmål om Git-integration
Kan jeg oprette forbindelse til et lager, der er i et andet område end mit arbejdsområde?
Hvis arbejdsområdets kapacitet er ét geografisk sted, mens Azure DevOps-repoet er et andet, kan Fabric-administratoren beslutte, om der skal aktiveres cross-geo eksport. Du kan finde flere oplysninger under Brugere kan eksportere elementer til Git-lagre på andre geografiske placeringer.
Hvordan gør jeg komme i gang med Git-integration?
Hvorfor blev mit element fjernet fra arbejdsområdet?
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.
Spørgsmål om udrulningspipelines
Hvad er nogle generelle udrulningsbegrænsninger, du skal være opmærksom på?
Følgende overvejelser er vigtige at være opmærksom på:
Hvordan kan jeg tildele arbejdsområder til alle faser i en pipeline?
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 Sammensat forbindelsestilstand, der bruger variations- eller automatiske dato-/klokkeslætstabeller?
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 følgende metoder 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 resultere i beskadigelse af data i dine visualiseringer.
Hvorfor viser nogle felter ikke oplysninger efter udrulningen?
Når du fastgør en tile til et dashboard, hvis tilen er afhængig af et ikke-understøttet element (ethvert element uden for denne liste er ikke understøttet), eller på et item, du ikke har tilladelse til at deploye, så vises tilen ikke efter at have deployet 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.
Spørgsmål om udrulningsplan
Hvad er en udsendelsesplan?
For en kort forklaring af udrulningsplaner, se oversigten over udrulningsplanen.
Jeg kan ikke se udrulningsplan-elementtypen i mit arbejdsområde. Hvordan får jeg den til at dukke op?
Udrulningsplan-objekttypen vises kun, efter at en Fabric-administrator har aktiveret lejerindstillingen. I admin-portalen, under LejerindstillingerMicrosoft>Fabric, aktiver Brugere kan oprette implementeringsplan- (forhåndsvisnings-) elementer, sætte Apply enten til hele organisationen eller en sikkerhedsgruppe, og vælg Apply.
Indtil denne indstilling er aktiveret, forbliver genstandstypen skjult i alle arbejdsområder.
Hvad sker der, hvis jeg bliver udsendt uden at vedhæfte en plan?
Udrulningen falder tilbage til sin standardadfærd. Genstande udrulles uden en erklæret ordre og uden handlinger før eller efter udsendelse. Enhver afhængighed, planen beskyttede, såsom en lagervisning, der læser en lakehouse-tabel fyldt med en notesbog, fejler igen.
Hvorfor kunne min lagervisning ikke binde, selvom varerne blev udsendt i den rigtige rækkefølge?
En korrekt ordnet plan deployerer itemmetadata i den rækkefølge, du angiver, men at deploye et lakehouse lægger ikke rækker i dets tabeller. En warehouse-visning, der læser en lakehouse-tabel, kan ikke binde, medmindre en notesbog eller datapipeline først producerede den tabel. Tilføj en post-deploy handling mellem søhuset og lageret, der producerer bordet. En handling rapporterer færdiggørelse, når selve handlingen slutter, ikke når de tjenester, den leverer til, har indhentet den, så sæt enhver parathedskontrol i den sidste celle i notesbogen eller den sidste aktivitet i datapipelinen. For et eksempel, se eksempler på udrulningsplaner.
Hvorfor skrev min notesbog til det forkerte arbejdsområde efter udrulningen?
En notesbogs standard lakehouse-felt indeholder ID'er, der peger på et specifikt lakehouse i et bestemt arbejdsområde. Når notesbogen lander i et nyt arbejdsområde via Git, kan disse ID'er stadig pege på det oprindelige arbejdsområde. Enten sæt standard-lakehouse for målmiljøet i notebook-indstillingerne før kørselen, eller lad notebooken løse sin lakehouse under kørsel. For mere information, se Notebook versionskontrol og implementering.
Hvor kan jeg se, hvad planen gjorde under en gennemspilning?
Kørselsoutput er synligt fra udrulningen i portalen. Handlingskørsler linker tilbage til den underliggende genstands kørselshistorik for logfiler og trindetaljer.
Hvordan kommer jeg mig efter en udsendelse, der mislykkedes delvist?
En mislykket udrulning ruller ikke færdiggjorte genstandsudrulninger eller ændringer foretaget af handlinger tilbage. For vejledning om genopretning, se Udsendelsen stoppede undervejs.
Kan jeg køre en udsendelsesplan efter en tidsplan?
Ikke direkte. Udløs opdatering fra Git fra en ekstern planlægger som Azure Pipelines eller GitHub Actions, og den tilknyttede plan kører som en del af den udrulning.
Kan jeg bruge en udrulningsplan fra min CI-pipeline?
Ja, hvis pipelinen driver udrulningen gennem et Fabric API, der understøtter vedhæftning af en plan, såsom Git sync API'en, deployer deployment pipelines API eller batch import API. En implementering drevet af Fabric CLI, Terraform-leverandøren for Fabric eller fabric-cicd Python-biblioteket kan ikke tilknytte en plan.
Deployerer en deployeringsplan workspace-indstillinger?
Nej. En plan styrer genstandene i en udsendelse og de handlinger, der foregår omkring dem. Konfiguration på arbejdsområdeniveau er ikke en del af en deployment, så indstillinger som workspace-identitet, Spark-indstillinger og Git-forbindelsen bliver ikke oprettet eller opdateret af en plan.
Konfigurer disse i målarbejdsområdet, før du deployerer. Et element, der afhænger af konfiguration på arbejdsområde, såsom en notesbog der autentificerer gennem arbejdsområdets identitet, fejler under kørsel, hvis målarbejdsområdet ikke er konfigureret på samme måde som kilden.
Kræver en udsendelsesplan særlige tilladelser?
Nej. En implementeringsplan følger den standard Fabric workspace-rollemodel. For mere information, se tilladelser til udrulningsplan.
Sideinddelte rapporter
Hvem er ejer af en udrullet sideinddelt rapport?
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.
Hvor er mine sideinddelte rapportunderrapporter?
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 opretter jeg en implementeringsregel for en pagineret rapport med en Fabric-semantisk 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 sætter en deploymentsregel for en pagineret rapport, der ikke har en Fabric-semantisk model, fordi måldatakilden er ekstern, skal du specificere både serveren og databasen.
Dog bruger paginerede rapporter, der bruger en Fabric-semantisk model, en intern semantisk model. I sådanne tilfælde kan du ikke stole på, at datakildens navn identificerer den Fabric-semantiske model, du forbinder 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 pagineret rapport med en Fabric semantisk 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.
Kan jeg downloade RDL-filen for den sideinddelte rapport efter udrulningen?
Efter en udrulning, hvis du downloader RDL'en af den paginerede rapport, er den måske ikke opdateret med den nyeste version, som du kan se i Power BI-tjeneste.
Dataflows
Hvad sker der med konfigurationen af trinvis opdatering efter installation af dataflow?
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.