Actualités

[28/12/2016] Smile vous souhaite une excellente année 2017

Toute l'équipe Smile vous souhaite une bonne année 2017 !

[15/12/2016] Smile récompensé par Akeneo: meilleur partenaire de l'année !

logo Akeneo

 

Akeneo est un innovant logiciel de PIM (Product Information Management) créé par une équipe franco-américaine en 2013. 

[29/11/2016] Coved lance son projet de cabines connectées avec Smile

Smile accompagne le groupe Coved dans le lancement à grande échelle d’un projet de cabines connectées. Découvrez le témoignage !

Toutes les actualités picto
       

Vous avez besoin de mettre à jour votre Lecteur Flash Flash 7

Guillemet ouvrant l'actualité des solutions
et des technologies open source Guillemet fermant
picto

Akeneo Partner Summit: Toutes les innovations techniques apportées par Akeneo

La deuxième édition de l’Akeneo Partner Summit a eu lieu les 29 et 30 novembre à Nantes. Voici un résumé des informations que nous avons collectées sur la nouvelle version 1.6 d’Akeneo lors des ateliers techniques de la seconde journée.

Tout d’abord, il est enthousiasmant de voir à quel point Akeneo a pris en compte les retours de ses partenaires et de ses clients. Ainsi, on peut voir que la documentation s’enrichit, que le code s’améliore, et que des fonctionnalités ont été modifiées pour en faciliter l’usage. Cette tendance a déjà été observée au premier semestre de cette année, et Akeneo confirme son engagement dans cette voie !

1. LES IMPORTS/EXPORTS

Le premier changement majeur concerne les imports/exports. Et c’est une bonne nouvelle : 90% des projets Akeneo nécessitent de développer des jobs d’imports/exports personnalisés. C’est un besoin récurrent, car à chaque fois qu’on crée une nouvelle entité, on a besoin de pouvoir l’alimenter par imports/exports de fichiers ; à chaque fois qu’on crée un nouveau type d’attribut, on doit pouvoir l’alimenter par imports/exports. L’import/export de fichiers est donc une fonctionnalité clé.

Dans cette version 1.6, Akeneo a été modifié pour standardiser et clarifier la création et la modification des jobs d’import/export.

Une simplification du code
Tout d’abord, jusqu’à la version 1.5, les objets utilisés pour l’import/export étaient répartis dans 5 bundles. Avec la version 1.6, cela a été réduit à 3 bundles.

Moins de readers & writers
Le découpage des readers & writers a été modifié. Nous étions habitués à manipuler des ORM reader, Doctrine reader, et Mongo reader, chacun d’entre eux utilisant différents namespaces même s’ils collectent les données au même endroit. Dans la version 1.6, nous avons des « file reader » et des « database reader », et puis c’est tout. Les précédents readers sont dépréciés et supprimés. Et la même simplification a été appliquée aux writers.

Un nouvel objet pour normaliser les données
Les entrées/sorties des Normalizations & De-normalizations ont également été améliorées. Avec les Normalization & De-normalization on prend en entrée un objet et on retourne un tableau, ou inversement. Le problème est que ces tableaux ne sont pas normalisés, ils dépendent du type d’objet et d’autres paramètres. Akeneo apporte une solution avec un nouvel objet appelé « StructuredFormat », d’après Akeneo cet objet sera bien plus facile à appréhender. La version 1.6 est une première étape, elle intègre cet objet dans plusieurs composants. Dans la future version 1.7, cette structure sera intégrée dans l’ensemble de la solution.

Une configuration plus rapide
La configuration des imports/exports a été revue. Dans Akeneo 1.5, chaque reader/processor/writer définit la liste des champs attendus en entrée. Et c’est un problème parce que cela ajoute de la complexité à chaque étape, et parce que rien ne permet de garantir que la donnée initiale ne sera pas altérée. C’est une question importante dans la distribution des responsabilités.
Sur cette question, Akeneo introduit un nouvel objet. Ce nouvel objet prend en charge la définition des entrants, la validation des données, et si nécessaire la transformation de ces données. Au départ, cela semble rendre la création d’un job un peu plus long, mais en fait cela ouvre de nouvelles possibilités.
La question est maintenant de savoir comment faire fonctionner ensemble reader/processor/writer avec les configurations. Et c’est là que ça devient vraiment intéressant car chaque configuration est un service Symfony. Chaque étape du job est un service Symfony également, et on peut y injecter n’importe quelle configuration. Et pour finir, le job est lui-même un service Symfony, ce qui signifie qu’il n’y a plus de fichier supplémentaire à créer, tout est géré par le framework.
En théorie ce changement devrait avoir peu d’incidence sur les performances, mais il devrait rendre le développement plus simple et plus lisible.

Des fonctionnalités pour aider les utilisateurs
D’un point de vue moins technique, de nombreuses options ont été ajoutées pour filtrer les données qui seront exportées. Vous pouvez par exemple exporter tous les produits d’une certaine marque, dont le prix est supérieur à X€.
Akeneo ajoute également le support des fichiers Excel. Partout où il y a un import/export de fichiers CSV, il y a maintenant un import/export de fichiers Excel. Pour cela, Akeneo a retiré la librairie pour le support des fichiers Excel qui avait été développée en interne, et utilise maintenant une nouvelle librairie qui est présentée comme beaucoup plus flexible.

Quid des performances ?
Pour l’avoir déjà expérimenté, on sait que lorsqu’il s’agit de traiter de très grosses volumétries, l’import et la publication de 1 million de produits dans Akeneo est difficile à réaliser dans un temps « raisonnable ».
On sait qu’Akeneo utilise depuis la version 1.4 des tests automatisés sur les imports/exports pour détecter les défauts de gestion de la mémoire et les baisses de performances. Cette version 1.6 ne déroge pas à la règle, et il n’y aura pas de dégradation des performances. Mais il ne faudra pas non plus s’attendre à une amélioration des performances, notamment sur de très grosses volumétries.
Il semble qu’Akeneo a quelques actions prévues à ce sujet dans sa roadmap, mais il n’y aura pas de saut de performance important dans un avenir proche.

2. ELASTICSEARCH & DES MILLIONS DE PRODUITS

Des millions de produits ? En fait, l’intitulé de l’atelier n’était pas exactement représentatif du sujet qui était traité.

Il y a un seuil de volumétrie à partir duquel il devient nécessaire d’utiliser MongoDB avec Akeneo pour conserver des performances satisfaisantes.

Les préconisations d’Akeneo situent ce seuil à partir de 5 millions de « valeurs d’attributs produits » en base de données. Comment savoir si on dépassera ce seuil ? Akeneo donne une formule précise sur cette page. Pour simplifier, c’est une combinaison du nombre de produits, du nombre d’attributs pour chaque produit, et du nombre de locales. Par exemple, si on a 50 000 produits, 10 attributs localisables et scopables (avec par exemple 2 canaux et 5 locales), alors on aura 50 000 x 10 x 10 = 5 000 000 valeurs d’attributs produit.

Comme vous pouvez le voir, le seuil des 5 millions sera atteint bien avant d’avoir 5 millions de produits. Et si on dépasse ce seuil, alors l’affichage de la liste des produits deviendra très lent. Heureusement, une solution existe : prévoir une base MongoDB pour accélérer l’affichage.
Maintenant que l’affichage de la liste des produits et le filtrage des produits sont rapides, que se passe-t-il si on augmente le nombre d’attributs ? Avec MongoDB on ne peut avoir que 65 indexes par collection. Or, dès lors que l'on souhaite utiliser un attribut sur la grille, il doit être indexé. Ainsi, avec 10 attributs scopables et localisables, 2 canaux et 5 locales, on arrive déjà à 100 indexes. Donc, la limite est atteinte très rapidement
C’est là qu’Akeneo apporte une solution depuis sa version 1.4 avec ElasticSearch et l'ElasticSearchBundle.

Pour ceux qui connaissent Magento, cela fonctionne globalement de façon similaire à l’indexation ElasticSearch de Magento. Les données produit dans la base MongoDB sont répliquées dans la base ElasticSearch, c’est ce qu’on appelle « l’indexation ». Ensuite lorsque l’utilisateur souhaite consulter la liste des produits, une première requête ElasticSearch permet de récupérer la liste des identifiants des produits à afficher, puis des requêtes dans MongoDB permettent de récupérer toutes les informations nécessaires pour afficher la grille à l’utilisateur.
Outre la prise en charge d’un plus grand nombre d’attributs, cela permet d’améliorer les performances. Akeneo communique les performances suivantes:

  •   En moyenne 1,3x plus rapide
  •   5x plus rapide pour chercher un produit à partir de son nom
  •   1,3x plus rapide pour chercher un produit à partir d’un attribut simple (comme la marque)
  •   4x plus rapide sur les recherches multi-critères

Ainsi ElasticSearch améliore vraiment les performances à l’affichage, mais… quelles sont les performances de l’indexation dans ElasticSearch ?

Tout d’abord, le processus d’indexation qui a été implémenté est synchrone : dès qu’on modifie un produit, il est immédiatement indexé dans ElasticSearch. Il n’y a pas de mise en file d’attente, c’est immédiat. Et la bonne nouvelle, c’est que c’est rapide, très rapide, et que le nombre d’attributs n’a que peu d’impact sur les performances d’indexation. Cela est dû au fait que les structures de données MongoDB et ElasticSearch se ressemblent, et que pour indexer un produit, Akeneo peut extraire les données de MongoDB et les envoyer à ElasticSearch avec très peu de modifications. Il n’y a pas de doctrine query, pas de transformation, et aucun chargement d’objet.
D’après Akeneo, 1 million de produits peuvent être indexés dans ElasticSearch en 45 minutes.

3. AUTRES AMELIORATIONS

Faciliter les migrations

Akeneo souhaite faciliter les migrations. A partir de cette version, les migrations vers les versions supérieures devraient être plus faciles.

Akeneo va fournir des informations sur ce qui doit être modifié lors d’une migration depuis la version précédente, donc on devrait avoir plus d’informations dans la Release Note de chaque version. En revanche, Akeneo ne s’engagera pas à garantir une compatibilité ascendante des développements spécifiques d’une version à une autre, et personnellement je pense que c’est une très bonne chose. Cela permettra à la solution d’évoluer de façon plus dynamique.

La marketplace Akeneo

Akeneo souhaite encourager ses partenaires à créer des bundles et à les partager avec la communauté sur la marketplace. Akeneo se déclare prêt à aider ses partenaires à construire un bundle générique pour la marketplace, et peut également signaler si un autre partenaire est déjà en train de travailler sur une fonctionnalité similaire.

Une fois qu’un bundle est publié, le partenaire peut décider de le partager gratuitement ou en échange d’une rétribution, dans tous les cas de figure Akeneo pourra aider le créateur d’un bundle à le migrer vers les versions supérieures.

4. CONCLUSION

Akeneo nous semble faire évoluer sa solution dans la bonne direction. Les améliorations apportées sont pertinentes et ouvrent de nouvelles perspectives.

Pour les versions suivantes, nous avons de nombreuses attentes, on pense notamment à une intégration plus profonde d’ElasticSearch, à des améliorations sur les performances lors de l’import de grosses volumétries de produits, et des outils pour faciliter l’initialisation des projets. Bref, vivement la suite !

J’aimerais terminer cet article par un petit divertissement créé par nos amis chez Akeneo : http://badger.akeneo.com. Comme son nom l’indique, cette petite application vous permet de gagner des badges par vos contributions au noyau d’Akeneo : signalement d’anomalies, aide à la traduction, réalisation de projets…

Et comme les choses les meilleures sont celles qu’on partage, le code est open source ! https://github.com/akeneo/badger

Pierrick Olivier, Oliver De Cramer
picto

Commentaires

Soyez la premiere personne à ajouter un commentaire sur cet article.
Ecrire un nouveau commentaire