Antes de aprobar una conexión entre tus sistemas de pedidos, almacén o contabilidad, pregunta qué ocurre si llega dos veces la misma actualización. Puede que haya que repetir la entrega, aunque la factura, la solicitud de envío o el mensaje al cliente ya existan.
Si falta la respuesta, queda una duda
Imagina que un sistema envía una actualización y el sistema receptor termina el trabajo. La respuesta que confirma que todo ha ido bien se pierde por el camino. El remitente espera, agota el tiempo límite y vuelve a intentarlo.
Ese tiempo de espera explica por qué se hizo otra entrega. No indica si el primer intento llegó a completarse. Desactivar los reintentos puede dejar trabajo pendiente; repetir cada acción comercial puede generar trabajo duplicado.
Malcolm Featonby explica esta incertidumbre en el artículo de Amazon Builders’ Library sobre cómo hacer seguros los reintentos. Stripe y Shopify también documentan las entregas repetidas de webhooks. Un webhook es una actualización automática que un sistema envía a otro. Conviene hablar de este comportamiento antes de poner en marcha la conexión.
¿Qué acción debe realizarse una sola vez?
Imagina una tienda en la que una actualización de pedido pagado debe crear una solicitud de preparación del envío. Estas tres situaciones requieren tratamientos distintos:
Llega de nuevo la misma actualización
Puede que la solicitud de preparación del envío ya exista. Otra entrega no debería crear una solicitud adicional para la misma acción prevista, dentro de los límites acordados.
Otra actualización se refiere a ese pedido
Un cambio de dirección o una cancelación pueden requerir un trabajo distinto. Que compartan el número de pedido no significa que todas las actualizaciones sean repetidas.
El cliente hace un segundo pedido
El nuevo pedido debe tramitarse, aunque coincidan el cliente, los artículos y el importe. Unos datos parecidos no demuestran que sea una repetición.
Pregunta al proveedor cómo se identifica la acción prevista y cómo se conserva esa identidad cuando vuelve a entregarse. No necesitas elegir el mecanismo técnico, pero sí entender cómo reconoce una repetición y permite que se realice un trabajo nuevo.
Los detalles varían según el proveedor. La documentación de Stripe trata los eventos repetidos y los eventos distintos sobre un mismo objeto. Shopify distingue cada entrega de la acción comercial que la origina. Un identificador útil para un fin no es automáticamente la regla adecuada para todas las acciones comerciales.
Encontrarás ejemplos relevantes en la documentación de webhooks de Stripe y la guía de Shopify para verificar entregas. El proveedor debe comprobar cómo funcionan ahora los sistemas que vas a conectar.
Averigua qué ocurre si solo se completa parte del trabajo
Supón que se crea la solicitud de preparación del envío, pero la conexión se interrumpe antes de registrar que terminó. En el siguiente intento, ¿cómo encuentra la solicitud existente? ¿Qué pasa si llegan dos copias a la vez? Una lista de actualizaciones ya recibidas no responde por sí sola a ninguna de estas preguntas.
Pide que te muestren por separado tres cosas: una prueba de que llegó la actualización, el estado de procesamiento de la conexión y una prueba de la acción resultante en el sistema receptor. El acuse de recibo de la entrega, por sí solo, no demuestra que exista la solicitud del paquete o la factura.
Si el resultado sigue sin estar claro, acordad quién lo investigará y qué comprobará antes de permitir otro intento. Deja claros los límites para el personal: qué acciones puede reanudar, cuáles requieren la ayuda del proveedor y cuándo debe detenerse para evitar otra acción comercial. Algunos problemas exigirán comparar registros entre sistemas y que una persona decida cómo proceder.
“Vuelve a intentarlo” solo sirve si sabes qué puede hacer el siguiente intento y quién se hará cargo cuando el resultado no esté claro.
Pide una demostración segura
“Vuelve a intentarlo” solo sirve si sabes qué puede hacer el siguiente intento y quién se hará cargo cuando el resultado no esté claro.
Usa un entorno de pruebas compatible, con datos ficticios y las acciones comerciales externas desactivadas. La demostración debe cubrir dos entregas de la misma actualización, un segundo pedido real y un fallo después de completar un paso. Comprueba los registros resultantes y el registro de entregas. No repitas nunca un pago o pedido real solo para averiguar qué ocurre.
Pide un breve informe por escrito que indique el desencadenante, la acción prevista, cómo se reconoce una repetición y dónde puede ver el personal el resultado. Incluye durante cuánto tiempo recuerda la conexión el trabajo anterior, qué ocurre con una entrega tardía y quién se ocupa de una acción incierta o parcialmente completada.
Si los sistemas no permiten demostrar de forma segura un fallo concreto, deja constancia de esa limitación y acuerda con el proveedor una revisión más acotada. Una prueba satisfactoria respalda el comportamiento en esas condiciones. No garantiza que todos los servicios conectados ejecuten la acción exactamente una vez ni demuestra que toda la secuencia se complete como una operación indivisible.
Preguntas antes de aprobar la conexión
¿Un tiempo de espera significa que falló el primer intento?
No. Puede que el trabajo haya terminado y que la respuesta se haya perdido. Comprueba el resultado del procesamiento y el sistema receptor antes de decidir qué debe hacer otro intento.
¿Pueden ser válidos dos pedidos que parecen idénticos?
Sí. Un cliente puede hacer intencionadamente otro pedido con los mismos artículos y el mismo importe. La conexión debe distinguir una intención nueva de una entrega repetida; los datos coincidentes no bastan para decidirlo.
¿Cómo podemos probar de forma segura el comportamiento ante repeticiones?
Pide un entorno de pruebas compatible, con datos ficticios y las acciones comerciales externas desactivadas. Incluye una repetición, una acción nueva real y un fallo después de que parte del trabajo se haya completado. Deja constancia de las limitaciones de las pruebas en lugar de experimentar con pedidos o pagos reales.
¿Quién debe resolver una acción completada solo en parte?
Acordad de antemano una persona o un equipo responsable. El personal debe saber qué puede comprobar o reanudar por su cuenta y cuándo debe intervenir el proveedor antes de permitir otra acción.
