Antes de aprovar uma ligação entre os seus sistemas de encomendas, armazém ou contabilidade, pergunte o que acontece quando a mesma atualização chega duas vezes. Pode ser necessário repetir a entrega, embora a fatura, o pedido de expedição ou a mensagem ao cliente já existam.
Uma resposta em falta deixa uma dúvida
Imagine que um sistema envia uma atualização e o sistema recetor conclui o trabalho. A resposta que confirma o sucesso perde-se no regresso. O emissor espera, atinge o limite de tempo e tenta novamente.
Esse limite de tempo explica por que houve outra entrega. Não indica se a primeira tentativa foi concluída. Desativar as tentativas pode deixar trabalho por concluir; repetir todas as ações comerciais pode criar trabalho a dobrar.
Malcolm Featonby descreve esta incerteza no artigo da Amazon Builders’ Library sobre como tornar as tentativas seguras. Stripe e Shopify também documentam entregas repetidas de webhooks. Um webhook é uma atualização automática enviada de um sistema para outro. Vale a pena falar deste comportamento antes de a ligação entrar em funcionamento.
Que ação deve acontecer uma só vez?
Imagine uma loja em que uma atualização de encomenda paga deve criar um pedido de preparação da expedição. Estas três situações exigem tratamentos diferentes:
A mesma atualização chega novamente
O pedido de preparação da expedição pode já existir. Outra entrega não deve criar um novo pedido para a mesma ação pretendida, dentro dos limites acordados.
Outra atualização diz respeito à encomenda
Uma alteração de morada ou um cancelamento podem exigir outro trabalho. Terem o mesmo número de encomenda não torna todas as atualizações redundantes.
O cliente faz uma segunda encomenda
A nova encomenda deve ser processada, mesmo que o cliente, os artigos e o total sejam iguais. Dados semelhantes não provam que se trata de uma repetição.
Pergunte ao fornecedor como se identifica a ação pretendida e como essa identidade se mantém noutra entrega. Não precisa de escolher o mecanismo técnico, mas precisa de perceber como reconhece uma repetição e permite trabalho realmente novo.
Os detalhes variam consoante o fornecedor. A documentação da Stripe aborda eventos repetidos e eventos diferentes sobre o mesmo objeto. A Shopify distingue uma entrega individual da ação comercial que lhe está subjacente. Um identificador útil para uma finalidade não é automaticamente a regra certa para todas as ações comerciais.
Encontra exemplos relevantes na documentação de webhooks da Stripe e guia da Shopify para verificar entregas. O fornecedor deve verificar o comportamento atual dos sistemas que vai ligar.
Descubra o que acontece quando só parte do trabalho é concluída
Suponha que o pedido de preparação da expedição é criado, mas a ligação para antes de registar a conclusão. Na tentativa seguinte, como encontra o pedido existente? E se chegarem duas cópias ao mesmo tempo? Uma lista de atualizações já recebidas não responde, por si só, a nenhuma destas perguntas.
Peça para ver três elementos em separado: prova de que a atualização chegou, o estado de processamento da ligação e prova da ação resultante no sistema recetor. Uma confirmação de entrega, por si só, não demonstra que o pedido de expedição ou a fatura existe.
Se o resultado continuar incerto, combine quem vai investigar e o que deve verificar antes de permitir uma nova tentativa. Defina limites claros para a equipa: que ações pode retomar, quais exigem a ajuda do fornecedor e quando deve parar para evitar outra ação comercial. Alguns problemas exigem comparar registos entre sistemas e uma pessoa decidir o que fazer a seguir.
“Tente novamente” só é útil quando sabe o que uma nova tentativa pode fazer e quem assume o caso se o resultado não for claro.
Peça uma demonstração segura
“Tente novamente” só é útil quando sabe o que uma nova tentativa pode fazer e quem assume o caso se o resultado não for claro.
Use um ambiente de testes suportado, com registos fictícios e ações comerciais externas desativadas. A demonstração deve incluir duas entregas da mesma atualização, uma segunda encomenda genuína e uma falha depois de uma etapa ter sido concluída. Verifique os registos resultantes e o histórico de entregas. Nunca repita um pagamento ou encomenda real apenas para descobrir o que acontece.
Peça um breve registo escrito do evento que inicia o processo, da ação pretendida, de como uma repetição é reconhecida e de onde a equipa pode consultar o resultado. Inclua durante quanto tempo a ligação mantém o histórico do trabalho anterior, o que acontece a uma entrega tardia e quem trata de uma ação incerta ou parcialmente concluída.
Se os sistemas não permitirem demonstrar em segurança uma falha específica, registe essa limitação e combine com o fornecedor uma análise mais restrita. Um teste bem-sucedido confirma o comportamento nessas condições. Não garante uma execução exatamente uma vez em todos os serviços ligados nem prova que toda a sequência será concluída como uma operação indivisível.
Perguntas antes de aprovar a ligação
Um limite de tempo significa que a primeira tentativa falhou?
Não. O trabalho pode ter sido concluído e a resposta ter-se perdido. Verifique o resultado do processamento e o sistema recetor antes de decidir o que uma nova tentativa deve fazer.
Duas encomendas aparentemente iguais podem ser válidas?
Sim. Um cliente pode fazer intencionalmente uma segunda encomenda com os mesmos artigos e o mesmo total. A ligação tem de distinguir uma nova intenção de uma entrega repetida; dados coincidentes não bastam para decidir.
Como podemos testar em segurança o comportamento perante repetições?
Peça um ambiente de testes suportado, com registos fictícios e ações comerciais externas desativadas. Inclua uma repetição, uma nova ação genuína e uma falha depois de parte do trabalho ter sido concluída. Registe as limitações dos testes em vez de experimentar com encomendas ou pagamentos reais.
Quem deve resolver uma ação parcialmente concluída?
Combine previamente uma pessoa ou equipa responsável. A equipa deve saber o que pode verificar ou retomar por si e quando o fornecedor tem de investigar antes de permitir outra ação.
