Le blog des équipes…

Importer des données dans une plateforme a toujours été un vrai casse-tête pour les informaticiens. A plus forte raison lorsque c’est dans Magento, et plus généralement dans une base de données de type EAV (Entités/Attributs/Valeurs).

Pour rappel, et pour faire court, une base de données (ou au moins une partie de celle-ci, car une base de données peut combiner un modèle relationnel standard et le modèle EAV, suivant les données à stocker, et c’est le cas de Magento) architecturée selon le « modèle EAV » permet de standardiser le stockage des données via quelques concepts clés :
-    Des Entités
-    Des Attributs
-    Des Valeurs

Dans le cas de Magento, les données sont ainsi segmentées par type de données au sens « informatique » du terme (c’est-à-dire des entiers, des chaines de caractères, des nombres à virgules…etc.) plutôt que par type de données au sens « métier » du terme (c’est-à-dire une table « client », une table « adresse »…).
L’inconvénient, c’est qu’on aura un nombre de tables bien plus important que dans un modèle standard, donc que les appels entre elles se multiplieront, donc que les temps de réponse entre l’envoi d’une requête et la réception de la réponse seront plus longs, et donc que votre site mettra plus de temps à afficher une page.
L’avantage, c’est que pour ajouter des champs (par exemple la photo d’un client, son âge…etc), on n’aura pas à modifier la structure de la base de données, mais simplement à rajouter des enregistrements dans les tables existantes !…
Pour prendre un exemple (j’en vois au fond à gauche qui baillent près de leur radiateur !… ) :
On veut stocker en base de données les infos d’un client.

En modèle standard, ça donnerait :
Table CLIENT :

Tandis qu’en modèle EAV, on aurait quelque chose comme :
Table ENTITE_CLIENT :

Table ENTITE_CLIENT_CHAINES_CARACTERES :

Table ENTITES_CLIENT_ENTIERS :

Vous allez me dire : « Oulalaaa, c’est bien compliqué pour pas grand-chose… ». Compliqué, oui. Pour pas grand-chose, non.
L’énorme avantage est la stabilité de la base de données. En effet, Magento n’a de cesse de se développer et les intégrateurs comme Bysoft n’ont de cesse de recevoir des demandes d’extensions de la plateforme. Dans l’exemple précédent, rajouter un champ « Civilité » pour les clients reviendrait à ajouter une colonne dans la table « CLIENT » du modèle standard, c’est-à-dire à modifier la structure et l’architecture de la base de données. Dans le modèle EAV, il suffit de rajouter un type « civilité » et un enregistrement dans la table « ENTITE_CLIENT_CHAINES_CARACTERES », ce qui ne modifie pas la structure de la base de données, mais seulement le nombre d’enregistrements.
Le principal soucis étant donc la lenteur de Magento, Varien propose depuis la release 1.3.0, un « Flat catalogue », c’est-à-dire la mise en cache de la base de données suivant le « modèle relationnel », c’est-à-dire un modèle statique.

On s’égare on s’égare, j’en reviens à l’essentiel : Comment importer des données avec toutes ces tables qui s’entremêlent ?

Plusieurs voies possibles :
- Utiliser les profils d’import/exportMagento

o Avantages : modifiable directement en BackOffice, facilité, rapidité de mise en place

o Inconvénients : limitation dans les entités importables et exportables, lent

-    Utiliser les webservices Magento

o    Avantages : facilité, rapidité de mise en place, appels directs et synchrones, évolution de l’API, aucune connaissance très poussée du code à avoir

o    Inconvénients : limitation à l’API ou nécessité de créer les webservices manquants, très lent lors du traitement de milliers d’appels

-    Utiliser les classes et méthodes existantes Magento et créer son propre script Magento

o    Avantages : mise en place assez rapide, évolution correcte avec les releases de Magento

o    Inconvénients : bonnes connaissances du code Magento nécessaire, assez lent lors du traitement de milliers d’appels

-    Insérer / mettre à jour directement les données en Base de données par des requêtes SQL

o    Avantages : très rapide lors du traitement de milliers d’appels, pas d’API, de classes ou de méthodes à créer

o    Inconvénients : compatibilité avec les releases suivantes de Magento à valider, Très bonne connaissance du code et de la Base de données de Magento nécessaire

La méthode à employer dépend ensuite :
-    Du type de données
-    Du nombre de données en base
-    De la fréquence de mise à jour des données
-    Des possibilités du client (présence d’un ERP ? saisie manuelle ? appels automatisables ou manuels ? le client a-t-il des développeurs pour mettre en place des appels webservices dans les applications internes ?…etc)
-    Du budget

Pour prendre un cas d’école, voici l’architecture choisie pour l’un de nos clients principaux sur Magento :
-    Import / mise à jour massif des fiches produits (simples et configurables) au format CSV, de manière asynchrone (plusieurs milliers voire dizaines de milliers de références à chaque import)
-    Import / mise à jour des catégories en webservices, de manière synchrone
-    Import / mise à jour des images produits au format CSV, de manière asynchrone
-    Assignation des produits simples aux produits configurables au format CSV, de manière asynchrone
-    Récupération des clients en webservices, de manière synchrone
-    Mise à jour des clients en webservices, de manière synchrone
-    Récupération des commandes en webservices, de manière synchrone
-    Facturation en webservices, de manière synchrone
-    Expéditions en webservices, de manière synchrone
Typiquement pour ce client, le BackOffice de Magento n’est pas du tout utilisé (ou ponctuellement, pour seulement en modifier la configuration). Les données sont constamment échangées avec l’ERP, dans lequel tout est centralisé (clients et ventes des autres sites du groupe, ventes des magasins physiques, facturation, expédition…).

Au vu de la quantité de données transitant, et après des tests et échanges auprès de Varien, la solution qui s’est imposée pour les imports massifs a été l’import direct en Base de données. Solution la plus rapide, elle a toutefois nécessité beaucoup de recherche et de tests pour garantir l’intégrité des données et la pérennité de la base, en association directe avec l’éditeur.

La V1 est maintenant pleinement opérationnelle, et le site en production. La V2 est en cours, avec au menu : des optimisations dans le chaînage des différents imports, une amélioration des fichiers de log et des optimisations de rapidité d’exécution.
Tant qu’on est en plein dedans, une petite astuce pour améliorer les temps d’import, désactiver les index sur les tables impactées, et les réactiver ensuite… Un exemple simple :
Juste avant de lancer l’import : ALTER TABLE nom_de_la_table DISABLE KEYS
Juste après l’import : ALTER TABLE nom_de_la_table ENABLE KEYS
C’est tout bête, mais ça permet de gagner un temps précieux lorsqu’on travaille sur des dizaines de milliers de références !…

Pour conclure, le transfert synchrone et asynchrone de données entre une plateforme Ecommerce (que ça soit Magento ou une autre), reste la principale problématique complexe à mettre en œuvre, très critique pour l’architecture d’un site de vente en ligne. Cette partie doit être clairement identifiée, soupesée et parfaitement architecturée, en prenant en compte tous les éléments pouvant l’impacter. Vont dépendre de ces choix préalables la fiabilité de votre plateforme, sa pérennité à long terme, l’intégrité des données, les perspectives d’évolution futures, les coûts de maintenance futurs, la rapidité du site. Tous ces éléments sont extrêmement critiques et ne doivent pas être pris à la légère. Un site dont les données ne sont pas à jour, ou dont les pages ne se chargent pas assez rapidement est clairement voué à l’échec vu l’agressivité et la concurrence du marché actuel.

Les problématiques des clients étant toutes différentes, nous ne recommanderons jamais assez de réfléchir à l’avance à ce que vous voulez mettre en place, et à ce que vous visez à terme. Il ne s’agit pas de partir tête baissée sur une plateforme parce qu’elle est la moins chère et parce que l’intégrateur vous a promis une livraison en 3 jours clés en main et le café offert… Prenez conseil, adressez-vous à des professionnels qui sauront comprendre votre métier et vos besoins pour définir avec vous l’architecture la plus adaptée (et pas forcément la plus chère… ). Un audit de deux jours dans vos locaux par un architecte Magento vous fera très certainement gagner des jours, des semaines, voire des mois dans le futur, parce qu’il vous aura conseillé la bonne architecture et vous aura indiqué les pièges qui jalonnent la route des entrepreneurs Ecommerce…