Partilhar via

Padrões de integração de dados para clouds do Microsoft Industry

Aplica-se a:

  • Microsoft Cloud for Sustainability
  • Microsoft Cloud for Financial Services
  • Microsoft Cloud for Healthcare
  • Microsoft Cloud for Retail

Os modelos de dados do setor servem de base para as respetivas clouds do Microsoft Industry. Dependendo do nível da maturidade do estado dos dados, pode ser necessário integrar as soluções noutros sistemas.

A seleção do padrão de integração apropriado é crucial para assegurar o êxito de uma implementação entre as soluções das clouds do Microsoft Industry e os sistemas externos. Este artigo apresenta os padrões de integração, ferramentas e tecnologias relevantes para a integração, bem como os fatores a considerar na tomada de decisões.

A necessidade de integração

Sistemas de terceiros podem ter processos separados e até uma lógica de negócio diferente. Se o sistema de terceiros utilizar o mesmo Common Data Model (CMD) subjacente do Industry Cloud, a necessidade de transferência de dados, sincronização e programação para transformar os dados é eliminada.

Utilizamos padrões de integração de dados nos seguintes cenários:

  • Dados primários ou transacionais que não são a parte central de um único processo de gestão contínuo. Os dados são sincronizados entre um processo num sistema e o Microsoft Industry Cloud.
  • Os dados são partilhados ou trocados entre sistemas quando necessário para cálculos.
  • Os dados são partilhados ou trocados entre sistemas, pelo que as ações num sistema são refletidas no outro.
  • Os dados agregados de um sistema com um nível detalhado de dados são trocados por um sistema com uma representação de nível superior dos dados.

Como selecionar o padrão de integração correto

Existem muitas opções técnicas para desenvolvimento da integração e cada uma com os seus próprios benefícios e desafios. Para identificar o padrão de extensão de integração correto, pode considerar os seguintes fatores e ponderar cada um deles entre as opções:

Fator de decisão Descrição
Tipos de dados e formatos Que formato e tipo de dados estão a ser integrados?
Volatilidade de dados De baixa volatilidade/mudando lentamente para elevada volatilidade/mudando rapidamente.
Volume de dados De dados de volume baixo para volume elevado.
Disponibilidade dos dados Quando pretende que os dados estejam prontos, da origem para o destino? Precisa deles em tempo real ou só precisa de recolher todos os dados no final do dia e enviá-los num lote agendado para o respetivo destino?
Proteção e limitação do serviço Assegurar a disponibilidade e o desempenho consistentes para todas as pessoas aplicando limites. Estes limites não devem afetar os utilizadores normais, apenas os clientes que efetuam pedidos extraordinários. Deve ser utilizado um padrão comum para serviços online para fornecer códigos de erro ao fazer demasiados pedidos.
Nível de transformação de dados necessário Pedido para converter ou agregar os dados de origem no destino.
Acionadores e ações de acionador Que ação aciona o envio de dados a partir da origem para o destino? Que ações específicas devem ser automatizadas depois de os dados chegarem ao destino?
Processamento de erros Monitorização que é aplicada para detetar quaisquer problemas com as interfaces.
Escalabilidade Processar os volumes de transações esperados no presente, a curto prazo e a longo prazo.
Sistema de registo Considerar qual é o sistema de registo ou o proprietário das informações.
Direção do fluxo de dados O sistema de destino terá de o solicitar ou o sistema de origem terá de o emitir?

Com base nestes fatores, pode identificar o padrão de integração e escolher a ferramenta ou tecnologia certa para a implementação.

Padrões de integração

Nesta secção, exploramos os seguintes padrões de integração que podem ser utilizados durante a integração com o Dataverse.

  • Integração em tempo real/síncrona
  • Integração quase em tempo real/assíncrona
  • Integração em lote
  • Integração da camada de apresentação

Em cada padrão, é apresentada uma estrutura exclusiva e pode ser atualizada utilizando um ou mais padrões. As secções subsequentes fornecem informações sobre como estes padrões são materializados com tecnologias específicas, juntamente com considerações e os cenários apropriados para os aplicar.

Integração em tempo real/síncrona

A integração em tempo real é indispensável em cenários nos quais o sistema de origem necessita de respostas instantâneas ou mínimas de latência aos dados que envia. Este requisito torna-se crucial quando o caso de utilização de negócio determina tanto os sistemas de origem como o de destino, para permanecerem consistentemente sincronizados, assegurando a coerência ininterrupta dos dados entre as duas entidades. A integração síncrona torna-se essencial quando o sistema de destino necessita de uma resposta imediata para avançar de forma simplificada num processo em curso, permitindo a execução atempada das ações subsequentes.

Esta forma de integração é frequentemente sinónimo de integração síncrona. O diagrama seguinte ilustra o padrão predominante de integração síncrona, em que a Aplicação A inicia um pedido a uma Aplicação B e recebe prontamente uma resposta, assegurando a troca de dados atempada e reativa.

Um diagrama que mostra o padrão de integração em tempo real

Algumas das escolhas tecnológicas mencionadas podem ser expandidas para incorporar um sistema intermediário, servindo de reencaminhamento para facilitar o processo de transação. Esta opção de reencaminhamento separa eficazmente as aplicações de origem e de destino gerindo a comunicação de pedidos e respostas em nome destas.

Um diagrama que mostra o padrão de integração em tempo real com um serviço de Reencaminhamento

Pode implementar estes padrões de integração de dados síncronos com diferentes tecnologias disponíveis nas soluções da cloud do setor. A tabela seguinte fornece os padrões de melhores práticas sobre quando os utilizar.

Opção de tecnologia Direções dos dados Propósito Utilizar Quando
API Web do Dataverse Extrair/enviar dados de Externo para Dataverse A implementação OData v4 fornece operações CRUD utilizando um conjunto padrão de interfaces, que fornece uma interface aberta a uma grande audiência de tecnologias. Sobretudo para integração de aplicações transacionais quando são necessárias operações CRUD discretas. Também pode ser utilizado para qualquer integração personalizada, mas inclui complexidades relacionadas com lógica de limitação, paralelismo e repetição, particularmente em grandes volumes de dados.
APIs publicadas por Clouds do Microsoft Industry Extrair/enviar dados de Externo para Dataverse APIs personalizadas criadas pelas Clouds do Microsoft Industry para suportar operações especiais, como o acesso a dados de emissões relacionados com a utilização do Azure. Operações específicas publicadas pelas Clouds do Microsoft Industry. Atribua prioridades à utilização destas APIs personalizadas antes de criar as suas próprias APIs personalizadas.
API do Dataverse Personalizada Extrair/enviar dados de Externo para Dataverse Criar a sua própria API no Dataverse. Quando é necessário consolidar uma ou mais operações numa única operação ou é necessário expor um novo tipo de evento de acionador.
Tabelas virtuais Extrair/enviar dados do Dataverse para Externo Ligue a origens de dados externos e trate-as como entidades nativas do Dataverse. Solicitar dados de referência e cenários CRUD de volume baixo.
Conectores Bidirecional Permitir a troca de dados integrada entre os Serviços Microsoft e sistemas externos, aplicações e origens de dados. Conectores publicados da Microsoft são para integrações normalmente utilizadas, tal como ligar os Serviços Microsoft a aplicações de primeira linha. Conectores publicados verificados são utilizados para integrações especializadas com aplicações de terceiros, assegurando compatibilidade e fiabilidade. Conectores personalizados podem ser utilizados quando a Microsoft ou os conectores de parceiros não resolvem as necessidades de negócio do cliente.

Integração quase em tempo real/assíncrona

A integração assíncrona é recomendada em cenários nos quais não existe necessidade imediata de respostas em tempo real num processo de negócio ou ação. Normalmente, é utilizada quando existe um volume substancial de comunicação de mensagens entre aplicações e sistemas. Os padrões de integração assíncronos asseguram que a comunicação entre sistemas não bloqueia ou desacelera processos, permitindo que cada sistema funcione independentemente e de forma assíncrona. Algumas das formas mais comuns de implementação de integrações assíncronas é feita através de filas de mensagens, publicação/subscrição e integrações de lotes. Pode utilizar estas integrações separadamente ou combinadas, dependendo dos requisitos. São muitas vezes referidos conjuntamente como arquitetura orientada por eventos (EDA).

No padrão de fila de mensagens seguinte, o remetente adota uma estrutura condicionada por evento e o consumidor cria um enlace diretamente para um evento. Quando a mensagem é enviada, o recetor é notificado diretamente e recebe os dados contidos na mensagem do evento.

Um diagrama que mostra o padrão de integração assíncrona com uma fila de mensagens.

No seguinte padrão de publicação-subscrição, o editor gera uma mensagem num formato publicado padrão e transmite-a a um canal de publicação/subscrição dedicado, que pode ter um ou mais subscritores. Cada subscritor subscreve um canal ou tópico específico, permitindo-lhe receber e processar a mensagem publicada (event), conforme necessário. O padrão de publicação-subscrição é escolhido para cenários de comunicação um para muitos, porque vários subscritores podem receber e processar independentemente as mensagens (eventos).

Um diagrama que mostra o padrão de integração assíncrona a utilizar o subscritor de publicações.

Estes padrões de integração de dados assíncronos podem ser implementados com diferentes opções. A tabela seguinte fornece-lhe as opções disponíveis e as melhores práticas sobre quando os utilizar.

Opção de tecnologia Condicionado por evento ou publicação/subscrição Propósito Considerações Utilizar quando
Power Automate Ambos Necessidades de automatização de low-code. Siga o Power Automate e a limitação de cada um dos conectores, tal como a limitação. Utilizar para fluxos acionadores do Dataverse ou quando pretender executar fluxos do Power Automate num agendamento.
Conectores personalizados com base no Logic Apps Condicionado por evento Criar conectores de dados para a solução obter dados a partir de soluções ISV. Tem de passar pelas revisões de conformidade privacidade e segurança antes que sejam movidas para produção. Utilização de cenários de integração ISV onde não existem conectores nativos.
Logic Apps e Azure Service Bus Publicação/subscrição O receção de mensagens pelo editor para um Service Bus e Logic Apps consome a mensagem para enviar para aplicações de subscritor. Tenha em consideração os Limites de execução e configuração de Logic Apps. Utilize para acionadores nativos em conectores do Logic Apps e integração personalizada com vários cenários de subscritor.
Funções do Azure, caraterística de Aplicações Web do Serviço de Aplicações do Azure e Azure Service Bus Publicação/subscrição Utilize uma fila de mensagens para implementar o canal de comunicação entre a aplicação e as instâncias do serviço de consumidor. Considere a ordenação de mensagens e outras considerações de design. Cenários de volume elevado e volatilidade, em que a integração não pode ser desenvolvida com opções low-code (Power Automate ou Logic Apps).
Ponto final de serviço Ambos Enviar as informações de contexto para uma fila, tópico, webhook ou hub de eventos. Não é adequado para transações de execução prolongada. Quando o requisito de integração é sobretudo cumprido com o envio do contexto do Dataverse para o destino diretamente e a ordenação de mensagens não é essencial.

Integração em lote

A criação de batches é a prática de recolher e transportar um conjunto de mensagens ou registos num lote para limitar a conversa e o overhead. O processamento em lotes recolhe dados ao longo de um período de tempo e, em seguida, processa-os em lotes. Esta abordagem é útil quando se processa grandes volumes de dados ou quando o processamento necessita de recursos significativos. Este padrão também verifica o âmbito para replicar os dados principais num armazenamento de réplicas para fins de análise.

Opção de tecnologia Direções dos dados Propósito Considerações Utilizar quando
Azure Data Factory Ambas as direções Criar fluxos de dados para transformar os dados recebidos a partir do Dataverse ou antes de os ingerir no Dataverse Limites de serviço do Data Factory Cenário de ingestão em massa ou exportação de dados com transformação complexa em várias fases.
Power Automate N/A Automatizar fluxos de trabalho e tarefas para a Microsoft Escalabilidade limitada e processamento longo Utilize o Power Automate quando precisar de automatizar tarefas repetitivas, acionar ações com base em eventos e integrar aplicações sem programação de código pesado.
Fluxo de dados do Power Query De sistemas externos para Dataverse Ferramenta de preparação de dados que permite ingerir, transformar e carregar dados em ambientes do Dataverse. Limitações Cenários básicos onde o destino é Dataverse e os conectores existentes não se adequam e outros cenários específicos para o Power BI.
Pipelines do Azure Synapse Ambas as direções Criar pipelines para transformar os dados recebidos a partir do Dataverse ou antes de os ingerir no Dataverse N/A Cenários de análise e de armazenamento de dados.
Azure Synapse Link for Dataverse Do Dataverse para o Azure Synapse Analytics ou o Azure Data Lake Storage v2 (ADLS) Replicar os dados do Dataverse para o Azure Synapse Analytics ou o ADLS v2 e permite-lhe executar cenários de análise, business intelligence, aprendizagem automática e relatórios personalizados nos seus dados. Tabelas que não são suportadas. Análise de dados e relatórios personalizados Adicionalmente, como fase intermédia da exportação de dados.
Azure Logic Apps N/A Criar fluxos de trabalho com capacidades de integração avançadas. Operações em lote complexas poderão requerer configuração e orquestração significativas. Não otimizado para cenários de processamento de lotes especializados. As Azure Logic Apps são adequadas para orquestrar processos de negócio e integrar serviços.
SQL Server Integration Services Ambas as direções Utilizar um conector de terceiros para extrair e enviar dados de/para Dataverse. Como não se trata de uma solução PaaS, o dimensionamento, a utilização da memória, o desempenho e o custo devem ser avaliados. Quaisquer limitações quanto as ferramentas de extração, transformação e carregamento de cloud (ETL) poderão não ser uma opção.

Integração da camada de apresentação

A apresentação ou User Interface Integration está no nível superior do sistema, e é aquilo que o utilizador vê e com o que interage. Em certos casos de uso, a integração tem de acontecer neste nível, combinando as informações de diferentes sistemas ou fontes de dados e mostrando-as numa só interface de utilizador. As aplicações condicionadas por modelo são um dos seus componentes e contribuem para a experiência completa do utilizador, permitindo interações condicionadas por dados e permitindo a navegação simples no ambiente integrado. A integração da apresentação é necessária quando há um desejo de manter a lógica de negócio existente ou a estrutura da aplicação, ao mesmo tempo que permite uma fácil agregação de dados, personalização da interface do utilizador ou aperfeiçoamento da experiência do utilizador. Por outro lado, acarreta restrições inerentes, incluindo complexidades na integração e manutenção, uma interdependência significativa entre sistemas integrados, potenciais implicações de desempenho e considerações relativas à consistência dos dados.

  • Ativar a agregação de dados
  • Personalização da interface de utilizador
  • Experiência de utilizador melhorada

Pelo contrário, tem restrições inerentes, incluindo:

  • Complexidades na integração e manutenção
  • Interdependência significativa entre sistemas integrados
  • Implicações potenciais para o desempenho
  • Considerações relativas à consistência dos dados
Opção de tecnologia Propósito Considerações Utilizar quando
Integrações de IU nativas proprietárias Utilização de Mapas Bing da Microsoft, Microsoft Teams e outras integrações de IU nativas proprietárias Não personalizável na maioria dos casos. Cenários específicos suportados na integração de IU nativa.
Páginas personalizadas Incorporar uma aplicação de tela numa aplicação condicionada por modelo. Limitações conhecidas Preferível tomar uma abordagem de integração de low-code e quando uma aplicação de tela for adequada para utilização.
Power Apps component framework (PCF) Um controlo reutilizável personalizado para apresentar ou interagir com o utilizador final, mantendo o design reativo. Estrutura de limitações do componente do Power Apps. Método preferencial quando uma IU personalizada precisa de ser desenvolvida dentro da aplicação condicionada por modelo na ausência de uma aplicação de tela.
Mosaicos do Power BI Mostrar o mosaico do Power BI num formulário de aplicação condicionada por modelo. Licenciamento do Power BI, autorização de dados do Power BI. Apresentar um mosaico do Power BI numa aplicação condicionada por modelo
Dashboard do Power BI Embedded Apresentar o dashboard do Power BI Embedded na aplicação condicionada por modelo. Licenciamento do Power BI, autorização de dados do Power BI. Apresentar a análise alojada no Power BI.
Incorporar como HTML iFrame Incorporar a outra IU de sistema numa aplicação condicionada por modelo. Início de sessão único (SSO), configuração de Partilha de Recursos Transversais à Origem (CORS) e design reativo. Cenários complexos de IU onde não existe serviço disponível.
Recurso Web personalizado Criar um esquema personalizado de IU na aplicação condicionada por modelo. Avalie a acessibilidade e a estrutura reativa da IU personalizada. Cenários onde outras integrações de IU não são uma opção.

Resumo de padrões de integração

No mundo da integração de software, existem vários padrões e mecanismos disponíveis para trocar dados entre diferentes sistemas. Cada padrão tem as suas próprias vantagens e desvantagens, sendo que a escolha do correto pode afetar bastante o desempenho e eficiência dos sistemas integrados.

A tabela seguinte apresenta um resumo destes padrões de integração: integração em tempo real ou síncrona, integração assíncrona, integração de lotes e integração de camadas de apresentação. Pode explorar os mecanismos, acionadores, vantagens, desvantagens e casos de utilização para cada padrão, para o ajudar a tomar uma decisão informada quando selecionar uma abordagem de integração para o seu sistema.

Padrão de integração Mecanismo Acionar Prós Contras Utilizar quando
Em tempo real ou síncrona Os dados são trocados, invocando ações através da integração de ponto a ponto ou do relé. Ação do utilizador ou evento de sistema. Percurso completo de pedido e resposta rápidos. Valores e informações em tempo real. Geralmente, não é uma melhor prática a utilizar devido ao risco de os processos ficarem presos e criar uma integração bastante vinculada. Risco de impacto de erros transitórios. Sensível à latência. Utilize quando as informações em tempo real forem cruciais.
Assíncrono Os dados são trocados ou ingeridos automaticamente numa agenda periódica ou como feed gotejado que utiliza padrões de mensagens. Agendado para um período ou acionado por uma nova mensagem publicada pelo sistema de origem. A vinculação adaptável de sistemas torna a solução robusta. Balanceamento de carga ao longo do tempo e recursos. Pode ser muito próximo de em tempo real. Processamento de erros atempado. Atraso na resposta e visibilidade das alterações entre sistemas. Necessidades de sincronização de dados quase em tempo real para volumes de dados baixos ou médios.
Criação de batches A criação de batches é a prática de recolher e transportar um conjunto de mensagens ou registos num lote para limitar a conversa e o overhead. Acionador agendado ou manual. Ótimo para utilização com serviços de mensagens e outros padrões de integração assíncronos. Menos pacotes individuais e menos tráfego de mensagens. A atualização dos dados é menor. A carga no sistema recetor pode ser a afetada se a lógica de negócio for executada quando a mensagem for recebida. Cenários de volume elevado ou de volatilidade onde recolher e transportar um conjunto de mensagens ou registos em forma de lote é viável, cenários de replicação de dados.
Camada de apresentação As informações de um sistema são totalmente integradas na IU de outro sistema. N/A Elimina a complexidade da sincronização de dados, porque os dados permanecem no sistema de origem. Em determinados setores, elimina os bloqueadores relacionados com residência dos dados devido a requisitos regulamentares. Difícil de utilizar os dados para cálculos para processamento, mais complexidades para satisfazer o início de sessão único, a partilha de recursos entre origens e o alinhamento de autorizações. Quando o requisito for satisfeito ao apresentar o sistema de origem ou a IU diretamente, sem que seja necessário sincronizar dados entre o sistema de origem e o sistema de destino.

Próximos passos

Microsoft Cloud for Sustainability

Microsoft Cloud for Financial Services

Microsoft Cloud for Healthcare