Eventual consistência entre várias instâncias do Power 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

Transfira um ficheiro do Visio desta arquitetura.

Fluxo de Trabalho

Esta solução pode ser construída com várias etapas do plugin , dentro do ciclo de vida do plugin. Quando a entidade que você está criando for obrigatória, use a etapa Pré-validação. A 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 do plugin PreCreate será suficiente.

1. A Instância dos EUA tenta sincronizar uma nova conta com a Instância da Europa através de uma Aplicação Lógica. A 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 Instância dos EUA. 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 Europa. 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 PreValidation/PreCreate primeiro executa um 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.

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:

• Logic Apps
• Aplicativos de função no Azure Functions
• Azure Data Factory
• Azure Synapse Analytics
• Power Automate

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.

Potenciais casos de utilização

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ção ou erros transitórios

Transfira um ficheiro do Visio desta arquitetura.

1. A Instância dos EUA sincroniza uma nova conta com a Instância da Europa 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 da 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 da 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

Transfira um ficheiro do Visio desta arquitetura.

1. A Instância dos EUA tenta sincronizar uma nova conta com a Instância da Europa através de uma Aplicação Lógica. A 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 de conta principais da 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 da Europa. A chamada de API falha porque a conta com o identificador fornecido não foi criada na Instância da Europa 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

• Power Platform
• O que é o Power Apps?
• O que é o Azure Logic Apps?
• Introdução ao Power Automate

Recursos relacionados

Arquiteturas relacionadas:

• IA cidadã com a Power Platform
• Automatize a implantação em escala

Orientação para desenvolvimento Web:

• Dez princípios de design para aplicativos do Azure
• Padrões de design e implementação
• Práticas recomendadas de implantação do Serviço de Aplicativo
• Estrutura bem arquitetada do Microsoft Azure