Un ejercicio de n8n y SAP: extraer datos de pedidos de venta y notificar
Ejercicio editorial de n8n y SAP: extraer y transformar pedidos de venta de un sandbox, y disparar una notificación, con renovación de sesión y manejo de errores.
Comprobado con las fuentes citadas el .
Ejercicio editorial: resumen de la tarea y objetivo de aprendizaje
Este es un ejercicio editorial para arquitectos SAP y desarrolladores de integración que quieren probar cómo un flujo de n8n con SAP podría extraer datos de pedidos de venta antes de construir uno para producción. La tarea: conectar n8n con un sandbox de SAP Business One Service Layer o con un sandbox de SAP S/4HANA Sales Order OData, iniciar sesión, recuperar un lote de registros de pedidos de venta, remodelarlos en una estructura limpia y disparar un paso de notificación de seguimiento, usando únicamente el nodo HTTP Request de n8n y APIs documentadas de SAP, con renovación de sesión y manejo de errores incorporados en el flujo.
Diseñamos este ejercicio a partir de capacidades documentadas de SAP y n8n; no lo hemos construido, ejecutado ni validado nosotros mismos, así que trátalo como un plano para probar en tu propio sandbox, no como una receta comprobada. El objetivo de aprendizaje es más específico que simplemente conectar n8n con SAP: se trata de decidir qué espera de quien la llama una API empresarial basada en sesiones, y dónde termina el trabajo de n8n y empieza el de SAP como sistema de registro.
Requisitos previos: acceso al sandbox, credenciales y herramientas
Para SAP Business One, la propia formación de SAP sobre Service Layer muestra una solicitud de inicio de sesión con autenticación básica que envía el nombre de la base de datos de la empresa, el nombre de usuario y la contraseña al endpoint de Login, usando una base de datos de demostración como ejemplo. Un intento en sandbox necesita esos mismos tres valores para la base de datos de empresa a la que puedas acceder, además de acceso de red a esa instancia de Service Layer desde donde se ejecute n8n. En el lado de n8n, las opciones de credenciales genéricas del nodo HTTP Request incluyen Basic auth, Custom auth y Digest auth, cualquiera de las cuales puede transportar la llamada de inicio de sesión o la sesión resultante.
Para SAP S/4HANA, el Business Accelerator Hub de SAP ofrece un sandbox de API generado por IA para probar APIs REST y OData, incluidos los endpoints de Sales Order, sin un backend real; tiene un límite de 20 llamadas por usuario al mes y devuelve respuestas simuladas. Para datos reales y un comportamiento de sesión real, la función Configured Environment del Hub permite a un desarrollador probar las APIs contra su propio sistema productivo o de pruebas con licencia, con soporte para OAuth 2.0 además de autenticación básica y por clave de API. La tabla siguiente resume lo que ofrece cada camino antes de empezar a construir.
| Opción | Autenticación | Datos | Ideal para |
|---|---|---|---|
| SAP Business One Service Layer (BD demo) | CompanyDB, usuario y contraseña mediante el endpoint Login | Datos reales de una empresa de demostración | Probar el inicio de sesión real, el tiempo de espera de sesión y el comportamiento 401 |
| Sandbox de API de S/4HANA generado por IA | No se necesita nada más allá del acceso al Hub | Respuestas simuladas generadas por IA | Solo dar forma a la estructura de solicitud y respuesta |
| Configured Environment de S/4HANA | Básica, clave de API u OAuth 2.0 | Datos de tu propio tenant de pruebas con licencia | Probar contra los datos de tu propio tenant con licencia |
En nuestra opinión, empezar con la base de datos de demostración de Business One es la elección pragmática para este ejercicio: su comportamiento de inicio de sesión, tiempo de espera y mensajes de error es el más documentado de las tres opciones, mientras que el sandbox simulado de S/4HANA solo es útil para dar forma a las solicitudes, no para ver expirar una sesión real.
Sources: Logging In and Out Using Basic Authentication with Service Layer, Managing Service Layer Settings | SAP Help Portal, 3383703 - SAP Business One Service Layer returns "Invalid session or session already timeout" error | SAP Knowledge Base Article, HTTP Request | Nodes | n8n Docs, Trying Out APIs in a AI-generated API Sandbox | SAP Help Portal, Trying Out APIs in a Configured Environment | SAP Help Portal
Entradas y restricciones: solo APIs documentadas
Ninguno de los dos sandboxes da acceso directo a la base de datos, así que el flujo de trabajo debe pasar por endpoints documentados y respetar la versión de protocolo que SAP admita actualmente en cada caso. La lista siguiente detalla lo que eso significa para este ejercicio de n8n y SAP, abarcando Service Layer, la interfaz A2X de Sales Order de S/4HANA, la paginación y los límites de los sandboxes públicos.
- Usa la entidad Orders de Service Layer o la interfaz A2X de Sales Order de S/4HANA, nunca una consulta directa a la base de datos.
- SAP dejó obsoleta la versión 3 de OData en Service Layer a partir del feature package 2405 de SAP Business One, convirtiendo a la versión 4 de OData en el protocolo principal allí.
- El servicio Orders también define acciones dedicadas, como una acción de cancelación, para operaciones que las simples llamadas de crear-leer-actualizar-eliminar no pueden expresar.
- La documentación de la API de S/4HANA versión 2608 de SAP incluye la interfaz de Sales Order tanto en variante OData V4 como OData V2.
- La propia guía de Service Layer de SAP dedica una sección a paginar los resultados de consultas de pedidos, aparte de un GET de una sola página.
- El nodo HTTP Request de n8n puede recorrer las páginas sucesivas por sí mismo usando su modo de paginación 'Update a Parameter in Each Request'.
- Trata el sandbox público simulado de S/4HANA solo como una herramienta para dar forma a las solicitudes; una descripción de 2017 de un sandbox público más antiguo como de solo lectura, actualizada por última vez en 2024, puede no reflejar las opciones actuales basadas en el Hub.
Sources: Service Layer API Reference, Working with SAP Business One Service Layer, Sales Order (A2X, OData V4) | SAP Help Portal, Sales Order (A2X, OData V2) | SAP Help Portal, HTTP Request | Nodes | n8n Docs, S/4HANA Cloud Sandbox is now available in SAP API ... - SAP Community
Construir el flujo de n8n con SAP: autenticación, extracción, transformación y notificación
La autenticación es lo primero en este flujo de n8n con SAP. Para Service Layer, el nodo HTTP Request envía la base de datos de la empresa, el nombre de usuario y la contraseña al endpoint de Login, siguiendo el patrón de autenticación básica que muestra la propia formación de SAP, y la respuesta incluye una sesión que reutilizan las llamadas posteriores. Para el Configured Environment de S/4HANA, OAuth 2.0 es una de las opciones de autenticación disponibles junto con Basic y clave de API, de modo que el tipo de credencial OAuth2 del nodo puede encargarse del intercambio de tokens.
Extraer los registros es un segundo nodo HTTP Request, un GET contra la entidad Orders o la interfaz A2X de Sales Order, usando opciones de consulta OData para seleccionar campos, ordenar resultados y limitar el tamaño de página. Una publicación de 2025 en SAP Community de un consultor de SAP Business One construye un GET similar contra Service Layer como una etapa de un flujo de generación de informes más amplio; su ruta de ejemplo usa la ruta v1 obsoleta, así que apunta en su lugar a la ruta v4. Para más de una página, el modo de paginación 'Update a Parameter in Each Request' del nodo puede recorrer las solicitudes sucesivas.
Transformar los registros es trabajo habitual de n8n a partir de aquí: un nodo Edit Fields o Code remodela el payload OData en bruto hacia los campos que necesita el resto del flujo, cambiando los nombres de campo internos de SAP por otros que una plantilla de notificación pueda leer directamente.
El paso de seguimiento, un correo electrónico, un mensaje de chat o una escritura en una hoja de seguimiento, lee de esos datos transformados en lugar de leer directamente de SAP, de modo que una llamada a SAP lenta o fallida nunca deja la notificación a medio construir.
Sources: Logging In and Out Using Basic Authentication with Service Layer, HTTP Request | Nodes | n8n Docs, Trying Out APIs in a Configured Environment | SAP Help Portal, Automating SAP Business One Sales Reporting with n... - SAP Community
Renovar la sesión y gestionar errores
La documentación de configuración de Service Layer de SAP establece el tiempo de espera de sesión inactiva predeterminado en 30 minutos, y el ajuste es configurable. Una vez que una sesión se cierra o deja de ser válida, la propia formación de SAP muestra que la siguiente solicitud devuelve un HTTP 401 con el mensaje 'Invalid session or session already timeout', y la base de conocimiento de SAP confirma que el mismo mensaje puede aparecer en cualquier solicitud una vez que la sesión ha caducado, en SAP Business One 10.0, versión para SAP HANA. Un flujo de trabajo que solo espera éxito en cada llamada se romperá la primera vez que ese tiempo de espera ocurra a mitad de la ejecución.
Por defecto, el nodo HTTP Request de n8n solo trata las respuestas 2xx como éxito, pero su opción 'Never Error' permite que un flujo de trabajo lea el propio código de estado y se ramifique: ante un 401, vuelve a llamar al endpoint de Login y luego reintenta la extracción original. El blog de un proveedor, del desarrollador de un nodo comunitario de SAP OData competidor, afirma que los servicios OData de SAP también requieren obtener un token CSRF antes de cada operación de escritura; trataríamos eso como la descripción del propio proveedor, a verificar contra la documentación oficial de SAP antes de confiar en ella para algo más allá de este ejercicio de solo lectura.
Sources: Logging In and Out Using Basic Authentication with Service Layer, Managing Service Layer Settings | SAP Help Portal, 3383703 - SAP Business One Service Layer returns "Invalid session or session already timeout" error | SAP Knowledge Base Article, HTTP Request | Nodes | n8n Docs, How I Built the First Real SAP OData Node for n8n | Avanai
Criterios de finalización y reflexión
Considera el ejercicio completo cuando el flujo de trabajo inicia sesión y recupera registros de pedidos de venta desde un endpoint documentado, aplica un paso de transformación que produce campos limpios y predecibles, envía una notificación de seguimiento construida a partir de esos campos, y detecta una respuesta 401 o de tiempo de espera y vuelve a autenticarse antes de reintentar en lugar de fallar silenciosamente.
SAP sigue siendo el sistema de registro del propio pedido de venta durante todo este ejercicio; n8n nunca sustituye su propia copia por la de SAP. Consideramos que esta división es donde las integraciones de n8n con SAP suelen funcionar mejor en la práctica: SAP sigue siendo propietario del registro del pedido y de sus reglas de negocio, mientras que n8n secuencia el inicio de sesión, los reintentos, la transformación y todo lo que ocurre alrededor de los datos una vez que salen de SAP.
