Dios mío, ¿dónde está mi Gateway?

Que si vamos a usar Fiori, que si vamos a trabajar con SAPUI5, que si consumimos servicios oData... Pero todo este "entramado" SAP UX necesita una parte tecnológica en la que sustentarse, que nos permite comunicar nuestro Front-End (la máquina a la que accedemos para usar nuestras aplicaciones SAPUI5 mediante el Fiori Launchpad) con nuestro Back-End (allí donde tenemos bien guardados nuestros datos maestros).

Este componente no es ni más ni menos que el SAP NetWeaver Gateway 2.0.

Básicamente, el Gateway permite que el Front-End exponga al exterior los datos que se generan en el Back-End (mediante los servicios oData). Toda la parte de autorizaciones de negocio y calidad del dato reside en el Back-End (la forma de obtener los datos es una caja negra para el usuario) y al Front-End sólo enviamos lo que el usuario puede ver, para que se pinte en la aplicación web.

Pero, ¿dónde está el famoso Gateway?

¡Será por posibilidades! Vamos a ver las distintas opciones de despliegue que tenemos para Fiori y, en cada una, dónde estaría nuestro Gateway.

Despliegue on-premise

Partiremos de la configuración más conocida, en la que todo lo tenemos en casa, on-premise.

Tenemos dos tipos de despliegue on-premise, en hub (una máquina es el Front-End y otra es el Back-End) e integrada (embedded, el Front-End y el Back-End son la misma máquina). A efectos teóricos, nos va a dar un poco igual, lo que nos interesa es saber que todas nuestras máquinas las tenemos en nuestro CPD (o debajo de la mesa del responsable de sistemas, o en un servidor de terceros, pero nosotros somos los encargados de mantenerlas).

Es en el Front-End donde tendremos ubicado el Gateway. Aunque hay que detallar que en el Back-End siempre tiene que existir un pequeño componente que forma parte del Gateway, llamado BEP (IW_BEP), que es el que se encarga de generar los servicios oData. Back-End genera, Front-End expone. Si tienes el Gateway instalado en un Back-End, enhorabuena, también tienes el BEP.

En esta configuración, el Front-End (directamente o a través del SAP Web Dispatcher) actúa como nexo de unión con el exterior, para acceder a las aplicaciones (Fiori-SAPUI5) y a los servicios oData (Gateway).

Entonces, en este caso, tendríamos una configuración como la siguiente. Sólo hay que seguir las rayitas que parten del pobre usuario que trabaja en el suelo porque no quedan sillas libres en la oficina:

El Gateway lo tenemos "en casa".
Aunque en el diagrama se ven como dos máquinas,
Front-End y Back-End podrían ser la misma, en modo embedded

Y entonces vino SAP Portal

A esta configuración estándar se le puede añadir una nueva variable: SAP Portal. Y es que a partir del SAP Portal NetWeaver 7.40 SPS7, se puede usar un desktop que nos permite "simular" el Fiori Launchpad y así poder integrar las aplicaciones SAPUI5 y mobilizar el portal. Y estaríamos reutilizando nuestro SAP Portal si no nos podemos desprender de él. Aquí se pueden ver los beneficios dependiendo del SPS de SAP Portal.

En este caso, la configuración es igual a la anterior, solo que el usuario accede a SAP Portal, éste muestra las aplicaciones que hay en el Front-End (mediante iViews), que obtiene los datos del Back-End. El Gateway, por tanto, sigue estando en el Front-End. Las aplicaciones SAPUI5 también, y las iViews lo que hacen es mostrárnoslas integradas en SAP Portal (como hacen con las Web Dynpros).

En SAP Portal añadiríamos iViews de tipo Fiori

Vamos al Cloud

Entonces entran en juego otra nueva variable... ¡la nube!

Podemos optar por montar un portal web Fiori gracias a las dos soluciones que nos proporciona SAP, ya sea el SAP Cloud Portal (si lo que tenemos son aplicaciones nuevas, desarrolladas por nosotros) o SAP Fiori Cloud Edition (para acceder a aplicaciones estándar en la nube).

Aunque tengamos las aplicaciones en la nube, nuestro Gateway puede seguir descansando tranquilamente en la oficina. Las aplicaciones se conectarán a dicho Gateway mediante un destination y el Gateway se conectará, como hasta ahora, al Back-End. Quizá aquí pueda ser necesario usar el SAP Cloud Conector si el Gateway está protegido del exterior.

El Front-End ya no actuará como tal, sino que sólo hará labores de publicación de datos (es decir, ya sólo nos interesa el Gateway).

Vayamos a la nube

Y llegó el OData Provisioning

Claro, que entonces alguien dirá "¿y para qué quiero yo tener el Gateway en mi casa si ya tengo las aplicaciones en la nube?". Pues hala, dicho y hecho, SAP nos proporciona otra solución: El HCP Odata Provisioning. O lo que es lo mismo, el Gateway en la nube.

Una solución que nos sirve para conectarnos a nuestro Back-End sin necesidad de disponer de una máquina propia,  dejando a nuestro antiguo Gateway on-premise en el olvido. Sólo tendremos que configurar el ODP para que se entienda con el componente BEP de nuestro Back-End, aparte de las activaciones de servicios cotidianas. Aquí sí que es más que probable que necesitemos el SAP Cloud Connector, ya que generalmente el Back-End no se suele exponer al exterior.

Adios, Gateway local, adios.

En resumen

Hemos visto que tenemos unas cuantas soluciones: Usar el Gateway en un Front-End on-premise; usar un Front-End en la nube y el Gateway on-premise; o usar el Front-End y el gateway en la nube.

Todo un laberinto en el que elegir y perdernos. Quizá perdernos demasiado.