Veelgestelde vragen over de hulpprogramma's voor levenscyclusbeheer van Fabric

Levenscyclusbeheer heeft twee onderdelen, integratie en implementatie. Raadpleeg de Git-integratieoverzicht voor meer informatie over de integratie in Fabric. Raadpleeg het overzicht van deployment-pijplijnen voor meer informatie over de implementatiepijplijnen in Fabric.

Zie het overzicht van Git-integratie voor een korte uitleg van Git-integratie. Een multiline of opgemaakt antwoord op de vraag. Gebruik elke gewenste Markdown-opmaak, mits u de inspringing behoudt op de regels na de '|' tekens.

Zie het overzicht van implementatiepijplijnen voor een korte uitleg van implementatiepijplijnen.

Zie Fabric licenties voor meer informatie over licenties.

Alle werkruimten moeten worden toegewezen aan een Fabric licentie. U kunt echter verschillende capaciteitstypen gebruiken voor verschillende werkruimten.

Zie Capaciteit en SKU's voor meer informatie over capaciteitstypen.

Het machtigingsmodel voor implementatiepijplijnen wordt beschreven in de sectie machtigingen .

Als u implementatieregels in implementatiepijplijnen wilt configureren, moet u de eigenaar van het semantische model zijn.

Als de capaciteit van de werkruimte zich op één geografische locatie bevindt terwijl de Azure DevOps opslagplaats zich op een andere locatie bevindt, kan de Fabric-beheerder bepalen of cross-geo-exports moeten worden ingeschakeld. Zie Gebruikers kunnen items exporteren naar Git-opslagplaatsen op andere geografische locaties voor meer informatie.

Ga aan de slag met Git-integratie met behulp van de instructies om aan de slag te gaan.

Er kunnen verschillende redenen zijn waarom een item uit de werkruimte is verwijderd.

• Als het item niet is doorgevoerd en u het hebt geselecteerd in een actie ongedaan maken, wordt het item uit de werkruimte verwijderd.
• Als het item gecommit is, kan het verwijderd worden als u overschakelt naar een andere vertakking en het item niet bestaat in de nieuwe vertakking.

De volgende overwegingen zijn belangrijk om rekening mee te houden:

• Beperkingen voor implementatieregels
• Ondersteunde gegevensbronnen voor gegevensstroom- en semantische modelregels
• Incrementeel vernieuwen
• Automatisering

U kunt één werkruimte toewijzen aan uw pijplijn en deze in de pijplijn implementeren of een andere werkruimte toewijzen aan elke pijplijnfase. Zie Een werkruimte toewijzen aan een implementatiepijplijn voor meer informatie.

Gegevenssets die de DirectQuery- of samengestelde connectiviteitsmodus gebruiken en variatie of automatische datum/tijd-tabellen hebben, worden niet ondersteund in implementatiepijplijnen. Als uw implementatie mislukt en u denkt dat dit komt doordat u een gegevensset met een variatietabel hebt, kunt u zoeken naar de eigenschap variaties in de kolommen van uw tabel. U kunt een van de volgende methoden gebruiken om uw semantische model te bewerken, zodat het werkt in implementatiepijplijnen.

• Gebruik in uw gegevensset, in plaats van de DirectQuery- of samengestelde modus, de importmodus .

• Verwijder de tabellen voor automatische datum/tijd uit uw semantische model. Verwijder indien nodig eventuele resterende variaties uit alle kolommen in uw tabellen. Als u een variatie verwijdert, kunnen door de gebruiker geschreven metingen, berekende kolommen en berekende tabellen ongeldig worden gemaakt. Gebruik deze methode alleen als u begrijpt hoe uw semantische modelmodel werkt, omdat dit kan leiden tot beschadiging van gegevens in uw visuals.

Wanneer u een tegel vastmaakt aan een dashboard, als de tegel afhankelijk is van een niet-ondersteund item (een item dat niet in deze lijst staat niet wordt ondersteund), of op een item waarvoor u geen machtigingen hebt om te implementeren, wordt de tegel niet weergegeven nadat het dashboard is geïmplementeerd. Als u bijvoorbeeld een tegel maakt op basis van een rapport dat afhankelijk is van een semantisch model waarvoor u geen beheerder bent, krijgt u bij het implementeren van het rapport een foutmelding. Wanneer u het dashboard echter implementeert met de tegel, treedt er geen foutbericht op, wordt de implementatie voltooid, maar wordt er geen informatie weergegeven op de tegel.

Voor een korte uitleg van de inzetplannen, zie het overzicht van het uitrolplan.

Het itemtype van het deployment plan-item verschijnt pas nadat een Fabric-beheerder de tenant-instelling heeft ingeschakeld. In het beheerportal, onder Tenantinstellingen>Microsoft Fabric, schakelt u Gebruikers kunnen items voor implementatieplannen (preview) maken in, stelt u Toepassen op in op de hele organisatie of een beveiligingsgroep, en selecteert u Toepassen.

Totdat deze instelling aan staat, blijft het itemtype verborgen in elke werkruimte.

De uitrol gaat terug naar het standaardgedrag. Items worden uitgezet zonder een aangegeven volgorde en zonder acties vóór of na de uitrol. Elke afhankelijkheid die door het plan werd beschermd, zoals een warehouseweergave die een lakehouse-tabel leest die door een notebook wordt gevuld, mislukt opnieuw.

Een correct geordend plan zet itemmetadata in de volgorde die je hebt opgegeven, maar het inzetten van een lakehouse voegt geen rijen in de tabellen in. Een warehouseweergave die een lakehouse-tabel uitleest, kan niet worden gekoppeld, tenzij een notebook of datapijplijn die tabel eerst heeft gemaakt. Voeg een post-deploy-actie toe tussen het lakehouse en het warehouse die de tabel produceert. Een actie meldt dat deze is voltooid wanneer de actie zelf eindigt, niet wanneer de services die ermee worden gevoed zijn bijgewerkt, dus plaats een controle of alles gereed is in de laatste cel van de notebook of in de laatste activiteit van de data-pipeline. Zie voorbeelden van implementatieplannen.

Het standaard lakehouse-veld van een notebook bevat ID's die wijzen op een specifiek lakehouse in een specifieke werkruimte. Nadat het notebook via Git in een nieuwe werkruimte is aangekomen, kunnen die ID's nog steeds naar de oorspronkelijke werkruimte verwijzen. Stel ofwel de standaard lakehouse in voor de doelomgeving in de notebookinstellingen vóór de run, of laat de notebook zijn lakehouse bij runtime oplossen. Zie Broncodebeheer en implementatie van Notebook voor meer informatie.

Uitvoer is zichtbaar vanuit de uitrol in het portaal. Actieruns koppelen terug naar de rungeschiedenis van het onderliggende item voor logs en stapdetails.

Een mislukte implementatie draait voltooide implementaties van items of wijzigingen die door acties zijn aangebracht niet terug. Voor herstelrichtlijnen, zie De implementatie is halverwege gestopt.

Niet rechtstreeks. Activeer Update vanuit Git via een externe scheduler zoals Azure-pipelines of GitHub Actions, en het bijgevoegde plan draait als onderdeel van die deployment.

Ja, als de pipeline de deployment aanstuurt via een Fabric API die het koppelen van een plan ondersteunt, zoals de Git sync API, dan deployen de deployment pipelines de API, of de batch import API. Een deployment die wordt uitgevoerd via de Fabric CLI, de Terraform-provider voor Fabric of de fabric-cicd Python-bibliotheek kan geen plan koppelen.

No. Een plan bepaalt de items in een inzet en de acties die eromheen plaatsvinden. Workspace-level configuratie maakt geen deel uit van een deployment, dus instellingen zoals de workspace-identiteit, Spark-instellingen en de Git-verbinding worden niet door een plan aangemaakt of bijgewerkt.

Configureer deze in de doelwerkruimte voordat je deze uitzet. Een item dat afhankelijk is van de configuratie op werkruimteniveau, zoals een notebook dat authenticeert via de werkruimte-identiteit, faalt tijdens runtime als de doelwerkruimte niet op dezelfde manier is geconfigureerd als de bron.

No. Een implementatieplan volgt het standaard Fabric-werkruimte-rolmodel. Voor meer informatie, zie inzetplanrechten.

De eigenaar van een geïmplementeerd gepagineerd rapport is de gebruiker die het rapport heeft geïmplementeerd. Wanneer u voor het eerst een gepagineerd rapport implementeert, wordt u de eigenaar van het rapport.

Als u een gepagineerd rapport implementeert in een fase die al een kopie van dat gepagineerde rapport bevat, overschrijft u het vorige rapport en wordt u de eigenaar ervan in plaats van de vorige eigenaar. In dergelijke gevallen hebt u referenties nodig voor de onderliggende gegevensbron, zodat de gegevens in het gepagineerde rapport kunnen worden gebruikt.

Gepagineerde rapportsubrapporten worden bewaard in dezelfde map waarin het gepagineerde rapport is opgeslagen. Als u selectief kopiëren gebruikt om een gepagineerd rapport met subrapporten te kopiëren, selecteert u zowel het bovenliggende rapport als de subrapporten om renderingproblemen te voorkomen.

Gepagineerde rapportregels kunnen worden gemaakt als u het gepagineerde rapport in dezelfde fase wilt laten verwijzen naar het semantische model. Wanneer u een implementatieregel voor een gepagineerd rapport maakt, moet u een database en een server selecteren.

Als u een implementatieregel instelt voor een gepagineerd rapport dat geen Fabric semantisch model heeft, omdat de doelgegevensbron extern is, moet u zowel de server als de database opgeven.

Gepagineerde rapporten die een Fabric semantisch model gebruiken, maken echter gebruik van een intern semantisch model. In dergelijke gevallen kunt u niet vertrouwen op de naam van de gegevensbron om het Fabric semantisch model te identificeren waarmee u verbinding maakt. De naam van de gegevensbron verandert niet wanneer u deze bijwerkt in de doelfase door een gegevensbronregel te maken of door de api voor de updategegevensbron aan te roepen. Wanneer u een implementatieregel instelt, moet u de databaseindeling behouden en de id van het semantische modelobject in het databaseveld vervangen. Omdat het semantische model intern is, blijft de server hetzelfde.

• Database - De databaseindeling voor een gepagineerd rapport met een Fabric semantisch model is sobe_wowvirtualserver-<dataset ID>. Bijvoorbeeld: sobe_wowvirtualserver-d51fd26e-9124-467f-919c-0c48a99a1d63. Vervang de <dataset ID> door de ID van uw gegevensset. U kunt de gegevensset-id ophalen uit de URL door de GUID te selecteren die na datasets/ en vóór de volgende slash komt.

  

• Server : de server die als host fungeert voor uw database. Behoud de bestaande server zoals deze is.

Als u na een implementatie de RDL van het gepagineerde rapport downloadt, wordt deze mogelijk niet bijgewerkt met de nieuwste versie die u in Power BI-service kunt zien.

Wanneer u een gegevensstroom hebt die semantische modellen bevat die zijn geconfigureerd met incrementeel vernieuwen, wordt het vernieuwingsbeleid niet gekopieerd of overschreven tijdens de implementatie. Nadat u een gegevensstroom met een semantisch model met incrementeel vernieuwen hebt geïmplementeerd in een fase die deze gegevensstroom niet bevat, moet u deze opnieuw configureren in de doelfase als u een vernieuwingsbeleid hebt. Als u een gegevensstroom met incrementeel vernieuwen implementeert in een fase waarin deze zich al bevindt, wordt het beleid voor incrementeel vernieuwen niet gekopieerd. Als u in dergelijke gevallen het vernieuwingsbeleid in de doelfase wilt bijwerken, moet u dit handmatig doen.

Gerelateerde inhoud

• Aan de slag met Git-integratie
• Aan de slag met implementatiepijplijnen