Integração unidirecional ou bidirecional: como decidir o sentido da sincronização sem criar conflitos de dados

Decidir entre uma integração unidirecional ou bidirecional não consiste apenas em desenhar uma seta entre duas aplicações. É uma decisão sobre propriedade dos dados, responsabilidades operacionais e tolerância ao risco. Uma ligação aparentemente simples entre um CRM, um ERP, um ecommerce ou uma plataforma de atendimento pode gerar duplicados, sobrescritas e erros de estado se ambos os sistemas modificarem a mesma informação sem regras explícitas.

A regra inicial é simples: sincronize nos dois sentidos apenas quando um processo real exigir que ambos os sistemas editem o mesmo domínio de dados. O facto de duas aplicações poderem trocar informações não significa que o devam fazer. Reduzir o número de fluxos e de campos editáveis tende a diminuir o custo de manutenção, os incidentes e as decisões manuais posteriores.

O que muda entre uma integração unidirecional e uma bidirecional

Numa integração unidirecional, um sistema publica ou envia informações e o outro recebe, replica ou consulta esses dados. Por exemplo, um ERP pode enviar catálogo, disponibilidade e preço para um ecommerce. O ecommerce recebe esses valores, mas não os corrige nem os devolve ao ERP.

Numa integração bidirecional, cada sistema pode gerar alterações que chegam ao outro. Um caso típico é o pedido: o ecommerce cria-o, o ERP atualiza a sua preparação ou faturação e o ecommerce precisa de refletir esse estado para informar o cliente. A bidirecionalidade pode ser adequada para esse objeto, mas não obriga a que todos os seus campos o sejam.

Convém evitar uma classificação global como “a integração é bidirecional”. A decisão útil é tomada por entidade, campo e operação:

• Entidade: cliente, pedido, produto, fatura, ticket ou inventário.
• Operação: criar, atualizar, cancelar, arquivar ou consultar.
• Campo: e-mail, morada de envio, estado, preço, identificador fiscal ou consentimento.

Assim, uma integração pode ser unidirecional para preços, bidirecional para estados de pedidos e apenas de consulta para faturas. Este nível de detalhe impede que uma alteração legítima num canal sobrescreva informações que pertencem a outro.

Comece pela propriedade dos dados, não pela API disponível

Antes de avaliar webhooks, tarefas agendadas ou capacidades de uma API, a equipa deve estabelecer um mapa de propriedade. Para cada dado relevante, responda quem o cria, quem o pode modificar, onde é validado e que aplicação o deve apresentar.

1. Identifique o sistema mestre. É a fonte autorizada quando existem discrepâncias. Não tem de ser o sistema onde o dado é visualizado com mais frequência.
2. Separe dados mestres e dados operacionais. Um ERP pode ser mestre de referências, impostos e disponibilidade, enquanto o ecommerce é mestre do canal de compra, do carrinho e da morada confirmada no checkout.
3. Defina a necessidade de retorno. Pergunte que decisão ou tarefa fica bloqueada se a alteração não regressar ao sistema de origem.
4. Documente as exceções. Pode haver campos com proprietários diferentes dentro da mesma entidade. Uma equipa comercial pode atualizar o telefone no CRM, enquanto a morada de entrega válida vem do pedido.

Surge um sinal de alerta quando a resposta a “quem decide sobre este campo?” é “depende”. Isso não impede a integração, mas exige transformar esse “depende” numa regra verificável: por estado, canal, data, tipo de cliente ou permissão de utilizador.

Quando um único sentido é suficiente e mais seguro

A sincronização unidirecional é a opção preferível quando existe uma fonte clara, o destinatário precisa principalmente de consumir dados e o retorno não desencadeia uma ação indispensável. É também adequada quando o dado é sensível, altamente regulado internamente ou difícil de reconciliar.

Casos frequentes incluem catálogo do ERP para o ecommerce, segmentos do CRM para uma plataforma de comunicações ou tickets fechados para um sistema de análise. Nestas situações, permitir edição no sistema recetor cria uma promessa difícil de cumprir: que qualquer alteração local será preservada e fará sentido fora desse contexto.

Sinais práticos para escolher um fluxo unidirecional

• Um sistema executa validações, aprovações ou cálculos que o outro não consegue reproduzir.
• O recetor precisa apenas de visibilidade, pesquisa, relatórios ou execução de uma tarefa posterior.
• As alterações no destino são locais, temporárias ou não devem afetar o registo mestre.
• Um conflito teria impacto financeiro, legal, operacional ou no atendimento ao cliente.
• A informação muda pouco ou pode ser atualizada em lotes sem afetar o processo.

O principal benefício não é apenas técnico. Um fluxo num único sentido permite explicar claramente por que motivo um valor aparece no ecrã e onde deve ser corrigido. Se o operador identificar um preço incorreto no ecommerce, sabe que deve corrigi-lo no ERP, e não editar uma cópia que será substituída na sincronização seguinte.

Quando a sincronização bidirecional se justifica

A bidirecionalidade justifica-se quando duas equipas trabalham em aplicações diferentes e ambas têm de concluir partes legítimas do mesmo processo. Deve existir uma necessidade operacional concreta, e não apenas o desejo de “ter tudo atualizado”.

Um exemplo habitual liga ecommerce, ERP e atendimento ao cliente. O ecommerce cria o pedido e recolhe a morada de envio. O ERP confirma a preparação, o envio ou o cancelamento. O atendimento ao cliente pode registar uma ocorrência ou um pedido de alteração. Ainda assim, nem todos devem editar os mesmos dados:

• O ecommerce é mestre dos dados recolhidos e confirmados durante a compra.
• O ERP é mestre dos estados logísticos, dos documentos operacionais e da disponibilidade comprometida.
• A aplicação de atendimento ao cliente pode criar um caso e propor uma ação, mas não deve alterar diretamente um estado logístico sem passar pela regra estabelecida no ERP.

Este desenho mantém uma experiência coordenada sem transformar três sistemas em autoridades equivalentes. A bidirecionalidade deve ter limites de escrita, e não apenas permissões de leitura.

Riscos dos dois sentidos e regras para resolver conflitos

As falhas típicas de uma sincronização bidirecional não costumam ser erros isolados de ligação. São ambiguidades de negócio expressas como erros de dados. As mais comuns são os ciclos de atualização, as sobrescritas, os duplicados, as alterações que chegam fora de ordem e os estados que não têm equivalência entre sistemas.

Um ciclo ocorre quando o sistema A atualiza o B, o B devolve a mesma alteração ao A e o ciclo continua. Uma sobrescrita surge quando dois utilizadores modificam um campo em locais diferentes antes de a integração propagar ambas as versões. Os duplicados aparecem se cada plataforma criar registos sem reconhecer o identificador da outra.

Para os evitar, defina uma política de conflitos antes de implementar:

• Precedência por campo: o ERP prevalece para stock; o ecommerce prevalece para a morada de entrega confirmada.
• Precedência por estado: enquanto um pedido está pendente, pode ser alterado no ecommerce; após a sua preparação, as alterações exigem um fluxo controlado.
• Última atualização: use-a apenas quando o relógio, o fuso horário e a semântica da alteração forem fiáveis. Não é uma regra universal.
• Revisão manual: envie os casos de elevado impacto para uma fila com responsável, motivo e dados comparados.
• Rejeição explícita: não aplique uma alteração incompatível; devolva um erro acionável e conserve a evidência.

Convém também modelar os estados. “Cancelado”, “reembolsado”, “enviado” e “fechado” nem sempre representam o mesmo em cada aplicação. Crie uma tabela de correspondência e determine quais as transições permitidas. Se um sistema não aceitar uma transição, não force uma equivalência que esconda uma exceção operacional.

Desenho técnico mínimo para uma integração operacional

A arquitetura deve suportar a política de dados, e não substituí-la. No mínimo, cada registo sincronizado precisa de um identificador interno estável e do identificador do sistema externo. Não utilize e-mail, nome ou referência visível como chave única se puderem mudar ou repetir-se.

• Marcas de origem: registe que sistema produziu a alteração para evitar que seja novamente processada como uma alteração nova.
• Versões ou datas de modificação: ajudam a detetar eventos atrasados e atualizações simultâneas.
• Idempotência: repetir uma mensagem não deve criar um pedido, cliente ou ticket adicional.
• Registo rastreável: guarde identificadores, direção do fluxo, resultado, erro e momento do processamento.
• Repetições controladas: distinga erros temporários de validações definitivas e limite as repetições.

origem: ecommerce
entidade: pedido
id_externo: EC-10452
versao: 7
operacao: atualizar_estado
chave_idempotencia: ecommerce-EC-10452-7

Este tipo de informação permite investigar por que motivo uma alteração não chegou, chegou duas vezes ou foi descartada. Sem rastreabilidade, a equipa acaba por comparar ecrãs e corrigir dados manualmente, uma prática que agrava a divergência.

Teste cenários de conflito e aprove o fluxo com uma checklist

Não valide uma integração apenas com criações e atualizações corretas. Os testes devem incluir alterações simultâneas, registos incompletos, eventos duplicados, erros de rede, permissões insuficientes e uma indisponibilidade prolongada de qualquer um dos sistemas.

Antes de aprovar a entrada em produção, confirme o seguinte:

• Cada entidade e campo importante tem um sistema mestre e um responsável de negócio.
• A direção de cada fluxo responde a uma necessidade operacional documentada.
• Existem regras de precedência, rejeição e revisão manual para conflitos.
• Os identificadores externos, a origem da alteração e a idempotência estão implementados.
• Os estados incompatíveis têm tratamento explícito, e não uma conversão implícita.
• Existem alertas e um procedimento para rever falhas, repetições e registos pendentes.
• As equipas sabem onde corrigir um dado e que alterações não devem fazer localmente.

A melhor integração não é a que movimenta mais dados nos dois sentidos. É a que preserva uma fonte de verdade compreensível, entrega a informação quando o processo precisa dela e torna visíveis as exceções antes de se transformarem em incidentes para o cliente.