Por Nicho Agencia Digital · Publicado el
Clasifica el fallo antes de repetir
Conviene separar tres situaciones: un problema temporal de comunicación, un dato que el destino rechaza y un resultado incierto. En el último caso, el destino pudo completar la operación aunque la respuesta no llegara.
El patrón de reintentos de Microsoft está orientado a fallos transitorios y advierte sobre los efectos de repetir operaciones que no son idempotentes. Por eso, la regla de reintento debe considerar el tipo de acción y la documentación del proveedor, además del código de error.
Un producto inexistente necesita corregir su equivalencia. Una credencial vencida requiere intervención autorizada. Una demora de red puede admitir otro intento, pero antes debe existir una forma segura de reconocer la misma operación.
Antes de habilitar repeticiones automáticas, revisa cómo usar idempotencia para evitar pedidos duplicados.
Diseña estados que el equipo pueda entender
Como propuesta operativa, usa estados separados para pendiente, en procesamiento, esperando reintento, requiere revisión y completado. Añade cancelado cuando exista una decisión explícita de no continuar. El estado debería responder qué sigue, sin obligar al equipo a interpretar un registro técnico.
- Identidad: operación, sistema de origen y registro relacionado.
- Contexto: momento del primer fallo, último intento y paso afectado.
- Tratamiento: causa clasificada, próximo intento o acción requerida.
- Responsabilidad: persona o equipo asignado y prioridad de negocio.
- Evidencia: referencia del destino y detalle técnico protegido cuando sea necesario.
No muestres claves de acceso ni vuelques información personal en alertas generales. La vista operativa puede enlazar a un detalle restringido en lugar de copiar todos los datos del pedido.
Separa la cola técnica de la revisión del negocio
Una cola de mensajes fallidos conserva operaciones que no pudieron procesarse. Azure Service Bus describe su dead-letter queue como un lugar para retener mensajes no entregables o no procesables, que luego pueden inspeccionarse. En ese servicio no hay limpieza automática de la cola.
Una lista técnica por sí sola no resuelve quién habla con bodega, quién corrige un código o quién verifica una orden. Para la revisión de negocio, define vistas, responsables y acciones permitidas. Una persona debería poder distinguir “falta una equivalencia” de “el proveedor está temporalmente caído”.
Controla cantidad de pendientes, antigüedad del más viejo y procesos afectados. La prioridad puede depender de un despacho próximo o de que un cliente esté esperando, aunque el total de errores sea pequeño.
Ejemplo hipotético: un pedido detenido por una variante
Una tienda envía un pedido y el sistema de bodega rechaza una variante que no reconoce. El flujo deja el pedido en revisión, conserva el evento original y muestra la equivalencia faltante. Reenviarlo sin cambiar nada produciría el mismo rechazo.
La persona autorizada verifica el catálogo y corrige la relación. Antes de reprocesar, el sistema consulta si el pedido ya existe en el destino y confirma que no está cancelado. Luego ejecuta el paso pendiente con la identidad original de la operación y registra el resultado.
Si la bodega ya lo había creado y solo faltaba la respuesta, la recuperación consiste en vincular la referencia existente. Crear otro pedido sería un error. Este ejemplo ilustra por qué el resultado incierto necesita una ruta distinta al dato inválido.
Prueba recuperación, alertas y permisos
Ensaya desconexión temporal, rechazo de datos, expiración de acceso y respuesta perdida. Comprueba que el número de intentos y las esperas respeten los límites definidos, que no se acumulen reintentos en varias capas y que una persona pueda detener un reprocesamiento riesgoso.
Después de recuperar un caso, verifica el efecto final en el destino y deja la evidencia vinculada. Marcar un mensaje como procesado sin comprobar el pedido puede cerrar la alerta demasiado pronto.
La decisión de automatizar más depende de contar con identificación confiable, observabilidad y una salida para las excepciones. Una cola facilita el diagnóstico, pero necesita atención asignada; tampoco vuelve segura cualquier repetición ni sustituye las condiciones del proveedor.
El siguiente paso
Podemos revisar un fallo recurrente de tu integración y definir qué se reintenta, qué se verifica y qué necesita una persona responsable.
Automatización de procesos comerciales · Conversar sobre tu proyecto ↗
Fuentes y alcance
Fuentes consultadas el 11 de octubre de 2026. Las recomendaciones de proceso son propuestas editoriales de Nicho; los ejemplos identificados como hipotéticos no representan resultados de clientes.
Contenido preparado con asistencia de IA y comprobaciones automáticas. No sustituye una evaluación de tu implementación ni garantiza resultados. Escríbenos si encuentras algo que debamos corregir.