Analytical List Page (ALP)

Une analytical list page convient lorsque les utilisateurs doivent voir une tendance avant de savoir sur quels postes agir. Le graphique répond à « où est le problème ? », et le tableau en dessous répond à « quels documents ? ».

• Si les utilisateurs connaissent déjà leur sélection et n'ont besoin que de lignes, un list report est plus simple.
• Si les utilisateurs ont besoin d'un graphique, de filtres et des postes sur une même page, utilisez une analytical list page.
• Si un rôle a besoin d'une synthèse de plusieurs sujets, une overview page convient mieux.
• Si l'objectif est de suivre un KPI gouverné depuis le launchpad, une application KPI SAP Smart Business est l'option la plus proche.

Exemple : un responsable des achats d'Alder Manufacturing sélectionne la barre Bright Freight dans un graphique de la valeur des commandes par fournisseur et ouvre les postes en retard dans le tableau ainsi restreint. L'application Monitor Purchase Order Items (F2358) de SAP suit ce modèle. Une analytical list page est le bon choix lorsque l'analyse et l'action relèvent de la même tâche.

Une analytical list page se compose de quatre zones, de haut en bas :

1. En-tête : le titre de la page, les variantes de page et, en option, des tags KPI : de courts libellés cliquables affichant une valeur de KPI, qui ouvrent une card de KPI.
2. Barre de filtres visuels : de petits graphiques, un par champ de filtre, chacun montrant une mesure par valeur de dimension. Choisir une barre ou un point définit le filtre. Une barre de filtres compacte, composée de champs classiques, constitue le mode alternatif, maintenu synchronisé.
3. Graphique principal : un graphique interactif des données filtrées. Sélectionner un segment du graphique restreint le tableau.
4. Tableau : les postes sous-jacents, avec des actions et la navigation vers une object page ou une autre application.

La zone de contenu affiche le graphique, le tableau ou les deux (la vue hybride). La caractéristique distinctive d'une analytical list page est que le graphique et le tableau partagent un même état de filtre, si bien que chaque sélection affine les deux.

En OData V2, l'analytical list page dispose de son propre modèle et ne fonctionne qu'avec des services analytiques ; defaultContentView et defaultFilterMode définissent la vue et le mode de filtre de départ. En OData V4, un list report reçoit un paramètre views avec un chemin principal pour le graphique, un chemin secondaire pour le tableau et un defaultPath. Si un chemin configuré n'existe pas, l'application V4 ne se charge pas. Une analytical list page ne vaut donc que ce que vaut le modèle analytique qui la sous-tend.

Un filtre visuel est un champ de filtre représenté sous forme de graphique, construit sur l'aide à la saisie du champ :

1. L'annotation ValueList du champ référence une variante de présentation.
2. Le filtre visuel n'utilise que la première mesure et la première dimension de son premier graphique.
3. Le type de graphique détermine ce qui est affiché : un graphique à barres montre les trois valeurs les plus hautes ou les plus basses ; un graphique linéaire montre les six premiers ou les six derniers points de données et nécessite une dimension de date ou d'heure ; OData V2 propose aussi un graphique en anneau.
4. La sélection de l'utilisateur devient une valeur de filtre, qui apparaît aussi dans la barre de filtres compacte.

L'aide à la saisie qui sous-tend le filtre visuel doit renvoyer les mêmes enregistrements que celle du champ de filtre classique, sinon les sélections cessent de se synchroniser. SAP documente les filtres visuels en OData V4 comme pris en charge avec des restrictions ; par exemple, seuls les graphiques à barres et linéaires sont rendus, et seules la première mesure et la première dimension de l'annotation de graphique sont utilisées. Les filtres visuels rendent l'exploration d'une analytical list page rapide, au prix d'une modélisation supplémentaire pour chaque champ de filtre.

Oui, selon la version OData et le propriétaire de l'application :

• OData V2, votre propre application : l'analytical list page dispose de ses propres extensions d'application : actions personnalisées sur le tableau et le graphique, filtres personnalisés pour la barre de filtres compacte et les tags KPI, et une API d'actualisation.
• OData V4, votre propre application : l'analytical list page est une variante du list report ; partez donc des options d'extension du list report et vérifiez dans le SDK SAPUI5 lesquelles la variante ALP prend en charge.
• Une application livrée par SAP : projets d'adaptation ou adaptation key user, sans modifier le code de SAP ; dans SAP S/4HANA Cloud Public Edition, n'utilisez que les options d'extensibilité que SAP documente pour cette édition.

Deux comportements intégrés comptent. Dans le flexible column layout, l'analytical list page ne prend en charge que la disposition à deux colonnes avec la première colonne développée. Lorsque My Home est activé, les utilisateurs peuvent transformer le graphique en Insights card, sauf si les développeurs masquent cette option. Les extensions d'une analytical list page doivent rester en périphérie, car l'interaction entre graphique et tableau est la partie que les utilisateurs apprécient.

1. Construire sur un service sans agrégation. Les graphiques nécessitent un entity set qui prend en charge l'agrégation ; un service purement transactionnel ne peut pas les alimenter.
2. Chemins d'annotation mal saisis. En OData V4, un chemin principal ou secondaire erroné empêche l'application de se charger.
3. Aides à la saisie divergentes. Lorsque le filtre visuel et le filtre classique lisent des enregistrements différents, les sélections se désynchronisent.
4. Filtres visuels en graphique linéaire sur des dimensions qui ne sont pas des dates. Ils ne sont pas rendus ; utilisez un graphique à barres.
5. Des tags KPI qui contredisent les tiles de KPI. Des requêtes différentes derrière un même nom de KPI produisent des chiffres différents.

Lorsque le graphique principal est vide, vérifiez dans l'ordre : la prise en charge de l'agrégation sur l'entity set, le chemin du graphique dans manifest.json, un UI.Chart par défaut sans qualificateur, puis les filtres et les autorisations de l'utilisateur. La plupart des défauts d'une analytical list page sont des défauts de modèle de données et d'annotations qui se manifestent dans le graphique.