Uma falha que faz barulho
Um endpoint morto é retentado por pouco mais de 24 horas, e se a última tentativa ainda falhar os administradores do workspace recebem um e-mail — uma vez por endpoint por dia, não uma vez por pedido.
Sincronização de pedidos
Valide o payload, atualize o cliente, chame o sistema que faz a entrega e retente por um dia se ele ficar mudo — com uma execução e uma trilha por trás de cada pedido.
O problema
Uma sincronização entre dois sistemas é fácil de construir e difícil de confiar. As falhas são silenciosas: um campo que mudou de formato, um token que venceu numa sexta, um endpoint que respondeu 200 e não fez nada. Nenhuma delas aciona ninguém, e todas aparecem uma semana depois como um pedido que foi pago e nunca enviado.
A saída de sempre é um painel dizendo quantas execuções deram certo. Isso responde à pergunta errada. O que você precisa é de um pedido — este aqui, de março — e do que foi de fato enviado, do que voltou e de quantas tentativas foram necessárias.
Como o fluxo se parece
Numerado porque a ordem é a ordem de execução, não porque é uma lista. Com quantos passos tiver, tudo isso é uma execução só.
Sua loja, seu checkout ou seu meio de pagamento envia o pedido no momento em que ele é pago.
Campos obrigatórios, um endereço entregável, um total que fecha. Um payload que falha para aqui com um motivo, em vez de se gravar pela metade em dois sistemas.
Guarde o cliente e o pedido como registros com esquema próprio, para o próximo pedido da mesma pessoa não começar do zero.
Um provedor pronto, ou uma Conexão Personalizada para qualquer API HTTPS ou JSON para a qual você tenha credenciais — seu depósito, seu ERP, seu operador logístico, o seu próprio serviço interno.
Quando o registro precisa cair no seu data warehouse em vez de em um fornecedor, o fluxo grava direto durante a execução.
Um pedido rejeitado desce pela ramificação dele: avise o canal responsável e guarde o payload, para ele ser reexecutado em vez de redigitado.
Publique as falhas onde alguém de operações vai ver hoje, com o código de resposta e a referência do pedido.
Devolva a referência da entrega para o sistema que chamou guardar o mesmo identificador que o fluxo recebeu.
O que o fluxo alcança
Um nó Conexão chama um dos 52 provedores prontos, ou qualquer API HTTPS ou JSON para a qual você tenha credenciais. Seis bancos conectam direto. Toda chamada acontece dentro da execução, com as suas credenciais, e cai na mesma trilha do resto dela.
O que muda
Um endpoint morto é retentado por pouco mais de 24 horas, e se a última tentativa ainda falhar os administradores do workspace recebem um e-mail — uma vez por endpoint por dia, não uma vez por pedido.
Abra a execução daquele pedido e leia o que foi enviado, o que voltou e quantas tentativas foram necessárias. Não um agregado; o pedido em si.
A versão nova roda contra payloads que você guardou, e o tráfego real continua na versão publicada até você publicar. Uma alteração pela metade não vaza para produção.
Perguntas
Dá. Uma Conexão Personalizada fala com qualquer API HTTPS ou JSON para a qual você tenha credenciais — você informa o endpoint, a autenticação e o modelo do corpo da requisição. Os 52 provedores prontos existem por conveniência; a Conexão Personalizada é o que cobre todo o resto.
A entrega é retentada seis vezes com intervalos crescentes: imediatamente, depois 5 segundos, 30 segundos, 5 minutos, 1 hora e 23 horas — pouco mais de um dia no total. As retentativas são de graça, então um pedido que precisou de seis tentativas continua sendo uma execução.
O tráfego real só roda versão publicada. Edite o rascunho, rode no Sandbox contra payloads que você guardou e publique — ou mova antes uma porcentagem dos pedidos para a versão nova e compare as execuções antes de ela levar tudo.
Quando você quiser
Monte o fluxo no Sandbox, rode seus próprios casos por ele e leia a trilha antes de qualquer coisa chegar a um cliente.