Editar

Partilhar via

Eventual consistência entre várias instâncias do Power Apps

Microsoft Power Platform
Microsoft Dataverse
Azure Logic Apps

Este artigo descreve um cenário em que um hipotético cliente baseado nos EUA, a Contoso, adquiriu recentemente outra empresa com sede na Europa e está no processo de sistemas CRM e ERP entre as duas empresas. Como parte dessa integração, eles devem manter uma parte de suas entidades do Dynamics 365 Dataverse sincronizadas até que possam ser totalmente integradas. Um aplicativo de linha de negócios (LOB) proprietário da Conotso consome dados de ambos os sistemas e deve ser capaz de aceitar solicitações quando os dados estão aguardando sincronização ou quando estão faltando. O guia a seguir mostra como levar em conta a eventual consistência entre instâncias da Power Platform.

Arquitetura

Plugin/flow para sempre upsert com base no GUID ou chave alternativa

Diagrama mostrando um plug-in dataverse fornecendo a solução para uma sincronização multissistema com falha.

Baixe um arquivo Visio dessa arquitetura.

Fluxo de trabalho

Esta solução pode ser construída com vários plugin passos, dentro do ciclo de vida do plugin. Quando a entidade que você está criando for obrigatória, use a etapa Pré-validação. de Pré-Validação acontece antes de qualquer transação de banco de dados ser iniciada. É a opção preferida, se o campo for obrigatório. No entanto, em alguns cenários, uma etapa PreCreate plugin será suficiente.

  1. O US Instance tenta sincronizar uma nova conta com a de Instância do Europe por meio de um aplicativo lógico. O da Instância Europa está inacessível devido a tempo de inatividade ou atualização.
  2. O aplicativo LOB da Contoso lê as entidades da conta principal da US Instance. Ele pretende enviar uma chamada de API que faça referência a uma entidade de conta que não foi replicada para a Instância Europe. Como está, a chamada de API falharia porque o registro não existe, devido à sincronização não funcionar.
  3. No entanto, um plug-in PreValidationPreCreate primeiro executa um de upsert com base no GUID da entidade fornecido e nos dados de referência fornecidos. Se já existe, então nada muda. Se não existir, é criada uma nova conta, com a maioria dos campos em branco.
  4. A chamada de API é bem-sucedida porque a conta com o ID fornecido existe no sistema. O plugin intercetou a operação e lidou com o registro ausente graciosamente. O relatório do aplicativo LOB é gerado com êxito.

Observação

A Microsoft recomenda a introdução de um padrão de disjuntor em seu código personalizado para recuar e tentar novamente como parte desta solução para lidar com interrupções de plataforma ao fazer referência a qualquer instância. Para obter mais informações sobre como usar um disjuntor, consulte Circuit Breaker Pattern.

Alternativas

O cenário descrito acima usa um aplicativo lógico personalizado como método de replicação. No entanto, há várias maneiras de replicar dados entre instâncias do Dataverse, que incluem, mas não estão limitadas a:

  • Aplicativos lógicos
  • Aplicativos de função no Azure Functions
  • Azure Data Factory
  • Azure Synapse Analytics
  • Automatize o poder

Detalhes do cenário

As organizações ocasionalmente encontram a necessidade de manter duas ou mais instâncias da Power Platform sincronizadas, mais especificamente, geralmente um subconjunto de entidades Dataverse. Esse requisito pode acontecer quando uma organização adicionou intencionalmente novas instâncias para isolamento geográfico, mas precisa de um conjunto de dados comum em todas as áreas geográficas. Ou pode acontecer quando duas organizações se fundem antes da conclusão da consolidação da Power Platform.

Quando o processo de sincronização funciona como projetado, os aplicativos de linha de negócios que consomem de ambas as instâncias não têm problemas. No entanto, os mecanismos de sincronização nunca são à prova de erros, interrupções ou problemas inesperados provavelmente surgirão. Nesse caso, seu aplicativo de linha de negócios que consome dados de ambas as instâncias deve ser criado para lidar com dados incompletos.

Para que a nova subsidiária europeia da Contoso seja integrada à estrutura de negócios da Contoso, ela deve sincronizar contas e contatos de uma instância da Power Platform para outra. Nesse cenário, a instância dos EUA do Power Platform sincroniza um lote diário de dados de referência por meio de um aplicativo lógico personalizado com a instância europeia. Um aplicativo LOB proprietário da Contoso gera relatórios sobre tíquetes de problemas criados pelos usuários. Para concluir essa tarefa, o aplicativo LOB lê os dados do usuário de ambas as instâncias do Dataverse para extrair os dados relevantes, as chaves de referência primárias da instância dos EUA e os dados de tíquete da instância da Europa. Se o processo de sincronização não tiver sido concluído devido a tempo de inatividade, manutenção ou outro problema de comunicação, a solicitação produzirá um erro devido a entidades ausentes da instância Europa.

Casos de uso potenciais

Este padrão pode ser útil nas seguintes situações:

  • O sistema que envia dados de referência está inativo.
  • A sincronização de dados leva muito tempo ou o processo está atrasado.
  • Os sistemas de consumo não têm lógica na criação da entidade que está sendo criada.

Quando usar esta abordagem

Use essa abordagem nos seguintes cenários:

  • Você quer garantir que um registro com uma determinada chave existe, e você não se importa que o registro não esteja totalmente hidratado.
  • Você deve aceitar a criação, mesmo que os dados ainda não estejam sincronizados.

Esse padrão pode não ser adequado no seguinte cenário:

  • A lógica é aplicada quando o registro é criado. Como os dados não serão hidratados, não é seguro confiar em certas propriedades disponíveis.

Exemplos

Os exemplos a seguir mostram as viagens potenciais e o resultado de atrasos de sincronização.

Exemplo 1 - Caminho bem-sucedido sem interrupções ou erros transitórios

Diagrama mostrando uma sincronização multissistema bem-sucedida.

Baixe um arquivo Visio dessa arquitetura.

  1. O US Instance sincroniza uma nova conta com o de Instância do Europe por meio de um aplicativo lógico. Todos estão funcionando porque não ocorreram falhas ou interrupções transitórias.
  2. O aplicativo LOB da Contoso lê as entidades de conta principais do de Instância dos EUA e pretende enviar uma chamada de API que faça referência a uma entidade de conta que foi replicada para a Instância Europa. Funciona porque tudo estava em alta e não ocorreram interrupções ou falhas transitórias. O relatório do aplicativo LOB é gerado com êxito.

Exemplo 2 - Caminho malsucedido onde a sincronização está inativa ou atrasada

Diagrama mostrando uma falha na sincronização de vários sistemas.

Baixe um arquivo Visio dessa arquitetura.

  1. O US Instance tenta sincronizar uma nova conta com a de Instância do Europe por meio de um aplicativo lógico. O da Instância Europa está inacessível devido a tempo de inatividade, manutenção ou outro problema de comunicação.
  2. O aplicativo LOB da Contoso lê as entidades da conta principal do de Instância dos EUA e pretende enviar uma chamada de API que faça referência a uma entidade de conta que não foi replicada para a Instância Europa. A chamada de API falha porque a conta com o identificador fornecido não foi criada no de Instância do Europe e o relatório não é gerado.

Considerações

Considere o impacto de qualquer lógica de negócios em uma entidade que ainda não está hidratada. Considere um cenário em que a entidade ainda não esteja totalmente hidratada e sincronizada. Algumas das propriedades serão nulas, portanto, você precisa garantir que todas as decisões sobre os dados sejam consideradas ao usar essa abordagem.

Próximos passos

Arquiteturas relacionadas:

Orientação para desenvolvimento Web: