Webhooks y ERP: evitar pedidos duplicados
Separe el evento del pedido. Un ejemplo desarrollado muestra repeticiones, entregas simultáneas y una respuesta perdida del ERP.
Prevea las notificaciones repetidas como un caso normal de la integración de su tienda. Un webhook es un mensaje HTTP iniciado por el sistema emisor. Si falta la confirmación de recepción, puede llegar otra vez. Eso no debe crear otro pedido en el ERP.
Stripe documenta eventos repetidos y posibles eventos distintos sobre el mismo objeto. Compruebe las reglas del emisor real. El ejemplo siguiente es ficticio y no describe la API de Stripe.
Dos identificadores con funciones distintas
La tienda shop-1 tiene el pedido W-240. El evento evt-17 comunica su creación. El ERP le asigna E-901. El identificador del evento reconoce otra entrega; la tienda y el pedido identifican juntos la operación de negocio. Más tarde, evt-18 puede comunicar un cambio del mismo pedido.
Mensaje o fallo | Resultado esperado |
|---|---|
Primer evt-17 | Crear E-901 en el ERP y asociarlo a W-240. |
evt-17 repetido | Reconocer la operación existente; no crear otro pedido. |
Dos copias simultáneas de evt-17 | Una restricción de unicidad permite crear una sola tarea. |
evt-18 para W-240 | Asociar el cambio al pedido existente y revisar las reglas de modificación. |
El ERP crea el pedido, pero se pierde la respuesta | Resultado inicialmente incierto; conciliar con la misma identidad antes de crear de nuevo. |
Guardar la aceptación de forma duradera
Autentique primero el mensaje con el procedimiento del emisor. Después guarde el evento de forma duradera antes de confirmar la recepción. Una regla única sobre emisor e identificador evita tareas separadas para copias simultáneas. Buscar antes de insertar, sin esa garantía, no basta en caso de concurrencia.
El procesamiento posterior debe arrancar de forma fiable desde ese registro duradero. Un proceso en segundo plano puede recoger los eventos guardados y pendientes. Así, la operación sigue localizable tras un fallo entre recepción y procesamiento.
Una posible respuesta tras guardar:
{
"eventId": "evt-17",
"orderId": "W-240",
"status": "queued"
}El ejemplo utiliza el estado HTTP 202. Confirma la entrada en procesamiento; todavía no confirma un pedido del ERP. Si no puede asegurarse la persistencia, el receptor no debe anunciar una aceptación correcta.
Proteger también la llamada al ERP
Utilice una clave estable de creación como shop-1:W-240:create si el destino la admite. Manténgala en un reintento seguro. Stripe muestra este principio para su propia API; el significado exacto y la retención dependen del destino.
Sin ese soporte hace falta otra asociación fiable: por ejemplo un identificador externo único en el destino y una consulta del resultado. Si un tiempo de espera deja incierta la creación, mantenga la operación pendiente de conciliación. Un identificador aleatorio nuevo haría que el reintento pareciera una creación nueva.
Guardar el evento y crear el pedido en dos sistemas no forma automáticamente una sola transacción. Distinga entre aceptación, procesamiento, resultado incierto y cierre confirmado. En el ejemplo, la creación termina al confirmarse la asociación con E-901.
Validar incluyendo los fallos
Reenvíe evt-17 de forma consecutiva y simultánea. Interrumpa la respuesta después de una creación ERP correcta. Pruebe después evt-18 como cambio real. Debe haber una sola creación, una asociación conservada y un estado de conciliación visible si el resultado se desconoce. Defina también cuánto tiempo se conservan los identificadores para cubrir posibles repeticiones.
Fuentes
Seguir leyendo
Todos los artículos
APIs e integración con ASES
ERP, CRM y tienda bien conectados