Del via

Planlegging av Power BI-implementering: Planlegge og utforme innhold

Notat

Denne artikkelen er en del av planleggingsserien for power BI-implementering av artikler. Serien fokuserer på å planlegge å implementere en Power BI-opplevelse i Microsoft Fabric. Se serieintroduksjonen.

Denne artikkelen hjelper deg med å planlegge og utforme innhold som en del av administrasjonen av innholdslivssyklusen. Det er primært rettet mot:

  • Center of Excellence (COE) og BI-team: Teamene som er ansvarlige for å overvåke Power BI i organisasjonen. Disse teamene inkluderer beslutningstakere som bestemmer hvordan de skal administrere livssyklusen til Power BI-innhold.
  • innholdsopprettere og innholdseiere: Brukere som oppretter innhold som de vil publisere til Fabric-portalen for å dele med andre. Disse personene er ansvarlige for å administrere livssyklusen til Power BI-innholdet de oppretter.

Livssyklusbehandling består av prosessene og praksisene du bruker til å håndtere innhold fra opprettingen til eventuell pensjonering. Som beskrevet i den første artikkelen i denne serien, er administrasjon av livssyklusen for Power BI-innhold viktig for å sikre pålitelig og konsekvent levering av innhold til forretningsbrukere.

Den første fasen av innholdslivssyklusen er å planlegge og utforme innhold. Du starter vanligvis innholdslivssyklusen ved å utføre BI-løsningsplanlegging. Du samle krav for å forstå og definere problemet løsningen skal løse, og komme frem til en løsningsutforming. I løpet av denne planleggings- og utformingsfasen tar du viktige beslutninger for å forberede deg til de senere fasene.

Bildet nedenfor viser livssyklusen til Power BI-innhold, utheving av trinn én, der du planlegger og utformer innhold.

diagram viser livssyklusen til Power BI-innhold. Trinn 1, som handler om innholdsplanlegging og utforming, er uthevet.

Notat

Hvis du vil ha en oversikt over behandling av innholdslivssyklus, kan du se den første artikkelen i denne serien.

Tips

Denne artikkelen fokuserer på viktige hensyn og beslutninger for innholdsplanlegging og utforming når de gjelder livssyklusadministrasjon.

  • Hvis du vil ha mer informasjon om hvordan du effektivt planlegger og utformer en Fabric- eller Power BI-løsning, anbefaler vi at du leser løsningsplanlegging artikkelen.
  • Hvis du vil ha mer informasjon om hvordan du effektivt planlegge en Power BI-overføring, anbefaler vi at du leser Power BI--serien.

Når du samler inn krav, bør du tydelig beskrive aspekter ved innholdet som påvirker din tilnærming til livssyklusbehandling. Du bør dokumentere disse aspektene som en del av løsningsplanleggingen og utformingen.

De følgende avsnittene i denne artikkelen beskriver de viktigste aspektene og vurderingene ved en løsning som motiverer din tilnærming til livssyklusbehandling etter hvert som du planlegger og utformer innholdet.

Identifisere og beskrive innholdet

Når du utformer løsningen, bør du beskrive hva innholdet er, hvem som skal opprette den, hvem som støtter den, og hvor kritisk dette innholdet er for organisasjonen. Du bør ta tak i disse faktorene under, eller etter at du er ferdig, samlekrav som en del av løsningsutformingen.

Notat

I likhet med kravene dine kan svarene på disse spørsmålene endres etter hvert som du utvikler løsningen, eller senere i livssyklusen. Når du har svart på disse spørsmålene, må du være forberedt på å evaluere dem regelmessig når du gjør endringer i innhold, eller når det skaleres i antall brukere det betjener.

Svar på følgende spørsmål om innholdet for å hjelpe deg med å ta beslutninger om livssyklusadministrasjon senere.

Hva er formatet på innholdet?

Innholdstypen, omfanget og kompleksiteten i innholdet motiverer viktige beslutninger om hvordan du skal administrere det. En enkelt rapport for en begrenset målgruppe krever for eksempel en annen tilnærming til livssyklusbehandling sammenlignet med en semantisk modell som skal brukes av hele organisasjonen og av flere forskjellige nedstrøms arbeidsbelastninger.

Svar på spørsmål som følgende for å hjelpe deg med å finne ut hvilken type innhold du skal opprette.

  • Hvilke elementtyper forventer du å opprette, og hvor mange av hver? Vil du for eksempel opprette dataelementer som dataflyter eller semantiske modeller, rapportere elementer som rapporter eller instrumentbord eller en kombinasjon av begge?
  • Hvordan leveres innholdet til innholdsforbrukere? Vil for eksempel forbrukere bruke dataelementer til å bygge sitt eget innhold, vil de bare vise sentraliserte rapporter eller en kombinasjon av begge?
  • Hvor komplekst er innholdet? Er det for eksempel en liten prototype, eller en stor semantisk modell som omfatter flere forretningsprosesser?
  • Forventer du at innholdets skala, omfang og kompleksitet vil vokse over tid? Vil for eksempel innholdet omfatte andre områder eller forretningsområder i fremtiden?
  • Hvor lenge forventer du at bedriften trenger dette innholdet? Vil for eksempel dette innholdet støtte et viktig initiativ for virksomheten som har en begrenset tidslinje?

Tips

Vurder å lage et arkitektonisk diagram for å beskrive formatet på innholdet. Du kan inkludere ulike datakilder, elementtyper og innholdsforbrukere, og relasjonene mellom disse diskrete komponentene. Et arkitektonisk diagram kan bidra til å vise innholdet og kompleksiteten konsist, og det hjelper deg med å planlegge livssyklusbehandlingen. Du kan bruke ikonene Fabric og Azure-ikoner til å opprette disse diagrammene i ekstern programvare. Alternativt kan du bruke Azure Diagrams, som leveres med ikoner og tegneverktøy for å lage disse diagrammene.

Hvis du vil ha et eksempel på slike diagrammer, kan du se Power BI-implementeringsplanleggingen bruksscenariodiagrammer.

Hvem vil opprette og støtte innholdet?

Innholdsopprettere har ulike behov, ferdigheter og arbeidsflyter. Disse faktorene vil påvirke suksessen til ulike tilnærminger for livssyklusadministrasjon. Større, sentrale team med samarbeid krever ofte mer avansert livssyklusadministrasjon av innhold enn mindre team av selvbetjente opprettere.

Svar på spørsmål som følgende for å hjelpe deg med å finne ut hvem som skal opprette eller støtte innholdet.

  • Hvor mange forskjellige personer forventer du å opprette dette innholdet? Vil flere innholdsopprettere samarbeide, eller er én enkelt person ansvarlig for å opprette innholdet?
  • Er innholdsopprettere kjent med livssyklusbehandling og relaterte konsepter, for eksempel versjonskontroll? Forstår innholdsopprettere fordelene ved livssyklusbehandling?
  • Vil innholdsoppretterne som utvikler løsningen, være de samme personene som støtter den etter distribusjon?
  • Har innholdsopprettere eller team eksisterende fremgangsmåter for livssyklusadministrasjon på plass for å støtte eksisterende løsninger?
  • Bruker innholdsopprettere for øyeblikket administrasjonsverktøy for livssyklus, for eksempel Azure DevOps?

Viktig

Sørg for at du tydelig dokumenterer hvem som er ansvarlig for å opprette innhold, og hvem som støtter det når det er distribuert til produksjon. Involver alle disse personene i planleggingen av innholdslivssyklusbehandling.

Hva er viktigheten av innholdet?

Avhengig av hvor viktig innholdet er for bedriften, vil du ta forskjellige avgjørelser om hvordan du administrerer det. Forretningskritisk innhold krever mer robuste fremgangsmåter for behandling av innholdslivssyklus for å sikre kvalitet og redusere mulige forstyrrelser.

Svar på spørsmål som følgende for å hjelpe deg med å finne ut om innholdet er kritisk.

  • Hvor kritisk er dette innholdet for virksomheten? Hvor presserende er forespørselen om å utvikle den?
  • Vil forretningskritiske beslutninger eller handlinger bli gjort fra informasjon fra dette innholdet?
  • Hvor bredt forventer du å distribuere dette innholdet (fra hele organisasjonen til et begrenset lokalt team)?
  • Vil ledere eller andre strategiske beslutningstakere stole på dette innholdet for sitt arbeid?
  • Hva er virkningen av dette innholdet? Hvis for eksempel innholdet plutselig ikke er tilgjengelig, hvilke forretningsmessige konsekvenser vil skje, for eksempel tapt omsetning eller avbrutte forretningsprosesser?

Når du har identifisert og beskrevet innholdet du skal opprette, bør du bestemme hvordan innholdsopprettere skal samarbeide.

Finne ut hvordan brukere skal bruke innholdet

I Power BI finnes det mange forskjellige måter brukere kan bruke innhold på, inkludert semantiske modeller og rapporter. Avhengig av hvordan personer får tilgang til og bruker dette innholdet, må du ta forskjellige avgjørelser om utformingen og hvordan du skal utvikle det. Noen av disse beslutningene kan drastisk endre både hvordan du lager innholdet og hvor mye tid og krefter det tar. Vanligvis, jo mer forskjellige måter folk vil bruke dine modeller og rapporter, jo flere hensyn du har i tankene, og jo høyere resultatutviklingskostnader.

Bruk og gjenbruk av semantiske modeller

Semantiske modeller er uten tvil de viktigste elementtypene i Power BI og Fabric, siden brukere kan bruke dem ved hjelp av mange forskjellige nedstrøms tilnærminger og elementer. Hvis du bare vil distribuere rapporter, vil du ta svært forskjellige utformingsbeslutninger som når brukere vil koble ulike elementer til modellen for å gjøre sine egne analyser eller oppnå sine egne mål.

diagram viser en semantisk modell og elementene som kan kobles til den i Power BI, Fabric og andre verktøy.

Du kan bruke en delt semantisk modell på nytt ved hjelp av følgende nedstrøms elementtyper:

Avsnittene nedenfor gir en oversikt over viktige hensyn når du bruker semantiske modeller med noen av disse elementene.

Notat

Mange av disse alternativene er bare tilgjengelige hvis du aktiverer de relevante leierinnstillingene. Sørg for at du gjør deg kjent med leierinnstillingene for å vite hvilke forbruksmetoder som er mulig i arbeidsområdet der du publiserer den semantiske modellen. Hvis disse alternativene er begrenset til bestemte sikkerhetsgrupper, må du sørge for at du identifiserer om brukerne tilhører (eller skal tilhøre) disse sikkerhetsgruppene, eller ikke.

Rapporter

Det finnes flere ulike måter brukere kan kommunisere med semantiske modeller på via rapporter:

  • Vise rapporter. Standardscenarioet der en bruker viser data i en rapport som du distribuerer eller deler med dem.
  • Koble til den semantiske modellen og opprette en ny rapport. Med byggetillatelserkan brukere opprette en ny rapport i Power BI Desktop eller i Power BI-tjenesten. Denne rapporten har en live-tilkobling til den delte semantiske modellen. Brukere kan også konvertere den direkte tilkoblede rapporten til en ny sammensatt semantisk modell som spør originalen ved hjelp av DirectQuery.
  • Oppretter en utforskning fra et eksisterende visualobjekt for rapporter. Med byggetillatelser kan brukere også velge et støttet visualobjekt for å opprette en utforskning av dataene. Dette oppretter et nytt utforskningselement som gjør det mulig for brukeren å legge til felt eller endre formatering. Brukere kan lagre og dele den resulterende utforskningen hvis de oppfyller de nødvendige kriteriene for lisensiering, arbeidsområdemedlemskap og elementtillatelser.
  • tilpasse rapportvisualobjekter, der brukere kan endre felt og formatering.Tilpasse visualobjekter fungerer på samme måte som en utforskning, men det krever bare lesetillatelser, og oppretter ikke et nytt element. Tilpass visualobjekter bruker også alle perspektiver som en bruker bruker på en rapportside, noe som begrenser de tilgjengelige feltene som en bruker kan se og bruke.

Disse ulike scenarioene oppretter en rekke hensyn som du må huske på for semantiske modeller, for eksempel:

  • Hvilke tillatelser du vil gi til brukere, og hvordan du skal administrere disse tillatelsene. Vi anbefaler at brukere fullfører en opplæring før de får byggetillatelser.
  • Enten du legger til perspektiver i modellen eller ikke. Du kan bare legge til perspektiver ved hjelp av TMDL-visning i Power BI Desktopeller ved hjelp av andre tredjepartsverktøy. Vi anbefaler at du legger til perspektiver når brukere skal bruke tilpassede visualobjekter eller sammensatte modeller.
  • Hvilke felt du bør skjule i modellen, og om du må aktivere IsPrivate- TOM-egenskapen for tabeller for å unngå at de eller de underordnede objektene vises som forslag. Vær oppmerksom på at private TOM-egenskapen bare kan angis ved hjelp av eksterne verktøy på en modellmetadatafil (for eksempel BIM eller TMDL) eller en ekstern modell som er publisert i Power BI-tjenesten.
  • Hvordan du dokumenterer modellen, og hva denne dokumentasjonen skal medføre. Vi anbefaler at du lager dokumentasjon som er skreddersydd for bestemte brukstilfeller, og at du inkluderer relevant og nyttig informasjon, og ikke eksporterer modellmetadata som DAX-måluttrykk, som vanligvis ikke er nyttige for sluttbrukere.
  • Slik råder du brukere til å velge én tilnærming fremfor en annen.

Forsiktighet

Når du gir lese- eller byggtillatelser til en semantisk modell, kan det hende at brukerne kan spørre etter en tabell eller kolonne i modellen ved hjelp av fremgangsmåtene som er beskrevet i denne delen. Dette gjelder selv om du ikke viser tabellen, målet eller kolonnen i en rapport. Kontroller at du alltid beskytter sensitive data ved hjelp av datasikkerhet, eller utelat dem fra modellen. På den måten kan du unngå utilsiktet å utsette sensitiv informasjon for feil personer.

Excel (analysere i Excel-pivottabeller)

Hvis brukere har byggetillatelser til en modell, kan de også koble til en semantisk modell fra Excel og spørre den ved hjelp av MDX fra en Excel-pivottabell. Dette kan være nyttig når brukere foretrekker å arbeide i Excel for å utforske eller analysere data selv.

Når du bruker analyser i Excel til å spørre etter den semantiske modellen, må du vurdere følgende:

  • Enkelte funksjoner som feltparametere eller måle dynamiske formatstrenger fungerer bare i Power BI, og ikke i Excel. Hvis du vil oppnå et lignende resultat, må du bruke andre tilnærminger.
  • Analyser i Excel krever at kolonneegenskapen IsAvailableinMDX er aktivert. Hvis brukere ikke bruker Excel, kan deaktivering av denne egenskapen føre til mindre og mer ytelsesfulle modeller.
  • Brukere kan ikke vise skjulte kolonner eller mål i den semantiske modellen, slik de kan fra Power BI Desktop (ved å høyreklikke på dataruten og velge «vis skjult»).
  • Brukere kan ikke opprette sine egne mål eller visuelle beregninger i Excel, slik de kan når de bruker en live-tilkobling fra Power BI Desktop. De kan imidlertid referere til pivottabellfeltene i andre Excel-celler og regneark for egendefinerte beregninger.
  • Brukere av analyser i Excel krever ofte ekstra opplæring om hvordan du bruker det. Dette gjelder spesielt hvis de forventer en eksportlignende opplevelse, eller de uttrykker en hensikt om å lagre frakoblede kopier av dataene. Vurder å lære opp brukere om ting som:
    • Slik oppdaterer du dataene.
    • Filtrer dataene før legge til felt i pivottabellen.
    • Unngå store og detaljerte spørringer uten filtre.
    • Power BI Desktop vil være mer utførlig enn Analyser i Excel, fordi analyser i Excel spør modellen ved hjelp av MDX, men Power BI Desktop spør modellen med DAX.
    • Slik unngår du å opprette styrings- eller sikkerhetsrisikoer samtidig som du utnytter Excel slik de foretrekker.

Copilot- og AI-ferdigheter

Hvis brukere har lesetillatelser til en modell, kan du bruke naturlig språk til å utforske og stille spørsmål om dataene ved hjelp av Copilot. Alternativt kan de også stille dataspørsmål om dataene sine i en AI-ferdighet, men i motsetning til Copilot må du først opprette og dele dette elementet med dem.

Når brukere ønsker å samhandle med semantisk modell ved hjelp av naturlig språk, er det betydelige konsekvenser for utformingen og implementeringen av modellen:

  • lingvistisk skjema: Du må legge til synonymer og relasjoner i modellen, slik at de riktige engelske ordene og termene er knyttet til de riktige modellobjektene.
  • Navnekonvensjoner: Du må bruke AI-vennlige, engelske navnekonvensjoner. Dette betyr at du bør unngå dupliserte eller altfor lignende feltnavn, akronymer, symboler og forkortelser, selv om de er standard i organisasjonen.
  • Egenskaper: Du må angi egenskaper som kolonne- eller målbeskrivelser, datakategorier og andre, slik at AI-verktøy bedre kan gjenkjenne og bruke disse feltene.
  • Skjule felt: Du må skjule felt som du ikke vil vise til Copilot eller bruke i svarene.

Du må også bruke ekstra innsats på opplæring av brukere:

  • Hva Copilot eller AI ferdigheter kan og ikke kan gjøre.
  • Når du skal bruke Copilot- eller AI-ferdigheter til å utforske data over en annen (ikke-AI)-tilnærming.
  • Slik skriver du effektive ledetekster.
  • Slik validerer du utdata.
  • Slik feilsøker du uventede utdata.

Tips

Se følgende artikler for flere, detaljerte tips og vurderinger om optimalisering av modeller for å fungere bra med Copilot:

Copilot og annen generativ AI-teknologi har viktige begrensninger og vurderinger som du også bør forstå i planleggings- og utformingsfasen av innholdet:

  • Det er ikke-deterministisk, noe som betyr at de samme inndataene i samme kontekst kan gi en annen utdata.
  • Du kan få lav kvalitet eller unøyaktige utganger, for eksempel når verktøyet hallusinerer, eller overstyrer viktigheten av visse fakta. Copilot kan også være feil eller unøyaktig ved utelatelse, der den utelater viktig informasjon.
  • Verktøyene er begrenset av deres opplæringsdata, så spørsmål om mer ny informasjon er mindre sannsynlig å produsere nyttige utganger.

Forsiktighet

Du bør redusere risikoen for disse begrensningene og vurderingene. Copilot, AI-ferdigheter, LLM-er og generativ AI er gryende teknologi, så du bør ikke bruke dem til autonome, høyrisiko- eller forretningskritiske prosesser og beslutninger. Hvis du vil ha mer informasjon, kan du også se Sikkerhetsveiledning for store språkmodeller.

Paginerte rapporter

Du kan skrive en DAX-spørring for en semantisk modell for å opprette en paginert rapport med spørringsresultatet. Dette er relevant hvis brukere krever paginerte rapporter, og du har tenkt å bruke den semantiske modellen som datakilde.

Når du planlegger å opprette paginerte rapporter på en semantisk modell, må du kanskje vurdere følgende punkter:

  • Hvordan du skriver og vedlikeholder DAX-spørringene, for eksempel ved hjelp av DAX-spørringsvisningen i Power BI Desktop eller andre tredjepartsverktøy.
  • Om du må ta utformingsbeslutninger for å sikre at den semantiske modellen er performant når du blir spurt, for eksempel materialisering av bestemte data i en modellkolonne eller tabell.
  • Om du skal bygge inn paginerte rapporter i interaktive Power BI-rapporter eller ikke ved hjelp av paginerte rapportvisualobjektet.
  • Slik sikrer du at det ikke er redundans mellom paginerte rapporter og andre rapporter.
  • I hvilket format du bør distribuere paginerte rapporter, og om du krever følsomhetsetiketter eller hindring av datatap for å beskytte disse utdataene fra å bli en styrings- eller sikkerhetsrisiko.

Andre

Det finnes også andre måter å bruke semantiske modeller på. Noen eksempler er nedenfor:

  • Activator (tidligere Refleks): Du kan bruke en semantisk modell til å automatisere datavarsler og utløse nedstrømsflyter, for eksempel de du oppretter ved hjelp av Power Automate.
  • metriske sett: Du kan opprette et metrisk sett, som inkluderer mål og anbefalte dimensjoner fra flere semantiske modeller på ett sted. Metriske sett kan forbedre dataoppdagelse for brukere.
  • Explorations: Bortsett fra å opprette utforskninger fra rapporter og Copilot-utganger, kan brukerne også opprette utforskninger fra en semantisk modell.

Distribusjon og deling av rapporter

Avhengig av hvordan du vil distribuere og dele Power BI-rapportene dine, gjør du forskjellige utformingsvalg. Ekstrahering over flere rapporter er for eksempel en funksjon som lar brukere navigere mellom rapporter i samme arbeidsområde eller app. Du kan imidlertid ikke bruke ekstrahering over flere rapporter hvis du bygger inn en rapport eller deler den offentlig via Publiser på nettet.

Andre elementer

Avhengig av hvordan personer bruker innholdet og de underliggende dataene, må du kanskje henvende deg til andre elementtyper i Power BI eller Fabric. Hvis brukere for eksempel vil legge til sine egne data og beregninger, kan de bruke sammensatte modeller med semantisk modell. Alternativt kan du gjøre andre sentraliserte dataelementer slik at de kan bruke i nye modeller, for eksempel en dataflyt.

Når du har bestemt hvordan brukere skal bruke innholdet du lager, bør du bestemme hvordan innholdsopprettere skal samarbeide under utvikling.

Bestem hvordan innholdsopprettere skal samarbeide

Etter hvert som en løsning øker i omfang og kompleksitet, kan det bli nødvendig for flere innholdsopprettere og eiere å arbeide i samarbeid. Når du oppretter komplekse løsninger, anbefaler vi at du bruker effektive verktøy som bidrar til å strukturere, administrere og støtte samarbeid. Det finnes mange måter å samarbeide på når du produserer Power BI-innhold, for eksempel ved hjelp av Microsoft Teams, Azure DevOps eller GitHub.

Tips

Selv når innholdsopprettere arbeider uavhengig, kan de fortsatt dra nytte av planlegging og strukturering av arbeidet sitt ved hjelp av verktøy som Microsoft Teams, Azure DevOps eller GitHub. Dette er spesielt viktig når du planlegger hvordan du distribuerer innhold, for eksempel ved hjelp av OneDrive Refresh fra et Dokumentbibliotek i Microsoft Teams eller Git-integrering fra en Azure DevOps- eller GitHub-repositorium.

Microsoft Teams

For mindre eller enklere prosjekter kan innholdsopprettere samarbeide ved hjelp av Microsoft Teams.

diagram viser tilnærming 1, som handler om å samarbeide ved hjelp av Microsoft Teams. Elementer som vises i diagrammet, beskrives neste.

Ved hjelp av Microsoft Teams strukturerer innholdsopprettere kommunikasjonen, planleggingen og arbeidet i team og kanaler. Microsoft Teams er ofte et godt valg for enklere samarbeidsscenarioer. Desentraliserte team som produserer innhold for en begrenset målgruppe, kan for eksempel bruke dokumentbiblioteker til lagring av filer og versjonskontroll. De kan også benytte seg av andre integrerte verktøy og tjenester.

Tips

Vi anbefaler at du bruker Microsoft Teams til å legge til rette for effektiv administrasjon av innholdslivssyklus i selvbetjente scenarioer med desentralisert innholdslevering.

Hvis du vil samarbeide og kommunisere i Microsoft Teams, bruker du støttetjenester gjennom hele livssyklusen til Power BI-innholdet.

  • Planner: Innholdseiere kan bruke Planner til å opprette planer, som de bruker til å spore oppgaver og omfangsinnhold. Oppgaver kan beskrive problemer, feil eller funksjoner i løsningen og tilsvarende interessenter.
  • SharePoint-: Innholdsopprettere kan lagre og behandle filer i et Microsoft Teams-dokumentbibliotek eller tilkoblet område for hver kanal. Innholdsfiler som er lagret i SharePoint, kan bruke versjonskontroll til å spore og behandle innholdsendringer. Hvis du vil ha mer informasjon om sporing og administrasjon av endringer ved hjelp av SharePoint, kan du se trinn 2: Utvikle innhold og behandle endringer.
  • Godkjenninger: Innholdsopprettere og eiere kan konfigurere og bruke arbeidsflyter til å godkjenne innholdsendringer eller utgivelser etter gjennomgang.
  • Fabric og Power BI: Innholdsopprettere og eiere kan få tilgang til Fabric-portalen fra Microsoft Teams. Derfra kan de administrere eller diskutere innhold og legge til nyttige rapporter i faner i Teams-kanaler.
  • Andre integreringer: Innholdsopprettere kan benytte seg av andre Microsoft- eller tredjepartstjenester som integreres med Microsoft Teams, slik at de passer best til deres foretrukne arbeidsflyt og behov.

Vi anbefaler at du definerer en strukturert prosess for hvordan innholdsopprettere skal bruke Microsoft Teams til å samarbeide. Kontroller at du bestemmer:

  • Slik administrerer du tilgang til team og kanaler.
  • Hvem som er ansvarlig for å administrere team og kanaler.
  • Hvordan arbeid er begrenset og organisert i distinkte team, kanaler og planer.
  • Slik bør innholdsopprettere bruke et dokumentbibliotek til å organisere filer og spore og behandle endringer. For eksempel hvordan du organiserer dokumentbiblioteket og om innholdsopprettere skal sjekke inn og sjekke ut filer.
  • Om innholdsopprettere skal bruke OneDrive Refresh til automatisk å publisere Power BI Desktop-filer (PBIX).
  • Slik løses filsynkroniseringskonflikter.
  • Når du skal arkivere og fjerne filer fra et dokumentbibliotek som ikke lenger er relevant.

Azure DevOps eller GitHub Enterprise

Innholdsopprettere og eiere kan også kommunisere og samarbeide i en sentral, organisert hub ved hjelp av Azure DevOps eller GitHub Enterprise.

diagram viser tilnærming 2, som handler om å samarbeide ved hjelp av Azure DevOps. Elementer som vises i diagrammet, beskrives neste.

Notat

Azure DevOps er en pakke med tjenester som integreres med Power BI og Fabric for å hjelpe deg med å planlegge og organisere administrasjon av innholdslivssyklus. Når du bruker Azure DevOps på denne måten, bruker du vanligvis følgende tjenester:

  • Azure Repos: Lar deg opprette og bruke et eksternt Git-repositorium, som er en ekstern lagringsplassering du bruker til å spore og behandle innholdsendringer.
  • Azure Pipelines: Lar deg opprette og bruke et sett med automatiserte oppgaver til å håndtere, teste og distribuere innhold fra et eksternt repositorium til et arbeidsområde.
  • Azure Test Plans: Lar deg utforme tester for å validere løsningen og automatisere kvalitetskontrollen sammen med Azure Pipelines.
  • Azure Boards: Lar deg bruke tavler til å spore oppgaver og planer som arbeidselementer, og koble eller referere til arbeidselementer fra andre Azure DevOps-tjenester.
  • Azure Wiki: Lar deg dele informasjon med teamet for å forstå og bidra til innhold.

Ved hjelp av Azure DevOps eller GitHub Enterprise bruker innholdsopprettere prosjekter til å strukturere kommunikasjon, planlegging og arbeid. I tillegg kan innholdsopprettere organisere behandling av innholdslivssyklus fra Azure DevOps ved å utføre kildekontroll, validering og distribusjon. Kildekontroll er prosessen med å administrere mer detaljerte endringer i innholdskode og metadata.

Azure DevOps er ofte et godt valg for mer avanserte samarbeidsscenarioer, fordi det finnes støttetjenester og alternativer for å organisere oppretting og distribusjon av innhold.

Tips

Vi anbefaler at du bruker Azure DevOps til å hjelpe deg med effektiv administrasjon av innholdslivssyklus i bedriftsscenarioer med sentralisert innholdslevering. Samarbeid ved hjelp av Azure DevOps eller lignende verktøy foretrekkes i større eller mer komplekse scenarioer over samarbeid ved hjelp av Microsoft Teams eller SharePoint. Det er fordi det finnes flere verktøy og alternativer som er tilgjengelige for å legge til rette for mer robust samarbeid og automatisering.

Vi anbefaler at du definerer en strukturert prosess for hvordan innholdsopprettere skal bruke Azure DevOps til å samarbeide. Kontroller at du bestemmer:

  • Hvordan arbeid er omfangsområder og hvordan innholdsgrener opprettes, navngis og brukes.
  • Hvordan forfattere grupperer og utfører endringer og beskriver dem med utføringsmeldinger.
  • Hvem som er ansvarlig for å gjennomgå og godkjenne endringer ved hjelp av pull-forespørsler.
  • Hvordan du henter forespørsler om flettekonflikter, løses og hvem som løser dem.
  • Hvordan endringer i ulike grener skal slås sammen til én enkelt gren.
  • Hvordan innhold testes og hvem som utfører testing før innhold distribueres.
  • Hvordan og når endringer distribueres til utviklings-, test- og produksjonsarbeidsområder.
  • Hvordan og når distribuerte endringer eller versjoner av løsningen kan rulles tilbake.

GitHub

Innholdsopprettere og eiere kan også kommunisere og samarbeide ved hjelp av GitHub- (bare skyversjoner) og GitHub Enterprise-. I likhet med Azure DevOps tilbyr GitHub en plattform med tjenester som du kan bruke til å organisere og administrere aspekter av Power BI- eller Fabric-miljøet.

Hovedforskjellen mellom Azure DevOps og GitHub er at selv om Azure DevOps tilbyr en rekke verktøy for administrasjon av livssyklusen for programvareutvikling, fokuserer GitHub hovedsakelig på å være vert for Git-repositorier, kildekontroll og samarbeid om kode. Du bruker hovedsakelig GitHub når du planlegger å distribuere innhold ved hjelp av Git-integrering. I tillegg kan du bruke GitHub til å synkronisere innhold fra et offentlig, åpen kildekode-repositorium til et arbeidsområde.

Hvis du vil bruke Git-integrering med GitHub, må du aktivere administratorleierens innstilling Brukere kan synkronisere arbeidsområdeelementer med GitHub-repositorier.

Notat

Du kan også bruke Microsoft Teams sammen med Azure DevOps eller GitHub fordi det finnes ulike måter å integrere disse tjenestene på. Du kan for eksempel vise og administrere Azure Boards og overvåke hendelser i Azure Pipelines fra Microsoft Teams.

Her kan du også samarbeide og planlegge innhold ved hjelp av andre verktøy som ikke er nevnt. Det viktigste er at du bruker verktøy og tjenester som tilrettelegger for samarbeid for deg, og som passer best til teamets behov og måten de fungerer på.

Når du har bestemt deg for om og hvordan innholdsopprettere skal samarbeide, bør du bestemme hvor du skal lagre filene dine. Mange av disse filene lagres der du velger å samarbeide.

Bestem hvor filer skal lagres

Når du oppretter innhold, produserer du vanligvis ulike filtyper. Det er viktig å bestemme hvor disse filene skal lagres, slik at du effektivt kan administrere dem.

Tips

Lagre filer der de kan åpnes av flere gruppemedlemmer, og der endringer enkelt kan spores (kjent som versjonskontroll). Denne fremgangsmåten sikrer at avgang av et gruppemedlem eller tap av en fil ikke fører til forstyrrelser.

Filtypene du må lagre, inkluderer ofte:

  • innholdsfiler: Filer som inneholder innholdsdataene eller metadataene. Innholdsfiler med data som PBIX- og Power BI Project-filer (PBIP) inneholder sensitiv informasjon. Lagre innholdsfiler på et sikkert sted som bare er tilgjengelig for dem som trenger tilgang til dem. Du bør også lagre innholdsfiler på en plassering som støtter versjonskontroll, for eksempel et dokumentbibliotek i Microsoft Teams eller et Git-repositorium i Azure DevOps. Eksempler på innholdsfiler inkluderer:
    • Power BI Desktop-filer (PBIX)
    • Power BI Project-filer (PBIP)
    • Paginerte rapportfiler i Power BI (RDL)
    • Modellmetadatafiler (.bim eller .tmdl)
    • Dataflytmetadatafiler (.json)
  • datakildefiler: Filer som forbrukes av dataelementer som semantiske modeller eller dataflyter. Innhold er direkte avhengig av datakildefiler, så det er viktig å vurdere nøye hvor de er lagret, fordi fjerning av dem vil føre til feil ved dataoppdatering. I tillegg kan disse filene inneholde sensitiv informasjon. Så lagre datakildefiler i et sikkert, pålitelig og pålitelig miljø som har begrenset tilgang av andre personer. Eksempler på datakildefiler kan omfatte:
    • Strukturerte datakilder, for eksempel Excel-arbeidsbøker, Parquet- eller CSV-filer.
    • Halvstrukturerte datakilder, for eksempel JSON- eller XML-filer.
    • Ustrukturerte datakilder, for eksempel bilder som du importerer til rapporter.
  • støttefiler: Filer som støtter oppretting eller administrasjon av innhold, men som ikke kreves for at det skal fungere. Støttefiler bør lagres på en plassering som støtter versjonskontroll, og der andre verktøy og innholdsopprettere kan få tilgang til dem. Eksempler på støttefiler kan omfatte:
    • Power BI-temafiler (.json).
    • Bildefiler (.png, .jpgeller .gif) i Power BI-rapporter.
    • Regler for anbefalte fremgangsmåter (.json) filer.
    • Kildekodefiler for innhold og spørringer.
    • Egendefinerte visualiseringsfiler (PBIVIZ).
  • Maler og dokumentasjon: Filer som hjelper deg med å opprette selvbetjent innhold eller beskrive eksisterende innhold. Maler og dokumentasjon skal være lett tilgjengelig for personer som trenger å bruke dem. Eksempler på maler og dokumentasjon kan omfatte:
    • Power BI-malfiler (PBIT).
    • Visualiseringsmaler og eksempelrapporter.
    • Løsningsutforminger og dokumentasjon.
    • Løsningsplanlegging og veikart.
    • Brukerforespørsler og løsningsproblemer.

Forsiktighet

Enkelte innholdsfiler som PBIX- og PBIP-filer kan inneholde sensitive data som er importert fra datakilder. I tillegg kan metadatafiler også inneholde sensitiv informasjon, eller i noen tilfeller datapunkter. Et eksempel på dette er rapportmetadata og PBIT-maler, som kan inneholde kolonneverdier under visse omstendigheter. Sørg for at du tar de nødvendige forholdsregler for å lagre disse filene på sikre plasseringer, og at du praktiserer effektiv hindring av datatap.

Du har ulike alternativer for lagring av filer. Kontroller at du velger riktig plassering, avhengig av filtype, innhold og hvordan den skal brukes.

SharePoint Online eller OneDrive

En vanlig løsning for lagring av filer er å bruke SharePoint- nettsteder. SharePoint er allment tilgjengelig for de fleste brukere og er svært integrert med både Power BI og andre Microsoft 365-programmer, for eksempel Microsoft Teams. I tillegg har den innebygde versjonskontroll, noe som gjør det praktisk å lagre de fleste filtyper. Med versjonskontroll kan du vise og administrere ulike lagrede versjoner av en fil.

Når du lagrer filer i SharePoint, bør du vurdere følgende punkter.

  • organization: Sørg for at du opprettholder en konsekvent og logisk struktur, slik at det er enkelt å finne bestemte filer. Bruk gode navnekonvensjoner, organiser filer i mapper og arkivfiler som ikke lenger er relevante for pågående prosjekter.
  • OneDrive-oppdatering: Du kan koble en publisert semantisk modell eller rapport til en PBIX-fil som er lagret på et SharePoint- eller OneDrive for jobb- eller skolenettsted. Med denne fremgangsmåten trenger du ikke lenger å publisere den semantiske modellen for å få endringer i kraft. I stedet er endringene synlige etter en automatisk OneDrive-oppdatering, som skjer hver time. Selv om det er praktisk, vær oppmerksom på at denne tilnærmingen kommer med noen advarsler og utfordringer. Når ting går, kan det ikke lett reverseres.
  • forhåndsvisningsrapporter: I SharePoint er det mulig å vise Power BI-rapporter uten å måtte installere Power BI Desktop eller laste ned PBIX-filen lokalt. Når du åpner rapporter på denne måten, vises de i nettleseren. Denne funksjonen kan være et praktisk alternativ til å vise rapporter fra Fabric-portalen. Det er aktivert som standard i Fabric-leierinnstillingene.

Tips

Når du samarbeider ved hjelp av Microsoft Teams, bør du vurdere å lagre filer i kanaldokumentbiblioteket. Denne fremgangsmåten bidrar til å sentralisere filer og forenkler samarbeid.

Vurder å lagre følgende filtyper i SharePoint.

  • maler og dokumentasjon: Lagre maler og dokumentasjon i SharePoint når du ikke har en eksisterende lagringsløsning. SharePoint er ideelt for disse filene fordi du kan gi tilgang til andre og administrere filer uten komplisert oppsett eller prosesser.
  • støttefiler: Lagre støttefiler i SharePoint når du ikke har en eksisterende lagringsløsning. Noen støttefiler (for eksempel Power BI-tema .json filer for rapporter) kan imidlertid være bedre lagret i et versjonskontrollsystem som gjør det mulig å vise og administrere lagrede endringer.
  • innholdsfiler: Lagre innhold i SharePoint når det ikke er viktig for bedriften, eller når du ikke har tilgang til et eksternt repositorium, for eksempel Azure Repos.
  • datakilder: Lagre datakilder i SharePoint bare når de er små i størrelse og kompleksitet. Øvelsesdisiplin når du bruker SharePoint til å lagre datakildefiler. Vurder andre mulige alternativer, for eksempel OneLake.

Forsiktighet

Ikke bruk SharePoint som et alternativ til en riktig dataarkitektur. Selv om lagring av datakildefiler i SharePoint kan være praktisk i noen begrensede scenarier, skaleres ikke denne tilnærmingen når du har større, mer komplekse datakilder, eller når du trenger lavere ventetid for data.

Advarsel

Ikke bruk personlige filsystemer eller personlige OneDrive-kontoer til å lagre filer. Hvis eieren forlater organisasjonen, vil ikke disse filene lenger være tilgjengelige.

OneLake

Hvis du har en Fabric-kapasitet, kan OneLake være et godt valg for å lagre datakildefiler. Du kan laste opp eller synkronisere filer til OneLake ved hjelp av OneLake File Explorer, der de kan transformeres til tabeller for bruk i nedstrøms arbeidsbelastninger som Power BI. Hvis du vil ha større eller jevnlig oppdaterte datakilder, kan du laste inn filer til OneLake automatisk ved hjelp av Fabric Data Factory eller andre programmer som bruker Azure Data Lake Storage (ADLS) Gen2 API eller Azure Storage Python SDK.

Forsiktighet

Handlinger som å laste opp eller laste ned filer fra OneLake bruke fabric-kapasitetsenheter. Du bør overvåke kapasitetsmåledata og iverksette tiltak for å unngå belastning på kapasiteten forårsaket av unødvendig flytting av store filer.

I tillegg er filer som brukes av brukere med OneLake File Explorer, sårbare for utilsiktede endringer eller tap. Vi anbefaler at du unngår å bruke OneLake File Explorer for forretningskritiske løsninger.

Advarsel

OneLake File Explorer har flere viktige begrensninger og hensyn. OneLake støtter for eksempel ikke versjonskontroll for filer, for eksempel SharePoint eller OneDrive. Ta hensyn til disse hensynene og begrensningene når du bestemmer deg for hvor du skal lagre filer.

Tips

Når du lagrer data i OneLake, bør du vurdere å aktivere forretningskontinuitet og nødgjenoppretting (BCDR) for å redusere risikoen for tap av data. Når BCDR er aktivert, dupliseres og lagres dataene i to forskjellige geografiske områder, i henhold til Azures standard områdesammenkoblinger.

Eksternt repositorium

Innholdsopprettere kan utføre og lagre arbeid fra sin lokale maskin til et eksternt repositorium– for eksempel en Azure Repos- eller GitHub- Git-repositorium – med jevne mellomrom under utvikling. Et eksternt repositorium inneholder den nyeste versjonen av innhold eller støttefiler, og det er tilgjengelig for hele utviklingsteamet. Vanligvis forenkler et eksternt repositorium mer avanserte fremgangsmåter for livssyklusadministrasjon enn å bruke Teams, SharePoint eller OneDrive. Dette er fordi innholdsopprettere kan dra nytte av mer avanserte alternativer for å samarbeide på filer ved hjelp av et eksternt repositorium, eller spore og behandle filendringer. Innholdsopprettere kan for eksempel arbeide på sin egen gren av det eksterne repositoriet for å gjøre endringer, og be om å slå sammen disse endringene til hovedgrenen når de er klare.

Vurder å lagre følgende filtyper i et eksternt repositorium.

  • Maler og dokumentasjon: Lagre maler og dokumentasjon i et eksternt repositorium når du administrerer prosjektet med relaterte tjenester som Azure DevOps.
  • støttefiler: Lagre støttefiler i et eksternt repositorium når en er tilgjengelig for enkel sporing og behandling av endringer.
  • innholdsfiler: Lagre innhold i et eksternt repositorium når det er viktig for bedriften, eller du har tenkt å samarbeide med andre utviklere om det samme innholdet. Et eksternt repositorium er ideelt for sporing av innholdsendringer og tilrettelegging av samarbeid.

Tips

Når du bruker et eksternt repositorium, anbefaler vi på det sterkeste at du lagrer Power BI-rapporter og semantiske modeller som Power BI Desktop-prosjekter (PBIP)-filer i stedet for PBIX-filer. Det er fordi lagrede endringer ikke kan identifiseres i en PBIX-fil.

Vurder også å bruke Power BI-utvidet rapportformat (PBIR) for rapporter. PBIR-formatet sikrer at rapportmetadata er enklere å lese, noe som gjør sporing og administrasjon av endringer i kildekontroll enklere. I tillegg kan rapporter som bruker dette formatet, enkelt administreres av programmatiske verktøy, for eksempel semantiske koblingslaboratorier, et Python-bibliotek fra Microsoft som du kan bruke i Fabric-notatblokker.

Ingen filer: Innhold opprettet i Stoff-portalen

Innholdsopprettere kan redigere innhold direkte i Stoff-portalen. I dette scenarioet fungerer de vanligvis ikke direkte med innholdsfiler. Du bør vanligvis bare redigere innhold i Stoff-portalen når elementtypene ikke kan opprettes andre steder (for eksempel dataflyter, instrumentbord eller målstyringer). Du kan også redigere rapporter og semantiske modeller i Stoff-portalen når du ikke har tilgang til en Windows-maskin, og derfor ikke kan bruke Power BI Desktop. Hvis du vil ha mer informasjon, kan du se Brukerverktøy og enheter.

Forsiktighet

Du kan ikke laste ned noe innhold som er opprettet i Stoff-portalen, som en fil. Rapporter som er opprettet i Fabric-portalen, kan for eksempel ikke lastes ned som PBIX-filer.

Når du redigerer innhold i Stoff-portalen, bør du i stedet bruke Fabric API-er eller Git-integrering for å sikkerhetskopiere innholdsdefinisjoner. Når du sikkerhetskopierer innholdsdefinisjoner, reduserer du forstyrrelser hvis innholdet utilsiktet blir slettet eller utilsiktet endret. Hvis innholdet ved et uhell slettes eller endres, kan du erstatte det ved hjelp av sikkerhetskopieringen.

sjekkliste – Når du planlegger og utformer innhold, omfatter viktige beslutninger og handlinger:

  • Gjennomføre løsningsplanlegging: Samle inn forretningskrav og tekniske krav for å forstå problemet innholdet vil løse, og for å utforme hvordan dette innholdet vil løse problemet.
  • Identifisere hvem som skal opprette innholdet: Avhengig av arbeidsflyten, ferdighetene og behovene til den individuelle innholdsoppretteren, kan det være nødvendig med ulike tilnærminger til livssyklusbehandling.
  • Identifisere om flere innholdsopprettere må samarbeide: Kontroller at opprettere av samarbeid bruker filtyper som støtter versjonskontroll, for eksempel PBIP-filer.
  • Bestem hvordan innholdsopprettere skal samarbeide: Bestem hvor avansert samarbeidet blir. I tillegg kan du bestemme hvordan du vil legge til rette for dette samarbeidet, for eksempel ved hjelp av Microsoft Teams, Azure DevOps eller GitHub.
  • Bestem formatet for innhold: Bestem om semantiske modeller og rapporter for Power BI skal bestå av PBIX- eller PBIP-filer (eller andre formater som BIM eller TMDL for modeller), og om rapporter skal bruke PBIR-formatet eller ikke.
  • Bestem hvordan innhold skal brukes: Evaluer hvordan brukere skal kommunisere med data. Bestem hvilke elementtyper du må opprette for å støtte forbruk, og om brukere bare trenger lesetillatelser, eller også bygge tillatelser til underliggende semantiske modeller eller andre dataelementer. Hvis brukere krever byggetillatelser, må du bestemme tidlig hvordan de skal bruke semantiske modeller, og hvordan du vil lære dem opp til å gjøre dette, effektivt.
  • Konfigurere samarbeidsverktøy: Kontroller at du utfører det nødvendige førstegangsoppsettet for løsningen eller prosjektet. Ta viktige avgjørelser om hvordan du skal administrere samarbeid ved hjelp av disse verktøyene.
  • Lagre datakildefiler i SharePoint eller OneLake: Lagre små, enkle datakildefiler i SharePoint. Ellers kan du bruke OneLake eller ADLSGen2 (hvis de er tilgjengelige) i stedet.
  • Lagre innhold og støttefiler i SharePoint, Microsoft Teams eller et Git-repositorium: Hvis du vil ha enklere, mindre prosjekter, kan du bruke SharePoint for de fleste filer hvis det er organisert og du praktiserer god tilgangsbehandling. For større miljøer eller når parallellt samarbeid kreves, kan du vurdere å bruke et Git-repositorium i GitHub eller Azure DevOps, som vil gi detaljert synlighet av innholdsendringer.
  • Lagre maler og dokumentasjon i Microsoft Teams eller SharePoint: Disse malene og dokumentasjonen er ment for brukerfellesskapet. Sørg for at maler og dokumentasjon er enkle for andre å finne, bruke og forstå.
  • Plan for utvikling og distribusjon: Hvis du vil avslutte denne første fasen, utfører du spesifikk planlegging for å adressere viktige områder og utføre første oppsett. Opprett for eksempel verktøy og test datakildetilkoblinger.

Relatert innhold

I den neste artikkelen i denne serienlærer du hvordan du utvikler innhold og administrerer endringer som en del av administrasjonen av innholdslivssyklusen.