Fallback e reenvio
Nesta página, você encontrará uma explicação sobre fallback e reenvio.
Contexto e necessidade
Em operações críticas como processamento de pedidos (POST /order), o Koncili pode enfrentar falhas internas transitórias que podem resultar em:
Importante
Estas situações exigem que o integrador implemente uma estratégia de reenvio para garantir a consistência dos dados, mesmo quando a falha originou-se no lado do Koncili.
Explicação essencial
1. Natureza das falhas
- Ocorrem raramente em condições específicas de carga do sistema
- Não são causadas por erros no payload do integrador
- Podem acontecer mesmo com respostas HTTP bem-sucedidas (200/201)
- Afetam igualmente endpoints de pedidos e conciliações
2. Comportamento do sistema
3. Responsabilidade do integrador
Embora a falha seja do sistema Koncili, cabe ao integrador:
- Manter temporariamente os dados enviados
- Implementar verificação posterior do estado
- Executar reenvio quando necessário
Para Ambos os Endpoints
Esta necessidade aplica-se igualmente a:
POST /order(criação de pedidos)
Por que o reenvio é necessário?
- Falhas pós-respostas
- O sistema pode aceitar a requisição (código 200/201) mas falhar internamente antes de persistir os dados
- Garantia de consistência
- Somente o integrador tem o contexto completo para reenviar os dados originais
Ação Recomendada
Implemente um mecanismo que:
- Armazene temporariamente os payloads enviados
- Verifique após 5-10 minutos se os dados foram persistidos
- Reenvie caso não estejam disponíveis
Consequências da não implementação
- Pedidos não criados: Vendas não conciliadas, receita não reconhecida
- Conciliações incompletas: Lançamentos financeiros faltantes, saldos incorretos
- Dados inconsistentes: Relatórios imprecisos, decisões comprometidas