Del via

Overføre apps og flows fra standardmiljøet

  • Artikel

I denne hvidbog forklares, hvordan organisationer og administratorer kan planlægge overførsel af deres apps og flows fra standardmiljøet.

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

Bemærk

Du kan gemme eller udskrive denne whitepaper ved at vælge Udskriv i din browser og derefter vælge Gem som PDF.

Standardmiljø

Der oprettes et enkelt standardmiljø for hver lejer, og det deles af alle brugere i denne lejer. Standardmiljøet oprettes i det område, der er nærmest standardområdet for Microsoft Entra-lejeren, og navngives på følgende måde: [Microsoft Entra-lejernavn] (standard). Når en ny bruger tilmelder sig Power Apps eller Power Automate, føjes brugeren automatisk til rollen Udvikler for standardmiljøet. Der føjes ikke automatisk brugere til rollen som miljøadministrator for standardmiljøet.

Du kan ikke slette standardmiljøet, og du kan ikke sikkerhedskopiere standardmiljøet manuelt. Sikkerhedskopiering af systemet sker løbende. Standardmiljøet er begrænset til 1 TB lagerkapacitet. Standardmiljøet har følgende funktioner:

  • 3 GB Dataverse-databasekapacitet
  • 3 GB Dataverse-filkapacitet
  • 1 GB Dataverse-logkapacitet

Den kapacitetskontrol, der udføres, før der oprettes nye miljøer, udelukker standardmiljøets gratis lagerkapacitet, når det beregnes, om du har tilstrækkelig kapacitet til at oprette et nyt miljø. Hvis du vil lagre flere data, kan du oprette et produktionsmiljø.

I standardmiljøet kan medarbejdere i en organisation med en licens til Microsoft 365 oprette apps og cloudflows. Standardmiljøet bliver det første studio, hvor disse medarbejdere kan begynde at bygge deres apps og flows. Da det ikke er muligt at fjerne rollen som miljøudvikler fra standardmiljøet, kan udviklerne gå i gang med at oprette personlige produktivitetsapps og -flows og dele dem i deres teams, så andre kan drage fordel af dem. De fleste organisationer omdøber ofte standardmiljøet til Personlig produktivitet.

Administratorer opdager reaktivt, at mange apps og flows er oprettet i standardmiljøet. Det er måske ikke passende, at en app eller et flow er i standardmiljøet i scenarier som:

  • En app deles med mange brugere i en funktionsmåde, der ligner produktionen.
  • I en app bruges Excel-projektmapper med følsomme data.
  • En app, der er baseret på SharePoint-lister, får mange datainteraktioner, f.eks. indsættelser eller opdateringer.
  • En app eller et flow bruger connectorer, der ikke er tilladt i nye DLP-politikker (forebyggelse af tab).
  • Brugerdefinerede connectorer aktiveres og bruges i standardmiljøet i stedet for at blive beskyttet i et dedikeret miljø.

Ovenstående scenarier er værd at overveje og giver en indikation på, at du bør begynde at flytte disse apps og flows fra standardmiljøet til deres eget udviklermiljø eller et andet delt miljø. Andre faktorer, der spiller ind, er de begrænsninger, der er knyttet til standardmiljøet.

CoE-teams (Center of Excellence), der overvåger Power Platform, tvinges til at reagere, når grænseværdierne er nået, hvilket har en negativ indvirkning på de apps, der kører i standardmiljøet. Denne begrænsning kan være noget, som en administrator eller CoE-teamet skal udføre jævnligt, også. Der er tre brede faser:

  • Identifikation af Power Platform-objekterne
  • Flytning af Power Platform-objekterne
  • Oprydning i Power Platform-objekterne

Du kan eksportere dine apps og flows på forskellige måder for at flytte dem til et nyt miljø. Løsninger er en enkelt fil, der kan indeholde næsten alt det, som udviklerne bygger i Power Platform, og flytte dem sammen. Lærredapps og cloudflows kan eksporteres direkte.

Power Platform-objekter har med tiden udviklet sig til at være løsningsbaserede. Apps og flows kan nu som standard være løsningsafhængige, selvom det kræver manuel aktivering. Udviklere kan stadig oprette apps og flows fra make.powerapps.com og make.powerautomate.com, der kan klassificeres som ikke-løsningsbaserede, og disse kan eksporteres enkeltvis eller føjes til en løsning. Ved at tilføje en løsning kan producenten udnytte miljøvariabler og forbindelsesreferencer til at konfigurere og installere slutpunkter på tværs af miljøer.

Målet er at føje alle Power Platform-komponenter til en enkelt løsning, så flere komponenter nemt kan flyttes som en enkelt enhed mellem miljøer.

Identifikation af Power Platform-objekterne

Det første trin er at identificere apps og flows og aktiver, der skal flyttes over eller ryddes op i. CoE Starter Kit indeholder en opgørelse over alle apps og flows, og Power BI-rapporterne er med til at bestemme brugen. I dette trin kan du evaluere brugen af appen og give den et navn. Når du gennemgår denne øvelse, skal du sørge for at kode apps og flows, der skal overføres til et andet miljø. En kode kan være baseret på de connectorer, der bruges, brugerplacering, brugerafdeling osv. I denne artikel beskrives også en metode til anerkendelse af elementer, der skal renses eller flyttes, på baggrund af praksis for forhindring af datatab (DLP).

Flytning af Power Platform-objekterne

Hvis komponenten er mærket til at flytte til et andet miljø, er der muligheder for at flytte appen. Et skridt er en interaktiv proces, og der skal være en vis grad af udviklerinteraktion. Kompleksiteten ved at flytte en app eller et flow øges med den blanding af komponenter, der bruges til at opbygge appen eller flowet.

En app med seks skærme har f.eks. 10 knapper via flere skærme. Lad os antage, at disse 10 knapper hver kalder et individuelt flow. Der er også et par flow, der udløses dagligt for at reparere data eller integrere data med et andet system. Lad os også antage, at der findes en AI Builder-billedbehandlingsmodel, der bruges som en del af automatiseringen. Hvis du vil flytte en sådan app, skal alle komponenter føjes til en løsning, og forbindelsesreferencerne skal justeres korrekt og testes, før fuldførelsen bekræftes.

I et andet tilfælde skal du antage, at der findes en lærredsapp, som bruger en Office 365-forbindelse. I dette tilfælde skal udvikleren kun føje lærredappen til løsningen.

Oprydning i Power Platform-objekterne

Hvis en komponent er markeret til oprydning, er der to hovedmuligheder. Den første mulighed er at slette den direkte, og den anden er at slette den, når du har taget en sikkerhedskopi. I sidste tilfælde af sikkerhedskopiering kan der være overlapning af trin med objekternes flytning.

Det kan f.eks. være administratorer af CoE-teamet, som finder ud af, at de fleste udviklere opretter testapps og flows med henblik på læring. Udviklerne dropper derefter de apps og flows, som kan bekræftes ved at kigge på forbrugsdata. En anden måde er at sætte en app i karantæne. Hvis ingen henvender sig til dig om appen, kan appen også slettes.

Vedligeholdelse af en kommunikationsstrategi spiller en væsentlig rolle. Administratorer skal planlægge at kommunikere:

  • Oprettelse af forbindelser, som udviklere skal tillade, når appen startes i det nye miljø.
  • Appens nye URL-adresse fra målmiljøet.
  • Navigering til det rette miljø.

Nogle af disse løsninger til flytning af objekter er klar til brug og kræver måske en separat licens til Power Apps og Power Automate, der giver brugerne mulighed for at oprette og køre apps på tværs af datakilder, der rækker ud over Microsoft 365.

Strategier

Hele processen til identifikation og flytning af apps og flows fra standardmiljøet vil med større sandsynlighed blive en succes, når den er baseret på en strategi. Du skal overveje flere strategier.

DLP-strategi

Politikker for forebyggelse af datatab (DLP) fungerer som retningslinjer, der skal forhindre, at brugere utilsigtet eksponerer organisationsdata, og beskytte informationssikkerheden i lejeren. DLP-politikker håndhæver regler for, hvilke forbindelser der er aktiveret for hvert miljø, og hvilke forbindelser der kan bruges sammen. Forbindelser klassificeres enten som kun firmadata, ingen forretningsdata tilladt eller blokeret. En forbindelse r i gruppen kun for forretningsdata kan kun bruges sammen med andre forbindelser fra denne gruppe i samme app eller flow. Vi anbefaler, at du som minimum har én politik.

Identifikation af objekterne med DLP

Det er nyttigt at definere målmiljøer for dine apps og flow ved hjælp af DLP-politikbaseret identifikation. Der kan være apps eller flows, der bruger en connector, som er blokeret af DLP eller en blanding af forretnings- og ikke-forretnings-connectorer, som holder op med at fungere efter aktivering af DLP.

Du kan forhindre nedetid for potentielt vigtige objekter, grundet DLP, som er en del af CoE Starter Kit, kan du finde DLP-editor værktøjet (virkningsanalyse). Målet med DLP-editoren er at give administratorer mulighed for at se virkningen af eksisterende politikker eller de potentielle konsekvenser af ændringer af politikker. Den giver administratorer et overblik over påvirkninger af apps og flows og ressourcer, der ville være deaktiveret, hvis nye eller opdaterede politikker håndhæves. Appen kan bruges til at gennemgå eksisterende politikker, ændre eksisterende politikker og afhjælpe risici ved at kontakte udviklere og informere dem om den bedste fremgangsmåde for deres app eller flow.

Opdater eksisterende DLP-politikker for at gennemgå effekten. Følg artiklen Etablering af lejerhygiene med CoE-startpakke for at finde flere oplysninger om DLP-editoren.

Før du slår DLP-funktionen til, kan du identificere, hvilke apps og flows der påvirkes, og give udviklerne besked. DLP-editoren kan sende en liste over alle de apps og flows, der påvirkes af en mailadresse, som opretter en .csv-fil for hver objekttype.

Vælg Eksportér påvirkede apps og flows til CSV i området Effektanalyse ved hjælp af DLP-editoren version 2.0.

Brug DLP editor version 2.0.

Hver genereret csv-fil (flow.csv og apps.csv) har oplysninger om:

  1. Navnet på apps og flows.
  2. Ejer af apps og flows.
  3. Ejermail for apps og flows.
  4. Alle forbindelser, der bruges af apps og flows.
  5. Id'et for apps og flows for at identificere objektet.
  6. Miljø-id, hvor apps og flow er placeret.

Bemærk, at Forbindelser giver dig en liste over alle de forbindelser, der bruges af appen eller flowet. Hvis du har brug for at identificere præcist, hvilken connector der påvirkes af den pågældende DLP, er der behov for automatisering på nuværende tidspunkt. Vi evaluerer ændring af denne situation i værktøjet.

Eksempel på implementering til identifikation af forbindelsen:

  1. Opret et Power Automate-flow.

  2. Brug den Get Tenant DLP Policy-connector, der angiver den pågældende DLP.

  3. Resultatet er to matrixer, virksomhedsdata og ikke-virksomhedsdata. Twitter-connectoren viser f.eks. denne kode:

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

  4. På denne liste har du adgang til navnet på den connector, der svarer til navnelisten for csv-appen eller flowet Forbindelse.

  5. Ved at konvertere csv til Excel-formatet og placere det i dit OneDrive, kan du læse alle de på påvirkede apps og flows fra Power Automate. Kontrollér, hvilken forbindelse der påvirkes, ud fra en logik, der sammenligner forbindelser med connectornavne.

  6. Når du har fundet ud af, hvilken forbindelse der påvirker forbindelsen, skal du oprette en ny liste med app- eller flow-id'et og den connector, der påvirkes af DLP.

  7. Brug de tidligere oplysninger til at give udvikleren besked om den fremtidige påvirkning. Du kan bruge Power Cards til at indsamle feedback fra udvikleren, hvis appen eller flowet kan slettes eller skal overføres til et andet miljø.

Hvis du ud fra analysen vurderer, at de berørte flows ikke bruges, kan du sætte dem i karantæne og sende en mail til udvikleren med instruktioner i, hvordan de flyttes til et andet miljø. Det opmuntrer til en gør-det-selv-kultur og fjerner skygge-it. I visse situationer vil du måske undtage visse objekter fra DLP. Du kan f.eks. kun anvende en bestemt DLP for nye ressourcer, der er oprettet, og undtage de aktuelle ressourcer. Du kan finde flere oplysninger om DLP-ressourceundtagelse i DLP-ressourceundtagelse.

Miljøstrategien defineres effektivt via DLP, og den giver en destination til de apps og flow, der er udviklet i standardmiljøet.

Miljøstrategi

Når du udarbejder en miljøstrategi, skal du konfigurere miljøer og andre lag af datasikkerhed på en måde, der understøtter produktiv udvikling i organisationen, samtidig med at ressourcerne beskyttes og organiseres. En strategi til administration af miljøklargøring og -adgang og kontrol af ressourcerne i dem er vigtig for at:

  • Beskytte data og adgang.
  • Du kan styre standardmiljøet på en kompatibel måde.
  • Administrere det rette antal miljøer for at undgå sprawl og spare på kapaciteten.
  • Facilitere og implementere en sund administration af programlivscyklus (ALM).
  • Organisere ressourcer i logiske partitioner.
  • Supporthandlinger (og helpdesk), der identificerer de apps, som er i produktion, ved at lade dem blive i dedikerede miljøer.
  • Sørge for, at data lagres og overføres i acceptable geografiske områder (med henblik til ydeevne og overholdelse af angivne standarder).
  • Sikre isolering af applikationer er under udvikling.
  • Aktivering af interne faktureringstjenester til de forretningsslutbrugere eller afdelinger, der forbruger servicen.

Du skal have etableret afdelinger, som kan arbejde selvstændigt og have eksisterende ALM-processer på plads. I disse tilfælde giver miljøer isolation og organiserer ressourcer baseret på afdelingen. En strategi, der er baseret på dette, ved at oprette separate miljøer for de enkelte afdelinger. Disse miljøer bliver derefter destinationen for apps og flow i standardmiljøet.

Kommunikationskategori

Effektiv kommunikation er vigtig under en overførselsproces. Kommunikation sker i alle faser af overførselsprocessen. Klar kommunikation fremmer forståelse og samarbejde mellem interessenter. Det muliggør problemfri informationsflow og sikrer, at alle de implicerede er velinformeret om overførselsplanerne, status og eventuelle udfordringer.

Som led i overførslen og oprydningen skal du sikre, at processen er problemfri for udviklerne, interessenterne og ledelsen. Udarbejd en strategi for, hvordan du bedst kommunikerer, og på hvilke punkter du har brug for at kommunikere, så målene bliver ensartede, og som hjælper med kommunikationen for alle de berørte parter. Nogle muligheder, du skal overveje, omfatter:

  • Brug CoE-startpakke som aktivsporing.
  • Tilføj brugerdefinerede cloudflows for at sende meddelelser i forskellige faser.
  • Opret skabelonmails, der sendes ud for at kommunikere med udviklere.

Et par ting, du skal huske:

  • Ændring i appens URL-adresse. Brugerne af appen skal opdatere eventuelle bogmærker til en app i standardmiljøet.
  • Hvis der er en URL-baseret HTTP-udløserflow, der skal opdateres i afhængige flow for at sikre, at det stadig fungerer som en webhook.
  • Angiv detaljerede trin til oprettelse af forbindelser, når flytningen er fuldført for både udviklere og appbrugere. Brugerne skal ikke bekymre sig om at oprette forbindelse, når de starter appen for første gang fra det nye miljø.

En god start på konfigurationen af kommunikation kræver, at en selvbetjeningsmodel kan skaleres og være mere realtid for brugere end blot at lade den være til en enkelt brugers mail eller en distributionsliste. Hvis du planlægger at oprette et SharePoint-websted, er der en skabelon tilgængelig, som du kan bruge til at oprette en intern hub på Microsoft Power Platform. Hubben bliver det samlede sted til at lære om strategi og vejledning, så udviklere kan træffe de rigtige beslutninger om, hvad de vil bygge, og hvor de skal gøre det.

Der findes nogle eksisterende løsningskomponenter som at konfigurere komponenter til inaktivitetsmeddelelser og konfigurere komponenter til udviklerens overholdelse af angivne standarder i CoE-startpakken, som du kan drage nytte af. Disse komponenter kommer med mailskabeloner, og de kan duplikeres, så de passer til dit formål og behov for at overføre dem fra standardmiljøet. En god tilføjelse er også at indlæse succeshistorier på kommunikationswebstedet.

Målgrupper

I overførselsprocessen er der typisk forskellige målgrupper, der er involveret i kommunikationen. Her er de mest typiske nøgleinteressenter og deres roller:

  • Appejere: Appejere er enkeltpersoner eller teams, der er ansvarlige for udvikling, vedligeholdelse og administration af specifikke applikationer. De har omfattende viden om funktionaliteten, arbejdsprocessen og konfigurationen af deres programmer. Kommunikation med appejerne er vigtig for at forstå deres appspecifikke krav, indsamle feedback, håndtere problemer og sikre en problemfri overførsel af deres apps til det nye miljø.
  • App-brugere: App-brugere er de personer, der bruger applikationerne regelmæssigt til at udføre deres opgaver eller arbejdsgange. De kan have forskellige niveauer af teknisk ekspertise og kendskab til programmerne. Kommunikation med appbrugere er vigtig for at informere dem om overførslen, levere opdateringer om eventuelle ændringer eller forstyrrelser, der kan forekomme, tilbyde oplæring eller support for at sikre en problemfri overgang og minimere enhver påvirkning af den daglige drift.
  • Afdelingsledere eller ledere: Afdelingsledere eller ledere spiller en væsentlig rolle i migreringsprocessen, da de fører tilsyn med driften og de strategiske mål for deres respektive afdelinger. De skal informeres om overførselstidslinjen, potentielle påvirkninger og fordele. Kommunikation med afdelingsledere giver dem mulighed for at yde den nødvendige vejledning, tilpasse overførslen til afdelingsmålene og sikre problemfri koordinering i deres teams.
  • IT-teams eller tekniske teams: IT-teams eller tekniske teams er ansvarlige for infrastrukturen, systemerne og de overordnede tekniske aspekter af migreringen. De er involveret i planlægning, udførelse og support af overførselsprocessen. Kommunikation med it-teams er vigtig for at diskutere tekniske krav, afhængigheder, sikkerhedsovervejelser og eventuelle nødvendige infrastruktur- eller konfigurationsændringer, der skal implementeres for at opnå en vellykket overførsel.
  • Sikkerheds- og overholdelsesteams: Sikkerheds- og overholdelsesteams spiller en afgørende rolle i at sikre datasikkerhed, beskyttelse af personlige oplysninger og overholdelse af lovgivningen under migreringen. De giver retningslinjer og sikrer, at der findes passende foranstaltninger til beskyttelse af følsomme oplysninger. Kommunikation med sikkerheds- og overholdelsesteam involverer krav til sikkerhed, krypteringsprotokoller, adgangskontroller og eventuelle overvejelser om overholdelse i hele overførselsprocessen.
  • Direktion: Direktionen, herunder ledere på C-niveau eller den øverste ledelse, bør holdes orienteret om migreringsprocessen. De kræver muligvis ikke detaljerede, tekniske oplysninger, men de skal være opmærksomme på projektets mål, status og potentielle konsekvenser for organisationen. Kommunikation med ledelsen er med til at sikre deres støtte, justering i forhold til de strategiske mål og ressourceallokeringen af overførslen.

Det er vigtigt at skræddersy kommunikationsstrategier og -meddelelser til den enkelte målgruppe, idet der gøres overvejelser om deres specifikke behov og niveau af teknisk forståelse. Klar og rettidig kommunikation med alle interessenter fremmer samarbejde, sikrer problemfri koordinering og afhjælper eventuelle udfordringer under overførselsprocessen.

Kadence

Kadencen eller hyppigheden af kommunikationen med interessenter under en overførselsproces varierer, afhængigt af projektets specifikke behov og dynamik. Det er vigtigt at etablere regelmæssig og gennemført kommunikation for at holde interessenterne velinformeret, håndtere problemer og opretholde justeringen i hele overførslen. Her er nogle overvejelser omkring kadencen for kommunikation med forskellige interessenter:

  • Appejere: Det er vigtigt at opretholde hyppig kommunikation med appejere gennem hele migreringsprocessen. Dette omfatter jævnlige opdateringer om status for overførslen, håndtering af eventuelle problemer og involvering af appejerne i beslutningsprocessen, når det er nødvendigt. Hyppigheden af kommunikation kan variere, afhængigt af appens kompleksitet og kritiskhed, men det anbefales, at du jævnligt kontrollerer og besvarer forespørgsler.
  • Appbrugere: Engager appbrugere gennem regelmæssige kommunikationskanaler for at holde dem informeret om migreringen. Det bør omfatte meddelelser, mails, nyhedsbreve eller endda dedikerede træningssessioner eller workshops. Hyppigheden af kommunikation med appbrugere kan variere, men det er vigtigt at levere opdateringer på vigtige milepæle, informere dem om eventuelle ændringer eller forstyrrelser, der kan påvirke dem, og yde support og vejledning under hele processen.
  • Afdelingsledere og ledere: Kommunikation med afdelingsledere og ledere kan ske med jævne mellemrum eller efter behov, baseret på betydningen af migreringen til deres afdelinger. Giv jævnlige opdateringer om den overordnede status, tidslinjer og indflydelse på deres teams.
  • IT- eller tekniske teams: Deltag i regelmæssig kommunikation med it- og tekniske teams, der er involveret i migreringen. Det omfatter løbende samarbejde, deling af opdateringer om tekniske spørgsmål eller problemer samt eventuelle nødvendige konfigurationer eller ændringer. Kommunikationshyppigheden er typisk højere i planlægnings- og analysefasen. I implementeringsfasen kan du have jævnlige kontaktpunkter eller møder for at sikre problemfri koordinering.

Ressourcer

Det er vigtigt, at ressourcerne administreres effektivt, hvis overførslen skal lykkes. Her er nogle nøgleaspekter, du skal overveje, når det drejer sig om styring under en overførsel:

  • Ressourceidentifikation: Identificer de ressourcer, der kræves til migreringsprojektet, herunder enkeltpersoner eller teams, der er ansvarlige for opgaver såsom forberedelser før migrering, datamigrering, test, implementering, konfiguration og support efter migrering. Fastsæt de specifikke færdigheder, den ekspertise og den tilgængelighed, der er nødvendig for de enkelte roller.
  • Ressourceallokering: Tildel ressourcer til roller og opgaver baseret på ressourcens færdigheder, tilgængelighed og arbejdsbelastningskapacitet. Sørg for, at ressourcerne allokeres korrekt for at skabe balance i arbejdsbelastningen og overholde projektterminerne. Overvej eventuelle afhængigheder eller begrænsninger, der kan påvirke ressourceallokeringen, f.eks. delte ressourcer på tværs af flere projekter.
  • færdigheder og uddannelse: Vurder færdigheder og videnshuller i teamet og sørg for nødvendige uddannelses- eller opkvalificeringsmuligheder for at sikre, at ressourcerne er tilstrækkeligt rustet til deres tildelte opgaver. Det kan omfatte uddannelsessessioner, workshops eller adgang til relevante ressourcer og dokumentation.
  • Kommunikation og samarbejde: Fremme effektiv kommunikation og samarbejde mellem ressourcer, der er involveret i migreringen. Opfordr til jævnlige statusopdateringer, koordineringsmøder og vidensdeling for at sikre, at alle gruppemedlemmer er tilpasset, velinformeret og arbejder sammen mod fælles mål.
  • Beredskabsplanlægning: Forudse potentielle ressourcebegrænsninger eller risici og udvikle beredskabsplaner. Få identificeret eller uddannet backup-ressourcer i vigtige roller for at afhjælpe eventuelle uventede udfordringer, f.eks. uventet fravær eller ressourcebegrænsninger.
  • Interessentengagement: Hold interessenter, såsom appejere, afdelingsledere og ledelse, informeret om ressourceallokering og enhver potentiel indvirkning på tidslinjer eller leverancer. Du kommunikerer jævnligt om ressourceopdateringer, statusrapporter og eventuelle justeringer af planer, så forventningerne administreres og vedligeholdes.

Individuel overførsel af objekter

Skelnen mellem app og løsning er vigtig. Eksport og import af en app påvirker kun objektet. En løsning er en objektbeholder, der kan have flere apps, flows og andre objekter.

Eksportere og importere en lærredapp (gammel metode)

De detaljerede trin dokumenteres i eksport af en lærredapppakke og import af en lærredapppakke.

Denne metode til eksport af apps er en ældre metode. Selvom det understøttes, anbefales det, at du bruger løsninger. Med løsninger kan du overføre flere komponenter i stedet for kun én ressource.

Eksport- og importflow (ældre metode)

I følgende trin beskrives, hvordan du eksporterer et flow.

  1. Vælg "..." menu, vælg Eksportér, og vælg derefter Pakke (.zip).
  2. Angiv et navn på og en beskrivelse af din pakke. Du kan derefter konfigurere standardindstillinger og tilføje kommentarer, der kan oprettes adgang til under importen.
  3. Vælg knappen Eksport i nederste højre hjørne for at downloade pakken. Hvis download ikke starter automatisk, kan du vælge knappen Download.

I følgende trin beskrives, hvordan du importerer et flow.

  1. Vælg knappen Importér.
  2. Upload pakkefilen, og vent på, at pakkeoplysningerne vises på skærmen.
  3. Når du konfigurerer flowindstillingerne, kan du vælge enten at oprette et nyt flow eller opdatere et eksisterende flow med flowdefinitionen fra pakken.
  4. Vælg de forbindelser, der kræves for at konfigurere flowet. Knappen Import vises nu, når du har konfigureret alle de nødvendige indstillinger.

Når du har importeret flowet, skal det aktiveres. Hvis der er forbindelsesreferencer til flowet, skal den bruger, der aktiverer det, have adgang til disse forbindelser. Hvis ikke, kan forbindelsesejeren give aktiveringsbrugeren adgang.

Denne metode til eksport af cloudflow er en ældre metode. Selvom det understøttes, anbefales det, at du bruger løsninger, som giver dig mulighed for at overføre flere komponenter i stedet for kun én ressource.

Eksportere og importere en modelbaseret app

En modelbaseret app er altid en del af en løsning. Den pakkede app, der findes i løsningsfilen (.zip), kan deles med brugere baseret på deres sikkerhedsroller, når den er eksporteret fra kildemiljøet og importeret i destinationsmiljøet.

De detaljerede trinvise processer dækkes i Eksport af en løsning og Import af en løsning.

Eksport og import af en Microsoft Copilot Studio-robot

Du kan eksportere og importere robotter ved hjælp af løsninger. Du kan se en detaljeret liste over trin i eksport og import ved hjælp af løsninger.

Eksport og import af Power Pages-websted

Overførsel af sider involverer eksport af din eksisterende konfiguration fra Microsoft Dataverse-kildemiljøet og derefter importere dem i Dataverse-målmiljøet. Der er visse nødvendige trin, der skal udføres i destinationsmiljøet. Når forberedelsesarbejdet er fuldført, kan portalkonfigurationsdataene eksporteres ved hjælp af Configuration Migration tool.

SharePoint Formularapp – specielt tilfælde for standardmiljø

SharePoint Formularapps kan kun knyttes til ét miljø, og hvis de ikke er konfigureret på anden måde, er de i standardmiljøet. En overførsel af alle apps kræver, at destinationen angives til et andet miljø i stedet for standardmiljøet. Eksisterende brugerdefinerede formularer overføres ikke automatisk til det miljø, du netop har angivet. Det er kun produktionsmiljøer, der kan angives til brugerdefinerede SharePoint-formularer. Den manuelle proces følger, f.eks. flytning af en lærredsapp.

Sikkerhedskopiering af Microsoft Power Platform-objekter

De fleste Microsoft Power Platform-objekter eksporteres som zip-filer. Hvis ikke, har de mindst ét filformat. Disse filer i deres oprindelige format, som en zip-fil eller en hvilken som helst filtype, de kommer med, kan føjes til en hvilken som helst placering af fillageret eller et lager efter eget valg. Et par muligheder, der skal nævnes, er Azure DevOps, GitHub, SharePoint One Drive eller en anden løsning, der understøtter alle filformater.

Muligheder for masseoverførsel

Overførslen af en app eller et flow lykkes, hvis den fungerer på samme måde som før. Der er dog visse elementer, der ikke kan overføres:

  • Flowkørselsdata om de tidligere kørsler af flowet – Dataene om flowkørsler gemmes kun i 28 dage. Hvis du har brug for dataene, kan de eksporteres og gemmes enten ved hjælp af CoE-startpakke , eller hvis du har konfigureret Eksportér til datasø. Den nyeste version af CoE-startpakken indeholder data om flowkørslen, hvis de bruges sammen med dataeksport.
  • Versioner af lærredappen – Efterhånden som udviklere gentager gennem udviklingsprocessen, kan der oprettes flere versioner. Tidligere versioner kan ikke overføres. Det er kun den nyeste version, der kan overføres.
  • Data, der tilgås af appen eller flowet eller ved hjælp af connectorer – Det er kun appmetadata, der medtages som en del af eksporten.

Eventuelle samarbejdskommentarer, der er foretaget i appen eller flowet, medtages heller ikke.

I denne artikel beskrives nogle muligheder. Det er vigtigt at nøje overveje konsekvenserne og fordelene ved hver enkelt mulighed, før du beslutter dig.

Overføre alle – sikkerhedskopiering og gendannelse af databaser

På samme måde som de fleste miljøtyper sikkerhedskopieres standardmiljøet også. Disse systemsikkerhedskopieringer udføres automatisk. Standardmiljøet har ikke mulighed for at anmode om det, så det kræver en supportanmodning. Sikkerhedskopien kan gendannes i et nyt miljø, hvor alle data holdes inden for Dataverse. Denne mulighed er kun til at vise læseren om dens eksistens og informere læseren om, hvad der skal overvejes. Det bør ikke forfølges som det primære valg, da det kun ville medføre delvis overførsel.

  • Understøttet: Dataverse, Dynamics-apps
  • Understøttes ikke fuldt ud: Lærredapp, komponentbibliotek, brugerdefinerede sider, Power Automate Microsoft Copilot Studio

Understøttes ikke fuldt ud angiver, at der kan ske tab af data under overførslen, og der skal muligvis udføres ekstra trin.

Overføre metadata og derefter data

En anbefalet fremgangsmåde er at bruge løsninger til at flytte metadataene, og derefter kan du enten bruge dataflow, Azure Data Factory eller et andet foretrukket værktøj til overførsel af data. Komplet automatisering fra start til slut kan muligvis ikke fuldføres i alle tilfælde på grund af de forskellige connectorer, men det er muligt at komme tæt på.

På et højt niveau er trinnene:

  1. Føj app til en løsning.
  2. Føj flow til en løsning.
  3. Tilføj eksisterende robotter.
  4. Juster forbindelsesreferencer i apps og flows.
  5. Kontrollér for løsningsafhængigheder, og tilføj objekter.
  6. Eksportér løsningen.
  7. Importér løsningen.
  8. Overfør data.

Kontroller for løsningsafhængigheder

Du kan kun opnå gode resultater med en løsningsimport i destinationsmiljøet, hvis du har føjet alle relaterede komponenter til løsningen, eller når de er tilgængelige i destinationsmiljøet. Hvis der mangler komponenter, vil importen af løsningen sandsynligvis mislykkes. Hvis du vil sikre, at alle påkrævede komponenter findes, er der muligheder for kombination:

  • Tilføj manuelt komponenterne i løsningen. I dette tilfælde antages det, at du ved, at alle afhængige komponenter allerede er tilgængelige i destinationsmiljøet.

  • Brug knappen Vis afhængigheder fra løsningen til at identificere afhængigheder for dig. Du kan tilføje alle afhængigheder eller kun tilføje de afhængigheder, der ikke findes i destinationsmiljøet.

    Billede, der viser et eksempel på afhængige komponenter til firmatabellen.

Tilføje en komponent i en løsning (manuelt)

Hvis der oprettes en løsning, skal en bruger bruge menuindstillingen Tilføj eksisterende komponent for at tilføje en eksisterende app, et eksisterende flow eller en eksisterende løsning.

Billede, der viser, hvordan du føjer eksisterende komponenter til en løsning.

Justere forbindelsesreferencer

Lærredapps og flow håndterer forbindelser anderledes. Flow bruger forbindelsesreferencer til alle connectorer, mens lærredapps kun bruger dem til implicit delte (ikke-OAuth) forbindelser, f.eks. SQL Servergodkendelse.

Opdatering af en app til at bruge forbindelsesreferencer i stedet for forbindelser

Lærredapps, der ikke er løsningsbaserede, når de tilføjes i en løsning, opgraderes ikke automatisk til brug af forbindelsesreferencer. Forbindelsesreferencer knyttes kun til apps på lærred, når datakilde føjes til appen. Hvis du vil opgradere apps, skal du:

  1. Føje en app, der ikke er løsningsbaseret, til en løsning.
  2. Fjerne forbindelsen fra appen.
  3. Oprette en ny forbindelsesreference i løsningen.
  4. Tilføj en forbindelse, der indeholder en tilknyttet forbindelsesreference.

Opdatering af et flow, så der bruges forbindelsesreferencer i stedet for forbindelser

Når et flow ikke findes i en løsning, bruges der forbindelser. Hvis flowet derefter tilføjes i løsningen, vil det fortsætte med at bruge forbindelser. Flows kan opdateres, så der bruges forbindelsesreferencer i stedet for forbindelser på to måder:

  • Hvis flowet eksporteres i en ikke-administreret løsning og importeres, fjernes forbindelserne med forbindelsesreferencer.

  • Når der åbnes et løsningsflow, vises der en advarsel om at bruge forbindelsesreferencer i flowkontrolløren på siden med flowdetaljer. Advarslen indeholder en handling til fjernelse af forbindelser, så der kan tilføjes forbindelsesreferencer. Hvis du vælger handlingen, fjernes forbindelser fra udløseren og handlingerne i flowet, og det er muligt at vælge og oprette forbindelsesreferencer.

Føje et objekt til en løsning (automatisering)

Du kan bruge PowerShell-kommandoer til at masseflytte apps til en løsning. Du kan også tilføje allerede eksisterende lærredsapps og cloudflows til løsninger via kommandolinjen. Installer de nyeste PowerShell-moduler for at afprøve dette. De to hovedkommandoer er Set-PowerAppAsSolutionAware og Set-FlowAsSolutionAware.

Når modulerne er installeret, skal du indsætte dit eget miljø-id, app-id, flow-id og løsnings-id.

Til en lærredsapp:

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

Til et flow:

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

Forbindelsesreferencer er dataposter i tabellen med forbindelsesreference. Hvis du vil bruge forbindelsesreferencen som en del af appen eller flowet, skal kerneappen eller flowdefinitionen ændres. Du skal erstatte noden connectionReferences med forbindelsesreferencen.

Import og eksport af løsning

Hvis løsningerne er klar, kan næste trin i automatiseringen udføres på flere måder:

  • Eksportér og importér løsningerne manuelt til destinationsmiljøet.

  • Brug pakker til at flytte flere løsninger ad gangen.

  • Brug Power Platform værktøjsopgaver til at udføre flere handlinger, f.eks. pakke løsning, pakke løsning ud, eksportere løsning og importere løsning. DevOps giver mulighed for at automatisere ALM (administration af programlivscyklus), og disse opgaver er udviklet til at understøtte ALM for Microsoft Power Platform.

Du kan også bruge Power Platform CLI (kommandolinjegrænseflade) til at eksportere og importere løsninger. Alle løsningsrelaterede kommandoer kan bruges til at oprette, eksportere og importere løsninger. Du kan også bruge CLI til at overføre data ind og ud.

Det findes en brugervenlig metode med pipelines, som skal udfylde ALM til Power Platform. Hvis du samler funktionerne til ALM-automatisering og løbende integration/løbende udrulning (CI/CD) i en enkelt funktionstjeneste er det nemmere for alle oprettere, administratorer og udviklere.

Oprettelse af forbindelser (manuelt)

I destinationsmiljøet, før importhandlingen er indstillet, skal du oprette de manglende forbindelser, der kræves af appen eller flowet. Du kan finde flere oplysninger om, hvordan du opretter forbindelser, under Administrere forbindelser i Power Automate.

Dataoverførsel

Der findes flere muligheder for dataoverførsel, lige fra manuel til fuld automatisering.

  • Eksportér og importér dataene manuelt ved hjælp af Excel-projektmapper.
  • Der kan udvikles et Power Automate-cloudflow, som udtrækker data fra kildetabellerne og skriver direkte til destinationen. Dette kræver dog, at udvikleren bruger Dynamics 365 Connector eller Dataverse (ældre) connector. Dataverse connector understøtter i øjeblikket ikke oprettelse af forbindelse på tværs af miljøer. Denne funktion er planlagt til fremtiden, og når den er frigivet, kan den bruges til at flytte data fra den ene til den anden.
  • Konfigurationsoverførselsværktøj (CMT) er et værktøj, der bruges til portaloverførsel, men kan også bruges til almindelig dataoverførsel. CMT kan også bruges med PowerShell. Værktøjet PAC CLI giver mulighed for at kalde CMT.
  • Dataflows kan bruges til at oprette tilknytninger mellem miljøer og bruges til at flytte data. HTTP Web connector kan bruges som et alternativ til Dataverse.
  • Azure Data Factory kan bruges sammen med Dataverse connectoren til at trække data fra kilden og indsætte dem i destinationen.

Da standardmiljøet er begrænset i størrelsen, er en af de ovennævnte muligheder tilstrækkelig til at flytte data ud af standardmiljøet.

Oprydningsovervejelser

En oprydning er en god ide til apps og flows, der ikke er blevet brugt og opdateret i lang tid. Der er forskellige veje, en administrator kan overveje med hensyn til oprydning.

  • Beslut rækkefølgen af dataimporten. De mindst afhængige tabeller går først, og de mest afhængige kommer til sidst.
  • Ikke alle felter skal tilknyttes. Felter som Version, Ændringsdato, Oprettet den og nogle andre systemfelter behøver ikke at blive tilknyttet.
  • Hvis du vil bevare den oprindelige Oprettet den, skal du knytte kildefeltet Oprettet den til feltet OverRiddenCreatedOn i destinationstabellen.
  • Overvågningsdata kan ikke overføres.
  • Aktivér ikke arbejdsprocesser eller flows, der udløses på baggrund af indsættelse af data, medmindre det er hensigten. Derved øges dataoverflytningstiden.

Tagging-muligheder

CoE-startpakke har ikke mulighed for tagging i dag. Det kan dog være en tilpasning, som du kan føje til startpakken.

Opret en tabel kaldet Tags , og opret en mange-til-mange-relation (N:N) med appen, flowene og andre lagertabeller. Du kan derefter oprette en tag og knytte disse poster til de relevante lagerelementer. Du kan opnå en bedre brugeroplevelse ved at integrere et gitter i hovedformularen for apps, flows og andre lagertabeller. Denne mulighed anbefales, da den har refererende ensartethed.

Opret et tekstfelt på de enkelte lagertabeller, og brug det til at indlæse den tekst (tag), du senere kan bruge.

Hvis du vil have en mere fast liste, skal du oprette en global grupperet indstilling og føje den til alle lagertabellerne og deres formularer.

Karantænemulighed

Hvis du er usikker på nødvendigheden af bestemte programmer, kan du prøve at isolere og sætte dem i karantæne i denne tilstand. Appen kan kun bruges af ejeren. Når en passende tid er gået, og der ikke er modtaget noget svar fra ejeren, kan du fjerne dem fra miljøet.

Flows understøtter ikke karantænetilstanden, men en lignende fremgangsmåde kan bruges ved at stoppe flowet og kontrollere, om det aktiveres igen af ejeren.

I begge tilfælde er det vigtigt at have korrekt kommunikation med ejeren.

Kun sletning

Hvis produktiviteten og genbrug af objekterne ikke går tabt, er denne mulighed den bedste. De fleste testflows og -apps er omfattet af denne kategori.

Når listen over objekter er identificeret, kan der i dette tilfælde udvikles et PowerShell-batch, og der overføres en csv-liste til den, som derefter sletter alle disse aktiver.

Når du løkker gennem id'erne for apps og flows, kan følgende kommando bruges til at fjerne dem fra standardmiljøet.

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

Sikkerhedskopiering og sletning af objekter

Antag f.eks., at der oprettes et Power Automate-flow for at imødekomme et bestemt behov, men at det ikke har været brugt længe. I dette tilfælde er det godt at tage en sikkerhedskopi af komponenten, før du sletter komponenten.

Hvis der skal oprettes en sikkerhedskopi af komponenten, kan der enten bruges individuel overførsel eller masseoverførsel til at oprette en eksporteret løsning. Det kan derefter føjes til enten et fillager efter eget valg eller til en OneDrive-placering.

Når sikkerhedskopieringen er beskyttet, kan du anvende indstillingen Slet for at fuldføre oprydningsprocessen.

I mange tilfælde er det testforløb og apps, der er oprettet af udviklere som en del af deres personlige produktivitetslæring og eksperimenter.

Konklusion

Power Platform er et værktøj, der anvendes af selvlærte udviklere og professionelle udviklere. Standardmiljøet bør primært fokusere på personlig produktivitet ved hjælp af Microsoft 365-produkter. Alle andre apps og udvikling af flows skal ske i bestemte delte, individuelle eller udviklermiljøer. Det anbefales derfor, at der udvikles en uafhængig miljøstrategi baseret på DLP, som kan hjælpe udviklere med at oprette deres apps og flows i det rigtige miljø. Det er også en stor fordel at udarbejde en kommunikationsstrategi og give brugerne selvbetjeningsmodeller for læring om strategien, implementering af løsninger og bedste praksis til udvikling af apps og flows. En god tilføjelse er at indlæse succeshistorier på kommunikationswebstedet. Succeshistorier, der udgives internt, hjælper udviklere med at komme i kontakt med ideer og gøre dem åbne over for muligheder, der kan opnås ved hjælp af Power Platform.

Det er vigtigt med stærk styringsstrategi i forbindelse med overførsel eller flytning af bestemte objekter. Der findes forskellige strategier for overførsel af objekter, herunder individuel og masseoverførsel. Den mulighed, der passer bedst, afhænger af organisationens politikker. Løsninger er den mest anbefalede måde at organisere komponenterne i programmet på og gøre det nemmere at foretage overflytninger.