Migrando aplicativos e fluxos do ambiente padrão

Este white paper explica como organizações e administradores podem planejar a migração de seus aplicativos e fluxos do ambiente padrão.

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

Observação

Você pode salvar ou imprimir este white paper selecionando Imprimir no seu navegador e, em seguida, selecionando Salvar como PDF.

Ambiente padrão

Um ambiente padrão é criado por locatário e é acessível por todos os usuários nesse locatário. O ambiente padrão é criado na região mais próxima à região padrão do locatário do Microsoft Entra e é nomeado da seguinte forma: [Nome do locatário do Microsoft Entra] (padrão). Sempre que um novo usuário se inscreve no Power Apps ou no Power Automate, ele é automaticamente adicionado à função Criador do ambiente padrão. Nenhum usuário é adicionado à função Administrador de Ambiente do ambiente padrão automaticamente.

Você não pode excluir o ambiente padrão e não pode fazer backup manualmente do ambiente padrão. Os backups do sistema são feitos de forma contínua. O ambiente padrão é limitado a 1 TB de capacidade de armazenamento. O ambiente padrão possui os seguintes recursos:

• Capacidade do banco de dados do Dataverse de 3 GB
• Capacidade do arquivo do Dataverse de 3 GB
• Capacidade do log do Dataverse de 1 GB

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

No ambiente padrão, os funcionários de uma organização com uma licença do Microsoft 365 podem criar aplicativos e fluxos de nuvem. O ambiente padrão se torna o primeiro estúdio de playground para esses funcionários começarem a construir seus aplicativos e fluxos. Como não é possível remover a função de criador de ambiente do ambiente padrão, os criadores começam a criar aplicativos e fluxos de produtividade pessoal e a compartilhá-los dentro de suas equipes para que outros possam se beneficiar. A maioria das organizações frequentemente renomeia o ambiente padrão para Produtividade Pessoal.

Os administradores descobrem de forma reativa que muitos aplicativos e fluxos são criados no ambiente padrão. Pode não ser apropriado que um aplicativo ou fluxo esteja no ambiente padrão em cenários como:

• Um aplicativo é compartilhado com muitos usuários em comportamento semelhante ao de produção.
• Um aplicativo usa pastas de trabalho do Excel com dados confidenciais.
• Um aplicativo, baseado em listas do SharePoint, recebe muitas interações de dados, como inserções ou atualizações.
• Um aplicativo ou fluxo está usando conectores que não são permitidos em novas políticas de prevenção contra perda de dados (DLP).
• Os conectores personalizados são ativados e usados ​​no ambiente padrão, em vez de serem protegidos em um ambiente dedicado.

Vale a pena considerar os cenários acima e fornecer uma indicação de que você deve começar a mover esses aplicativos e fluxos do ambiente padrão para o seu próprio ambiente de desenvolvedor ou outro ambiente compartilhado. Outros fatores que entram em jogo são as limitações associadas ao ambiente padrão.

As equipes do Centro de Excelência (CoE) que monitoram o Power Platform são forçadas a reagir quando os limites são atingidos, o que afeta negativamente os aplicativos que estão em execução no ambiente padrão. Essa limitação também pode ser algo que um administrador ou a equipe do CoE precise realizar regularmente. Há três estágios amplos:

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

Existem diferentes maneiras de exportar seus aplicativos e fluxos para movê-los para um novo ambiente. As soluções são um único arquivo que pode incluir quase tudo o que seus criadores constroem no Power Platform e movem juntos. Aplicativos de tela e fluxos de nuvem podem ser exportados diretamente.

Com o tempo, os objetos do Power Platform evoluíram para apresentarem reconhecimento da solução. Agora, os aplicativos e fluxos podem ter reconhecimento de solução por padrão, embora isso exija ativação manual. Os criadores ainda podem criar aplicativos e fluxos de make.powerapps.com e make.powerautomate.com, que podem ser classificados como sem reconhecimento de solução, e podem ser exportados individualmente ou adicionados a uma solução. Ao adicionar uma solução, o criador pode aproveitar variáveis ​​de ambiente e referências de conexão para configurar e implantar pontos de extremidade em ambientes.

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

Identificação dos objetos do Power Platform

A primeira etapa é identificar aplicativos, fluxos e ativos que precisam ser movidos ou limpos. O Kit de Início do CoE fornece um inventário de todos os aplicativos e fluxos, e os relatórios do Power BI ajudam a determinar o uso. Esta etapa ajuda a avaliar o uso do aplicativo e deve ajudar a rotulá-los. Ao realizar o exercício, marque os aplicativos e fluxos que devem ser migrados para outro ambiente. Uma tag pode ser baseada nos conectores usados, na localização do usuário, no departamento do usuário e assim por diante. Este artigo também descreve um método para reconhecer itens que devem ser limpos ou realocados com base em práticas de prevenção contra perda de dados (DLP).

Mover os objetos do Power Platform

Se o componente estiver marcado para ser movido para um ambiente diferente, há opções disponíveis para mover o aplicativo. Uma mudança é um processo interativo e precisa de algum nível de interação do criador. O nível de complexidade para mover um aplicativo ou fluxo aumenta com a combinação de componentes usados ​​para construir o aplicativo ou o fluxo.

Por exemplo, um aplicativo com seis telas possui 10 botões em várias telas. Vamos supor que cada um desses 10 botões chame um fluxo individual. Existem também alguns fluxos que são acionados diariamente para corrigir dados ou integrá-los a outro sistema. Suponhamos também que exista um modelo de processamento de imagem do AI Builder que é usado como parte da automação. Para mover esse aplicativo, todos os componentes devem ser adicionados a uma solução e as referências de conexão devem ser ajustadas corretamente e testadas antes de confirmar a conclusão.

Em outro caso, suponha que haja um aplicativo de tela que usa uma conexão do Office 365. Nesse caso, o criador só precisa adicionar o aplicativo de tela à solução.

Limpar os objetos do Power Platform

Se um componente estiver marcado para limpeza, existem duas opções principais. A primeira opção é excluí-lo diretamente e a segunda opção é excluí-lo após fazer um backup. Neste último caso de backup, pode haver alguma sobreposição de etapas coincidentes com objetos em movimento.

Por exemplo, os administradores da Equipe CoE descobrem que a maioria dos criadores cria aplicativos e fluxos de teste para fins de aprendizagem. Os criadores então abandonam os aplicativos e fluxos, o que pode ser confirmado observando as métricas de uso. Outra maneira é colocar um aplicativo em quarentena. Se ninguém abordar você sobre o aplicativo, ele também poderá ser excluído.

Manter uma estratégia de comunicação desempenha um papel fundamental. Os administradores devem planejar a comunicação:

• Estabelecer conexões que os criadores precisam permitir ao lançar o aplicativo no novo ambiente.
• A nova URL do aplicativo do ambiente de destino.
• Navegue até o ambiente correto.

Algumas dessas soluções para realocar objetos são prontas e podem exigir uma licença do Power Apps e do Power Automate que permitem aos usuários criar e executar aplicativos em fontes de dados que se estendem além do Microsoft 365.

Estratégias

Todo o processo de identificação e movimentação de aplicações e fluxos do ambiente padrão tem mais probabilidades de ser bem sucedido quando se baseia numa estratégia. Existem várias estratégias que você deve considerar.

Estratégia de DLP

As políticas de prevenção contra perda de dados (DLP) funcionam como proteções para ajudar a evitar que os usuários exponham dados organizacionais acidentalmente e manter a segurança das informações no locatário. As políticas DLP impõem regras para as quais conectores são habilitados para cada ambiente e define quais conectores podem ser usados juntos. Os conectores são classificados como somente dados corporativos, nenhum dado corporativo permitido, ou bloqueado. Um conector no grupo somente dados corporativos só pode ser usado com outros conectores desse grupo no mesmo aplicativo ou fluxo. Recomendamos que você tenha pelo menos uma política.

Identificação dos objetos usando DLP

A identificação baseada em políticas DLP é útil para definir ambientes de destino para seus aplicativos e fluxos. Pode haver aplicativos ou fluxos que usam um conector bloqueado pelo DLP ou uma combinação de conectores comerciais e não comerciais que, após a ativação do DLP, param de funcionar.

Para evitar o tempo de inatividade de possíveis objetos críticos, devido ao DLP, parte do Kit de Início do CoE, você pode encontrar Ferramenta do editor DLP (análise de impacto). A meta do editor DLP é permitir que os administradores vejam o impacto das políticas existentes ou o impacto potencial das alterações nas políticas. Ela fornecer a administradores uma exibição de aplicativos e fluxos afetados, e recursos que seriam desabilitados se políticas novas ou atualizadas fossem impostas. O aplicativo pode ser usado para revisar políticas existentes, alterar políticas existentes e mitigar riscos, entrando em contato com os criadores e informando-os sobre o melhor curso de ação para seu aplicativo ou fluxo.

Atualize as políticas de DLP existentes para analisar o impacto. Siga o artigo Estabelecendo a higiene do locatário com o Kit de início do CoE para encontrar mais informações sobre o editor DLP.

Antes de ativar o recurso DLP, você pode identificar quais aplicativos e fluxos são afetados e alertar os criadores. O editor DLP pode enviar uma lista de todos os aplicativos e fluxos afetados para um endereço de email, o que gera um arquivo .csv para cada tipo de objeto.

Usando o editor DLP versão 2.0, na área Análise de Impacto, escolha Exporte aplicativos e fluxos afetados para CSV.

Cada arquivo csv gerado (flow.csv e apps.csv) contém informações sobre:

1. Nome dos aplicativos e fluxos.
2. Proprietário dos aplicativos e fluxos.
3. Email do proprietário dos aplicativos e fluxos.
4. Todas as conexões usadas pelos aplicativos e fluxos.
5. ID dos aplicativos e fluxos para identificar o objeto.
6. ID do ambiente onde os aplicativos e fluxos estão localizados.

Observe que as Conexões fornecem a lista de todas as conexões usadas pelo aplicativo ou fluxo. Caso seja necessário identificar exatamente qual conector é impactado pela DLP em questão, é necessária uma automação neste momento. Estamos avaliando mudar essa situação na ferramenta.

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

1. Criar um fluxo do Power Automate.

2. Use o conector Obter Política DLP de Locatário especificando o DLP em questão.

3. O resultado são duas matrizes, dados comerciais e dados não comerciais. Por exemplo, o conector do Twitter mostra este código:

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

4. Nessa lista, você tem acesso ao nome do conector que corresponde à lista de nomes do aplicativo csv ou coluna Conexão do fluxo.

5. Ao converter o formato csv para Excel e colocá-lo em seu OneDrive, você pode ler todos os aplicativos e fluxos afetados do Power Automate. Verifique qual conexão é afetada com base na lógica que compara conexões com nomes de conectores.

6. Depois de ter uma correspondência sobre qual conexão está causando o impacto, gere uma nova lista com o ID do aplicativo ou fluxo e o conector afetado pela DLP.

7. Use as informações anteriores para notificar o criador sobre o impacto futuro. Você pode usar Power Cards para coletar feedback do criador se o aplicativo ou fluxo puder ser excluído ou precisar ser migrado para outro ambiente.

Com base na sua análise, se você determinar que os fluxos afetados não estão sendo usados, poderá colocá-los em quarentena e enviar um email ao criador com instruções sobre como movê-los para um ambiente diferente. Isso incentiva uma cultura do tipo faça você mesmo e elimina TI sombra. Em algumas situações, talvez você queira isentar alguns objetos da DLP. Por exemplo, talvez você queira aplicar uma DLP específica apenas para novos recursos que foram 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, sua estratégia de ambiente é definida por meio de DLP e fornece um destino para os aplicativos e fluxos desenvolvidos no ambiente padrão.

Estratégia do ambiente

Desenvolver uma estratégia de ambiente exige configurar ambientes e outras camadas de segurança de dados de forma a permitir o desenvolvimento produtivo na sua organização, enquanto protege e organiza os recursos. Uma estratégia para gerenciar o provisionamento do ambiente, gerenciamento de acesso e controlar recursos dentro deles é importante para:

• Proteger os dados e o acesso.
• Governar o ambiente padrão de maneira compatível.
• Gerenciar o número correto de ambientes para evitar a proliferação e conservar a capacidade.
• Facilitar e implementar o gerenciamento do ciclo de vida do aplicativo (ALM).
• Organizar recursos em partições lógicas.
• Oferecer suporte a operações (e helpdesk) de identificação de aplicativos em produção, colocando-os em ambientes dedicados.
• Garantir que os dados estão sendo armazenados e transmitidos em regiões geográficas aceitáveis (por motivos de desempenho e conformidade).
• Garantir o isolamento dos aplicativos em desenvolvimento.
• Ativação de serviços de faturamento interno para usuários finais de negócios ou unidades de negócios que consomem os serviços.

Você deve ter departamentos bem estabelecidos que possam ser autossustentáveis ​​e ter processos de ALM existentes em vigor. Nesses casos, os ambientes proporcionam isolamento e organizam os recursos com base no departamento. Uma estratégia baseada nisso pode ser alcançada criando ambientes separados para cada departamento. Esses ambientes tornam-se então o destino dos aplicativos e fluxos no ambiente padrão.

Estratégia de comunicação

A comunicação eficaz é crucial durante um processo de migração. A comunicação acontece em todas as fases do processo de migração. A comunicação clara promove a compreensão e a colaboração entre as partes interessadas. Permite o fluxo suave de informações, garantindo que todos os envolvidos estejam 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 seja tranquilo para os criadores, partes interessadas e liderança. Desenvolva uma estratégia sobre a melhor forma de comunicar e em que pontos você precisa se comunicar, que forneça consistência em seus objetivos e ajude na comunicação para todos os envolvidos. Algumas opções a serem consideradas incluem:

• Use o Kit de início do CoE como um rastreador de ativos.
• Adicione fluxos de nuvem personalizados para enviar notificações em vários estágios.
• Crie modelos de email que serão enviados para comunicação com os criadores.

Itens para serem considerados:

• Alteração na URL do aplicativo. Os usuários do aplicativo precisam atualizar todos os marcadores de um aplicativo no ambiente padrão.
• Se houver um fluxo de gatilho HTTP baseado em URL, ele deverá ser atualizado em fluxos dependentes para garantir que ainda atue como um webhook.
• Forneça etapas detalhadas para estabelecer conexões assim que a mudança for concluída para criadores e usuários do aplicativo. Os usuários não devem se preocupar em criar uma conexão ao iniciar o aplicativo pela primeira vez no novo ambiente.

Um bom começo para configurar comunicações requer um modelo de autoatendimento que seja dimensionado e seja mais em tempo real para os usuários do que apenas deixá-lo no email de um único usuário ou em uma lista de distribuição. Se você planeja estabelecer um site do SharePoint, há um modelo disponível que você pode usar para criar um hub interno do Microsoft Power Platform. O hub torna-se o local comum para aprender sobre estratégia e orientação, para que os criadores possam tomar decisões corretas sobre o que pretendem construir e onde devem ir para fazer.

Existem alguns componentes de solução existentes, como configurar componentes de notificações de inatividade e configurar componentes de Conformidade do Desenvolvedor no Kit de início do CoE que você pode aproveitar. Esses componentes vêm com modelos de email e podem ser duplicados para atender ao seu propósito e necessidade de migrá-los do ambiente padrão. Uma boa vantagem é capturar também algumas histórias de sucesso no site de comunicação.

Públicos-alvo

No processo de migração, normalmente existem diferentes públicos envolvidos na comunicação. Aqui estão as principais partes interessadas mais típicas e suas funções:

• Proprietários de aplicativos: Proprietários de aplicativos são indivíduos ou equipes responsáveis pelo desenvolvimento, manutenção e geranciamento de aplicativos específicos. Eles têm conhecimento profundo da funcionalidade, do fluxo de trabalho e da configuração de seus aplicativos. A comunicação com os proprietários de aplicativos é crucial para compreender os requisitos específicos de seus aplicativos, coletar feedback, abordar preocupações e garantir uma migração tranquila de seus aplicativos para o novo ambiente.
• Usuários de aplicativos: Usuários de aplicativos são indivíduos que utilizam os aplicativos regularmente para executar suas tarefas ou fluxos de trabalho. Eles podem ter vários níveis de conhecimento técnico e familiaridade com as aplicações. A comunicação com os usuários do aplicativo é importante para informá-los sobre a migração, fornecer atualizações sobre quaisquer alterações ou interrupções que possam ocorrer, oferecer treinamento ou suporte para garantir uma transição perfeita e minimizar qualquer impacto nas suas operações diárias.
• Chefes ou gerentes de departamento: Chefes ou gerentes de departamento desempenham um papel significativo no processo de migração, pois supervisionam as operações e os objetivos estratégicos de seus respectivos departamentos. Eles precisam ser informados sobre a linha do tempo da migração, os possíveis impactos e benefícios. A comunicação com os chefes de departamento permite que vocês forneçam as orientações necessárias, alinhar a migração com os objetivos departamentais e garantir uma coordenação tranquila dentro das suas equipes.
• Equipes de TI ou técnicas: As equipes de TI ou técnicas são responsáveis pela infraestrutura, sistemas e aspectos técnicos gerais da migração. Eles estão envolvidos no planejamento, execução e suporte do processo de migração. A comunicação com as equipes de TI é essencial para discutir requisitos técnicos, dependências, considerações de segurança e quaisquer alterações necessárias na infraestrutura ou na configuração que precisam ser implementadas para uma migração bem-sucedida.
• Equipes de segurança e conformidade: As equipes de segurança e conformidade desempenham um papel fundamental para garantir a segurança dos dados, a privacidade e a conformidade regulatória durante a migração. Eles fornecem orientação e garantem que medidas adequadas estejam em vigor para proteger informações confidenciais. A comunicação com as equipes de segurança e conformidade envolve a discussão de requisitos de segurança, protocolos de criptografia, controles de acesso e quaisquer considerações relacionadas à conformidade durante todo o 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. Eles podem não exigir informações técnicas detalhadas, mas devem estar cientes dos objetivos do projeto, do progresso e dos impactos potenciais na organização. A comunicação com a gerência executiva ajuda a garantir o seu apoio, o alinhamento com os objetivos estratégicos e a alocação de recursos para a migração.

É importante adaptar estratégias e mensagens de comunicação para cada público, considerando suas necessidades, preocupações e nível de conhecimento técnico específicos. A comunicação clara e oportuna com todas as partes interessadas promove a colaboração, garante uma coordenação tranquila e mitiga quaisquer desafios potenciais durante o processo de migração.

Cadência

A cadência ou frequência da comunicação com as partes interessadas durante um processo de migração varia de acordo com as necessidades e dinâmicas específicas do projeto. É importante estabelecer uma comunicação regular e consistente para manter as partes interessadas informadas, abordar as preocupações e manter o alinhamento durante toda a migração. Aqui estão algumas considerações para determinar a cadência da comunicação com diferentes partes interessadas:

• Proprietários de aplicativos: Manter 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 de aplicações na tomada de decisões, quando necessário. A frequência da comunicação pode variar dependendo da complexidade e da criticidade do aplicativo, mas é recomendável fazer check-ins regulares e respostas oportunas às dúvidas.
• 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. Isso deve incluir anúncios, emails, boletins informativos ou até mesmo sessões de treinamento ou workshops dedicados. A frequência da comunicação com os usuários do aplicativo pode variar, mas é crucial fornecer atualizações nos principais marcos, informá-los sobre quaisquer alterações ou interrupções que possam afetá-los e oferecer suporte e orientação durante todo o processo.
• Chefes e gerentes de departamento: A comunicação com 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. Fornece atualizações periódicas sobre o progresso geral, cronogramas e impacto em suas equipes.
• Equipes de TI ou técnicas: mantenha comunicação regular com as equipes de TI e técnicas envolvidas na migração. Isso inclui colaboração contínua, compartilhamento de atualizações sobre questões ou problemas técnicos e coordenação de quaisquer configurações ou alterações necessárias. A frequência de comunicação é normalmente maior na fase de planejamento e análise. Durante a fase de implementação, realize reuniões ou pontos de contato regulares para garantir uma coordenação tranquila.

Recurso

O gerenciamento eficaz dos recursos é crucial para uma migração bem-sucedida. Aqui estão alguns aspectos importantes a serem considerados quando se trata de gerenciamento 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 preparações de pré-migração, migração de dados, testes, implantação, configuração e suporte pós-migração. Determine as habilidades, 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 habilidades, disponibilidade e capacidade de carga de trabalho do recurso. Certifique-se de que os recursos sejam alocados adequadamente para equilibrar 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, como recursos compartilhados entre vários projetos.
• Desenvolvimento e treinamento de habilidades: Avalie as lacunas de conhecimento e habilidades dentro da equipe e forneça treinamento necessário ou oportunidades de qualificação para garantir que os recursos estejam adequadamente equipados para as tarefas atribuídas. Isso pode envolver o fornecimento de sessões de treinamento, workshops ou acesso a recursos e documentação relevantes.
• Comunicação e colaboração: Promover comunicação e colaboração eficazes entre os recursos envolvidos na migração. Incentive atualizações regulares de status, reuniões de coordenação e compartilhamento de conhecimento para garantir que todos os membros da equipe estejam alinhados, informados e trabalhando juntos em prol de metas comuns.
• Planejamento de contingência: Antecipe potenciais restrições ou riscos de recursos e desenvolva planos de contingência. Tenha recursos de backup identificados ou treinados em funções críticas para mitigar quaisquer desafios imprevistos, como ausências inesperadas ou limitações de recursos.
• Engajamento das partes interessadas: Mantenha as partes interessadas, como proprietários de aplicativos, chefes de departamento e gerência, informados sobre a alocação de recursos e qualquer impacto potencial nos cronogramas ou entregas. Comunique regularmente atualizações de recursos, relatórios de progresso e quaisquer ajustes nos planos de recursos para gerenciar expectativas e manter a transparência.

Migração individual de objetos

A distinção entre aplicativo e solução é importante. Exportar e importar um aplicativo afeta apenas esse objeto. Uma solução é um contêiner que pode ter vários aplicativos, fluxos e outros objetos.

Exportar e importar um aplicativo de tela (modo legado)

As etapas detalhadas estão documentadas em Exportando um pacote de aplicativo de tela e Importando um pacote de aplicativo de tela.

Este método de exportação de aplicativos é legado. Embora seja compatível, recomendamos que você use soluções. As soluções permitem migrar vários componentes em vez de apenas um recurso.

Fluxo de exportação e importação (modo legado)

As etapas a seguir descrevem como exportar um fluxo.

1. Selecione o menu "…", escolha Exportar e selecione Pacote (.zip).
2. Insira um nome e uma descrição para seu pacote. Você pode então definir as configurações padrão e adicionar comentários que estarão acessíveis durante a fase de importação.
3. Selecione o botão Exportar no canto inferior direito e faça download do pacote. Se o download não iniciar automaticamente, você poderá selecionar o botão Fazer Download .

As etapas a seguir descrevem como importar um fluxo.

1. Selecione o botão Importar.
2. Faça upload do arquivo do pacote e aguarde a tela mostrar os detalhes do pacote.
3. Ao definir as configurações de fluxo, você pode optar por criar um novo fluxo ou atualizar um existente com a definição de fluxo do pacote.
4. Selecione as conexões necessárias para configurar o fluxo. O botão Importar deverá ficar disponível depois de você ter configurado com sucesso todas as definições necessárias.

Depois de importar o fluxo, ele deverá ser ativado. Se o fluxo tiver alguma referência de conexão, o usuário que o ativar deverá ter acesso a essas conexões. Caso contrário, o proprietário da conexão poderá conceder acesso ao usuário de ativação.

Este método de exportação de fluxos de nuvem é legado. Embora seja suportado, recomendamos que utilize soluções, que permitem migrar vários componentes em vez de apenas um recurso.

Exportar e importar um aplicativo baseado em modelo

Um aplicativo baseado em modelo sempre faz parte de uma solução. O aplicativo empacotado, incluído no arquivo de solução (.zip), pode ser compartilhado com os usuários com base em suas funções de segurança após ter sido exportado com êxito do ambiente de origem e importado para o ambiente de destino.

Os processos passo a passo detalhados são abordados em Exportar uma solução e Importar uma solução.

Exportar e importar um bot do Microsoft Copilot Studio

Você pode exportar e importar bots usando as soluções. Uma lista detalhada de etapas é abordada em Exportar e importar bots usando soluções.

Exportar e importar site do Power Pages

As páginas de migração envolvem exportar a configuração existente do ambiente de origem do Microsoft Dataverse e, em seguida, importá-la para o ambiente de destino do Dataverse. Existem algumas etapas de pré-requisito que devem ser executadas no ambiente de destino. Após a conclusão do trabalho de preparação, os dados de configuração do portal poderão ser exportados usando a ferramenta de migração de configuração.

Aplicativo de formulário do SharePoint – caso especial para ambiente padrão

SharePoint Os aplicativos de formulário podem ser associados a apenas um ambiente e, se não forem configurados de outra forma, estarão no ambiente padrão. Uma migração de todos os aplicativos requer a configuração do destino como um ambiente diferente, em vez do ambiente padrão. Os formulários personalizados existentes não migram automaticamente para o ambiente recém-designado. Apenas ambientes de produção podem ser designados para formulários personalizados do SharePoint. O processo manual segue, como mover um aplicativo de tela.

Fazendo backup dos objetos do Microsoft Power Platform

A maioria dos objetos do Microsoft Power Platform são exportados como arquivos zip. Caso contrário, eles têm pelo menos um formato de arquivo. Esses arquivos em seu formato original, como um arquivo zip ou qualquer extensão que venham, podem ser adicionados a qualquer local de armazenamento de arquivos ou repositório de sua escolha. Algumas opções a serem mencionadas são Azure DevOps, GitHub, SharePoint, One Drive ou qualquer outra solução que suporte todos os formatos de arquivo.

Opções de migração em massa

A migração de um aplicativo ou fluxo será bem-sucedida se funcionar da mesma maneira que antes. No entanto, existem certos 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 você precisar dos dados, eles poderão ser exportados e armazenados usando o Kit de início do CoE ou se você tiver que configurar a exportação para data lake. A versão mais recente do Kit de início do CoE possui os dados de execução do fluxo, se usado com a Exportação de Dados.
• Versões do aplicativo Canvas - À medida que os criadores iteram pelo processo de desenvolvimento, There pode ter várias versões criadas. As versões anteriores não podem ser migradas. Somente a versão mais recente pode ser migrada.
• 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 no aplicativo ou fluxo também não serão incluídos.

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

Migrar tudo – opção de backup e restauração de banco de dados

Semelhante à maioria dos tipos de ambiente, também é feito backup do ambiente padrão. Esses backups do sistema são executados automaticamente. Não há opção sob demanda para o ambiente padrão, portanto, é necessária uma solicitação de suporte. O backup pode ser restaurado em um novo ambiente mantendo todos os dados no Dataverse. Esta opção serve apenas para mostrar ao leitor sua existência e educá-lo sobre quando considerar. Não deveria ser considerada a escolha principal, pois só geraria uma migração parcial.

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

Não totalmente compatível pode haver perda potencial de dados durante a migração e mais etapas obrigatórias.

Migrar metadados e depois dados

Uma abordagem recomendada é utilizar soluções para mover os metadados e, em seguida, fluxos de dados, Azure Data Factory ou outra ferramenta de preferência podem ser usadas para transferir dados. A automaçã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 próxima.

Em um nível alto, as etapas são:

1. Adicionar um aplicativo a uma solução.
2. Adicione fluxo à solução.
3. Adicione os bots existentes.
4. Ajuste referências de conexão em aplicativos e fluxos.
5. Verifique se há dependências de solução e adicione objetos.
6. Exporte a solução.
7. Importe a solução.
8. Transferência de dados.

Verificando dependências da solução

O sucesso de uma importação de solução no ambiente de destino só pode ser garantido quando você tiver todos os componentes relacionados adicionados à solução ou quando eles estiverem disponíveis no ambiente de destino. Se houver componentes ausentes, a importação da solução provavelmente falhará. Para garantir que todos os componentes necessários estejam presentes, existem opções que são melhores se usadas em combinação:

• Adicionar manualmente os componentes à solução. Neste caso, presume-se que você saiba que todos os componentes dependentes já estão disponíveis no ambiente de destino.

• Use o botão mostrar dependências na solução para permitir que o sistema identifique dependências para você. Você pode adicionar todas as dependências ou adicionar seletivamente apenas as dependências que não existem no ambiente de destino.

  

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

Supondo que uma solução seja criada, um criador precisa usar a opção de menu de adição de componente existente para incluir um aplicativo, fluxo ou bot existente.

Ajustar referências de conexão

Aplicativos de tela e fluxos tratam conexões de maneira diferente. Os fluxos usam referências de conexão para todos os conectores, enquanto os aplicativos de tela os usam apenas para conexões compartilhadas implicitamente (não OAuth), como autenticação do SQL Server.

Atualização de um aplicativo para usar referências de conexão, em vez de conexões

Aplicativos de tela adicionados de soluções externas não serão atualizados automaticamente para usar referências de conexão. As referências de conexão são associadas a aplicativos de tela apenas no momento em que uma fonte de dados é adicionada ao aplicativo. Para atualizar aplicativos, você deve:

1. Adicionar um aplicativo que não reconhece a solução a uma solução.
2. Remover a conexão do aplicativo.
3. Criar uma nova referência de conexão n solução.
4. Adicionar uma conexão contendo uma referência de conexão associada.

Atualização de um fluxo para usar referências de conexão em vez de conexões

Quando não está em uma solução, um fluxo usa conexões. Se esse fluxo for então adicionado a uma solução, ele continuará a usar as conexões inicialmente. Os fluxos podem ser atualizados para usar referências de conexões, em vez de conexões de uma de duas maneiras:

• Se o fluxo for exportado em uma solução não gerenciada e importado, as conexões são removidas e substituídas por referências de conexão.

• Quando um fluxo de solução for aberto, o verificador de fluxo na página de detalhes do fluxo mostra um aviso para Usar referências de conexão. A mensagem de aviso contém uma ação que você seleciona para Remover as conexões para que as referências de conexão possam ser adicionadas. Selecionar essa ação remove conexões do gatilho e ações no fluxo e permite que referências de conexão sejam selecionadas e criadas.

Adicionando um objeto a uma solução (automação)

Você pode usar comandos do PowerShell para mover aplicativos em massa para uma solução. A adição de aplicativos de tela e fluxos de nuvem pré-existentes às soluções também pode ser feita por meio da linha de comando. Instale os módulos mais recentes do PowerShell para experimentar esta opção. Os dois comandos principais são Set-PowerAppAsSolutionAware e Set-FlowAsSolutionAware.

Depois que os módulos forem instalados, insira seu próprio ID de ambiente, ID de aplicativo, ID de fluxo e ID de solução.

Para um aplicativo 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}

Referências de conexão são entradas de dados na tabela referência de conexão. Usar a referência de conexão como parte do aplicativo ou fluxo requer uma modificação do aplicativo principal ou da definição do fluxo. Você precisa substituir o nó connectionReferences pela referência de conexão.

Exportação e importação de solução

Supondo que as soluções estejam prontas, a próxima etapa da automação pode ser realizada de diversas maneiras:

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

• Use pacotes para mover diversas soluções em uma única passagem.

• Use as tarefas de ferramentas de compilação do Power Platform para executar diversas operações, como empacotar solução, descompactar solução, exportar solução e importar solução. O DevOps oferece a capacidade de automatizar o gerenciamento do ciclo de vida de aplicativos (ALM), e todas essas tarefas são criadas para oferecer suporte ao ALM para o Microsoft Power Platform.

A Command Line Interface (CLI) do Power Platform também oferece opções para exportar e importar soluções. Todos os comandos relacionados à solução podem ser usados ​​para criar, exportar e importar soluções. Você também pode usar a CLI para transferir dados de entrada e saída.

Uma opção amigável para os criadores é usar pipelines destinados a democratizar o ALM para o Power Platform. Trazer a automação do ALM e os recursos de integração/implantação contínua (CI/CD) em um único serviço de recurso é mais acessível para todos os criadores, administradores e desenvolvedores.

Criando conexões (manual)

No ambiente de destino, antes de a operação de importação ser definida, crie as conexões ausentes exigidas pelo aplicativo ou fluxo. Para obter mais informações sobre como criar conexões, consulte Gerenciar conexões no Power Automate.

Migração de dados

Existem várias opções disponíveis para migração de dados, desde manual até automação total.

• Exporte e importe manualmente os dados usando pastas de trabalho do Excel.
• Um fluxo em nuvem do Power Automate pode ser desenvolvido para extrair dados de tabelas de origem e gravá-los diretamente no destino. No entanto, isso exige que o criador use o Dynamics 365 Connector ou o conector do Dataverse (herdado). Atualmente, o conector do Dataverse não oferece suporte à conexão entre ambientes. Esse recurso está planejado para o futuro e, uma vez lançado, poderá ser usado para mover dados de um para outro.
• A ferramenta de migração de configuração (CMT) é uma ferramenta usada para migração de portais, mas também pode ser usada para migração regular de dados. A CMT também pode ser usada com o PowerShell. A ferramenta CLI do PAC permite chamar a CMT.
• Os fluxos de dados podem ser usados ​​para criar mapeamentos entre os ambientes e para mover dados. O conector HTTP Web pode ser usado como uma alternativa ao Dataverse.
• O Azure Data Factory pode ser usado com o conector do Dataverse para extrair dados da origem e inseri-los no destino.

Dado que o ambiente padrão é limitado em tamanho, uma das opções acima deve ser suficiente para mover os dados para fora do ambiente padrão.

Limpar considerações

Uma limpeza é uma boa ideia para aplicativos e fluxos que não são usados ​​e atualizados há muito tempo. Existem diferentes caminhos a serem considerados por um administrador 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êm no final.
• Nem todos os campos precisam ser mapeados. Campos como Versão, Data de modificação, Criado na data, e alguns outros campos do sistema não precisam ser mapeados.
• Se você quiser preservar o campo Criado na data original, use mapear o campo Criado na data de origem para o campo OverRiddenCreatedOn na tabela de destino.
• Os dados de auditoria não podem ser migrados.
• Não habilite nenhum fluxo de trabalho ou fluxo que seja acionado com base na inserção de dados, a menos que seja intencional. Isso aumenta o tempo para migração de dados.

Opções de marcação

O Kit de início do CoE não tem uma opção de marcação hoje. No entanto, pode ser uma personalização que você pode adicionar ao Kit de Início.

Crie uma tabela chamada Tags e configure um relacionamento muitos para muitos (N:N) com o aplicativo, os fluxos e outras tabelas de inventário. Você pode então criar uma tag e associar esses registros aos itens de inventário apropriados. Para obter uma melhor experiência do usuário, você pode incorporar uma grade na forma Principal de aplicativos, fluxos e outras tabelas de estoque. Esta opção é recomendada porque possui consistência referencial.

Crie um campo de texto em cada tabela de estoque e use-o para capturar o texto (tag) que você poderá usar posteriormente.

Se você quiser uma lista mais fixa, crie um conjunto de opções global e adicione-o a todas as tabelas de estoque e seus formulários também.

Opção de quarentena

Se não tiver certeza sobre a necessidade de determinados aplicativos, você pode tentar isolá-los por um tempo e colocá-los em quarentena durante esse estado. O aplicativo só pode ser usado pelo proprietário. Depois de decorrido um período de tempo adequado e se nenhuma resposta do proprietário for recebida, você poderá removê-los do ambiente.

Os fluxos não suportam o estado de quarentena, mas uma abordagem semelhante pode ser usada parando o fluxo e verificando se ele é ativado novamente pelo proprietário.

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

Somente Excluir opção

Se realmente não há perda de produtividade e reaproveitamento dos objetos, esta opção é a melhor. A maioria dos fluxos de teste e aplicativos se enquadram nesta categoria.

Neste caso, uma vez identificada a lista de objetos, um lote do PowerShell poderia ser desenvolvido e uma lista csv passada para ele, o que excluiria todos esses ativos.

À medida que você percorre os IDs de aplicativos e fluxos, o comando a seguir pode ser usado para removê-los do ambiente padrão.

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

Opção de backup e Exclusão de Objetos

Como exemplo, suponha que um fluxo do Power Automate é criado para atender a uma necessidade sazonal específica, mas que não é usado há muito tempo. Nesse caso, é bom fazer um backup do componente antes de excluí-lo.

Para fazer um backup do componente, podem ser utilizadas opções de migração individual ou migração em massa para gerar uma solução exportada. Isso pode então ser adicionado a um repositório de arquivos de sua escolha ou a um local do OneDrive.

Depois que o backup estiver protegido, você poderá aplicar a opção Excluir para concluir o processo de limpeza.

Em muitos casos, trata-se de fluxos de teste e aplicativos criados pelos criadores como parte de seu aprendizado e experimentação de produtividade pessoal.

Conclusão

O Power Platform é uma ferramenta para desenvolvedores cidadãos e desenvolvedores profissionais. O uso do ambiente padrão deve se concentrar principalmente na produtividade pessoal usando produtos do Microsoft 365. Todos os outros aplicativos e desenvolvimento de fluxo devem acontecer em ambientes designados compartilhados, individuais ou de desenvolvedor. Uma forte recomendação é desenvolver uma estratégia ambiental independente baseada em DLP, que possa ajudar os criadores a desenvolver as suas aplicações e fluxos no ambiente certo. Há também um grande benefício em estabelecer uma estratégia de comunicação e fornecer aos usuários modelos de autoatendimento para aprender sobre a estratégia, implementação de soluções e práticas recomendadas para desenvolver aplicativos e fluxos. Uma boa vantagem é capturar também algumas histórias de sucesso no site de comunicação. Histórias de sucesso publicadas internamente ajudam os criadores a se conectarem com as ideias e os abrem para possibilidades que poderiam ser alcançadas com o uso 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 a migração de objetos, incluindo 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 tornar as migrações mais simples.