Del via

Overfør apper og flyter fra standardmiljøet

  • Artikkel

Dette tekniske dokumentet forklarer hvordan organisasjoner og administratorer kan planlegge overføring av appene og flytene fra standardmiljøet.

Forfattere: Ravi Chada (Microsoft), Rui Santos (Microsoft)

Merk

Du kan lagre eller skrive ut dette tekniske dokumentet ved å velge Skriv ut fra nettleseren og deretter velge Lagre som PDF.

Standardmiljø

Ett standardmiljø blir opprettet for hver leier og er tilgjengelig for alle brukerne i denne leieren. Standardmiljøet opprettes i området nærmest standardområdet for Microsoft Entra-leieren og får følgende navn: [Microsoft Entra-leiernavn] (standard). Når en ny bruker registrerer seg for Power Apps eller Power Automate, legges vedkommende til automatisk med rollen Utvikler for standardmiljøet. Ingen brukere legges til automatisk i Miljøadministrator-rollen i standardmiljøet.

Du kan ikke slette standardmiljøet, og du kan ikke sikkerhetskopiere standardmiljøet manuelt. Systemsikkerhetskopier gjøres kontinuerlig. Standardmiljøet er begrenset til 1 TB lagringskapasitet. Standardmiljøet har følgende funksjoner:

  • 3 GB Dataverse-databasekapasitet
  • 3 GB Dataverse-filkapasitet
  • 1 GB Dataverse-loggkapasitet

Kapasitetskontrollen som ble utført før du opprettet nye miljøer, utelater standardmiljøets inkluderte lagringskapasitet ved beregning av om du har tilstrekkelig kapasitet til å opprette et nytt miljø. Hvis du vil lagre mer data, kan du opprette et produksjonsmiljø.

I standardmiljøet kan ansatte i en organisasjon med en Microsoft 365-lisens opprette apper og skyflyter. Standardmiljøet blir det første lekeplasstudioet der disse ansatte kan begynne å bygge apper og flyter. Siden det ikke går an å fjerne miljøutviklerrollen fra standardmiljøet, begynner utviklere å bygge personlige produktivitetsapper og -flyter, og deler dem i teamene slik at andre kan dra nytte av dem. De fleste organisasjoner gir ofte standardmiljøet navnet Personlig produktivitet.

Administratorer oppdager reaktivt at mange apper og flyter opprettes i standardmiljøet. Det er kanskje ikke aktuelt å ha en app eller flyt i standardmiljøet i for eksempel følgende scenarioer:

  • En app deles med mange brukere i produksjonslignende funksjonalitet.
  • En app bruker Excel-arbeidsbøker med sensitive data.
  • En app som er basert på SharePoint-lister, får mange datasamhandlinger, for eksempel innsettinger eller oppdateringer.
  • En app eller flyt bruker koblinger som ikke er tillatt i nye policyer for hindring av datatap.
  • Egendefinerte koblinger aktiveres og brukes i standardmiljøet i stedet for at de sikres i et eget miljø.

Scenarioene ovenfor er verdt å ta hensyn til, og de gir en indikasjon på at du bør begynne å flytte disse appene og flytene fra standardmiljøet til et eget utviklermiljø eller et annet delt miljø. Andre faktorer av betydning er begrensningene som er knyttet til standardmiljøet.

Center of Excellence-team (CoE) som overvåker Power Platform, blir tvunget til å reagere når grensene er nådd, som har en negativ innvirkning på appene som kjører i standardmiljøet. Denne begrensningen kan også være noe en administrator eller CoE-teamet må utføre regelmessig. Det finnes tre omfattende faser:

  • Identifikasjon av Power Platform-objektene
  • Flytting av Power Platform-objektene
  • Opprydding i Power Platform-objektene

Du kan eksportere apper og flyter på ulike måter for å flytte dem til et nytt miljø. Løsninger er en enkeltfil som kan inneholde nesten alt som utviklerne bygger i Power Platform, og å flytte dem sammen. Lerretsapper og skyflyter kan eksporteres direkte.

Over tid er Power Platform-objekter utviklet for å være løsningsavhengige. Nå kan apper og flyter være løsningsavhengige som standard, men dette krever manuell aktivering. Utviklere kan fortsatt opprette apper og flyter fra make.powerapps.com og make.powerautomate.com, som kan klassifiseres som ikke-løsningsavhengige, og disse kan eksporteres enkeltvis eller legges til i en løsning. Hvis utvikleren legger til en løsning, kan vedkommende dra nytte av miljøvariabler og tilkoblingsreferanser for å konfigurere og distribuere endepunkter på tvers av miljøer.

Målet er å legge til alle Power Platform-komponentene i én løsning, som gjør at flere komponenter enkelt kan flyttes som én enhet mellom miljøer.

Identifikasjon av Power Platform-objektene

Det første trinnet er å identifisere apper, flyter og aktiva som må flyttes eller ryddes. Startpakken for CoE gir en oversikt over alle appene og flytene, og Power BI-rapportene bidrar til å fastsette bruk. Dette trinnet hjelper deg å evaluere appbruken og skal gjøre det enklere å merke dem. Når du går gjennom øvelsen, passer du på å merke apper og flyter som skal overføres til et annet miljø. Et merke kan baseres på koblingene som brukes, brukerplassering, brukeravdeling og så videre. Denne artikkelen skisserer også en metode for å gjenkjenne elementer som skal ryddes eller flyttes, basert på rutiner for hindring av datatap.

Flytting av Power Platform-objektene

Hvis komponenten er merket for å flyttes til et annet miljø, finnes det alternativer for å flytte appen. En flytting er en interaktiv prosess, og utvikleren må gjøre litt arbeid. Kompleksitetsnivået knyttet til flytting av en app eller flyt øker med blandingen av komponenter som ble brukt til å bygge appen eller flyten.

La oss for eksempel si at en app har seks skjermer og ti knapper via flere skjermer. La oss si at hver av disse ti knappene kaller opp en individuell flyt. Det finnes også et par flyter som utløses daglig for å rette data eller integrere data med et annet system. La oss også si at det er en bildebehandlingsmodell i AI Builder som brukes som en del av automatiseringen. For å kunne flytte en slik app må alle komponentene legges til i en løsning, og tilkoblingsreferanser må justeres riktig og testes før fullføringen bekreftes.

La oss si at i et annet tilfelle har vi en lerretsapp som bruker en Office 365-tilkobling. I dette tilfellet trenger utvikleren bare å legge til lerretsappen i løsningen.

Opprydding i Power Platform-objektene

Hvis en komponent er merket for opprydding, finnes det to hovedalternativer. Det første alternativet er å slette den direkte, og det andre er å slette den etter at du har tatt en sikkerhetskopi. I det siste tilfellet med sikkerhetskopiering kan enkelte trinn overlappe med objekter som flyttes.

Et eksempel er at administratorer av CoE-team finner at de fleste utviklere oppretter testapper og -flyter for å lære. Utviklerne slutter deretter helt å bruke appene og flytene, som kan bekreftes ved å se på bruksdataene. En annen måte er å sette en app i karantene. Hvis ingen spør etter appen, kan du også slette den.

Det er viktig å iverksette en kommunikasjonsstrategi. Administratorer bør planlegge å meddele følgende:

  • Opprette tilkoblinger som utviklerne må tillate når de lanserer appen i det nye miljøet.
  • Den nye nettadressen til appen fra målmiljøet.
  • Naviger til det riktige miljøet.

Noen av disse løsningene for flytting av objekter er klare til bruk og krever kanskje en frittstående Power Apps- og Power Automate-lisens som gjør at brukere kan å opprette og kjøre apper på tvers av datakilder som strekker seg utover Microsoft 365.

Strategier

Det er større sannsynlighet for at hele prosessen med identifisering og flytting av apper og flyter fra standardmiljøet blir vellykket når den er basert på en strategi. Det finnes flere strategier du kan vurdere.

Strategi for hindring av datatap

Policyer for hindring av datatap fungerer som beskyttelsessperrer for å forhindre brukere fra å eksponere organisasjonsdata utilsiktet og for å beskytte informasjonssikkerheten i leieren. DLP-policyer håndhever regler for hvilke koblinger som er aktivert for hvert miljø, og hvilke koblinger som kan brukes sammen. Koblinger klassifiseres bare som enten bare forretningsdata, ingen forretningsdata tillatt eller blokkert. En kobling i gruppen bare forretningsdata kan bare brukes med andre tilkoblinger fra den gruppen i samme app eller flyt. Vi anbefaler at du har minst én policy.

Identifikasjon av objektene ved hjelp av hindring av datatap

Identifisering basert på policy for hindring av datatap er nyttig for å definere målmiljøer for appene og flytene. Det finnes kanskje apper eller flyter som bruker en kobling som blokkeres av hindring av datatap, eller en blanding av forretningskoblinger og ikke-forretningskoblinger som slutter å fungere når hindring av datatap aktiveres.

For å unngå at potensielt kritiske objekter utsettes for nedetid på grunn av hindring av datatap, som er en del av startpakken for CoE, kan du finne redigeringsverktøyet for hindring av datatap (innvirkningsanalyse). Målet med redigeringsprogrammet for hindring av datatap er å la administratorer se innvirkningen til eksisterende policyer eller den potensielle innvirkningen til policyendringer. Det gir administratorer en oversikt over berørte apper og flyter, og ressurser som hadde blitt deaktivert hvis nye eller oppdaterte policyer hadde blitt håndhevet. Appen kan brukes til å gå gjennom eksisterende policyer, endre eksisterende policyer og redusere risikoen ved å kontakte utviklere og informere dem om det beste tiltaket for appen eller flyten.

Oppdater eksisterende policyer for hindring av datatap for å gå gjennom innvirkningen. Se artikkelen Opprett leiersanering med startpakken for CoE hvis du vil ha mer informasjon om redigeringsprogrammet for hindring av datatap.

Før du aktiverer funksjonen for hindring av datatap, kan du identifisere hvilke apper og flyter som berøres, og varsle utviklerne. Redigeringsprogrammet for hindring av datatap kan sende en liste over alle appene og flytene som påvirkes, til en e-postadresse, som genererer en CSV-fil for hver objekttype.

Velg Eksporter påvirkede apper og flyter til CSV i Innvirkningsanalyse i versjon 2.0 av redigeringsprogrammet for hindring av datatap.

Bruk versjon 2.0 av redigeringsprogrammet for hindring av datatap.

Hver genererte CSV-fil (flow.csv og apps.csv) har informasjon om følgende:

  1. Navn på appene og flytene.
  2. Eier av appene og flytene.
  3. E-postadressen til eieren av appene og flytene.
  4. Alle tilkoblinger som brukes av appene og flytene.
  5. ID for appene og flytene til identifisering av objektet.
  6. Miljø-ID der appene og flytene er plassert.

Legg merke til at Tilkoblinger gir deg listen over alle tilkoblinger som brukes av appen eller flyten. Hvis du må identifisere nøyaktig hvilken kobling som påvirkes av den aktuelle hindringen av datatap, må du foreløpig bruke en automatisering. Vi evaluerer endring av denne situasjonen i verktøyet.

Eksempel på implementering for å identifisere tilkoblingen:

  1. Opprett en Power Automate-flyt.

  2. Bruk koblingen Hent policy for hindring av datatap for leier som angir den aktuelle hindringen av datatap.

  3. Resultatet er to matriser, forretningsdata og ikke-forretningsdata. Som et eksempel viser Twitter-koblingen denne koden:

    [
  {
    "id": "/providers/Microsoft.PowerApps/apis/shared_twitter",
    "name": "Twitter",
    "type": "Microsoft.PowerApps/apis"
  }
……
]

  4. Fra denne listen har du tilgang til navnet på koblingen som samsvarer med navnelisten i Tilkobling-kolonnen i CSV-appen eller -flyten.

  5. Når du konverterer CSV-filen til Excel-format og legger den på OneDrive, kan du lese alle appene og flytene som påvirkes fra Power Automate. Kontroller hvilken tilkobling som påvirkes, basert på logikk som sammenligner tilkoblinger med navn på koblinger.

  6. Etter at du har funnet tilkoblingen som forårsaker innvirkningen, genererer du en ny liste med app- eller flyt-ID-en og koblingen som påvirkes av hindringen av datatap.

  7. Bruk den tidligere informasjonen til å varsle utvikleren om den fremtidige innvirkningen. Du kan bruke Power Cards til å samle inn tilbakemelding fra utvikleren hvis appen eller flyten kan slettes eller må overføres til et annet miljø.

Hvis du basert på analysen fastslår at de berørte flytene ikke blir brukt, kan du sette dem i karantene og sende en e-postmelding til utvikleren med instruksjoner om hvordan de kan flyttes et annet miljø. Dette fremmer en gjør-det-selv-kultur og fjerner skygge-IT. I enkelte situasjoner kan det være aktuelt å utelate enkelte objekter fra hindringen av datatap. Det kan for eksempel hende at du vil bruke en bestemt hindring av datatap for nye ressurser som er opprettet, og utelate de gjeldende ressursene. Hvis du vil ha mer informasjon om ressursunntak ved hindring av datatap, kan du se DLP-ressursunntak.

Miljøstrategien defineres via hindringen av datatap, og dette utgjør et mål for appene og flytene som utvikles i standardmiljøet.

Miljøstrategi

Utvikling av en miljøstrategi krever konfigurasjon av miljøer og andre lag med datasikkerhet på en måte som støtter produktivitetsutvikling i organisasjonen, under sikring og ordning av ressurser. En strategi for å administrere miljøklargjøring, tilgangsstyring og kontroll av ressurser i dem, er viktig for følgende:

  • Sikre data og tilgang.
  • Styr standardmiljøet på en måte som samsvarer med forskriftene.
  • Administrer det riktige antallet miljøer for å unngå spredning og spare kapasitet.
  • Støtt og implementer en sunn administrasjon av applivssyklus.
  • Organiser ressurser i logiske partisjoner.
  • Kundestøtteoperasjoner (og brukerstøtte) for å identifisere apper som er i produksjon ved å ha dem i dedikerte miljøer.
  • Kontroller at data blir lagret og overført i akseptable geografiske områder (for hensyn til ytelse og overensstemmelse).
  • Sikre at programmer som utvikles, isoleres.
  • Aktivering av interne faktureringstjenester for forretningssluttbrukere eller forretningsenheter som bruker tjenestene.

Du bør ha veletablerte avdelinger som kan opprettholde seg selv, og ha eksisterende ALM-prosesser på plass. I slike tilfeller kan miljøer sørge for isolasjon og organisere ressurser basert på avdelingen. En strategi basert på dette, kan oppnås ved å opprette separate miljøer for hver avdeling. Disse miljøene blir deretter målet for appene og flytene i standardmiljøet.

Kommunikasjonsstrategi

Effektiv kommunikasjon er avgjørende i en overføringsprosess. Kommunikasjon skjer i alle faser av overføringsprosessen. Tydelig kommunikasjon fremmer forståelse og samarbeid blant interessenter. Den gjør at informasjonen kan flyte uten problemer, slik at alle involverte er velinformert om overføringsplanene, fremdriften og eventuelle utfordringer.

Som en del av overføringen og oppryddingen må du sikre at prosessen er knirkefri for utviklerne, interessentene og ledelsen. Utarbeid en strategi for hvordan du best kan kommunisere, og på hvilke trinn du må meddele informasjonen, slik at målene forblir konsekvente og bidrar til kommunikasjon for alle involverte. Her er noen alternativer du kan vurdere:

  • Bruk startpakken for CoE til sporing av aktiva.
  • Legg til egendefinerte skyflyter for å sende varsler i ulike faser.
  • Opprett mal-e-postmeldinger som sendes ut for å kommunisere med utviklere.

Ting å huske på:

  • Endring i nettadressen til appen. Brukere av appen må oppdatere eventuelle bokmerker til en app i standardmiljøet.
  • Hvis det finnes en URL-basert HTTP-utløserflyt, må denne oppdateres i avhengige flyter for å sikre at den fortsatt fungerer som en webhook.
  • Gi detaljerte trinn for å opprette tilkoblinger etter at flyttingen er fullført, for både utviklere og appbrukere. Brukere skal ikke være redde for å opprette en tilkobling når de starter appen for første gang i det nye miljøet.

En god start for oppsett av kommunikasjon omfatter en selvbetjeningsmodell som kan skaleres og være nærmere sanntid for brukere, i stedet for bruk av en enkeltbrukers e-postadresse eller en distribusjonsliste. Hvis du planlegger å opprette et SharePoint-område, finnes det en mal du kan bruke til å opprette et internt Microsoft Power Platform-senter. Senteret blir stedet der brukere kan lære om strategi og veiledning, slik at utviklere kan ta riktige beslutninger med hensyn til det de har tenkt å bygge, og hvor de finner det.

Det finnes noen eksisterende løsningskomponenter, for eksempel Konfigurer komponenter for inaktivitetsvarsler og Konfigurere Developer Compliance-komponenter i startpakken for CoE som du kan dra nytte av. Disse komponentene kommer med e-postmaler, og du kan duplisere dem og tilpasse dem til formålet og behovet ditt for overføring fra standardmiljøet. Det er også fint om du kan publisere noen suksesshistorier på kommunikasjonsnettstedet.

Målgrupper

I overføringsprosessen er vanligvis ulike målgrupper involvert i kommunikasjonen. Her er de vanligste interessentene og rollene deres:

  • Appeiere: Appeiere er enkeltpersoner eller team som er ansvarlige for utvikling, vedlikehold og administrasjon av spesifikke apper. De har inngående kunnskaper om funksjonaliteten, arbeidsflyten og konfigurasjonen i programmene. Kommunikasjon med appeiere er avgjørende for å forstå appspesifikke kravene de har, innsamling av tilbakemelding, håndtering av bekymringer og sikre en problemfri overføring av appene til det nye miljøet.
  • Appbrukere: Appbrukere er personene som bruker applikasjonene regelmessig for å utføre sine oppgaver eller arbeidsflyter. De kan ha ulike nivåer av teknisk ekspertise og kjennskap til programmene. Det er viktig at kommunikasjonen med appbrukere informerer dem om overføringen, oppdaterer dem om eventuelle endringer eller avbrudd som kan oppstå, tilbyr dem opplæring eller støtte for å sikre en sømløs overgang, og minimerer eventuell negativ innvirkning på det daglige arbeidet deres.
  • Avdelingsledere eller ledere: Avdelingsledere eller ledere spiller en betydelig rolle i migreringsprosessen når de fører tilsyn med driften og strategiske mål for sine respektive avdelinger. De må informeres om tidslinjen for overføringen, mulige innvirkninger og fordeler. Kommunikasjon med avdelingsledere gjør at de kan gi nødvendig veiledning, tilpasse overføringen etter avdelingsmål og sikre problemfri koordinering i teamene.
  • IT- eller tekniske team: IT- eller tekniske team er ansvarlige for infrastrukturen, systemene og de generelle tekniske aspektene ved overføringen. De er involvert i planleggingen, utførelsen og støtten i overføringsprosessen. Kommunikasjon med IT-team er avgjørende for å diskutere tekniske krav, avhengigheter, sikkerhetshensyn og eventuelle nødvendige infrastruktur- eller konfigurasjonsendringer som må implementeres for at overføringen skal bli vellykket.
  • Sikkerhets- og samsvarsteam: Sikkerhets- og samsvarsteam spiller en kritisk rolle i å sikre datasikkerhet, personvern og forskriftssamsvar under overføringen. De gir veiledning og sikrer at nødvendige tiltak er på plass for å beskytte sensitiv informasjon. Kommunikasjon med team for sikkerhet og forskriftssamsvar innebærer diskutering av sikkerhetskrav, krypteringsprotokoller, tilgangskontroller og eventuelle forskriftsrelaterte hensyn gjennom hele overføringsprosessen.
  • Toppledelsen: Toppledelsen, inkludert ledere på C-nivå eller toppledelse, bør holdes informert om migreringsprosessen. De trenger kanskje ikke detaljert, teknisk informasjon, men bør være oppmerksomme på prosjektets mål, fremdrift og potensielle innvirkninger på organisasjonen. Kommunikasjon med ledelsen bidrar til å sikre støtte fra dem, samsvar med strategiske mål og ressursallokering for overføringen.

Det er viktig å skreddersy kommunikasjonsstrategier og meldinger for hver enkelt målgruppe, og å ta hensyn til de bestemte behovene, bekymringene og den tekniske forståelsen deres. Tydelig kommunikasjon med alle interessenter til rett tid fremmer samarbeid, sikrer problemfri koordinering og reduserer eventuelle vanskeligheter under overføringsprosessen.

Hyppighet

Hvor ofte du kommuniserer med interessenter i en overføringsprosess varierer basert på de bestemte behovene og dynamikken i prosjektet. Det er viktig å etablere regelmessig og konsekvent kommunikasjon for å holde interessenter informert, ta hensyn til bekymringer og være konsekvent gjennom hele overføringen. Her er noe å være oppmerksom på når det gjelder hvor ofte du bør kommunisere med ulike interessenter:

  • Appeiere: Det er viktig å opprettholde hyppig kommunikasjon med appeiere gjennom hele migreringsprosessen. Dette omfatter regelmessige oppdateringer om fremdriften i overføringen, håndtering av eventuelle bekymringer, og involvering av appeierne i beslutninger når det er nødvendig. Kommunikasjonsfrekvensen kan variere avhengig av hvor kompleks og kritisk appen er, men vi anbefaler regelmessig informering og svar på forespørsler i god tid.
  • Appbrukere: Engasjer appbrukere gjennom vanlige kommunikasjonskanaler for å holde dem informert om migreringen. Dette bør omfatte kunngjøringer, e-post, nyhetsbrev eller til og med dedikerte opplæringsøkter eller seminarer. Hvor ofte du kommuniserer med appbrukere kan variere, men det er avgjørende å oppdatere dem ved viktige milepæler, informere dem om eventuelle endringer eller avbrudd som kan påvirke dem, og tilby støtte og veiledning gjennom hele prosessen.
  • Avdelingsledere og ledere: Kommunikasjon med avdelingsledere og ledere kan skje med jevne mellomrom eller etter behov, basert på betydningen av migreringen til deres avdelinger. Gi oppdateringer regelmessig om den totale fremdriften, tidslinjene og innvirkningen på teamene.
  • IT- eller tekniske team: Delta i regelmessig kommunikasjon med IT- og tekniske team som er involvert i overføringen. Dette omfatter pågående samarbeid, deling av oppdateringer om tekniske spørsmål eller problemer, og koordinering av nødvendige konfigurasjoner eller endringer. Kommunikasjonsfrekvensen er vanligvis høyere i planleggings- og analysefasen. I implementeringsfasen har du vanlige berøringspunkter eller møter for å sikre problemfri koordinering.

Ressursforsyning

Effektiv administrasjon av ressurser er avgjørende for en vellykket overføring. Her er noen viktige aspekter å ta hensyn til når det gjelder administrasjon av ressursforsyning i en overføring:

  • Ressursidentifikasjon: Identifiser ressursene som kreves for migreringsprosjektet, inkludert enkeltpersoner eller team som er ansvarlige for oppgaver som forberedelser før migrering, datamigrering, testing, distribusjon, konfigurasjon og støtte etter migrering. Fastsett de bestemte ferdighetene, ekspertisen og tilgjengeligheten som er kreves for hver rolle.
  • Ressursallokering: Tildel ressurser til roller og oppgaver basert på ressursens kompetanser, tilgjengelighet og arbeidsbelastningskapasitet. Sørg for at ressurser er allokeres riktig for å balansere arbeidsmengden og oppfylle prosjektfrister. Ta hensyn til eventuelle avhengigheter eller begrensninger som kan påvirke ressursallokeringen, for eksempel ressurser som er delt på tvers av flere prosjekter.
  • Kompetanser og opplæring: Vurder kompetanser og kunnskapshull i teamet og gi nødvendige opplærings- eller kompetansemuligheter for å sikre at ressursene er tilstrekkelig rustet for de tildelte oppgavene. Dette kan omfatte opplæringsøkter, seminarer eller tilgang til relevante ressurser og dokumentasjon.
  • Kommunikasjon og samarbeid: Fremme effektiv kommunikasjon og samarbeid mellom ressurser som er involvert i migreringen. Oppmuntre til regelmessige statusoppdateringer, koordineringsmøter og kunnskapsdeling for å sikre at alle teammedlemmene er à jour, informert og samarbeider mot felles mål.
  • Beredskapsplanlegging: Forutse potensielle ressursbegrensninger eller risikoer og utvikle beredskapsplaner. Ha reserveressurser klare og opplært i kritiske roller for å redusere eventuelle uventede vanskeligheter, for eksempel uventet fravær eller ressursbegrensninger.
  • Interessentengasjement: Hold interessenter, som appeiere, avdelingsledere og ledelse, informert om ressursallokering og potensiell innvirkning på tidslinjer eller leveranser. Meddel ressursoppdateringer, fremdriftsrapporter og eventuell justering av ressursforsyningsplaner regelmessig for å håndtere forventninger og opprettholde åpenhet.

Individuell overføring av objekter

Forskjellen på app og løsning er viktig. Eksport og import av en app påvirker bare dette objektet. En løsning er en beholder som kan ha flere apper, flyter og andre objekter.

Eksporter og importer en lerretsapp (gammel måte)

De detaljerte trinnene er dokumentert i Eksportere en lerretsapp-pakke og Importere en lerretsapp-pakke.

Dette er en gammel måte å eksportere apper på. Selv om den støttes, anbefaler vi at du bruker løsninger. Løsninger gjør at du kan overføre flere komponenter i stedet for bare én ressurs.

Eksporter og importer flyt (gammel måte)

Fremgangsmåten nedenfor beskriver hvordan du eksporterer en flyt.

  1. Velg …-menyen, velg Eksporter og velg deretter Pakke (ZIP).
  2. Angi et navn og en beskrivelse for pakken. Du kan deretter konfigurere standardinnstillinger og legge til kommentarer som er tilgjengelige i importfasen.
  3. Velg Eksporter-knappen i nedre høyre hjørne for å laste ned pakken. Hvis nedlastingen ikke starter automatisk, kan du velge Last ned-knappen.

Fremgangsmåten nedenfor beskriver hvordan du importerer en flyt.

  1. Velg Importer-knappen.
  2. Last opp pakkefilen, og vent til skjermen viser pakkedetaljene.
  3. Når du konfigurerer flytinnstillingene, kan du opprette en ny flyt eller oppdatere en eksisterende flyt med flytdefinisjonen fra pakken.
  4. Velg tilkoblingene som kreves for å konfigurere flyten. Du skal kunne se Import-knappen etter at du har konfigurert alle de nødvendige innstillingene.

Etter at du har importert flyten, må du aktivere den. Hvis flyten har tilkoblingsreferanser, må brukeren som aktiverer den, ha tilgang til disse tilkoblingene. Hvis ikke kan tilkoblingseieren gi tilgang til aktiveringsbrukeren.

Dette er en gammel måte å eksportere skyflyter på. Selv om den støttes, anbefaler vi at du bruker løsninger, som gjør at du kan overføre flere komponenter i stedet for bare én ressurs.

Eksporter og importer en modelldrevet app

En modelldrevet app er alltid en del av en løsning. Den pakkede appen, som er inkludert i løsningsfilen (ZIP), kan deles med brukere basert på sikkerhetsrollene deres etter at den er eksportert fra kildemiljøet og importert til målmiljøet.

De detaljerte, trinnvise prosessene dekkes i Eksporter en løsning og Importer en løsning.

Eksporter og importer en Microsoft Copilot Studio-robot

Du kan eksportere og importere roboter ved hjelp av løsninger. Du finner en detaljert liste over trinn i Eksporter og importer roboter ved hjelp av løsninger.

Eksporter og importer et Power Pages-nettsted

Overføringssider omfatter eksport av den eksisterende konfigurasjonen fra Microsoft Dataverse-kildemiljøet og deretter import av dem til Dataverse-målmiljøet. Det er enkelte nødvendige trinn som må utføres i målmiljøet. Etter at klargjøringsarbeidet er fullført, kan portalkonfigurasjonsdataene eksporteres ved hjelp av verktøyet for konfigurasjonsoverføring.

SharePoint-skjemaapp – spesialtilfelle for standardmiljø

SharePoint Skjemaapper kan bare knyttes til ett miljø, og hvis de ikke er konfigurert på annen måte, er de i standardmiljøet. En overføring av alle apper krever at målet er et annet miljø enn standardmiljøet. Eksisterende egendefinerte skjemaer overføres ikke automatisk til det nylig angitte miljøet. Bare produksjonsmiljøer kan være angitt for egendefinerte SharePoint-skjemaer. Den manuelle prosessen følger, for eksempel flytting av en lerretsapp.

Sikkerhetskopiering av Microsoft Power Platform-objekter

De fleste Microsoft Power Platform-objekter eksporteres som ZIP-filer. Hvis ikke har de minst ett filformat. Du kan legge til disse filene på enhver fillagringsplass eller et valgfritt repositorium, i det opprinnelige filformatet, som en ZIP-fil eller filtypen de kommer med. Du kan for eksempel velge blant Azure DevOps GitHub, SharePoint One Drive eller andre løsninger som støtter alle filformater.

Alternativer for masseoverføring

Overføringen av en app eller flyt er vellykket hvis den fungerer på samme måte som den gjorde før. Det er imidlertid enkelte elementer som ikke kan overføres:

  • Flytkjøringsdata om tidligere kjøringer av flyten – Dataene om flytkjøringer lagres bare i 28 dager. Hvis du trenger dataene, kan du eksportere og lagre dem ved hjelp av startpakken for CoE eller hvis du har konfigurert eksport til datasjø. Den nyeste versjonen av startpakken for CoE har flytkjøringsdataene hvis den brukes med Dataeksport.
  • Versjoner av lerretsappen – Etter hvert som utviklere gjentar seg gjennom utviklingsprosessen, kan der opprettes flere versjoner. De tidligere versjonene kan ikke overføres. Bare den nyeste versjonen kan overføres.
  • Data som åpnes av appen eller flyten eller ved hjelp av koblinger – Bare appmetadata er inkludert som en del av eksporten.

Eventuelle samarbeidskommentarer som er skrevet i appen eller flyten, tas heller ikke med.

Denne artikkelen skisserer noen muligheter. Det er viktig å vurdere implikasjonene og fordelene ved hver mulighet nøye før du bestemmer deg.

Overfør alle – alternativ for sikkerhetskopiering og gjenoppretting av database

Standardmiljøet sikkerhetskopieres også, slik som de fleste miljøtypene. Disse systemsikkerhetskopieringene utføres automatisk. Det finnes ikke noe behovsbetinget alternativ for standardmiljøet, så det krever en støtteforespørsel. Sikkerhetskopien kan gjenopprettes til et nytt miljø der alle dataene beholdes i Dataverse. Dette alternativet er bare for å vise leseren at det finnes og lære leseren når det bør vurderes. Det bør ikke regnes for å være førstevalget siden det bare hadde gitt delvis overføring.

  • Støttes: Dataverse, Dynamics-apper
  • Støttes ikke fullt ut: Lerretsapp, komponentbibliotek, egendefinerte sider, Power Automate Microsoft Copilot Studio

Støttes ikke helt angir at det kan oppstå et datatap under overføringen, og at flere trinn kreves.

Overfør metadata og deretter data

En anbefalt tilnærming er å bruke løsninger til å flytte metadataene, og deretter enten dataflyter, Azure Data Factory eller et annet verktøy til å overføre data. Det går kanskje ikke an å foreta fullstendig automatisering fra begynnelse til slutt i alle tilfeller, på grunn av de varierte koblingene, men en tilnærming er mulig.

Trinnene er som følger på et høyere nivå:

  1. Legge til en app i en løsning.
  2. Legg til en flyt i en løsning.
  3. Legg til eksisterende roboter.
  4. Juster tilkoblingsreferanser i apper og flyter.
  5. Se etter løsningsavhengigheter, og legg til objekter.
  6. Eksportere løsningen.
  7. Importer løsningen.
  8. Overfør data.

Ser etter løsningsavhengigheter

En løsningsimport i målmiljøet kan bare sikres når alle relaterte komponenter er lagt til i løsningen, eller når de er tilgjengelige i målmiljøet. Hvis det mangler komponenter, mislykkes sannsynligvis importen av løsningen. For å sikre at alle nødvendige komponenter finnes, har du alternativer som fungerer best i kombinasjon:

  • Legg til valgte komponenter i løsningen manuelt. I dette tilfellet antas det at du vet at alle avhengige komponenter allerede finnes i målmiljøet.

  • Bruk knappen Vis avhengigheter i løsningen for å la systemet identifisere avhengigheter for deg. Du kan legge til alle avhengigheter eller bare legge til avhengigheter som ikke finnes i målmiljøet.

    Bilde av et eksempel på avhengige komponenter for forretningsforbindelsestabellen.

Tilføying av en komponent i en løsning (manuelt)

Hvis vi antar at en løsning blir opprettet, må en oppretter bruke menyalternativet for å legge til eksisterende komponent for å kunne legge til en eksisterende app, flyt eller robot.

Bilde av hvordan du legger til eksisterende komponenter i en løsning.

Juster tilkoblingsreferanser

Lerretsapper og flyter håndterer tilkoblinger på en annen måte. Flyter bruker tilkoblingsreferanser for alle koblinger, mens lerretsapper bare bruker dem for implisitt delte (ikke-OAuth) tilkoblinger, for eksempel SQL Servergodkjenning.

Oppdater en app til å bruke tilkoblingsreferanser i stedet for tilkoblinger

Lerretsapper som ikke er løsningsavhengige når de legges til i en løsning, oppgraderes ikke automatisk til å bruke tilkoblingsreferanser. Tilkoblingsreferanser knyttes bare til lerretsapper når en datakilde legges til i appen. Du må gjøre følgende for å kunne oppgradere apper:

  1. Legg til en app som ikke er løsningsavhengig, i en løsning.
  2. Fjern tilkoblingen fra appen.
  3. Opprett en ny tilkoblingsreferanse i løsningen.
  4. Legg til en tilkobling som inneholder en tilknyttet tilkoblingsreferanse.

Oppdater en flyt til å bruke tilkoblingsreferanser i stedet for tilkoblinger

Når en flyt ikke finnes i en løsning, brukes tilkoblinger. Hvis denne flyten deretter legges til i en løsning, fortsetter den i utgangspunktet å bruke tilkoblinger. Flyter kan oppdateres til å bruke tilkoblingsreferanser i stedet for tilkoblinger på en av to måter:

  • Hvis flyten eksporteres i en uadministrert løsning og importeres, blir tilkoblingene fjernet med tilkoblingsreferanser.

  • Når en løsningsflyt åpnes, viser flytkontrollen på siden med flytdetaljer en advarsel om å bruke tilkoblingsreferanser. Advarselsmeldingen har en handling du kan velge for å fjerne tilkoblinger slik at tilkoblingsreferanser kan legges til. Hvis du velger denne handlingen, fjernes tilkoblinger fra utløseren og handlingene i flyten, og tilkoblingsreferanser kan velges og opprettes.

Tilføying av et objekt i en løsning (automatisering)

Du kan bruke PowerShell-kommandoer til masseflytting av apper til en løsning. Du kan også legge til eksisterende lerretsapper og skyflyter i løsninger via kommandolinjen. Installer de nyeste PowerShell-modulene for å prøve dette alternativet. De to hovedkommandoene er Set-PowerAppAsSolutionAware og Set-FlowAsSolutionAware.

Etter at modulene er installert, setter du inn din egen miljø-ID, app-ID, flyt-ID og løsnings-ID.

For en lerretsapp:

Set-PowerAppAsSolutionAware -EnvironmentName {Environment ID} -AppName {App ID} -SolutionId {Solution ID}

For en flyt:

Set-FlowAsSolutionAware -EnvironmentName {Environment ID} -FlowName {Flow ID} - SolutionId {Solution ID}

Tilkoblingsreferanser er dataoppføringer i tabellen for tilkoblingsreferanse. Hvis du vil bruke tilkoblingsreferansen som en del av appen eller flyten, må du endre kjerneappen eller flytdefinisjonen. Du må erstatte noden connectionReferences med tilkoblingsreferansen.

Import og eksport av løsninger

Forutsatt at løsningene er klare kan neste trinn i automatiseringen utføres på flere måter:

  • Eksporter og importer løsningene til målmiljøet manuelt.

  • Bruk pakker til å flytte flere løsninger i én omgang.

  • Bruk Power Platform build tools-oppgaver til å utføre flere operasjoner, for eksempel pakking av løsning, utpakking av løsning, eksport av løsning og import av løsning. DevOps gjør at du kan automatisere administrasjon av programlivssyklus (ALM), og alle disse oppgavene er bygd for å støtte ALM for Microsoft Power Platform.

Power Platform-kommandolinjegrensesnittet (CLI) har også alternativer for eksport og import av løsninger. Alle løsningsrelaterte kommandoer kan brukes til å bygge, eksportere og importere løsninger. Du kan også bruke CLI til å sende data inn og ut.

Et utviklervennlig alternativ er å bruke datasamlebånd som er ment å demokratisere ALM for Power Platform. Å samle funksjoner for ALM-automatisering og CI/CD (Continuous Integration/Continuous Deployment) i én funksjonstjeneste er mer brukervennlig for utviklere, administratorer og utviklere.

Oppretting av tilkoblinger (manuelt)

Opprett de manglende tilkoblingene som kreves av appen eller flyten, i målmiljøet før du angir importoperasjonen. Hvis du vil ha mer informasjon om hvordan du oppretter tilkoblinger, kan du se Behandle tilkoblinger i Power Automate.

Dataoverføring

Det finnes flere alternativer for dataoverføring, alt fra manuell til fullstendig automatisert overføring.

  • Eksporter og importer dataene manuelt ved hjelp av Excel-arbeidsbøker.
  • En Power Automate-skyflyt kan utvikles for å trekke ut data fra kildetabeller og skrive direkte til målet. Dette krever imidlertid at utvikleren bruker Dynamics 365 Connector eller Dataverse-koblingen (eldre). Dataverse-koblingen støtter for øyeblikket ikke tilkobling på tvers av miljøer. Denne funksjonen er planlagt i fremtiden, og etter at den er gitt ut, kan du bruke den til å flytte data fra det ene til det andre.
  • Konfigurasjonsoverføringsverktøyet (CMT) er et verktøy som brukes til portaloverføring, men som også kan brukes til vanlig dataoverføring. CMT kan også brukes med PowerShell. PAC CLI-verktøyet gjør at du kan kalle opp CMT.
  • Dataflyter kan brukes til å opprette tilordninger mellom miljøene og brukes til å flytte data. HTTP-nettkoblingen kan brukes som et alternativ til Dataverse.
  • Azure Data Factory kan brukes med Dataverse-koblingen til å hente data fra kilden og sette dem inn i målet.

Siden standardmiljøet er begrenset i størrelse, skal et av alternativene ovenfor være tilstrekkelig til å flytte data ut av standardmiljøet.

Oppryddingshensyn

Det er lurt å foreta en opprydding i apper og flyter som ikke har vært brukt og oppdatert på lenge. Det finnes ulike fremgangsmåter en administrator kan vurdere når det gjelder opprydding.

  • Fastsett rekkefølgen dataene skal importeres i. De minst avhengige tabellene importeres først, og de mest avhengige importeres til slutt.
  • Det er ikke nødvendig å tilordne alle feltene. Felter som Versjon, Endringsdato, Opprettingsdato og enkelte andre systemfelter trenger ikke å tilordnes.
  • Hvis du vil beholde den opprinnelige opprettingsdatoen, tilordner du kildefeltet Opprettingsdato til feltet OverRiddenCreatedOn i måltabellen.
  • Data for sporing av endringer kan ikke overføres.
  • Ikke aktiver arbeidsflyter eller flyter som utløses basert på datainnsetting, med mindre dette er hensikten. Dette øker dataoverføringstiden.

Merkingsalternativer

Startpakken for CoE har for øyeblikket ikke et merkingsalternativ. Dette kan imidlertid være en tilpassing du kan legge til i startpakken.

Opprett en tabell kalt Merker, og konfigurer en mange-til-mange-relasjon med appen, flytene og andre lagertabeller. Du kan deretter opprette et merke og knytte disse oppføringene til de riktige lagervarene. Du kan få en bedre brukeropplevelse ved å bygge inn et rutenett i Hoved-skjemaet i apper, flyter og andre lagertabeller. Dette alternativet anbefales fordi det har referansekonsekvens.

Opprett et tekstfelt i hver lagertabell, og bruk dette til å registrere teksten (merket) du kan bruke senere.

Hvis du vil ha en fastere liste, oppretter du et globalt alternativsett og legger til dette i alle lagertabellene og skjemaene deres.

Alternativ for karantene

Hvis du ikke er sikker på om visse programmer er nødvendige, kan du prøve å isolere dem en stund og sette dem i karantene mens de er i denne tilstanden. Appen kan bare brukes av eieren. Når det har gått en god stund og du ikke har fått spørsmål om appen fra eieren, kan du fjerne den fra miljøet.

Flyter støtter ikke karantenestatusen, men du kan bruke en lignende metode ved å stoppe flyten og se om den aktiveres på nytt av eieren.

I begge tilfeller er det viktig å ha god kommunikasjon med eieren.

Alternativet Bare slett

Dette alternativet er best hvis det virkelig ikke fører til produktivitetstap og gjenbruk av objektene. De fleste testflyter og -apper havner i denne kategorien.

Når listen over objekter er identifisert, kan du i dette tilfellet utvikle en satsvis PowerShell-fil og sende en CSV-liste til den som deretter sletter alle disse objektene.

Når du går i løkke gjennom ID-ene for apper og flyter, kan du bruke følgende kommando til å fjerne dem fra standardmiljøet.

  • Remove-AdminFlow -EnvironmentName Default-[Guid] -FlowName [Guid]
  • Remove-AdminPowerApp -AppName [Guid] -EnvironmentName [Guid]

Alternativet for sikkerhetskopiering og sletting av objekter

La oss for eksempel si at en Power Automate-flyt er opprettet for å løse et bestemt sesongbasert behov, men at den ikke har vært brukt på lenge. I dette tilfellet er det lurt å ta en sikkerhetskopi av komponenten før du sletter den.

For å ta en sikkerhetskopi av komponenten kan du bruke alternativet for enkeltoverføring eller masseoverføring til å generere en eksportert løsning. Du kan deretter legge denne til i et valgfritt filrepositorium eller i en OneDrive-plassering.

Etter at sikkerhetskopien er sikret, kan du bruke alternativet Slett til å fullføre oppryddingen.

Dette er i mange tilfeller testflyter og -apper utviklere har opprettet som en del av den personlige produktivitetsopplæringen og -eksperimenteringen.

Konklusjon

Power Platform er et verktøy for både selvlærte og profesjonelle utviklere. Bruken av standardmiljøet bør hovedsakelig fokusere på personlig produktivitet ved bruk av Microsoft 365-produkter. Utvikling av alle andre apper og flyter bør skje i angitte, delte miljøer, individuelle miljøer eller utviklermiljøer. Vi anbefaler på det sterkeste utviklingen av en uavhengig miljøstrategi basert på hindring av datatap, som kan hjelpe utviklere å utvikle appene og flytene deres i det riktige miljøet. Det er også en stor fordel å etablere en kommunikasjonsstrategi og gi brukere selvbetjeningsmodeller for læring om strategien, implementering av løsninger og anbefalte fremgangsmåter for å utvikle apper og flyter. Det er fint om du kan publisere noen suksesshistorier på kommunikasjonsnettstedet. Suksesshistorier som publiseres internt, kan gi utviklere forslag og gjøre at de ser hva som er mulig å gjøre ved hjelp av Power Platform.

En sterk styringsstrategi er avgjørende ved overføring eller flytting av bestemte objekter. Det finnes ulike strategier for overføring av objekter, inkludert enkeltoverføring og masseoverføring. Det beste alternativet avhenger av organisasjonspolicyene. Løsninger er den sterkest anbefalte fremgangsmåten for å organisere komponentene i programmet og gjøre overføringer enklere.