Vanliga frågor och svar om Fabric-livscykelhanteringsverktyg

Livscykelhantering har två delar, integrering och distribution. Information om vilken integrering som finns i Fabric finns i översikten för Git-integrering. Information om vilka distributionspipelines som finns i Fabric finns i översikten distributionspipelines.

En kort förklaring av Git-integrering finns i Översikt över Git-integrering. Ett flersidigt eller formaterat svar på frågan. Använd valfri Markdown-formatering, förutsatt att du behåller indraget på raderna efter | Tecken.

För en kort förklaring av distributionspipelines, se översikten över distributionspipelines.

Information om licenser finns i Fabric licenser.

Alla arbetsytor måste tilldelas en Fabric-licens. Du kan dock använda olika kapacitetstyper för olika arbetsytor.

Information om kapacitetstyper finns i Kapacitet och SKU:er.

Behörighetsmodellen för distributionspipelines beskrivs i avsnittet om behörigheter.

Om du vill konfigurera distributionsregler i distributionspipelines måste du vara ägare till den semantiska modellen.

Om arbetsytekapaciteten finns på en geografisk plats medan den Azure DevOps lagringsplatsen finns på en annan plats kan Fabric administratören bestämma om kors-geo-export ska aktiveras. Mer information finns i Användare kan exportera objekt till Git-lagringsplatser på andra geografiska platser.

Kom igång med Git-integrering med hjälp av kom igång-instruktionerna.

Det kan finnas flera orsaker till att ett objekt har tagits bort från arbetsytan.

• Om objektet inte har checkats in och du valde det i en ångra-åtgärd tas objektet bort från arbetsytan.
• Om objektet har checkats in kan det tas bort om du växlar grenar och objektet inte finns i den nya grenen.

Följande överväganden är viktiga att tänka på:

• Begränsningar för distributionsregel
• Datakällor som stöds för dataflöde och semantiska modellregler
• Inkrementell uppdatering
• Automatisering

Du kan antingen tilldela en arbetsyta till din pipeline och distribuera den över pipelinen eller tilldela en annan arbetsyta till varje pipelinesteg. För mer information, se tilldela en arbetsyta till en distributionspipeline.

Datauppsättningar som använder DirectQuery eller sammansatt anslutningsläge och har variant- eller automatiska datum-/tidstabeller stöds inte i distributionspipelines. Om distributionen misslyckas och du tror att det beror på att du har en datauppsättning med en varianttabell kan du leta efter variantegenskapen i tabellens kolumner. Du kan använda någon av följande metoder för att redigera din semantiska modell så att den fungerar i distributionspipelines.

• Använd importläge i stället för att använda DirectQuery eller sammansatt läge i datauppsättningen.

• Ta bort de automatiska datum-/tidstabellerna från din semantiska modell. Om det behövs tar du bort eventuella återstående variationer från alla kolumner i dina tabeller. Om du tar bort en variant kan användarskapade mått, beräknade kolumner och beräknade tabeller ogiltigförklaras. Använd endast den här metoden om du förstår hur din semantiska modellmodell fungerar eftersom den kan leda till att data skadas i dina visuella objekt.

När du fäster en panel på en instrumentpanel, om panelen förlitar sig på ett objekt som inte stöds (alla objekt som inte finns i listan stöds inte) eller på ett objekt som du inte har behörighet att distribuera, efter att ha distribuerat instrumentpanelen återges inte panelen. Om du till exempel skapar en panel från en rapport som förlitar sig på en semantisk modell som du inte är administratör för får du en felvarning när du distribuerar rapporten. Men när du distribuerar instrumentpanelen med rutan får du inget felmeddelande, och distributionen lyckas, men rutan visar ingen information.

För en kort förklaring av utplaceringsplaner, se översikten över utplaceringsplanen.

Distributionsplanens objekttyp visas först efter att en Fabric-administratör aktiverat tenant-inställningen. I administratörsportalen, under Klientorganisationsinställningar>Microsoft Fabric, aktiverar du Användare kan skapa objekt för distributionsplaner (förhandsversion), anger Tillämpa på till antingen hela organisationen eller en säkerhetsgrupp och väljer Använd.

Tills denna inställning är aktiverad förblir föremålstypen dold i varje arbetsyta.

Distributionen återgår till sitt standardbeteende. Föremål distribueras utan en deklarerad order och utan åtgärder före eller efter utplacering. Alla beroenden som skyddades av planen, till exempel en warehouse-vy som läser en lakehouse-tabell som har fyllts med data av en notebook, misslyckas igen.

En plan i korrekt ordning distribuerar objektmetadata i den ordning du anger, men att distribuera ett lakehouse innebär inte att rader läggs till i dess tabeller. En lagervy som läser en lakehouse-tabell går inte att binda om inte tabellen först har skapats av en notebook eller en datapipeline. Lägg till en åtgärd efter distribution mellan lakehouse och datalagret som skapar tabellen. En åtgärd rapporterar slutförande när själva åtgärden avslutas, inte när tjänsterna den matar har hunnit ikapp, så placera alla beredskapskontroller i den sista cellen i anteckningsboken eller den sista aktiviteten i datapipelinen. För ett exempel, se exempel på utplaceringsplaner.

En anteckningsboks standardfält för sjöhus innehåller ID:n som pekar på ett specifikt sjöhus i en specifik arbetsyta. Efter att anteckningsboken landar i en ny arbetsyta via Git kan dessa ID:n fortfarande peka på den ursprungliga arbetsytan. Ange antingen ett standardlakehouse för målmiljön i anteckningsbokens inställningar före körningen, eller låt anteckningsboken avgöra vilket lakehouse som ska användas under körning. Mer information finns i Källkontroll och distribution av notebook-filer.

Körningsutdata är synligt från utplaceringen i portalen. Åtgärdskörningar länkar tillbaka till den underliggande objektets körhistorik för loggar och stegdetaljer.

En misslyckad driftsättning återställer inte slutförda distributioner av objekt eller ändringar som gjorts av åtgärder. För vägledning om återhämtning, se Utplaceringen stoppades halvvägs.

Inte direkt. Utlös Update from Git från en extern schemaläggare som Azure-pipelines eller GitHub Actions, så körs den anslutna planen som en del av den driftsättningen.

Ja, om pipelinen driver utrullningen via ett Fabric-API som har stöd för att bifoga en plan, till exempel Git sync API, deploy pipelines-deploy-API:et eller batchimport-API:et. En distribution som drivs av Fabric CLI, Terraform-leverantören för Fabric eller fabric-cicd-biblioteket Python kan inte bifoga en plan.

No. En plan styr föremålen i en utplacering och de handlingar som sker runt dem. Konfiguration på arbetsytsnivå ingår inte i en distribution, så inställningar som arbetsytans identitet, Spark-inställningar och Git-anslutningen skapas eller uppdateras inte av en plan.

Konfigurera dessa i målarbetsytan innan du deployerar. Ett objekt som är beroende av konfiguration på arbetsytsnivå, såsom en anteckningsbok som autentiserar via arbetsytans identitet, misslyckas vid körning om målarbetsytan inte är konfigurerad på samma sätt som källkoden.

No. En distributionsplan följer den standardiserade Fabric-arbetsmiljöns rollmodell. För mer information, se behörigheter för utrullningsplaner.

Ägaren till en distribuerad sidnumrerad rapport är den användare som distribuerade rapporten. När du distribuerar en sidnumrerad rapport för första gången blir du ägare till rapporten.

Om du distribuerar en sidnumrerad rapport till en fas som redan innehåller en kopia av den sidnumrerade rapporten skriver du över den tidigare rapporten och blir dess ägare i stället för den tidigare ägaren. I sådana fall behöver du autentiseringsuppgifter till den underliggande datakällan, så att data kan användas i den sidnumrerade rapporten.

Sidnumrerade rapportunderrapporter sparas i samma mapp som innehåller den sidnumrerade rapporten. Om du vill undvika återgivningsproblem väljer du både den överordnade rapporten och underrapporterna när du använder selektiv kopiering för att kopiera en sidnumrerad rapport med underrapporter.

Sidnumrerade rapportregler kan skapas om du vill peka den sidnumrerade rapporten till den semantiska modellen i samma fas. När du skapar en distributionsregel för en sidnumrerad rapport måste du välja en databas och en server.

Om du anger en distributionsregel för en sidnumrerad rapport som inte har en Fabric semantisk modell, eftersom måldatakällan är extern, måste du ange både servern och databasen.

Sidnumrerade rapporter som använder en semantisk Fabric-modell använder dock en intern semantisk modell. I sådana fall kan du inte förlita dig på datakällans namn för att identifiera den Fabric semantiska modell som du ansluter till. Namnet på datakällan ändras inte när du uppdaterar det i målfasen, genom att skapa en datakällregel eller genom att anropa API:et för uppdateringsdatakällan . När du anger en distributionsregel måste du behålla databasformatet och ersätta objekt-ID:t för semantikmodellen i databasfältet. Eftersom den semantiska modellen är intern förblir servern densamma.

• Database – Databasformatet för en sidnumrerad rapport med en Fabric semantisk modell är sobe_wowvirtualserver-<dataset ID>. Exempel: sobe_wowvirtualserver-d51fd26e-9124-467f-919c-0c48a99a1d63 Ersätt <dataset ID> med datauppsättningens ID. Du kan hämta datamängds-ID:t från URL:en genom att välja det GUID som kommer efter datasets/ och före nästa snedstreck.

  

• Server – den server som är värd för din databas. Behåll den befintliga servern som den är.

Om du laddar ned RDL:en för den sidnumrerade rapporten efter en distribution kanske den inte uppdateras med den senaste versionen som du kan se i služba Power BI.

När du har ett dataflöde som innehåller semantiska modeller som har konfigurerats med inkrementell uppdatering kopieras eller skrivs inte uppdateringsprincipen över under distributionen. När du har distribuerat ett dataflöde som innehåller en semantisk modell med inkrementell uppdatering till en fas som inte innehåller det här dataflödet måste du konfigurera om det i målfasen om du har en uppdateringsprincip. Om du distribuerar ett dataflöde med inkrementell uppdatering till ett stadium där det redan finns kopieras inte principen för inkrementell uppdatering. I sådana fall, om du vill ändra uppdateringsprincipen i målfasen, måste du göra det manuellt.

Relaterat innehåll

• Kom igång med Git-integrering
• Kom igång med distributionspipelines