Object Page

L'object page convient chaque fois que la tâche porte sur un seul business object : modifier une commande client et ses postes, créer une commande d'achat sous forme de draft, libérer une facture bloquée ou comparer un draft avec la version enregistrée. Ce floorplan s'adapte aussi bien à quelques champs qu'à des objets complexes comportant de nombreuses sections et des tableaux associés.

Deux critères de décision aident :

• Si les utilisateurs ont d'abord besoin de contexte, comme le statut de l'objet, ses chiffres clés et les éléments associés, l'object page standard convient.
• Si les utilisateurs ne font que saisir des données et n'ont besoin ni d'en-tête ni de navigation entre sections, la form entry object page, une variante qui masque les deux, est plus légère.

Exemple : un acheteur d'Alder Manufacturing ouvre une commande d'achat pour Bright Freight, vérifie les informations de l'en-tête, puis modifie deux postes. L'object page convient lorsque la question est « qu'en est-il de cet objet précis ? »

L'object page se compose de cinq zones, de haut en bas :

1. Titre de l'en-tête : le titre et le sous-titre de l'objet, une image facultative, le statut d'édition lorsqu'un draft existe, et une barre d'outils avec des actions telles que Edit, Delete, Related Apps et Share.
2. Facettes d'en-tête : les informations clés sous forme de paires libellé-valeur ou de petits visuels comme un micro chart ou une notation. SAP recommande au maximum cinq paires libellé-valeur.
3. Barre de navigation : des ancres qui mènent à chaque section sur une seule page défilante, ou des onglets qui affichent une section à la fois.
4. Zone de contenu : des sections et sous-sections contenant des formulaires, des tableaux d'éléments associés, des graphiques ou des composants réutilisables.
5. Barre d'outils du pied de page : en mode édition, Save ou Create, les actions déterminantes et le bouton des messages.

Le choix d'une ligne dans un tableau de postes ouvre une subobject page pour l'entité enfant, avec des boutons de pagination pour passer d'un poste à l'autre. Chaque zone de l'object page répond à une question : de quoi s'agit-il, qu'est-ce qui compte, où cela se trouve-t-il, comment terminer.

En ABAP CDS, toutes ces facettes s'écrivent sous forme d'entrées @UI.facet avec un type, par exemple une référence à un field group ou une collection, et un purpose qui distingue les facettes d'en-tête des sections standard. Seuls deux niveaux de collection facets sont rendus. Le choix entre ancres et onglets est un paramètre du manifest.json, sectionLayout, avec Page comme valeur par défaut en OData V4. La structure de l'object page est donc définie presque entièrement dans UI.Facets.

Avec un service compatible draft, l'object page crée un draft dès qu'un utilisateur commence à modifier ou à créer. Le draft est enregistré en arrière-plan pendant que l'utilisateur travaille, ce qui produit quatre comportements :

• le travail non enregistré survit à une interruption ou à un plantage, et l'utilisateur peut le reprendre plus tard ;
• le draft fait office de verrou : les autres utilisateurs voient que l'objet est en cours de modification ;
• les validations et le contrôle des champs s'exécutent pendant la saisie, et pas seulement à la fin ;
• Save transforme le draft en version active.

SAP Fiori elements for OData V4 distingue les drafts exclusifs, détenus par un seul utilisateur, des drafts collaboratifs que plusieurs utilisateurs peuvent modifier ensemble ; SAP ne documente les drafts collaboratifs que pour les services basés sur RAP. RAP et CAP fournissent tous deux la gestion des drafts côté service. Sans draft, rien n'atteint le back-end avant que l'utilisateur n'enregistre, et SAP ne conseille les applications sans draft que pour des flux simples. La prise en charge des drafts est la décision de service qui façonne le plus l'expérience d'édition dans une object page.

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

• Votre propre application : des points d'extension ajoutent des sections et sous-sections personnalisées, des facettes d'en-tête, des éléments de formulaire, des actions et des colonnes de tableau ; des composants réutilisables peuvent être placés dans les sections ; avec OData V4, les building blocks et les custom pages du flexible programming model couvrent les besoins plus importants.
• Une application livrée par SAP : des adaptation projects (SAP Fiori tools) ou l'adaptation key user, sans modifier le code de SAP.

Dans SAP S/4HANA Cloud Public Edition, les voies disponibles suivent les modèles d'extensibilité de SAP propres à cette édition ; consultez la documentation d'extensibilité de votre release.

Les sections personnalisées ont un coût en performance. OData V4 propose des request groups et le lazy loading pour les object pages ; en OData V2, le lazy loading doit être activé pour chaque section personnalisée. Un test pratique : si la plupart des sections sont personnalisées, une custom page ou du SAPUI5 freestyle peut être plus honnête qu'une object page lourdement étendue.

1. Trop de sections sur une seule page défilante. Regroupez les sections ou passez aux onglets, que SAP recommande pour les grid tables.
2. Des en-têtes surchargés. Au-delà d'une poignée d'informations d'en-tête, l'en-tête devient un second formulaire.
3. Une imbrication de facettes trop profonde. Les collection facets au-delà du deuxième niveau sont ignorées, et une collection facet qui n'enveloppe qu'une seule reference facet peut mal s'afficher ; utilisez directement la reference facet.
4. Des virgules dans les titres de section. SAP Fiori elements utilise les virgules comme séparateurs lorsqu'il regroupe les messages ; évitez-les donc dans les titres de sections et de sous-sections.
5. Une édition sans draft. Les utilisateurs perdent la reprise du travail et l'information de verrouillage.

Lorsqu'une section manque, vérifiez dans l'ordre : l'annotation UI.Facets dans les métadonnées du service, le niveau de la facette, son qualifier cible, toute condition UI.Hidden, et un fichier d'annotations local qui pourrait remplacer l'UI.Facets du back-end. La plupart des défauts d'object page sont des problèmes de structure des facettes, pas des bugs de rendu.