El despliegue de la aplicación SAPUI5 en SAP Cloud Foundry dentro de SAP Business Technology Platform.
El proceso desde la configuración inicial hasta el undeploy de la aplicación.
El despliegue se realiza en un space de SAP Cloud Foundry, que es el entorno lógico donde se ejecutan las aplicaciones dentro de una subcuenta de BTP. Para poder hacer el deploy desde SAP Business Application Studio (BAS) es necesario contar con ciertos datos de conexión: el API Endpoint de la región, el nombre de la organización (Organization) y el nombre del space donde se desplegará la aplicación. Todos estos datos se encuentran en el Cockpit de SAP BTP, dentro de la subcuenta correspondiente, ya sea en la vista general (Overview) o en la sección Cloud Foundry → Spaces.
En cuanto al enrutamiento, SAP recomienda utilizar el SAP Managed Approuter, ya que permite ejecutar aplicaciones HTML5 sin necesidad de un runtime dedicado, reduciendo consumo de recursos y simplificando el mantenimiento. Solo en escenarios avanzados se utiliza un Standalone Approuter. El Managed Approuter facilita la escalabilidad automática y aprovecha las capacidades de enrutamiento actualizadas de SAP sin configuraciones complejas adicionales.
Antes de realizar el deploy, es fundamental revisar ciertos archivos de configuración. El archivo xs-app.json define el enrutamiento y suele incluir la propiedad welcomeFile para que al acceder a la URL raíz se cargue automáticamente el index.html. El archivo manifest.json, dentro de la sección sap.app, contiene el ID de la aplicación, que es clave para la configuración de rutas. Una regla importante es que, cuando se utiliza este ID en configuraciones técnicas, debe escribirse sin puntos. También se debe prestar atención a la definición de URLs de recursos: no deben comenzar con barra y deben definirse de forma relativa. Además, la carpeta localService, utilizada comúnmente para mockdata en desarrollo local, no se incluye en el build final en Cloud Foundry, por lo que no debe utilizarse para recursos productivos. En el archivo index.html es necesario verificar que las librerías de SAPUI5 se carguen desde la URL correcta del CDN oficial.
El archivo mta.yaml es el descriptor central de la aplicación multi-target. Allí se definen todos los módulos, recursos y servicios necesarios, así como la versión de la aplicación y la versión del esquema MTA. Este archivo orquesta todo el deployment, indicando qué componentes deben desplegarse y qué servicios deben crearse o vincularse. Entre los servicios más importantes se encuentra XSUAA, el servicio de autenticación y autorización de SAP BTP.
SAP Authorization and Trust Management Service (XSUAA) es el encargado de autenticar usuarios, gestionar permisos y emitir tokens JWT para acceso seguro. Se define como recurso dentro del mta.yaml y requiere un archivo xs-security.json donde se configuran scopes y roles. Los roles definidos allí deben asignarse luego a usuarios mediante Role Collections en BTP. Cada aplicación deployada tiene su propia instancia de XSUAA y su correcta configuración es crítica para la seguridad.
El proceso de build toma el archivo mta.yaml, compila los módulos definidos, empaqueta los recursos y genera un archivo final con extensión .mtar dentro de la carpeta mta_archives. Este archivo es el que se despliega en Cloud Foundry. Para hacerlo desde la terminal, primero se debe iniciar sesión con el comando cf login, proporcionando el API Endpoint, usuario, organización y space. Luego se ejecuta el comando cf deploy seguido del nombre del archivo .mtar. Este paso despliega todos los módulos y crea o vincula automáticamente los servicios definidos en el mta.yaml.
Una vez deployada, la aplicación aparece en el BTP Cockpit dentro de Cloud Foundry → Spaces → Applications. Allí se puede ver su estado (started, stopped o crashed), la memoria consumida y los servicios asociados. También puede consultarse desde la terminal con el comando cf apps. Durante el deploy pueden crearse servicios automáticamente si están definidos en el mta.yaml, aunque también es posible crearlos manualmente desde el Service Marketplace o mediante comandos CLI. Los servicios están asociados a un space específico y pueden visualizarse tanto a nivel de aplicación (Service Bindings) como a nivel general del space (Service Instances).
El proceso de undeploy elimina la aplicación y, si se indica, también los servicios asociados. Un punto importante es que, si existen Service Keys activas, deben eliminarse antes de borrar el servicio, de lo contrario se producirá un error. Desde la terminal puede utilizarse el comando cf undeploy junto con las opciones para eliminar servicios y service keys en un solo paso. También puede realizarse desde el BTP Cockpit eliminando manualmente la aplicación y los servicios vinculados.
Por último, los logs son fundamentales durante todo el ciclo de vida de la aplicación. Registran el inicio y detención, errores, solicitudes HTTP y mensajes de depuración. Pueden visualizarse en tiempo real desde la terminal con cf logs o desde el BTP Cockpit en la pestaña Logs de la aplicación. Revisarlos después de cada deploy es una buena práctica para confirmar que la aplicación inició correctamente y no existen errores ocultos.
CONCLUSIÓN
El flujo completo del deployment consiste en preparar correctamente los archivos de configuración, ejecutar el build desde el mta.yaml para generar el .mtar, autenticarse en Cloud Foundry, realizar el deploy, verificar servicios y logs, y finalmente gestionar el undeploy cuando sea necesario. Todo este proceso garantiza que la aplicación SAPUI5 quede correctamente integrada y segura dentro del entorno de SAP BTP.
- Preparación: Configurar xs-app.json, manifest.json, index.html
- Build: Ejecutar build desde mta.yaml → genera .mtar
- Login: Conectarse a CF con cf login
- Deploy: Ejecutar cf deploy mta_archives/<nombre>.mtar
- Verificación: Revisar logs y confirmar que los servicios se crearon correctamente
- Acceso: La app está disponible en la URL generada
- Undeploy (cuando sea necesario): cf undeploy <mta-id> --delete-services --delete-service-keys -f