SAP Fiori Elements

SAP Fiori elements déplace les décisions d'interface du code vers les métadonnées :

1. Un service OData expose les entités métier, par exemple les commandes d'achat et leurs postes.
2. Les annotations décrivent comment l'interface doit les présenter : UI.SelectionFields pour les champs de filtre, UI.LineItem pour les colonnes de tableau, UI.HeaderInfo pour les titres d'objet, UI.Facets pour les sections de l'object page.
3. L'app descriptor (manifest.json) sélectionne un template de floorplan pour chaque page et définit des options telles que le chargement initial ou le mass edit.
4. À l'exécution, le framework lit les métadonnées, les annotations et le descriptor, puis construit les pages, y compris la barre de filtres, les variantes, les tableaux, les formulaires, les messages et la navigation.
5. Lorsque la page générée ne suffit pas, les développeurs ajoutent des extensions au lieu de réécrire la page.

L'essentiel du travail du développeur porte donc sur le service et ses annotations, pas sur le JavaScript. SAP Fiori elements transforme un service bien annoté en application fonctionnelle, et un service mal annoté en application médiocre.

OData V4 ajoute les building blocks et les custom pages, ce qui permet aux développeurs de combiner des éléments standard avec leur propre code SAPUI5 au sein de la même application. Le list report associé à l'object page est la combinaison classique, souvent abrégée LROP. Choisir un floorplan dans SAP Fiori elements, c'est choisir un modèle d'interaction, pas un template visuel.

SAP recommande SAP Fiori elements for OData V4 pour les nouvelles applications et indique que la variante OData V2 reste entièrement prise en charge. En pratique, le choix dépend de trois facteurs :

• Back-end : les service bindings RAP peuvent publier un service UI en OData V2 ou V4, et CAP sert OData V4 par défaut. Les services construits dans SEGW sont généralement en OData V2.
• Besoins d'extension : les building blocks et le flexible programming model ne sont disponibles qu'avec OData V4.
• Applications existantes : une application qui fonctionne en V2 n'a pas besoin d'être migrée pour continuer à tourner ; les paramètres de configuration diffèrent entre les deux, par exemple initialLoad en V4 contre loadDataOnAppLaunch en V2.

Pour une nouvelle application spécifique sur un back-end SAP S/4HANA ou SAP BTP actuel, OData V4 est le choix par défaut dans SAP Fiori elements, et V2 le choix pragmatique lorsque le service existe déjà.

SAP Fiori elements convient lorsque la tâche suit un modèle standard : rechercher dans une liste, ouvrir un objet, le modifier, exécuter des actions. Le framework fournit barres de filtres, gestion des variantes, tableaux, drafts, messages, accessibilité et prise en charge de la traduction sans code spécifique, et SAP maintient ces fonctions à jour au fil des releases SAPUI5.

Le SAPUI5 freestyle convient lorsque l'interaction elle-même est inhabituelle : un tableau de planification, un parcours de scan guidé, une mise en page très visuelle ou des données provenant de sources autres qu'OData. Le code freestyle donne un contrôle total et une responsabilité totale de la maintenance.

Les propres recommandations de SAP présentent les deux approches comme combinables plutôt qu'exclusives : partir de SAP Fiori elements, utiliser les building blocks et n'écrire du code freestyle que pour combler les lacunes. Un test de décision utile consiste à savoir si les parties prenantes peuvent accepter la mise en page du floorplan, au moins pour les écrans principaux. SAP Fiori elements est le meilleur choix chaque fois que le besoin porte sur un business object, et non sur une interaction sur mesure.

Les options d'extension dépendent de qui possède l'application :

• Votre propre application : les points d'extension permettent aux développeurs d'ajouter des colonnes, actions, sections, facettes d'en-tête et filtres personnalisés ; avec OData V4, le flexible programming model ajoute les building blocks et les custom pages.
• Une application livrée par SAP : les adaptation projects, créés avec SAP Fiori tools, modifient ou étendent l'application sans modifier le code de SAP ; l'adaptation key user permet aux key users de réorganiser ou de masquer des champs à l'exécution.
• Côté données : un nouveau champ commence généralement dans le service et ses annotations, pas dans l'interface.

La disponibilité varie selon l'édition : dans SAP S/4HANA Cloud Public Edition, vérifiez lesquelles de ces voies SAP prend en charge pour l'application concernée. Toute extension d'une application SAP Fiori elements devient du code ou de la configuration dont quelqu'un doit assumer la responsabilité au fil des mises à niveau.

1. Lutter contre le floorplan. De grandes quantités de code spécifique pour imposer une mise en page non standard annulent le bénéfice en maintenance ; à ce stade, le SAPUI5 freestyle est souvent plus honnête.
2. Le traiter comme du no-code. Les annotations sont du code sous une autre forme ; elles exigent revue, gestion de versions et tests.
3. Ignorer la gestion des drafts. Les scénarios d'édition sans service compatible draft perdent la reprise du travail, le verrouillage et les validations auxquels les utilisateurs s'attendent.
4. Ne pas examiner les valeurs par défaut. Le chargement initial, le mass edit et les types de tableaux ont des valeurs par défaut qui peuvent charger trop de données ou trop peu ; définissez-les délibérément.
5. Annoter à deux endroits. Les annotations peuvent se trouver dans les CDS du back-end et dans des fichiers d'annotations locaux ; les fichiers locaux remplacent les métadonnées du service, et le dernier fichier déclaré dans manifest.json l'emporte, si bien que les doublons rendent le comportement difficile à tracer.

La plupart des problèmes de SAP Fiori elements sont des problèmes de conception du service et des annotations qui ne deviennent visibles que dans l'interface.