App Descriptor (manifest.json)

L'app descriptor regroupe ses attributs en namespaces, chacun relevant d'un consommateur différent :

Un _version au niveau racine indique le schéma de manifest que suit le fichier. L'ID sap.app doit correspondre au namespace du composant dans Component.js, ne peut pas dépasser 70 caractères et doit être unique dans le système. L'app descriptor est donc l'endroit unique où sont déclarés l'identité d'une application, ses connexions aux données et son contrat de navigation.

Le launchpad s'intéresse surtout à sap.app → crossNavigation :

• Les inbounds déclarent les intents que l'application accepte : un semantic object et une action, un titre et une icône de tile facultatifs, les types d'appareils, une signature de paramètres avec valeurs requises et valeurs par défaut, et une règle pour les paramètres supplémentaires (autorisés, ignorés ou non autorisés).
• Les outbounds déclarent les intents que l'application déclenche elle-même lorsqu'elle navigue vers d'autres applications.

La suite dépend de la plateforme :

1. SAP BTP et SAP Build Work Zone : l'application est déployée avec son descriptor, par exemple dans le HTML5 Application Repository, et le site utilise les inbounds comme target mappings.
2. Launchpad ABAP (SAP S/4HANA on-premise et Private Edition) : le target mapping d'un technical catalog, créé avec le launchpad app manager (/UI2/FLPAM), référence l'ID sap.app de l'application. Le SAPUI5 application index, construit par /UI5/APP_INDEX_CALCULATE, lit les descriptors des applications déployées.
3. SAP S/4HANA Cloud Public Edition : les applications livrées par SAP comportent des descriptors comme toute application SAPUI5 ; les applications spécifiques sont déployées dans le SAPUI5 ABAP repository du tenant de développement, avec leur tile définie dans l'application, et un administrateur accorde l'accès via un business role.

L'application alder.mm.supplierrating d'Alder Manufacturing, avec un inbound d'illustration Supplier-rate, ne s'ouvre que si une tile déclenche exactement cet intent. L'app descriptor publie le contrat de navigation ; le contenu du launchpad décide qui peut l'utiliser.

Le schéma du manifest évolue avec SAPUI5. Chaque version de schéma est comprise par une version SAPUI5 correspondante, et le SDK SAPUI5 publie cette correspondance, par exemple le schéma 1.60.0 pour SAPUI5 1.120 et versions ultérieures.

À partir de SAPUI5 1.136, une nouvelle version majeure 2 du manifest est disponible. Elle suit les bonnes pratiques actuelles et supprime des fonctionnalités que les versions précédentes avaient seulement déclarées obsolètes ; y passer est donc une migration, pas un simple changement de numéro. Le SDK liste les modifications nécessaires, et le UI5 linter signale les configurations de manifest obsolètes.

Deux paramètres liés sont souvent confondus :

• _version décrit le schéma dans lequel le fichier est écrit.
• sap.ui5 → dependencies → minUI5Version indique la version SAPUI5 la plus basse dont l'application a besoin.

Critère de décision : fixez minUI5Version à la version SAPUI5 la plus basse parmi les systèmes sur lesquels l'application s'exécutera, et choisissez une version de schéma que cette version comprend. Un décalage entre le schéma de l'app descriptor et le runtime est une source fréquente de fonctionnalités qui, sans le signaler, ne font rien.

• SAP Fiori elements : le descriptor sélectionne le floorplan de chaque page via ses cibles de routage et porte les paramètres de page, comme le chargement initial, la gestion des variantes ou le type de table. Les annotations décrivent les données ; le descriptor décrit l'application.
• Variantes d'application : un projet d'adaptation ne modifie pas le fichier d'origine. Il crée une variante avec son propre fichier de modifications du descriptor (manifest.appdescr_variant), dans lequel l'ID sap.app est l'ID de la variante et sap.ui5 → componentName pointe vers l'application de base. L'application d'origine reste intacte et continue de recevoir les mises à jour SAP.
• Adaptation key user : flexEnabled indique que l'application est activée pour la flexibilité SAPUI5, sur laquelle repose l'adaptation de l'interface à l'exécution.

SAP considère le descriptor comme étant en lecture seule après livraison ; c'est pourquoi les modifications des applications livrées par SAP passent par des variantes et des modifications de flexibilité. L'app descriptor est l'ancrage auquel se réfèrent les extensions, pas un fichier à corriger.

Effectuez ces vérifications lorsqu'une application ne démarre pas ou ne navigue pas comme prévu :

1. ID incohérent. L'ID sap.app diffère du namespace de Component.js : le composant est introuvable.
2. ID en double ou trop long. Les contrôles de cohérence du SAPUI5 application index signalent les IDs en double et les IDs de plus de 70 caractères.
3. L'inbound ne correspond pas à la tile. Le semantic object, l'action ou la signature de paramètres diffère de l'intent que déclenche la tile ; une règle « not allowed » pour les paramètres supplémentaires rejette les paramètres en trop. Sur le launchpad ABAP, /UI2/FLIA montre comment l'intent a été résolu.
4. Type d'appareil désactivé. L'inbound ou sap.ui exclut les téléphones : l'application ne fonctionne que sur desktop.
5. Mauvaise source de données. L'URI de dataSources pointe vers un chemin de service qui n'existe pas dans le système cible ou qui n'y est pas routé.
6. Index obsolète. Une application modifiée n'est pas encore connue du SAPUI5 application index. Le déploiement depuis SAP Business Application Studio le met à jour automatiquement ; les SAP Notes, support packages, mises à niveau et certains imports de transports nécessitent /UI5/APP_INDEX_CALCULATE.

La plupart des problèmes d'app descriptor sont des incohérences de contrat entre le fichier, le contenu du launchpad et le back-end, pas des erreurs de syntaxe.