Gestión de ETag en SAP OData: un ejercicio editorial en n8n antes de reintentar
Diseña un ejercicio de ETag de SAP OData en n8n: conserva la lectura original, introduce un cambio de cola concurrente y concilia antes del reintento condicional.
Comprobado con las fuentes citadas el .
Define el ejercicio de ETag de SAP OData y sus límites
Este ejercicio editorial de ETag de SAP OData te propone diseñar un flujo de n8n que lea un WarehouseOrder desechable, conserve su estado original, introduzca una actualización concurrente de la cola y se detenga para conciliar los cambios antes de reintentar. Es una propuesta de aprendizaje, no un flujo ejecutado ni validado.
El entorno objetivo es SAP S/4HANA Cloud Public Edition 2608. SAP documenta Warehouse Order and Task (A2X) como una API OData V4 y permite cambiar la cola de un WarehouseOrder mediante PATCH o PUT. Deja fuera de este ejercicio los registros de producción, la confirmación de tareas y la eliminación.
Empieza con una conexión a un entorno de pruebas ya autorizada. SAP identifica SAP_COM_0353 como el escenario de comunicación de esta API, pero esa referencia no constituye una guía de configuración completa. Reúne los siguientes datos antes de empezar a construir.
| Dato de entrada | Decisión necesaria |
|---|---|
| Orden desechable | Claves EWMWarehouse y WarehouseOrder aprobadas |
| Valores de cola | Colas original, concurrente y deseada aprobadas por el administrador |
| Preparación para escribir | Procedimiento de autenticación, CSRF y sesión aprobado para el tenant |
| Contrato condicional | Ubicación del ETag, uso de If-Match y respuesta ante conflictos verificados |
| Responsable de la decisión | Persona identificada y autorizada para conciliar los cambios de cola |
Sources: APIs for Warehouse Management | SAP Help Portal, Update Queue for Warehouse Order | SAP Help Portal, 3400080 - No authorization to access service group 'API_WAREHOUSE_ORDER_TASK_2' - S/4HANA Cloud
Conserva la lectura original antes de introducir una actualización concurrente
Considera la verificación del contrato condicional un requisito previo. La documentación aportada de Cloud Public Edition 2608 no establece la ubicación del ETag en la lectura de la entidad, su reutilización en If-Match ni la respuesta exacta ante una etiqueta obsoleta. La documentación independiente de SAP para instalaciones locales, versión 2025 FPS02, indica a los consumidores que recuperen un ETag mediante GET y exige If-Match para las operaciones de cambio; esos requisitos no permiten establecer el comportamiento de Cloud.
El ejemplo de actualización de cola de Cloud incluye If-Match y X-CSRF-Token. La obtención del token y el reenvío de las cookies de sesión asociadas en n8n deben seguir el procedimiento aprobado de tu tenant antes de cualquier escritura. No deduzcas el comportamiento de n8n a partir del de SAP Cloud SDK.
En el nodo HTTP Request de n8n, activa Include Response Headers and Status. Su documentación también permite referenciar un nodo anterior por su nombre, lo que permite que este diseño mantenga la lectura original separada de las respuestas posteriores. La documentación aportada no especifica ninguna versión, edición ni plan para estas capacidades; las referencias por nombre no proporcionan persistencia duradera.
Una vez resueltos esos requisitos previos, utiliza esta secuencia sugerida para ETag de SAP OData. Creemos que mantener la instantánea original claramente separada aporta más valor aquí que compactar el flujo.
- Lee el WarehouseOrder aprobado en un nodo llamado Original Read; conserva sin cambios su cola, sus claves y el ETag opaco verificado.
- Registra la cola deseada por separado de la instantánea original.
- Realiza una actualización concurrente autorizada de la cola mediante el procedimiento condicional verificado del tenant.
- Intenta realizar la actualización deseada original con la etiqueta original conservada; evita que la respuesta de la actualización concurrente la sustituya.
Sources: Update Queue for Warehouse Order | SAP Help Portal, Operations for Warehouse Order and Task API | SAP Help Portal, n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.httprequest/README.md at main · n8n-io/n8n-docs · GitHub, Use the UI mapper | Build | n8n Docs
Inspecciona la respuesta y exige conciliar los cambios
Para inspeccionar la respuesta, n8n documenta que Never Error permite continuar con las respuestas independientemente del estado HTTP. Si lo activas, que el nodo termine correctamente no demuestra que la actualización de SAP haya tenido éxito: inspecciona explícitamente el estado y el cuerpo devueltos.
Dirige la respuesta a la verificación del éxito, a un punto de conciliación o a otra ruta de error mediante reglas explícitas. El enrutamiento por estado es una aplicación editorial de las salidas separadas de la implementación de Switch V3; la implementación aportada procede de la rama master en evolución, no de una versión fija de n8n.
La documentación de la biblioteca REST de la plataforma ABAP de SAP, versión 2025 FPS02, describe HTTP 412 para un ETag obsoleto después del cambio de otro cliente. Úsalo como contexto, no como resultado garantizado del ejercicio en Cloud. Un artículo de SAP Community de 2026 sobre CAP Java recomienda revisar las diferencias antes de volver a aplicar los cambios; ese ejemplo de la comunidad respalda la idea de conciliar, no el comportamiento de este servicio.
En ese punto, compara la cola original, la deseada y la más reciente, y registra la decisión del responsable de cancelar o aprobar una actualización revisada. Consideramos que renovar una etiqueta debe venir después de decidir la intención, en lugar de sustituir esa decisión. Desactiva los reintentos automáticos y el uso de comodines en If-Match en este ejercicio.
Sources: n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.httprequest/README.md at main · n8n-io/n8n-docs · GitHub, Conditional Handling | SAP Help Portal, Handling Concurrent Updates in SAP CAP Java - SAP Community, n8n/packages/nodes-base/nodes/Switch/V3/SwitchV3.node.ts at master · n8n-io/n8n · GitHub
Completa el ejercicio con pruebas y una decisión del responsable
Utiliza estos criterios de aceptación propuestos para la gestión de ETag de SAP OData. Tras la aprobación, recupera una entidad y una etiqueta nuevas mediante el procedimiento verificado, ejecuta la actualización condicional aprobada y vuelve a leer para comprobar el resultado. Si observas una respuesta distinta, debe quedar en el registro de pruebas, no en una ruta que dé el éxito por supuesto.
Como reflexión, pregúntate: ¿quién puede decidir si debe mantenerse la asignación de cola concurrente? Si no puedes identificar a ese responsable, detente en la conciliación. Incluiríamos esa cuestión de responsabilidad en la revisión antes de debatir si el reintento debe automatizarse.
