Consistência eventual entre várias instâncias do Power Apps

Este artigo descreve um cenário em que um cliente hipotético sediado 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 LOB (linha de negócios) proprietário da Contoso 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 ausentes. O guia a seguir mostra como considerar consistência eventual entre instâncias do Power Platform.

Arquitetura

Plug-in/fluxo para sempre fazer upsert com base no GUID ou na chave alternativa

Baixe um Arquivo Visio dessa arquitetura.

Workflow

Esta solução pode ser criada com várias etapas de plug-in, dentro do ciclo de vida do plug-in. Quando a entidade que você estiver criando for obrigatória, use a etapa PreValidation. PreValidation ocorre antes do início de qualquer transação de banco de dados. É a opção preferencial quando o campo é obrigatório. No entanto, em alguns cenários, a etapa de plug-in PreCreate é suficiente.

1. A Instância dos EUA tenta sincronizar uma nova conta com a Instância da Europa por meio de um Aplicativo Lógico. A instância da Europa está inacessível, devido ao tempo de inatividade ou à atualização.
2. O aplicativo LOB da Contoso lê as entidades principais da conta na instância dos EUA. Ele pretende enviar uma chamada à API que faça referência a uma entidade de conta que não foi replicada para a Instância da Europa. No estado atual, a chamada à API falharia porque o registro não existe, já que a sincronização não está funcionando.
3. No entanto, um plug-in PreValidation/PreCreate primeiro executa um upsert com base no GUID da entidade fornecida e nos dados de referência fornecidos. Se já existir, nada será alterado. Se não existir, uma conta será criada, com a maioria dos campos em branco.
4. A chamada à API é bem-sucedida porque a conta com a ID fornecida existe no sistema. O plugin interceptou a operação e lidou normalmente com o registro ausente. 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, entre outras:

• Aplicativos Lógicos
• Aplicativos de funções no Azure Functions
• Fábrica de dados do Azure
• Azure Synapse Analytics
• Power Automate

Detalhes do cenário

Raramente, as organizações veem necessidade de manter duas ou mais instâncias do Power Platform sincronizadas, mais específica e geralmente em um subconjunto de entidades do 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 regiões geográficas. Ou pode acontecer quando duas organizações se fundem antes da finalização da consolidação do Power Platform.

Quando o processo de sincronização funciona conforme esperado, os aplicativos de linha de negócios que consomem de ambas as instâncias não têm problemas. No entanto, a sincronização de mecanismos não é à prova de erros, interrupções ou problemas inesperados provavelmente acontecerã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, é preciso sincronizar contas e contatos de uma instância do Power Platform com outra. Nesse cenário, a instância do Power Platform nos EUA 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 ao tempo de inatividade, à manutenção ou a outro problema de comunicação, a solicitação produzirá um erro devido a entidades ausentes na instância da Europa.

Possíveis casos de uso

O 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 sobre a criação da entidade que está sendo criada.

Quando usar essa abordagem

Use a abordagem nos seguintes cenários:

• Você deseja garantir a existência de um registro com uma determinada chave e não se importa que o registro não esteja totalmente hidratado.
• Você precisa aceitar a criação, mesmo que os dados ainda não sejam sincronizados.

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

• Há aplicação de lógica quando o registro é criado. Como os dados não estarão hidratados, não é seguro supor que determinadas propriedades estarão disponíveis.

Exemplos

Os exemplos a seguir mostram as possíveis jornadas e o resultado de atrasos na sincronização.

Exemplo 1: caminho bem-sucedido sem interrupção nem erros transitórios

Baixe um Arquivo Visio dessa arquitetura.

1. A Instância dos EUA sincroniza uma nova conta com a Instância da Europa por meio de um Aplicativo Lógico. Tudo está funcionando porque não ocorreram falhas nem interrupções transitórias.
2. O aplicativo LOB da Contoso lê as entidades principais da conta na Instância dos EUA e pretende enviar uma chamada à API que faça referência a uma entidade de conta que foi replicada na Instância da Europa. Isso funciona porque tudo estava pronto e não ocorreram interrupções nem falhas transitórias. O relatório do aplicativo LOB é gerado com êxito.

Exemplo 2: caminho com falha porque a sincronização está inativa ou atrasada

Baixe um Arquivo Visio dessa arquitetura.

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

Considerações

Considere o impacto de lógicas de negócios em uma entidade que ainda não foi hidratada. Considere um cenário em que a entidade ainda não está totalmente hidratada e sincronizada. Algumas das propriedades serão nulas, portanto, é preciso considerar as decisões sobre os dados ao usar essa abordagem.

Próximas etapas

• Power Platform
• O que é o Power Apps?
• O que são os Aplicativos Lógicos do Azure?
• Introdução ao Power Automate

Recursos relacionados

Arquiteturas relacionadas

• CI/CD para o Microsoft Power Platform
• IA de cidadãos com a Power Platform
• Implantação do Power Automate em escala

Diretrizes para desenvolvimento na Web:

• Dez princípios de design para aplicativos do Azure
• Padrões de design e implementação
• Melhores práticas de implantação do Serviço de Aplicativo
• Estrutura Bem Projetada do Microsoft Azure