Edition du 14 juin 2017 : d’après cet article paru hier pendant l’OroVibe, la prochaine version ne serait pas numérotée 1.8 et le rythme des sorties de versions changera à partir de Septembre 2017.
Edition du 7 septembre 2017 : Akeneo a confirmé sur Twitter que la prochaine version sera numérotée 2.0.
Akeneo, le gestionnaire d’informations produit bénéficie de mises à jour majeures sur un rythme de 2 versions par an. La prochaine, qui devrait être logiquement la version 1.8, est prévue pour l’automne et promet déjà de grands changements.
Le Single storage, MySQL 5.7 et ElasticSearch
Depuis plusieurs versions, Akeneo utilise plusieurs modes de fonctionnement pour stocker les informations, selon la volumétrie du catalogue :
- MySQL seul
- MySQL et MongoDB en association, appelé « Hybrid Storage »
- MySQL, MongoDB et ElasticSearch, pour les grosses volumétries disponible en édition Enterprise uniquement
À partir de la version 1.8, ces trois méthodes n’existeront plus. Elles seront remplacées par le Single Storage, un mode de stockage unique tirant partie des champs JSON de MySQL 5.7 et de l’indexation ElasticSearch.
MongoDB disparaît des dépendances, ce qui permettra de simplifier la maintenance quand des reference data sont présentes sur le projet et la nécessité de maitriser les deux types de mappings (Doctrine ORM et Doctrine MongoDB ODM).
Ce n’est pas pour autant que les infrastructures serveur seront plus simples, ElasticSearch est une brique très efficace mais qui demande des compétences encore peu répandues à l’heure actuelle. Ce n’est qu’une question de temps je pense, le gain de performances apporté par cet outil est très loin d’être négligeable.
La version MySQL 5.7 devient également un pré-requis. Elle apporte des gains de performances, mais également un nouveau type de champ JSON et un ensemble de fonctions et d’opérateurs pour gérer ce type de données. Il est également possible d’utiliser une syntaxe pour rechercher à l’intérieur du JSON sur le même principe que la commande jq pour en extraire certaines parties ou bien filtrer sur le contenu de ce JSON.
Migration sur Symfony 3.3
Dans cette nouvelle version Akeneo migre d’une version 2.7 aujourd’hui agée de 2 ans vers une version plus récente, la version 3.3 sortie ce 29 mai. Cette montée de version permettra de bénéficier d’améliorations de performances mais aussi des nouveaux outils apparus depuis dans le framework.
Autre point induit par cette migration, les formulaires sont migrés sur des vues Backbone. Depuis la version 1.6, un nouveau type de formulaire était apparu sur le formulaire d’édition de produit, qui exploite donc des vues Backbone. Entièrement conçu en javascript, il permet de simplifier l’organisation des pages et la conception de nouvelles interfaces.
Utilisation de BCMath avec les unités de mesure
Les attributs de type métrique vont bénéficier de l’utilisation de l’extension BCMath, qui permet de réaliser des calculs sur des nombres, avec un contrôle du niveau de précision et des arrondis.
Dans le cadre où l’on a besoin de gérer des données techniques de précision, nous pourrons mieux maitriser les arrondis et permettre à ceux qui en ont besoin d’obtenir des dimensions dans des unités adaptées et précises.
Utilisation des UUID pour identifier les produits
L’identification des produits utilisera désormais des UUID, à la place des entiers auto-incrémentés utilisés jusqu’à présent. Ce changement permettra d’une part de ne pas induire de verrouillage des tables MySQL lors des imports en masse des produits, ce qui peut poser des problèmes de performances et d’expérience utilisateur.
D’autre part, ça permettra aux développeurs de disposer d’un identifiant produit avant que celui-ci ne soit effectivement présent en base de données. Ce second point était une source de difficultés lors de l’écriture de certain types de connecteurs dans l’AkeneoBatchBundle. Il y a évidemment des points négatifs à ce nouveau fonctionnel, en particulier si tous les développements n’ont pas étés réalisés correctement, comme la possibilité laissée d’enregistrer une référence d’un produit qui ne sera jamais sauvegardé en base de données.
Le côté frontend n’est pas oublié avec Webpack
Du côté du frontend, Webpack prendra le pas sur l’ancien OroRequirejsBundle qui pour sa part sera retiré. C’est je pense une bonne chose qui permettra aux développeurs front de réaliser leurs développements en isolation, sans nécessiter d’avoir une version complète d’Akeneo sur leur environnement de développement.