Integrar SAP R/3 o ECC con un eCommerce es posible, pero requiere conocer las interfaces disponibles y sus limitaciones reales. SAP R/3 —y su evolución ECC 6.0— no dispone de una API REST moderna como S/4HANA. En su lugar, ofrece tres mecanismos de integración: RFC (Remote Function Call), BAPI (Business Application Programming Interface) e IDoc (Intermediate Document). Cada uno sirve para un propósito distinto, y elegir mal significa meses de retrabajo.
La realidad es que miles de empresas industriales en España siguen operando con SAP ECC, y necesitan conectar su ERP con tiendas online B2B sin esperar a migrar a S/4HANA. Con un middleware como Integrafy, estas interfaces legacy se abstraen en conectores estandarizados que traducen RFC y BAPI en llamadas REST que cualquier eCommerce entiende. El resultado: integración funcional sin tocar el core de SAP.
RFC, BAPI e IDoc: qué es cada cosa y cuándo usarla
Las RFC son llamadas remotas a funciones ABAP dentro de SAP. Permiten ejecutar lógica de negocio en SAP desde un sistema externo. Son síncronas (sRFC), asíncronas (aRFC) o transaccionales (tRFC). Para eCommerce, las RFC síncronas son útiles para consultar stock en tiempo real o verificar precios, pero tienen un coste computacional en SAP que limita su uso masivo.
Las BAPI son un subconjunto de RFC estandarizadas por SAP para operaciones de negocio: crear pedidos de venta (BAPI_SALESORDER_CREATEFROMDAT2), consultar materiales (BAPI_MATERIAL_GET_DETAIL), obtener datos de cliente (BAPI_CUSTOMER_GETDETAIL2). Son la opción recomendada porque siguen la lógica de negocio de SAP —validaciones de crédito, verificación de stock, determinación de precios— en lugar de escribir directamente en tablas.
Los IDoc son documentos intermedios que SAP usa para intercambio asíncrono de datos. Funcionan como mensajes XML estructurados que SAP envía o recibe. Son ideales para sincronización masiva: catálogo de productos (MATMAS), precios (COND_A), pedidos (ORDERS), clientes (DEBMAS). La ventaja de los IDoc es que desacoplan los sistemas: SAP genera el IDoc, lo deposita en una cola, y el middleware lo recoge cuando puede.
Lo que puedes y lo que no puedes hacer con SAP ECC
Sí es viable
Sincronizar catálogo de materiales mediante IDoc MATMAS o RFC de lectura. Sincronizar stock desde la tabla MARD usando RFC custom o extractores estándar. Crear pedidos de venta vía BAPI_SALESORDER_CREATEFROMDAT2. Consultar precios específicos por cliente usando condiciones de precio (tablas KONV/KONP). Enviar confirmaciones de envío y tracking. Sincronizar datos maestros de clientes B2B.
Tiene limitaciones serias
El stock en tiempo real requiere RFC síncronas que pueden sobrecargar SAP si el catálogo es grande y hay miles de consultas por minuto. Los precios en SAP son extraordinariamente complejos: escalas, rappels, condiciones por cliente/material/grupo, fechas de vigencia. Replicar toda esa lógica en la tienda es casi imposible. Lo que hacen la mayoría de implementaciones es consultar el precio final vía simulación de pedido (BAPI_SALESORDER_SIMULATE) y cachearlo.
Otro límite real: los IDoc requieren configuración en SAP (transacciones WE20, WE21, BD64) que necesita un consultor ABAP. No es algo que se haga desde el middleware sin acceso a SAP. Y cada IDoc custom necesita desarrollo ABAP específico.
SAP R/3 vs SAP ECC vs S/4HANA: diferencias para integración
SAP R/3 (versiones 3.x a 4.7) usa RFC y BAPI pero con interfaces más antiguas. Algunas BAPI estándar no existen o tienen comportamiento distinto. SAP ECC 6.0 (EhP 0 a 8) añade BAPI modernas y soporte mejorado de IDoc. S/4HANA cambia el paradigma: ofrece APIs REST/OData nativas, simplifica el modelo de datos (tabla MATDOC sustituye a MKPF/MSEG) y es mucho más fácil de integrar.
Si tu empresa está en R/3 o ECC y no va a migrar a S/4HANA en los próximos 2-3 años, la integración vía middleware es la opción pragmática. Integrafy mantiene conectores SAP que abstraen estas diferencias: el mismo flujo de sincronización funciona independientemente de si el SAP subyacente es ECC 6.0 EhP5 o S/4HANA 2023.
Arquitectura recomendada para SAP ECC + eCommerce
La arquitectura que mejor funciona en producción es: SAP ECC genera IDoc para datos maestros (productos, clientes, precios base) que el middleware procesa en batch. Para operaciones transaccionales (crear pedido, consultar stock disponible), el middleware llama a BAPI vía RFC en tiempo real. Los estados de pedido (confirmación, envío, factura) viajan como IDoc de SAP al middleware, que actualiza la tienda.
Esta arquitectura híbrida (IDoc para batch + RFC/BAPI para real-time) equilibra rendimiento y actualidad de datos. El middleware actúa como buffer: si SAP está en mantenimiento o sobrecargado, las operaciones se encolan y se reenvían cuando SAP está disponible. Sin este buffer, un pico de tráfico en la tienda puede tumbar el rendimiento de SAP para todos los usuarios internos.
Errores comunes en integraciones SAP ECC
El error más frecuente es intentar leer datos directamente de las tablas de SAP (VBAK, VBAP, MARA, MARD) sin pasar por BAPI. Funciona en desarrollo pero en producción viola la lógica de negocio: autorizaciones, validaciones, conversiones de unidades. SAP no garantiza la consistencia si escribes directamente en tablas.
Segundo error: no dimensionar la carga de RFC. Cada RFC abre una sesión en SAP. Si la tienda hace 500 consultas de stock por minuto, necesitas un pool de conexiones RFC gestionado. JCo (Java Connector) o NCo (.NET Connector) gestionan este pool, pero hay que configurarlo explícitamente.
Tercer error: asumir que el ERP está siempre disponible. SAP tiene ventanas de mantenimiento, procesos batch nocturnos que bloquean tablas, y cierres de periodo. El middleware debe gestionar estas situaciones con colas y reintentos, no con errores al usuario final.
La integración SAP ECC con eCommerce no es trivial, pero es un problema resuelto si se usa la arquitectura correcta. Un middleware como Integrafy, con conectores SAP probados en producción, reduce el proyecto de 6-8 meses a 6-8 semanas porque las interfaces ya están implementadas y testeadas.