Planlegging av Power BI-implementering: Arbeidsområder på arbeidsområdenivå

Denne artikkelen beskriver taktisk implementeringsplanlegging som du gjør på arbeidsområdenivå for Microsoft Fabric-arbeidsområder, med vekt på Power BI-opplevelsen i Fabric.

Artikkelen gjelder først og fremst for:

• Fabric-administratorer: Administratorer som er ansvarlige for å overvåke Fabric-implementeringen i organisasjonen.
• Center of Excellence (CoE), IT og business intelligence (BI)-team: Team som er ansvarlige for å overvåke bruken av data og BI i organisasjonen, og for å støtte selvbetjente brukere i hele organisasjonen.
• Innholdsopprettere og eiere: Selvbetjente brukere som oppretter, publiserer og administrerer innhold i arbeidsområder.

Hvis du vil bruke arbeidsområder effektivt, tar du mange taktiske beslutninger. Når det er mulig, bør individuelle beslutninger på arbeidsområdenivå samsvare med avgjørelsene på leiernivå.

Arbeidsområdeformål

Når du planlegger et arbeidsområde, er det viktig å vurdere ikke bare hvilken type innhold det vil lagre, men også aktivitetene arbeidsområdet er ment å støtte.

Vurder følgende to eksempler på finansrelaterte arbeidsområder. Selv om begge er dedikert til samme team, tjener hvert arbeidsområde et annet formål:

• arbeidsområde for økonomisk månedsavslutning: Arbeidsområdet for økonomiske inneholder avstemming og avslutningsrapporter for månedsslutt. Dette arbeidsområdet regnes som et uformelt arbeidsområde for å støtte samarbeid. En Power BI-app er ikke nødvendig for innholdslesere fordi den primære bruken av dette arbeidsområdet er samarbeid av en liten gruppe personer som jobber tett sammen. De fleste gruppemedlemmer har tillatelser som lar dem redigere innhold i dette arbeidsområdet.
• arbeidsområde for økonomirapportering: Arbeidsområdet for økonomirapportering inneholder de ferdige rapportene på presentasjonsnivå. Dette arbeidsområdet inneholder innhold som er bredt distribuert over hele organisasjonen til mange seere, inkludert til ledere, via en Power BI-app. Arbeidsområdet er nært styrt.

Med disse to eksemplene i tankene bør du vurdere to spesifikke aspekter ved arbeidsområdeformål: hensikt for samarbeid og hensikt for visning.

Hensikt for samarbeid

Hovedmålet med et arbeidsområde i Fabric-portalen er å legge til rette for samarbeid mellom flere bidragsytere.

Samarbeid i et arbeidsområde skjer på flere måter:

• Teambasert utvikling: Brukere kan samarbeide for å bygge, teste og publisere innhold. Én bruker kan arbeide med utformingen av et lakehouse. En annen bruker kan arbeide med utformingen av semantisk modell, og andre brukere kan fokusere på å bygge rapporter.
• Testing og valideringer: Brukere må kanskje utføre datavalideringer for nytt innhold. Emneeksperter fra forretningsenheten må kanskje utføre testing av brukergodkjenning (UAT). Det kan hende at et datakvalitetsteam må validere nøyaktigheten til den semantiske modellen.
• Forbedringer: Innholdsinteressenter og forbrukere kan foreslå forbedringer av innhold gjennom hele livssyklusen til innholdet.
• Eierskapsoverføring: En annen person eller et annet team kan påta seg ansvaret for innhold som noen andre opprettet.

Et av de viktigste områdene i stoffinnføringsveikartet er eierskap og administrasjon av innhold. Samarbeidstypen som forekommer i et arbeidsområde, er forskjellig basert på fremgangsmåten du velger for innholdseierskap og -administrasjon:

• Forretningsledet selvbetjent BI: Innhold som innholdsoppretterne i en forretningsenhet eller avdeling eier eller administrerer. I dette scenarioet forekommer det meste av samarbeidet i arbeidsområdet blant brukere i denne forretningsenheten.
• Administrert selvbetjent BI: Data som et sentralisert team eier eller administrerer, men ulike innholdsopprettere fra forretningsenheter tar ansvar for rapporter og instrumentbord. I dette scenarioet er det svært sannsynlig at flere arbeidsområder er nødvendig for å sikre samarbeid av flere team av personer.
• Enterprise BI: Innhold som et sentralisert team, for eksempel IT, enterprise BI eller CoE eier eller administrerer. I dette scenarioet forekommer samarbeidsarbeid i arbeidsområdet blant brukere i det sentraliserte teamet.

Sjekkliste over viktige beslutninger og handlinger når du planlegger samarbeid i et arbeidsområde:

Hensikt for innholdsvisning

Det sekundære målet for et arbeidsområde er å distribuere innhold til forbrukere som trenger å vise innholdet. For innholdslesere er den primære fabric-arbeidsbelastningen Power BI.

Du kan nærme deg innholdsdistribusjon i Power BI-tjenesten på flere måter:

• Rapporter kan vises ved hjelp av en Power BI-app: Innhold som er lagret i et arbeidsområde som ikke er personlig, kan publiseres til en Power BI-app. En Power BI-app er en mer brukervennlig opplevelse enn å vise rapporter direkte i et arbeidsområde. Av denne grunn er bruk av en Power BI-app ofte det beste valget for distribusjon av innhold til forbrukere. Målgrupper for en Power BI-app er fleksible. Noen ganger er imidlertid målene for hvordan du distribuerer innhold med en app en faktor for å bestemme hvordan du organiserer innhold i eller på tvers av arbeidsområder. Hvis du vil ha mer informasjon om sikring av Power BI-apper, kan du se Planlegging av rapportforbrukersikkerhet.
• Rapporter kan vises direkte i arbeidsområdet: Denne tilnærmingen passer ofte for uformelle arbeidsområder. Arbeidsområderoller definerer hvem som kan vise eller redigere innholdet i et arbeidsområde. Hvis du vil ha mer informasjon om arbeidsområderoller, kan du se Sikkerhetsplanlegging for innholdsoppretter.
• Rapporter kan deles: Bruk av tillatelser per element (koblinger eller direkte tilgang) er nyttig når du trenger skrivebeskyttet tilgang til ett enkelt element i et arbeidsområde. Vi anbefaler at du bruker apptillatelser og arbeidsområderoller oftere enn deling fordi de er enklere å vedlikeholde. Hvis du vil ha mer informasjon, kan du se Rapporter planlegging av forbrukersikkerhet.
• Rapporter kan bygges inn i et annet program og vises i programmet: Noen ganger er hensikten for forbrukere å vise Power BI-innhold innebygd i et annet program. Innebygging av innhold er nyttig når det er fornuftig for brukeren å forbli i programmet for å øke effektiviteten og holde seg innenfor arbeidsflyten.

Et annet viktig område i stoffinnføringsveikartet er innholdsleveringsomfang. Måtene et arbeidsområde støtter innholdsdistribusjon på, varierer basert på omfanget for innholdslevering:

• Personlig BI: Innhold er ment for innholdsoppretteren å bruke. Siden deling av innhold med andre brukere ikke er et mål, utføres personlig BI i et personlig arbeidsområde som beskrevet i neste del.
• Team BI: Innhold deles med et relativt lite antall kolleger som jobber tett sammen. I dette scenarioet er de fleste arbeidsområder uformelle arbeidsområder.
• Departmental BI: Innhold distribueres til mange forbrukere som tilhører en stor avdeling eller forretningsenhet. I dette scenarioet er arbeidsområdet først og fremst for samarbeidsarbeid. I scenarioer for avdelings-BI vises ofte innhold i en Power BI-app i stedet for direkte vist i arbeidsområdet.
• Enterprise BI-: Innhold leveres bredt på tvers av organisasjonsgrenser til det største antallet målforbrukere. I dette scenarioet er arbeidsområdet først og fremst for samarbeidsarbeid. For enterprise BI-scenarioer vises innhold vanligvis i en Power BI-app i stedet for direkte vist i arbeidsområdet.

Sjekkliste over viktige beslutninger og handlinger når du vurderer forventninger til hvordan arbeidsområdeinnhold vises:

Riktig bruk av personlige arbeidsområder

Du kan velge mellom to typer arbeidsområder:

• Personlige arbeidsområder: Hver bruker har et personlig arbeidsområde. Et personlig arbeidsområde kan brukes til å publisere bestemte typer innhold til Stoff-portalen. Hovedformålet er å støtte personlige BI-bruksscenarioer .
• arbeidsområder: Hovedformålet med et arbeidsområde er å støtte samarbeid mellom flere brukere. Det kan også brukes et arbeidsområde til å vise innhold.

Et personlig arbeidsområde som brukes til noe annet enn å lære personlig BI, midlertidig innhold eller testing, øker risikoen for en organisasjon. Bare eieren av arbeidsområdet oppretter og administrerer innholdet i et personlig arbeidsområde. Et personlig arbeidsområde støtter heller ikke samarbeid med andre.

Hvis du vil tillate en bruker å opprette en hvilken som helst type Stoff-element, for eksempel et lakehouse eller et lager, må et arbeidsområde legges til i en Fabric-kapasitet. Prosessen gjelder både for standard arbeidsområder og personlige arbeidsområder. Du kan styre hvem som kan opprette bestemte typer elementer i et personlig arbeidsområde ved å administrere kapasitetstilordningen.

Et personlig arbeidsområde er begrenset i alternativene for å dele innhold med andre. Du kan ikke publisere en Power BI-app fra et personlig arbeidsområde. Power BI-apper er også en viktig mekanisme for distribusjon av innhold til organisasjonen. Tillatelser per element (koblinger eller direkte tilgang) er den eneste måten å dele personlig arbeidsområdeinnhold med andre på. Omfattende bruk av tillatelser per element innebærer mer innsats, og det øker risikoen for feil. Hvis du vil ha mer informasjon, kan du se Rapporter planlegging av forbrukersikkerhet.

Sjekkliste over viktige beslutninger og handlinger når du vurderer forventninger til hvordan personlige arbeidsområder brukes:

Hvis du vil ha mer informasjon, kan du se veikartet for stoffinnføring:

• Sentralisert stoffportal
• Stoffopplæring
• Stoffdokumentasjon

Eierskap for arbeidsområde

Noe av det viktigste å tenke på når du planlegger arbeidsområder, er å bestemme eierskaps- og forvaltningsrollene og ansvarsområdene. Målet er å ha klarhet i nøyaktig hvem som er ansvarlig for å opprette, vedlikeholde, publisere, sikre og støtte innholdet i hvert arbeidsområde.

Klarhet i eierskap er spesielt relevant når ansvar for å opprette og administrere data desentraliseres eller distribueres mellom avdelinger og forretningsenheter. Dette konseptet kalles også noen ganger en datanettarkitektur . Hvis du vil ha mer informasjon om datanett, kan du se Hva er datanett?.

I Fabric aktiveres desentralisert eller distribuert eierskap gjennom arbeidsområder. Ulike områder i organisasjonen kan arbeide uavhengig, men likevel bidra til den samme underliggende datastrukturen i OneLake. Hvert arbeidsområde kan ha sin egen administrator, tilgangskontroll og kapasitetstilordning (for fakturering, geografisk dataplassering og ytelsesovervåking).

Når hensikten med samarbeid innebærer desentralisering og flere team utover én enkelt forretningsenhet, kan det legge til kompleksitet for administrasjon av arbeidsområder. Det er ofte nyttig å opprette separate arbeidsområder for å tydelig avgrense hvilket team som er ansvarlig for hvilket innhold. Bruk av flere arbeidsområder gjør at du kan være spesifikk når det gjelder eierskap og administrasjonsansvar, og det kan hjelpe deg med å angi sikkerhet i henhold til prinsippet om minst rettigheter. Hvis du vil ha flere sikkerhetshensyn, kan du se Sikkerhetsplanlegging for innholdsoppretter.

Sjekkliste over viktige beslutninger og handlinger når du vurderer ansvarsområder for eierskap av arbeidsområder:

Arbeidsområdeorganisasjon

Hvordan du organiserer arbeidsområder er en av de viktigste aspektene ved planlegging av arbeidsområder.

Ulike forretningsenheter og avdelinger kan bruke arbeidsområder på en annen måte, avhengig av samarbeidskravene. Når du trenger et nytt arbeidsområde, anbefaler vi at du vurderer faktorene som er beskrevet i denne delen.

Emne og omfang for arbeidsområde

Følgende alternativer gir noen forslag til hvordan du kan organisere arbeidsområder etter emne og omfang.

I noen tilfeller kan det hende at du allerede har opprettet noen nyttige grupper i Microsoft Entra ID. Du kan bruke gruppene til å administrere tilgang til ressurser for det definerte emneområdet og omfanget. Det kan imidlertid hende at du må opprette nye grupper for å implementere denne fremgangsmåten fullt ut. Hvis du vil ha mer informasjon, kan du se Tilgang til arbeidsområdet.

Alternativ 1: Ett arbeidsområde per emneområde eller prosjekt

Hvis du oppretter ett arbeidsområde for hvert emneområde eller prosjekt, kan du fokusere på arbeidsområdet. Denne fremgangsmåten kan være mer balansert i distribusjonen av innhold mellom arbeidsområder.

Eksempler: Kvartalsvis økonomi eller produktlanseringsanalyse

Fordelene med alternativ 1 inkluderer:

• Det er enklere å administrere brukertilgang for hvem som kan redigere eller vise innhold fordi tilgangen er begrenset per emneområde.
• Når brukere på tvers av organisasjonsgrenser får tilgang til innhold, er strukturering av arbeidsområder etter emneområde mer fleksibelt og enklere å administrere, som sammenlignes med alternativ 2, diskutert neste gang.
• Ett omfang per emneområde er et godt kompromiss mellom arbeidsområder som inneholder for mange elementer og arbeidsområder som inneholder for få elementer.

En ulempe med alternativ 1 er at avhengig av hvor smale eller brede arbeidsområder er definert, risikerer du fortsatt at brukere oppretter et stort antall arbeidsområder. Det kan være utfordrende å finne innhold for brukere når innhold er spredt over mange arbeidsområder.

Alternativ 2: Ett arbeidsområde per avdeling eller team

En vanlig fremgangsmåte er å opprette ett arbeidsområde per avdeling, team eller forretningsenhet. Justering med organisasjonskartet er faktisk den vanligste måten personer begynner å planlegge arbeidsområder på. Men denne tilnærmingen er ikke ideell for alle scenarier.

Eksempler: Finance Department eller Sales Team Analytics

Diagrammet nedenfor viser et generalisert eksempel på hvordan du kan skille arbeidsområder etter avdeling, team eller emneområde. Alternativ 1 og alternativ 2 ser like ut. Elementene som skal inkluderes i hvert arbeidsområde, avhenger av hva slags data hver avdeling, gruppe eller emneområde fokuserer på, og hvordan de har tenkt å bruke dataene.

Fordelene med alternativ 2 inkluderer:

• Det er enkelt å komme i gang med planleggingen. Alt innhold som avdelingsbrukere trenger, er i ett arbeidsområde.
• Det er enkelt for brukere å vite hvilket arbeidsområde som skal brukes, fordi alt innholdet publiseres i arbeidsområdet som er knyttet til avdelingen eller teamet.
• Det kan være enkelt å administrere sikkerhetsroller, spesielt når du bruker anbefalt fremgangsmåte for å tilordne Microsoft Entra-grupper til arbeidsområderoller.

Ulempene med alternativ 2 inkluderer:

• Resultatet er ofte et arbeidsområde med bredt omfang som inneholder mange elementer. Et bredt definert arbeidsområdeomfang kan gjøre det utfordrende for brukere å finne bestemte elementer.
• Siden det finnes en én-til-én-relasjon mellom et arbeidsområde og en Power BI-app, kan et bredt definert arbeidsområde resultere i apper for brukere som inneholder mye innhold. Du kan redusere problemet ved å utelate bestemte arbeidsområdeelementer fra appen og via utformingen av appnavigasjon.
• Når brukere fra andre avdelinger må vise bestemte arbeidsområdeelementer, kan det være mer komplisert å administrere tillatelser. En risiko er at folk antar at alt i avdelingens arbeidsområde bare er for deres øyne. En annen risiko er at deling av enkeltelementer i stedet for roller brukes til å utføre detaljerte visningstillatelser.
• Hvis noen innholdsopprettere trenger tillatelser til å redigere noen, men ikke alle elementer, er det ikke mulig å angi disse tillatelsene i ett enkelt arbeidsområde. Arbeidsområderoller, som bestemmer redigerings- eller visningstillatelser, defineres på arbeidsområdenivå.
• Når du har et stort antall arbeidsområdeelementer, må du ofte bruke strenge navnekonvensjoner for elementer, slik at brukerne kan finne det de trenger.
• Brede arbeidsområder med mange elementer kan ha en teknisk begrensning på antall elementer som kan lagres i et arbeidsområde.

Alternativ 3: Arbeidsområde for en bestemt rapport eller app

Oppretting av et arbeidsområde for hver rapport eller type analyse anbefales ikke bortsett fra under bestemte omstendigheter.

Eksempler: Daglig salgssammendrag eller lederbonuser

Fordelene med alternativ 3 inkluderer:

• Formålet med et snevert definert arbeidsområde er klart.
• Ultrasensitivt innhold kan, og ofte bør, skilles inn i sitt eget arbeidsområde, slik at det kan administreres og styres eksplisitt.
• Finjusterte arbeidsområdetillatelser gjelder for noen få elementer. Dette oppsettet er nyttig når for eksempel en bruker har tillatelse til å redigere én rapport, men ikke en annen.

Ulemper med alternativ 3 inkluderer:

• Hvis det brukes for mye, kan smalt definerte arbeidsområder føre til et stort antall arbeidsområder.
• Et stort antall arbeidsområder krever mer innsats for brukere. Selv om brukere kan stole på søk, kan det være frustrerende å finne riktig innhold i riktig arbeidsområde.
• Et større antall arbeidsområder øker overvåkingen og arbeidsbelastningen.

Sjekkliste over viktige beslutninger og handlinger når du vurderer emneområdet og omfanget av arbeidsområdeinnhold:

Elementtyper for arbeidsområde

En vanlig praksis for å koble dataressurser fra analytiske ressurser er å skille dataarbeidsområder fra rapportering av arbeidsområder.

• Et dataarbeidsområde er dedikert til lagring og sikring av dataelementer som lakehouse, lager, datasamlebånd, dataflyt eller semantisk modell.
• Et rapporteringsområde fokuserer mer på analyseaktiviteter nedstrøms. Et arbeidsområde for rapportering lagrer og sikrer bare elementer som rapporter, instrumentbord og måledata. Rapportering av arbeidsområder inkluderer vanligvis Power BI-innhold, men det er ikke nødvendig.

I Fabric kan du utvide denne separasjonen til å ha distinkte arbeidsområder for andre elementtyper.

Her er noen eksempler:

• Datakildearbeidsområder for datalagre, lakehouses og SQL-databaser som lagrer data
• Arbeidsområder for datatransformasjon for datasamlebånd, notatblokker og dataflyter som transformerer data
• Distribusjonsarbeidsområder for scorekort og organisasjonsapplikasjoner som distribuerer data til brukere

Diagrammet nedenfor viser et eksempel på hvordan du kan skille arbeidsområder etter elementtype.

Fordelene ved å skille dataarbeidsområder fra rapporteringsarbeidsområder inkluderer:

• Kritiske organisasjonsdata, for eksempel et godkjent lakehouse eller semantisk modell, kan ligge i et bestemt arbeidsområde som er utformet for å gjøre gjenbrukbare data tilgjengelige i virksomhetsskala. Vanlige eksempler inkluderer:
  • Rapportopprettere kan enkelt finne og bruke pålitelige delte semantiske modeller på nytt. Hvis du vil ha mer informasjon, kan du se det administrerte selvbetjente BI-bruksscenarioet .
  • Semantiske modellopprettere kan enkelt finne pålitelige dataflyter eller lakehouse-tabeller. Hvis du vil ha mer informasjon, kan du se det selvbetjente dataforberedelsesbruksscenarioet og det avanserte selvbetjente bruksscenarioet for dataforberedelser .
• Tilgangsbehandling kan sentraliseres for kritiske organisasjonsdata. Det er nyttig å administrere tilgang separat for dataarbeidsområdet sammenlignet med arbeidsområder for rapportering når ulike personer er ansvarlige for data og rapporter. Med administrert selvbetjent BI er det vanlig å ha mange rapportopprettere og færre dataopprettere.
• Begrensning av hvem som kan redigere og administrere semantiske modeller minimerer risikoen for utilsiktede endringer, spesielt for kritiske dataelementer som brukes på nytt for mange formål eller av mange brukere. Fysisk separasjon reduserer sjansene for utilsiktede eller ikke godkjente endringer. Dette ekstra beskyttelseslaget er nyttig for sertifiserte semantiske modeller, som organisasjonen er avhengig av for kvalitet og troverdighet.
• Scenarioer for medeierskap er avklart. Når delte semantiske modeller leveres fra et sentralisert BI- eller IT-team, publiserer selvbetjente innholdsopprettere i forretningsenheter rapporter. En god praksis er å skille de semantiske modellene i et eget arbeidsområde. Denne tilnærmingen unngår tvetydigheten i scenarioer med medeierskap fordi eierskap og ansvar per arbeidsområde er tydeligere definert.
• Sikkerhet på radnivå (RLS) håndheves. Når du oppfordrer opprettere til å arbeide i ulike arbeidsområder, har de ikke unødvendige redigeringstillatelser til den opprinnelige semantiske modellen. Fordelen er at RLS og sikkerhet på objektnivå (OLS) håndheves for innholdsopprettere og innholdslesere.

Ulemper ved å skille dataarbeidsområder fra rapporteringsarbeidsområder inkluderer:

• Det kreves en navnekonvensjon for arbeidsområdet for å skille et dataarbeidsområde fra et rapporteringsområde.
• Ekstra brukeropplæring kreves for å sikre at innholdsforfattere og forbrukere vet hvor de skal publisere og finne innhold.
• Noen ganger er det utfordrende å tydelig avgrense elementtypene som skal være i et arbeidsområde. Over tid kan et arbeidsområde ende opp med å inneholde flere typer innhold enn det som opprinnelig var ment.
• Bruk av separate arbeidsområder resulterer i et større antall arbeidsområder som du må administrere og overvåke. Når du planlegger for formål, omfang og andre hensyn (for eksempel fordeling av utvikling, test og produksjonsinnhold), kan tilnærmingen til arbeidsområdeutforming bli mer komplisert.
• Ekstra endringsbehandlingsprosesser kan være nødvendig for å spore og prioritere forespurte endringer i sentraliserte dataelementer, spesielt når rapportopprettere har krav utover hva sammensatte modeller og mål på rapportnivå kan håndtere.

Arbeidsområdeutviklingsfase

En vanlig praksis er å bruke separate arbeidsområder for ulike stadier av innholdsutvikling. Vanligvis involverer denne praksisen følgende faser:

• Utviklingsarbeidsområder for utestede endringer
• Test arbeidsområder for dedikert intern testing og brukertesting
• Produksjonsarbeidsområder for utgivelse av innhold for forbrukere

I Fabric kan du legge til arbeidsområder for hvert trinn i et utrullingssamlebånd. Et utrullingssamlebånd hjelper med administrasjon av innholdslivssyklus ved å la pipelineadministratorer sammenligne og distribuere endringer mellom faser. Vanligvis publiserer du først innhold til den tidligste fasen (for eksempel utvikling), og deretter distribuerer du det til neste fase (for eksempel distribusjon av innhold fra utvikling til testarbeidsområder , og deretter fra test til produksjonsarbeidsområder ).

Her er et eksempel på dette oppsettet:

Du kan også kombinere skillearbeidsområder etter både utviklingstrinn og elementtype. Hvis du bruker utrullingssamlebånd, kan du bruke autobinding for å sikre at faser er koblet sammen. Autobinding sikrer for eksempel at rapporter i arbeidsområdet for rapportutvikling peker til riktig semantisk modell i arbeidsområdet for modellutvikling.

Her er et eksempel:

Du kan også ha andre arbeidsområder, for eksempel følgende typer arbeidsområder:

• Private arbeidsområder for opprettere å arbeide isolert. Bruk av dette oppsettet er en vanlig praksis for å samarbeide om innhold ved hjelp av Git-integrering, fordi hver innholdsoppretter arbeider på sin egen egen kopi (gren) av innholdet for å unngå å forstyrre hverandres arbeid. Deretter kan opprettere åpne en pull-forespørsel for å flette endringene til en annen gren som synkroniseres til utviklingsarbeidsområdet, som opprettere kan vise, men ikke endre eller publisere innhold til.
• Førproduksjonsarbeidsområder for opprettere kan utføre bestemte tester før de slipper innhold. Disse testene kan omfatte ytelsestesting eller testing av støtteressurser som datagatewayer og apper.
• Sandkassearbeidsområder for opprettere kan fritt eksperimentere og gjennomføre improviserte utforskninger. Sandkassearbeidsområder tømmes vanligvis med regelmessig frekvens (ofte automatisk, for eksempel ved hjelp av API-er eller notatblokker). Innhold som oppretterne ønsker å beholde fra et sandkassearbeidsområde, kan kopieres til et personlig eller privat arbeidsområde for mer utvikling.

Fordelene ved å skille arbeidsområder etter utviklingsstadium inkluderer:

• Du kan støtte mer avanserte og strukturerte utviklingsprosesser, inkludert:

  • Utrullingssamlebånd for å kopiere innhold mellom faser
  • Git-integrerings- og forgreningsstrategier for distribusjon og utgivelse
  • Notatblokker for å organisere eller automatisere bestemte oppgaver i innholdslivssyklusen

• Du kan unngå å forstyrre produksjonsinnholdet som forbrukerne bruker.

• Du har bedre tilgangskontroll for innhold.

Ulempene ved å skille arbeidsområder etter utviklingsstadium inkluderer:

• Du må administrere og styre flere arbeidsområder, noe som skaper mer overhead.
• Du må planlegge for nye distribusjons- og etterdistribusjonsaktiviteter.
• Det kan hende du må ta hensyn til andre verktøy eller funksjoner som ikke støttes, som distribuerer eller promoterer innhold gjennom utviklingsfasene.
• Det kreves mer avanserte retningslinjer for tilgang til arbeidsområdet for å hindre at opprettere publiserer til og bruker feil fase.

Organisasjon i intraarbeidsområde

I tillegg til å organisere arbeidsområdestrukturen, må du også organisere innhold i ett enkelt arbeidsområde.

Hvis du vil organisere innhold bedre i et arbeidsområde, kan du vurdere følgende retningslinjer:

• Bruk klare navnekonvensjoner for enkelt å identifisere annet innhold. Vurder å bruke numeriske prefikser (for eksempel 01 – Daglig salg for å bestille innhold alfabetisk, om nødvendig).
• Bruk aktivitetsflyter til å gruppere innhold etter formålet i arbeidsflyten til oppgaver. Når du bruker aktivitetsflyter, kan du raskt identifisere og velge lignende innhold (ved å velge oppgaven i oppgaveflyten). Det er viktig hvis du bestemmer deg for å inkludere mange elementtyper med ulike formål i samme arbeidsområde.
• Bruk arbeidsområdemapper til å organisere lignende innhold i grupper. Arbeidsområdemapper kan brukes i stedet for eller i tillegg til oppgaver i oppgaveflyter.
• Bruk godkjennings- og følsomhetsetiketter til å merke innhold på riktig måte basert på godkjenning og følsomhetsstatus.

Sjekkliste over viktige beslutninger og handlinger når du vurderer elementtyper som en bruker kan lagre i et arbeidsområde:

Arbeidsområdetilgang

Fordi hovedformålet med et arbeidsområde er samarbeid, gjelder arbeidsområdetilgang hovedsakelig for brukere som oppretter og administrerer arbeidsområdeinnhold. Access kan også være relevant når arbeidsområdet brukes til å vise innhold. Dette formålet er et sekundært formål for arbeidsområder, som beskrevet tidligere i artikkelen.

Når du begynner å planlegge for arbeidsområderoller, er det nyttig å vurdere følgende spørsmål:

• Hvordan skjer samarbeid i arbeidsområdet?
• Vil forbrukere vise innhold direkte i arbeidsområdet?
• Hvem er ansvarlig for å administrere innholdet i arbeidsområdet?
• Hvem kan vise innhold som er lagret i arbeidsområdet?
• Har du tenkt å tilordne individuelle brukere eller grupper til arbeidsområderoller?

En anbefalt fremgangsmåte er å bruke grupper til å tilordne arbeidsområderoller. Sikkerhetsgrupper, e-postaktiverte sikkerhetsgrupper, distribusjonsgrupper og Microsoft 365-grupper støttes alle for arbeidsområderoller. Hvis du vil ha mer informasjon om hvordan du bruker grupper, kan du se Sikkerhetsplanlegging på leiernivå.

Når du planlegger å bruke grupper, kan du vurdere å opprette én gruppe per rolle per arbeidsområde. Hvis du for eksempel vil støtte arbeidsområdet Kvartalsvis økonomi , kan du opprette følgende grupper:

• Administratorer for stoffarbeidsområde – kvartalsvis økonomi
• Medlemmer av stoffarbeidsområdet – Kvartalsvis økonomi
• Bidragsytere for stoffarbeidsområde – kvartalsvis økonomi
• Stoffarbeidsområdeseere – kvartalsvis økonomi
• Power BI-app-seere – kvartalsvis økonomi

Når dataarbeidsområder er atskilt fra rapporteringsarbeidsområder, som beskrevet tidligere i denne artikkelen, resulterer det i et enda større antall grupper. Vurder hvordan antall grupper dobles fra fem til ti når du skiller data og rapporterer arbeidsområder:

• Administratorer for stoffdataarbeidsområde – Kvartalsvis økonomi
• Administratorer for arbeidsområdet for stoffrapportering – kvartalsvis økonomi
• Medlemmer av stoffdataarbeidsområdet – Kvartalsvis økonomi
• Medlemmer av arbeidsområdet for stoffrapportering – Kvartalsvis økonomi
• Bidragsytere for stoffdataarbeidsområde – Kvartalsvis økonomi
• Bidragsytere for arbeidsområdet for stoffrapportering – kvartalsvis økonomi
• Visning av stoffdataarbeidsområde – kvartalsvis økonomi
• Visning av arbeidsområder for stoffrapportering – kvartalsvis økonomi
• Power BI-app-seere – kvartalsvis økonomi

Når det finnes flere arbeidsområder for utvikling, test og produksjon, resulterer det i et enda større antall grupper. Potensielt kan antall grupper tredobles. For bare administratorene for dataarbeidsområdet oppretter du for eksempel disse tre gruppene:

• Administratorer for stoffdataarbeidsområde – Kvartalsvis økonomi [Utvikling]
• Administratorer for stoffdataarbeidsområde – Kvartalsvis økonomi [Test]
• Administratorer for stoffdataarbeidsområde – Kvartalsvis økonomi

De foregående eksemplene er ment å formidle at bruken av grupper som tilordnes til arbeidsområderoller raskt kan bli uhåndterlig.

Effektiv bruk av grupper for arbeidsområderoller kan kreve betydelig planlegging. Vær forberedt på å støte på scenarioer når eksisterende grupper (som kan være på linje med organisasjonskartet) ikke oppfyller alle dine behov for administrasjon av stoffinnhold. I dette tilfellet anbefaler vi at du oppretter grupper spesielt for dette formålet. Ordene Fabric eller Power BI er inkludert i gruppenavnet i de foregående eksemplene for dette formålet. Hvis du har flere verktøy for forretningsintelligens, kan du velge å bruke bare BI som prefiks i stedet. På den måten kan du bruke de samme gruppene på tvers av flere verktøy.

Til slutt viser eksemplene ett arbeidsområde – Kvartalsvis økonomi – men ofte er det mulig å administrere en samling arbeidsområder med ett sett med grupper. Det kan for eksempel hende at flere arbeidsområder som eies og administreres av finansteamet, kan bruke de samme gruppene.

Sjekkliste over viktige beslutninger og handlinger når du vurderer tilgang til arbeidsområdet:

Arbeidsområdedomene

Som beskrevet tidligere i denne artikkelen, er det viktig å ha klarhet i eierskap til arbeidsområdet. Én måte å støtte eierskap av arbeidsområder i Fabric på, er å bruke domener. Et domene er en logisk gruppering av flere arbeidsområder som har lignende egenskaper.

Hvis du vil ha mer informasjon om planlegging av domener i leieren, kan du se Arbeidsområdedomener.

Arbeidsområdeinnstillinger

Du kan konfigurere flere innstillinger for hvert enkelt arbeidsområde. Disse innstillingene kan påvirke hvordan samarbeid oppstår, hvem som har tilgang til arbeidsområdet, og nivået på data gjenbrukbarhet på tvers av stoffarbeidsbelastninger.

Arbeidsområdetype

Hvert arbeidsområde har en arbeidsområde-innstilling . Du kan sette en arbeidsområdetype til Pro, Premium per bruker, Premium-kapasitet, Embedded, Fabric-kapasitet eller Prøveversjon.

Lisenstypen er viktig for planlegging av arbeidsområdet fordi den bestemmer:

• funksjoner: Ulike funksjoner støttes. PPU inneholder flere funksjoner (for eksempel utrullingssamlebånd) som ikke er tilgjengelige i Pro. Mange flere stofffunksjoner (for eksempel lakehouses) blir tilgjengelige for arbeidsområder som er tilordnet en Fabric-kapasitet.

• Innholdstilgang: Lisenstypen bestemmer hvem som har tilgang til innhold i arbeidsområdet:

  • Bare brukere som har en PPU-lisens (i tillegg til å bli tilordnet en arbeidsområderolle) kan få tilgang til et PPU-arbeidsområde.
  • Hvis du forventer å levere innhold til innholdslesere som har en gratis lisens, trenger du en lisens på F64 eller høyere.

• datalagringsplassering: Når du trenger å lagre data i et bestemt geografisk område (utenfor hjemområdet), blir det mulig med et arbeidsområde som er tilordnet en kapasitet (og derfor opprettes kapasiteten i dette området). Hvis du vil ha mer informasjon om plassering av datalagring, kan du se Leieroppsett.

Sjekkliste over viktige beslutninger og handlinger når du vurderer arbeidsplasstype:

Administrasjon av arbeidsområdelivssyklus

Når innholdsopprettere samarbeider for å levere analytiske løsninger som er viktige for organisasjonen, må du ta ulike beslutninger om livssyklusadministrasjon . Prosessene for livssyklusadministrasjon kalles også kontinuerlig integrasjon/kontinuerlig levering (CI/CD), og de er ett aspekt av DevOps.

Vurderinger for livssyklusbehandling omfatter hvordan du:

• Sikre rettidig, pålitelig og konsekvent levering av innhold.
• Kommunisere og koordinere aktiviteter mellom flere innholdsopprettere som arbeider på samme prosjekt.
• Løs konflikter når flere innholdsopprettere redigerer det samme elementet i samme prosjekt.
• Strukturer en enkel og pålitelig distribusjonsprosess.
• Rull tilbake distribuert innhold til en tidligere stabil, fungerende versjon.
• Balansere raske utgivelser av nye funksjoner og feilrettinger når du beskytter produksjonsinnholdet.

Fabric har to komponenter for administrasjon av hovedlivssyklus:

• versjonskontroll av innhold: Git-integrering gjør det mulig for innholdseiere og opprettere å opprette versjoner av arbeidet sitt. Den kan brukes med nettbasert utvikling i et arbeidsområde, eller når team utvikler seg i et klientverktøy, for eksempel Power BI Desktop. Versjonskontroll (også kalt kildekontroll) oppnås ved å spore alle revisjoner av et prosjekt ved hjelp av grener som er knyttet til lokale og eksterne repositorier i Azure DevOps. Endringer utføres regelmessig i grener i det eksterne repositoriet. Når en innholdsoppretter fullfører revisjoner som er testet og godkjent, slås grenen sammen med den nyeste versjonen av løsningen i det eksterne hovedrepositoriet (etter at de har løst eventuelle flettekonflikter). Git-integrering kan angis for hvert arbeidsområde i Stoff-portalen hvis funksjonen er aktivert i leierinnstillingene.
• å fremme innhold: utrullingssamlebånd er primært fokusert på utgivelsesadministrasjon for å opprettholde et stabilt miljø for brukere. Du kan tilordne et arbeidsområde til en fase (utvikling, test eller produksjon) i et utrullingssamlebånd. Deretter kan du enkelt og systematisk promotere eller distribuere innholdet til neste fase.

Når du kombinerer funksjonene for livssyklusadministrasjon, bruker cosider i løpet av planleggingsprosessen anbefalte fremgangsmåter. Du kan for eksempel velge å bruke Git-integrasjon for utviklingsarbeidsområdet og utrullingssamlebånd til å publisere til test- og produksjonsarbeidsområdene. Slike beslutninger krever at du bruker den avtalte praksisen konsekvent. Vi anbefaler at du gjør et konseptbevis for å teste konfigurasjons-, prosess- og tillatelsesmodellen fullstendig.

Sjekkliste over viktige beslutninger og handlinger når du planlegger livssyklusadministrasjon av arbeidsområdene:

Arbeidsområdeintegrering med Data Lake Storage Gen2

Det er mulig å koble et arbeidsområde til en Azure Data Lake Storage Gen2-konto. Du kan ta denne fremgangsmåten av to grunner:

• Lagring av Power BI-dataflytdata: Hvis du velger å hente inn din egen datainnsjø, kan data for Power BI-dataflyter (Gen1) åpnes direkte i Azure. Direkte tilgang til dataflytlagring i Data Lake Storage Gen2 er nyttig når du vil at andre brukere eller prosesser skal vise eller få tilgang til dataene. Det er spesielt nyttig når målet ditt er å bruke dataflyter på nytt utover Power BI. Du har to valg for å tilordne lagringsplass:

  • Lagring på leiernivå, som er nyttig når du vil sentralisere alle data for Power BI-dataflyter til én Data Lake Storage Gen2-konto.
  • Lagring på arbeidsområdenivå, som er nyttig når forretningsenheter administrerer sin egen datainnsjø eller har visse krav til datalagring.

• sikkerhetskopiering og gjenoppretting for Semantiske Power BI-modeller: power bi semantisk modell for sikkerhetskopiering og gjenoppretting støttes for arbeidsområder som er tilordnet kapasitet eller PPU. Denne funksjonen bruker samme Data Lake Storage Gen2-konto som brukes til lagring av Dataflytdata for Power BI (beskrevet i forrige punkt). Sikkerhetskopier av semantisk modell er nyttige for:

  • Etterlevelse av krav til dataoppbevaring
  • Lagre rutinemessige sikkerhetskopier som en del av en strategi for nødutvinning
  • Lagre sikkerhetskopier i et annet område
  • Overføre en datamodell

Sjekkliste over viktige beslutninger og handlinger når du planlegger arbeidsområdeintegrering med Data Lake Storage Gen2:

Arbeidsområdeintegrering med Log Analytics

Log Analytics er en funksjon i Azure Monitor. Du kan bruke Log Analytics til å se gjennom diagnosedata som genereres av Analysis Services-motoren, som er vert for semantiske modeller for Power BI. Logger på arbeidsområdenivå er nyttige for å analysere ytelse og trender, utføre dataoppdateringsanalyse, analysere XMLA-endepunktoperasjoner med mer. Log Analytics er bare tilgjengelig for arbeidsområder som er tilordnet kapasitet eller PPU.

Hvis du vil ha mer informasjon om hendelseslogger for semantisk modell, kan du se Overvåking på datanivå.

Hvis du vil ha mer informasjon om hvordan du konfigurerer Log Analytics for bruk med Power BI, kan du se Konfigurere logganalyse for Power BI. Pass på å forstå forutsetningene du må ha på plass for å implementere integreringen.

Sjekkliste over viktige beslutninger og handlinger når du planlegger arbeidsområdeintegrering med Log Analytics:

Andre egenskaper for arbeidsområde

Flere andre egenskaper for arbeidsområdet kan gi nyttig informasjon. For styrte arbeidsområder anbefaler vi at du angir disse egenskapene.

Her er noen forslag til hvordan du angir nøkkelinnstillingene for å forbedre opplevelsen for brukerne:

• Arbeidsområdebeskrivelse: En god beskrivelse av arbeidsområdet inneholder en kort, men spesifikk forklaring på hvilken type innhold som er i arbeidsområdet. Du kan bruke opptil 4000 tegn til å beskrive:

  • Formålet med arbeidsområdet
  • Målgruppen
  • Innholdstypen som er publisert i arbeidsområdet
  • Om arbeidsområdet anses som underlagt
  • Om arbeidsområdet omfatter utviklings-, test- eller produksjonsdata
  • Hvem du skal kontakte for spørsmål eller støtte

• arbeidsområdekontakter: Kontaktlisten for arbeidsområdet inneholder administratorene for arbeidsområdet som standard. Hvis du har tekniske innholdseiere som er forskjellige fra fagekspertene, kan det være nyttig å angi andre kontakter. Andre kontakter kan være grupper eller enkeltpersoner som kan svare på spørsmål om innholdet i arbeidsområdet.

• Arbeidsområdebilde: Konsekvent bruk av arbeidsområdebilder kan være nyttig for brukere når de skanner en liste over arbeidsområder.

  Vurder å bruke et bilde for å hjelpe brukere med å identifisere:

  • Domenet eller emneområdet
  • Forretningsenheten eller teamet som eier og administrerer innholdet
  • Et dataarbeidsområde som er dedikert til lagring av gjenbrukbare elementer, for eksempel et innsjøhus, lager, datasamlebånd, dataflyt eller semantisk modell
  • Et rapporteringsområde dedikert til lagring av analytiske elementer, for eksempel rapporter, instrumentbord eller måledata

• Innstillinger for datamodell: Gjør det mulig for medlemmer av arbeidsområdet, administratorer og brukere med kompileringstillatelser på semantiske modeller å redigere Power BI-datamodeller ved hjelp av nettgrensesnittet. Denne innstillingen brukes med brukere til å redigere datamodeller i leierinnstillingen for Power BI-tjenesten . Denne innstillingen bør samsvare med dine beslutninger og prosesser for hvordan du oppretter, administrerer og distribuerer innhold. Vurder også metoden for versjonskontroll som beskrevet tidligere.

Sjekkliste over viktige beslutninger og handlinger når du vurderer andre egenskaper for arbeidsområdet:

Andre tekniske faktorer

Andre tekniske faktorer kan påvirke konfigurasjonen av arbeidsområdet:

• Integrering av innhold med andre verktøy og tjenester kan ha lisensieringsimplikasjoner. Hvis du for eksempel bygger inn et Power Apps-visualobjekt i en Power BI-rapport, må du ha relevante Power Apps-lisenser.
• Lagringsgrenser per arbeidsområde gjelder for mengden data du kan lagre i et Pro-arbeidsområde. Hvis bruk av kapasitet eller PPU ikke er et alternativ, bør du vurdere hvordan du arbeider innenfor lagringsgrensene under planleggingsprosessen for arbeidsområdet.
• Når du installerer en malapp fra Microsoft AppSource, oppretter appen et nytt arbeidsområde som har et smalt emne og omfang.

Sjekkliste over viktige beslutninger og handlinger når du vurderer andre tekniske faktorer:

Relatert innhold

Hvis du vil ha mer informasjon, handlinger, beslutningskriterier og anbefalinger for å hjelpe deg med implementeringsbeslutninger for Power BI, kan du se:

• Innføring i planlegging av Power BI-implementering