Cómo extraer los datos de SAP: Gateway y servicios oData (I)

He intentado varias veces vender mi aplicación en SAPUI5 de Hola Mundo, pero a nadie parece interesarle. Resulta que lo que todo el mundo quiere es extraer datos de algún sistema. Muy exigentes me parecen a mí.

Así que vamos a necesitar una forma de extraer la información de SAP. De esa manera, podremos construir una aplicación SAPUI5 más chula, con datos reales y todo. Y eso lo vamos a conseguir mediante un componente instalado en SAP: El Gateway y sus servicios oData.

Gateway

El Gateway (SAP NetWeaver Gateway 2.0) es un componente que tendremos instalado de forma predeterminada si nuestra versión de NetWeaver es una 7.40 o superior. Eso puedes verlo fácilmente revisando la versión del componente SAP BASIS.
Si lo que tenemos es un NW 7.31, entonces este componente hay que instalarlo aparte. Ahí nos tienen que echar una manita los nunca-lo-suficientemente-bien-valorados compañeros de Basis.
Si es una versión anterior, lamento decirte que no podrás instalarte el componente. Es lo que hay :( . Quizá sea el momento de desarrollar algo a medida o usar otras tecnologías, como Neptune.

El Gateway es el responsable de crear, generar y exponer la información mediante servicios oData. ¿Lo cualo? Pues es la forma con la que nos comunicaremos con SAP para obtener la información.

oData

oData es un protocolo estándar creado por Microsoft y mantenido actualmente por Oasis. Básicamente son las normas que nos dicen de qué forma tenemos que solicitar la información y cómo hay que estructurar la respuesta. El propio protocolo en sí no nos dice cómo calcular esa información, sólo cómo debe ser solicitada y cómo debe ser devuelta.

La solicitud se realiza por HTTP(s), mediante una URL. Eso quiere decir que con un simple navegador web ya podremos solicitar este recurso, como si fuese una página más.

El resultado es un fichero XML o JSON que utilizaremos en nuestra página web. Y no sólo nos sirve para leer datos, sino que también nos sirve para todas las operaciones CRUD: create, read, update and delete.

¿Quién es el encargado de entender la URL solicitada, determinar el dato y generar el XML de salida? El Gateway, por supuesto.

Cuando creamos un servicio (mediante la transacción SEGW), el Gateway nos generará toda la infraestructura para traducirnos la URL a ABAP y, a su vez, traducir el ABAP a XML.

Esta infraestructura incluirá unas clases ABAP llamadas Data Provider Class (DPC) y Model Provider Class (MPC). Nosotros sólo tenemos que programar los métodos oportunos para obtener la información que nos piden. No tenemos que preocuparnos en generar el XML, eso ya lo hará el Gateway por nosotros.

Éste es un diagrama muy muy muy básico

Cada servicio oData es una agrupación "temática" de información. Generalmente se crea un servicio oData por cada aplicación que vayamos a construir. El servicio tendrá, a su vez:

• Una o varias entidades (entities), que son como las "estructuras" de información que posee el servicio. Cada entidad tiene una serie de propiedades, que son los campos de la entidad.
• Por cada entidad puede existir una colección (o entitySet), que es la "tabla" que nos devolverá la información.
• Un documento de servicio, que se obtiene llamando directamente a la URL del servicio oData, y que nos mostrará la colecciones disponibles en el servicio.
• El documento metadata (EDMX), que podemos obtener con la URL MI_SERVICIO/$metadata, y que nos proporciona toda la información del servicio (entidades y sus propiedades, colecciones, y otros elementos).

Mediante el documento de servicio y el documento metadata, obtendremos la información del servicio. Las entidades nos proporcionan la estructura del documento. Mediante las colecciones, obtendremos la información.

Vamos a poner dos ejemplos, uno teórico y uno práctico.

Ejemplo 1: Servicio oData de Solicitud de absentismos

La aplicación de Fiori "Solicitud de absentismos" (My leave requests) se usa para que un empleado pueda pedir y comunicar ausencias a su manager (vacaciones, enfermedad, etc). Esta aplicación utiliza un servicio oData para mostrar dicha información, llamado HCM_LEAVE_REQ_CREATE_SRV. Algunas de sus colecciones son:

• AbsenceTypeCollection: Que es la que nos devuelve los tipos de ausencia que podemos elegir, y que luego la aplicación añadirá a la ayuda de búsqueda.
• ApproverCollection: Nos devuelve los aprobadores del empleado. Así sabe a quién le va a llegar la solicitud.
• LeaveRequestCollection: Nos devuelve los absentismos que tenemos creados en el sistema para nuestro número de personal. De esta manera sabemos lo que hemos pedido y en qué estado se encuentra.
• TimeAccountCollection; Nos devuelve los derechos de ausencia que tenemos. Así sabemos cuantos días de vacaciones aún tenemos por solicitar.

Ejemplo 2: Servicio oData de Nothwind

Podemos ver un ejemplo práctico, gracias al servicio oData de Northwind, que es accesible públicamente sin pedir usuario ni contraseña, mediante los siguientes enlaces:

• Documento de servicio: http://services.odata.org/V4/Northwind/Northwind.svc/
• Documento metadata: http://services.odata.org/V4/Northwind/Northwind.svc/$metadata
• Ejemplo de colección Customers: http://services.odata.org/V4/Northwind/Northwind.svc/Customers

La URL del servicio oData en SAP

El formato de la URL para solicitar cualquier colección de un servicio oData en SAP es /sap/opu/odata/sap/MISERVICIO/NombreDeLaColeccion.

La llamada es case-sensitive, es decir, que debemos tener cuidado con las mayúsculas y minúsculas.

Para que esta URL esté accesible, es necesario activar el servicio oData en la SICF. Aunque eso también lo hará el Gateway automáticamente por nosotros.

Y ojo, esto es importante... cuando envías datos mediante un servicio oData, aunque luego en la aplicación no pintes todos eso datos, el usuario puede ser capaz de ver todos los datos. ¡Le vale con consultar en su navegador las herramientas de desarrollador, F12! ¿Qué quiere decir esto? Que nunca debemos crear un servicio oData con más información de la que pueda ver el usuario, aunque pensemos que no lo va a mostrar la web. Siempre enviamos la justa (o la que no sea confidencial). Los datos tendremos que filtrarlos, por tanto, en la parte ABAP.

Arquitectura

Un último detalle a tener en cuenta, referente al Gateway, es la arquitectura sobre la que está montado.

Pensando tanto en un entorno Fiori o sólo aplicaciones SAP UI5 independientes (aquello que llaman aplicaciones standalone), la arquitectura más básica se basará en dos servidores, que no son más que dos SAP NetWeaver.

Uno de ellos hará de Front-End, que es donde están las páginas web que el usuario visitará y donde el Gateway publica los servicios oData para que la gente los pueda usar.

El otro (u otros) será el Back-End, que es donde estarán los datos y donde habrá una pequeña porción del Gateway (un componente llamado IW BEP) que usaremos para desarrollar nuestras clases DPC.

El Front-End mostrará la página web al usuario y le pedirá al Back-End (mediante una conexión segura y de confianza) los datos para enlazarlos en la web. Hará las veces de traductor (la URL la transformará a ABAP y el ABAP a XML) y de proxy inverso (el usuario creerá que los datos están en el Front-End pero realmente vienen del Back-End... ¡el usuario nunca sabrá de dónde salío esa información!). Esto añade, además, más seguridad, ya que se puede hacer que el Front-End esté expuesto al exterior (vulnerable a ataques) pero no el Back-End (los datos están a salvo).

¿Y por qué puede haber varios Back-End? Pues porque puede que tengamos un servidor Back-End para HR, otro para Finanzas, otro para MM, etc. El Front-End tendrá parametrizado una serie de conexiones (los Alias de Sistema) que le dirán, en todo momento, de donde obtener los datos de cada servicio oData.

Básicamente y hablando mal y rápido (es una analogía para entenderlo mejor), el Front-End haría las veces de lo que hasta ahora teníamos en el SAP Portal. Las aplicaciones Web estarán en el Front-End (como pasaba con las Web Dynpro Java) y los datos en el Back-End.

El esquema básico, que es lo que SAP llama despliegue en Hub es el siguiente:

El SAP Web Dispatcher, en este ejemplo, es opcional.
Sirve para enmascarar la URL y poder solicitar recursos de varios servidores usando el mismo subdominio... esto evita la protección contra CSRF que presentan los nuevos navegadores web. En este diagrama, realmente el Gateway hace esas mismas funciones.

Una posible disposición más sencilla es montar el Front-End y Back-End la misma máquina. En ese caso, el Gateway "se conecta consigo mismo": Todavía hace falta crear un alias de sistema y una conexión de confianza, pero será para conectarse él. El Gateway no se fía ni de si mismo, oye.

Esta arquitectura es la denominada Embedded deployment, o despliegue integrado. No es la aconsejada, sobre todo si tienes varios Back-End, pero si sólo tienes un Back-End está claro que será más barata. Aunque eso supondrá que si la expones al exterior expones toda la máquina, no sólo la parte web.

El Front-End y el Back-End son la misma máquina

¡Pero todavía lo podemos complicar un poco más! Si tenemos la aplicación en el SAP HCP (ya sea porque estamos desarrollándola o porque la hayamos colgado en el portal de SAP HCP), el despliegue será el siguiente:

Se crea un destination para apuntar a nuestra Front-End.
Esa es la manera de decirle a SAP HCP: ¡Eh, mira, aquí está mi servidor!

Y si queremos aprovechar que nuestra cuenta también dispone de su propio Gateway, podríamos incluso llevar todo el Front-End al HCP. En ese caso, no necesitaríamos un servidor Front-End propio, sólo losBack-End, al que apuntaríamos desde HCP con un destination por cuenta. 

Pero siempre que usemos el SAP HCP, tendremos que pensar también en cuentas de usuario e historias de esas. Cosas que de momento dejamos, para que no nos quiten el sueño.

El próximo paso es ponernos con la parte práctica: crear nuestro propio servicio oData en SAP.