Cómo diseñar una automatización de pedidos con estados y reintentos
Los pedidos necesitan estados explícitos, idempotencia y excepciones tratables para evitar duplicados y operaciones inciertas.
Una automatización de pedidos debe poder explicar qué ocurrió con cada orden. Para ello necesita estados persistentes, identificadores compartidos y reglas de reintento. Un proceso que solo devuelve éxito o error deja demasiadas operaciones en una situación incierta.
Modelar el recorrido antes de programarlo
Un flujo puede incluir recibido, validado, pendiente de proveedor, creado, confirmado, rechazado y revisión manual. Los nombres dependen del negocio, pero cada transición debe tener una causa y registrar quién o qué la ejecutó.
Evitar pedidos duplicados
La idempotencia permite repetir una petición sin crear otra orden. Se utiliza una clave estable del origen y se registra el resultado de la primera ejecución. Antes de reintentar una operación con efecto, hay que comprobar si el proveedor la aceptó aunque la respuesta se haya perdido.
Distinguir errores temporales y definitivos
Un timeout o un límite de llamadas puede admitir reintento con espera. Un SKU inexistente, credencial inválida o precio que necesita aprobación requiere otra acción. Repetir todos los errores indefinidamente aumenta carga y oculta casos que necesitan intervención.
Tratar precio, stock y respuestas parciales
El flujo debe definir tolerancias y responsables cuando precio o disponibilidad difieren. En pedidos con varias líneas hay que decidir si se acepta una parte, se espera o se rechaza el conjunto. Estas reglas son comerciales y deben acordarse antes de quedar embebidas en código.
Trazabilidad y notificaciones
Cada intento debería conservar fecha, entrada relevante, respuesta y referencia externa sin exponer secretos. Las alertas deben indicar qué pedido está detenido y qué puede hacer una persona. Notificar cada reintento genera ruido; conviene avisar cuando cambia la acción necesaria.
Probar también los fallos
Además del pedido correcto, prueba timeout, respuesta incompleta, duplicado, stock insuficiente y caída durante la confirmación. Una automatización está lista para operar cuando puede recuperarse o detenerse de forma comprensible en esos escenarios.