✒️SAP BASIS / Configuración del SAP Gateway Por Fernando Escola

Configuración del SAP Gateway

El Estándar OData

1. El Estándar OData y su Arquitectura

OData funciona como un contrato de comunicación uniforme entre un cliente y un servidor, permitiendo que ambos sean independientes e intercambiables mediante el uso de conectores.

• Lado del Cliente: Utiliza un conector (OData SDK) que traduce las peticiones de la aplicación (Escritorio, HTML5 o Móvil) al formato OData.

• Infraestructura Web: La comunicación se realiza a través del protocolo HTTP.

• Lado del Servidor (SAP): El SAP Gateway actúa como el conector fundamental. Traduce las entidades OData provenientes de la web a las API de ABAP que manejan la lógica de negocio en sistemas como SAP S/4HANA o Business Suite.

2. El Protocolo OData (El "ODBC de la Web")

OData sigue el paradigma REST (Representational State Transfer), donde los datos son recursos direccionables mediante URIs (Uniform Resource Identifiers).

• Formatos de Datos: Permite el intercambio de información principalmente en JSON (más ligero) o XML (en combinación con Atom Publishing y Atom Syndication para un soporte más amplio).

• Componentes Clave:

  • SAP Annotations: Etiquetas adicionales que SAP añade a los datos para enriquecer la información.

  • HTTP(S): Es el protocolo de red utilizado para toda la comunicación.

• Objetivo: Proporcionar una API neutral respecto al proveedor que permita acceder a los recursos del servidor de forma similar a como se accede a una base de datos, de ahí su apodo como "ODBC para la Web".

3. Extensibilidad y Versiones

El protocolo es extensible, permitiendo a SAP complementar los datos con información adicional del Diccionario de Datos ABAP, facilitando el desarrollo de interfaces modernas como SAP Fiori.

• Compatibilidad de Versiones en SAP:

  • V2: Es la versión en la que se basan la mayoría de los servicios. SAP Gateway la soporta desde el servidor de aplicación ABAP 7.00.

  • V4: Soportada desde el AS ABAP 7.50.

  • V3: SAP Gateway no es compatible con esta versión (fue omitida).

En resumen, OData es el puente que permite a aplicaciones externas "entenderse" con el backend de SAP de manera estandarizada, abierta y eficiente.

Las Bases del SAP Gateway

SAP Gateway actúa como un punto de entrada único para acceder a los datos de negocio de sistemas basados en ABAP (como SAP Business Suite o S/4HANA). No debe confundirse con el proceso gateway del kernel utilizado para comunicaciones RFC.

• Consumo de datos: Permite que aplicaciones externas (móviles, navegadores web, software empresarial como Office o nubes empresariales) consuman datos de SAP sin necesidad de que el cliente tenga conocimientos internos del sistema SAP.

• Otros proveedores: Además de SAP Gateway (para AS ABAP), existe SAP HANA XS, que cumple un rol similar pero directamente dentro de la base de datos SAP HANA.

2. Estructura y Evolución Técnica

El funcionamiento de SAP Gateway se divide en dos áreas principales:

• Tiempo de ejecución (Runtime): Proporciona el servicio OData de forma externa a través de la URL.

• Tiempo de diseño (Design Time): Contiene el entorno de desarrollo para crear y procesar las peticiones.

Evolución: En versiones antiguas (AS ABAP 7.00 a 7.31), estas funciones venían en add-ons individuales. A partir de AS ABAP 7.40, todos los componentes se fusionaron en un único componente de software llamado SAP_GWFND (SAP Gateway Foundation).

3. Opciones de Despliegue (Deployment)

Existen tres formas principales de configurar SAP Gateway:

• Hub Deployment con desarrollo en el Backend (BES): El servidor Gateway (Front-end) funciona como punto único de acceso y enrutamiento hacia múltiples sistemas backend. El desarrollo de los servicios ocurre en el backend. Es la configuración recomendada para SAP Business Suite.

• Hub Deployment con desarrollo en el Front-end (FES): El desarrollo se realiza en el servidor Gateway. Los datos se leen desde el backend mediante módulos de función habilitados para RFC. Es útil para integrar múltiples sistemas backend con diferentes versiones de SAP.

• Despliegue Embebido (Embedded Deployment): El Gateway reside en el mismo servidor que el sistema backend. Esto permite un acceso directo a las definiciones de datos y objetos del repositorio, lo que mejora el rendimiento y la eficiencia del desarrollo. Es la configuración recomendada para SAP S/4HANA.

4. Valor Agregado

Para escenarios de movilidad, se pueden integrar los SAP Mobile Services, que añaden capacidades adicionales a las aplicaciones que consumen los servicios OData generados por el Gateway.

Los componentes del SAP Gateway

La arquitectura de SAP Gateway ha pasado de ser un conjunto de parches o "add-ons" individuales a un componente unificado:

• AS ABAP 7.00 a 7.31 (Era de los Add-ons):

  • La funcionalidad OData se dividía en piezas separadas.

  • GW_CORE y IW_FND: Formaban el tiempo de ejecución (Runtime) y el registro de servicios.

  • IW_BEP: El componente central para el tiempo de diseño (Design Time) y la implementación de servicios.

  • Add-ons específicos: Existían componentes adicionales para funciones particulares, como IW_PGW (Process Gateway Workflow), IW_GIL (Generic Interaction Layer) e IW_SPI (Service Provider Infrastructure).

• AS ABAP 7.40 a 7.50 (Unificación):

  • Se crea el componente de software SAP_GWFND (Gateway Foundation).

  • Este nuevo componente fusiona los antiguos GW_CORE, IW_FND, IW_BEP y IW_HDB (específico para SAP HANA).

  • Los componentes como IW_PGW o IW_GIL se mantienen como grupos de add-ons para consumo de modelos de datos.

• AS ABAP ≥ 7.51 (Consolidación Final):

  • Incluso el componente de Workflow (IW_PGW) se integra dentro de SAP_GWFND.

  • Muchos add-ons antiguos se consideran obsoletos y deben desinstalarse, ya que sus funciones están integradas o ya no son compatibles.

2. Definiciones Clave

• SAP Gateway Foundation: Es el término técnico actual para lo que antes se conocía informalmente como "SAP Gateway 2.0". Es el corazón que permite la ejecución e implementación de OData.

• SAP NetWeaver y Downports: Para mantener la compatibilidad, SAP ha realizado "downports" (transferencia de funcionalidades de versiones nuevas a anteriores) de paquetes de estructura de SAP Gateway Foundation desde NetWeaver 7.52 a versiones como 7.51 o 7.50.

3. Consideraciones Técnicas

• Soporte de Protocolos: El framework unificado de SAP Gateway Foundation soporta tanto OData V2 como OData V4, aunque excluye componentes específicos como el Canal de Notificación en ciertos paquetes de estructura.

• Variaciones: Al usar versiones con downports, pueden existir ligeras variaciones en la funcionalidad o características que no se transfirieron íntegramente de la versión superior.

En resumen, la tendencia de SAP ha sido simplificar la administración pasando de múltiples componentes dispersos a un único núcleo robusto (SAP_GWFND) integrado directamente en el servidor de aplicaciones.

La administración del SAP Gateway

1. Configuración Básica y Manual

Para habilitar OData se requieren cuatro pasos esenciales, gestionados a través de las transacciones SPRO, SM59 y SICF:

• Destino RFC: Crear la conexión del Front-End (FES) al Back-End (BES). No aplica en despliegue embebido.

• Activación: Activar el SAP Gateway en el FES (o BES en modo embebido).

• Alias de Sistema: Definir la conexión lógica en el FES.

• Nodos ICF: Activar los servicios necesarios bajo la ruta /sap/opu.

2. Gestión de Alias de Sistema y SAP Gateway

El comportamiento de los servicios depende de los indicadores marcados en el alias:

• Local GW: Se marca para Despliegue Embebedido.

• Local App: Se marca para Hub Deployment con desarrollo en FES.

• Alias de SAP Gateway: Es una conexión inversa (BES a FES) necesaria para que los desarrolladores puedan registrar y probar servicios desde la transacción SEGW en el backend.

3. Optimización: OData on Backend y Co-Deploy

A partir de SAP NetWeaver 7.50, se busca mejorar el rendimiento:

• OData on Backend: Enruta el procesamiento al BES para liberar carga en el FES.

• Co-deployed only: Es el modo recomendado para el despliegue embebido, ya que elimina capas de comunicación intermedias y maximiza la velocidad.

4. Automatización con Listas de Tareas (Transacción STC01)

Para simplificar la inicialización y el mantenimiento, SAP ofrece listas de tareas predefinidas que ejecutan configuraciones complejas de forma automática:

• SAP_GATEWAY_BASIC_CONFIG: Realiza la configuración base, activa el Gateway, configura nodos ICF centrales y la caché de metadatos (disponible desde ABAP 7.40).

• SAP_SAP2GATEWAY_TRUSTED_CONFIG: Configura la conexión RFC de confianza entre BES y FES, habilitando el inicio de sesión único (SSO).

• SAP_GATEWAY_ACTIVATE_ODATA_SERV: Registra servicios basados en enrutamiento (routing-based) o co-desplegados.

• /IWFND/TL_SERVICE_MAINTENANCE: (Desde ABAP 7.54) Permite el mantenimiento masivo de servicios, incluyendo la gestión de alias, modos de procesamiento, transporte y eliminación de servicios.

En conclusión, la administración ha evolucionado desde procesos puramente manuales hacia un modelo automatizado por tareas, priorizando el rendimiento a través del procesamiento en el backend y el despliegue embebido.

Las herramientas del SAP Gateway

1. Mantenimiento de Servicios OData V2

La transacción central para gestionar servicios V2 es /IWFND/MAINT_SERVICE (en el Front-End Server). Se divide en tres áreas funcionales:

• Catálogo de Servicios: Permite visualizar nombres, descripciones y configuraciones técnicas de los servicios registrados.

• Nodos ICF: Gestión de los nodos del árbol de servicios de Internet y ejecución de pruebas rápidas.

• Alias de Sistema: Mantenimiento de la conexión hacia el back-end.

• Nota técnica: Si un servicio no se conecta a otros sistemas, el modo de procesamiento se define como Co-deployed only y no requiere alias.

2. Mantenimiento de Servicios OData V4

A diferencia de V2, los servicios V4 no se registran de forma individual, sino que se publican en grupos de servicios.

• Backend Service Administration (/IWBEP/V4_ADMIN): Se utiliza en el BES para crear y proporcionar los grupos de servicios.

• Gateway Service Administration (/IWFND/V4_ADMIN): Se utiliza en el FES para publicar dichos grupos y permitir su consumo externo.

• Grupo por defecto: Existe un grupo llamado /IWBEP/ALL para facilitar pruebas en desarrollo, pero nunca debe usarse en entornos productivos.

3. Cliente de SAP Gateway (/IWFND/GW_CLIENT)

Es la herramienta principal para que los administradores y desarrolladores prueben los servicios sin necesidad de una aplicación externa.

• Funcionalidades: Soporta métodos HTTP (GET, POST, PUT, MERGE, PATCH, DELETE). Permite simular el cuerpo de la solicitud y visualizar la respuesta en formatos XML Atom o JSON.

• Casos de prueba: Los ajustes y URIs ejecutados se pueden guardar como casos de prueba para uso posterior.

4. Transacciones de Administración y Monitoreo

Las herramientas se clasifican según su ubicación (Front-End vs. Back-End) y su función:

En el Front-End (Transacciones /IWFND/...):

• Administración: Activación de Gateway (/IWFND/IWF_ACTIVATE) y gestión de enrutamiento (/IWFND/ROUTING).

• Gestión: Limpieza de caché (/IWFND/CACHE_CLEANUP) y activación de metadatos (/IWFND/MED_ACTIVATE).

• Monitoreo: Log de errores (/IWFND/ERROR_LOG), monitor de notificaciones, trazas (/IWFND/TRACES) y estadísticas de rendimiento (/IWFND/STATS).

En el Back-End (Transacciones /IWBEP/...):

• Administración: Configuración global (/IWBEP/GLOBAL_CONFIG).

• Gestión: Limpieza de caché a nivel de backend.

• Monitoreo: Registro de errores de backend y herramientas de traza para depurar la lógica de negocio.

5. Guía de Implementación (SPRO)

Además de las transacciones directas, toda la configuración jerárquica reside en la Guía de Referencia de SAP (SPRO), que organiza las tareas en ramas de tiempo de ejecución y tiempo de diseño.

En resumen, el ecosistema de herramientas permite un control total desde la creación del servicio en el backend hasta su exposición y diagnóstico de errores en la capa de comunicación front-end.

El mantenimiento del SAP Gateway

1. Limpieza de Caché (Metadata Cache)

La limpieza de la caché es fundamental para asegurar que los cambios realizados en el backend se reflejen correctamente en el servicio OData. Existen dos niveles de limpieza:

• En el Front-End (FES): Se utiliza para limpiar la caché de metadatos del Gateway.

  • Transacción: /IWFND/CACHE_CLEANUP

• En el Back-End (BES): Se utiliza para limpiar la caché de los proveedores de datos.

  • Transacción: /IWBEP/CACHE_CLEANUP

• Nota técnica: En el despliegue embebido, dado que ambos componentes residen en el mismo servidor, se deben ejecutar ambas transacciones localmente.

2. Análisis y Registro de Errores (Error Log)

El log de errores es la herramienta principal para identificar fallas en la comunicación o en el procesamiento de datos.

• Error Log en el Front-End Server (FES):

  • Transacción: /IWFND/ERROR_LOG

  • Registra problemas relacionados con la infraestructura del Gateway, el enrutamiento y la comunicación externa.

• Error Log en el Back-End Server (BES):

  • Transacción: /IWBEP/ERROR_LOG

  • Muestra errores relacionados con la implementación de la lógica de negocio y el procesamiento de los datos en el backend.

• Funciones avanzadas: Ambos registros permiten la reproducción del error para facilitar la depuración, navegación directa a la implementación y visualización de detalles técnicos de la petición.

3. Trazas de SAP Gateway (Traces)

Las trazas se utilizan para un análisis más profundo de las peticiones HTTP y el rendimiento.

• Transacción: /IWFND/TRACES

• Payload Trace: Permite ver el contenido exacto (cuerpo de la petición y respuesta) que viaja entre el cliente y el servidor. Es vital para diagnosticar problemas de estructura de datos.

• Performance Trace: Mide los tiempos de respuesta y ejecución, ayudando a identificar cuellos de botella en el servicio.

4. Herramientas de Limpieza General

SAP proporciona programas para el mantenimiento preventivo y la eliminación de registros antiguos que pueden ocupar espacio innecesario:

• Limpieza de Logs de Error: Transacción /IWFND/CLEANUP_ERRLOG (permite borrar registros por fecha o usuario).

• Limpieza de Trazas: Transacción /IWFND/CLEANUP_TRACE.

• Estadísticas: El sistema permite gestionar la retención de datos estadísticos para monitorear el uso de los servicios a largo plazo sin saturar la base de datos.

En resumen, un correcto mantenimiento implica la limpieza coordinada de cachés (FES y BES) tras cada transporte o actualización, y el uso estratégico de los logs de errores y trazas para garantizar la estabilidad del servicio.

El estado suave del SAP Gateway

1. Verificación del Estado de los Componentes

Para que SAP Gateway funcione, es esencial que los componentes de software estén instalados y activos. Esto se verifica en el sistema ABAP:

• Componente SAP_GWFND: A partir de AS ABAP 7.40, es el núcleo unificado. Se debe comprobar su versión y nivel de Service Pack en el estatus del sistema.

• Componentes Heredados: En versiones anteriores (7.00 a 7.31), se debe verificar la presencia de IW_FND, GW_CORE e IW_BEP.

• Business Functions: Algunas capacidades requieren la activación de funciones de negocio específicas a través de la transacción SFW5.

2. Estado de la Conectividad (RFC y Confianza)

El estado de la comunicación entre el Front-End (FES) y el Back-End (BES) es crítico:

• Conexión RFC (SM59): Se debe testear la conexión de tipo 3 (ABAP) y asegurar que el "Connection Test" y el "Authorization Test" sean exitosos.

• Relación de Confianza (Trusted Relationship): El estado debe ser "Trusted" para permitir el Single Sign-On (SSO). Se verifica que el usuario tenga los permisos necesarios en el BES para ser aceptado por el FES.

3. Estado de los Servicios y Nodos ICF

Un servicio OData puede existir pero no estar operativo si su infraestructura web está desactivada:

• Transacción SICF: Se debe verificar el estado (color verde) de los nodos bajo la ruta /sap/opu/odata. Si el nodo está en gris, el servicio devolverá un error HTTP 403 o 404.

• Transacción /IWFND/MAINT_SERVICE: En el catálogo de servicios, se comprueba si el servicio tiene asignado al menos un Alias de Sistema válido y si el indicador de estado del servicio es óptimo.

4. Monitoreo de Disponibilidad y Rendimiento

Existen herramientas para validar el estado de salud en tiempo real:

• Gateway Client (/IWFND/GW_CLIENT): Ejecutar una petición básica al documento de servicio o al metadato ($metadata). Si devuelve un código HTTP 200 OK, el estado del servicio es funcional.

• Service Health Check: Algunas versiones de Gateway permiten realizar diagnósticos automatizados sobre la configuración para detectar inconsistencias en los alias o en los destinos RFC de forma masiva.

• Monitor de Tareas (STC01): El estado de las listas de tareas (como SAP_GATEWAY_BASIC_CONFIG) indica si la configuración inicial se completó sin errores o si quedaron pasos pendientes.

En conclusión, el "estado" del Gateway es un conjunto de validaciones que van desde la capa de software base hasta la activación individual de cada nodo de servicio en la infraestructura web.