Flexible Programming Model

Le flexible programming model n'est pas un framework distinct, mais un ensemble d'options que SAP Fiori elements pour OData V4 propose pour aller au-delà des floorplans tout en laissant le framework aux commandes :

1. Les points d'extension des list reports et des object pages acceptent des sections, des colonnes et des actions personnalisées écrites en SAPUI5.
2. Les building blocks placent des éléments pilotés par les métadonnées, tels qu'un tableau, une barre de filtres ou un champ, là où c'est nécessaire.
3. Les extensions de contrôleur et l'ExtensionAPI permettent au code personnalisé de réagir aux événements du framework, tels que la sauvegarde ou la navigation.
4. Les pages personnalisées (custom pages) ajoutent au routage de l'application une page dotée de sa propre vue XML. La page s'exécute sur le runtime SAP Fiori elements (composant sap.fe.core.fpm), avec le contexte de binding OData, la navigation vers les pages standard et la prise en charge des building blocks.

Le flexible programming model est donc une échelle graduée entre interface générée et interface écrite à la main, décidée page par page et section par section.

Les building blocks sont des éléments d'interface réutilisables et pilotés par les annotations de SAP Fiori elements pour OData V4, les mêmes éléments que le framework utilise pour assembler ses floorplans.

• Non pas des contrôles, mais des modèles. Un building block est un ensemble d'instructions de templating. À l'exécution, il produit des contrôles adaptés aux données liées : un texte pour une propriété de type chaîne, un sélecteur de date pour une date.
• Configurés à trois endroits. Les annotations du service définissent le comportement par défaut, les attributs XML en ligne l'affinent, et le manifest prévaut sur les deux en cas de conflit.
• Référencés par chemin de métadonnées. Un building block pointe vers un entity set, une propriété ou une annotation au lieu de lier des colonnes à la main.
• Exemples : Table, FilterBar, Chart, Field, Share et Page.

Comme ils lisent les mêmes annotations que les floorplans, les building blocks héritent de la gestion des variantes, de la personnalisation et de la prise en compte du draft. Les building blocks sont la raison pour laquelle une page personnalisée peut encore ressembler à une page SAP Fiori elements standard et se comporter comme elle.

La recommandation de SAP est d'utiliser autant de SAP Fiori elements que possible et autant de SAPUI5 freestyle que nécessaire :

Les quatre peuvent coexister dans une même application : un cockpit fournisseurs chez Alder Manufacturing pourrait combiner un graphique personnalisé avec un building block Table standard, puis ouvrir une object page standard.

Test de décision : si une page que vous prévoyez de construire en freestyle contient une barre de filtres et un tableau standard, essayez d'abord une page personnalisée avec des building blocks. Le flexible programming model est le bon choix lorsque la mise en page est personnalisée mais que les composants sont standard.

• Pas de choix rigide. Les équipes n'ont pas à abandonner SAP Fiori elements dès qu'une exigence sort du cadre d'un floorplan.
• Comportement standard fourni d'office. Les building blocks apportent depuis le framework le filtrage, les variantes, les messages, la gestion des drafts et l'accessibilité.
• Les annotations restent la source de vérité. Un libellé modifié dans les annotations du service met à jour aussi bien les pages de floorplan que les pages personnalisées.
• Surface d'extension prise en charge. Les extensions de contrôleur et l'ExtensionAPI offrent au code personnalisé des points d'ancrage documentés, plus faciles à maintenir stables lors des mises à niveau SAPUI5.

Pour les applications OData V4, le flexible programming model est le moyen le plus direct d'ajouter une interface personnalisée sans renoncer à ce que SAP Fiori elements fournit déjà.

• OData V4 uniquement. Les building blocks et les pages personnalisées relèvent de SAP Fiori elements pour OData V4. Une application OData V2 conserve les points d'extension V2 ; adopter le modèle implique de faire passer l'application et le service en V4.
• Dépendant de la version. Les building blocks arrivent release après release : une application ne peut donc utiliser que ce que propose la version SAPUI5 du système cible ; l'API Reference indique la release dans laquelle chaque building block est devenu disponible.
• Toutes les fonctionnalités des floorplans ne sont pas reprises. SAP documente par exemple que la création d'une card pour la section Insights de My Home n'est pas disponible lorsque le building block Table se trouve dans une page personnalisée ou une section personnalisée.
• L'usage en freestyle a des prérequis. Les building blocks peuvent figurer dans des applications SAPUI5 freestyle, mais la configuration requise par chaque building block doit être vérifiée dans la documentation SAPUI5 de la release utilisée.
• SAP S/4HANA Cloud Public Edition suit ses propres règles d'extensibilité pour les applications développées par les clients ; consultez la documentation de cette édition avant d'en planifier une.

Le flexible programming model élargit ce que SAP Fiori elements peut faire ; il ne supprime pas la dépendance à OData V4 et à des annotations bien conçues.

1. Reconstruire à la main des éléments standard. Un tableau personnalisé doté de sa propre logique de filtrage duplique les building blocks Table et FilterBar. Configurez plutôt le building block.
2. Configurer à trois endroits. Lorsque les annotations, les attributs XML et les paramètres du manifest décrivent le même tableau, le manifest l'emporte et les autres semblent défaillants. Choisissez un seul endroit par paramètre.
3. Charger les fragments de la mauvaise manière. SAP exige que les fragments chargés dynamiquement qui contiennent des building blocks soient chargés via la méthode loadFragment de l'ExtensionAPI.
4. Corriger l'interface au lieu du service. Un libellé manquant est généralement un problème d'annotation ; le corriger dans du code personnalisé le masque pour toutes les autres pages.
5. Ignorer la version SAPUI5 de la production. Des building blocks testés sur la release la plus récente peuvent être absents du serveur front-end.

La plupart des problèmes liés au flexible programming model sont des erreurs de configuration ou de répartition entre couches, et non des limites du modèle lui-même.