Miremos el Paradigma de desarrollo del canal ODataque describe el modelo de programación utilizado por el tiempo de ejecución de SAP Gateway.

El Odatos El canal para SAP Gateway le permite desarrollar contenido definiendo modelos de objetos y registrando un DPC de tiempo de ejecución correspondiente. La ventaja del paradigma del canal OData es una cierta libertad con respecto al desarrollo; Se pueden utilizar definiciones DDIC completas e interfaces locales del sistema backend de SAP para desarrollar servicios de SAP Gateway. Además, las opciones de consulta de OData se pueden aprovechar en sus sistemas backend de SAP para que solo los datos solicitados por el cliente se seleccionen del sistema backend de SAP y se envíen de vuelta por cable. Esta especificidad da como resultado servicios altamente optimizados e importantes mejoras de rendimiento debido a transferencias de datos más pequeñas.

Con respecto al modelo de programación OData, los servicios de SAP Gateway constan de cuatro componentes:

• MPC: Implementado para proporcionar la representación en tiempo de ejecución de la definición de su modelo.
• DPC: Llamado en tiempo de ejecución para realizar solicitudes de datos.
• Nombre del servicio técnico: Se utiliza para registrar el servicio en el sistema backend de SAP junto con el nombre del modelo técnico.
• Nombre del modelo técnico: Se utiliza para registrar el servicio en el sistema backend de SAP junto con el nombre del servicio técnico.

El nombre del servicio técnico y el nombre del modelo técnico se generan automáticamente con MPC y DPC al generar un proyecto utilizando Service Builder.

Clase de proveedor modelo

El MPC es un ABAP clase que proporciona la representación en tiempo de ejecución de la definición de su modelo; es decir, el MPC define el EDM de un servicio. Como tal, toda la información del modelo que haya definido en su proyecto se genera en el MPC. Por lo tanto, debe regenerar el MPC cada vez que cambie la definición del modelo en su proyecto. El MPC es importante porque todo lo que encuentra en el documento de metadatos de servicio de un servicio OData publicado a través de SAP Gateway se ha definido mediante programación en el MPC.

Técnicamente, la definición del modelo se genera en dos clases:

• Clase base: Técnicamente, la clase base se deriva de la superclase /IWBEP/CL_MGW_PUSH_ABS_ MODEL y tiene el sufijo _MPC.
• Clase de extensión: La clase de extensión tiene la clase base como superclase y tiene el sufijo _MPC_EXT. La clase de extensión se registrará mediante el nombre del modelo técnico. En la clase de extensión, puede elegir qué métodos redefinir y qué métodos heredar de la clase base.

En la mayoría de los casos, un desarrollador no necesita tocar la clase de extensión del proveedor de modelo con el sufijo _MPC_EXT generada por Service Builder. Una excepción a esta regla es, por ejemplo, si desea crear servicios de SAP Gateway con características que (todavía) no se pueden modelar utilizando las herramientas de SAP Gateway. En este caso, un desarrollador puede redefinir métodos en la clase de extensión del proveedor de modelos. La siguiente figura muestra la clase base del proveedor de modelos en la parte superior, que hereda de /IWBEP/CL_MGW_PUSH_ABS_MODEL. ZCL_ZPRODUCT_MPC_EXT es la subclase de la clase de proveedor de modelo. El DEFINIR El método se sobrescribe.

Análisis profundo de la clase de proveedor de modelos

Por lo general, un desarrollador no necesita acceder a la codificación del MPC que genera Service Builder. Pero echemos un vistazo más de cerca a los métodos que se generan para comprender mejor el marco subyacente.

El método GET_LAST_MODIFIED es la base para un protocolo de enlace entre el sistema backend de SAP y SAP Gateway para iniciar una actualización de los metadatos almacenados en caché del servicio en el backend de SAP Gateway y el servidor de SAP Gateway después de que se haya cambiado la clase. Este método no debe cambiarse manualmente.

En los métodos DEFINE específicos del tipo de entidad, Service Builder genera la codificación que crea las partes del modelo OData que definen los tipos de entidad y los conjuntos de entidades que se basan en el tipo de entidad. Se crean las propiedades y aquellas propiedades que se han marcado como campo clave en Service Builder se establecen como campos clave en la codificación:

lo_property = lo_entity_type->

create_property( iv_property_name="ProductID"

iv_abap_fieldname="PRODUCT_ID" ).

lo_property->set_is_key( ).

Finalmente, el tipo de entidad se vincula a una estructura DDIC y se crean uno o más conjuntos de entidades. Tenga en cuenta que un tipo de entidad que está vinculado a una estructura DDIC existente puede aprovechar las salidas de conversión, así como las etiquetas de los elementos de datos de la DDIC. La etiqueta de campo mediana de un elemento de datos se utiliza como sap:label de forma predeterminada:

...

lo_entity_type->

bind_structure( iv_structure_name =

   'BAPI_EPM_PRODUCT_HEADER' iv_bind_conversions="X" ).

...

lo_entity_set = lo_entity_type->

create_entity_set( 'Products' )

En el método DEFINE_ASSOCIATION, puede encontrar el código generado que define asociaciones, conjuntos de asociaciones, restricciones referenciales y propiedades de navegación de un modelo OData.

Clase de proveedor de datos y clase de extensión de proveedor de datos

DPC es una clase ABAP que proporciona todos los métodos necesarios para manejar solicitudes de OData. Se llama en tiempo de ejecución para realizar estas solicitudes; Básicamente, estamos hablando de la representación en tiempo de ejecución de la implementación de su servicio. Por ejemplo, un DPC ejecuta operaciones CRUD-Q, entre muchas más operaciones.

Nuevamente, puede encontrar una clase de extensión (sufijo _DPC_EXT) y una clase base (sufijo _DPC). La clase de extensión del proveedor de datos hereda de la clase base DPC, como se muestra en la siguiente figura. Podemos ver los métodos que la clase de extensión ha heredado de la clase base para CRUD-Q y operaciones de consulta y un método que se ha redefinido en la clase de extensión para la implementación basada en código. La clase de extensión DPC se registra mediante el nombre del servicio técnico. Entonces, la clase de extensión se ejecuta en su servicio OData.

Tenga en cuenta que, en DPC, algunos métodos son específicos de un conjunto de entidades y otros no.

Análisis profundo de la clase de proveedor de datos

Para cada conjunto de entidades, Service Builder crea métodos que el marco llama si se envía un método de creación, lectura, actualización y eliminación (CRUD) a este conjunto de entidades. Para un conjunto de entidades llamado , los métodos creados en la clase base se muestran en esta tabla.

Los métodos adicionales disponibles se aplican no sólo para un único conjunto de entidades sino para todos ellos (métodos no específicos de conjuntos de entidades). Ejemplos de estos métodos incluyen métodos que manejan sentencias $EXPAND, sentencias de inserción profunda o sentencias que se llaman cuando se realiza una importación de función. Echemos un vistazo más de cerca a estos ejemplos:

• GET_EXPANDED_ENTITY y GET_EXPANDED_ENTITYSET: El marco de SAP Gateway ofrece el manejo de declaraciones $expand de manera genérica después de haber modelado la propiedad de navegación adecuada e implementado el manejo de las propiedades de navegación. En algunas situaciones, podrías manejar las solicitudes $expand mediante una implementación de aplicación específica. Algunos ejemplos son ciertas BAPI como BAPI_EPM_SO_GET_LIST que, junto con los datos del encabezado, también recuperan líneas de pedido. En este caso, al recuperar los datos del encabezado del pedido de ventas para un determinado pedido de ventas, también se leen los elementos del pedido de ventas correspondientes. Si también se llama al conjunto de entidades para expandir las líneas de pedido junto con el encabezado del pedido de ventas, esto da como resultado solicitudes de base de datos innecesarias.
• CREATE_DEEP_ENTITY: La contraparte de la declaración $expand es la inserción profunda declaración, que llama a CREATE_DEEP_ENTITY. Un ejemplo típico es el caso en el que un pedido de ventas solo se puede crear junto con al menos un artículo de pedido de ventas. A diferencia de la declaración $expand, no hay un manejo genérico de una solicitud de inserción profunda. El desarrollador debe implementar este método.
• EJECUTAR_ACCIÓN: El método EXECUTE_ACTION tampoco es un método específico de un conjunto de entidades. Este método es más bien semántico de servicio y se llama si se llama a una función de importación en un servicio OData. Las importaciones de funciones le permiten ejecutar funciones que pueden leer y/o escribir datos. Las importaciones de funciones son adecuadas siempre que el escenario empresarial requiera leer o cambiar datos que no se pueden modelar en una entidad donde se pueden utilizar métodos CRUD-Q.5

Consideraciones técnicas

El desarrollo del canal OData puede tener lugar en el sistema backend de SAP o en el servidor SAP Gateway, como se muestra en la figura final. Ambas opciones son adecuadas para determinados casos de uso y tienen sus ventajas. Dondequiera que desarrolle, el componente BEP debe estar instalado en ese sistema, o debe utilizar un sistema basado en SAP NetWeaver 7.40 o superior.

Nota del editor: esta publicación ha sido adaptada de una sección del libro. Pasarela SAP y OData de Carsten Bönnen, Ludwig Diehl, Volker Drees, André Fischer y Karsten Strothmann.