Quando a API do ERP dá timeout e o pedido pode ter sido gravado, não reenvie na hora. Primeiro consulte se o pedido existe; só então decida se envia de novo.
Timeout quer dizer que o portal desistiu de esperar. Não quer dizer que o ERP não gravou. O ERP pode ter recebido, gravado e demorado demais para responder.
Se o portal reenvia no escuro, o resultado pode ser pedido duplicado, estoque reservado duas vezes e um cliente com duas cobranças.
Por que o timeout engana
Entre o clique do usuário e a gravação no ERP existem rede, servidor, validações e regras de negócio. A resposta pode se perder em qualquer ponto desse caminho.
Por isso o portal tem três estados possíveis: gravou, não gravou ou não sei. O erro mais comum é tratar o "não sei" como "não gravou".
Consulte o estado antes de reenviar
Todo pedido deve sair do portal com um identificador próprio, gerado antes do envio. Ele viaja junto com o pedido e fica registrado no ERP.
Em caso de timeout, o portal marca o pedido como em confirmação e consulta o ERP por esse identificador.
- Encontrou. O pedido foi gravado. Atualize o portal com o número do ERP e não reenvie.
- Não encontrou. Reenvie com o mesmo identificador, para que uma segunda tentativa nunca crie outro pedido.
- Consulta também falhou. Mantenha em confirmação e tente de novo depois de um intervalo. Não crie um pedido novo.
O que combinar com a TI
Esse tratamento só funciona se o ERP aceitar o identificador do portal e permitir consultar por ele. Confirme isso antes de qualquer projeto.
- Identificador. Onde ele fica guardado no pedido do ERP e se a duplicidade é barrada.
- Consulta. Qual chamada REST devolve o pedido a partir desse identificador.
- Limite de espera. Quanto o portal aguarda antes de marcar o pedido como em confirmação.
- Intervalo e limite de novas consultas. Quantas vezes o portal consulta e quando passa para análise manual.
- Erro técnico ou de negócio. Quem trata cada um. Veja como separar em erro técnico ou erro de negócio na integração com o ERP.
Nos portais da FBS Portais, o que acontece no portal reflete no ERP e as regras e validações do ERP são respeitadas em cada operação. Por isso o desenho do reenvio é combinado com a equipe do cliente na etapa de integração.
O que mostrar ao usuário
Não mostre "erro, tente novamente". O usuário vai clicar de novo, e o risco de duplicar volta. Mostre "pedido recebido, confirmando no ERP" e bloqueie um novo envio igual enquanto o estado não for resolvido.
Posso reenviar o pedido se a consulta ao ERP também deu timeout?
Não crie um pedido novo. Mantenha o pedido em confirmação e consulte de novo depois de um intervalo. Se o ERP continuar sem responder, encaminhe para a TI verificar manualmente.
Reenviar com o mesmo identificador resolve sempre?
Só se o ERP reconhecer o identificador e recusar ou devolver o pedido já existente. Teste isso com a TI antes de colocar em produção.
Como próximo passo, simule um timeout em ambiente de teste e veja o que acontece com o pedido. Se o ERP gravar duas vezes, ajuste o identificador e a consulta antes de ir para produção.