List Report

Un list report convient lorsque les utilisateurs partent d'un ensemble large et ouvert de business objects et doivent le restreindre avant de pouvoir travailler : examiner les commandes à livrer, traiter un ensemble de commandes d'achat, repérer les documents bloqués au paiement ou répéter une sélection de fin de mois au moyen d'une variante enregistrée.

Le critère de décision est la forme de la recherche. Si les utilisateurs combinent plusieurs critères de filtre avant que la liste prenne son sens, un list report convient. Si les éléments sont déjà connus et peu nombreux, une worklist est plus légère. Si les utilisateurs doivent analyser à l'aide de graphiques avant d'agir, l'analytical list page convient mieux.

Exemple : les acheteurs d'Alder Manufacturing filtrent les commandes d'achat par fournisseur et par date de livraison pour trouver les commandes en retard de Cedar Office Supply, puis ouvrent chacune d'elles sur son object page. Un list report est le bon choix lorsque le filtrage est la première étape de la tâche.

Une page list report est assemblée à partir de composants standard, de haut en bas :

1. Titre et gestion des variantes : un contrôle de vues dans lequel les utilisateurs enregistrent les valeurs de filtre, l'ordre de tri et les colonnes.
2. Barre d'outils de l'en-tête : des actions génériques de page, dont un menu Share.
3. Barre de filtres : les champs de UI.SelectionFields ainsi que tous les champs de filtre obligatoires. La recherche s'exécute lorsque l'utilisateur choisit Go, sauf si le mode live est configuré.
4. Zone de contenu : un tableau, un graphique ou les deux, éventuellement sous forme de plusieurs vues que l'on bascule par un bouton segmenté ou par des onglets.
5. Navigation : choisir une ligne ouvre l'object page, éventuellement côte à côte dans le flexible column layout.

Avec un service compatible draft, le framework ajoute un filtre Editing Status et indique quelles lignes ont un draft ou sont verrouillées par un autre utilisateur. Chaque composant d'un list report est généré à partir des métadonnées : les list reports se comportent donc de la même manière d'une application à l'autre.

En ABAP CDS, les deux premières apparaissent sous la forme @UI.selectionField et @UI.lineItem sur chaque élément ; CAP utilise les noms de termes OData. Le comportement de la page, comme le chargement initial, la modification en masse, les vues et le type de tableau, est défini dans manifest.json. Les annotations décident de ce qu'un list report affiche ; l'app descriptor décide de la manière dont il se comporte.

Chargement initial. Lorsque l'application démarre avec un contexte de navigation, comme des paramètres provenant d'une autre application ou du target mapping, les données se chargent immédiatement. Sinon, la variante par défaut de l'utilisateur décide via son paramètre Apply Automatically ; seule la variante Standard suit manifest.json :

Les utilisateurs peuvent remplacer ce paramètre pour chaque vue. SAP recommande des valeurs de filtre par défaut pour que la page ne s'ouvre pas vide.

La modification en masse (mass edit) reste désactivée tant qu'un développeur ne l'active pas. En OData V4, enableMassEdit fonctionne sur le list report (pour les enregistrements actifs sans draft en cours) et sur l'object page en mode modification ; visibleFields ou ignoredFields limitent la boîte de dialogue. En OData V2, multiEdit ne fonctionne que sur le list report, pour les tables responsive et grid. Ces deux comportements du list report sont des choix de configuration délibérés, et non des valeurs par défaut à accepter sans examen.

Oui, et les options dépendent du propriétaire de l'application :

• Votre propre application, OData V4 : les points d'extension ajoutent des colonnes, des actions et des champs de filtre personnalisés, du contenu d'en-tête au-dessus de la barre de filtres et des vues personnalisées sous forme d'onglets supplémentaires ; les building blocks et les pages personnalisées du flexible programming model couvrent les manques plus importants.
• Votre propre application, OData V2 : les extensions enregistrées dans manifest.json couvrent des zones comparables, comme les colonnes, les actions et les filtres.
• Une application livrée par SAP : projets d'adaptation (SAP Fiori tools) ou adaptation key user, sans modifier le code de SAP.

Dans SAP S/4HANA Cloud Public Edition, vérifiez lesquelles de ces voies SAP prend en charge pour l'application et la release. Test de décision : si du code personnalisé est nécessaire au-delà de quelques colonnes, actions ou filtres, réexaminez le choix du floorplan. Étendre un list report coûte peu en périphérie et cher au cœur.

1. Tout charger au lancement. Charger systématiquement un très grand entity set ralentit chaque démarrage ; les valeurs de filtre par défaut sont un meilleur levier.
2. S'ouvrir sur un tableau vide sans explication. Lorsque les utilisateurs signalent « aucune donnée », vérifiez dans l'ordre : le contexte de navigation, la variante par défaut et son indicateur Apply Automatically, le paramètre du manifest, puis les filtres obligatoires (en OData V2, un filtre obligatoire vide bloque le chargement initial).
3. Surcharger la barre de filtres. Vingt champs de sélection masquent les trois qui comptent.
4. Confondre variantes et vues. Les variantes sont enregistrées par les utilisateurs ; les vues multiples sont des onglets définis par les développeurs.
5. Activer la modification en masse pour tous les champs. Limitez la boîte de dialogue à un groupe de champs qui peut être modifié en masse sans risque.
6. Utiliser un list report pour une file de travail. Un ensemble de tâches court et connu convient à une worklist.

La plupart des problèmes de list report sont des problèmes de configuration et de conception de la sélection plutôt que des défauts du framework.