Saltar al contenido principal

Fallback y reenvío

En esta página encontrarás una explicación sobre el fallback y el reenvío.

Contexto y necesidad​

En operaciones críticas como el procesamiento de pedidos (POST /order), Koncili puede enfrentar fallas internas transitorias que pueden resultar en:

Importante

Estas situaciones exigen que el integrador implemente una estrategia de reenvío para garantizar la consistencia de los datos, incluso cuando la falla se originó del lado de Koncili.

Explicación esencial​

1. Naturaleza de las fallas​

  • Ocurren raramente, en condiciones específicas de carga del sistema
  • No son causadas por errores en el payload del integrador
  • Pueden ocurrir incluso con respuestas HTTP exitosas (200/201)
  • Afectan por igual a los endpoints de pedidos y de conciliaciones

2. Comportamiento del sistema​

3. Responsabilidad del integrador​

Aunque la falla sea del sistema Koncili, le corresponde al integrador:

  • Mantener temporalmente los datos enviados
  • Implementar una verificación posterior del estado
  • Ejecutar el reenvío cuando sea necesario
Para ambos endpoints

Esta necesidad se aplica por igual a:

  • POST /order (creación de pedidos)

¿Por qué es necesario el reenvío?​

  1. Fallas posteriores a la respuesta
  • El sistema puede aceptar la solicitud (código 200/201), pero fallar internamente antes de persistir los datos
  1. Garantía de consistencia
  • Solo el integrador tiene el contexto completo para reenviar los datos originales
Acción recomendada

Implementa un mecanismo que:

  1. Almacene temporalmente los payloads enviados
  2. Verifique después de 5-10 minutos si los datos se persistieron
  3. Los reenvíe si no están disponibles
Consecuencias de no implementarlo
  • Pedidos no creados: Ventas no conciliadas, ingresos no reconocidos
  • Conciliaciones incompletas: Movimientos financieros faltantes, saldos incorrectos
  • Datos inconsistentes: Informes imprecisos, decisiones comprometidas