HTML5 Application Repository

Le référentiel sépare l'endroit où les fichiers d'interface sont stockés de ce qui les sert :

1. Un développeur crée une application SAPUI5, généralement dans SAP Business Application Studio, et la package dans une multitarget application.
2. Au déploiement, le HTML5 application deployer charge les fichiers statiques de l'application dans une instance de service du plan app-host.
3. Un application router lié à une instance app-runtime récupère ces fichiers à l'exécution, authentifie l'utilisateur et transmet les appels de données aux back-ends via des destinations.
4. SAP recommande l'application router géré par SAP, qui ne nécessite aucun runtime propre ; un router autogéré est destiné aux cas avancés, comme les extensions de router.

Comme les fichiers sont découplés du router, une nouvelle version de l'application est mise en ligne sans aucun redémarrage, et le service conserve les versions et met le contenu en cache. Le HTML5 Application Repository assure le stockage et la livraison des fichiers d'interface ; ce n'est pas un runtime pour la logique métier.

Lorsqu'un sous-compte s'abonne à SAP Build Work Zone, un fournisseur de contenu HTML5 Apps apparaît automatiquement dans le Channel Manager. Il reflète les applications déployées dans le référentiel de ce sous-compte. Pour afficher une application sur un site :

1. Décrivez-la dans manifest.json : un ID d'application unique, un nom de business service (sap.cloud.service) et un inbound avec semantic object et action.
2. Déployez-la dans le même sous-compte que l'abonnement SAP Build Work Zone.
3. Mettez à jour le fournisseur de contenu HTML5 Apps dans le Channel Manager.
4. Ajoutez l'application dans le Content Explorer, puis affectez-la à des groupes, des catalogues et des rôles, et les rôles à un site.

Une erreur fréquente consiste à sauter l'étape 3 et à se demander pourquoi une nouvelle version n'apparaît pas. Le HTML5 Application Repository livre les fichiers, tandis que SAP Build Work Zone décide qui voit la tile.

Points forts

• Mises à jour sans interruption : le contenu change sans redémarrer l'application router.
• Livraison serverless : avec l'application router géré, une interface n'a besoin d'aucune instance d'application en cours d'exécution.
• Partage et gestion des versions : les applications publiques peuvent être consommées par des routers d'autres spaces, et le contenu peut être exploré par version.

Limites

• Contenu statique uniquement. Les services OData, la logique métier et les données résident ailleurs, par exemple dans CAP, RAP ou SAP S/4HANA.
• Limites documentées. SAP documente 100 Mo par instance app-host et des limites de débit par sous-compte pour les déploiements et les requêtes d'exécution.
• Pas de données personnelles. Comme le contenu peut être partagé, SAP déconseille d'y stocker des données personnelles.
• Périmètre du sous-compte. L'intégration à Work Zone suppose que les applications se trouvent dans le même sous-compte que l'abonnement.

Le HTML5 Application Repository indique où résident les fichiers SAPUI5 sur SAP BTP, pas comment fonctionne l'application qui les utilise.

SAP propose désormais aussi Application Frontend service, qui héberge et sert des applications front-end via un point d'entrée unique, avec sa propre CLI, une interface dans le cockpit et plusieurs versions actives. SAP le positionne pour les nouvelles applications autonomes et single-tenant qui ne se connectent pas à d'autres applications, et précise qu'une utilisation productive nécessite une licence SAP Build.

SAP indique que les équipes dont les besoins sont couverts par le HTML5 Application Repository et l'application router peuvent continuer à les utiliser. Les applications déployées avec Application Frontend service peuvent également être ajoutées à SAP Build Work Zone, standard et advanced edition, soit manuellement comme applications URL, soit via une configuration Common Data Model.