Conectar SAP Business One: Service Layer, OData y middleware RFC comparados

SAP Business One es, en muchas empresas medianas, la columna vertebral de la contabilidad financiera, el almacén y las ventas. En cuanto este sistema ERP debe conectarse con otras herramientas como un CRM, una tienda online o un panel de reporting, surge una pregunta arquitectónica fundamental: a través del Service Layer basado en REST con OData o mediante un middleware RFC clásico. Esta decisión tiene un impacto directo en el esfuerzo del proyecto, la mantenibilidad y, en última instancia, en el coste de la automatización, por lo que debe tomarse de forma clara al inicio de cada proyecto de integración de SAP B1.

En este artículo comparamos ambos enfoques, mostramos cómo n8n se sitúa en medio como capa de automatización y a qué debes prestar atención en cuanto a autenticación, gestión de errores y escalado. Actualizado: julio de 2026.

Service Layer vs. middleware RFC: el conflicto fundamental

SAP Business One ofrece dos formas fundamentalmente distintas de acceder a los datos desde el exterior:

• Service Layer: Una API web RESTful moderna que acepta solicitudes HTTP y devuelve los datos en formato JSON. Sigue el protocolo OData y está diseñada específicamente para la integración con herramientas modernas de nube y automatización.
• RFC (Remote Function Call): El protocolo más antiguo y propio de SAP a través del cual se comunican los sistemas SAP clásicos. Para acceder desde una herramienta de automatización como n8n necesitas aquí obligatoriamente una capa de middleware, por ejemplo un servicio Node.js con una librería RFC o una plataforma de integración como SAP Cloud Integration que traduce las llamadas RFC a una interfaz HTTP.

La diferencia decisiva para tu proyecto: el Service Layer ya habla el idioma que n8n entiende de forma nativa, es decir, HTTP y JSON. Con RFC necesitas además un componente de middleware independiente que debe desarrollarse, alojarse y mantenerse por separado. Esto aumenta el esfuerzo inicial y el número de piezas móviles del sistema, pero puede valer la pena si ya cuentas con un panorama de integración SAP existente con módulos RFC o necesitas funciones que el Service Layer no cubre.

El enfoque del Service Layer con n8n

Para la mayoría de los proyectos de automatización, el Service Layer es el punto de partida más pragmático. El HTTP Request Node es, según la documentación de n8n, "one of the most versatile nodes in n8n" y permite enviar "HTTP requests to query data from any app or service with a REST API". Eso es exactamente lo que se necesita para el Service Layer, ya que no existe un node dedicado de SAP B1 en n8n y tú mismo modelas la conexión mediante llamadas HTTP.

Flujo de una conexión típica

• Login: Un node HTTP Request envía un POST al endpoint de login del Service Layer (normalmente `https://<server>:<port>/b1s/v1/Login`) con CompanyDB, UserName y Password en el body.
• Cookie de sesión: La respuesta contiene una cookie `B1SESSION` que almacenas en n8n, por ejemplo mediante un node Set o un almacenamiento de datos estáticos, y que envías en el header en todas las solicitudes siguientes.
• Consultas OData: Los nodes HTTP Request posteriores acceden a entidades como `Orders`, `BusinessPartners` o `Items`. Los parámetros de consulta OData como `$select`, `$filter`, `$orderby` y `$top` reducen la cantidad de datos exactamente a lo que necesita el workflow, en lugar de cargar conjuntos de datos completos y filtrarlos recién en n8n.
• Tiempo de expiración de sesión: Las sesiones del Service Layer caducan tras un cierto período de inactividad. Un workflow robusto comprueba el código de estado de la respuesta y renueva automáticamente la sesión si es necesario, en lugar de simplemente cancelarse ante un error 401.

Modelar la autenticación de forma limpia

Como no existe una credential predefinida de n8n para el Service Layer, trabajas con las opciones de autenticación genéricas del node HTTP Request. Según la documentación sobre credentials de HTTP Request están disponibles entre otras "Basic auth, Custom auth, Digest auth, Header auth, OAuth1 API, OAuth2 API, Query auth". Para el flujo clásico de login por cookie del Service Layer, normalmente basta con una combinación de una solicitud de login inicial y una credential de Header auth posterior, en la que introduces dinámicamente la cookie de sesión. Importante para entornos productivos: si el Service Layer funciona con un certificado autofirmado o interno, según la documentación puedes enviar "an SSL certificate with your HTTP request" almacenando el CA bundle, el certificado y la clave privada como una credential propia, en lugar de desactivar las comprobaciones SSL de forma general.

El enfoque de middleware RFC

En panoramas SAP más grandes, o cuando se necesitan funciones que el Service Layer no cubre, por ejemplo determinados procesos heredados o módulos de función profundamente arraigados en la lógica de negocio, no hay forma de evitar RFC. Como n8n no habla RFC de forma nativa, necesitas una capa de middleware intermedia:

• Un servicio propio de Node.js o Python con una librería RFC traduce las solicitudes HTTP entrantes en llamadas RFC al sistema SAP y devuelve la respuesta en formato JSON.
• n8n se comunica entonces con este servicio de forma completamente normal a través del node HTTP Request, igual que con cualquier otra API REST.
• Alternativamente, una plataforma de integración existente (por ejemplo, SAP Cloud Integration) se encarga de esta traducción, y n8n se convierte en la capa de orquestación que controla los triggers, la gestión de errores y la conexión con sistemas de terceros.

Este enfoque implica más esfuerzo de desarrollo al principio, porque el middleware en sí debe construirse, probarse y operarse. A cambio, obtienes acceso a módulos de función que simplemente no existen en el Service Layer, y puedes seguir utilizando los conceptos de autorización SAP existentes a nivel de RFC. Para proyectos con un alto valor de integración, este suele ser el punto en el que una decisión de arquitectura limpia se amortiza económicamente, porque una conexión mal elegida debe adaptarse más adelante a un coste elevado.

Vigilar la gestión de errores y la operación

Una conexión SAP que solo funciona en el caso ideal no es suficiente para el uso productivo. Incorpora puntos de control fijos en cada workflow:

• Renovación de sesión: Detecta las sesiones caducadas por el código de estado y renueva automáticamente el login, en lugar de dejar que el workflow falle.
• Lógica de reintento: Los problemas de red o la indisponibilidad breve del Service Layer deben gestionarse mediante un reintento limitado con tiempo de espera, no con un único intento.
• Registro de errores: Una ruta de error independiente en el workflow, que registra las solicitudes fallidas y notifica si es necesario, evita que los errores de datos pasen desapercibidos a los sistemas posteriores.

Si el volumen de datos crece, por ejemplo con varias integraciones paralelas o sincronizaciones de alta frecuencia, vale la pena echar un vistazo a la operación productiva de n8n en sí. Para las instalaciones autoalojadas, la documentación describe el modo de cola, en el que una instancia principal recibe los triggers y varios procesos worker se encargan de las ejecuciones propiamente dichas. Esto separa la carga de procesamiento de la recepción de triggers, crítica en cuanto al tiempo, y hace que la automatización sea más estable cuando se ejecutan muchos workflows de SAP al mismo tiempo.

Qué enfoque encaja con tu proyecto

Para la mayoría de las conexiones de empresas medianas, ya sea reflejar datos de pedidos en el CRM, informar del stock a una tienda online o preparar datos de facturación para una herramienta de reporting, el Service Layer es el camino más directo y con menos mantenimiento. Funciona sin middleware adicional, habla HTTP estándar y puede modelarse completamente a través del node HTTP Request en n8n. La variante de middleware RFC queda reservada a proyectos en los que el Service Layer no es funcionalmente suficiente o en los que ya existe una capa de integración RFC que se desea seguir utilizando.

En ambos casos mantienes el control sobre tus datos y sobre el proceso: n8n se ejecuta ya sea en tu propia infraestructura o en un entorno elegido por ti, y cada paso de la conexión SAP permanece visible y ajustable como workflow, en lugar de desaparecer en una caja negra opaca. Si no estás seguro de qué enfoque es el adecuado para tu panorama de SAP Business One, vale la pena realizar un análisis conjunto antes de que comience el desarrollo.

Preguntas frecuentes

¿Necesito un node especial de SAP B1 en n8n para el enfoque del Service Layer?

No. n8n no ofrece un node dedicado de SAP Business One, pero tampoco es necesario. El Service Layer es una API REST normal con soporte de OData, que modelas por completo mediante el node HTTP Request, incluyendo el login, la gestión de sesión y las propias consultas de datos.

¿Cuándo vale la pena el middleware RFC a pesar del mayor esfuerzo?

El middleware RFC vale la pena si dependes de módulos de función que el Service Layer no cubre, o si ya existe un panorama de integración RFC que se desea seguir utilizando. Para proyectos de integración nuevos y ligeros, el Service Layer suele ser el punto de partida más eficiente.

¿Cómo gestiono las sesiones del Service Layer que caducan?

El Service Layer restablece las sesiones tras un cierto período de inactividad. Un workflow de n8n robusto comprueba el código de estado de cada respuesta, detecta automáticamente un login caducado y desencadena una nueva solicitud de login antes de repetir la recuperación de datos propiamente dicha, en lugar de dejar que falle todo el workflow.

¿Puedo almacenar certificados SSL para servidores SAP internos en n8n?

Sí. Según la documentación de n8n, un certificado SSL, compuesto por un CA bundle, un certificado y una clave privada, puede configurarse como una credential propia y vincularse al node HTTP Request. Esta es la solución más limpia frente a desactivar de forma general la comprobación SSL, especialmente con certificados SAP firmados internamente.

¿Qué ocurre con un alto volumen de datos y muchas sincronizaciones SAP paralelas?

Cuando el volumen crece, se recomienda el modo de cola para las instalaciones de n8n autoalojadas. En este modo, una instancia principal recibe los triggers mientras que varios procesos worker se encargan de las ejecuciones de workflow propiamente dichas. Esto mantiene la automatización estable y con buen rendimiento incluso con varias integraciones de SAP ejecutándose simultáneamente.