Pedidos duplicados na integração: causas e solução

Pedido que chega em dobro no ERP é um problema caro: gera faturamento errado, estoque reservado à toa e horas de conferência manual. E costuma virar discussão entre fornecedores, cada um apontando para o outro lado.

Na maioria das vezes, a causa não é um bug isolado. É o desenho da integração, que não previa a mesma operação chegando duas vezes.

O caso que ensina o problema

Em um dos casos que atendemos, pedidos do ERP chegavam em dobro no Fluig, ou não chegavam. A varredura de milhões de linhas de log mostrou de que lado estava a falha e revelou dois padrões:

• Reenvio por timeout. O sistema de origem não recebia resposta a tempo e enviava de novo.
• Reprocessamento em lote. Uma rotina reenviava pedidos que já tinham sido processados.

A solução foi uma trava contra duplicidade e um log persistente, no lugar do reprocessamento manual.

Por que o timeout gera duplicidade

Este é o ponto central: timeout não significa que a operação falhou. Significa que você não sabe o que aconteceu.

O cenário costuma ser assim:

1. O sistema A envia o pedido ao sistema B.
2. O sistema B grava o pedido com sucesso.
3. A resposta demora ou se perde na rede.
4. O sistema A atinge o timeout e assume que deu errado.
5. O sistema A reenvia, e o sistema B grava de novo.

Nenhum dos dois errou de acordo com a própria lógica. A falha está na combinação. Por isso o problema costuma aparecer em momentos de maior carga, quando as respostas ficam mais lentas, e some quando alguém tenta reproduzi-lo com calma.

No Fluig, isso se conecta a um recurso útil. A atividade de serviço faz novas tentativas quando o script falha. Ótimo para instabilidades, mas perigoso se o outro lado não reconhecer a repetição.

Outras causas frequentes

• Duplo clique ou duplo envio do usuário, sem proteção na tela.
• Rotinas agendadas que selecionam registros por data, sem marcar o que já foi enviado.
• Reprocessamento manual depois de um incidente, sem saber o que de fato entrou.
• Evento que dispara mais de uma vez, quando a integração está em um ponto do fluxo pelo qual a solicitação pode passar de novo.

Como provar a causa

Antes de corrigir, descubra o que aconteceu. Isso também encerra o jogo de empurra entre fornecedores.

1. Separe uma amostra de duplicados. Liste os pedidos repetidos com identificador e horário de cada registro.

2. Compare os intervalos. Essa é uma das pistas mais úteis. Duplicatas separadas por um tempo próximo ao timeout configurado sugerem reenvio. Duplicatas concentradas em um horário fixo sugerem rotina em lote.

3. Compare os dados. Registros idênticos indicam repetição técnica. Diferenças de valor ou item podem indicar que um reprocessamento alterou algo.

4. Cruze os dois lados. Para cada duplicata, procure a requisição na origem e o recebimento no destino. Quantas vezes foi enviada? Quantas vezes foi recebida?

Se os logs não permitem essa análise, esse já é o primeiro achado: sem um identificador comum, nenhuma investigação vai ser rápida.

A solução: idempotência

Idempotência é uma propriedade simples: fazer a mesma operação uma ou dez vezes produz o mesmo resultado. Em uma integração, isso significa que reenviar um pedido não cria um segundo pedido.

Ela é construída assim:

Crie um identificador único por operação. A origem define esse identificador antes da primeira tentativa e o reutiliza em todas as repetições. Em um processo Fluig, o número da solicitação é um candidato natural.

Grave o identificador no destino, com índice único. Esta é a parte que muitas integrações pulam. Fazer uma consulta "já existe?" antes de gravar não basta: duas requisições simultâneas podem passar pela consulta ao mesmo tempo. O índice único no banco é o que garante a trava, inclusive sob concorrência.

Responda de forma coerente à repetição. Se o pedido já existe, a resposta não deve ser um erro genérico. Deve dizer "já processado" e devolver o número do pedido. Assim, a origem segue o fluxo normalmente.

Trate o estado "em andamento". A primeira tentativa pode ainda estar rodando quando a segunda chega. O registro precisa diferenciar ausente, em andamento e concluído.

Evite usar o conteúdo como chave. Comparar cliente, item e valor parece prático, mas dois pedidos legítimos e iguais seriam tratados como duplicados.

Como isso fica em Fluig e Protheus

Um desenho comum:

1. A atividade de serviço envia o número da solicitação junto com os dados.
2. A API do Protheus verifica o identificador em um campo de referência externa com índice único.
3. Se for novo, grava o pedido e registra o vínculo. Se já existir, devolve o número do pedido criado antes.
4. O Fluig guarda esse número no formulário, e a solicitação segue.

O código da chamada está em como chamar a API REST do Protheus pelo Fluig.

O log persistente

A outra metade da solução é poder responder, meses depois, o que aconteceu com um pedido. Um bom log de integração registra:

• Identificador da operação e número de tentativas.
• Horário de envio e de resposta.
• Status e resposta recebida.
• Se a operação foi nova ou reconhecida como repetição.

Com isso, o reprocessamento deixa de ser manual e arriscado. Reenviar passa a ser seguro, porque a trava impede a duplicidade. Esse registro também sustenta uma boa trilha de auditoria.

E os pedidos que já duplicaram?

Antes de criar a trava, faça a limpeza com critério:

• Levante os duplicados e classifique o estágio de cada um: só pedido, faturado, com estoque reservado.
• Envolva fiscal e financeiro no que já gerou documento. Excluir registros direto no banco não é o caminho.
• Crie a trava primeiro no fluxo novo, para o problema parar de crescer.

Perguntas frequentes

Aumentar o timeout resolve?

Reduz a frequência, mas não resolve. Qualquer lentidão maior que o novo limite recria o problema. A trava precisa estar no destino.

Dá para resolver só no Fluig?

Parcialmente. Controles no processo ajudam, mas a proteção definitiva fica em quem grava o registro, porque é lá que a duplicidade se concretiza.

O que é uma integração idempotente?

É aquela em que repetir a mesma requisição não muda o resultado. O pedido é criado uma vez, e as repetições apenas confirmam que ele já existe.

Se os seus pedidos somem, duplicam ou travam entre Fluig e ERP, a MyQube faz esse diagnóstico com evidência, para corrigir a causa e o problema não voltar. Fale com a gente.