Le blog des équipes…

Afin de pouvoir intervenir rapidement dans la résolution d’erreurs, il est important d’avoir les bons outils.
Voici un cas d’erreur rencontré récemment :

Contexte
Une page de listing de données (contenant un moteur permettant de filtrer les données affichées) fonctionne correctement sous Firefox, mais est très lente sous IE 7, IE 8 et plante de temps en temps sous IE6.

Intervention
Le problème se produisant seulement sous IE, il était difficile de cerner la cause par le manque d’outils sous IE aussi précis que Firebug sous Firefox.
En effet avec Firebug, il est possible de voir le détail de l’exécution du JavaScript.
La première action fut donc de rechercher des outils pour permettre l’analyse du problème sous IE :

• Fiddler : Fiddler est une sorte de proxy, qui permet de voir tous les échanges qui sont fait entre le navigateur et le serveur (fonctionne pour tous les navigateurs)
• DynaTrace: Permet de visualiser toute l’exécution du code JavaScript sous IE

Dans notre cas, voici ce que l’on pouvait voir avec Fiddler lorsqu’on choisissait un critère :

Il est indiqué que pour un critère du moteur choisi, 6 requêtes HTTP sont envoyées vers le serveur. Cela ne se produit que sous IE (toute version), sous firefox (ou autre navigateur) on a bien  une seule requête HTTP.

Nous constatons des effets similaires avec l’outil DynaTrace :

6 appels ajax sont remontés :
 

En regardant le détail des requêtes Ajax qui sont faites, on peut voir qu’il s’agit de la même requête à chaque fois :

Avec DynaTrace, il est possible de voir tout le déroulement du JavaScript.

La démarche fut donc de regarder ce qui était à l’origine des appels Ajax générés.
Ci-dessous la même vue que précédemment, mais en filtrant sur la fonction Ajax de jquery:

Dans BackTraces, il est possible de voir les fonctions qui sont à l’origine de l’appel.
On peut voir qu’il y a :
- OnClickList : ce qui est normal, c’est lorsqu’on clique la première fois sur le critère.
- OnChangeCheckbox : ce qui n’est pas normal, cette fonction devrait être appelée seulement lorsque l’utilisateur clique sur une case à cocher. Visiblement lorsque le JavaScript traite le résultat renvoyé par le premier appel AJAX, IE mets à jour les cases à cocher, ce qui déclenche la fonction OnChangeCheckbox.

Résolution
Il faut modifier le code JavaScript pour que la fonction OnChangeCheckbox soit appelée différemment.
La page de listing peut à présent s’exécuter sous IE sans plantage.

Présentation

Principe

Phing (Phing Is Not Gnu make) est un outil de déploiement permettant d’automatiser une suite d’opérations. Il est comparable à Make (généralement utilisé pour les développements en C et C++) et Ant (le plus souvent utilisé dans le cadre de développements en Java). Comme ces deux outils, il permet de définir une série de tâches à accomplir et des dépendances entre ces tâches. Sur beaucoup de points, Phing ressemble à Ant sur lequel il est basé directement.

Phing est un outil programmé entièrement en PHP, développé en open source (Gnu Lesser General Public License). Toute la documentation, et le code source sont disponibles sur le site suivant : http://www.phing.info/trac/

Installation

L’installation de Phing est très aisée, que ce soit sur Linux ou Windows : elle se fait en utilisant le package manage  Pear :

pear channel-discover pear.phing.info
pear install phing/phing-beta

Nous avons également installé l’extension pour utilisation native de SVN :

pear install VersionControl_SVN-0.3.3

Dans notre cas, il a aussi été nécessaire d’installer SSH2, la librairie PHP permettant de se connecter en SSH :

pecl install SSH2-0.11.0

Utilisation

Phing est un outil en ligne de commande, qui s’appelle simplement en tapant la commande :

phing

Si l’on veut exécuter une tâche particulière, il suffit de la spécifier de cette façon :

phing <task name>

Fonctionnement

Lorsque phing s’exécute, il va chercher le fichier ‘build.xml’ à l’emplacement du dossier courant, et exécute la tâche spécifiée ou la tâche par défaut du fichier.

Le fichier build.xml est un fichier xml de ce type :

<?xml version=”1.0″?>
<project name=”build” default=”main”>
<property value=”.” />
<property value=”svn” />
<target depends=”update-back”/>
<target>
<svnupdate
svnpath=”${svn_path}”
todir=”${project_root}”
nocache=”true” />
</target>
</project>

Le tag project définit le projet, la propriété default est le nom de la tâche appelée par défaut.

Les tags ‘property’ correspondent à des variables. La propriété name en est le nom, et value la valeur. Il peut s’agir de chaines de caractères, ou de listes de chaines de caractères séparées par une virgule.

Les tags ‘target’ correspondent à des tâches. La propriété name est le nom d’appel de la tâche. La propriété depends est la liste des autres tâches à exécuter avant la tâche courante. A l’intérieur du tag, les autres tags sont la liste des commandes à exécuter par le script. Pour la tâche update-back par exemple, il s’agit d’un svn update.

Il existe un certain nombre de commande exécutables par défaut :

exec : exécute une ligne de commande

foreach : parcours un tableau et pour chaque élément renvoie vers une autre tache avec l’élément en argument

et différentes autres : chmod, chown, delete, move, etc. La documentation complète est disponible ici : http://phing.info/docs/guide/trunk/

Usage sur un projet spécifique PHP/Symfony

Choix de Phing

Phing a été choisi, plutôt que Ant ou Make pour une raison principale : c’est un outil fait en PHP. Cela apporte les gains suivants :

• Facilité d’utilisation pour une équipe PHP
• Pas besoin d’installer Java ou d’autres utilitaires sur nos serveurs
• Possibilité d’écrire du code PHP directement dans une tâche si nécessaire
• Possibilité d’étendre l’outil en créant de nouvelles tâches en cas de besoin

Tâches disponibles

Les tâches suivantes on été créées dans le cadre de notre projet. Toutes ont été écrites pour être appelées depuis le serveur de backend. Le fichier build.xml est présent sur le serveur de backend, et est dans svn à la racine de la branche de production.

Celles-ci ont été écrites pour être appelées par des tâches principales, elles ne devraient pas être appelées individuellement :

update-back : update la copie locale du backend

rollback-back : revert la copie locale du backend jusqu’à la révision spécifiée

clear-backend-cache : vide le cache symfony du backend

update-filer : update la copie locale du filer

rollback-filer : revert la copie locale du filer jusqu’à la révision spécifiée

clear-frontend-cache : vide le cache symfony des serveurs frontaux

Celles-ci sont les tâches principales, qui peuvent être appelées directement :

main : (tâche par défaut), elle appelle update-back, update-filer et clear-backend-cache. Elle permet d’effectuer une livraison sans risque sur les frontaux – mais dont les effets ne pourront peut-être pas être vus immédiatement car les caches ne sont pas vidés.

cc : elle appelle main et clear-frontend cache. Elle sert à effectuer une livraison avant 9h.

rollback : elle prend en argument une révision, et appelle les tâches rollback-back, rollback-filer et clear-backend-cache. Elle permet de faire un retour arrière sans risque sur les frontaux – mais dont les effets ne pourront peut-être pas être vus immédiatement car les caches ne sont pas vidés.

rollbackcc : elle prend en argument une révision, et appelle les tâches rollback et clear-frontend-cache. Elle sert à faire un retour arrière avant 9h.

Gain par Phing

Phing a été mis en place il y a une semaine. Les gains déjà visibles sont :

• Facilité des déploiements, moins fastidieux
• Sécurité des déploiements : plus de problème d’oubli d’un update ou d’un vidage de cache
• Rapidité des déploiements : 30 secondes d’opération au lieu de plusieurs minutes
• Maintien de la simplicité des déploiements en cas d’évolution de l’architecture système (par exemple, lors de l’ajout d’un frontal, il suffit d’ajouter son IP dans la liste des frontaux, et le processus de déploiement reste valide)

Evolutions futures

Phing est un outil extrêmement flexible, voici quelques évolutions possibles de son utilisation :

• Passage de tests automatiques dans la foulée du déploiement pour le valider
• Automatisation des évolutions de base de données en utilisant les outils symfony appropriés
• Validation de l’absence de conflit SVN lors du déploiement

Depuis quelques temps maintenant, Google a intégré dans son algorithme de référencement un critère non négligeable : la rapidité de chargement des sites !
En effet, on peut se dire qu’il est totalement juste de proposer aux internautes des sites rapides en priorité (bien sûr ce critère ne passe pas devant les bonnes pratiques du référencement naturel !), ce qui est au final un gage d’une qualité de service plus pointue.

Ce changement dans le mode de calcul du leader mondial de la recherche sur internet avait en effet été annoncé par Matt Cutts lors de la conférence Pubcon en fin 2009 qui affirmait que le temps de chargement d’une page et le temps de réaction d’un site lors de la visite du spider (le robot chargé de l’indexation) pourrait être un facteur positif dans l’algorithme de classement des résultats d’une recherche.
Toutefois,  ce critère n’est  pas un facteur négatif : un site à vitesse de chargement très lente ne sera par exemple pas non plus pénalisé pour autant.

Optimiser la vitesse de chargement de vos pages
L’heure est donc à l’optimisation de nos pages web, afin d’augmenter la vitesse de leur chargement en mettant en œuvre les moyens suivants :

• Optimisation des images du site (choix du bon format et d’une compression adaptée)
• Optimisation du découpage du site
• Optimisation du code des pages (écriture d’un code propre, sans répétition inutile de blocs, et sans caractère superflu)
• Mise en place de systèmes de cache
• Choix de la plateforme d’hébergement : parce que le type de serveur et de l’infrastructure hébergeant un site joue évidemment son rôle dans son temps de réponse !

Les outils à disposition
Pour bien suivre ce nouveau critère de classement, Google a bien sûr prévu un outil pour les webmasters consciencieux dans sa suite Google Webmaster Tools  intitulé « Performance du site ».
Vous pourrez également télécharger le plugin Firefox Google Page Speed (équivalent à YSlow) qui vous permettra d’auditer le temps de chargement de vos pages et vous apporter des solutions pour son amélioration.

Lien yslow : https://addons.mozilla.org/en-US/firefox/addon/5369/

Bysoft vient de publier sur MagentoConnect le module officiel ICI relais (http://www.icirelais.com), en collaboration avec la société Exapaq. Le module est accessible à cette adresse:

http://www.magentocommerce.com/magento-connect/Bysoft/extension/3651/bysoft_icirelais_officielle

ICI relais, c’est quoi ?
ICI relais est un mode de livraison via des relais colis disséminés partout en France. Le client choisit l’espace ICI relais de destination de sa commande et, une fois le colis arrivé, vient le retirer directement dans cet espace, près de chez lui.

ICI relais offre au client la possibilité rare de garder son temps totalement sous contrôle

• Il décide où doit avoir lieu sa livraison.
• Il décide quand retirer sa commande.
• Il ne se déplace qu’avec l’assurance que sa commande est bien disponible grâce à l’avisage envoyé par email ou sms.
• Il retire rapidement sa commande.

Avec ICI relais, livrez vos clients en 24 ou 48 heures en commerces de proximité sur toute la France sans leur imposer de contraintes. Nous mettons a votre disposition des espaces ICI relais dont la localisation et les larges plages horaires d’ouverture vont faciliter la vie de vos clients.

Avec ICI relais, c’est l’assurance pour vous et votre client d’avoir  :

• un accès a un réseau intégré de transport totalement sécurisé : vidéo-suivi des colis, 7 scannages, procédure de sécurisation…
• une information maitrisée : le client destinataire est automatiquement avise par courriel ou SMS de l’arrivée de son colis en espace relais.
• une disponibilité de votre colis : le colis est conserve jusqu’à 9 jours dans l’espace relais
• une transparence d’information : accès au tracing complet de votre colis jusqu’à sa preuve de livraison

Le module Bysoft ICI relais pour Magento

Le module ICI relais vous permet d’ajouter un nouveau mode de livraison a votre site marchand avec deux grandes fonctionnalités :  la recherche et sélection d’un espace ICI relais,  et un tracing complet de la commande. Pour toute question relative a l’intégration du module, ou pour l’ouverture d’un compte client ICI relais, veuillez nous contacter a l’adresse : ensavoirplus@icirelais.com .
Plus d’information sur www.icirelais.com

Le module “Bysoft ICI relais” a été validé par les équipes de Bysoft sur les versions 1.3.x et 1.4.x de Magento, dans sa version communautaire. Après installation du module via la plateforme MagentoConnect, le marchand peut paramétrer directement son module via son interface d’administration habituelle, en y saisissant ses identifiants de connexion, fournis par ICI relais.

Pour garantir de bonnes performances d’affichage lors de la recherche d’un espace ICI relais, les bases de données d’espaces ICI relais sont téléchargées depuis un Webservice et collectées dans la base de données du marchand. Cette mise a jour peut, par la suite, se faire manuellement depuis l’interface d’administration du site ou bien être programmée via une tache automatique au niveau du serveur (CRONjob).

Fonctionnement

Lorsque le client passe commande, il choisit le mode de livraison “Livraison en espace ICI relais”. Un formulaire lui permet alors de saisir une adresse postale, afin de trouver l’espace ICI relais le plus proche de son lieu de livraison préféré (domicile, lieu de travail, lieu de vacances…).

En fonction de cette adresse postale, le module va déterminer, suivant des règles métiers spécifiques (délais de livraison, fermeture des espaces relais, périodes de congés…) une liste ordonnée d’espaces ICI relais les plus proches du lieu choisi. Pour chaque espace ICI relais sont indiques :

• ses coordonnées
• une carte de géolocalisation
• les horaires d’ouverture et les dates de fermeture

Le module comporte un système de Backup au Code postal. Concrètement, il s’agit de garantir l’affichage d’une liste d’espaces ICI relais même si l’adresse postale du client a été mal saisie ou qu’elle est introuvable. Ce Backup se base alors uniquement sur le Code Postal pour déterminer une liste d’espaces ICI relais de “secours” et la proposer au client. Cette garantie de service empêche ainsi une baisse du taux de transformation liée a une adresse invalide.

Tracing Colis

Après enregistrement d’une commande, le marchand peut, via l’interface de Magento, créer des expéditions pour cette commande. Le module Bysoft ICI relais permet au marchand d’associer un numéro de colis ICI relais a une expédition. Ce numéro, reconnu par le module, propose au client, depuis son compte, un lien direct de suivi. En cliquant sur son numéro de colis, il arrive alors directement sur la page de suivi du site www.icirelais.com, sans avoir a ressaisir quoi que ce soit. En un clic, il accède donc a l’état de livraison.

(c) BYSOFT http://www.bysoft.fr

(c) EXAPAQ SAS, société par actions simplifiées, au capital de 18.500.000 euros, dont le siège social est situe 2 ter rue Louis Armand a Paris (75015), immatriculée au registre du commerce et des sociétés de Paris sous le numéro 444 420 830

Etude de cas sur la Segmentation Clients

Un peu d’histoire
La version Entreprise de Magento comporte une fonctionnalité très intéressante pour les marchands : la Segmentation Dynamique des Clients. Mais que se cache-t-il donc derrière ce superbe titre ?

A l’origine, il y a la gestion des Groupes de Clients, disponible dans toute solution Ecommerce qui se respecte. Cela permet aux administrateurs du site Ecommerce d’associer ses clients à des groupes de clients, pour les classifier dans des ensembles (typiquement, les clients « normaux », les clients « professionnels », les « revendeurs », les « distributeurs »…etc.). Par défaut, l’assignation d’un client à un groupe donné se fait manuellement en BackOffice. Des développements sur-mesure sont ensuite possibles, pour assigner un client à tel ou tel groupe en fonction de règles préétablies (par exemple, assigner automatiquement les clients à un groupe « Professionnels » s’ils ont saisi un numéro de TVA Intracom dans le formulaire d’inscription…). Mais une fois que le client est assigné à son groupe, c’est plus ou moins gravé dans le marbre. Pour le déplacer à nouveau, il faut le faire manuellement, ou implémenter une nouvelle règle lancée sur un nouvel évènement…

Bref, pas très pratique tout ça… Sans compter qu’un client ne peut en général être affecté qu’à un groupe, et pas à plusieurs. Impossible dans ce cas d’avoir un groupe dédié à des clients Pros, et un groupe dédié aux meilleurs clients, avec des clients pouvant appartenir à ces deux groupes.

La solution
Heureusement, l’équipe de Varien a eu l’excellente idée d’imaginer pour vous (et pour nous aussi… ) un module permettant, à partir d’une règle prédéfinie par le marchand, de rechercher dynamiquement tous les clients qui remplissent tous les critères de cette règle, et de les associer à ce groupe de clients dynamique. Concrètement, vous définissez une règle d’affectation en BackOffice, par exemple « Tous les clients qui ont commandé pour plus de 500 euros sur mon site », vous lancez la moulinette, et vous obtenez la liste de tous les clients qui ont commandé pour plus de 500 euros sur votre site. Souple, facile, rapide, précis.

Il est possible de créer autant de règles que vous le voulez en BackOffice. De plus, les clients peuvent ainsi appartenir à plusieurs segments de clients, ce qui vous permet de générer des listes de clients aussi précises que possibles, sans risque d’oublis. Les conditions sont créées en BackOffice grâce au même moteur algorithmique de règles que pour la gestion des promotions de Magento.

Un cas concret
L’un de nos clients est venu nous voir avec le besoin de créer des promotions progressives sur montants de commandes cumulés. La règle complète s’apparente à ceci :

• -5% de remise immédiate dès 100€ d’achats
• -7,5% de remise immédiate dès 500€ d’achats
• -10% de remise immédiate dès 750€ d’achats
• -15% de remise immédiate dès 1000€ d’achats
• -20% de remise immédiate dès 3000€ d’achats

Les remises sont valables dès le premier achat et les totaux des commandes sont cumulables. De plus, les totaux sont remis à zéro si le client n’a passé aucune commande dans les six derniers mois.

La Segmentation des Clients de Magento Enterprise Edition permet de mettre en place ces règles de manière dynamique et souple.

Définir les segments
La première étape est de définir ces règles sur le BackOffice de Magento EE. On se rend dans le menu « Clients » => « Segments de Clients », et on crée une nouvelle règle en cliquant sur « Nouveau Segment ».
Trois onglets sont présents sur la gauche :

• Propriétés Générales     => définissez ici les infos générales de votre segment

1. Nom du segment    => Choisissez ici un nom pour votre segment
2. Description        => Donnez une description
3. Assigné au site        => Si le segment doit se limiter à un site en particulier, choisissez-le ici
4. Statut            => Choisissez d’activer ou désactiver votre segment

• Conditions        => définissez ici l’algorithme de vos critères de segmentation

• Clients correspondant    => après vérification des critères, la liste des clients correspondant s’affichera ici. Elle est pour le moment vide.

Les conditions peuvent être définies sur plusieurs entités :

• •    Infos Client

1. Groupe du Client (hé oui, c’est cumulatif avec la notion de Groupe Clients standard…)
2. Date de naissance
3. Adresse de facturation par défaut
4. Adresse de livraison par défaut
5. Email
6. Prénom
7. Nom
8. Inscription à la newsletter
9. Crédit en cours
10. Adresses

• Panier en cours du client

1. Total du panier en cours (sur le total, sous-total, taxes, frais de port, crédit, carte cadeau…)
2. Nombre de produits différents dans le panier
3. Quantité de produits dans le panier

• Listes de produits du client

1. Produits présents/absents dans le panier ou dans la wishlist (avec filtres sur l’ensemble des attributs des produits
2. Historique des produits visualisés ou commandés

• Commandes du client

1. Adresse utilisée pour une commande (avec filtres sur tous les éléments constitutifs d’une adresse : ville, pays, téléphone, société, email, nom…)
2. Montant total de commandes (avec filtres sur les statuts de commandes, sur les périodes de commandes, les dates de commandes…)
3. Nombre de commandes (avec mêmes filtres que ci-dessus)
4. Quantités commandées (avec mêmes filtres que ci-dessus)

Tous ces critères peuvent être combinés et cumulés entre eux.

Pour en revenir à notre client, on a donc défini toutes les règles nécessaires, en se basant sur l’algorithme suivant :

Si on reprend cette règle pas à pas, on voit que l’on ne prend que les clients :

• Dont le total des commandes est supérieur ou égal à 500€, en ne prenant que les commandes « Terminées » (hé oui, on ne prend en compte que les commandes réellement payées pour faire monter le client dans les segments de promotion…), et sur les 180 derniers jours (= 6 mois)
• Dont le total des commandes est inférieur à 750€, en ne prenant que les commandes « Terminées »
• Ayant passé au moins une commande sur les 180 derniers jours

Cela correspond à la seconde règle énoncée dans le besoin du client, pour rappel : « -7,5% de remise immédiate dès 500€ d’achats », et on fait de même pour toutes les autres règles. On n’a pas encore défini les 7,5% de remise me direz-vous, et vous aurez raison, on y va de ce pas, mais je tiens à insister sur le caractère extrêmement souple de cette fonction de Segmentation des Clients. Les règles sont totalement personnalisables par la suite, depuis le BackOffice, sans avoir aucune connaissance technique. Le marchand peut donc ensuite faire évoluer ces règles avec son business model, sans aucune intervention de la part de l’intégrateur, en toute autonomie.

En cliquant alors sur le bouton « Match Customers », la liste des clients matchant les critères sera alors mise à jour, et vous pourrez la consulter et l’exporter.

Définir les réductions associées
Bon on a défini toutes nos règles, on va donc maintenant créer les promotions correspondantes. Pour cela, on se rend, en BackOffice, dans le menu « Promotions » => « Règles de prix Panier », et on crée une nouvelle règle.

Il suffit de définir comme conditions le fait de n’appliquer la réduction qu’aux clients du Segment correspondant, et que cela ne s’applique qu’aux paniers situés entre 500 et 750€ :

NB : Sur l’exemple ci-dessus, dans « Customer Segment matches 1 », le chiffre « 1 » est en fait l’identifiant du segment de clients que vous avez créé précédemment. Une interface permet de le sélectionner directement :

L’onglet « Action » permettra de définir le montant de la réduction, ici 7.5% :

Quelques astuces de mise en place
A ce moment-là, la question qui devrait vous venir à l’esprit, c’est « C’est génial, mais s’il faut cliquer sur « Match Customers » toutes les 5 minutes pour mettre à jour les segments de clients, ça n’a plus rien d’automatique ». Et je vous répondrai : « C’est pas faux… »

Mais l’équipe de Varien a anticipé votre question et remonté dans un fichier de configuration la gestion des évènements déclenchant le matching des clients. C’est-à-dire que vous pouvez définir quels évènements précisément vont déclencher un « Match des clients », en FrontOffice comme en BackOffice :