Si quitas las presentaciones de los proveedores, toda integración de ERP a comercio es una de dos arquitecturas. En la primera, la tienda lee del ERP en el momento de la solicitud: un comprador con sesión iniciada abre una página de producto y la plataforma le pregunta al ERP, justo entonces, cuánto paga este cliente y qué hay en existencia. Sana Commerce está construida así. En la segunda, un conector copia el catálogo, los precios y el inventario del ERP hacia la propia base de datos de la plataforma de comercio, de forma programada o mediante webhooks. La tienda sirve luego esa copia. BigCommerce, Adobe Commerce y la mayoría de las plataformas funcionan de este modo, con middleware entre los dos sistemas.
Construimos ambos. Hemos entregado tiendas Sana que leen precios en vivo desde Business Central y S/4HANA, y hemos construido tiendas BigCommerce sincronizadas por middleware donde un conector mantiene el catálogo al ritmo del ERP. Ninguna es "la respuesta correcta" en abstracto. Fallan de manera distinta, cuestan de manera distinta, y cada una es claramente correcta para algunas empresas y silenciosamente errónea para otras. Esta es la comparación honesta.
Los dos modelos, con precisión
La forma más limpia de definirlos es por dónde vive físicamente, en el instante en que se renderiza la página, la respuesta a "cuánto paga este cliente por este artículo ahora mismo".
En el modelo de lectura en vivo (tiempo real), la respuesta vive en el ERP, y la tienda no la tiene hasta que pregunta. Cada precio autenticado, cada cifra de existencias, cada verificación de crédito es un viaje de ida y vuelta al sistema de registro. Existe exactamente una copia de la verdad, y la tienda nunca es su dueña. Este es el patrón ERP primero del que hemos escrito en otro lugar en el contexto de Sana Commerce.
En el modelo de middleware (sincronización), la respuesta vive en la base de datos de comercio, escrita allí antes por un conector que la leyó del ERP. La tienda posee una copia. Esa copia está tan fresca como la última sincronización que la tocó. El ERP está aguas arriba y, en el momento de la solicitud, fuera del circuito. Así es como se construyen la mayoría de las integraciones de ERP con BigCommerce.
Todo lo demás se desprende de esa única diferencia. Tenla presente, porque casi cada compensación de abajo no es más que una consecuencia de dónde se asientan los datos.
Exactitud: una sola fuente de verdad frente a una copia gestionada
La lectura en vivo es correcta por construcción. Si el precio cambió en el ERP hace un segundo, el siguiente render de la página ve el nuevo precio, porque el render de la página es la consulta. No hay ventana alguna durante la cual la tienda esté equivocada con confianza. Para B2B, donde el precio es con frecuencia específico de cada cliente (tarifas de contrato, escalones por volumen, ajustes negociados) y donde equivocarse en un precio de contrato es una disputa de facturación, este es un beneficio real e infravalorado.
El modelo de middleware es correcto entre sincronizaciones y se desvía en medio. El tamaño de la ventana de desviación es una decisión de diseño: un conector impulsado por webhooks puede empujar un cambio de precio en segundos, mientras que una tarea de catálogo nocturna te deja hasta un día desactualizado. La mayoría de los sistemas reales son una mezcla, y el planteamiento honesto no es "¿es exacto?", sino "¿cuál es tu peor caso de desactualización y puede el negocio tolerarlo para estos campos en particular?". Las existencias que pasan de 4 a 0 entre sincronizaciones son el caso doloroso clásico, porque el cliente que pidió la unidad fantasma se entera en el momento de la entrega.
Rendimiento: el ERP está en la ruta de la solicitud, o no lo está
Aquí es donde el modelo de middleware gana con claridad. Servir un precio desde tu propia base de datos, o desde una caché delante de ella, es rápido y predecible. Puedes poner una CDN delante de las páginas de navegación anónima y no molestar al ERP en absoluto. La latencia de la página queda desacoplada de cómo se sienta el ERP hoy.
La lectura en vivo pone el tiempo de respuesta del ERP en la ruta crítica de la página. Una plataforma como Sana lo mitiga con fuerza mediante caché y agrupación de conexiones, y para catálogos B2B típicos (compradores autenticados de cientos a unos pocos miles, no millones de sesiones anónimas) no es un problema. Pero el techo de la velocidad de tu página lo fija el ERP, y si el ERP es una máquina local muy cargada, lo notas. La mitigación es disciplina arquitectónica: mantén las páginas de navegación anónima cacheables y reserva el viaje en vivo para los momentos que realmente lo necesitan, como un precio autenticado o una verificación de existencias al agregar al carrito.
Resiliencia: qué pasa cuando el ERP está caído
Esta es la pregunta que la mayoría de las evaluaciones se salta, y es la que muerde más fuerte en el segundo año.
En el modelo de lectura en vivo, el ERP es una dependencia dura para las partes del sitio que leen de él. Si el ERP se cae por mantenimiento o se desploma, el precio autenticado y las existencias en vivo se degradan con él. Las buenas implementaciones suavizan esto con respaldos en caché y mensajes elegantes, pero no puedes fingir que la tienda es plenamente independiente, porque arquitectónicamente no lo es. El tiempo de actividad de tu tienda, para sus funciones más acopladas al ERP, está acotado por el tiempo de actividad de tu ERP.
En el modelo de middleware, la tienda sigue sirviendo su copia mientras el ERP está caído. La navegación, los precios y las existencias en caché siguen funcionando. La trampa está en el otro sentido: los pedidos hechos durante la caída tienen que ir a algún lado. Un conector bien construido los pone en cola y los publica cuando el ERP regresa, lo que significa que tu ruta de publicación de pedidos tiene que ser duradera e idempotente (más sobre esto abajo). Uno mal construido los pierde o los publica por duplicado. El desacoplamiento te compra resiliencia del lado de lectura y te entrega a cambio un problema de encolamiento del lado de escritura.
Precios específicos de cliente: el punto crucial del B2B
Este único requisito decide más arquitecturas que cualquier otro. En B2B, el precio suele ser función de quién pregunta: precios de contrato, escalones por volumen, reglas específicas de destino de envío, ajustes promocionales que el equipo de ventas mantiene en el ERP.
La lectura en vivo maneja esto de forma nativa, porque el contexto del cliente es parte de la consulta. Le preguntas al ERP por "este cliente, este artículo, hoy" y obtienes la respuesta que daría el ERP, sin un motor de precios que reconstruir. El middleware tiene que replicar la lógica de precios, o al menos las listas de precios resueltas, dentro de la plataforma de comercio. Para unas cuantas listas de precios planas eso es trivial. Para una matriz profunda de reglas de contrato específicas de cliente, replicarla con exactitud (y revalidarla cada vez que cambian las reglas del ERP) se convierte en un proyecto en sí mismo, y es exactamente la clase de segundo motor de precios que se desvía. Este es el argumento individual más fuerte a favor de la lectura en vivo en un B2B con muchos contratos, y el lugar donde los equipos subestiman con más frecuencia el desarrollo del middleware.
Costo y complejidad
Ningún modelo es gratis, y gastan tu presupuesto en lugares distintos. La lectura en vivo concentra el costo en el conector del ERP y en el rendimiento del ERP: necesitas que el ERP responda rápido y de forma fiable bajo carga web, lo que a veces implica ajustes en el ERP o capacidad que no habías planeado. El middleware concentra el costo en la canalización de datos del conector: las tareas de sincronización, el mapeo de campos, la lógica de conflictos e invalidación, y el monitoreo que te avisa cuando la sincronización se ha desviado. El middleware además agrega una superficie operativa que la lectura en vivo simplemente no tiene, a saber, un sistema de sincronización que él mismo puede romperse, rezagarse o detenerse en silencio, y que por tanto necesita sus propias alertas. El error recurrente es presupuestar la construcción del conector y olvidar el impuesto operativo permanente del conector.
Hacer que el middleware se sienta en tiempo real
La mayoría de las plataformas son plataformas de middleware, así que la pregunta práctica no suele ser "cómo evito el middleware" sino "cómo hago que una tienda sincronizada se comporte como una en vivo donde importa". Tres técnicas hacen la mayor parte del trabajo.
Cachea con invalidación explícita, no solo con expiración. La expiración basada en tiempo garantiza desactualización hasta el TTL. El mejor patrón es dejar que los cambios del ERP invaliden activamente las entradas de caché relevantes mediante webhooks, de modo que un cambio de precio o de existencias empuje una invalidación en lugar de esperar a un temporizador. La expiración se vuelve entonces una red de seguridad, no el mecanismo principal. La parte difícil es el alcance de la invalidación: un solo cambio de precio de contrato puede tocar muchas entradas calculadas, y acertar con el radio de impacto es la ingeniería de verdad.
Llamadas en vivo al visualizar SKU sensibles. No necesitas todo en vivo. Identifica los campos y artículos donde equivocarse sale caro (artículos con precio de contrato, SKU de bajo inventario o fabricados sobre pedido, cualquier cosa con control de crédito) y haz una llamada en vivo dirigida al ERP solo para esos, solo en las páginas donde aparecen. El resto del catálogo sigue en caché y rápido. Esto toma de forma selectiva la exactitud del modelo de lectura en vivo justo donde se paga sola, que suele ser la mezcla correcta.
Publicación de pedidos idempotente y duradera. Con cualquier modelo con el que leas, la ruta de escritura de vuelta al ERP debe ser segura de reintentar. Dale a cada pedido una clave de idempotencia estable, encola las publicaciones de forma duradera y haz que el manejador del lado del ERP rechace los duplicados en lugar de crear una segunda orden de venta. Esto es lo que te permite sobrevivir a caídas del ERP y reinicios del conector sin publicar pedidos por duplicado, y importa en ambos modelos, pero es innegociable para el middleware porque la cola está haciendo trabajo real durante cada tropiezo del ERP.
Un marco de decisión
Esta es la versión corta que de verdad usamos, en prosa y no en tabla. Inclínate por la lectura en vivo cuando el ERP guarda precios profundos específicos de cliente o de contrato que no quieres reconstruir, cuando el disponible-para-prometer en tiempo real y el estado de crédito realmente condicionan las ventas, cuando tu audiencia es en su mayoría compradores autenticados y no navegantes anónimos, y cuando tu ERP puede responder rápido bajo carga. Inclínate por la sincronización con middleware cuando la mayor parte del tráfico es navegación anónima de catálogo que debería ir a velocidad de CDN, cuando los precios son lo bastante simples para replicarse como un puñado de listas de precios, cuando necesitas que la tienda siga vendiendo mientras el ERP está fuera de línea, o cuando el ERP no puede aceptar tráfico web en vivo. Y echa mano del híbrido (sincroniza el grueso, llama en vivo a los pocos sensibles) cuando tienes un catálogo anónimo rápido pero una cola de artículos con precio de contrato o de bajo inventario que deben ser exactos. Lo que hay que evitar es elegir un modelo y luego operarlo como si fuera el otro: cachear una plataforma de lectura en vivo hasta que en secreto sea una copia desactualizada, o atornillar tantas llamadas en vivo a una plataforma de middleware que hayas reconstruido la dependencia del ERP sin la garantía de fuente única.
Qué significa esto para los compradores
La plataforma que elijas ya ha tomado esta decisión por ti, en su mayor parte. Sana es lectura en vivo. BigCommerce y Adobe son middleware. Así que la decisión real está aguas arriba: ¿tu negocio funciona sobre el ERP al punto de que una copia es un pasivo, o el ERP es lo bastante ligero como para que desacoplar sea pura ganancia? Responde eso con honestidad y la lista corta de plataformas casi se escribe sola. Si estás sopesando exactamente esto, nuestra comparación entre Sana Commerce y BigCommerce recorre la misma bifurcación desde el lado de la plataforma.
Si estás dimensionando esto en un proyecto real y quieres una respuesta directa sobre qué modelo encaja, ese es el trabajo que hacemos. Inicia una conversación aquí.