Migrar aplicacions i fluxos des de l'entorn per defecte

Aquest llibre blanc explica com les organitzacions i els administradors poden planificar la migració de les seves aplicacions i fluxos des de l'entorn per defecte.

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

Nota

Podeu desar o imprimir aquest llibre blanc seleccionant Imprimeix des del navegador i, a continuació, seleccionant Desa com a PDF.

Entorn predeterminat

Es crea un entorn per defecte per inquilí i és accessible per a tots els usuaris d'aquest inquilí. L'entorn per defecte es crea a la regió més propera a la regió per defecte de l'inquilí Microsoft Entra i s'anomena de la manera següent: [Microsoft Entra nom de l'inquilí] (per defecte). Cada vegada que un usuari nou es registra o Power Apps Power Automate s'afegeix automàticament a la funció Creador de l'entorn per defecte. No s'afegeix automàticament cap usuari a la funció administrador de l'entorn de l'entorn per defecte.

No podeu suprimir l'entorn per defecte i no podeu fer còpies de seguretat manuals de l'entorn per defecte. Les còpies de seguretat del sistema es fan contínuament. L'entorn per defecte està limitat a 1 TB de capacitat d'emmagatzematge. L'entorn per defecte té les capacitats següents:

• 3 GB Dataverse de capacitat de base de dades
• 3 GB Dataverse de capacitat d'arxiu
• 1 GB Dataverse de capacitat de registre

La comprovació de capacitat realitzada abans de crear entorns nous, exclou la capacitat d'emmagatzematge inclosa de l'entorn per defecte quan calculeu si teniu prou capacitat per crear un entorn nou. Per emmagatzemar més dades, podeu crear un entorn de producció.

A l'entorn per defecte, els empleats d'una organització amb una Microsoft 365 llicència poden crear aplicacions i fluxos al núvol. L'entorn predeterminat es converteix en el primer estudi de jocs infantils perquè aquests empleats comencin a crear les seves aplicacions i fluxos. Com que no és possible suprimir la funció creador de l'entorn de l'entorn per defecte, els creadors comencen a crear aplicacions i fluxos de productivitat personal i a compartir-los dins dels seus equips perquè altres se'n beneficiïn. La majoria de les organitzacions sovint canvien el nom de l'entorn per defecte a Productivitat personal.

Els administradors descobreixen reactivament que moltes aplicacions i fluxos es creen a l'entorn per defecte. És possible que no sigui adequat que una aplicació o un flux estiguin a l'entorn per defecte en escenaris, com ara:

• Una aplicació es comparteix amb molts usuaris amb un comportament semblant al de producció.
• Una aplicació utilitza llibres de treball de l'Excel amb dades sensibles.
• Una aplicació, basada en SharePoint llistes, obté moltes interaccions de dades, com ara insercions o actualitzacions.
• Una aplicació o flux utilitza connectors que no estan permesos a les noves normes de prevenció de pèrdua de dades (DLP).
• Els connectors personalitzats s'habiliten i s'utilitzen a l'entorn per defecte, en lloc d'estar protegits en un entorn dedicat.

Val la pena tenir en compte els escenaris anteriors i proporcionar una indicació que hauríeu de començar a moure aquestes aplicacions i fluxos de l'entorn predeterminat al seu propi entorn de desenvolupador o un altre entorn compartit. Altres factors que entren en joc són les limitacions associades a l'entorn per defecte.

Els equips del Centre d'Excel·lència (CoE) que supervisen Power Platform es veuen obligats a reaccionar un cop assolits els límits, cosa que afecta negativament les aplicacions que s'executen a l'entorn predeterminat. Aquesta limitació pot ser una cosa que un administrador o l'equip de CoE també hagin de realitzar regularment. Hi ha tres grans etapes:

• Identificació dels Power Platform objectes
• Moure els Power Platform objectes
• Netejar els Power Platform objectes

Hi ha diferents maneres d'exportar les aplicacions i els fluxos per moure'ls a un entorn nou. Les solucions són un sol fitxer que pot incloure gairebé qualsevol cosa que els vostres creadors construeixin Power Platform i les moguin juntes. Les aplicacions de llenç i els fluxos al núvol es poden exportar directament.

Amb el temps, Power Platform els objectes han evolucionat per ser conscients de la solució. Ara les aplicacions i els fluxos poden ser conscients de la solució per defecte, tot i que això requereix una activació manual. Els creadors encara podrien crear aplicacions i fluxos de make.powerapps.com i make.powerautomate.com, que es poden classificar com a no compatibles amb la solució, i es poden exportar individualment o afegir-los a una solució. En afegir una solució, el creador pot aprofitar les variables d'entorn i les referències de connexió per configurar i implementar punts finals entre entorns.

L'objectiu és que tots els Power Platform components s'afegeixin a una única solució, cosa que permet moure fàcilment múltiples components com una sola unitat entre entorns.

Identificació dels Power Platform objectes

El primer pas és identificar aplicacions, fluxos i recursos que cal moure o netejar. El CoE Starter Kit proporciona un inventari de totes les aplicacions i fluxos, i els informes ajuden a determinar-ne l'ús Power BI . Aquest pas us ajuda a avaluar l'ús de l'aplicació i us ajudarà a etiquetar-les. A mesura que avanceu en l'exercici, assegureu-vos d'etiquetar les aplicacions i els fluxos que s'han de migrar a un altre entorn. Una etiqueta es pot basar en els connectors utilitzats, la ubicació de l'usuari, el departament d'usuaris, etc. Aquest article també descriu un mètode per reconèixer els elements que s'han de netejar o reubicar en funció de les pràctiques de prevenció de pèrdua de dades (DLP).

Moure els Power Platform objectes

Si el component està etiquetat per desplaçar-se a un altre entorn, hi ha opcions disponibles per moure l'aplicació. Un moviment és un procés interactiu i necessita un cert nivell d'interacció del fabricant. El nivell de complexitat per moure una aplicació o un flux augmenta amb la combinació de components utilitzats per crear l'aplicació o el flux.

Per exemple, una aplicació amb sis pantalles té 10 botons a través de diverses pantalles. Suposem que aquests 10 botons criden cadascun un flux individual. També hi ha un parell de fluxos que s'activen diàriament per arreglar dades o integrar dades amb un altre sistema. Suposem també que hi ha un AI Builder model de processament d'imatges que s'utilitza com a part de l'automatització. Per moure aquesta aplicació, tots els components s'han d'afegir a una solució i les referències de connexió s'han d'ajustar correctament i provar abans de confirmar la finalització.

En un altre cas, suposeu que hi ha una aplicació de llenç que utilitza una Office 365 connexió. En aquest cas, el creador només ha d'afegir l'aplicació del llenç a la solució.

Netejar els Power Platform objectes

Si un component està etiquetat per netejar-lo, hi ha dues opcions principals. La primera opció és eliminar-la directament i la segona opció és eliminar-la després de fer una còpia de seguretat. En aquest últim cas de còpia de seguretat, pot haver-hi alguna superposició de passos coincidents amb objectes en moviment.

Com a exemple, els administradors de CoE Team troben que la majoria dels creadors creen aplicacions i fluxos de prova amb finalitats d'aprenentatge. A continuació, els fabricants abandonen les aplicacions i els fluxos, cosa que es pot confirmar mirant les mètriques d'ús. Una altra manera és posar en quarantena una aplicació. Si ningú no se us acosta sobre l'aplicació, també es pot suprimir l'aplicació.

Mantenir una estratègia de comunicació juga un paper clau. Els administradors haurien de planificar comunicar-se:

• Establir connexions que els fabricants han de permetre a mesura que llancen l'aplicació en el nou entorn.
• El nou URL de l'aplicació des de l'entorn de destinació.
• Navegant a l'entorn adequat.

Algunes d'aquestes solucions per reubicar objectes estan preparades i poden requerir una llicència i Power Apps una llicència independents Power Automate que proporcionin als usuaris la capacitat de crear i executar aplicacions a través de fonts de dades que s'estenen més enllà Microsoft 365.

Estratègies

Tot el procés d'identificació i transferència d'aplicacions i fluxos de l'entorn predeterminat té més probabilitats de tenir èxit quan es basa en una estratègia. Hi ha múltiples estratègies que hauríeu de tenir en compte.

Estratègia DLP

Les polítiques de prevenció de pèrdua de dades (DLP) funcionen com a baranes de protecció per ajudar a evitar que els usuaris exposin involuntàriament dades organitzatives i per protegir la seguretat de la informació a l'inquilí. Les normes de DLP apliquen regles per als connectors que estan habilitats per a cada entorn i quins connectors es poden utilitzar conjuntament. Els connectors es classifiquen com a Només dades empresarials, No es permeten les dades empresarials o Bloquejats. Un connector del grup Només dades empresarials només es pot utilitzar amb altres connectors d'aquest grup a la mateixa aplicació o flux. Et recomanem que tinguis, com a mínim, una pòlissa.

Identificació d'objectes mitjançant DLP

La identificació basada en polítiques DLP és útil per definir entorns de destinació per a les vostres aplicacions i fluxos. És possible que hi hagi aplicacions o fluxos que utilitzin un connector bloquejat pel DLP o una combinació de connectors empresarials i no empresarials que, després de l'activació del DLP, deixin de funcionar.

Per evitar el temps d'inactivitat de possibles objectes crítics, a causa de DLP, part de CoE Starter Kit, podeu trobar l'eina d'editor DLP (anàlisi d'impacte). L'objectiu de l'editor DLP és permetre als administradors veure l'impacte de les polítiques existents o l'impacte potencial dels canvis en les polítiques. Proporciona als administradors una visió de les aplicacions i fluxos afectats, i recursos que es desactivarien si s'apliquessin polítiques noves o actualitzades. L'aplicació es pot utilitzar per revisar les polítiques existents, canviar les polítiques existents i mitigar el risc contactant amb els creadors i informant-los sobre la millor manera d'actuar per a la seva aplicació o flux.

Actualitzeu les polítiques DLP existents per revisar-ne l'impacte. Seguiu l'article Establiment de la higiene dels inquilins amb l'article CoE Starter Kit per trobar més informació sobre l'editor DLP.

Abans d'activar la funció DLP, podeu identificar quines aplicacions i fluxos es veuen afectats i alertar els creadors. L'editor DLP pot enviar una llista de totes les aplicacions i fluxos que es veuen afectats a una adreça de correu electrònic, que genera un fitxer .csv per a cada tipus d'objecte.

Amb l'editor DLP versió 2.0, a l'àrea Anàlisi d'impacte , trieu Exporta les aplicacions i els fluxos afectats a CSV .

Cada fitxer csv generat (flow.csv i apps.csv) té informació sobre:

1. Nom de les aplicacions i dels fluxos.
2. Propietari de les aplicacions i els fluxos.
3. PropietariCorreu electrònic de les aplicacions i fluxos.
4. Totes les connexions utilitzades per les aplicacions i els fluxos.
5. ID de les aplicacions i fluxos per identificar l'objecte.
6. Identificador d'entorn on es troben les aplicacions i els fluxos.

Tingueu en compte que el Connections us proporciona la llista de totes les connexions utilitzades per l'aplicació o el flux. Si necessiteu identificar exactament quin connector es veu afectat pel DLP en qüestió, cal una automatització en aquest moment. Estem avaluant canviar aquesta situació a l'eina.

Exemple d'implementació per identificar la connexió:

1. Creeu un Power Automate flux.

2. Utilitzeu el connector Obtén la norma DLP de l'inquilí especificant el DLP en qüestió.

3. El resultat són dues matrius, dades empresarials i dades no empresarials. Com a exemple, el connector de Twitter mostra aquest codi:

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

4. Des d'aquesta llista, teniu accés al nom del connector que coincideix amb la llista de noms de l'aplicació csv o la columna Connexió del flux .

5. En convertir el csv a Excel i col·locar-lo al vostre OneDrive, podeu llegir totes les aplicacions i fluxos afectats Power Automate. Comproveu quina connexió es veu afectada en funció de la lògica que compara les connexions amb els noms dels connectors.

6. Un cop hàgiu coincidit amb quina connexió està causant l'impacte, genereu una llista nova amb l'identificador de flux o aplicació i el connector afectat pel DLP.

7. Utilitzeu la informació anterior per notificar al fabricant l'impacte futur. Podeu utilitzar el Power Targetes per recollir els comentaris del creador si l'aplicació o el flux es poden suprimir o cal migrar a un altre entorn.

Segons l'anàlisi, si determineu que els fluxos afectats no s'estan utilitzant, podeu posar-los en quarantena i enviar un correu electrònic al fabricant amb instruccions sobre com moure'ls a un altre entorn. Això fomenta una cultura fes-ho tu mateix (DIY) i elimina l'ombra de les TI. En algunes situacions, és possible que vulgueu eximir alguns objectes del DLP. Per exemple, és possible que vulgueu aplicar un DLP específic només per als recursos nous que s'hagin creat i que eximeixin els recursos actuals. Per obtenir més informació sobre l'exempció de recursos DLP, vegeu Exempció de recursos DLP.

Efectivament, la vostra estratègia d'entorn es defineix mitjançant DLP i això proporciona una destinació per a les aplicacions i fluxos desenvolupats a l'entorn per defecte.

Estratègia d’entorn

El desenvolupament d'una estratègia d'entorn requereix configurar entorns i altres capes de seguretat de dades de manera que donin suport al desenvolupament productiu de la vostra organització, alhora que assegureu i organitzeu els recursos. Una estratègia per gestionar l'aprovisionament d'entorns, la gestió d'accés i el control dels recursos dins d'ells, és important per:

• Protegir les dades i l'accés.
• Governar l'entorn per defecte d'una manera compatible.
• Administrar el nombre correcte d'entorns per evitar-ne un excés i conservar-ne la capacitat.
• Facilitar i implementar una gestió del cicle de vida de l'aplicació saludable (ALM).
• Organitzar els recursos en particions lògiques.
• Admetre operacions (i servei d'assistència) en la identificació d'aplicacions que estan en producció, ja que es tenen en entorns dedicats.
• Garantir que les dades s'emmagatzemin i es transmetin a regions geogràfiques acceptables (per raons de rendiment i compliment).
• Garantir l'aïllament de les aplicacions que es desenvolupen.
• Habilitació de serveis de facturació interna als usuaris finals de negoci o unitats de negoci consumidores dels serveis.

Hauríeu de tenir departaments ben establerts que puguin autosostenir-se i tenir processos d'ALM existents. En aquests casos, els entorns proporcionen aïllament i organitzen els recursos en funció del departament. Una estratègia basada en això es pot aconseguir creant entorns separats per a cada departament. Aquests entorns es converteixen en la destinació de les aplicacions i els fluxos de l'entorn per defecte.

Estratègia de comunicació

Una comunicació eficaç és crucial durant un procés migratori. La comunicació es produeix en totes les fases del procés migratori. Una comunicació clara fomenta l'entesa i la col·laboració entre les parts interessades. Permet el flux fluid d'informació, assegurant que tots els involucrats estiguin ben informats sobre els plans de migració, el progrés i els possibles reptes.

Com a part de l'esforç de migració i neteja, assegureu-vos que el procés sigui fluid per als creadors, les parts interessades i el lideratge. Desenvolupeu una estratègia sobre la millor manera de comunicar-vos i en quins punts heu de comunicar-vos, que proporcioni coherència en els vostres objectius i ajudi a la comunicació per a tots els implicats. Algunes opcions a tenir en compte inclouen:

• Utilitzeu el CoE Starter Kit com a rastrejador d'actius.
• Afegiu fluxos de núvol personalitzats per enviar notificacions en diverses etapes.
• Creeu correus electrònics de plantilla que s'enviïn per comunicar-vos amb els creadors.

Les coses que cal tenir en compte inclouen:

• Canvi a l'URL de l'aplicació. Els usuaris de l'aplicació han d'actualitzar les adreces d'interès a una aplicació de l'entorn per defecte.
• Si hi ha un flux d'activació HTTP basat en URL, s'ha d'actualitzar en fluxos dependents per assegurar-se que encara actua com a webhook.
• Proporcioneu passos detallats per establir connexions un cop finalitzat el moviment tant per als creadors com per als usuaris de l'aplicació. Els usuaris no s'han de preocupar de crear una connexió quan inicien l'aplicació per primera vegada des del nou entorn.

Un bon començament per configurar les comunicacions requereix un model d'autoservei per escalar i ser més en temps real per als usuaris que deixar-lo per al correu electrònic d'un sol usuari o una llista de distribució. Si teniu previst establir un SharePoint lloc, hi ha una plantilla disponible que podeu utilitzar per crear un centre intern. Microsoft Power Platform El hub es converteix en el lloc comú per aprendre sobre estratègia i orientació perquè els responsables puguin prendre decisions correctes sobre el que pretenen construir i cap a on han d'anar.

Hi ha alguns components de la solució existents, com ara configurar components de notificacions d'inactivitat i configurar components de compliment per a desenvolupadors al Kit d'inici de CoE que podeu aprofitar. Aquests components inclouen plantilles de correu electrònic i es poden duplicar per adaptar-se al vostre propòsit i necessitat de migrar-los des de l'entorn predeterminat. Una bona addició és capturar alguns casos d'èxit al lloc de comunicació, també.

Públics

En el procés de migració, normalment hi ha diferents públics implicats en la comunicació. Aquests són els grups d'interès clau més típics i els seus rols:

• Propietaris d'aplicacions: els propietaris d'aplicacions són persones o equips responsables del desenvolupament, manteniment i gestió d'aplicacions específiques. Tenen un coneixement profund de la funcionalitat, el flux de treball i la configuració de les seves aplicacions. La comunicació amb els propietaris d'aplicacions és crucial per entendre els requisits específics de l'aplicació, recollir suggeriments, resoldre dubtes i garantir una migració fluida de les seves aplicacions al nou entorn.
• Usuaris d'aplicacions: els usuaris de l'aplicació són les persones que utilitzen les aplicacions regularment per realitzar les seves tasques o fluxos de treball. Poden tenir diferents nivells d'experiència tècnica i familiaritat amb les aplicacions. La comunicació amb els usuaris de l'aplicació és important per informar-los sobre la migració, proporcionar actualitzacions sobre qualsevol canvi o interrupció que es pugui produir, oferir formació o suport per garantir una transició perfecta i minimitzar qualsevol impacte en les seves operacions diàries.
• Caps de departament o caps de departament: Els caps o gerents de departament tenen un paper important en el procés de migració, ja que supervisen les operacions i els objectius estratègics dels seus respectius departaments. Han d'estar informats sobre el calendari de migració, els possibles impactes i els beneficis. La comunicació amb els caps de departament els permet proporcionar l'orientació necessària, alinear la migració amb els objectius departamentals i garantir una coordinació fluida dins dels seus equips.
• Equips informàtics o tècnics: els equips informàtics o tècnics són responsables de la infraestructura, els sistemes i els aspectes tècnics generals de la migració. Participen en la planificació, execució i suport del procés migratori. La comunicació amb els equips de TI és essencial per discutir els requisits tècnics, les dependències, les consideracions de seguretat i qualsevol canvi d'infraestructura o configuració necessari que s'hagi d'implementar per a la migració amb èxit.
• Equips de seguretat i compliment: Els equips de seguretat i compliment tenen un paper fonamental a l'hora de garantir la seguretat, la privadesa i el compliment normatiu de les dades durant la migració. Proporcionen orientació i garanteixen que hi hagi mesures adequades per protegir la informació sensible. La comunicació amb els equips de seguretat i compliment implica discutir els requisits de seguretat, els protocols de xifratge, els controls d'accés i qualsevol consideració relacionada amb el compliment durant tot el procés de migració.
• Direcció executiva: La direcció executiva, inclosos els executius de nivell C o els alts directius, s'ha de mantenir informada sobre el procés de migració. És possible que no requereixin informació tècnica detallada, però han de ser conscients dels objectius, el progrés i els possibles impactes del projecte en l'organització. La comunicació amb la direcció executiva ajuda a garantir el seu suport, alineació amb els objectius estratègics i assignació de recursos per a la migració.

És important adaptar les estratègies i els missatges de comunicació per a cada audiència, tenint en compte les seves necessitats específiques, preocupacions i nivell de comprensió tècnica. La comunicació clara i oportuna amb totes les parts interessades fomenta la col·laboració, garanteix una coordinació fluida i mitiga qualsevol repte potencial durant el procés migratori.

Cadència

La cadència o freqüència de comunicació amb els grups d'interès durant un procés de migració varia en funció de les necessitats i dinàmiques específiques del projecte. És important establir una comunicació regular i coherent per mantenir informades les parts interessades, abordar les preocupacions i mantenir l'alineació durant tota la migració. Aquestes són algunes consideracions per determinar la cadència de la comunicació amb els diferents grups d'interès:

• Propietaris d'aplicacions: és important mantenir una comunicació freqüent amb els propietaris d'aplicacions durant tot el procés de migració. Això inclou actualitzacions periòdiques sobre el progrés de la migració, resoldre qualsevol dubte i implicar els propietaris d'aplicacions en la presa de decisions, quan sigui necessari. La freqüència de comunicació pot variar en funció de la complexitat i criticitat de l'aplicació, però es recomana fer registres regulars i respostes oportunes a les consultes.
• Usuaris de l'aplicació: involucreu els usuaris de l'aplicació a través de canals de comunicació habituals per mantenir-los informats sobre la migració. Això hauria d'incloure anuncis, correus electrònics, butlletins o fins i tot sessions de formació o tallers dedicats. La freqüència de comunicació amb els usuaris de l'aplicació pot variar, però és crucial proporcionar actualitzacions en les fites clau, informar-los sobre qualsevol canvi o interrupció que els pugui afectar i oferir-los suport i orientació durant tot el procés.
• Caps i caps de departament: La comunicació amb els caps i caps de departament es pot produir a intervals regulars o segons sigui necessari, en funció de la importància de la migració als seus departaments. Proporcioneu actualitzacions periòdiques sobre el progrés general, els terminis i l'impacte en els seus equips.
• Equips informàtics o tècnics: Mantenir una comunicació regular amb els equips informàtics i tècnics implicats en la migració. Això inclou la col·laboració contínua, compartir actualitzacions sobre qüestions o problemes tècnics i coordinar qualsevol configuració o canvi necessari. La freqüència de comunicació sol ser més alta en la fase de planificació i anàlisi. Durant la fase d'implementació, tingueu punts de contacte o reunions periòdiques per garantir una coordinació fluida.

Recursos

Gestionar els recursos de manera eficaç és crucial per a una migració exitosa. Aquests són alguns aspectes clau a tenir en compte a l'hora de gestionar els recursos durant una migració:

• Identificació de recursos: Identificar els recursos necessaris per al projecte de migració, inclosos els individus o equips responsables de tasques com ara preparacions prèvies a la migració, migració de dades, proves, desplegament, configuració i suport posterior a la migració. Determinar les habilitats, l'experiència i la disponibilitat específiques necessàries per a cada funció.
• Assignació de recursos: assignar recursos a rols i tasques en funció de les habilitats, la disponibilitat i la capacitat de càrrega de treball del recurs. Assegureu-vos que els recursos s'assignen adequadament per equilibrar la càrrega de treball i complir els terminis del projecte. Penseu en les dependències o restriccions que poden afectar l'assignació de recursos, com ara els recursos compartits en diversos projectes.
• Desenvolupament i formació de competències: Avaluar les mancances d'habilitats i coneixements dins de l'equip i proporcionar les oportunitats de formació o capacitació necessàries per garantir que els recursos estiguin adequadament equipats per a les tasques assignades. Això pot implicar proporcionar sessions de formació, tallers o accés a recursos i documentació rellevants.
• Comunicació i col·laboració: Fomentar una comunicació efectiva i la col·laboració entre els recursos implicats en la migració. Fomenteu actualitzacions periòdiques d'estat, reunions de coordinació i intercanvi de coneixements per garantir que tots els membres de l'equip estiguin alineats, informats i treballin junts cap a objectius comuns.
• Planificació de contingències: Anticipar-se a possibles limitacions de recursos o riscos i elaborar plans de contingència. Tenir recursos de còpia de seguretat identificats o entrenats creuadament en rols crítics per mitigar qualsevol repte imprevist, com ara absències inesperades o limitacions de recursos.
• Participació de les parts interessades: mantingueu informades les parts interessades, com ara els propietaris d'aplicacions, els caps de departament i la gestió, sobre l'assignació de recursos i qualsevol impacte potencial en els terminis o els lliurables. Comunicar regularment actualitzacions de recursos, informes de progrés i qualsevol ajust en els plans de recursos per gestionar les expectatives i mantenir la transparència.

Migració individual d'objectes

La distinció entre aplicació i solució és important. L'exportació i la importació d'una aplicació només afecta aquest objecte. Una solució és un contenidor que pot tenir diverses aplicacions, fluxos i altres objectes.

Exportar i importar una aplicació de llenç (manera heretada)

Els passos detallats es documenten a Exportació d'un paquet d'aplicació de llenç i Importació d'un paquet d'aplicació de llenç.

Aquest mètode d'exportació d'aplicacions és una manera heretada. Tot i que s'admet, us recomanem que utilitzeu solucions. Les solucions us permeten migrar diversos components en lloc d'un sol recurs.

Flux d'exportació i importació (via heretada)

Els passos següents descriuen com exportar un flux.

1. Seleccioneu "..." seleccioneu Exporta i, a continuació, seleccioneu Paquet (.zip).
2. Introduïu un nom i una descripció per al paquet. A continuació, podeu configurar els paràmetres predeterminats i afegir comentaris accessibles durant la fase d'importació.
3. Seleccioneu el botó Exporta a la cantonada inferior dreta per descarregar el paquet. Si la baixada no s'inicia automàticament, pots seleccionar el botó Baixa .

Els passos següents descriuen com importar un flux.

1. Seleccioneu el botó Importa .
2. Carregueu el fitxer del paquet i espereu que la pantalla mostri els detalls del paquet.
3. Quan configureu la configuració del flux, podeu triar crear un flux nou o actualitzar-ne un d'existent amb la definició de flux del paquet.
4. Seleccioneu les connexions necessàries per configurar el flux. Hauríeu de veure que el botó Importa està disponible després d'haver configurat correctament tots els paràmetres necessaris.

Després d'importar el flux, s'ha d'activar. Si el flux té referències de connexió, l'usuari que l'activa ha de tenir accés a aquestes connexions. Si no és així, el propietari de la connexió pot concedir accés a l'usuari d'activació.

Aquest mètode d'exportació de fluxos de núvols és una manera heretada. Tot i que és compatible, us recomanem que utilitzeu solucions, que us permeten migrar diversos components en lloc d'un sol recurs.

Exportar i importar una aplicació basada en models

Una aplicació basada en models sempre forma part d'una solució. L'aplicació empaquetada, inclosa al fitxer de solució (.zip), es pot compartir amb els usuaris en funció de les seves funcions de seguretat després que s'hagi exportat correctament de l'entorn d'origen i importat a l'entorn de destinació.

Els processos detallats pas a pas es tracten a Exporta una solució i Importa una solució.

Exportar i importar un Microsoft Copilot Studio bot

Podeu exportar i importar robots mitjançant solucions. Es tracta d'una llista detallada dels passos a Exportar i importar robots mitjançant solucions.

Lloc d'exportació i importació Power Pages

Les pàgines de migració impliquen exportar la configuració existent des de l'entorn d'origen Microsoft Dataverse i, a continuació, importar-la a l'entorn de destinació Dataverse . Hi ha alguns passos de requisits previs que s'han de realitzar a l'entorn objectiu. Un cop finalitzat el treball de preparació, les dades de configuració del portal es poden exportar mitjançant l'eina migració de configuració.

SharePoint Aplicació del formulari: cas especial per a l'entorn per defecte

SharePoint Les aplicacions de formularis només es poden associar a un entorn i, si no es configuren d'una altra manera, es troben a l'entorn per defecte. Una migració de totes les aplicacions requereix que la destinació sigui un entorn diferent en lloc de l'entorn per defecte. Els formularis personalitzats existents no es migren automàticament a l'entorn que s'ha designat recentment. Només es poden designar entorns de producció per als formularis personalitzats de SharePoint. El procés manual segueix, com ara moure una aplicació de llenç.

Còpia de seguretat d'objectes Microsoft Power Platform

La majoria Microsoft Power Platform dels objectes s'exporten com a fitxers zip. Si no, tenen almenys un format de fitxer. Aquests fitxers en el seu format original, com a fitxer zip o qualsevol extensió que incloguin, es poden afegir a qualsevol ubicació d'emmagatzematge d'arxius o a un repositori de la vostra elecció. Algunes opcions a esmentar són Azure DevOps, GitHub, SharePoint One Drive o qualsevol altra solució que admeti tots els formats de fitxer.

Opcions de migració massiva

La migració d'una aplicació o flux té èxit si funciona de la mateixa manera que ho feia abans. No obstant això, hi ha certs elements que no es poden transferir:

• Dades d'execució del flux sobre les últimes execucions del flux : les dades sobre les execucions del flux només s'emmagatzemen durant 28 dies. Si necessiteu les dades, es poden exportar i emmagatzemar mitjançant el CoE Starter Kit o si heu configurat Exportació al llac de dades. L'última versió del CoE Starter Kit té les dades d'execució del flux si s'utilitza amb Exportació de dades.
• Versions de l'aplicació del llenç: a mesura que els creadors iteren durant el procés de desenvolupament, hi pot haver diverses versions creades. Les versions anteriors no es poden migrar. Només es pot migrar l'última versió.
• Dades a les quals accedeix l'aplicació o el flux o mitjançant connectors : només s'inclouen metadades de l'aplicació com a part de l'exportació.

Tampoc s'inclouen els comentaris de col·laboració realitzats a l'aplicació o al flux.

En aquest article s'esbossen algunes possibilitats. És important considerar acuradament les implicacions i avantatges de cada possibilitat abans de decidir-se.

Migra-ho tot: opció de còpia de seguretat i restauració de la base de dades

De manera similar a la majoria de tipus d'entorn, també es fa una còpia de seguretat de l'entorn per defecte. Aquestes còpies de seguretat del sistema es realitzen automàticament. No hi ha cap opció sota demanda per a l'entorn per defecte, de manera que requereix una sol·licitud de suport tècnic. La còpia de seguretat es pot restaurar en un nou entorn mantenint totes les dades dins Dataverse. Aquesta opció és només per mostrar al lector sobre la seva existència i educar el lector sobre quan ha de considerar. No s'hauria de perseguir com l'opció principal, ja que només produiria una migració parcial.

• Suportat: Dataverse, Aplicacions del Dynamics
• No és totalment compatible: aplicació de llenç, biblioteca de components, pàgines personalitzades, Power Automate Microsoft Copilot Studio

No és totalment compatible indica que pot haver-hi pèrdues potencials de dades durant la migració i es requereixen més passos.

Migrar metadades i després dades

Un enfocament recomanat és utilitzar solucions per moure les metadades i, a continuació, es podrien utilitzar fluxos de dades, Azure Data Factory o una altra eina de preferència per transferir dades. És possible que l'automatització completa de principi a fi no sigui assolible en tots els casos, a causa dels diversos connectors, però és possible una aproximació propera.

A un nivell alt, els passos són:

1. Afegiu una aplicació a una solució.
2. Afegiu flux a la solució.
3. Afegiu bots existents.
4. Ajusteu les referències de connexió a les aplicacions i als fluxos.
5. Comproveu si hi ha dependències de la solució i afegiu objectes.
6. Exporteu la solució.
7. Importeu la solució.
8. Transferir dades.

Comprovació de dependències de la solució

L'èxit de la importació d'una solució a l'entorn de destinació només es pot garantir quan afegiu tots els components relacionats a la solució o estan disponibles a l'entorn de destinació. Si falten components, és probable que la importació de la solució falli. Per assegurar-vos que tots els components necessaris estiguin presents, hi ha opcions millor si s'utilitzen en combinació:

• Afegiu manualment els components seleccionats a la solució. En aquest cas, se suposa que sabeu que tots els components dependents ja estan disponibles a l'entorn de destinació.

• Utilitzeu el botó Mostra les dependències des de la solució per permetre que el sistema identifiqui les dependències. Podeu afegir totes les dependències o afegir selectivament només les dependències que no existeixen a l'entorn de destinació.

  

Addició d'un component a una solució (manual)

Suposant que es crea una solució, un creador ha d'utilitzar l'opció Afegeix el menú de components existent per afegir una aplicació, un flux o un bot existents.

Ajustar les referències de connexió

Les aplicacions i els fluxos de llenç gestionen les connexions de manera diferent. Els fluxos utilitzen referències de connexió per a tots els connectors, mentre que les aplicacions de llenç només les utilitzen per a connexions compartides implícitament (no OAuth), com ara l'autenticació de l'SQL Server.

Actualització d'una aplicació per utilitzar referències de connexió en lloc de connexions

Les aplicacions de llenç que no són compatibles amb les solucions quan s'afegeixen a una solució no s'actualitzaran automàticament per utilitzar referències de connexió. Les referències de connexió s'associen amb les aplicacions del llenç només en el moment d'afegir una font de dades a l'aplicació. Per actualitzar aplicacions, has de complir els requisits següents:

1. Afegiu una aplicació que no sigui conscient de la solució a una solució.
2. Suprimiu la connexió de l'aplicació.
3. Creeu un referència de connexió nou a la solució.
4. Afegiu una connexió que contingui una referència de connexió associada.

Actualitzar un flux per utilitzar referències de connexió en comptes de connexions

Quan un flux no es troba en una solució, utilitza connexions. Si aquest flux s'afegeix a una solució, continua utilitzant connexions inicialment. Els fluxos es poden actualitzar per utilitzar referències de connexions, en lloc de connexions, d'una d'aquestes dues maneres:

• Si el flux s'exporta en una solució no administrada i s'importa, les connexions s'eliminen amb referències de connexió.

• Quan s'obre un flux de solució, el comprovador de flux a la pàgina de detalls del flux mostra un advertiment per utilitzar referències deconnexió. El missatge d'advertiment té una acció que podeu seleccionar per suprimir connexions perquè es puguin afegir referències de connexió. La selecció d'aquesta acció elimina les connexions de l'activador i les accions del flux i permet seleccionar i crear referències de connexió.

Addició d'un objecte a una solució (automatització)

Podeu utilitzar ordres del PowerShell per desplaçar aplicacions de manera massiva a una solució. L'addició d'aplicacions de llenç preexistents i fluxos de núvol a les solucions també es pot fer mitjançant la línia d'ordres. Instal·leu els mòduls del PowerShell més recents per provar aquesta opció. Les dues ordres principals són Set-PowerAppAsSolutionAware i Set-FlowAsSolutionAware.

Un cop instal·lats els mòduls, inseriu el vostre propi identificador d'entorn, identificador d'aplicació, identificador de flux i identificador de solució.

Per a una aplicació de llenç:

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

Per a un flux:

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

Les referències de connexió són entrades de dades a la taula referència de connexió. Per utilitzar el referència de connexió com a part de l'aplicació o del flux cal modificar l'aplicació principal o la definició del flux. Heu de substituir el node connectionReferences pel referència de connexió.

Exportació i importació de solucions

Suposant que les solucions estan preparades, la següent etapa d'automatització es pot fer de diverses maneres:

• Exporteu i importeu manualment les solucions a l'entorn de destinació. ...

• Utilitzeu paquets per moure diverses solucions en una sola passada.

• Utilitzeu Power Platform tasques d'eines de compilació per realitzar diverses operacions com ara solució de paquet, solució de desembalatge, solució d'exportació i solució d'importació. DevOps proporciona la possibilitat d'automatitzar la gestió del cicle de vida de l'aplicació (ALM) i totes aquestes tasques estan dissenyades per admetre ALM Microsoft Power Platform.

La interfície de línia d'ordres Power Platform (CLI) també proporciona opcions per exportar i importar solucions. Totes les ordres relacionades amb la solució es poden utilitzar per crear, exportar i importar solucions. També podeu utilitzar CLI per transferir dades d'entrada i sortida.

Una opció fàcil de fer és utilitzar canonades destinades a democratitzar l'ALM Power Platform. Incorporar capacitats d'automatització d'ALM i integració contínua / desplegament continu (CI / CD) en un sol servei de funcions és més accessible per a tots els fabricants, administradors i desenvolupadors.

Creació de connexions (manual)

A l'entorn de destinació abans de definir l'operació d'importació, creeu les connexions que falten necessàries per a l'aplicació o el flux. Per obtenir més informació sobre com crear connexions, vegeu Administrar connexions Power Automate.

Migració de dades

Hi ha múltiples opcions disponibles per a la migració de dades, que van des de l'automatització manual fins a l'automatització completa.

• Exporteu i importeu manualment les dades mitjançant llibres de treball de l'Excel.
• R Power Automate flux de núvol es pot desenvolupar per extreure dades de les taules d'origen i escriure directament a la destinació. Tanmateix, això requereix que el creador utilitzi el connector del Dynamics 365 o el Dataverse connector (heretat). Actualment, el connector no admet la Dataverse connexió entre entorns. Aquesta característica està planificada per al futur i, un cop alliberada, es pot utilitzar per moure dades d'una a l'altra.
• L'eina de migració de configuració (CMT) és una eina que s'utilitza per a la migració del portal, però també es pot utilitzar per a la migració regular de dades. CMT també es pot utilitzar amb PowerShell. L'eina PAC CLI dóna la possibilitat de trucar a CMT.
• Els fluxos de dades es poden utilitzar per crear assignacions entre els entorns i utilitzar-los per moure dades. El connector web HTTP es pot utilitzar com a alternativa Dataverse.
• L'Azure Data Factory es pot utilitzar amb el Dataverse connector per extreure dades de l'origen i inserir-les a la destinació.

Atès que l'entorn per defecte té una mida limitada, una de les opcions anteriors hauria de ser suficient per moure les dades fora de l'entorn predeterminat.

Netejar consideracions

Una neteja és un bon idea per a aplicacions i fluxos que no s'han utilitzat i actualitzat en molt de temps. Hi ha diferents camins que un administrador ha de tenir en compte pel que fa a la neteja.

• Decidiu l'ordre d'importació de les dades. Les taules menys dependents van primer i les més dependents arriben al final.
• No cal mapejar tots els camps. No cal assignar camps com Versió, Data modificada, Data de creació i alguns altres camps del sistema.
• Si voleu conservar la data original Creat en la data , utilitzeu el camp Creat en la datad'origen al camp OverRiddenCreatedOn de la taula de destinació.
• Les dades d'auditoria no es poden migrar.
• No habiliteu els fluxos de treball ni els fluxos que s'activin en funció de la inserció de dades, tret que sigui intencionat. Això augmenta el temps per a la migració de dades.

Opcions d'etiquetatge

CoE Starter Kit no té cap opció d'etiquetatge avui. Tot i això, podria ser una personalització que podríeu afegir al kit d'inici.

Creeu una taula anomenada Etiquetes i configureu una relació de diversos a molts (N:N) amb l'aplicació, els fluxos i altres taules d'inventari. A continuació, podeu crear una etiqueta i associar aquests registres amb els elements d'inventari adequats. Per obtenir una millor experiència d'usuari, podeu incrustar una quadrícula al formulari principal d'aplicacions, fluxos i altres taules d'inventari. Aquesta opció és recomanable ja que té consistència referencial.

Creeu un camp de text a cada taula d'inventari i utilitzeu-lo per capturar el text (etiqueta) que podeu utilitzar posteriorment.

Si voleu una llista més fixa, creeu una conjunt d'opcions global i afegiu-la també a totes les taules d'inventari i als seus formularis.

Opció de quarantena

Si no esteu segur de la necessitat de certes aplicacions, podeu provar d'aïllar-les durant un temps i posar-les en quarantena durant aquest estat. El propietari només pot utilitzar l'aplicació. Un cop transcorregut el temps adequat i si no s'ha rebut cap resposta del propietari, podeu eliminar-los de l'entorn.

Els fluxos no admeten l'estat de quarantena, però es pot utilitzar un enfocament similar aturant el flux i comprovant si el propietari el torna a activar.

En tots dos casos, tenir una correcta comunicació amb el propietari és important.

Només opció Suprimeix

Si realment no hi ha pèrdua de productivitat i reutilització dels objectes, aquesta opció és la millor. La majoria de fluxos de prova i aplicacions pertanyen a aquesta categoria.

En aquest cas, un cop identificada la llista d'objectes, es podria desenvolupar un lot de PowerShell i passar-hi una llista csv, que eliminaria tots aquests actius.

A mesura que feu un bucle pels identificadors de les aplicacions i els fluxos, es pot utilitzar l'ordre següent per eliminar-los de l'entorn per defecte.

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

Còpia de seguretat d'objectes i opció Eliminar

Com a exemple, suposeu que es crea un Power Automate flux per atendre una necessitat estacional específica, però que no s'ha utilitzat durant molt de temps. En aquest cas, és bo fer una còpia de seguretat del component abans de suprimir el component.

Per fer una còpia de seguretat del component, es podrien utilitzar opcions de migració individual o migració massiva per generar una solució exportada. A continuació, es pot afegir a un repositori de fitxers que trieu o a una OneDrive ubicació.

Un cop assegurada la còpia de seguretat, podeu aplicar l'opció Suprimeix per completar el procés de neteja.

En molts casos, es tracta de fluxos de prova i aplicacions creades per makers com a part del seu aprenentatge i experimentació de productivitat personal.

Conclusió

Power Platform és una eina tant per a desenvolupadors ciutadans com per a desenvolupadors professionals. L'ús predeterminat de l'entorn s'ha de centrar principalment en la productivitat personal mitjançant Microsoft 365 productes. La resta d'aplicacions i el desenvolupament del flux s'han de dur a terme en entorns compartits, individuals o de desenvolupador designats. Una forta recomanació és desenvolupar una estratègia d'entorn independent basada en DLP, que pugui ajudar els fabricants a desenvolupar les seves aplicacions i fluxos en l'entorn adequat. També és un gran avantage establir una estratègia de comunicació i proporcionar als usuaris models d'autoservei d'aprenentatge sobre l'estratègia, la implementació de solucions i les millors pràctiques per desenvolupar aplicacions i fluxos. Una bona addició és capturar alguns casos d'èxit al lloc de comunicació. Els casos d'èxit publicats internament ajuden els creadors a connectar amb Idees i els obren a possibilitats que es podrien aconseguir utilitzant Power Platform.

Una estratègia de governança sòlida és essencial a l'hora de migrar o moure objectes específics. Hi ha diverses estratègies disponibles per a la migració d'objectes, incloent la migració individual i massiva. L'opció que millor s'adapti depèn de les polítiques de la nostra organització. Les solucions són la forma més recomanable d'organitzar els components de la vostra aplicació i fer migracions més senzilles.