Leonardo Peron5 min de leitura
"Esse sistema não tem API" é uma das frases mais repetidas em reunião de integração no Brasil, e uma das menos verificadas. Ela costuma significar outra coisa: o comercial do fornecedor não soube responder, ou a API existe e é um módulo pago, ou existe e só é liberada para parceiro homologado. Antes de desenhar contorno, vale gastar uma semana atrás da resposta real.
Confirme a ausência antes de aceitá-la
Pergunte por escrito, ao suporte técnico e não ao vendedor, quatro coisas específicas, porque "vocês têm integração?" convida a uma resposta vaga:
Existe API documentada, e sob quais condições comerciais. Existe exportação agendada, para pasta ou servidor de transferência. Existe conector oficial para ferramenta de BI ou de integração. Onde ele existe há um caminho de leitura para reaproveitar. E existe programa de parceiro, com documentação que não circula fora dele.
A resposta muda o projeto inteiro e merece estar num e-mail, não numa lembrança de call. Sem ela, o resto deste texto é escolha entre saídas piores.
Primeira saída: exportação agendada
É a menos glamourosa e quase sempre a melhor. O sistema grava um arquivo com o que mudou, num horário combinado, e o outro lado lê.
O motivo de ela ganhar não é técnico, é contratual: arquivo tem layout, e layout é um acordo que alguém escreveu. Tabela de banco não é acordo nenhum, e tela muito menos. Publicando o layout, o fornecedor assume que aquilo tem versão e que mudança se avisa, mais do que as outras duas saídas oferecem.
O custo aparece em três lugares: a latência é o intervalo entre as rodadas, o lado que grava não sabe se alguém leu, e o conteúdo é o que o fornecedor decidiu exportar, não o que você precisa. Os detalhes de como fazer isso sobreviver estão em integração por arquivo, que é o formato mais antigo em uso e o menos escrito.
Segunda saída: ler o banco direto
É a mais tentadora: o dado está ali, sem cota e sem espera, e num fim de semana alguém entrega uma consulta que parece resolver o problema.
O que se compra junto raramente é discutido. O banco de um sistema é a implementação dele, não um contrato: ninguém prometeu que a tabela continua existindo nem que a coluna continua significando a mesma coisa depois da próxima versão. Quando muda, não vem erro, vem dado errado, que é a falha mais cara de todas. É o mesmo alerta que vale para integração de ERP, e ele não fica mais barato porque o sistema é pequeno.
Há ainda dois efeitos que só aparecem depois. A consulta pesada disputa recurso com a operação, e a lentidão da terça vira discussão sem dono. E há contrato em que acesso direto ao banco suspende o suporte: no dia do problema, a resposta é que a base foi tocada por fora.
O que exigir por contrato antes de aceitar essa via, e antes de escrever a primeira consulta:
- Autorização escrita do fornecedor, dizendo que o acesso não afeta suporte nem garantia.
- Somente leitura, e não como promessa: como usuário sem permissão de escrita. Escrever na tabela pula a regra que o sistema aplica ao gravar, e o defeito aparece meses depois, num fechamento.
- Réplica ou janela de baixa carga, para a consulta não competir com quem está operando.
- Uma camada de visões estáveis mantida pelo fornecedor, em vez de tabela crua. É o único item que transforma implementação em contrato.
- Aviso de mudança de esquema junto com o comunicado de nova versão, e uma pessoa nomeada que manda esse aviso.
- Um plano de reteste a cada atualização do sistema, tratado como risco e não como formalidade.
Quando o fornecedor recusa todos, a informação é sobre o fornecedor, não sobre o banco, e ela vale para a decisão de integrar ou trocar.
Terceira saída: automação de tela
O robô abre o sistema, digita e lê como uma pessoa faria. É a única saída que funciona quando não há arquivo nem banco (portal de órgão público, sistema de terceiro, legado sem interface), e a comparação entre RPA e integração por API detalha quando ela se justifica.
O que falta no orçamento não é a construção, é a operação. O robô precisa de uma credencial, e credencial é de uma pessoa: quando ela sai, ou quando entra segundo fator, o robô para. As ações ficam registradas com o nome dessa pessoa, o que atrapalha auditoria. E mudança de tela quebra tudo, em silêncio, que é o pior jeito de quebrar.
Automação de tela é ponte, e ponte precisa de data de demolição. Sem previsão de saída, ela vira infraestrutura crítica que ninguém projetou para isso: o mesmo lugar em que mora o sistema que ninguém sabe manter.
O levantamento que decide a via
Antes de escolher, junte estas respostas e leve-as ao levantamento:
- A resposta escrita do fornecedor às quatro perguntas do começo.
- Quais entidades precisam atravessar, e em que direção. Se alguma precisa escrever no sistema sem API, isso elimina a leitura de banco e restringe muito o resto.
- Qual atraso é aceitável em cada uma. Exportação diária resolve cadastro e não resolve saldo.
- Com que frequência o sistema é atualizado, e se o fornecedor avisa antes.
- Quem é o dono da credencial que a via escolhida vai usar, e o que acontece quando essa pessoa sai.
O teste que vale mais que os cinco: peça ao fornecedor o registro de mudanças da última atualização. Se ele existir e disser o que mudou no banco ou no layout, qualquer via fica viável. Se não existir, você já sabe o formato do custo de manter, e ele entra na conta agora, não depois.