Os cinco principais padrões de integração de dados

Os dados são um ativo comercial valioso, mas muitas vezes podem ser difíceis de acessar, orquestrar e interpretar.

Quando os dados se movem entre sistemas, nem sempre estão em um formato padrão; a integração de dados torna os dados agnósticos — para que possam ser acessados e manipulados com facilidade.

Para tornar os dados ainda mais utilizáveis com mais rapidez, os desenvolvedores podem usar padrões de integração de dados para padronizar o processo de integração.

Como uma trilha de caminhada, os padrões são descobertos e estabelecidos com base no uso. Os padrões sempre vêm em graus de perfeição, mas podem ser otimizados ou adotados de acordo com as necessidades de negócios que exigem soluções. Você pode pensar no caso de uso de negócios como uma instanciação do padrão, ou seja, um uso para o processo genérico de movimentação e manuseio de dados.

Há cinco padrões de integração de dados baseados em casos de uso de negócios e padrões de integração em nuvem.

Migração é o ato de mover dados de um sistema para outro. Uma migração contém um sistema de origem onde os dados residem antes da execução, um critério que determina o escopo dos dados a serem migrados, uma transformação pela qual o conjunto de dados passará, um sistema de destino onde os dados serão inseridos e a capacidade de capturar os resultados da migração para saber o estado final em relação ao estado desejado.

A migração de dados é essencial para todos os sistemas de dados. Gastamos muito tempo criando e mantendo dados, e a migração é o segredo para manter esses dados agnósticos das ferramentas que usamos para criá-los, visualizá-los e gerenciá-los. Sem a migração, perderemos todos os dados que acumulamos sempre que quisermos alterar as ferramentas — prejudicando nossa capacidade de ser produtivos no mundo digital.

A migração de dados ocorre ao mover de um sistema para outro, mover para outra instância ou instância mais nova desse sistema, implantar um novo sistema que estende sua infraestrutura atual, fazer backup de um conjunto de dados, adicionar nós a clusters de bancos de dados, substituir hardware de banco de dados, consolidar sistemas e muitos mais.

A transmissão também pode ser chamada de “sincronização unilateral de um para muitos” e se refere ao ato de mover dados de um único sistema de origem para vários sistemas de destino de forma contínua e em tempo real (ou quase em tempo real).

Sempre que houver necessidade de manter nossos dados atualizados entre vários sistemas ao longo do tempo, você precisará de um padrão de transmissão, sincronização bidirecional ou correlação. O padrão de transmissão, assim como o padrão de migração, move os dados apenas em uma direção, da origem ao destino. O padrão de transmissão, ao contrário do padrão de migração, é transacional.

Isso significa que ele não executa a lógica dos processadores de mensagem para todos os itens que estão no escopo. Ele executa a lógica apenas para os itens que foram alterados recentemente. Pense na transmissão como uma janela deslizante que captura apenas os itens que possuem valores de campo que foram alterados desde a última transmissão.

Outra grande diferença está em como a implementação do padrão é projetada. A migração será ajustada para suportar grandes volumes de dados e processar muitos registros em paralelo e para ter um caso de falha normal. Os padrões de transmissão são otimizados para processar os registros rapidamente e serem altamente confiáveis para evitar a perda de dados críticos em trânsito.

O padrão de transmissão é extremamente valioso quando o sistema B precisa saber algumas informações quase em tempo real que são oriundas ou residentes do sistema A. Por exemplo, você pode criar um painel de relatórios em tempo real — um destino de vários aplicativos de transmissão que recebe atualizações em tempo real sobre o que está acontecendo em vários sistemas.

Você pode iniciar imediatamente o atendimento de pedidos que vêm de seu CRM, ferramenta de comércio eletrônico ou ferramenta interna onde o sistema de processamento de atendimento é centralizado, independentemente do canal de origem do pedido. Você pode enviar uma notificação da temperatura de sua turbina a vapor para um sistema de monitoramento a cada 100 ms. Você pode transmitir para um sistema de gerenciamento de pacientes de um clínico geral quando um de seus pacientes regulares der entrada no pronto-socorro. Existem inúmeros exemplos de quando você pode transferir dados de um sistema de origem e transmiti-los para outro.

A "necessidade" do padrão de transmissão pode ser facilmente identificada pelos seguintes critérios:

• O sistema B precisa saber assim que o evento acontece? — Sim
• Os dados precisam fluir de A para B automaticamente, sem envolvimento humano? — Sim
• O sistema A precisa saber o que acontece com o objeto no sistema B? — Não

A primeira pergunta ajudará você a decidir se deve usar o padrão de migração ou transmissão com base na necessidade de os dados serem transmitidos em tempo real. Qualquer coisa abaixo de aproximadamente a cada hora tende a ser um padrão de transmissão. No entanto, sempre há exceções com base nos volumes de dados.

A segunda pergunta geralmente exclui aplicativos “sob demanda” e, em geral, os padrões de transmissão serão iniciados por uma notificação por push ou uma tarefa agendada e, portanto, não terão envolvimento humano.

Com a última pergunta, você saberá se é necessário unir os dois conjuntos de dados para que sejam sincronizados em dois sistemas, o que chamamos de sincronização bidirecional. Diferentes necessidades exigirão padrões de integração de dados diferentes, mas o padrão de transmissão é muito mais flexível no que se refere a como você pode associar os aplicativos, e recomendamos o uso de dois aplicativos de transmissão em vez de um aplicativo de sincronização bidirecional.

O padrão de integração de dados por sincronização bidirecional é o ato de combinar dois conjuntos de dados em dois sistemas diferentes para que se comportem como um, respeitando a necessidade de existirem como conjuntos de dados diferentes. Esse tipo de necessidade de integração surge quando se tem diferentes ferramentas ou diferentes sistemas para realizar diferentes funções no mesmo conjunto de dados.

Por exemplo, você pode ter um sistema para receber e gerenciar pedidos e um sistema diferente para o suporte ao cliente. Você pode descobrir que esses dois sistemas são os melhores da categoria e que é importante usá-los em vez de um conjunto que ofereça suporte a ambas as funções e tenha um banco de dados compartilhado. O uso da sincronização bidirecional para compartilhar o conjunto de dados permite o uso de ambos os sistemas, mantendo uma visualização consistente e em tempo real dos dados nos dois sistemas.

A sincronização bidirecional pode ser viabilizadora e salvadora, dependendo das circunstâncias que justificam sua necessidade. Se tiver duas ou mais representações independentes e isoladas da mesma realidade, você poderá usar a sincronização bidirecional para otimizar seus processos.

Por outro lado, você pode usar a sincronização bidirecional para sair de um pacote de produtos que funcionam bem juntos — mas podem não ser os melhores em suas funções individuais — para um pacote que você escolhe a dedo e integra usando uma plataforma de integração corporativa, como Anypoint Platform da MuleSoft.

A necessidade de um aplicativo de integração de sincronização bidirecional é sinônimo de querer que as representações de objetos da realidade sejam abrangentes e consistentes. Por exemplo, se quiser uma visão única de seu cliente, você poderá resolver isso manualmente, concedendo para todos o acesso a todos os sistemas que têm uma representação da noção de um cliente. No entanto, uma solução mais eficiente é listar quais campos precisam estar visíveis para aquele objeto de cliente em quais sistemas e quais sistemas são os proprietários.

A maioria dos sistemas corporativos tem uma maneira de estender objetos de forma que você possa modificar a estrutura de dados do objeto do cliente para incluir esses campos. Em seguida, você pode criar aplicativos de integração como aplicativos ponto a ponto (usando uma plataforma de integração comum) se for uma solução simples, ou um sistema de roteamento mais avançado como um modelo de roteamento pub/sub ou de fila se houver vários sistemas em jogo.

Por exemplo, um vendedor deve saber o status de uma entrega, mas não precisa saber em qual armazém a entrega está. Da mesma forma, o entregador precisa saber o nome do cliente para quem se destina a entrega, sem precisar saber quanto o cliente pagou por ela. A sincronização bidirecional permite que ambas as pessoas tenham uma visão em tempo real do mesmo cliente através das lentes necessárias.

O padrão de integração de dados por correlação é um design que identifica a interseção de dois conjuntos de dados e faz uma sincronização bidirecional desse conjunto de dados com escopo definido apenas se esse item ocorrer em ambos os sistemas naturalmente. Isso é semelhante à forma como o padrão bidirecional sincroniza a união do conjunto de dados com escopo definido, a correlação sincroniza a interseção.

No caso do padrão de correlação, os itens que residem em ambos os sistemas podem ter sido criados manualmente em cada um desses sistemas, como dois representantes de vendas entrando no mesmo contato em ambos os sistemas de CRM. Ou eles podem ter sido trazidos como parte de uma integração diferente. O padrão de correlação não se importará com a origem desses objetos; ele os sincronizará de forma agnóstica, contanto que estejam em ambos os sistemas.

O padrão de integração de dados de correlação é útil quando você tem dois grupos ou sistemas que desejam compartilhar dados apenas se ambos tiverem um registro que representa o mesmo item/pessoa na realidade. Por exemplo, um grupo de hospitais possui dois hospitais na mesma cidade. Você pode querer compartilhar dados entre os dois hospitais para que, caso um paciente use qualquer um dos hospitais, você tenha um registro atualizado do tratamento que recebeu em ambos os locais.

Para realizar uma integração como essa, você pode decidir criar duas integrações de padrão de transmissão, uma do Hospital A para o Hospital B e uma do Hospital B para o Hospital A. Isso garantirá que os dados sejam sincronizados. No entanto, agora você tem dois aplicativos de integração para gerenciar.

Para aliviar a necessidade de gerenciar dois aplicativos, você pode apenas usar o padrão de sincronização bidirecional entre os Hospitais A e B. Mas, para aumentar a eficiência, você pode querer que a sincronização não traga os registros dos pacientes do Hospital B se esses pacientes não tiverem associação com o Hospital A e trazê-los em tempo real assim que o registro do paciente for criado. O padrão de correlação é valioso porque sincroniza apenas bidirecionalmente os objetos somente quando é preciso saber tais dados, em vez de sempre mover todo o escopo do conjunto de dados em ambas as direções.

O padrão de integração de dados de correlação é útil quando você tem dois grupos ou sistemas que desejam compartilhar dados apenas se ambos tiverem um registro que representa o mesmo item/pessoa na realidade. Por exemplo, um grupo de hospitais possui dois hospitais na mesma cidade. Você pode querer compartilhar dados entre os dois hospitais para que, caso um paciente use qualquer um dos hospitais, você tenha um registro atualizado do tratamento que recebeu em ambos os locais.

Para realizar uma integração como essa, você pode decidir criar duas integrações de padrão de transmissão, uma do Hospital A para o Hospital B e uma do Hospital B para o Hospital A. Isso garantirá que os dados sejam sincronizados. No entanto, agora você tem dois aplicativos de integração para gerenciar.

Para aliviar a necessidade de gerenciar dois aplicativos, você pode apenas usar o padrão de sincronização bidirecional entre os Hospitais A e B. Mas, para aumentar a eficiência, você pode querer que a sincronização não traga os registros dos pacientes do Hospital B se esses pacientes não tiverem associação com o Hospital A e trazê-los em tempo real assim que o registro do paciente for criado. O padrão de correlação é valioso porque sincroniza apenas bidirecionalmente os objetos somente quando é preciso saber tais dados, em vez de sempre mover todo o escopo do conjunto de dados em ambas as direções.

O padrão de integração de dados por correlação é mais útil quando ter os dados extras é mais caro do que benéfico, pois permite que você retire do escopo os dados “desnecessários”. Por exemplo, se você for uma universidade, parte de um sistema universitário maior e deseja gerar relatórios para seus alunos.

Você provavelmente não quer nesses relatórios um monte de alunos que nunca frequentaram sua universidade. Mas você pode querer incluir as unidades que esses alunos concluíram em outras universidades do seu sistema universitário. Aqui, o padrão de correlação pouparia muito esforço tanto na integração quanto na geração de relatórios, pois permitiria sincronizar apenas as informações dos alunos que frequentaram as duas universidades.

Agregação é o ato de pegar ou receber dados de vários sistemas e inseri-los em um sistema. Por exemplo, a integração de dados do cliente pode residir em três sistemas diferentes, e um analista de dados pode querer gerar um relatório que use dados de todos eles. Uma pessoa pode criar uma migração diária de cada um desses sistemas para um repositório de dados e depois consultar esse banco de dados. Mas, com isso, haveria outro banco de dados para controlar e manter sincronizado.

Além disso, conforme as coisas mudam nos outros três sistemas, o repositório de dados teria de ser constantemente atualizado. Outra desvantagem é que os dados teriam um dia de duração. Portanto, para relatórios em tempo real, o analista teria de iniciar as migrações manualmente ou esperar outro dia. Há a possibilidade de configurar três aplicativos de transmissão, chegando a uma situação em que o banco de dados de relatórios é sempre atualizado com as mudanças mais recentes em cada um dos sistemas. Mas ainda haveria a necessidade de manter esse banco de dados que armazena apenas dados replicados para poderem ser consultados de vez em quando. Além disso, haveria uma série de chamadas desnecessárias à API para garantir que o banco de dados esteja sempre a X minutos da realidade.

É aí que o padrão de agregação entra. Se você criar um aplicativo ou usar um de nossos modelos baseados nesse padrão, perceberá que pode consultar vários sistemas sob demanda, mesclar o conjunto de dados e fazer o que quiser com ele.

Por exemplo, você pode criar um app de integração que consulta os vários sistemas, mescla os dados e depois produz um relatório. Dessa forma, você evita ter um banco de dados separado e pode fazer com que o relatório chegue em um formato como .csv ou no formato de sua preferência. Você pode colocar o relatório no local onde os relatórios são armazenados diretamente.

O padrão de agregação deriva seu valor ao permitir que você extraia e processe dados de vários sistemas em um aplicativo unificado. Isso significa que os dados são atualizados no momento em que você precisa deles, não são replicados e podem ser processados ou mesclados para produzir o conjunto de dados que você deseja.

O padrão de agregação é valioso quando você cria APIs de orquestração para “modernizar” sistemas legados, especialmente quando se cria uma API que obtém dados de vários sistemas e os processa em uma resposta. Outro caso de uso é criar relatórios ou painéis que extraiam dados de vários sistemas e criam uma experiência com esses dados.

Finalmente, você pode ter sistemas usados para fins de conformidade ou auditoria que precisam ter dados relacionados de vários sistemas. O padrão de agregação é útil para garantir que seus dados de conformidade residam em um sistema, mas pode ser a combinação de dados relevantes de vários sistemas. Você pode, portanto, reduzir a quantidade de aprendizado que precisa ocorrer nos vários sistemas para garantir a visibilidade do que está acontecendo.