RESUMEN RÁPIDO
Qué sacar del artículo
- Todo evento importante necesita una identidad y un resultado rastreable.
- El reintento no debe repetir el efecto comercial.
- Los errores deben tener dueño, plazo de resolución y posibilidad de recuperación segura.
Determinar qué sistema es la fuente de la verdad.
La tienda electrónica acepta el pedido, el almacén reserva la mercancía y el sistema contable gestiona el documento. Si cada sistema puede cambiarlo todo sin reglas, surgen conflictos. Para cada campo, determine el propietario: quién decide el precio, el estado del pago, la disponibilidad y el estado del envío. Otros sistemas reciben un cambio verificado o envían una solicitud para ejecutarlo.
Para varias empresas, la identificación también debe incluir la empresa. El mismo número de pedido puede existir en dos agendas separadas. Por lo tanto, el vínculo entre registros no debe basarse únicamente en el número que se muestra al cliente. Necesita identificadores internos y mapeo entre sistemas. El marco empresarial describe el artículo sobre almacén y tienda electrónica conectada a ERP.
Un webhook es una notificación, no una garantía de finalización
El webhook notifica a la otra aplicación de un evento, como un pago exitoso. El destinatario debe verificar el remitente y los datos. La documentación de Stripe advierte sobre la verificación de firmas, la posibilidad de eventos duplicados y que es posible que no se garantice la orden de entrega. Estas características deben tenerse en cuenta en el diseño de cada integración específica según su documentación.
Recomendamos primero poner en cola de forma segura el evento antes de confirmar su recepción. El procesamiento comercial en sí puede continuar por separado. De este modo, el sistema distingue entre eventos recibidos, procesados y de error. No basta con devolver una respuesta exitosa y esperar que se lleve a cabo el siguiente paso. Si la confirmación se realiza antes de que persista, la interrupción puede hacer perder el evento.
Idempotencia: misma instrucción, mismo efecto
Idempotencia significa que repetir de forma segura la misma instrucción no creará un segundo pedido, reserva o factura. En la práctica, el destinatario recuerda el identificador único del evento y el resultado del procesamiento. Al mismo tiempo, también debe proteger la operación comercial, ya que dos eventos técnicos diferentes pueden describir el mismo cambio.
Imagine una interrupción después de crear un pedido en ERP, pero antes de que la confirmación se envíe a la tienda electrónica. La tienda online intentará realizar la solicitud nuevamente. El resultado correcto es encontrar el enlace existente y devolver el mismo pedido, no crear otro. El control deberá resistir también dos intentos simultáneos; El simple "buscar primero y luego crear" sin protección de concurrencia puede no ser suficiente.
Los eventos retrasados no deben retrasar el orden.
El mensaje "pedido recibido" puede llegar sólo después del mensaje "pagado". Si todos sobrescriben el estado sin verificarlo, la información anterior borrará el resultado más reciente. Utilice las transiciones de estado permitidas y la versión u hora disponible del evento. En caso de conflicto, cargue el estado actual desde el sistema fuente.
La cancelación y el reembolso son eventos separados. No borre el historial de ventas exitosas; tenga en cuenta el cambio posterior. El mismo principio se aplica a los envíos parciales y a los pedidos divididos. Un estado universal de "hecho" a menudo no es suficiente para el almacenamiento, el transporte y los documentos.
| Área | Postup | Que comprobar |
|---|---|---|
| Webhook repetido | El resultado existente, sin una segunda operación. | Número de reservas y documentos. |
| Abandono después del registro | Repetir encontrará un pedido ya creado. | Vinculación de identificadores entre sistemas. |
| orden incorrecta | Un estado anterior no sobrescribirá uno más nuevo confirmado. | Transiciones permitidas e historia. |
| Datos incorrectos | La grabación se detiene por un motivo específico. | Persona responsable y procedimiento de reparación seguro. |
Repetición automática y lista de trabajo de excepciones.
Una interrupción temporal se puede resolver repitiendo a medida que aumenta la distancia. Sin embargo, la repetición por sí sola no corregirá una tarifa faltante, un producto desconocido o la empresa equivocada. Divida los errores técnicos en temporales y sustanciales. Después del límite establecido, el evento debe pasar a la lista para resolución, no ejecutarse indefinidamente.
El gerente necesita ver la cantidad de pedidos atascados, su antigüedad, valor y motivo. El trabajador necesita un siguiente paso específico y acceso a los documentos relevantes. Después de la reparación, sólo se debe restaurar la parte necesaria del proceso. Analizamos el diseño del informe matutino en el artículo panel de control multiempresa.
Comprueba también lo que no ha llegado.
El monitoreo de eventos detectará un mensaje de error, pero es posible que no detecte un evento completamente perdido. Por lo tanto, agregue una conciliación periódica: pedidos web versus ERP, pagos confirmados versus pedidos pagados y envío versus movimientos de stock. Las excepciones deben ser explicables y atribuibles a una persona o a un proceso de reparación.
Ejecute el piloto en una sola secuencia con alcance limitado. Mida el tiempo de procesamiento, la tasa de intervención manual, el número de duplicados y el número de diferencias pendientes. Extienda la automatización solo cuando la interrupción pueda recuperarse de manera segura. Una conexión fiable supone un ahorro precisamente porque la empresa no tiene que comprobar manualmente cada día si se ha perdido algo.
