Dois sistemas podem se integrar quando um grava dados em tabelas que o outro consulta. O acesso ao banco precisa funcionar, mas a integração também depende de saber quando um registro está pronto e quais regras permitem alterá-lo.
O banco como interface
A integração pode usar um banco compartilhado, tabelas intermediárias, views ou uma ligação entre bancos. Um sistema publica os dados em uma estrutura combinada, e o outro lê ou atualiza esses dados pelo mecanismo autorizado.
O servidor, o banco e o usuário na configuração, as tabelas de interface e os erros de SQL nos registros sugerem uma integração por banco. O próprio sistema também usa esses dados no funcionamento normal, e por isso o papel de cada conexão é confirmado antes da classificação.
Estrutura e concorrência
O acoplamento aumenta quando um programa depende das tabelas internas de outro. Uma coluna renomeada, um tipo alterado ou uma regra nova pode tornar a consulta incompatível. Views e tabelas de interface formam um contrato mais controlado, que também precisa de versão e de manutenção.
Operações simultâneas podem gerar bloqueios e conflitos. As validações podem estar no banco ou na aplicação, e o acesso direto não garante nem a presença nem a ausência delas. Uma gravação direta em tabelas de negócio, sem um contrato que a permita, pode violar regras que só a aplicação conhece.
Os erros de banco apontam situações diferentes. No MySQL, alguns códigos comuns são estes:
1045: o acesso foi negado ao usuário;1054: a coluna informada não existe;1062: a chave já existe, em uma entrada duplicada;1146: a tabela não existe;1205: a espera por um bloqueio de linha acabou, no InnoDB.
O comando SQL e a mensagem completa separam um problema de acesso, de estrutura ou de processamento.
Tabelas de situação e de log
Algumas integrações registram a situação, as tentativas e a mensagem de cada registro em tabelas próprias. Uma consulta de leitura, autorizada e feita pelo identificador do registro, esclarece o histórico.
Cada valor de situação precisa ter um significado conhecido. Enviado pode indicar só uma etapa, e pendente pode aguardar outro processo. A alteração manual da situação para forçar uma conclusão, sem o procedimento específico, esconde a falha e pode quebrar o processo.
Quando o registro está pronto
O contrato de uma tabela intermediária define quais registros formam uma unidade, como o cabeçalho e os itens de um pedido, e qual situação libera essa unidade para o processamento. A leitura de um cabeçalho gravado enquanto os itens ainda chegam produz um pedido incompleto. Em uma tabela MyISAM, que não tem transações, cada gravação fica visível na hora, e o sinal de prontidão é a proteção contra essa leitura.
Também é preciso uma regra para que dois consumidores não peguem o mesmo trabalho e para registrar a conclusão ou a falha recuperável. Ler os pendentes e atualizar depois, sem coordenação, pode deixar dois processos tratando a mesma linha.
Uma transação local não une uma chamada remota e a gravação no banco. Quando a API conclui e a gravação falha, o ROLLBACK local não desfaz a operação remota, e o identificador remoto, a política de repetição e a reconciliação tratam essa diferença.
No suporte
Diante de uma integração por banco, convém conferir a conexão, o contrato da tabela ou da view, a versão e a situação do registro. O comando, o erro e o histórico são lidos juntos, porque a mensagem de SQL não indica sozinha qual componente causou a divergência.
Para guardar
- A integração por banco depende da estrutura, do acesso e das regras combinadas.
- Mudanças de estrutura e operações simultâneas podem quebrar o processo.
- Uma tabela de situação é evidência quando o significado de cada valor é conhecido.
- O sinal de prontidão evita a leitura de um registro incompleto.
- Uma transação local não desfaz uma operação remota.
Depois de uma atualização, a integração informa o erro 1054, de coluna inexistente. Qual hipótese investigar?
Uma incompatibilidade entre a consulta e a estrutura ou a versão do banco. O SQL, o banco selecionado e as alterações de estrutura são conferidos, porque a proximidade com a atualização não prova sozinha qual mudança causou o erro.
Uma tabela registra o pedido como enviado, mas o outro sistema não mostra o pedido. Isso confirma que ele foi importado?
Não. A situação enviado pode representar só a disponibilização dos dados. O significado da situação e a etapa de leitura e de processamento no outro sistema mostram o que aconteceu.