Overview Page (OVP)

L'overview page convient au suivi et à la prise de décision pour un domaine d'activité, comme les achats ou les ventes, lorsque les informations proviennent de plusieurs entités et que l'utilisateur a besoin d'une lecture rapide avant d'agir ailleurs.

Critères de décision :

• Un seul jeu de données que les utilisateurs analysent en profondeur, puis sur lequel ils agissent : une analytical list page.
• Plusieurs jeux de données qu'un rôle parcourt à la recherche d'exceptions, puis qu'il approfondit : une overview page.
• Une page d'accueil personnelle couvrant tout le travail d'un utilisateur : My Home, la page d'entrée du launchpad dans SAP S/4HANA.
• Une recherche sur de nombreux objets : un list report.

Exemple : le responsable des achats d'Alder Manufacturing ouvre une overview page avec quatre cards : les demandes d'achat en attente d'approbation, la valeur des commandes par fournisseur, les livraisons en retard de Bright Freight et des liens rapides vers les applications d'achat. Chaque card ouvre l'application où le travail se fait. La Procurement Overview Page (F1990) de SAP suit ce modèle. L'overview page est le bon choix lorsqu'un rôle a d'abord besoin d'une vue d'ensemble, et du détail un clic plus loin.

L'overview page a une structure simple :

1. En-tête : le titre du domaine métier couvert par la page, avec un menu utilisateur qui permet notamment de gérer les cards affichées.
2. Barre de filtres (facultative) : des filtres au niveau de l'application, comme un code société ou une plage de dates, qui s'appliquent à toutes les cards dont l'entité partage la propriété filtrée.
3. Cards en grille : des colonnes responsives, jusqu'à cinq selon la largeur de l'écran, que les utilisateurs peuvent réorganiser par glisser-déposer.

Chaque card comporte deux zones. L'en-tête de la card porte un titre obligatoire, un sous-titre facultatif et un compteur indiquant combien d'enregistrements la card affiche sur le total correspondant au filtre en cours ; il peut aussi porter une valeur de KPI avec sa tendance, ce qui exige un service qui agrège. La zone de contenu affiche une liste, un tableau, des liens ou un graphique. Un clic sur une card ou sur l'un de ses éléments déclenche une navigation, généralement via la navigation basée sur les intents, vers l'application qui gère le détail. C'est la card, et non la page, qui constitue l'unité de travail d'une overview page.

Chaque card est liée à un seul entity set. UI.SelectionVariant et UI.PresentationVariant restreignent et trient ce qu'affiche une card, UI.Identification contient les actions de la card, et UI.KPI configure les en-têtes de KPI. Les développeurs peuvent aussi créer des cards personnalisées. Les cards d'overview page sont des composants de ce floorplan pilotés par les annotations ; les UI integration cards sont une technologie de card déclarative distincte, conçue pour être réutilisée dans plusieurs hôtes. Bien choisir les types de cards représente l'essentiel du travail de conception d'une overview page.

Tous les paramètres se trouvent dans la section sap.ovp du manifest.json, à deux niveaux :

• Niveau page : le modèle et l'entity set du filtre global, la disposition du conteneur (une disposition redimensionnable permet aux utilisateurs de redimensionner les cards), le chargement des données au lancement et le rafraîchissement automatique, dont l'intervalle minimal et par défaut est d'une minute.
• Niveau card : pour chaque card, le template, l'entity set, les chemins d'annotation pour les line items, les graphiques, la sélection, la présentation et le KPI, ainsi que les paramètres de navigation.

L'overview page accepte les services OData V2 et V4, y compris au sein d'une même page. SAP précise que ses principes d'interface viennent d'OData V2, qu'elle utilise toujours des smart controls et que seul le building block FilterBar est utilisé ; la documentation complète se trouve donc dans la section V2 du SDK. Les utilisateurs peuvent réorganiser, masquer, afficher, redimensionner et filtrer les cards, et les cards déplacées conservent leur position. Le flexible column layout ne s'applique pas aux overview pages. Dans SAP S/4HANA Cloud Public Edition, les overview pages personnalisées dépendent des options d'extensibilité disponibles dans cette édition ; consultez donc la documentation d'extensibilité de votre release. Configurer une overview page consiste surtout à sélectionner les bonnes cards, pas à construire des écrans.

1. Des cards qui ne mènent nulle part. Une card sans navigation montre un problème, mais pas le moyen de le résoudre.
2. Trop de cards. Vingt cards transforment une vue d'ensemble en défilement ; gardez celles qu'un rôle consulte chaque jour.
3. Ignorer les autorisations. Sans le paramètre de card requireAppAuthorization, les utilisateurs peuvent voir une card puis se heurter à une erreur d'accès lors de la navigation. Avec ce paramètre, la card n'apparaît que si l'utilisateur est autorisé à ouvrir l'intent cible.
4. Des en-têtes de KPI sur des services qui n'agrègent pas. Les valeurs de KPI exigent une agrégation dans le back-end.
5. Dupliquer des applications existantes. Une card qui reproduit un list report complet incite les utilisateurs à travailler dans la card plutôt que dans l'application.

Lorsqu'une card est absente ou vide, vérifiez dans l'ordre : si l'utilisateur l'a masquée dans Manage Cards, l'intent requireAppAuthorization et les rôles de l'utilisateur, la variante de sélection de la card, les valeurs du filtre global, puis l'autorisation sur l'entity set de la card. La plupart des problèmes d'overview page viennent de la sélection des cards et des autorisations, pas du framework.