Aller au contenu principal

Akeneo PIM : comment visualiser l’ensemble des jobs exécutés et leur rapport d’exécution

Akeneo PIM est une puissante solution de gestion d’information produit (Product Information Management) aujourd’hui plébiscitée par nombre d’acteurs du e-commerce pour sa simplicité d’utilisation et les services rendus. Akeneo PIM permet de collecter, gérer, enrichir l’information produit, créer des catalogues, afin de les distribuer sur différents canaux de diffusion (web, print, etc…).

Akeneo PIM évolue rapidement et pour le meilleur. Les performances ont été grandement améliorées grâce à l’exploitation d’index ElasticSearch. La solution propose désormais également une API REST robuste, qui permet d’effectuer toutes sortes de requêtes sur le catalogue, sa structure, son contenu. L’interface graphique a été entièrement revue, pour le plus grand bonheur des utilisateurs.

Des changements apportés dans le “process tracker”

Certaines fonctionnalités ont cependant disparu, alors qu’elles avaient une utilité recherchée. La première qui me vient à l’esprit concerne l’affichage de l’historique des jobs exécutés, dans le “process tracker”, le traqueur de processus.

Les jobs sont des commandes, des scripts chargés d’accomplir certaines tâches : importer des données d’un ERP, exporter des données CSV ou XLSX pour des clients comme Magento, Oro Commerce, Salesforce et bien d’autres. Mais les jobs ne se limitent bien sûr pas aux imports/exports; on peut imaginer toutes sortes d’opérations effectuées par des jobs. Dans tous les cas, les jobs manipulent des données sensibles, et il est indispensable de pouvoir vérifier si un job s’est bien exécuté, s’il y a eu des erreurs, des alertes, afin de pouvoir prendre les mesures nécessaires le cas échéant.

Or, dans les anciennes versions du PIM Akeneo, un utilisateur possédant suffisamment de droits (un administrateur par exemple) pouvait visualiser l’ensemble des jobs exécutés et leur rapport d’exécution. Sur les versions récentes (2.x+), un utilisateur, même doté des permissions les moins restrictives, ne voit plus que la liste des jobs qu’il a lui-même lancés.

Beaucoup de clients ont été étonnés de cette restriction lorsqu’ils sont passés d’une version 1.x à une version 2.x ou 3.x, et m’ont demandé de “restaurer” le fonctionnement qu’ils connaissaient. En effet, les administrateurs ne voient plus les jobs lancés par leurs collaborateurs ou en tâches automatisées, et n’ont donc plus accès aux rapports qui leur permettaient de comprendre un dysfonctionnement.

Enrichir l’Event Listener pour améliorer le suivi des jobs

Je me suis donc penché sur la question, le code en l’occurrence, et je me suis rapidement rendu compte que la requête exécutée pour retrouver la liste des jobs était modifiée dans un Event Listener, de la façon suivante :

Ce listener “intercepte” la requête avant qu’elle ne soit envoyée, récupère l’identité de l’utilisateur connecté et ajoute une condition WHERE filtrant les exécutions de jobs pour ne récupérer que celles lancées par l’utilisateur en question.

On peut assez facilement contourner cette restriction en écrivant notre propre listener :

L’amélioration consiste à informer le listener d’une liste de rôles $notRestrictedRoles pour lesquels il n’y a pas lieu de filtrer les résultats. Si l’utilisateur courant possède l’un de ces rôles, on sort du listener sans modifier la requête, et l’ensemble du résultat est renvoyé.

Surcharger la définition du service

Il ne faut pas oublier de surcharger la définition du service concerné dans le container de l’application (dans app/config/services.yml par exemple):

La liste des rôles pour lesquels ne pas filtrer est indiquée à ce niveau. Dans cet exemple, un seul rôle aura accès à l’ensemble des résultats de la requête : ROLE_ADMINISTRATOR.

Conclusion

Akeneo a fait le choix de n’afficher nativement qu’une liste de processus filtrée en fonction de l’utilisateur connecté. Cette restriction peut présenter un certain nombre d’inconvénients à l’usage. Il est néanmoins relativement simple de surcharger ce comportement par défaut en modifiant le Listener chargé d’ajouter le filtre sur la requête.

Par Benoit Wannepain, Expert Technique Akeneo

Si vous souhaitez être accompagné pour la mise en place de votre PIM, n’hésitez pas à demander conseil à nos experts certifiés Akeneo.

 

Martin Meunier - Business Developer Kaliop Digital Commerce