Migrera program och flöden från standardmiljö

Artikel
09/05/2023

I det här dokumentet förklaras hur organisationer och administratörer kan planera migrering av sina appar och flöden från standardmiljön.

Författare: Ravi Chada (Microsoft), Rui Santos (Microsoft)

Obs

Du kan spara eller skriva ut detta white paper genom att välja Skriv ut i webbläsaren och sedan välja Spara som PDF.

Standardmiljö

En standardmiljö skapas automatiskt för varje klientorganisation och kan kommas åt av alla användare i klientorganisationen. Standardmiljön skapas i det närmaste området till standardområdet för Microsoft Entra klientorganisationen och erhåller namnet: [namn på Microsoft Entra-klientorganisation] (standard). När en ny användare registrerar sig för Power Apps eller Power Automate läggs de automatiskt till i standardmiljöns roll för utvecklare. Inga användare kommer automatiskt att läggas till i rollen miljöadministratör i standardmiljön.

Det går inte att ta bort standardmiljön och det går inte att säkerhetskopiera standardmiljön manuellt. Systemsäkerhetskopiering sker kontinuerligt. Standardmiljön är begränsad till 1 TB lagringskapacitet. Standardmiljön har följande funktioner:

3 GB Dataverse databaskapacitet
3 GB Dataverse filkapacitet
1 GB Dataverse loggkapacitet

Kapacitetskontrollen som utfördes innan du skapade nya miljöer utesluter standardmiljöns lediga lagringskapacitet vid beräkning av om du har tillräcklig kapacitet för att skapa en ny miljö. För att lagra mer data kan du skapa en produktionsmiljö.

I standardmiljön kan anställda i en organisation med Microsoft 365-licens skapa appar och molnflöden. Standardmiljön blir den första testplatsstudio där de anställda börjar bygga sina appar och flöden. Eftersom det inte går att ta bort miljöskaparrollen från standardmiljön börjar utvecklare bygga personliga produktivitetsappar och -flöden och dela dem i sina team så att andra kan använda dem. De flesta organisationer byter ofta namn på standardmiljön till Personlig produktivitet.

Administratörer upptäcker återaktivt att många appar och flöden skapas i standardmiljön. Det kanske inte är lämpligt att en app eller ett flöde finns i standardmiljön i situationer som:

En app delas med många användare i produktions liknande beteende.
En app använder Excel-arbetsböcker med känsliga data.
En app, som bygger på SharePoint-listor, får många datainteraktioner, till exempel infogningar eller uppdateringar.
En app eller ett flöde använder anslutningar som inte är tillåtna i nya policyer för förhindrande av dataförlust (DLP).
Anpassade anslutningsprogram aktiveras och används i standardmiljön i stället för att skyddas i en dedikerad miljö.

Ovanstående scenarier är värda att överväga och ger en indikation på att du bör börja flytta dessa appar och flöden från standardmiljön till deras egen, utvecklarmiljö eller annan delad miljö. Andra faktorer som spelar in är begränsningarna som är kopplade till standardmiljön.

Center of Excellence (CoE) team som övervakar Power Platform måste reagera när begränsningarna har nåtts, vilket påverkar apparna som körs i standardmiljön negativt. Den här begränsningen kan också en administratör eller CoE-team måste utföras regelbundet. Det finns tre breda stadier:

Identifiering av Power Platform objekten
Flytta Power Platform objekt
Rensa Power Platform objekten

Det finns olika sätt att exportera appar och flöden för att flytta dem till en ny miljö. Lösningar är en enskild fil som kan innehålla i stort sett allt som utvecklarna bygger i Power Platform och flyttar samman. Arbetsyteappar och molnflöden kan exporteras direkt.

Med tiden har Power Platform objekten har utvecklats till att vara lösningsmedveten. Appar och flöden kan nu lösningsmedveten som standard, men detta kräver manuell aktivering. Utvecklarna kan fortfarande skapa appar och flöden från make.powerapps.com och make.powerautomate.com, som kan exporteras enskilt eller läggas till i en lösning. Genom att lägga till en lösning kan tillverkaren utnyttja miljövariabler och anslutningsreferenser för att konfigurera och distribuera slutpunkter över miljöer.

Målet är att alla Power Platform-komponenter ska läggas till i en enda lösning, vilket gör att flera komponenter enkelt kan flyttas som en enskild enhet mellan miljöer.

Identifiering av Power Platform objekten

Det första steget är att identifiera appar och flöden och tillgångar som behöver flyttas över eller tas över. CoE-startpaket innehåller ett lager av alla appar och flöden och Power BI-rapporter hjälper dig att avgöra hur användningen fungerar. Det här steget hjälper dig att utvärdera appanvändningen och bör hjälpa till att ange etiketter för dem. Var noga med att tagga appar och flöden som ska migreras till en annan miljö när du går igenom övningen. En tagg kan grundas på de anslutningsprogram som används, användarplats, användaravdelning och så vidare. I den här artikeln beskrivs också en metod för att identifiera objekt som bör användas för att förhindra eller omplaceras baserat på dataförlustskydd (DLP).

Flytta Power Platform objekt

Om komponenten har taggats så att den flyttas till en annan miljö finns det alternativ för att flytta appen. En åtgärd är en interaktiv process och kräver interaktion på en viss nivå. Komplexitetsnivån för att flytta en app eller ett flöde ökar med mixen av komponenter som används för att bygga appen eller flödet.

En app med sex skärmar har till exempel 10 knappar via flera skärmar. Vi antar att var och en av de tio knapparna anropar ett enskilt flöde. Det finns också ett par flöden som dagligen utlöses för att åtgärda data eller integrera data med ett annat system. Anta också att det finns en AI Builder bildbearbetningsmodell som används som en del av automatiseringen. För att flytta en sådan app måste alla komponenter läggas till i en lösning och anslutningsreferenserna måste justeras korrekt och testas ut innan de bekräfta att de har slutförts.

I ett annat fall bör du anta att det finns en arbetsyteapp som använder en Office 365-anslutning. I det här fallet behöver tillverkaren bara lägga till arbetsyteapp och lösningen.

Rensa Power Platform objekten

Om en komponent har taggats för rensning finns det två huvudalternativ. Det första alternativet är att ta bort den direkt och det andra alternativet är att ta bort den efter att ha tagit en säkerhetskopia. När säkerhetskopieringen gäller kan det finnas en del överlappande steg som rör sig mot flyttande objekt.

Som ett exempel upptäcker CoE-teamadministratörer att de flesta utvecklare skapar testappar och flöden för utbildningssyften. Skaparna avstår sedan från apparna och flödena, vilket kan bekräftas genom att titta på användningsstatistik. Ett annat sätt är att sätta en app i karantän. Om ingen tar sig an dig om appen kan du också ta bort appen.

Att upprätthålla en kommunikationsstrategi är en viktig roll. Administratörerna bör planera att kommunicera med:

Upprätta anslutningar som utvecklare måste tillåta när de startar appen i den nya miljön.
Den nya URL till appen från målmiljön.
Navigera till rätt miljö.

Vissa av dessa lösningar för att flytta objekt är färdiga och kan kräva en fristående Power Apps och Power Automate-licens som ger användarna möjlighet att skapa och köra appar över datakällor som sträcker sig längre än Microsoft 365.

Strategier

Det är troligare att hela processen med att identifiera och flytta appar och flöden från standardmiljön lyckas om den bygger på en strategi. Du bör överväga flera olika metoder.

DLP-strategi

DLP-policyer (dataförlustskydd) fungerar som skyddsmekanismer för att förhindra att användare oavsiktligt exponerar organisationsdata och skyddar informationssäkerheten i klientorganisationen. DLP-policyer tvingar fram regler för vilka anslutningsprogram som aktiveras för respektive miljö samt vilka kopplingar som kan användas tillsammans. Anslutningsprogram klassificeras antingen som endast affärsdata, inga affärsdata tillåtna eller blockerade. Ett anslutningsprogram i gruppen för endast affärsdata kan endast användas med andra anslutningsprogram från den gruppen i samma program eller flöde. Vi rekommenderar att du har minst en policy.

Identifiering av objekt med DLP

DLP-policybaserade identifierade kan vara till hjälp när du definierar målmiljöer för dina appar och flöden. Det kan finnas appar eller flöden som använder en anslutning som blockeras av DLP eller en blandning av affärs- och icke-affärsanslutningar, som efter DLP-aktivering slutar fungera.

För att förhindra driftstopp för potentiella kritiska objekt, på grund av DLP, en del av CoE-startpaket kan du hitta DLP-redigeringsverktyg (konsekvensanalys). Målet med DLP-redigeraren är att administratörer ska kunna se påverkan av befintliga principer eller den potentiella påverkan av policyändringar. Administratörerna får en vy över påverkade appar och flöden samt resurser som skulle inaktiveras om nya eller uppdaterade principer skulle tillämpas. Appen kan användas för att granska befintliga principer, ändra befintliga principer och minska riskerna genom att kontakta utvecklare och informera dem om den bästa åtgärden för deras app eller flöde.

Uppdatera befintliga DLP-principer för att granska påverkan. Följ artikeln Om att upprätta en klientorganisation med CoE-startpaket om du vill ha mer information om DLP-redigeraren.

Innan du slår på DLP-funktionen kan du identifiera vilka appar och flöden som påverkas och varna skaparna. DLP-redigeraren kan skicka en lista över alla appar och flöden som påverkas till en e-postadress, som genererar en .cvs-fil för varje typ av objekt.

Med hjälp av DLP-redigeraren version 2.0, i området konsekvensanalys, välj Exportera påverkade appar och flöden i CSV.

Använd DLP-redigeraren version 2.0.

Varje genererad csv-fil (flow.csv och apps.csv) innehåller information om:

Namn på apparna och flödena.
Ägare av apparna och flödena.
OwnerEmail av apparna och flödena.
Alla anslutningar som används av apparna och flödena.
ID för apparna och flödena för att identifiera objektet.
Miljö-ID där apparna och flödena finns.

Observera att Anslutningar innehåller en lista över alla anslutningar som appen eller flödet använder. Om du behöver identifiera exakt vilken anslutningsprogram som påverkas av den här DLP behövs en automatisering för detta tillfälle. Vi utvärderar hur situationen i verktyget ändras.

Exempel på implementering för att identifiera anslutningen:

Skapa ett Power Automate-flöde.
Använd anslutningsprogram Hämta en DLP-policy för klientorganisationen som anger DLP i fråga..

Resultatet är två matriser, affärsdata och data som inte är affärsdata. Som ett exempel visar Twitter anslutningsprogram den här koden:

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

I den här listan har du åtkomst till namnet på anslutningsprogrammet som överensstämmer med namnlistan för csv-appen eller flödet i kolumnen anslutning.
Genom att konvertera csv till Excel-format och placera det i din OneDrive kan du läsa alla påverkade appar och flöden från Power Automate. Kontrollera vilken anslutning som påverkas av logik som jämför anslutningar med anslutningsnamn.
När du har en matchning på vilken anslutning som orsakar påverkan genererar du en ny lista med appen eller flödes-ID:t och den anslutning som påverkas av DLP.
Använd den tidigare informationen om du vill meddela tillverkaren om den framtida påverkan. Du kan använda Power Cards för att samla in feedback från utvecklaren om appen eller flödet kan tas bort eller behöver migreras till en annan miljö.

Baserat på din analys, om du fastställer att de påverkade flödena inte används, kan du sätta dem i karantän och skicka ett e-postmeddelande till utvecklaren med instruktioner om hur du flyttar dem till en annan miljö. Detta gör att du kan göra det själv (DIY) och ta bort skugg-IT. I vissa situationer kanske du vill undanta vissa objekt från DLP. Du kanske t.ex. endast vill tillämpa en särskild DLP för nya resurser som har skapats och undanta de aktuella resurserna. För mer information om undantag från DLP-resurser, se Undantag från DLP-resurser.

Din miljöstrategi definieras effektivt med hjälp av DLP och som är en destination för de appar och flöden som utvecklats i standardmiljön.

Miljöstrategi

Utveckling av en miljöstrategi kräver att konfigurera miljöer och andra lager av datasäkerhet på ett sätt som stöder produktiv utveckling i organisationen, samtidigt som du säkrar och organiserar resurser. En strategi för att hantera miljöetableringen, åtkomsthantering och kontroll av resurser inom dem är viktigt för:

Skydda data och åtkomst.
Styr standardmiljön på ett kompatibelt sätt.
Hantera rätt antal miljöer för att undvika tillväxt och bevara kapacitet.
Underlätta och implementera en felfri programlivscykelhantering (ALM).
Ordna resurser i logiska partitioner.
Stödja åtgärder (och supportavdelning) för att identifiera program som är i produktion genom att använda dem i särskilda miljöer.
Säkerställa att data lagras och överförs i godkända geografiska regioner (av effektivitets- och kvalitetsskäl).
Säkerställa isolering av program som utvecklas.
Interna faktureringstjänster kan aktiveras för slutanvändare eller affärsenheter som använder tjänsterna.

Du bör ha väletablerade avdelningar som kan självbetjäna och som har befintliga ALM-processer på plats. I sådana fall är miljön isolerad och resurserna ordnas utifrån avdelningen. En strategi som bygger på detta genom att skapa separata miljöer för varje avdelning. Dessa miljöer blir sedan destination för apparna och flödena i standardmiljön.

Kommunikationskategori

Effektiv kommunikation är mycket viktig under en migreringsprocess. Kommunikation sker över alla faser i migreringsprocessen. Tydlig kommunikation och förståelse och samarbete mellan intressenter. Det ger ett smidigt informationsflöde och garanterar att alla inblandade är välinformerade om migreringsplanerna, förloppet och eventuella utmaningar.

Som en del av migreringen och rensningen bör du se till att processen är smidig för utvecklare, intressenter och ledning. Utveckla en strategi för hur du bäst kommunicerar och på vilka punkter du behöver kommunicera, som ger enhetlighet i målen och underlättar kommunikationen för alla inblandade. Några alternativ att tänka på:

Använd CoE-startpaket som tillgångslåda.
Lägg till anpassade molnflöden för att skicka meddelanden i olika stadier.
Skapa mall-e-postmeddelanden som skickas ut för att kommunicera med utvecklare.

Saker att tänka på:

Ändra appens URL. Användare av appen måste uppdatera eventuella bokmärken till en app i standardmiljön.
Om det finns ett URL-baserat HTTP-utlösarflöde som måste uppdateras i beroende flöden för att säkerställa att det fortfarande fungerar som en webhook.
Tillhandahåll detaljerade steg för att upprätta anslutningar när steget är klart för både utvecklare och appanvändare. Användarna ska inte bekymra sig om hur de skapar en anslutning när de startar appen för första gången från den nya miljön.

En bra start för att konfigurera kommunikation kräver en självbetjäningsmodell för att kunna skala och vara mer i realtid för användare än att bara lämna den för en enskild användares e-post eller en distributionslista. Om du planerar att upprätta en SharePoint-webbplats finns det en mall som du kan använda för att skapa ett internt Microsoft Power Platform-nav. Navet blir den vanliga platsen där du lär dig mer om strategi och vägledning, så att utvecklarna måste fatta rätt beslut om vad de tänkt bygga och var de ska gå för det.

Det finns vissa befintliga lösningskomponenter konfigurera komponenter för inaktivitetsmeddelanden och konfigurera komponenter för utvecklarefterlevnad i CoE-startpaket som du kan dra nytta av. Komponenterna har e-postmallar och kan dupliceras så att de passar dina behov och behov av att migrera dem från standardmiljön. Ett bra tillägg är också att ta till vara på några framgångar på kommunikationsplatsen.

Målgrupper

I migrationsprocessen är det vanligtvis olika målgrupper involverade i kommunikation. Här är de mest typiska viktiga intressenter och deras roller:

Appägare: Appägare är personer eller team som ansvarar för utveckling, underhåll och hantering av specifika program. De har ingående kunskaper om funktionerna, arbetsflödet och konfigurationen av programmen. Kommunikation med appägare är mycket viktigt för att förstå deras appspecifika krav, samla in feedback, åtgärda problem och säkerställa en smidig migrering av apparna till den nya miljön.
Appanvändare: Appanvändare är de personer som använder applikationerna regelbundet för att utföra sina uppgifter eller arbetsflöden. De kan ha olika tekniska expertområden och erfarenhet av programmen. Kommunikation med appanvändare är viktigt att informera dem om migreringen, ge uppdateringar om eventuella ändringar eller avbrott, erbjuda utbildning eller support för att säkerställa en smidig övergång och minimera påverkan på den dagliga verksamheten.
Avdelningschefer eller chefer: Avdelningschefer eller chefer spelar en viktig roll i migreringsprocessen eftersom de övervakar verksamheten och de strategiska målen för sina respektive avdelningar. De måste informeras om tidslinjen för migreringen, potentiella effekter och fördelar. Kommunikationen med avdelningen ger nödvändig vägledning, anpassar migreringen efter avdelningsmål och säkerställer en smidig koordinering i teamen.
IT- eller tekniska team: IT- eller tekniska team ansvarar för infrastrukturen, systemen och de övergripande tekniska aspekterna av migreringen. De deltar i planeringen, utförandet och supporten av migreringsprocessen. Kommunikation med IT-team är nödvändigt för att diskutera tekniska krav, beroenden, säkerhetsaspekter och eventuella nödvändiga infrastruktur- eller konfigurationsändringar som behöver implementeras för att migreringen ska lyckas.
Säkerhets- och efterlevnadsteam: Säkerhets- och efterlevnadsteam spelar en viktig roll för att säkerställa datasäkerhet, sekretess och regelefterlevnad under migreringen. De ger vägledning och säkerställer att det finns lämpliga åtgärder för att skydda känslig information. Kommunikation med säkerhets- och regelefterlevnadsteam omfattar säkerhetskrav, krypteringsprotokoll, åtkomstkontroller och eventuella regelefterlevnadsrelaterade saker under hela migreringsprocessen.
Verkställande ledning: Verkställande ledningen, inklusive chefer på C-nivå eller högsta ledningen, bör hållas informerade om migreringsprocessen. De kanske inte behöver detaljerad, teknisk information, men de bör känna till projektets mål, förlopp och potentiella effekter på organisationen. Kommunikation med den verkställande ledning bidrar till att säkerställa support, anpassning till de strategisk målen och resursallokeringen för migreringen.

Det är viktigt att skräddarsy kommunikationsstrategier och budskap för varje målgrupp, med hänsyn till deras specifika behov, problem och nivå av teknisk förståelse. Tydlig kommunikation med alla intressenter vid rätt tidpunkt, säkerställer smidig koordinering och minskar eventuella problem under migreringsprocessen.

Sekvens

Kommunikationen med intressenterna under en migreringsprocess varierar beroende på projektets specifika behov och dynamiskhet. Det är viktigt att kommunicera regelbundet och konsekvent för att hålla intressenterna informerade, åtgärda problemen och upprätthålla anpassningen under hela migreringen. Här är några saker du bör tänka på när du ska bestämma hur kommunikationen med olika intressenter ska se ut:

Appägare: Det är viktigt att upprätthålla frekvent kommunikation med appägare under hela migreringsprocessen. Här finns regelbundna uppdateringar om migreringens utveckling, information om eventuella problem som kan behövas och där appägarna är med och fattar beslut om det behövs. Kommunikationsfrekvensen kan variera beroende på appens komplexitet och kriticitet, men vi rekommenderar att du gör regelbundna kontroller och får svar på frågor vid rätt tidpunkt.
Appanvändare: Engagera appanvändare via regelbundna kommunikationskanaler för att hålla dem informerade om migreringen. Detta bör omfatta meddelanden, e-postmeddelanden, nyhetsbrev eller till och med dedikerade utbildningssessioner eller workshops. Hur ofta de kommunicerar med appanvändarna kan variera, men det är viktigt att tillhandahålla uppdateringar vid viktiga milstolpar, informera dem om eventuella förändringar eller avbrott som kan påverka dem och ge support och vägledning genom hela processen.
Avdelningschefer och chefer: Kommunikation med avdelningschefer och chefer kan ske med jämna mellanrum eller vid behov, baserat på migrationens betydelse för deras avdelningar. Ge regelbundna uppdateringar om förloppet, tidslinjerna och påverkan på deras team.
IT- eller tekniska team: Kommunicera regelbundet med IT- och tekniska team som är involverade i migreringen. Detta omfattar kontinuerligt samarbete, delning av uppdateringar om tekniska frågor och problem, samt nödvändiga konfigurationer och ändringar. Kommunikationsfrekvensen är oftast högre i planerings- och analysfasen. Under implementeringsfasen kan du ha regelbundna pekpunkter eller möten för att säkerställa en smidig koordinering.

Resurser

Att hantera resurser på ett effektivt sätt är en förutsättning för en lyckad migrering. Här är några viktiga aspekter att tänka på när det gäller hantering av information under en migrering:

Resursidentifiering: Identifiera de resurser som krävs för migreringsprojektet, inklusive individer eller team som ansvarar för uppgifter som förberedelser före migreringen, datamigrering, testning, distribution, konfiguration och support efter migreringen. Bestäm vilka färdigheter, expertområden och tillgänglighet som behövs för varje roll.
Resursfördelning: Tilldela resurser till roller och uppgifter baserat på resursens färdigheter, tillgänglighet och arbetsbelastningskapacitet. Se till att resurser anslås för att fördela arbetsbelastningen på ett balanserat sätt och uppfylla projektets deadlines. Tänk på beroenden eller begränsningar som kan påverka resurstilldelning, till exempel delade resurser för flera projekt.
Utveckling och utbildning av färdigheter: Bedöm färdigheter och kunskapsluckor inom teamet och tillhandahåll nödvändiga utbildnings- eller kompetenshöjningsmöjligheter för att säkerställa att resurserna är tillräckligt utrustade för sina tilldelade uppgifter. Det kan handla om utbildningssessioner, workshops eller tillgång till relevanta resurser och dokumentation.
Kommunikation och samarbete: Främja effektiv kommunikation och samarbete mellan resurser som är involverade i migreringen. Uppmuntra till regelbundna statusuppdateringar, koordineringsmöten och kunskapsdelning för att se till att alla teammedlemmar är anpassade, informerade och arbetar tillsammans mot gemensamma mål.
Beredskapsplanering: Förutse potentiella resursbegränsningar eller risker och utveckla beredskapsplaner. Identifiera säkerhetskopieringsresurser eller utbilda dem i viktiga roller för att hantera eventuella utmaningar som kan behövas, till exempel oväntade frånvaro eller resursbegränsningar.
Intressentengagemang: Håll intressenter, t.ex. appägare, avdelningschefer och ledning, informerade om resursfördelning och eventuell inverkan på tidslinjer eller leveranser. Kommunicera regelbundet resursuppdateringar, förloppsrapporter och eventuella anpassningar av resurstilldelningsplaneringen för att hantera förväntningarna och underhålla dess resultat.

Enskild migrering av objekt

Skillnaden mellan app och lösning är viktig. Exportera och importera en app påverkar bara det objektet. En lösning är en behållare som kan ha flera appar, flöden och andra objekt.

Exportera och importera en arbetsyteapp (äldre sätt)

De detaljerade stegen dokumenteras i Export av ett paket med arbetsyteapp och Import av ett paket med arbetsyteapp

Den här metoden för att exportera appar är ett tidigare sätt. Medan det stöds rekommenderar vi att du använder lösningar. Med hjälp av lösningar kan du migrera flera komponenter i stället för bara en resurs.

Exportera och importera flöde (tidigare sätt)

I följande steg beskrivs hur du exporterar ett flöde.

Välj "…" meny, välj Exportera och välj sedan Paket (.zip).
Ange ett namn och en beskrivning för ditt paket. Sedan kan du konfigurera standardinställningarna och lägga till kommentarer som är tillgängliga under importfasen.
Välj knappen Exportera längst ned i högra hörnet för att ladda ned paketet. Om hämtningen inte startar automatiskt kan du välja knappen Hämta.

I följande steg beskrivs hur du importerar ett flöde.

Klicka på knappen Importera.
Överför paketfilen och vänta tills skärmen visar paketinformationen.
När du konfigurerar flödesinställningarna kan du välja att antingen skapa ett nytt flöde eller uppdatera ett befintligt flöde med flödesdefinitionen från paketet.
Välj de anslutningar som krävs för att konfigurera flödet. Du bör se att knappen Importera när du har konfigurerat alla nödvändiga inställningar.

När du har importerat flödet måste det aktiveras. Om flödet har anslutningsreferenser måste användaren som aktiverar det ha åtkomst till dessa anslutningar. Om det inte gör det kan anslutningsägaren ge åtkomst till aktiveringsanvändaren.

Den här metoden för att exportera molnflöden är ett tidigare sätt. Vi rekommenderar att du använder lösningar som gör att du kan migrera flera komponenter i stället för en resurs.

Exportera och importera en modellbaserad app

En modellbaserad app ingår alltid i en lösning. Den paketerade appen, som ingår i lösningsfilen (.zip), kan delas med användare baserat på deras säkerhetsroller när den har exporterats från källmiljön och importerats till målmiljön.

De detaljerade steg-för-steg-processerna täcks in Exportera en lösning och Importera en lösning.

Exportera och importera Microsoft Copilot Studio-robotar

Du kan exportera och importera bots med hjälp av lösningar. En detaljerad lista med steg beskrivs i Export och import av lösningar.

Exportera och importera Power Pages-webbplats

Migreringssidor involverar att exportera den befintliga konfigurationen från Microsoft Dataverse-källmiljön och sedan importera den till Dataverse-målmiljön. Det finns några nödvändiga steg som måste utföras i målmiljön. När förberedelsearbetet är klart kan portalkonfigurationsdata exporteras med hjälp av Configuration Migration Tool.

SharePoint Formulärapp – specialfall för standardmiljö

SharePoint Formulärappar kan bara associeras med en miljö, och om de inte konfigureras på annat sätt finns de i standardmiljön. Om alla appar ska migreras måste destinationen vara en annan miljö i stället för standardmiljön. Befintliga anpassade formulär migreras inte automatiskt till den nya miljön. Det går endast att ange produktionsmiljöer för SharePoint anpassade formulär. Den manuella processen fungerar som att flytta en arbetsyteapp.

Säkerhetskopiera Microsoft Power Platform-objekt

De flesta Microsoft Power Platform objekt exporteras som zip-filer. I annat fall har de minst ett filformat. Dessa filer i originalformat, som zip-filer eller med andra tillägg, kan läggas till i valfri fillagringsplats eller en förvaringsplats som du väljer. Ett par alternativ att tala om Azure DevOps, GitHub, SharePoint, One Drive, eller någon annan lösning som stöder alla filformat.

Massmigreringsalternativ

Migreringen av en app eller ett flöde lyckas om den fungerar på samma sätt som den gjorde tidigare. Det finns emellertid vissa element som inte kan överföras:

Flödeskörningsdata om tidigare körningar av flödet – Data om flödeskörningar lagras endast i 28 dagar. Om du behöver dina data kan du exportera dem och lagra dem med hjälp av CoE-startpaket eller om du har ställt in export till datasjö. Den senaste versionen av CoE-startpaket har flödeskörningsdata som används vid dataexport.
Versioner av arbetsyteappen - När tillverkarna itererar genom utvecklingsprocessen kan det Dit skapas flera versioner. De tidigare versionerna kan inte migreras. Endast den senaste versionen kan migreras.
Data som används av appen eller flödet eller med hjälp av anslutningsprogram – Endast appmetadata ingår som en del av exporten.

Samarbetskommentarer som görs i appen eller i flödet ingår inte heller.

I den här artikeln beskrivs några möjligheter. Det är viktigt att tänka på vad varje möjlighet har för effekter och fördelar innan du bestämmer dig.

Migrera alla – alternativet för säkerhetskopiering och återställning av databaser

På samma sätt som för de flesta miljötyper fungerar standardmiljön också. Säkerhetskopieringarna utförs automatiskt. Det finns inget alternativ på begäran för standardmiljön, så det krävs en supportbegäran. Säkerhetskopieringen kan återställas till en ny miljö och behålla all data i Dataverse. Det här alternativet är endast till för att visa läsaren om dess existens och utbilda läsaren om när man bör överväga. Det bör inte ses som det primära valet eftersom det bara skulle ge en delmigrering.

Stöds:, Dynamics-appar Dataverse
Stöds inte fullt ut: Arbetsyteapp, komponentbibliotek, anpassade sidor, Power Automate, Microsoft Copilot Studio

Stöds inte fullt ut indikerar att det kan finnas potentiell dataförlust under migreringen och att fler steg krävs.

Migrera metadata och sedan data

Vi rekommenderar att du använder lösningar för att flytta metadata och sedan använda antingen dataflöden, Azure Data Factory eller något annat verktyg som du föredrar för att överföra data. Fullständig automatisering från början till slut kanske inte är möjlig i alla fall på grund av de olika anslutningsprogram, men det är möjligt att stänga anslutningar.

På en hög nivå är stegen:

Lägga till en app i en lösning.
Lägg till flöde i en lösning.
Lägga till befintliga robotar.
Justera anslutningsreferenser i appar och flöden.
Kontrollera om det finns lösningsberoenden och lägg till objekt.
Exportera lösningen
Importera lösningen.
Överför data.

Kontrollerar för lösningsberoenden

En lyckad lösningsimport i målmiljön kan endast säkerställas om du har lagt till alla relaterade komponenter i lösningen eller om de är tillgängliga i målmiljön. Om komponenter saknas kommer importen av lösningen troligen att misslyckas. För att säkerställa att alla nödvändiga komponenter finns med finns det alternativ som bäst kan användas tillsammans:

Lägg manuellt till valda komponenter till lösningen. I det här fallet beror det på att du vet att alla beroende komponenter redan är tillgängliga i målmiljön.
Använd knappen Visa beroenden inifrån lösningen om du vill låta systemet identifiera beroenden åt dig. Du kan lägga till alla beroenden eller endast lägga till beroenden som inte finns i målmiljön.

Lägg till en komponent till en lösning (manuell)

Om en lösning skapas behöver en tillverkare använda det befintliga komponentmenyalternativet för att lägga till en befintlig app, ett flöde eller en robot.

Bild som visar hur du lägger till befintliga komponenter i en lösning.

Justera anslutningsreferenser

Arbetsyteappar och flöden hanterar anslutningar på ett annat sätt. Flöden använder anslutningsreferenser för alla anslutningar, medan arbetsyteappar endast använder dem för implicit delade (icke-)OAuth anslutningar, till exempel SQL Server autentisering.

Uppdatera en app så att anslutningsreferenser används i stället för anslutningar

Arbetsyteappar som inte är lösningsmedvetna när de läggs till i en lösning uppgraderas inte automatiskt för att använda anslutningsreferenser. Anslutningsreferenser associeras endast med arbetsyteappar när en datakälla läggs till i programmet. Om du vill uppgradera appar måste du:

Lägg till en app som inte är lösningsmedveten i en lösning.
Ta bort anslutningen från appen.
Skapa en ny anslutningsreferens i lösningen.
Lägga till en anslutning som innehåller en associerad anslutningsreferens.

Uppdatera ett flöde så att anslutningsreferenser används i stället för anslutningar

När ett flöde inte finns i en lösning används anslutningarna. Om det flödet sedan läggs till i lösningen fortsätter det att använda anslutningarna intialt. Det går att uppdatera flöden genom att använda anslutningsreferenser i stället för anslutningar på ett av två sätt:

Om flödet exporteras i en ohanterad lösning och importeras tas anslutningarna bort med anslutningsreferenser.
När ett lösningsflöde öppnas kommer flödeskontrollen på flödesinformationssidan att visa en varning till Använd anslutningsreferenser. Varningsmeddelandet innehåller en åtgärd som du kan välja för att Ta bort anslutningar så att anslutningsreferenser kan läggas till. Om du väljer den åtgärden tas anslutningarna bort från utlösaren och åtgärderna i flödet och gör att anslutningsreferenser kan markeras och skapas.

Lägga till ett objekt i en lösning (automatisering)

Du kan använda PowerShell-kommandon för att flytta appar samtidigt till en lösning. Det går också att lägga till befintliga molnappar och molnflöden i lösningar via kommandoraden. Prova det här alternativet genom att installera de senaste PowerShell-modulerna. De två huvudkommandona är Set-PowerAppAsSolutionAware och Set-FlowAsSolutionAware.

När modulerna har installerats sätter du in ditt eget miljö-ID, app-ID, flödes-ID och lösnings-ID.

För en arbetsyteapp:

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

För ett flöde:

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

Anslutningsreferenser är datainmatningar i tabellen med anslutningsreferenser. För att anslutningsreferensen ska kunna användas som en del av appen eller flödet måste viktigaste appen eller flödesdefinitionen ändras. Du måste byta ut noden connectionReferences med anslutningsreferensen.

Importera och exportera en lösning

Om lösningarna är klara kan nästa automatiseringsstadium göras på flera sätt:

Exportera och importera lösningarna manuellt till målmiljön.
Med paket kan du flytta flera lösningar i en enda passering.
Använd Power Platform uppgifter för byggverktyg om du vill utföra flera åtgärder, till exempel paketlösning, packa upp lösning, exportera lösning och importera lösning. DevOps ger möjlighet att automatisera hantering av programmets livscykel (ALM) och dessa uppgifter är alla skapade för ge stöd till ALM för Microsoft Power Platform.

I Power Platform kommandoradsgränssnittet (CLI) finns även alternativ för export och import av lösningar. Alla lösningsrelaterade kommandon kan användas för att skapa, exportera och importera lösningar. Du kan också använda CLI för att överföra data in och ut.

Ett utvecklarvänligt alternativ är att använda pipelines som är avsedda att demokratisera ALM för Power Platform. Att samla ALM-automatisering och kontinuerlig integrering/kontinuerlig distribution (CI/CD) i en enda funktionstjänst är mer lättillgängligt för alla tillverkare, administratörer och utvecklare.

Skapa anslutningar (manuell)

Skapa de anslutningar som saknas för appen eller flödet i målmiljön innan importen har angetts. För mer information om hur du skapar anslutningar, se Hantera anslutningar i Power Automate.

Datamigrering

Det finns flera alternativ för datamigrering, allt från manuell till fullständig automatisering.

Exportera och importera data manuellt med hjälp av Excel-arbetsböcker.
Ett Power Automate molnflöde kan utvecklas för att extrahera data från källtabeller och skriva direkt till destinationen. Detta kräver dock att tillverkaren använder Dynamics 365 Connector eller Dataverse (äldre) anslutningsprogram. För närvarande stöder Dataverse anslutningsprogram inte anslutning mellan miljöer. Den här funktionen är planerad för framtiden och när den har getts ut kan den användas för att flytta data från en till en annan.
Configuration Migration Tool (CMT) är ett verktyg som används för portalmigrering, men kan också användas för vanlig datamigrering. CMT kan också användas med PowerShell. Med PAC CLI-verktyget kan du anropa CMT.
Dataflöden kan användas för att skapa mappningar mellan miljöerna och användas för att flytta data. HTTP-webbanslutning kan användas som ett alternativ till Dataverse.
Azure Data Factory kan användas med Dataverse anslutningsprogram för att hämta data från källan och infoga dem i destinationen.

Eftersom standardmiljön är begränsad till sin storlek bör ett av alternativen ovan räcka för att flytta data från standardmiljön.

Rensa överväganden

En rensning är en bra idé för appar och flöden som inte har använts och uppdaterats på länge. Det finns olika sökvägar som en administratör kan ta hänsyn till när det gäller rensning.

Bestämma i vilken ordning data ska importeras. De minst beroende tabellerna är först och de mest beroende kommer till slutet.
Alla fält behöver inte mappas. Fält som Version, Ändrat datum, Skapad datum och vissa andra systemfält behöver inte mappas.
Om du vill bevara det ursprungliga Skapad den, använd sedan mappa källfältet Skapad den till fältet OverRiddenCreatedOn i måltabellen.
Det går inte att migrera granskningsdata.
Aktivera inga arbetsflöden eller flöden som utlöses baserat på infogning av data, såvida de inte är avsedda. Detta ökar tiden för datamigrering.

Taggningsalternativ

CoE-startpaket har inget taggningsalternativ i dag. Det kan dock vara en anpassning som du kan lägga till i startpaketet.

Skapa en tabell med namnet Taggar och konfigurera en många till många-relation (N:N) med appen, flödena och andra lagertabeller. Sedan kan du skapa en tagg och associera posterna med rätt lagerobjekt. För en bättre användarupplevelse kan du inbädda ett rutnät i huvudformuläret för appar, flöden och andra lagertabeller. Det här alternativet rekommenderas eftersom det har refererande enhetlighet.

Skapa ett textfält i varje lagertabell och använd det för att samla in texten (taggen) som du kan använda senare.

Om du vill ha en fastare lista skapar du en global alternativuppsättning lägger till den i alla lagertabeller och deras formulär.

Alternativ för karantän

Om du känner dig osäker på om vissa program kan du försöka isolera dem en stund och sätta dem i karantän under den här tiden. Appen kan bara användas av ägaren. Efter att en lämplig tid har förflutit och om inget svar från ägaren har inkommit kan du ta bort dem från miljön.

Flöden stöder inte tillståndet för flöden, men en liknande metod kan användas genom att stoppa flödet och kontrollera om det aktiveras igen av ägaren.

I båda fallen är det viktigt att kommunicera med ägaren.

Ta endast bort alternativ

Om det egentligen inte går att förlora produktiviteten och återanvända objekten är det här alternativet det bästa. De flesta testflöden och appar tillhör den här kategorin.

I det här fallet kan en PowerShell-grupp utvecklas så snart objektlistan har identifierats, och en csv-lista skickas till den, som sedan skulle ta bort alla dessa tillgångar.

När du loopar genom ID för appar och flöden kan följande kommando användas för att ta bort dem från standardmiljön.

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

Alternativet Säkerhetskopiera och ta bort objekt

Anta till exempel att ett Power Automate flöde skapas för att hantera ett specifikt behov, men att det inte har använts på länge. I det här fallet kan du göra en säkerhetskopia av komponenten innan du tar bort komponenten.

För att göra en säkerhetskopia av komponenten kan antingen alternativ för enskild migrering eller massmigrering användas för att skapa en exporterad lösning. Detta kan sedan läggas till antingen i en valfri fildatabas eller på en OneDrive plats.

När säkerhetskopian är säker kan du utföra rensningen genom att använda alternativet Ta bort.

I många fall är det testflöden och appar som skapas av beslutsfattare som en del i den personliga produktivitetsundervisningen och experimentet.

Slutsats

Power Platform är ett verktyg för civila utvecklare och professionella utvecklare. Standardmiljöns användning bör i första hand vara inriktad på personlig produktivitet med hjälp av Microsoft 365 produkter. Alla andra appar och flödesutveckling ska ske i angivna delade, enskilda miljöer eller utvecklingsmiljöer. En god rekommendation är att ta fram en oberoende miljöstrategi baserad på DLP, som kan hjälpa utvecklare att utveckla sina appar och flöden i rätt miljö. Det finns också en stor nytta av att fastställa en kommunikationsstrategi och ge användarna självbetjäningsmodeller för att lära sig om strategin, implementeringen av lösningar och metodtips för att utveckla appar och flöden. Ett bra tillägg är också att ta till vara på några framgångar på kommunikationsplatsen. Framgångsartiklar som publicerats internt hjälper utvecklarna att komma i kontakt med idéer och gör dem öppna för möjligheter som kan uppnås med hjälp av Power Platform.

Det är viktigt att ha en kraftfull strategi när du migrerar eller flyttar specifika objekt. Det finns olika sätt att migrera objekt, till exempel enskild migrering och massmigrering. Vilket alternativ som passar bäst beror på våra organisationspolicyer. Lösningar är det mest rekommenderade sättet att ordna komponenterna i programmet och göra migreringarna mer enkla.

Dela via