HTML5 Application Repository

El repositorio separa dónde se almacenan los archivos de UI de lo que los sirve:

1. Un desarrollador crea una aplicación SAPUI5, normalmente en SAP Business Application Studio, y la empaqueta en una multitarget application.
2. En el despliegue, el HTML5 application deployer sube los archivos estáticos de la aplicación a una instancia de servicio del plan app-host.
3. Un application router vinculado a una instancia app-runtime recupera esos archivos en tiempo de ejecución, autentica al usuario y reenvía las llamadas de datos a los back-ends a través de destinations.
4. SAP recomienda el application router gestionado por SAP, que no necesita runtime propio; un router operado por el propio equipo está pensado para casos avanzados, como las extensiones del router.

Como los archivos están desacoplados del router, una nueva versión de la aplicación entra en producción sin reiniciar nada, y el servicio conserva versiones y almacena el contenido en caché. El HTML5 Application Repository es almacenamiento y entrega de archivos de UI, no un runtime para lógica de negocio.

Cuando una subcuenta se suscribe a SAP Build Work Zone, aparece automáticamente un proveedor de contenido HTML5 Apps en el Channel Manager. Refleja las aplicaciones desplegadas en el repositorio de esa subcuenta. Para mostrar una aplicación en un site:

1. Descríbala en manifest.json: un ID de aplicación único, un nombre de business service (sap.cloud.service) y un inbound con semantic object y acción.
2. Despliéguela en la misma subcuenta que la suscripción a SAP Build Work Zone.
3. Actualice el proveedor de contenido HTML5 Apps en el Channel Manager.
4. Añada la aplicación en el Content Explorer, asígnela después a grupos, catálogos y roles, y los roles a un site.

Un error frecuente es omitir el paso 3 y preguntarse por qué falta una nueva versión. El HTML5 Application Repository entrega los archivos, mientras que SAP Build Work Zone decide quién ve el tile.

Puntos fuertes

• Actualizaciones sin tiempo de inactividad: el contenido cambia sin reiniciar el application router.
• Entrega serverless: con el application router gestionado, una UI no necesita ninguna instancia de aplicación en ejecución.
• Uso compartido y versionado: las aplicaciones públicas pueden ser consumidas por routers de otros spaces, y el contenido puede explorarse por versión.

Dónde están sus límites

• Solo contenido estático. Los servicios OData, la lógica de negocio y los datos residen en otro lugar, por ejemplo en CAP, RAP o SAP S/4HANA.
• Límites documentados. SAP documenta 100 MB por instancia app-host y límites de frecuencia por subcuenta para los despliegues y las solicitudes en tiempo de ejecución.
• Sin datos personales. Como el contenido puede compartirse, SAP desaconseja almacenar datos personales en él.
• Ámbito de subcuenta. La integración con Work Zone espera las aplicaciones en la misma subcuenta que la suscripción.

El HTML5 Application Repository responde a dónde residen los archivos SAPUI5 en SAP BTP, no a cómo funciona la aplicación que hay detrás.

SAP ofrece ahora también Application Frontend service, que aloja y sirve aplicaciones front-end como punto de entrada único, con su propia CLI, su propia UI en el cockpit y varias versiones activas. SAP lo posiciona para nuevas aplicaciones independientes y single-tenant que no se conectan con otras aplicaciones, y señala que el uso productivo requiere una licencia de SAP Build.

SAP indica que los equipos cuyas necesidades cubren el HTML5 Application Repository y el application router pueden seguir usándolos. Las aplicaciones desplegadas con Application Frontend service también pueden añadirse a SAP Build Work Zone, standard y advanced edition, ya sea manualmente como aplicaciones URL o mediante una configuración de Common Data Model.