Gestionar un fallo de integración con estados veraces

Durante un fallo de integración, muestre lo que el software sabe realmente. Un portal puede amortiguar una interrupción, pero no debe presentar un procesamiento ERP aún abierto como un pedido terminado. Son determinantes los estados trazables y una reanudación controlada.

Determinar el último estado acreditado

En un portal ficticio, un cliente envía una solicitud para crear un pedido. El ERP está temporalmente inaccesible. El portal debe poder deducir si la solicitud ya fue aceptada a partir de su propio estado de procesamiento registrado de forma fiable. Una indicación en pantalla no guarda por sí sola una solicitud.

Estos estados son nuestro modelo de ejemplo. Las etiquetas deben ajustarse a las pruebas reales de la aplicación. Una recepción HTTP rápida y correcta no demuestra por sí sola que haya terminado la creación del pedido.

Relacionar las repeticiones con la misma operación

Si un cliente vuelve a enviar porque la pantalla sigue sin resolver el estado, la aplicación debe poder reconocer si se pretende el mismo pedido. Defina el identificador, su ámbito y el tratamiento de solicitudes ya procesadas. Stripe describe la entrega repetida de eventos como un caso concreto de webhook; eso no establece una regla universal de reintento para su ERP.

Compruebe en especial el caso en que se creó el pedido ERP, pero se perdió su respuesta. Un reintento no debe provocar una segunda creación sin comprobación.

Definir responsabilidades y comunicación

Determine quién evalúa el fallo, quién autoriza la reanudación del procesamiento y quién actualiza el estado visible. Google SRE Workbook distingue la resolución de un incidente de su coordinación y comunicación. Un equipo pequeño puede combinar funciones, pero sigue necesitando responsabilidades claras.

Reanudar de forma controlada tras la recuperación

La disponibilidad del ERP es el punto de partida de la comprobación. Aclare las solicitudes abiertas y las ya procesadas antes de ejecutar de nuevo el trabajo pendiente. Muestre el estado confirmado solo cuando exista la prueba correspondiente.

Pruebe un fallo antes del guardado, otro después y una respuesta ERP perdida. Compruebe el estado visible en el portal y el número real de pedidos creados. Así verá si la respuesta sigue siendo veraz cuando el cliente experimenta directamente el fallo.

Fuentes

• Google SRE Workbook: Incident Response

• Stripe: Webhooks