Capítulo 6: Desarrollo de Servicios OData en SAP Gateway
SAP Gateway es la tecnología fundamental de SAP que actúa como puente entre el mundo exterior (aplicaciones Fiori/UI5, aplicaciones móviles, sistemas de terceros) y los sistemas backend de SAP (como S/4HANA o SAP Business Suite). Permite la creación, publicación y gestión de servicios OData que exponen datos y funcionalidades de negocio de forma estandarizada y segura.74 Este capítulo se centra en el proceso práctico de desarrollo de servicios OData utilizando SAP Gateway.
Introducción a SAP Gateway
SAP Gateway (ahora a menudo referido como SAP Gateway Foundation como parte de la plataforma ABAP) proporciona las herramientas y el tiempo de ejecución necesarios para desarrollar y consumir servicios OData basados en datos SAP.74 Traduce las solicitudes OData entrantes en llamadas a la lógica de negocio del backend (ej. BAPIs, Módulos de Función RFC, Vistas CDS, clases ABAP) y formatea los resultados del backend en respuestas OData estándar (JSON o Atom/XML).91
Arquitectura (Hub vs. Embedded)
Existen dos principales escenarios de despliegue para SAP Gateway:
Hub Deployment (Despliegue Centralizado): SAP Gateway se instala en un sistema servidor separado (el "Hub") que se conecta a uno o más sistemas backend SAP. Todas las solicitudes OData pasan por este Hub central.
Ventajas: Punto único de acceso y gestión, mayor seguridad (los backends no están expuestos directamente), posibilidad de composición y enrutamiento de servicios desde múltiples backends.91
Desventajas: Requiere un sistema adicional, posible punto único de fallo, latencia adicional por el salto de red RFC entre Hub y Backend.
Recomendación: Era la configuración recomendada para SAP Business Suite.91
Embedded Deployment (Despliegue Embebido): Los componentes de SAP Gateway (IW_BEP para el backend, SAP_GWFND para el frontend/hub) se instalan directamente en el mismo sistema SAP backend (ej. S/4HANA).
Ventajas: Arquitectura simplificada (menos sistemas), menor latencia (sin llamada RFC externa), más fácil de configurar.
Desventajas: La gestión de servicios está distribuida, el sistema backend está más expuesto.
Recomendación: Es el enfoque predominante y recomendado para SAP S/4HANA.93
En ambos escenarios, la comunicación entre los componentes de frontend (manejo de OData) y backend (lógica de negocio) utiliza RFC, incluso si están en el mismo sistema en el despliegue embebido.94
Service Builder (Transacción SEGW)
El SAP Gateway Service Builder (Transacción SEGW) es el entorno de diseño principal en el sistema ABAP para crear y mantener servicios OData.32 Proporciona un conjunto de herramientas visuales e integradas que guían al desarrollador a través del ciclo de vida del servicio.
Creación de Proyectos
Todo desarrollo de servicio OData en SEGW comienza con la creación de un proyecto.
Iniciar SEGW.
Hacer clic en el botón "Crear Proyecto".32
Asignar un nombre al proyecto (siguiendo convenciones, ej. Z<NOMBRE>_SRV), una descripción y seleccionar un paquete de desarrollo (o $TMP para objetos locales).32
Seleccionar el tipo de proyecto. "Service with SAP Annotations" o "Service with Vocabulary-Based Annotations" son comunes.93
El proyecto actúa como un contenedor para todos los artefactos relacionados con el servicio.35
Definición del Modelo de Datos (Entidades, Conjuntos, Asociaciones)
Una vez creado el proyecto, el siguiente paso es definir el Modelo de Datos de Entidad (EDM) en la rama Data Model del proyecto.35
Entity Types (Tipos de Entidad): Representan las estructuras de datos. Se pueden crear de varias maneras:
Manualmente: Definiendo cada propiedad (nombre, tipo Edm, clave, etc.) una por una.
Importando: Desde estructuras DDIC (tablas, estructuras, vistas), BAPIs/RFCs, o archivos.32 Al importar desde DDIC, se seleccionan los campos deseados y se marca(n) la(s) propiedad(es) clave.32
Referenciando Fuentes de Datos (CDS Views): En enfoques más modernos, se pueden referenciar Vistas CDS existentes (ver Capítulo 8).74
Entity Sets (Conjuntos de Entidades): Son las colecciones de instancias de Entity Types. Se crean haciendo clic derecho en la carpeta Entity Sets y asociándolos a un Entity Type existente.32 La convención de nombres suele ser <EntityType>Set o <EntityType>Collection.32
Associations (Asociaciones) y Navigation Properties (Propiedades de Navegación): Definen las relaciones entre Entity Types.
Se crea una Asociación especificando la entidad principal (Principal Entity), la entidad dependiente (Dependent Entity), la cardinalidad (ej. 1 a N), y las propiedades clave que las vinculan (Referential Constraints).32
Al crear la Asociación, se definen automáticamente las Propiedades de Navegación correspondientes en cada Entity Type, permitiendo navegar entre entidades relacionadas en las URIs OData (ej. /SalesOrders(1)/Items).32
Generación de Artefactos (MPC, DPC)
Una vez definido el modelo de datos, se deben generar los objetos de tiempo de ejecución (Runtime Artifacts).
Hacer clic en el botón "Generate Runtime Objects" (o clic derecho en el proyecto -> Generate Runtime).32
El sistema propone nombres para las clases ABAP que se generarán y el nombre del servicio técnico.32 Se recomienda mantener los valores predeterminados.
Confirmar la creación y asignar un paquete (o local).
Esto genera automáticamente varias clases ABAP y registra el servicio y el modelo 32:
Clase MPC (Model Provider Class): Define el modelo de datos en tiempo de ejecución (ej. ZCL_<PROYECTO>_MPC). Contiene tipos (TS_<EntityType>, TT_<EntityType>) que representan las estructuras de las entidades.72
Clase MPC_EXT (Model Provider Extension Class): Hereda de la MPC. Permite extender o modificar el modelo mediante código (ej. redefiniendo el método DEFINE).36
Clase DPC (Data Provider Class): Contiene la implementación genérica de las operaciones OData (ej. ZCL_<PROYECTO>_DPC).
Clase DPC_EXT (Data Provider Extension Class): Hereda de la DPC. Aquí es donde se implementa la lógica de negocio específica para las operaciones CRUD, funciones, acciones, etc., redefiniendo los métodos heredados.32
Servicio Técnico: El nombre bajo el cual se registra el servicio en Gateway (ej. <PROYECTO>_SRV).72
Modelo Técnico: El nombre bajo el cual se registra el modelo (ej. <PROYECTO>_MDL).72
Implementación de Métodos DPC (*_EXT classes)
La lógica real que recupera, crea, actualiza o elimina datos se implementa en la clase DPC_EXT (Data Provider Class Extension).32 Se navega a esta clase desde SEGW (expandiendo Runtime Artifacts, doble clic en DPC_EXT) o directamente desde SE24/SE80.32 Dentro de esta clase, se redefinen los métodos correspondientes a las operaciones OData que el servicio debe soportar.
Métodos CRUD (GET_ENTITYSET, GET_ENTITY, CREATE_ENTITY, UPDATE_ENTITY, DELETE_ENTITY)
Para cada Entity Set definido (ej. SalesOrderSet), la DPC hereda métodos específicos que se pueden redefinir:
<ENTITYSET_NAME>_GET_ENTITYSET: Se llama para solicitudes GET a la colección (ej. /SalesOrderSet). Debe recuperar múltiples entidades y devolverlas en el parámetro de exportación ET_ENTITYSET.65 Aquí se implementa la lógica para $filter, $orderby, $top, $skip, $count, $search.
<ENTITYSET_NAME>_GET_ENTITY: Se llama para solicitudes GET a una entidad individual (ej. /SalesOrderSet('123')). Debe leer la(s) clave(s) del parámetro de importación IT_KEY_TAB, recuperar la entidad correspondiente y devolverla en ER_ENTITY.72
<ENTITYSET_NAME>_CREATE_ENTITY: Se llama para solicitudes POST a la colección (ej. /SalesOrderSet). Debe leer los datos de la nueva entidad del cuerpo de la solicitud usando io_data_provider->read_entry_data( IMPORTING es_data = ls_data ), realizar la inserción en el backend y devolver la entidad creada en ER_ENTITY.72
<ENTITYSET_NAME>_UPDATE_ENTITY: Se llama para solicitudes PUT o PATCH a una entidad individual (ej. /SalesOrderSet('123')). Debe leer la(s) clave(s) de IT_KEY_TAB, leer los datos actualizados de io_data_provider->read_entry_data(), realizar la actualización en el backend (verificando ETags si aplica con If-Match) y opcionalmente devolver la entidad actualizada en ER_ENTITY.65
<ENTITYSET_NAME>_DELETE_ENTITY: Se llama para solicitudes DELETE a una entidad individual (ej. /SalesOrderSet('123')). Debe leer la(s) clave(s) de IT_KEY_TAB, realizar la eliminación en el backend (verificando ETags si aplica con If-Match).72
Nota: Es una buena práctica no poner lógica de negocio compleja directamente en estos métodos, sino encapsularla en clases de API separadas que son llamadas desde los métodos de la DPC_EXT.75
Implementación de Opciones de Consulta ($filter, $orderby, $top, $skip)
Como se mencionó en el Capítulo 4, estas opciones requieren implementación en GET_ENTITYSET:
Acceso a Opciones: Se utiliza el parámetro de importación io_tech_request_context (tipo /IWBEP/IF_MGW_REQ_ENTITYSET) que ofrece métodos como:
get_filter(): Devuelve un objeto para acceder a las opciones de filtro (get_filter_select_options(), get_filter_string()).44
get_orderby(): Devuelve los criterios de ordenación.104
get_top(): Devuelve el valor de $top.17
get_skip(): Devuelve el valor de $skip.17
get_skiptoken(): Devuelve el valor de $skiptoken.
get_search_string(): Devuelve el valor de $search.
Aplicación: La lógica ABAP debe interpretar estas opciones y construir una consulta de base de datos (generalmente SELECT) que las aplique. Para $filter, esto a menudo implica construir una cláusula WHERE dinámica. Para $orderby, añadir una cláusula ORDER BY. Para $top/$skip, usar UP TO/OFFSET o lógica de paginación post-selección.17
Implementación de $expand
Aunque el framework maneja la expansión básica, se pueden redefinir los métodos /IWBEP/IF_MGW_APPL_SRV_RUNTIME~GET_EXPANDED_ENTITYSET y /IWBEP/IF_MGW_APPL_SRV_RUNTIME~GET_EXPANDED_ENTITY para controlar o optimizar cómo se recuperan los datos expandidos.17 Esto puede ser necesario para escenarios complejos o para mejorar el rendimiento sobre la implementación genérica.
Implementación de Funciones/Acciones (EXECUTE_ACTION)
Como se detalló en el Capítulo 5, todas las Function Imports y Action Imports se manejan redefiniendo el método /IWBEP/IF_MGW_APPL_SRV_RUNTIME~EXECUTE_ACTION en la DPC_EXT.39 Se usa iv_action_name para identificar la operación y io_tech_request_context->get_parameters() para obtener los parámetros de entrada. El resultado se establece en er_data usando copy_data_to_ref.71
Registro y Mantenimiento de Servicios (/IWFND/MAINT_SERVICE)
Una vez que el servicio se ha generado (y opcionalmente implementado), debe registrarse en el sistema SAP Gateway para que sea accesible desde el exterior.
Ir a la transacción /IWFND/MAINT_SERVICE (en el sistema Hub o en el sistema Embebido).36 También se puede acceder desde SEGW (rama Service Maintenance -> clic derecho en el alias del sistema -> Register).35
Hacer clic en "Add Service".85
Especificar el System Alias que apunta al sistema backend donde se definieron los artefactos (a menudo LOCAL para despliegues embebidos o si se registra desde el backend).85
Buscar el Servicio Técnico (ej. Z<PROYECTO>_SRV) generado en SEGW.85
Seleccionar el servicio y hacer clic en "Add Selected Services".85
Confirmar la asignación del paquete y la creación.85
El servicio aparecerá ahora en el catálogo de servicios. Asegurarse de que el nodo ICF (columna ICF Node) esté activo (luz verde).35 Si no, seleccionarlo y activar el nodo ICF desde el menú.
Esta transacción también se utiliza para eliminar servicios, desactivar nodos ICF y gestionar alias del sistema.
Pruebas con SAP Gateway Client (/IWFND/GW_CLIENT)
SAP Gateway proporciona un cliente de pruebas integrado, el SAP Gateway Client (Transacción /IWFND/GW_CLIENT), que permite enviar solicitudes OData al servicio registrado y ver las respuestas HTTP.35
Desde /IWFND/MAINT_SERVICE, seleccionar el servicio registrado y hacer clic en el botón "SAP Gateway Client".35
La URI base del servicio se rellena automáticamente.
Seleccionar el método HTTP (GET, POST, PUT, PATCH, DELETE).35
Completar la URI con el resourcePath deseado (ej. /SalesOrderSet, /SalesOrderSet('123')) y las queryOptions (ej. ?$filter=...&$top=...).35 Los botones "EntitySets" y "Add URI Option" pueden ayudar.35
Para POST, PUT, PATCH, introducir el payload en el área "HTTP Request Body".35
Añadir cabeceras HTTP si es necesario (ej. Content-Type, Accept, If-Match).
Hacer clic en "Execute" (F8).35
La respuesta HTTP (código de estado, cabeceras, cuerpo) se muestra en el panel "HTTP Response".35
Permite establecer puntos de interrupción externos en la DPC_EXT y depurar la ejecución del servicio.102
Ofrece botones para navegar al Error Log (/IWFND/ERROR_LOG) o usar la respuesta como base para una nueva solicitud ("Use as Request").36
El Gateway Client es una herramienta indispensable para probar y depurar servicios OData durante el desarrollo.
Last updated