Worklist

La worklist convient lorsque l'ensemble des éléments est déjà défini par la tâche et que le rôle de l'utilisateur consiste à le traiter : demandes d'achat en attente d'un acheteur, documents auxquels il manque un champ, livraisons à confirmer. Le traitement consiste généralement à ouvrir un élément, à l'examiner, puis à le terminer ou à le transmettre.

Le critère de décision est l'endroit où se situe l'effort de sélection :

• Si les utilisateurs doivent combiner plusieurs critères avant que la liste ait du sens, utilisez un list report.
• Si la liste est prédéfinie et que les utilisateurs agissent surtout sur elle, utilisez une worklist.
• Si les éléments sont des tâches de workflow acheminées vers l'utilisateur par un moteur de workflow, My Inbox fournit déjà la boîte de réception, avec les décisions, le transfert et la suppléance.

Exemple : l'équipe achats d'Alder Manufacturing ouvre une worklist de demandes d'achat, triées en onglets par statut, et traite une à une les demandes ouvertes de Cedar Office Supply et de Bright Freight. La worklist est le bon choix lorsque le traitement, et non la recherche, constitue la première étape de la tâche.

Une page worklist comporte quatre zones, de haut en bas :

1. Titre de l'en-tête : le nom de la file de travail, sans l'en-tête chargé de variantes d'un list report.
2. Onglets par statut : des vues facultatives, définies par les développeurs, qui répartissent les éléments en groupes tels que ouverts, en cours et terminés. Chaque onglet peut afficher le nombre d'éléments qu'il contient.
3. Champ de recherche : une recherche en texte libre dans la barre d'outils du tableau, qui remplace la barre de filtres.
4. Tableau : les éléments eux-mêmes, avec des actions dans la barre d'outils ou sur chaque ligne et une navigation vers une object page pour le détail.

Dans SAP Fiori elements for OData V2, la worklist utilise par défaut un responsive table, affiche le nombre de lignes dans le titre du tableau et masque la gestion des variantes, sauf si le développeur l'active. La worklist V2 ne propose pas non plus d'export vers un tableur. La worklist renonce à la barre de filtres au profit d'une page plus épurée qui met en avant les éléments et leurs actions.

La configuration diffère entre les deux variantes de SAP Fiori elements :

Les onglets de statut sont des vues multiples. Les développeurs les définissent avec des annotations UI.SelectionVariant ou UI.SelectionPresentationVariant et les déclarent dans manifest.json. En V4, le multiple table mode affiche une icon tab bar, et l'option showCounts, désactivée par défaut, ajoute le nombre d'éléments à chaque onglet. Les colonnes du tableau proviennent d'UI.LineItem, et chaque onglet peut pointer vers son propre line item via une presentation variant. Configurer une worklist revient donc pour l'essentiel à configurer un list report sans barre de filtres.

Oui. SAP documente la worklist comme un list report simplifié ; les options du list report s'appliquent donc :

• Votre propre application : les points d'extension ajoutent des colonnes, des actions et des vues personnalisées ; en OData V4, les building blocks et les custom pages du flexible programming model couvrent les besoins plus importants. Des vues personnalisées peuvent aussi être ajoutées comme onglets supplémentaires au moyen d'une controller extension.
• Une application livrée par SAP : les adaptation projects créés avec SAP Fiori tools, ou l'adaptation key user, modifient l'application 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 concernée.

Une limite pratique : dès que les utilisateurs demandent plusieurs champs de filtre, le besoin est devenu un list report, et réactiver la barre de filtres est plus honnête que de construire des filtres personnalisés autour d'une worklist. Étendre une worklist fonctionne bien pour les actions et les colonnes, moins bien pour la recherche.

1. Utiliser une worklist pour une recherche ouverte. Sans barre de filtres, les utilisateurs font défiler et recherchent au lieu de sélectionner ; un list report convient mieux.
2. La faire pointer vers un entity set volumineux. Une barre de filtres masquée signifie que le contenu se charge au démarrage ; les variantes de sélection des onglets doivent donc déjà restreindre les données.
3. Des onglets qui se chevauchent. Si un élément peut apparaître dans deux onglets de statut, les compteurs ne s'additionnent plus et les utilisateurs perdent confiance dans la file.
4. Attendre des compteurs en temps réel. En OData V4, l'actualisation du compteur d'un onglet via un side effect global ne fonctionne que pour une vue que l'utilisateur a déjà ouverte ; prévoyez donc comment les compteurs se mettent à jour après les actions.
5. Reconstruire My Inbox. Modéliser des approbations de workflow sous forme de worklist spécifique duplique le transfert, la suppléance et la gestion des tâches que My Inbox fournit déjà.

Lorsque les compteurs semblent faux, vérifiez dans l'ordre : la variante de sélection derrière chaque onglet, les chevauchements entre onglets, et si l'onglet a été actualisé après la dernière action. La plupart des problèmes de worklist sont des problèmes de conception de la sélection, pas des défauts du framework.