Multiples aplicaciones SAPUI5 en un mismo MTAR

Después de comentarlo con varias personas, me he dado cuenta que dependiendo del template que uséis para generar vuestra aplicación des de BAS tendréis mas o menos opciones. Esto es así ya que el proyecto, aunque sea el mismo, genera una estructura de carpetas o otras y esto nos puede determinar las opciones disponibles.

En este post veremos los distintos tipos de template, sus problemas, y como remediar el problema de las aplicaciones que no aparecen en el Launchpad.

Tipos de template

Antes de empezar vamos a ver las dos maneras de generar con el template de BAS una aplicación SAPUI5:

• Generar un «Basic Multitarget Application» y posteriormente añadir un módulo de aplicación SAPUI5: Esta opción nos permitirá añadir mas de una aplicación en el mismo proyecto y en el mismo repo-host, pero no tendremos la opción de añadir un appRouter des del wizard.

• Generar un «HTML5 project»: Con esta opción el propio wizard nos permite generar una aplicación SAPUI5 con un managed appRouter o con su propio appRouter. Aun así no podremos añadir módulos nuevos con nuevas aplicaciones SAPUI5

Para la primera opción, existe un problema, y es que al desplegar nuestra aplicación SAPUI5 la aplicación no aparecerá en el launchpad. Al menos en la versión actual del template.

Arreglando nuestra multitarget application

Para solucionarlo aquí tenéis los pasos que arreglan el problema:

Añadir configuración para el cloud launchpad en el manifest

En el fichero manifest.json falta la configuración cloud, el ultimo tag a añadir será:

    "sap.cloud": {
        "public": true,
        "service": "ecastella-firstapp"
    }

Añadir el servicio «XSUAA» para la conectividad entre la aplicación y el launchpad

En el fichero mta.yalm añadiremos los siguientes servicios/módulos:

• (Configuración de seguridad XSUAA) Añadimos en la raíz de nuestra aplicación el fichero xs-security.json, este será el contenido:

{
  "xsappname": "firstapp",
  "tenant-mode": "dedicated",
  "description": "Security profile of called application",
  "scopes": [
    {
      "name": "uaa.user",
      "description": "UAA"
    }
  ],
  "role-templates": [
    {
      "name": "Token_Exchange",
      "description": "UAA",
      "scope-references": [
        "uaa.user"
      ]
    }
  ]
}

Y este será el resultado en el directorio del proyecto:

• (Configuración de seguridad XSUAA) en el fichero mta.yaml añadiremos la creación del nuevo servicio bajo el bloque de resources:

- name: firstapp-uaa
  type: org.cloudfoundry.managed-service
  parameters:
    path: ./xs-security.json
    service: xsuaa
    service-name: firstapp-xsuaa-srv
    service-plan: application

• (Destinations / Resources) en resources modificaremos el servicio de destinations, modificaremos el parámetro » HTML5Runtime_enabled» del servicio de destination:

- name: ecastella-secondapp-dest-srv
  type: org.cloudfoundry.managed-service
  parameters:
    config:
      HTML5Runtime_enabled: true

• (Destinations / Modules) añadimos la configuración de binding de cada uno de los servicios, sin este servicio el portal no puede encontrar la aplicación:

- name: firstapp-dest-content
  type: com.sap.application.content
  requires:
  - name: firstapp-dest-srv
    parameters:
      content-target: true
  - name: firstapp-repo-host
    parameters:
      service-key:
        name: firstapp-repo-host-key
  - name: firstapp-uaa
    parameters:
      service-key:
        name: firstapp-uaa-key
  parameters:
    content:
      instance:
        destinations:
        - Name: firstapp_repo_host
          ServiceInstanceName: firstapp-html5-srv
          ServiceKeyName: firstapp-repo-host-key
          sap.cloud.service: firstapp
        - Authentication: OAuth2UserTokenExchange
          Name: firstapp_uaa
          ServiceInstanceName: firstapp-xsuaa-srv
          ServiceKeyName: firstapp-uaa-key
          sap.cloud.service: firstapp
        existing_destinations_policy: ignore
  build-parameters:
    no-source: true

A esta configuración extra le añadiremos «no-source» para indicar que no generara ningún artefacto ya que últimamente lo utilizamos para crear las destinations.

Vamos a analizar un poco esta parte ya que es la parte mas importante. Por u lado tenemos la generación de las keys necesarias para la lectura de la configuración por parte del portal «* -key»,por otro lado, la generación de las destinations ligadas a las keys anteriores.

• Por último aunque no es necesario, al final del fichero mta.yaml añadiremos el indicador para realizar estas operaciones de manera paralela:

  enable-parallel-deployments: true

Aplicaciones extra

Por último para cada aplicación nueva que añadamos en el proyecto deberemos verificar en su manifest.json que tengamos añadida la configuración para publicar en el launchpad.

El servicio deberá coincidir con la configuración de destinations:

Y este será el resultado

---

Como siempre suscribete, dale a la campanita de notificaciones y comparte en redes para estar a la última. Vota Like / Dislike para aportar feedback.