La mayoría de integraciones entre WooCommerce y SAP Business One terminan convirtiéndose en una mezcla difícil de mantener:
- middleware externo
- APIs duplicadas
- sincronizaciones lentas
- lógica repartida entre varios sistemas
- errores constantes de stock y precios
Después de trabajar en varios proyectos B2B conectando WooCommerce con SAP, acabamos llegando a una conclusión bastante simple:
cuanto más cerca esté WooCommerce del Service Layer de SAP, más estable termina siendo todo.
En este artículo explico la arquitectura que estamos usando para sincronizar:
- productos
- stock
- precios
- clientes B2B
- pedidos
sin añadir capas innecesarias.
El problema no es “conectar SAP”
Hoy conectar dos sistemas es relativamente sencillo.
El problema real aparece meses después:
- productos desactualizados
- pedidos duplicados
- precios incorrectos
- integraciones que se rompen en actualizaciones
- lógica B2B imposible de mantener
Esto ocurre especialmente cuando WooCommerce empieza a asumir responsabilidades que deberían seguir viviendo dentro de SAP.
Arquitectura recomendada
La estructura más estable que hemos encontrado es esta:
WooCommerce
↓
Plugin de integración
↓
SAP Business One Service Layer
↓
SAP B1
Sin middleware pesado.
Sin ETLs complejos.
Sin sincronizaciones masivas cada pocos minutos.
Por qué usar Service Layer
SAP Business One ya expone prácticamente toda la información necesaria:
artículos
stock
almacenes
listas de precios
clientes
pedidos
descuentos
tarifas especiales
Además:
funciona sobre REST
usa JSON
evita acceso directo a base de datos
permite mantener SAP como fuente de verdad
Eso simplifica muchísimo el mantenimiento a largo plazo.
Qué sincronizar y qué no
Uno de los errores más habituales es intentar sincronizar absolutamente todo.
Normalmente trabajamos así:
Desde SAP hacia WooCommerce
- productos
- categorías
- stock
- precios
- tarifas B2B
- clientes empresariales
Desde WooCommerce hacia SAP
- pedidos
- clientes nuevos
- observaciones comerciales
Ejemplo básico consultando artículos desde SAP
Petición típica al Service Layer:
GET /b1s/v1/Items
Ejemplo sencillo en WordPress:
$response = wp_remote_get(
$sap_url . '/b1s/v1/Items',
[
'headers' => [
'Cookie' => 'B1SESSION=' . $session,
'Content-Type' => 'application/json'
]
]
);
$data = json_decode(
wp_remote_retrieve_body($response),
true
);
A partir de ahí:
se mapean SKUs
se sincroniza stock
se actualizan precios
se crean o actualizan productos WooCommerce
El punto crítico: precios B2B
Aquí es donde suelen romperse la mayoría de proyectos.
Muchos negocios trabajan con:
- precios por cliente
- descuentos escalados
- tarifas por volumen
- precios por kilos
- listas específicas SAP
WooCommerce no está pensado para manejar toda esa lógica empresarial por sí solo.
La aproximación más estable suele ser:
consultar el precio directamente desde SAP en función del cliente autenticado.
Ejemplo simplificado:
Cliente → CardCode SAP
Producto → ItemCode
Cantidad → tramo
Resultado → precio dinámico
Así:
- SAP mantiene la lógica comercial
- WooCommerce solo representa el resultado
- no se duplican reglas
Evitar sincronizaciones innecesarias
Otro error frecuente:
ejecutar sincronizaciones constantes cada minuto.
No suele hacer falta.
Nuestra recomendación:
- Tiempo real
- pedidos
- stock crítico
- Batch programado
- catálogo
- imágenes
- contenido
Esto reduce muchísimo:
- carga sobre SAP
- bloqueos
- timeouts
- problemas de rendimiento
WooCommerce no debería convertirse en el ERP
Muchos proyectos acaban intentando gestionar desde WordPress:
- inventario
- lógica de precios
- reglas comerciales
- clientes empresariales
Eso suele acabar mal.
SAP debería seguir siendo:
- la fuente de verdad
- el sistema central
- quien controla la lógica empresarial
WooCommerce debería centrarse en:
- experiencia de compra
- catálogo
- conversión
- frontend comercial
- Seguridad básica
Nunca conviene:
- exponer credenciales SAP
- llamar al Service Layer desde frontend
- dejar endpoints públicos sin control
Todas las llamadas deberían pasar por backend y autenticación segura.
Rendimiento
Algunas optimizaciones que nos han funcionado especialmente bien:
- cachear respuestas no críticas
- limitar llamadas concurrentes
- evitar recalcular precios masivos en frontend
- usar colas para pedidos
- no sincronizar imágenes continuamente
- Nuestra implementación
Después de varios proyectos terminamos desarrollando nuestro propio conector para WordPress y SAP Business One:
https://replanta.net/conector-sap-woocommerce/
El objetivo era mantener una arquitectura simple, estable y cercana al funcionamiento real de SAP.
Actualmente lo utilizamos en proyectos B2B donde necesitamos:
- sincronización estable
- precios dinámicos
- stock multi-almacén
- clientes empresariales
- pedidos automáticos
- integración directa con Service Layer
Conclusión
Muchas integraciones WooCommerce + SAP terminan siendo difíciles de mantener porque intentan replicar dentro de WordPress toda la lógica empresarial que ya existe en SAP.
Cuanto más simple sea la arquitectura:
- más estable será el proyecto
- menos mantenimiento tendrá
- menos problemas aparecerán tras actualizaciones
En la mayoría de casos, SAP debería seguir siendo quien gobierna la lógica del negocio.
WooCommerce simplemente debería vender bien.
Top comments (0)