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.