Integração de Sistemas

Por que os sistemas não conversam

A ausência de comunicação entre sistemas quase nunca é decisão consciente, é resultado do jeito como o parque tecnológico foi montado. Cada ferramenta foi comprada em um momento diferente, por uma área diferente, para resolver um problema específico, e ninguém foi contratado para pensar no conjunto.

O efeito aparece em forma de trabalho humano. Alguém exporta o relatório do ERP e importa no BI; alguém copia o pedido do e-commerce para o sistema de expedição; alguém confere se o cadastro do cliente está igual nos dois lugares. Esse trabalho é invisível no organograma e caro na prática, porque consome tempo qualificado em tarefa de transporte.

Há um custo adicional que só aparece na hora de decidir: sem integração, a informação vive fragmentada e a empresa não consegue responder perguntas que atravessam áreas. Quanto custa conquistar o cliente que efetivamente pagou é uma pergunta que exige marketing, comercial e financeiro na mesma leitura.

As formas de integrar, e o que cada uma exige

Existem caminhos diferentes para conectar dois sistemas, e a escolha depende do que cada um oferece, do volume e da urgência da informação. As formas mais usadas:

• API: a interface que o sistema expõe para que outro consulte ou grave informação de forma estruturada. É o caminho preferido quando existe, porque é controlado e documentado;
• webhook: o sistema avisa o outro no momento em que algo acontece, em vez de esperar ser consultado. Reduz atraso e carga;
• troca de arquivos: exportação programada em formato estruturado, comum em sistemas antigos que não têm API. Funciona, com atraso maior e mais chance de inconsistência;
• acesso direto ao banco de dados: leitura da base do sistema. Rápido de implementar e arriscado de manter, porque depende da estrutura interna do produto, que pode mudar sem aviso;
• middleware ou barramento: uma camada intermediária que centraliza as conexões, indicada quando existem muitos sistemas envolvidos.

A última opção merece explicação. Conectar cada sistema diretamente a cada outro produz uma teia que cresce em progressão desconfortável: com cinco sistemas ligados entre si, são dez conexões para manter. Uma camada central reduz isso a cinco, e passa a valer a pena a partir de certo tamanho.

Documentação, versão e o que perguntar ao fornecedor

Antes de escolher o caminho técnico, vale levantar com cada fornecedor um conjunto pequeno de informações que determina o esforço do projeto. A documentação da interface está disponível publicamente ou só sob contrato? Existe ambiente de teste separado do de produção?

Quais são os limites de chamadas por período, e o que acontece quando eles são atingidos? Como as credenciais são emitidas e com que validade? Qual a política de descontinuação de versões, e com quanto tempo de aviso? Existe suporte técnico para dúvida de integração, ou apenas para uso da ferramenta?

Essas respostas mudam o desenho e o risco. Um sistema sem ambiente de teste obriga a estratégias mais conservadoras de entrada em produção; um sem política clara de versões coloca a integração em risco de parar sem aviso em qualquer atualização do fornecedor.

Vale registrar tudo isso em um lugar consultável. Quando a integração quebrar daqui a dois anos, quem estiver resolvendo vai precisar exatamente dessas informações, e recuperá-las do zero custa dias de trabalho.

Integração de API na prática

Integrar por API significa conectar dois sistemas usando a interface que eles disponibilizam para troca programada de dados, respeitando o formato, a autenticação e os limites que o fornecedor definiu. É o caminho mais confiável, e ainda assim há detalhes que decidem se a conexão vai sustentar a operação.

O primeiro é o limite de requisições. Quase toda API restringe quantas chamadas podem ser feitas por minuto ou por dia, e uma integração que ignora isso funciona no teste e falha no pico de movimento. O tratamento correto envolve espaçar as chamadas, agrupar registros quando possível e recuar quando o limite é atingido.

O segundo é a autenticação e sua renovação. Chaves expiram, tokens são rotacionados, credenciais são revogadas quando um funcionário sai. Uma integração que não trata a renovação para de funcionar em algum momento previsível.

O terceiro é a mudança de versão. Fornecedores atualizam APIs e descontinuam versões antigas, normalmente com aviso prévio que ninguém lê. Registrar quais integrações dependem de quais versões é o que permite planejar a migração antes do desligamento.

Qual sistema manda: a decisão que evita conflito

Antes de conectar dois sistemas, é preciso definir qual deles é a fonte de verdade para cada informação. Sem essa definição, os dois passam a sobrescrever um ao outro e a empresa ganha um problema pior do que o que tinha.

O caso mais comum envolve cadastro de cliente. Se o e-commerce e o ERP podem alterar o endereço, e a integração sincroniza nos dois sentidos, uma alteração feita em um lugar pode ser desfeita pela sincronização vinda do outro. Quando isso acontece de forma intermitente, o diagnóstico é penoso.

A definição costuma ser feita por campo, e não por sistema inteiro. O ERP é dono do preço e do estoque; o e-commerce é dono da descrição comercial e das imagens; o CRM é dono do estágio da negociação. Escrever essa distribuição é um dos artefatos mais úteis de um projeto de integração, e um dos mais esquecidos.

Carga inicial: o que fazer com o histórico

Antes de a integração passar a operar no dia a dia, é preciso decidir o que acontece com o que já existe nos dois lados. Essa carga inicial costuma ser a operação mais delicada do projeto, porque envolve volume grande de uma só vez e altera dados que a empresa já usa.

As decisões necessárias são poucas e importantes. Qual período de histórico migra, já que trazer tudo raramente compensa. O que fazer com registros que existem nos dois sistemas com informações divergentes. E se os registros antigos passam a ser sincronizados continuamente ou ficam congelados como estão.

A prática que reduz risco é executar a carga em um recorte pequeno primeiro, conferir o resultado registro a registro e só então rodar o volume completo. Vale também guardar uma cópia do estado anterior, porque desfazer uma carga malfeita sem esse ponto de retorno costuma custar mais do que o projeto inteiro.

Sincronização: quando o dado precisa chegar

A frequência da troca é uma decisão de negócio com consequência técnica direta. Nem tudo precisa ser instantâneo, e tratar tudo como urgente encarece o projeto sem melhorar a operação.

Informação que muda decisão imediata pede sincronização em tempo real, normalmente por webhook: um pedido aprovado no site precisa chegar na expedição agora. Informação de acompanhamento tolera lotes periódicos: o cadastro contábil pode ser atualizado a cada hora sem prejuízo.

A escolha também considera custo. Sincronização em tempo real sobre uma API com limite apertado pode ser inviável em volume alto, e nesses casos o desenho correto combina os dois: evento imediato para o que é crítico, e carga periódica para o restante.

Repetição sem duplicidade

Uma integração confiável precisa poder repetir uma operação sem duplicar o efeito dela, propriedade que em arquitetura se chama idempotência. Isso parece detalhe técnico e resolve um problema muito concreto.

O cenário é simples de imaginar. O sistema A envia um pedido para o sistema B, B recebe e grava, e a resposta se perde no caminho. A não sabe se deu certo. Se ele tentar de novo sem controle, o pedido é criado duas vezes; se não tentar, o pedido pode nunca ter chegado.

A solução envolve identificar cada operação com uma referência única, de modo que o receptor reconheça a repetição e ignore a segunda tentativa. Integrações construídas sem esse cuidado geram pedidos duplicados, cobranças repetidas e registros fantasma, e o efeito costuma aparecer justamente nos dias de maior movimento.

Monitoramento e o que fazer quando algo falha

Toda integração vai falhar em algum momento, e o projeto precisa definir o comportamento nessas horas. Sistema fora do ar, campo obrigatório vazio, formato inesperado e limite atingido são ocorrências normais em ambiente de produção.

O desenho adequado registra cada tentativa, repete automaticamente as falhas temporárias com intervalo crescente, separa em uma fila de exceção o que não pôde ser processado e avisa uma pessoa quando a intervenção humana é necessária. A fila de exceção é importante: sem ela, o registro que falhou simplesmente desaparece.

O monitoramento acompanha o volume esperado, não apenas o erro explícito. Uma integração que deveria processar duzentos pedidos por dia e processou três não gerou erro nenhum, e ainda assim está quebrada. Alerta por ausência de movimento captura esse tipo de falha, que é a mais difícil de perceber.

Segurança e proteção de dados na troca

Integração movimenta dado sensível entre sistemas, e o desenho precisa considerar isso desde o início. Cadastro de cliente, informação de pagamento e histórico de compra circulam nessas conexões.

As práticas que a DreamMark aplica incluem transporte criptografado, credenciais guardadas fora do código e com rotação prevista, permissão mínima necessária para cada integração, e registro de acesso que permita auditoria posterior. Uma integração que usa credencial de administrador para uma tarefa que exige apenas leitura amplia o estrago de qualquer incidente.

Há também o critério de necessidade. Trafegar apenas os campos que a outra ponta realmente usa reduz exposição e simplifica a adequação à LGPD. Enviar a base inteira porque era mais fácil é uma escolha que cobra caro depois.

Como a DreamMark conduz o projeto

O trabalho começa pela arquitetura e termina no acompanhamento em produção:

1. Inventário: quais sistemas existem, o que cada um guarda e onde a informação se repete;
2. Definição de fonte de verdade: qual sistema é dono de cada campo, escrito e acordado entre as áreas;
3. Verificação de acesso: API disponível, documentação, limites, ambiente de teste e forma de autenticação;
4. Desenho da integração: direção do fluxo, frequência, tratamento de erro e comportamento em caso de conflito;
5. Implementação: construção com registro de execução, controle de repetição e fila de exceção;
6. Testes: validação com dados reais, incluindo os casos estranhos que a operação produz;
7. Entrada em produção assistida: período de acompanhamento com o processo anterior ainda disponível;
8. Documentação e monitoramento: registro da arquitetura e configuração dos alertas.

A etapa 3 define o que é possível prometer. Sistema sem API, sem documentação ou sem ambiente de teste muda completamente o esforço e o risco, e essa checagem acontece antes do compromisso de prazo.

Quando a integração não é a resposta

Nem todo problema de informação fragmentada se resolve conectando sistemas. Em alguns casos, a integração apenas mantém viva uma arquitetura que já deveria ter sido simplificada.

Quando duas ferramentas fazem quase a mesma coisa e a empresa mantém as duas por hábito, unificar costuma custar menos que integrar. Quando o sistema de origem está prestes a ser substituído, construir uma conexão elaborada para ele é investimento com prazo curto. E quando o problema é que o dado nunca é preenchido, nenhuma integração resolve, porque não há o que transportar.

A DreamMark aponta esses casos em vez de seguir com o escopo pedido, porque integração mal indicada vira manutenção permanente sem retorno proporcional.

Conversão de dados entre os dois lados

Dois sistemas quase nunca representam a mesma informação da mesma forma, e a camada de conversão costuma ser onde o projeto passa mais tempo. Não é trabalho glamouroso e é o que determina se a integração vai funcionar em produção.

As divergências mais comuns aparecem em coisas simples. Datas com fuso horário diferente, ou gravadas sem fuso nenhum. Valores decimais com separadores distintos. Documentos com e sem formatação. Telefone com e sem código de país. Códigos de estado escritos por extenso de um lado e abreviados do outro.

Há também as diferenças de vocabulário. O status "em andamento" de um sistema pode corresponder a dois status distintos no outro, e essa correspondência precisa ser decidida por alguém que entende do negócio, não inferida por quem implementa.

A parte mais delicada é o campo que existe de um lado e não do outro. Quando o sistema de destino exige uma informação que a origem não guarda, o projeto precisa decidir entre um valor padrão, uma regra de dedução ou o bloqueio do registro. As três opções têm consequência, e escolher por omissão é o pior caminho.

Ambiente de teste e a entrada em produção

Integração testada apenas em produção cria risco desproporcional, porque o erro não fica contido: ele grava dado errado em sistemas que a operação usa. Por isso a existência de um ambiente de homologação é uma das primeiras verificações do projeto.

Nem todo sistema oferece esse ambiente, e quando não oferece o desenho precisa compensar. Os caminhos usuais são testar com um conjunto restrito de registros marcados, operar inicialmente apenas em modo de leitura, ou executar a integração com a gravação desligada e comparar o que ela teria feito com o que a operação fez manualmente.

A entrada em produção costuma ser feita de forma gradual, começando por um subconjunto e ampliando conforme a estabilidade se confirma. Junto com isso, vale ter definido como desligar rapidamente a integração se algo inesperado aparecer, e como corrigir o que já foi gravado errado. Plano de reversão pensado antes vale mais do que improviso durante o incidente.

Como começar

O primeiro passo é desenhar, mesmo que de forma simples, quais sistemas a empresa usa e por onde a informação passa hoje, incluindo os trechos em que ela passa por uma pessoa. Esse desenho revela em pouco tempo onde a conexão traria mais alívio.

A DreamMark atende de forma remota em todo o Brasil, a partir do Rio Grande do Sul, com reuniões presenciais em Gravataí, Cachoeirinha, Porto Alegre e região metropolitana, Lajeado, Caxias do Sul, Santa Cruz do Sul e no Litoral Norte gaúcho.

Vale reunir, junto com esse desenho, o nome e o contato de quem responde tecnicamente por cada sistema, incluindo os fornecedores externos. Boa parte do prazo de um projeto de integração é consumida esperando resposta sobre acesso e credencial, e ter esse mapa pronto encurta bastante o início.

Também ajuda listar o que já foi tentado antes. Muitas empresas têm integrações antigas que funcionaram por um período e pararam, e entender por que elas pararam costuma revelar restrições do ambiente que economizam semanas de investigação.