Padrões de integração de dados da Microsoft Cloud for Sustainability

O modelo de dados forma a base da Microsoft Cloud for Sustainability. Dependendo do nível de maturidade da propriedade de dados, a solução pode exigir integração com outros sistemas. Escolher o padrão certo é fundamental para uma implementação bem-sucedida.

Este artigo apresenta padrões de integração, ferramentas e fatores de decisão, enquanto a ingestão única de dados ou orientação de migração é abordada na Estratégia de migração de dados para o Microsoft Sustainability Manager.

A necessidade de integração

No atual ambiente acelerado dos negócios, as organizações enfrentam muitos desafios no gerenciamento e integração de sistemas e dados. Um dos maiores obstáculos é a necessidade de integração entre diferentes soluções de sustentabilidade, que podem ser demoradas, complexas e caras.

No entanto, o surgimento de soluções do setor de nuvem da Microsoft oferece uma solução promissora para esse problema. Ao usar um modelo de dados comum que é compartilhado por várias soluções de terceiros, a necessidade de integração pode ser bastante reduzida ou até mesmo eliminada. Para obter detalhes sobre o nível de adoção, acesse Níveis de maturidade da propriedade de dados. No entanto, as integrações ainda podem ser necessárias para os seguintes cenários:

• O processo abrange vários sistemas e os dados precisam ser sincronizados de um sistema para outro.
• Quando necessário, os dados são compartilhados ou trocados entre sistemas para cálculos de emissões.
• Os dados são compartilhados ou trocados entre sistemas para que as ações que ocorrem em um sistema sejam refletidas no outro.
• Os dados agregados de um sistema com um nível detalhado de dados são trocados para um sistema com uma representação de dados de nível superior.

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

Muitas opções técnicas estão disponíveis para o desenvolvimento de integração, cada uma com suas próprias vantagens e desvantagens. Para identificar o padrão de extensão de integração correto, você pode considerar os seguintes fatores e ponderá-los entre as opções:

Fator de decisão	Descrição
Tipos de dados e formatos	Qual tipo e formato de dados estão sendo integrados?
Volatilidade de dados	Os dados que precisam ser sincronizados mudam com frequência?
Volume de dados	Qual é o volume da alteração de dados que precisa ser sincronizada?
Disponibilidade de dados	Quando você quer que os dados estejam prontos, da origem ao destino? É necessário em tempo real ou você só precisa coletar todos os dados no final do dia e enviá-los em um lote programado para o destino?
Proteção e limitação de serviço	Existem limites com base na janela de tempo, simultaneidade e direitos?
Nível de transformação de dados necessário	Existe algum requisito para converter ou agregar os dados de origem ao destino?
Gatilhos e ações de gatilho	Que ação aciona o envio de dados da origem para o destino? Quais ações específicas serão automatizadas depois que os dados chegarem ao destino?
Tratamento de erros	Algum monitoramento será implementado para detectar possíveis problemas com as interfaces?
Escalabilidade	Como você lidará com os volumes de transações esperados no presente, em curto e em longo prazo?
Sistema de registro	Qual é o sistema de registro ou quem é o proprietário da informação?
Direção do fluxo de dados	O sistema de destino precisará efetuar pull ou o sistema de origem precisará efetuar push?

Com base nesses fatores, você pode identificar o padrão de integração e também escolher a ferramenta ou tecnologia certa para a implementação.

Padrões de integração

Existem vários padrões que podem ser usados na integração com o Dataverse. Cada padrão representa uma forma que pode ser realizada usando uma ou mais tecnologias. A realização desses padrões com a tecnologia é explicada nas seções a seguir.

Integração em tempo real ou síncrona

A integração em tempo real é necessária quando o sistema de origem (Aplicativo-A) envia alguma informação e precisa de uma resposta imediata do sistema de destino (Aplicativo-B) para que ele possa fazer algumas ações de acompanhamento.

Esse padrão pode ser implementado com estas opções de tecnologia:

Observação

Entrada se refere a chamadas de serviço de entrada para o Dataverse enquanto saída se refere a chamadas de serviço de saída do Dataverse para outros sistemas.

Opção de tecnologia	Entrada/Saída	Finalidade	Use quando
API do Dataverse	Entrada (push)	Implementação do OData v4 para fornecer operações CRUD usando um conjunto padrão de interfaces, fornecendo uma interface aberta a um amplo público tecnológico.	Principalmente para integração de aplicativos transacionais quando operações CRUD discretas forem necessárias. Também pode ser usado para qualquer integração personalizada, mas traz complexidades relacionadas à limitação, ao paralelismo e à lógica de repetição, principalmente em grandes volumes de dados.
API do Cloud for Sustainability (versão preliminar)	Entrada (pull)	APIs personalizadas criadas pela Microsoft Cloud for Sustainability para acessar dados de emissões relacionados ao seu uso do Azure.	A filtragem dos dados de emissões é necessária onde o conector nativo do Painel do Impacto das Emissões não pode ser usado.
API de cálculo de emissão generalizada	Entrada (push)	APIs personalizadas criadas pela Microsoft Cloud for Sustainability para calcular as emissões de atividades usando um modelo de cálculo sem criar um perfil de cálculo.	O cálculo de emissão de gatilho é necessário de acordo com um evento.
API personalizada do Dataverse	Entrada	Criação da sua própria API no Dataverse.	Uma ou mais operações precisam ser consolidadas em uma única operação ou expor um novo tipo de evento de gatilho.
Tabelas virtuais	Saída (pull)	Conecte-se a fontes de dados externas e trate-as como entidades nativas do Dataverse.	Extração de dados de referência e cenários CRUD de baixo volume.
Plugin em tempo real	Saída	Invocação do outro sistema em tempo real em um evento do lado do servidor.	Não é uma opção desejada devido ao limite de tempo limite do canal de dois minutos e pode degradar a experiência do usuário para registros síncronos.

As opções de tecnologia descritas podem ser estendidas para introduzir um sistema intermediário para atuar como uma retransmissão para a transação. A opção de retransmissão separa o aplicativo de origem e destino, manipulando a solicitação e a comunicação de resposta em nome dos aplicativos, conforme mostrado na imagem a seguir.

Integração assíncrona

A integração assíncrona é necessária onde não há dependência de resposta em tempo real para uma ação ou processo empresarial. Em geral, é utilizado quando há alto volume de comunicação de mensagens entre o aplicativo e os sistemas. Você pode escolher o consumidor orientado a eventos ou o padrão publish-subscriber para implementar a integração assíncrona.

No padrão de consumidor orientado a eventos no diagrama a seguir, o remetente adota uma estrutura orientada a eventos e o consumidor cria uma ligação diretamente a um evento. Quando o evento é disparado, o consumidor é notificado diretamente e recebe os dados contidos na mensagem do evento.

No padrão de publicação-assinante no diagrama a seguir, o publicador cria uma mensagem em um formato publicado e a envia para uma fila de mensagens, que possui um ou mais assinantes. O assinante lê a fila de mensagens para recuperar a mensagem publicada da fila.

Esses padrões assíncronos podem ser implementados com as opções de tecnologia na tabela a seguir.

Opção de tecnologia	Orientado por evento ou publish-subscriber	Finalidade	Considerações	Use quando
Power Automate	Ambos	Necessidades da automação low-code.	Siga o Power Automate e cada limitação de conectores, como limitação.	Use para os eventos de gatilho do Dataverse.
Conectores personalizados baseados na estrutura de Aplicativos Lógicos	Orientado a eventos	Criação de conectores de dados para a solução do Microsoft Sustainability Manager para obter conjuntos de dados completos para uma ou mais emissões de carbono e categorias de sustentabilidade.	É necessário passar por análises de privacidade, segurança e conformidade antes de serem colocados em produção.	Uso de cenários de integração ISV onde não existem conectores nativos.
Aplicativos Lógicos e Barramento de Serviço do Azure	Publish-subscriber	O recebimento de mensagens pelo distribuidor para um barramento de serviço e aplicativos lógicos consome a mensagem para enviar aos aplicativos de assinantes.	Siga a Configuração e limites de execução dos Aplicativos Lógicos.	Use para gatilhos nativos em conectores de Aplicativos Lógicos e integração personalizada com vários cenários de assinantes.
Azure Functions, recurso de Aplicativos Web do Serviço de Aplicativo do Azure e Barramento de Serviço do Azure	Publish-subscriber	Use uma fila de mensagens para implementar o canal de comunicação entre o aplicativo e as instâncias do serviço do consumidor.	Considere a ordem de mensagens e outras questões de design.	Cenários de alto volume e volatilidade, onde a integração não pode ser desenvolvida com opções de low-code (Power Automate ou Aplicativos Lógicos).
Plugin assíncrono ou ponto de extremidade de serviço	Ambos	Envio das 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 é atendido principalmente com o envio do contexto do Dataverse para o destino diretamente e a ordem das mensagens não é crítica.

Integração do lote

O envio em lote é a prática de reunir e transportar um conjunto de mensagens ou registros em um lote para limitar a vibração e a sobrecarga. Esse padrão também abrange a replicação dos dados originais para um armazenamento de réplica para fins analíticos. Esse padrão de integração em lote pode ser implementado com as opções de tecnologia na tabela a seguir.

Opção de tecnologia	Entrada/Saída	Finalidade	Considerações	Use quando
Conectores do Power Query para Microsoft Sustainability Manager	Entrada (pull)	Um catálogo robusto de conectores pré-construídos e personalizados de provedores de dados operacionais.	Uso somente de conectores originais.	Cenários adequados ao fluxo de dados compatíveis com os conectores do Power Query específicos do Microsoft Sustainability Manager.
Conectores internos do Power Query	Entrada (pull)	Atualmente, os usuários podem conectar seus dados por meio de arquivos de valores separados por vírgula (CSV), arquivos do Excel, Open Data Protocol (OData) e mais de 40 conectores disponíveis no Power Query.	Recursos de transformação limitados compatíveis com o Power Query.	Cenários de ingestão de dados ou integração de entrada que os conectores dão suporte nativamente.
Azure Data Factory	Entrada (push)	Criação de fluxos de dados para transformar os dados recebidos do Dataverse ou antes da ingestão 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ários estágios.
SQL Server Integration Services (SSIS)	Entrada (push)	Usando um conector de terceiros para efetuar pull e push de dados de e para o Dataverse.	Por não ser uma solução PaaS, o dimensionamento, uso de memória, desempenho e custo devem ser avaliados.	Quaisquer limitações quando as ferramentas de extração, transformação e carregamento (ETL) da nuvem podem não ser uma opção.
Azure Synapse Link	Saída (pull)	Replicação dos dados do Dataverse para Synapse Analytics ou Data Lake para análises e relatórios personalizados.	Tabelas não compatíveis.	Análise de dados e relatórios personalizados. Também como uma etapa intermediária de exportação de dados.

Integração de apresentação

A integração da apresentação em Dataverse é normalmente usada quando você deseja exibir dados externos na interface do usuário do Dataverse. Essa abordagem é útil quando você precisa fornecer aos usuários uma experiência perfeita ao acessar dados de vários sistemas sem alternar entre diferentes aplicativos. Esse padrão de integração também elimina a necessidade de sincronizar dados se os dados não forem consumidos pelo aplicativo de destino. A tabela a seguir fornece algumas opções de tecnologia para integração de apresentação.

Opção de tecnologia	Finalidade	Considerações	Use quando
Integrações de IU nativas originais	Uso de mapas Bing, equipes e outras integrações de interface do usuário de terceiros	Não personalizável na maioria dos casos	Cenários específicos com suporte na integração nativa da interface do usuário
Páginas personalizadas ou aplicativos de tela incorporados	Experiência do usuário usando os recursos do aplicativo de tela com páginas personalizadas ou incorporando um aplicativo de tela em um aplicativo baseado em modelo	Limitações conhecidas	Preferencial para adotar uma abordagem de integração low-code e quando um aplicativo de tela é adequado para usabilidade
Componente do Power Apps	Um controle reutilizável personalizado para exibir ou interagir com o usuário final, mantendo o design responsivo	Limitações de componentes do Power Apps	Método preferencial quando uma interface do usuário personalizada é desenvolvida dentro de um modelo orientado na ausência de um aplicativo de tela
Blocos do Power BI	Mostrando o bloco do Power BI em um formulário de aplicativo baseado em modelo	Licenciamento do Power BI, autorização de dados do Power BI	Exibindo um bloco do Power BI em um aplicativo baseado em modelo
Painel incorporado do Power BI	Exibindo o painel incorporado do Power BI no aplicativo baseado em modelo	Licenciamento do Power BI, autorização de dados do Power BI	Exibindo as análises hospedadas no Power BI
Incorporando como iFrame	Incorporando a outra IU do sistema em um aplicativo baseado em modelo	Configuração de logon único, compartilhamento de recursos entre origens (CORS) e design responsivo	Cenários complexos de interface do usuário em que nenhum serviço está disponível
Recurso da Web personalizado	Criação de um layout de interface do usuário personalizado no aplicativo baseado em modelo	Design responsivo	Cenários em que outras integrações de interface do usuário não são uma opção

Resumo dos padrões de integração

No mundo da integração de software, existem vários padrões e mecanismos disponíveis para troca de dados entre diferentes sistemas. Cada padrão tem suas vantagens e desvantagens, e escolher o certo pode afetar muito o desempenho e a eficiência dos sistemas integrados. Veja a seguir uma exibição resumida desses padrões de integração: tempo real ou síncrono, assíncrono, lote e apresentação. Você pode explorar os mecanismos, gatilhos, prós, contras e casos de uso para cada padrão, para ajudar a tomar uma decisão informada ao selecionar uma abordagem de integração para seu sistema.

Padrão de integração	Mecanismo	Gatilho	Prós	Contras	Use quando
Em tempo real ou síncrono	Os dados são trocados de forma síncrona, invocando ações via integração ponto a ponto ou usando retransmissão.	Ação do usuário ou evento do sistema.	Solicitação rápida e tempo de resposta. Valores e informações em tempo real.	Geralmente, não é uma prática recomendada a ser usada devido ao risco de os processos ficarem paralisados e criarem uma integração fortemente acoplada. Risco de efeito cascata de erros transitórios. Sensível à latência.	Use quando as informações em tempo real forem críticas.
Assíncrono	Os dados são trocados ou ingeridos sem supervisão em uma programação periódica ou como um feed lento usando padrões de mensagens.	Agendado por um período ou acionado por uma nova mensagem publicada pelo sistema de origem.	O baixo acoplamento de sistemas torna a solução robusta. Balanceamento de carga ao longo do tempo e recursos. Pode ser muito próximo do tempo real. Tratamento oportuno de erros.	Atraso na resposta e visibilidade das mudanças nos sistemas.	Necessidades de sincronização de dados quase em tempo real para volumes de dados baixos ou médios
Envio em lote	O envio em lote é a prática de reunir e transportar um conjunto de mensagens ou registros em um lote para limitar a vibração e a sobrecarga.	Gatilho programado ou manual.	Ótimo para uso com serviços de mensagens e outros padrões de integração assíncrona. Menos pacotes individuais e menos tráfego de mensagens.	A atualização dos dados é menor. A carga no sistema receptor pode ser afetada se a lógica de negócios for executada na chegada da mensagem.	Cenários de alto volume ou volatilidade em que é possível reunir e transportar um conjunto de mensagens ou registros em lote, cenários de replicação de dados.
Apresentação	As informações de um sistema são perfeitamente integradas à interface do usuário de outro sistema.	N/A	Eliminando a complexidade da sincronização de dados, pois os dados permanecem no sistema de origem.	Dificuldade de usar os dados para cálculos para processamento, mais complexidades para satisfazer o logon único, script de origem cruzada e alinhamento de autorização.	Quando o requisito é atendido exibindo o sistema de origem ou a interface do usuário diretamente, sem a necessidade de sincronizar dados entre o sistema de origem e o de destino.