Migrar aplicações e fluxos do ambiente predefinido

Este documento técnico explica como as organizações e os administradores podem planear a migração das suas aplicações e fluxos a partir do ambiente predefinido.

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

Nota

Pode guardar ou imprimir este documento técnico ao selecionar Imprimir no seu browser e, em seguida, ao selecionar Guardar como PDF.

Ambiente predefinido

É criado um ambiente predefinido por inquilino e está acessível a todos os utilizadores nesse inquilino. O ambiente predefinido é criado na região mais próxima à região predefinida do inquilino do Microsoft Entra e é nomeado da seguinte forma: [nome do inquilino do Microsoft Entra] (predefinido). Sempre que um novo utilizador se inscreve para o Power Apps ou o Power Automate, é adicionado automaticamente à função de criador do ambiente predefinido. Nenhum utilizador é adicionado automaticamente à função de Administrador do Ambiente do ambiente predefinido.

Não pode eliminar o ambiente predefinido e não pode criar manualmente uma cópia de segurança do ambiente predefinido. As cópias de segurança do sistema são efetuadas continuamente. O ambiente predefinido é limitado a 1 TB de capacidade de armazenamento. O ambiente predefinido tem as seguintes capacidades:

• Capacidade da base de dados do Dataverse de 3 GB
• Capacidade de ficheiros do Dataverse de 3 GB
• Capacidade de registos do Dataverse de 1 GB

A verificação de capacidade realizada antes da criação de novos ambientes exclui a capacidade de armazenamento incluído do ambiente predefinido ao calcular se tem capacidade suficiente para criar um novo ambiente. Para armazenar mais dados, pode criar um ambiente de produção.

No ambiente predefinido, os colaboradores de uma organização com uma licença do Microsoft 365 podem criar aplicações e fluxos cloud. O ambiente predefinido passa a ser o primeiro estúdio de ambiente de demonstração para que estes colaboradores comecem a criar aplicações e fluxos. Uma vez que não é possível remover a função de criador de ambientes do ambiente predefinido, os criadores começam a criar aplicações e fluxos de produtividade pessoais e a partilhá-los nas suas equipas para que outros beneficiem deles. A maioria das organizações, muitas vezes, muda o nome do ambiente predefinido para Produtividade Pessoal.

Os administradores descobrem reativamente que muitas aplicações e fluxos são criados no ambiente predefinido. Pode não ser apropriado para uma aplicação ou um fluxo estar no ambiente predefinido em cenários como:

• Uma aplicação é partilhada com muitos utilizadores por comportamento semelhante a produção.
• Uma aplicação utiliza livros do Excel com dados confidenciais.
• Uma aplicação, baseada em listas do SharePoint, obtém muitas interações de dados, tais como inserções ou atualizações.
• Uma aplicação ou um fluxo está a utilizar conectores que não são permitidos nas novas políticas de prevenção de perda de dados (DLP).
• Os conectores personalizados estão ativados e são utilizados no ambiente predefinido, em vez serem protegidos num ambiente dedicado.

Os cenários acima podem ser considerados e fornecem uma indicação de que deve começar a mover estas aplicações e fluxos do ambiente predefinido para o seu próprio ambiente de programação ou para outro ambiente partilhado. Outros fatores em consideração são as limitações associadas ao ambiente predefinido.

As equipas do Centro de Excelência (CoE) que monitorizam o Power Platform são forçadas a reagir após os limites serem atingidos, o que afeta negativamente as aplicações em execução no ambiente predefinido. Esta limitação também pode ser algo que um administrador ou a equipa de CoE tem de efetuar regularmente. Existem três fases abrangentes:

• Identificação dos objetos do Power Platform
• Mover os objetos do Power Platform
• Limpar os objetos do Power Platform

Existem várias formas de exportar as suas aplicações e os fluxos para os mover para um novo ambiente. As soluções são um ficheiro único que pode incluir praticamente tudo o que os criadores criam no Power Platform e podem movê-los juntos. As aplicações de tela e os fluxos cloud podem ser exportados diretamente.

Com o tempo, os objetos do Power Platform evoluíram para suportarem a solução. Por predefinição, as aplicações e os fluxos podem suportar a solução, embora isto requeira a ativação manual. Os criadores podem ainda criar aplicações e fluxos a partir de make.powerapps.com e make.powerautomate.com, que podem ser classificados como sem suporte para soluções, estes podem ser exportados individualmente, ou adicione-os a uma solução. Ao adicionar uma solução, o criador pode tirar partido das variáveis de ambiente e das referências de ligação para configurar e implementar pontos finais entre ambientes.

O objetivo é fazer com que todos os componentes do Power Platform sejam adicionados a uma única solução, o que permite que vários componentes sejam movidos facilmente como uma unidade única entre ambientes.

Identificação dos objetos do Power Platform

O primeiro passo é identificar as aplicações, os fluxos e os recursos que necessitam de ser movidos ou limpos. O Kit de Iniciação CoE fornece um inventário de todas as aplicações e fluxos, sendo que os relatórios do Power BI ajudam a determinar a utilização. Este passo ajuda-o a avaliar a utilização da aplicação e deverá ajudar a etiquetá-los. Enquanto realiza o exercício, certifique-se de que marca etiqueta as aplicações e os fluxos que devem ser migrados para outro ambiente. Uma etiqueta pode basear-se nos conectores utilizados, localização do utilizador, departamento do utilizador, entre outros. Este artigo também descreve um método para reconhecer itens que devem ser limpos ou mudados com base nas práticas de prevenção de perda de dados (DLP).

Mover os objetos do Power Platform

Se o componente estiver identificado para se mover para outro ambiente, existem opções disponíveis para mover a aplicação. Uma mudança é um processo interativo e necessita de algum nível de interação do criador. O nível de complexidade para mover uma aplicação ou fluxo aumenta com a mistura de componentes utilizados para criar a aplicação ou o fluxo.

Por exemplo, uma aplicação com seis ecrãs tem 10 botões através de vários ecrãs. Vamos supor que cada um destes 10 botões chama um fluxo individual. Também existem dois fluxos que são acionados diariamente para corrigir ou integrar dados com outro sistema. Vamos supor também que existe um modelo de processamento de imagem do AI Builder que é utilizado como parte da automatização. Para mover uma aplicação deste tipo, todos os componentes têm de ser adicionados a uma solução e as referências de ligação têm de ser ajustadas corretamente e testadas antes de confirmar a conclusão.

Noutro caso, suponha que existe uma aplicação de tela que utiliza uma ligação do Office 365. Neste caso, o criador só necessita de adicionar apenas a aplicação de tela à solução.

Limpar os objetos do Power Platform

Se um componente for identificado para limpeza, existem duas opções principais. A primeira opção é eliminá-lo diretamente e a segunda opção é eliminá-lo depois de criar uma cópia de segurança. No caso da cópia de segurança, poderá haver alguma sobreposição de passos que coincidem com objetos móveis.

Por exemplo, os administradores da Equipa de CoE descobrem que a maior parte dos criadores cria aplicações e fluxos de teste para fins de aprendizagem. Os criadores podem então abandonar as aplicações e os fluxos, o que pode ser confirmado vendo as métricas de utilização. Outra forma é colocar em quarentena uma aplicação. Se ninguém o contactar sobre a aplicação, esta também poderá ser eliminada.

Manter uma estratégia de comunicação é uma função-chave. Os admins deverão planear comunicar:

• Estabelecer ligações que os criadores têm de permitir quando iniciam a aplicação no novo ambiente.
• O novo URL da aplicação do ambiente de destino.
• Navegar para o ambiente correto.

Algumas destas soluções para realocação de objetos estão prontas a ser utilizadas e poderão requerer uma licença autónoma do Power Apps e do Power Automate que fornece aos utilizadores a capacidade de criar e executar aplicações entre origens de dados que se expandem para além do Microsoft 365.

Estratégias

É mais provável que todo o processo de identificação e mudança de aplicações e fluxos do ambiente predefinido tenha êxito quando se baseia numa estratégia. Existem várias estratégias que deve considerar.

Estratégia DLP

As políticas de prevenção de perda de dados (DLP) funcionam como proteções para ajudar a evitar que os utilizadores exponham involuntariamente os dados organizacionais e proteger a segurança das informações no inquilino. As políticas DLP impõem regras para as quais os conectores estão ativados para cada ambiente, bem como quais os conectores que podem ser utilizados em conjunto. Os conectores são classificados como apenas dados de negócio, dados de negócio não permitidos ou bloqueado. Um conector no grupo apenas dados de negócio só pode ser utilizado com outros conectores desse grupo na mesma aplicação ou fluxo. Recomendamos que tenha, pelo menos, uma política.

Identificação dos objetos utilizando DLP

A identificação baseada na política DLP é útil para definir ambientes de destino para as suas aplicações e fluxos. Poderão haver aplicações ou fluxos que estão a utilizar um conector que está bloqueado pela DLP ou uma mistura de conectores de negócio e de não negócio que, após a ativação da DLP, deixam de funcionar.

Para impedir tempo de inatividade de potenciais objetos críticos, devido à DLP, parte do Kit de Iniciação CoE, pode encontrar a ferramenta do editor de DLP (análise de impacto). O objetivo do editor de DLP é permitir que os admins vejam o impacto de políticas existentes ou o impacto potencial das alterações à política. Fornece aos admins uma vista das aplicações e fluxos afetados, bem como de recursos que seriam desativados se fossem aplicadas políticas novas ou atualizadas. A aplicação pode ser utilizada para rever políticas existentes, alterar políticas existentes e mitigar riscos contactando os criadores e informando-os sobre a melhor ação a tomar para a respetiva aplicação ou fluxo.

Atualize políticas DLP existentes para rever o impacto. Siga o artigo Estabelecer higiene do inquilino com o Kit de Iniciação CoE para encontrar mais informações sobre o editor de DLP.

Antes de ativar a caraterística DLP, pode identificar que aplicações e fluxos são afetados e alertar os criadores. O editor de DLP pode enviar uma lista de todas as aplicações e fluxos que são afetados para um endereço de e-mail, o que gera um ficheiro .csv para cada tipo de objeto.

Utilizando a versão 2.0 do editor de DLP, na área Análise do Impacto, escolha Exportar aplicações e fluxos afetados para CSV.

Cada ficheiro csv gerado (flow.csv e apps.csv) tem informações relativas a:

1. Nome das aplicações e fluxos.
2. Proprietário das aplicações e fluxos.
3. E-mail do Proprietário das aplicações e fluxos.
4. Todas as ligações utilizadas pelas aplicações e fluxos.
5. O ID das aplicações e fluxos para identificar o objeto.
6. ID do Ambiente em que as aplicações e os fluxos estão localizados.

Note que as Ligações do lhe dão a lista de todas as ligações utilizadas pela aplicação ou fluxo. Se precisar de identificar exatamente qual o conector afetado pela DLP em questão; é necessária uma automatização nesta altura. Estamos a avaliar a alteração desta situação na ferramenta.

Exemplo de implementação para identificar a ligação:

1. Criar um fluxo do Power Automate.

2. Utilize o conector Obter Política DLP do Inquilino especificando a DLP em questão.

3. O resultado são duas matrizes, dados de negócio e dados de não negócio. Como exemplo, o conector do Twitter mostra este código:

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

4. A partir desta lista, tem acesso ao nome do conector que corresponde à lista de nomes da coluna Ligação da aplicação ou fluxo csv.

5. Ao converter o csv para o formato Excel e colocando-o no seu OneDrive, pode ler todas as aplicações e fluxos afetados a partir do Power Automate. Verifique que ligação é afetada com base na lógica que compara ligações com nomes de conectores.

6. Depois de ter uma correspondência sobre que ligação está a causar o impacto, gere uma nova lista com o ID da aplicação ou do fluxo e o conector afetado pela DLP.

7. Utilize as informações anteriores para notificar o criador acerca do impacto futuro. Pode utilizar Cartões Power para recolher o feedback do criador se a aplicação ou o fluxo puder ser eliminado ou se necessitar de ser migrado para outro ambiente.

Com base na sua análise, se determinar que os fluxos afetados não estão a ser utilizados, pode colocá-los em quarentena e enviar um e-mail ao criador com instruções sobre como movê-los para um ambiente diferente. Isto encoraja uma cultura de faça você mesmo (DIY) e remove a TI sombra. Em algumas situações, poderá querer isentar alguns objetos da DLP. Por exemplo, poderá querer aplicar uma DLP específica apenas para novos recursos que tenham sido criados e isentar os recursos atuais. Para obter mais informações sobre a isenção de recursos DLP, consulte Isenção de recursos DLP.

Efetivamente, a estratégia do ambiente é definida através da DLP e isso fornece um destino para as aplicações e fluxos desenvolvidos no ambiente predefinido.

Estratégia do ambiente

Desenvolver uma estratégia ambiental requer configurar os ambientes e outras camadas de segurança de dados de uma forma que suporte o desenvolvimento produtivo na sua organização, ao mesmo tempo que protege e organiza recursos. É importante ter uma estratégia para gerir o aprovisionamento do ambiente, a gestão de acessos e controlar os recursos nele contidos, para:

• Proteger os dados e o acesso.
• Governe o ambiente predefinido em conformidade.
• Gerir o número correto de ambientes para evitar a dispersão e conservar a capacidade.
• Facilite e implemente uma gestão saudável do ciclo de vida de aplicações (ALM).
• Organizar recursos em partições lógicas.
• Apoiar as operações (e o suporte técnico) na identificação de aplicações que estão em produção ao tê-las em ambientes dedicados.
• Assegurar que os dados estão a ser armazenados e transmitidos em regiões geográficas aceitáveis (por razões de desempenho e conformidade).
• Assegurar o isolamento das aplicações que estão a ser desenvolvidas.
• Capacitação de serviços de faturação internos para utilizadores finais de negócio ou unidades de negócio que consomem os serviços.

Deverá ter departamentos bem estabelecidos que podem manter-se por eles próprios e que têm processos ALM em vigor. Nesses casos, os ambientes fornecem isolamento e organizam recursos com base no departamento. Uma estratégia baseada nisso pode ser alcançada criando ambientes separados para cada departamento. Estes ambientes tornam-se no destino das aplicações e fluxos no ambiente predefinido.

Estratégia de comunicação

Uma comunicação eficaz é crucial durante um processo de migração. As comunicações ocorrem ao longo de todas as fases do processo de migração. Comunicação clara fomenta a compreensão e a colaboração entre os intervenientes. Permite o fluxo suave de informações, assegurando que todas os envolvidos estão bem informados sobre os planos de migração, o progresso e quaisquer desafios potenciais.

Como parte do esforço de migração e limpeza, certifique-se de que o processo é suave para os criadores, intervenientes e a liderança. Desenvolva uma estratégia sobre como melhor comunicar e em que pontos é necessário comunicar, que fornece consistência nos seus objetivos e ajuda a comunicação para todos os envolvidos. Algumas opções a considerar incluem:

• Utilize o Kit de Iniciação CoE como um monitorizador de recursos.
• Adicione fluxos de cloud personalizados para enviar notificações em várias fases.
• Crie e-mails de modelo que são enviados para comunicar com os criadores.

Aspetos a ter em conta incluem:

• Alteração no URL da aplicação. Os utilizadores da aplicação necessitam de atualizar quaisquer marcadores para uma aplicação no ambiente predefinido.
• Se houver um fluxo de acionador HTTP baseado em URL, este tem de ser atualizado em fluxos dependentes para garantir que continua a atuar como um webhook.
• Forneça passos detalhados para estabelecer ligações depois de concluída a mudança para os criadores e para os utilizadores da aplicação. Os utilizadores não devem ficar preocupados com a criação de uma ligação quando iniciam a aplicação pela primeira vez a partir do novo ambiente.

Um bom início para configurar comunicações requer um modelo de gestão própria para dimensionar e ser mais em tempo real para os utilizadores do que apenas deixá-lo para o e-mail de um único utilizador ou lista de distribuição. Se pretende estabelecer um site do SharePoint, existe um modelo disponível para criar um hub do Microsoft Power Platform interno. O hub torna-se o local comum para obter informações sobre estratégia e orientação para que os criadores tomem as decisões certas sobre o que pretendem criar e para onde devem dirigir-se para o conseguir.

Existem alguns componentes de solução existentes, como configurar componentes de notificações de inatividade e configurar componentes de Conformidade do Programador no Kit de Iniciação CoE dos quais pode tirar partido. Estes componentes são fornecidos com modelos de e-mail e podem ser duplicados para se adaptarem ao seu propósito e necessidade para os migrar do ambiente predefinido. Uma boa adição é também a captura de algumas histórias de êxito no site de comunicação.

Audiências

No processo de migração, normalmente, existem audiências diferentes envolvidas na comunicação. Eis os intervenientes-chave mais típicos e as suas funções:

• Proprietários de aplicativos: os proprietários de aplicativos são indivíduos ou equipes responsáveis pelo desenvolvimento, manutenção e gerenciamento de aplicativos específicos. Têm conhecimento aprofundado sobre a funcionalidade, fluxo de trabalho e configuração das suas aplicações. A comunicação com os proprietários das aplicações é crucial para compreender os requisitos específicos da aplicação deles, recolher feedback, abordar preocupações e garantir uma migração suave das aplicações para o novo ambiente.
• Usuários de aplicativos: os usuários de aplicativos são os indivíduos que utilizam os aplicativos regularmente para executar suas tarefas ou fluxos de trabalho. Podem ter diversos níveis de conhecimento técnico e familiaridade com as aplicações. As comunicações com os utilizadores das aplicações são importantes para os informar sobre a migração, fornecer atualizações sobre quaisquer alterações ou interrupções que possam ocorrer, oferecer formação ou suporte para assegurar uma transição totalmente integrada e minimizar qualquer impacto nas operações diárias.
• Chefes de departamento ou gerentes: Os chefes de departamento ou gerentes desempenham um papel significativo no processo de migração, pois supervisionam as operações e os objetivos estratégicos de seus respetivos departamentos. Necessitam de ser informados sobre a linha cronológica da migração, impactos potenciais e os benefícios. A comunicação com os chefes de departamento permite-lhes fornecer as orientações necessárias, alinhar a migração com os objetivos departamentais e assegurar uma coordenação suave nas respetivas equipas.
• Equipes técnicas ou de TI: as equipes técnicas ou de TI são responsáveis pela infraestrutura, pelos sistemas e pelos aspetos técnicos gerais da migração. Estão envolvidos no planeamento, execução e suporte do processo de migração. A comunicação com as equipas de TI é essencial para debater requisitos técnicos, dependências, considerações de segurança e quaisquer alterações à infraestrutura ou à configuração necessárias que têm de ser implementadas para a migração com êxito.
• Equipes de segurança e conformidade: as equipes de segurança e conformidade desempenham um papel fundamental na garantia da segurança dos dados, da privacidade e da conformidade regulatória durante a migração. Fornecem orientações e asseguram que as medidas adequadas para proteger as informações confidenciais estão em vigor. A comunicação com as equipas de segurança e conformidade envolve o debate de requisitos de segurança, protocolos de encriptação, controlos de acesso e quaisquer considerações relacionadas com conformidade ao longo do processo de migração.
• Gestão executiva: A gestão executiva, incluindo executivos de nível C ou liderança sénior, deve ser mantida informada sobre o processo de migração. Poderão não requerer informações técnicas detalhadas, mas deverão estar cientes dos objetivos, progresso e potenciais impactos do projeto na organização. A comunicação com a gestão executiva ajudam a garantir o respetivo suporte, o alinhamento com objetivos estratégicos e a alocação de recursos para a migração.

É importante personalizar as estratégias de comunicação e as mensagens para cada audiência, considerando as respetivas necessidades específicas, as preocupações e o nível de compreensão técnica. Uma comunicação clara e atempada com todos os intervenientes fomenta a colaboração, assegura uma coordenação suave e mitiga quaisquer desafios potenciais durante o processo de migração.

Cadência

A cadência ou frequência da comunicação com os intervenientes durante um processo de migração varia com base nas necessidades específicas e na dinâmica do projeto. É importante estabelecer comunicação regular e consistente para manter os intervenientes informados, abordar preocupações e manter o alinhamento ao longo da migração. Eis algumas considerações para determinar a cadência da comunicação com diferentes intervenientes:

• Proprietários de aplicativos: manter uma comunicação frequente com os proprietários de aplicativos durante todo o processo de migração é importante. Isto inclui atualizações regulares sobre o progresso da migração, abordando quaisquer preocupações e envolvendo os proprietários das aplicações na tomada de decisão, quando necessário. A frequência da comunicação pode variar consoante a complexidade e a importância da aplicação, mas é recomendável que tenha consultas regulares e respostas atempadas a inquéritos.
• Usuários do aplicativo: envolva os usuários do aplicativo por meio de canais de comunicação regulares para mantê-los informados sobre a migração. Isto deverá incluir anúncios, e-mails, newsletters ou até sessões de preparação ou workshops dedicados. A frequência de comunicação com os utilizadores da aplicação pode variar, mas é crucial fornecer atualizações em marcos-chave, informá-los sobre quaisquer alterações ou interrupções que possam afetá-los e oferecer suporte e orientação ao longo do processo.
• Chefes de departamento e gerentes:A comunicação com os chefes e gerentes de departamento pode ocorrer em intervalos regulares ou conforme necessário, com base na importância da migração para seus departamentos. Forneça atualizações periódicas sobre o progresso global, as linhas cronológicas e o impacto nas respetivas equipas.
• Equipes técnicas ou de TI: Envolva-se em comunicação regular com as equipes técnicas e de TI envolvidas na migração. Isto inclui a colaboração contínua, a partilha de atualizações sobre questões ou problemas técnicos e a coordenação de quaisquer configurações ou alterações necessárias. Normalmente, a frequência de comunicação é mais elevada na fase de planeamento e análise. Durante a fase de implementação, tenha contactos ou reuniões regulares para assegurar uma coordenação suave.

Recursos

A gestão de recursos é efetivamente crucial para uma migração com êxito. Eis alguns aspetos-chave a considerar quando se trata da gestão de recursos durante uma migração:

• Identificação de recursos: Identifique os recursos necessários para o projeto de migração, incluindo indivíduos ou equipes responsáveis por tarefas como preparativos pré-migração, migração de dados, testes, implantação, configuração e suporte pós-migração. Determine as competências, conhecimentos e disponibilidade específicos necessários para cada função.
• Alocação de recursos: atribua recursos a funções e tarefas com base na capacidades, disponibilidade e capacidade de carga de trabalho do recurso. Certifique-se de que os recursos são alocados adequadamente para balancear a carga de trabalho e cumprir os prazos do projeto. Considere quaisquer dependências ou restrições que possam afetar a alocação de recursos, tais como recursos partilhados entre vários projetos.
• capacidades desenvolvimento e formação: Avaliar as lacunas de capacidades e conhecimento dentro da equipa e fornecer oportunidades de treinamento ou aperfeiçoamento necessárias para garantir que os recursos estejam adequadamente equipados para as tarefas atribuídas. Isto poderá envolver o fornecimento de sessões de preparação, workshops ou acesso a recursos e a documentação relevantes.
• Comunicação e colaboração: Promover uma comunicação e colaboração eficazes entre os recursos envolvidos na migração. Incentive as atualizações de estado regulares, as reuniões de coordenação e a partilha de conhecimento para garantir que todos os membros da equipa estão alinhados, informados e que a trabalhar em conjunto para objetivos comuns.
• Planos de contingência: Antecipar potenciais restrições ou riscos de recursos e desenvolver planos de contingência. Ter recursos de cópia de segurança identificados ou com preparação transversal em funções críticas para mitigar quaisquer desafios imprevistos, tais como ausências inesperadas ou limitações de recursos.
• Envolvimento das partes interessadas: mantenha as partes interessadas, como proprietários de aplicativos, chefes de departamento e gerência, informadas sobre a alocação de recursos e qualquer impacto potencial nos cronogramas ou resultados. Comunique regularmente atualizações de recursos, relatórios de progresso e quaisquer ajustes aos planos de recursos para gerir as expetativas e manter a transparência.

Migração individual de objetos

A distinção entre a aplicação e a solução é importante. A exportação e importação de uma aplicação só afeta esse objeto. Uma solução é um contentor que pode ter várias aplicações, fluxos e outros objetos.

Exportar e importar uma aplicação de tela (forma legada)

Os passos detalhados são documentados em Exportar um pacote da aplicações de tela e Importar um pacote de aplicações de tela.

Este método de exportar aplicações é uma forma legada. Apesar de ser suportado, recomendamos que utilize soluções. As soluções permitem-lhe migrar vários componentes, em vez de apenas um recurso.

Exportar e importar fluxo (forma legada)

Os seguintes passos descrevem como exportar um fluxo.

1. Selecione o menu "...", selecione Exportar e selecione Pacote (.zip).
2. Introduza um nome e uma descrição para o pacote. Em seguida, pode configurar as predefinições e adicionar comentários que estejam acessíveis durante a fase de importação.
3. Selecione o botão Exportar no canto inferior direito para transferir o pacote. Se a transferência não iniciar automaticamente, poderá selecionar o botão Transferir.

Os seguintes passos descrevem como importar um fluxo.

1. Selecionar o botão Importar.
2. Carregue o ficheiro do pacote e aguarde que o ecrã mostre os detalhes do pacote.
3. Ao configurar as definições do fluxo, pode optar por criar um novo fluxo ou atualizar um fluxo existente com a definição de fluxo a partir do pacote.
4. Selecione as ligações necessárias para configurar o fluxo. Deverá ver o botão Importar disponível depois de ter configurado com êxito todas as definições necessárias.

Depois de ter importado o fluxo, tem de ser ativado. Se o fluxo tiver referências de ligação, o utilizador que o ativar tem de ter acesso a essas ligações. Caso contrário, o proprietário da ligação poderá conceder acesso ao utilizador da ativação.

Este método de exportar fluxos de cloud é uma forma legada. Apesar de ser suportado, recomendamos que utilize soluções que lhe permitam migrar vários componentes, em vez de apenas um recurso.

Exportar e importar uma aplicação condicionada por modelo

Uma aplicação condicionada por modelo faz sempre parte de uma solução. A aplicação empacotada, incluída no ficheiro de solução (.zip), pode ser partilhada com os utilizadores com base nos respetivos direitos de acesso depois de ter sido exportada com êxito do ambiente de origem e importada para o ambiente de destino.

Os processos passo a passo detalhados estão abrangidos em Exportar uma solução e Importar uma solução.

Exportar e importar um bot do Microsoft Copilot Studio

Pode exportar e importar bots através de soluções. Uma lista detalhada de passos está abrangida em Exportar e importar bots utilizando soluções.

Exportar e importar site do Power Pages

Migrar páginas envolve exportar a configuração existente a partir do ambiente de origem do Microsoft Dataverse e importá-los para o ambiente do Dataverse de destino. Existem alguns passos de pré-requisitos que têm de ser efetuados no ambiente de destino. Quando o trabalho de preparação estiver concluído, é possível exportar os dados de configuração do portal utilizando a ferramenta de migração de configuração.

Aplicação Formulário do SharePoint — caso especial para ambiente predefinido

SharePoint Os aplicativos de formulário podem ser associados a apenas um ambiente e, se não configurados de outra forma, estão no ambiente padrão. Uma migração de todas as aplicações requer que a definição do destino seja um ambiente diferente, em vez do ambiente predefinido. Os formulários personalizados existentes não migram automaticamente para o ambiente recém-designado. Só os ambientes de produção podem ser designados para formulários personalizados do SharePoint. Segue-se o processo manual, como mover uma aplicação de tela.

Criar cópia de segurança de objetos do Microsoft Power Platform

A maioria dos objetos do Microsoft Power Platform são exportados como ficheiros zip. Caso contrário, têm, pelo menos, um formato de ficheiro. Estes ficheiros no formato original, como um ficheiro zip ou seja qual for a extensão com que são fornecidos, podem ser adicionados a qualquer localização de armazenamento de ficheiros ou a um repositório à sua escolha. Algumas opções a mencionar são o Azure DevOps, o GitHub, o SharePoint, o One Drive ou qualquer outra solução que suporte todos os formatos de ficheiro.

Opções de migração em massa

A migração de uma aplicação ou de um fluxo tem êxito se funcionar da mesma forma que anteriormente. No entanto, existem determinados elementos que não podem ser transferidos:

• Dados de execução de fluxo sobre as execuções anteriores do fluxo - Os dados sobre execuções de fluxo são armazenados apenas por 28 dias. Se precisar dos dados, os dados podem ser exportados e armazenados utilizando o Kit de Iniciação CoE ou se tiver configurado o Exportar para Data Lake. A versão mais recente do Kit de Iniciação CoE tem os dados de execução de fluxo se for utilizada com a Exportação de Dados.
• Versões do aplicativo canvas- À medida que os criadores iteram através do processo de desenvolvimento, pode haver várias versões criadas. As versões anteriores não podem ser migradas. Só é possível migrar a versão mais recente.
• Dados acessados pelo aplicativo ou fluxo ou usando conectores - Somente metadados do aplicativo são incluídos como parte da exportação.

Quaisquer comentários de colaboração feitos na aplicação ou no fluxo também não são incluídos.

Este artigo descreve algumas possibilidades. É importante que considere cuidadosamente as implicações e as vantagens de cada possibilidade antes de decidir.

Migrar tudo — opção de cópia de segurança e restauro da base de dados

À semelhança da maioria dos tipos de ambiente, também é criada uma cópia de segurança do ambiente predefinido. Estas cópias de segurança do sistema são efetuadas automaticamente. Não existe nenhuma opção a pedido para o ambiente predefinido, pelo que requer um pedido de suporte. A cópia de segurança pode ser restaurada num novo ambiente, o que mantém todos os dados no Dataverse. Esta opção só serve para mostrar ao leitor sobre a sua existência e educá-lo sobre o que considerar. Não deve ser considerado como a escolha primária, pois só produziria migração parcial.

• Suportado: Dataverse, Aplicações Dynamics
• Não totalmente suportado: aplicativo Canvas, biblioteca de componentes, páginas personalizadas, Power Automate Microsoft Copilot Studio

Não totalmente suportado indica que pode haver uma potencial perda de dados durante a migração e podem ser necessários mais passos.

Migrar metadados e, em seguida, dados

Uma abordagem recomendada é a utilização de soluções para mover os metadados e, em seguida, é possível utilizar fluxos de dados, o Azure Data Factory ou outra ferramenta preferencial para transferir dados. A automatização completa, do início ao fim, pode não ser possível em todos os casos, devido aos diversos conectores, mas é possível uma aproximação.

A um nível elevado, os passos são:

1. Adicionar uma aplicação a uma solução.
2. Adicionar fluxo a uma solução.
3. Adicionar bots existentes.
4. Ajustar as referências de ligação em aplicações e fluxos.
5. Procurar dependências de solução e adicionar objetos.
6. Exportar a solução
7. Importar a solução.
8. Transferir dados.

Procurar por dependências de solução

O sucesso de uma importação de solução no ambiente de destino só pode ser assegurado quando tiver adicionado todos os componentes relacionados à solução ou se estiverem disponíveis no ambiente de destino. Se faltarem componentes, é provável que a importação da solução falhe. Para garantir que todos os componentes necessários estão presentes, há melhores opções se utilizadas em combinação:

• Adicione manualmente os componentes selecionados à solução. Neste caso, assume-se que sabe que todos os componentes dependentes já estão disponíveis no ambiente de destino.

• Utilize o botão mostrar dependências a partir da solução para permitir que o sistema identifique dependências por si. Pode adicionar todas as dependências ou adicionar seletivamente apenas as dependências que não existem no ambiente de destino.

  

Adicionar um componente a uma solução (manual)

Assumindo que uma solução é criada, um criador precisa de utilizar a opção de menu Adicionar componente existente para adicionar uma aplicação, fluxo ou bot existente.

Ajustar referências de ligação

As aplicações de tela e fluxos lidam com ligações de forma diferente. Os fluxos usam referências de conexão para todos os conectores, enquanto os aplicativos de tela só as usam para conexões (não)OAuth compartilhadas implicitamente, como a autenticação do SQL Server.

Atualizar uma aplicação para utilizar referências de ligação em vez de ligações

As aplicações de tela que não suporte soluções quando adicionadas a uma solução não serão automaticamente atualizadas para utilizar referências de ligação. As referências de ligação ficam associadas a aplicações de tela apenas no momento em que uma origem de dados é adicionada à app. Para atualizar aplicações, tem de:

1. Adicionar uma aplicação que não suporte soluções a uma solução.
2. Remover a ligação da aplicação.
3. Criar uma nova referência de ligação na solução.
4. Adicionar uma ligação que contenha uma referência de ligação associada.

Atualizar um fluxo para utilizar referências de ligação em vez de ligações

Quando um fluxo não está numa solução, utiliza ligações. Se esse fluxo for adicionado a uma solução, continua a utilizar ligações inicialmente. Os fluxos podem ser atualizados para utilizar referências de ligações, em vez de ligações, de uma de duas maneiras:

• Se o fluxo for exportado numa solução não gerida e importada, as ligações são removidas com referências de ligação.

• Quando um fluxo de solução é aberto, o verificador de fluxos na página de detalhes do fluxo mostra um aviso para utilizar referências de ligação. A mensagem de aviso tem uma ação que pode selecionar para Remover ligações para que seja possível adicionar referências de ligação. Selecionar essa ação remove as ligações do acionador e as ações no fluxo, e permite a seleção e criação de referências de ligação.

Adicionar um objeto a uma solução (automatização)

Pode utilizar os comandos do PowerShell para mover aplicações em massa para uma solução. A adição de aplicações de tela e fluxos de cloud pré-existentes a soluções também pode ser feito através da linha de comandos. Instale os módulos do PowerShell mais recentes para experimentar esta opção. Os dois comandos principais são Set-PowerAppAsSolutionAware e Set-FlowAsSolutionAware.

Depois de instalados os módulos, insira o seu próprio ID de ambiente, ID da aplicação, ID do fluxo e ID da solução.

Para uma aplicação de tela:

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

Para um fluxo:

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

As referências de conexão são entradas de dados na tabela referência de ligação. A utilização da referência de ligação como parte da aplicação ou do fluxo requer uma modificação da aplicação central ou da definição do fluxo. Tem de substituir o nó connectionReferences pela referência de ligação.

Exportação e importação da solução

Assumindo que as soluções estão prontas, a fase seguinte da automatização pode ser feita de várias formas:

• Exporte e importe manualmente as soluções para o ambiente de destino.

• Utilize pacotes para mover várias soluções de uma só vez.

• Utilize tarefas de ferramentas de compilação do Power Platform para efetuar várias operações, como empacotar solução, desempacotar solução, exportar solução e importar solução. O DevOps fornece a capacidade de automatizar a gestão do ciclo de vida das aplicações (ALM) e estas tarefas são todas criadas para suportar ALM para Microsoft Power Platform.

A Interface da Linha de Comandos (CLI) do Power Platform também fornece opções para exportar e importar soluções. Todos os comandos relacionados com a solução podem ser utilizados para criar, exportar e importar soluções. Também pode utilizar a CLI para transferir e carregar dados.

Uma opção amigável para criadores é utilizar pipelines destinados a democratizar o ALM para Power Platform. Reunir as capacidades de automatização de ALM e integração contínua/implementação contínua (CI/CD) num único serviço de caraterísticas é mais acessível para todos os criadores, admins e programadores.

Criar ligações (manual)

No ambiente de destino antes de a operação de importação ser definida, crie as ligações em falta necessárias para a aplicação ou o fluxo. Para obter mais informações sobre como criar ligações, consulte Gerir ligações no Power Automate.

Migração de dados

Existem várias opções disponíveis para migração de dados, desde a automatização manual à automatização completa.

• Exporte e importe manualmente os dados utilizando livros do Excel.
• É possível desenvolver um fluxo de cloud do Power Automate para extrair dados de tabelas de origem e escrever diretamente para o destino. No entanto, isto requer que o criador utilize o Dynamics 365 Connector ou o conector Dataverse (legado). Atualmente, o conector Dataverse não suporta a ligação entre ambientes. Esta caraterística está planeada para o futuro e, depois de lançada, pode ser utilizada para mover dados de um para o outro.
• A Ferramenta de Migração de Configuração (CMT) é uma ferramenta usada para migração de portal, mas também pode ser usada para migração regular de dados. A CMT também pode ser utilizada com o PowerShell. A ferramenta PAC CLI dá a capacidade de chamar a CMT.
• Os fluxos de dados podem ser utilizados para criar mapeamentos entre os ambientes e utilizados para mover dados. O conector Web HTTP pode ser utilizado como alternativa ao Dataverse.
• O Azure Data Factory pode ser utilizado com o conector Dataverse para solicitar dados da origem e inseri-los no destino.

Tendo em conta que o ambiente predefinido está limitado em tamanho, uma das opções acima deverá ser suficiente para mover dados para fora do ambiente predefinido.

Considerações de limpeza

Uma limpeza é uma boa ideia para aplicações e fluxos que não são utilizados e atualizados há muito tempo. Existem vários caminhos que um administrador deve considerar no que diz respeito à limpeza.

• Decida a ordem de importação dos dados. As tabelas menos dependentes vão primeiro e as mais dependentes vão no fim.
• Nem todos os campos precisam de ser mapeados. Campos como Versão, Data de modificação, Criado na data e alguns outros campos de sistema não precisam de ser mapeados.
• Se quiser preservar o Criado na data original, utilize mapear a origem do campo Criado na data para o campo OverRiddenCreatedOn na tabela de destino.
• Não é possível migrar dados de auditoria.
• Não ative fluxos de trabalho ou fluxos que são acionados com base na inserção de dados, a menos que seja o pretendido. Isto aumenta o tempo da migração de dados.

Opções de identificação

Atualmente, o Kit de Iniciação CoE não tem uma opção de identificação. No entanto, poderia ser uma personalização que poderia adicionar ao Kit de Iniciação.

Crie uma tabela denominada Etiquetas e configure uma relação muitos-para-muitos (N:N) com a aplicação, fluxos e outras tabelas de inventário. Em seguida, pode criar uma etiqueta e associar estes registos aos itens de inventário apropriados. Para uma melhor experiência de utilizador, pode incorporar uma grelha no formulário Principal de aplicações, fluxos e outras tabelas de inventário. Esta opção é recomendada, uma vez que tem consistência referencial.

Crie um campo de texto em cada tabela de inventário e utilize-o para capturar o texto (etiqueta) que poderá utilizar posteriormente.

Se pretender uma lista mais fixa, crie um conjunto de opções global e adicione-o a todas as tabelas de inventário e também os respetivos formulários.

Opção de quarentena

Se não tiver a certeza da necessidade de determinadas aplicações, pode tentar isolá-las durante algum tempo e colocá-las em quarentena durante este estado. A aplicação só pode ser utilizada pelo proprietário. Depois de decorrido um período de tempo adequado, se não tiver sido recebida nenhuma resposta do proprietário, poderá removê-las do ambiente.

Os fluxos não suportam o estado da quarentena, mas é possível utilizar uma abordagem semelhante para parar o fluxo e verificar se o fluxo é novamente ativado pelo proprietário.

Em ambos os casos, é importante ter uma comunicação adequada com o proprietário.

Opção Só Eliminar

Se, na verdade, não houver perda de produtividade e reutilização de objetos, esta é a melhor opção. A maioria dos fluxos de teste e aplicações enquadra-se nesta categoria.

Neste caso, após a identificação da lista de objetos, é possível desenvolver um lote do PowerShell e uma lista de csv é-lhe transmitida, o que eliminaria todos os recursos.

À medida que percorre os IDs de aplicações e fluxos, o comando seguinte pode ser utilizado para removê-los do ambiente predefinido.

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

Opção de Cópia de segurança e Eliminação de objetos

Como exemplo, suponha que um fluxo do Power Automate é criado para abordar uma necessidade sazonal específica, mas que não é utilizado há muito tempo. Neste caso, é bom criar uma cópia de segurança do componente antes de o eliminar.

Para criar uma cópia de segurança do componente, é possível utilizar a opção de migração individual ou de migração em massa para gerar uma solução exportada. Esta pode ser adicionado a um repositório de ficheiros à sua escolha ou a uma localização do OneDrive.

Depois de a cópia de segurança estar protegida, poderá aplicar a opção Eliminar para concluir o processo de limpeza.

Em muitos casos, tratam-se de fluxos e aplicações de teste criados por criadores como parte da sua aprendizagem de produtividade e experimentação pessoal.

Conclusão

O Power Platform é uma ferramenta para programadores cidadãos e para programadores profissionais. A utilização do ambiente predefinido deve focar-se principalmente na produtividade pessoal utilizando produtos do Microsoft 365. Todas as outras aplicações e o desenvolvimento de fluxos devem ocorrer em ambientes de programação, individuais ou partilhados designados. Uma recomendação importante é desenvolver uma estratégia de ambiente independente baseada na DLP, o que pode ajudar os criadores a desenvolver as aplicações e os fluxos no ambiente certo. Além disso, poderá beneficiar bastante do estabelecimento de uma estratégia de comunicação e de fornecer aos utilizadores modelos de gestão personalizada de aprendizagem sobre a estratégia, implementação de soluções e melhores práticas para desenvolver aplicações e fluxos. Uma boa adição é a captura de algumas histórias de êxito no site de comunicação. Histórias de sucesso publicadas internamente para ajudar os criadores a ligar-se a ideias e apresenta-lhes possibilidades que poderiam ser alcançadas através da utilização do Power Platform.

Uma estratégia de governação forte é essencial ao migrar ou mover objetos específicos. Existem várias estratégias disponíveis para migrar objetos, incluindo a migração individual e em massa. A opção mais adequada depende das políticas da nossa organização. As soluções são a forma mais recomendada de organizar os componentes da sua aplicação e simplificar as migrações.