Deconstrucción de una aplicación UI5 en Cloud Foundry

Introducción

Estructura de una aplicación SAPUI5 generada en CF

En la entrada de hoy nos ponemos el gorro de los grandes cheff para deconstruir una aplicación SAPUI5 y desgranar todos los elementos que la componen.

Pero… antes de empezar ¿Qué peculiaridades tiene una aplicación en Cloud Foundry? La respuestas no es fácil pero para simplificarlo la principal diferencia respecto a un despliegue NEO es que la aplicación se incluye en un enrutador que a su vez controla el acceso llamado UAA.

Construyendo nuestra aplicación en CF

Muy bien, para poder decosntruir primero necesitaremos una aplicación, para ello crearemos una aplicación basada en un template de webide, sin mas complicaciones.

• Nos dirigimos a nuestro WEBIde y allí vamos a «File» > «New» > «Project from tempate».
• Seleccionaremos el tipo de plataforma «Cloud Foundry» y creamos un proyecto tipo «Multi tarjet application».

• Añadimos un nombre al proyecto y en la siguiente pantalla marcamos el flag «Use HTML5 Application Repository» que nos añadirá los módulos node.js para poder acceder. Mas adelante entraremos en detalle, por último pulsamos el botón finalizar:

• Una vez creado el proyecto MTA, crearemos un nuevo modulo HTML5, con esto añadiremos una aplicación SAPUI5.

• Aparecerá un wizard con las posibles aplicaciones SAPUI5 para Cloud Foundry, para nuestro caso crearemos lo mas básico «SAPUI5 Application» con los siguientes datos:

Al final del step «Template Customization» ya tenemos todo apunto, finalizamos el wizard y ya podemos comenzar la deconstrucción.

Ya tenemos nuestra aplicación, si eres de los que se conforma con tener una aplicación en CF sin saber que ha pasado puedes quedarte aquí.

¿Qué hemos construido? (teoria)

SAP Cloud foundry se basa en microservicios. La idea de cloud fondry es crear unas pequeñas cajas negras que interaccionan entre ellas a partir de APIs. Estas cajas negras o microservicios se pueden crear en cualquier lenguaje ya que lo importante es sus llamadas.

Este es el esquema de lo que tenemos en nuestra aplicación:

Al crear nuestra aplicación hemos creado 2 servicios básicos:

• App Router: Como su nombre indica es nuestro router, su misión es la de redirigir las primeras llamadas para obtener del servicio XSUAA el Json Web Token (nuestro token de acceos) y gestionar las llamadas que hacemos hacia los distintos servicios disponibles en nuestro proyecto.
• XSUAA: Se encarga de la seguridad de la aplicación. Cuando configuramos el proyecto yalm podemos crear scopes y roles para poder acceder. Cada rol es un conjunto de scopes que nos permiten realizar distintas acciones siempre que el usuario tenga asingados estos roles.

• El componente XSUAA se encarga de gestionar si el usuario que intenta entrar en la aplicación tiene los roles asociados asignados, en caso afirmativo se obtiene el JWT o token de acceso al microservicio. Esto lo puede realizar contra el servicio de autentificación de SAP o cualquier IDP configurado.

A nivel practico esto se traduce en los siguientes pasos:

• Para acceder a nuestra aplicación lo hacemos pasando por el App router, veremos en nuestra url de la aplicación la coletilla «approuter» que también nos aparece cuando realizamos el deploy.
• App router nos da información de la aplicación e inicia la llamada al servició XSUAA para obtener el json web token o JWT y validar nuestro usuario.
• El servicio xsuaa obtiene nuestros datos de sesion (validados en el IDP) y compara que el usuario tenga los scopes de la aplicación.
• Si todos los paso anterior se han cumplido, obtenemos nuestro JWT de acceso y nos redirige hacia nuestra webapp (también se usaria este mismo mecanismo para APIS).

¿Qué tenemos en nuestro WEBIde?

Nuestro proyecto tiene, el siguiente aspecto (Si no lo ves como en la imagen, pulsa el botón del ojo)

Paso a detallar cada uno de los puntos:

mta.yaml

Este fichero es el germen de todo lo que tengamos en nuestro proyecto MTA (Multi Target Application). Es el que contiene las instrucciones de construcción, despliegue y activación del proyecto cuando se realiza el deploy hacia la plataforma SAP Cloud Foundry.

Destacar 3 grandes bloques de este fichero:

• ID: permite añadir el identificador y la versión del proyecto. La versión es útil para evitar que se suban versiones anteriores, al intentar hacer deploy se valida el número de versión y si es menor a la publicada no permite el deploy.

ID: deconstruccion
 _schema-version: '2.1'
 parameters:
   deploy_mode: html5-repo
 version: 0.0.1

• Modules: Son los modulos a desplegar y contiene los distintos microservicios que incluiran, equivalen a las distintas instancias que se generarán al hacer un deploy. En este punto, también se define las cuotas de lo que vamos a desplegar, pero tranquilos, se pude modificar a posteriori con el cliente de cloud foundry o des del cockpit:

modules:
  - name: deconstruccion_appRouter
    type: approuter.nodejs
    path: deconstruccion_appRouter
    parameters:
      disk-quota: 256M
      memory: 256M
    requires:
      - name: deconstruccion_html5_repo_runtime
      - name: uaa_deconstruccion
  - name: deconstruccion_ui_deployer
    type: com.sap.html5.application-content
    path: deconstruccion_ui_deployer
    requires:
      - name: deconstruccion_html5_repo_host
    build-parameters:
      requires:
        - name: deconstruccion_APP
          artifacts:
            - './*'
          target-path: resources/deconstruccion_APP
  - name: deconstruccion_APP
    type: html5
    path: deconstruccion_APP
    build-parameters:
      builder: grunt

Vamos a explayarnos un poco en este punto. Cada módulo se indica con «-» y se traduce en una instancia en el deploy.

El primer modulo, deconstruccion_appRouter, es el app Router que he comentado en el punto anterior, contiene las cuotas de la aplicación y las dependencias que utilizará la aplicación. Vemos que incluye el recurso deconstruccion_html5_repo_runtime que es donde se alojara nuestra webapp y uaa_deconstruccion que orquestra toda la seguridad. Aquí tambien deberiamos añadir los servicios de theming o las destinations en caso de usarlos.

El segundo modulo, deconstruccion_ui_deployer, este modulo es únicamente para que la aplicación se empaquete dentro del app router en el momento del deploy por lo que este servició casi siempre lo veremos parado (recordemos que nuestra app estará alojada en deconstruccion_html5_repo_host).

El tercer modulo deconstruccion_APP es el constructor de la aplicación.

Sin mas pasamos a la segunda parte del fichero:

• Resources: Esta sección contiene la definicion de los microservicios a utilizar, algunos de ellos pueden existir y otros se crearan/actualizarán en el momento del deploy.

resources:
  - name: deconstruccion_html5_repo_runtime
    parameters:
      service-plan: app-runtime
      service: html5-apps-repo
    type: org.cloudfoundry.managed-service
  - name: deconstruccion_html5_repo_host
    parameters:
      service-plan: app-host
      service: html5-apps-repo
    type: org.cloudfoundry.managed-service
  - name: uaa_deconstruccion
    parameters:
      path: ./xs-security.json
      service-plan: application
      service: xsuaa
    type: org.cloudfoundry.managed-service
  - name: dest_deconstruccion
    parameters:
      service-plan: lite
      service: destination
    type: org.cloudfoundry.managed-service

Entrando en mas detalle vemos los siguiente:

• deconstruccion_html5_repo_runtime que como ya he comentado anteriormente es donde se el app router con el que accederemos a la aplicación.
• deconstruccion_html5_repo_host que es donde se alojan los ficheros de nuestra aplicación. Este microservicio es esencial en caso de crear tareas tipo UI en workflows.
• uaa_deconstruccion microservicio de autentificación y obtencion de JWT.
• dest_deconstruccion este microservició es el de destinations, podemos utilizar uno propio del proyecto o reutilizar la instancia genérica de destinations a nivel de subacount.

A modo recordatorio, estos microservicios definidos en resources son los que se requeriran «requires» en el apartado de modules para que todo funcione. Si queremos interactuar con otros microservicios primero lo definiremos aquí y luego lo podremos añadir al modulo.

En caso que queramos utilizar un microservicio ya definido añadiremos en resource el tipo: org.cloudfoundry.existing-service y en el modulo que necesitemos añadiremos el servicio en «requires».

Vamos a analizar ahora la estructura de carpetas:

deconstruccion_APP

La aplicación que hemos creado se integra dentro de nuestro proyecto MTA:

Carpeta deconstruccion_appRouter

Contiene la aplicación node appRouter. El fichero package.json nos pemite modificar la versión node y indica el fichero JS a iniciar con el enrutador:

Carpeta deconstruccion_ui_deployer

Contiene las configuraciones de despliegue, esta carpeta la pasamos rápida al no tener mucho mas

Fichero xs-security.json

En este fichero en tiempo de desarrollo es donde definimos los roles y scopes de la aplicación. Estos roles los podrá seleccionar el administrador de la cuenta para añadir a un role collection y permitir el acceso a ciertas zonas de nuestra aplicación o API.

Para entender el concepto de roles y scopes, un usuario puede acceder a visualizar y modificar datos de la aplicación para ello crearemos un role-template de administrador y añadiremos un scope de visualizar y otro de modificar. El resto de usuarios tendrán asignados otro rol con solo el scope de visualizar.

Acceso a la aplicación

Vale, todo esto esta muy bien, pero 2 preguntas básicas, o al menos yo las tenia en su dia…

¿Como sabe el componente APP Router donde hay que ir?

Los pasos son los siguientes:

• Al deployar nuestra aplicación, en el fichero «mta.yaml» le hemos dicho que cualquer ruta «./*» se redirija hacia «resources/<nuestra_app>

• Esta ruta es la de nuestra aplicación

Por último el fichero xs-app.json nos redirigirá hacia el welcomefile que tengamos definido:

¿Como accedo a mi aplicación?

• Si entrar en detalle de como hacer un deploy, así os dejo espacio a la investigación, y después de todo lo leído únicamente hay que posicionarse sobre la carpeta de proyecto y apretar el boton de play, pero a que es mejor si sabemos todo lo que hay por detras 🙂

---

Hasta aquí la entrada de hoy, si queréis tener mas detalle sobre tecnologías Cloud puedes consultar esta entrada arquitectura de sistemas cloud ¿Por donde empiezo?

Y si quieres profundizar mas sobre la seguridad en CF te recomiendo este blog https://blogs.sap.com/2017/05/17/deploying-a-sapui5-application-on-cloud-foundry-environment-within-sap-cloud-platform/ donde se explica como hacer un deploy fuera de SAP WebIDE

Por último, Suscribete y no te pierdas ninguna novedad!