Le logiciel E-connecteur dispose d’un kit de développement (SDK) permettant entre autre, de modifier à la volée des données échangées avec les webservices E-commerce. Ce kit est disponible sous forme de module additionnel. La documentation de ce SDK est disponible sur notre base de connaissances.
Voyons aujourd’hui un cas pratique d’utilisation que l’on a pu mettre en œuvre pour l’un de nos clients.
Au sommaire
Contexte
Avec E-connecteur B2B, il est possible d’envoyer les clients de sa gestion commerciale sur le site e-commerce afin de transférer des grilles de tarifs des produits.
Quand on utilise des grilles de prix par familles ou groupe de client avec Prestashop, on affecte des prix spécifiques à des groupes au niveau des produits. Ensuite, au niveau du client, il est nécessaire de changer le groupe par défaut du client.
Il faut comprendre que Prestashop utilise les groupes pour 2 choses. Tout d’abord pour restreindre l’affichage de certains prix, mais aussi pour définir des règles de visibilité des catégories de produits et des modules.
Bref, si vous souhaitez faire des grilles de prix par groupe, il faudra aussi pas mal modifier Prestashop pour conserver la visibilité adéquate des produits, catégories, modules, boutons d’achat, etc … D’autres solutions sont disponibles dans notre base de connaissance, mais toutes nécessitent une intervention technique de la part d’un développeur Prestashop.
Cela peut passer par une modification de template, par des modules d’affectation automatique de groupes, etc … Cette stratégie doit être mise en place indépendamment d’une connexion avec votre logiciel de gestion commerciale.
La solution à mon sens la meilleure est de mettre en place un moteur de sélection des prix spécifiques, en fonction des priorités propres de l’entreprise. Cela évite à gérer les cascades de droits sur la visibilité des produits. Cependant, dans certains cas vous préférerez recourir à la solution de gérer les visibilités et droits des modules. On voit cette solution quand :
- les groupes n’évoluent pas après la création de la boutique,
- les tarifs étaient plutôt saisis manuellement dans Prestashop, sans liaison avec un ERP.
Liste non exhaustive bien sûr !
Problématique
Si vous optez pour la dernière solution, vous pouvez aussi choisir une affectation automatique, sur le site Prestashop des groupes de clients à l’aide d’un développement ou d’un module. C’est dans ce contexte que l’on peut avoir un problème de données hétérogènes lorsque l’on automatise les échanges de données clients avec E-connecteur.
En effet, vous vous retrouvez à définir des règles de catégorisation clients différentes entre le logiciel de gestion commerciale et le site e-commerce.
Quand on met en place un outil d’échange de données, quel qu’il soit, on définit forcément une base de données maitre, qui, en cas de conflit entre les données, aura raison et écrasera les données de toutes les bases esclaves.
Si vous avez suivi, là, on modifie des données clients de part et d’autre, il y a donc conflit et dans ce cas E-connecteur prend comme valeur de référence, les données maitres, celles de la gestion commerciale.
La problématique est là, c’est que quand une donnée est synchronisée, il ne faut pas vouloir la modifier sur une base esclave (Prestashop), mais sur la base maitre (la gestion commerciale).
Dans la pratique, on peut vouloir personnaliser le flux envoyé à Prestashop pour gérer des exceptions de mise à jour. Le SDK E-connecteur permet justement cela, voyons comment.
Principe technique
Le webservice Prestashop est un webservice de type REST échangeant des données XML. Le langage XML peut être modifié grâce au langage XSLT. C’est un outil très puissant, dont voilà un peu de documentation. Le SDK E-connecteur permet à la réception ou à l’envoi des données, d’appliquer le script XSLT aux données XML.
Avec le webservice Prestashop, si on ne veut pas modifier une donnée, il suffit soit de la renvoyer à l’identique, soit de supprimer le nœud en question. Ici il faudra donc supprimer les nœuds que l’on ne souhaite pas mettre à jour.
Réalisation
C’est la méthode customers de Prestashop qui permet la mise à jour d’un client. Avec Prestashop, une mise à jour via son webservice est une requête http de type put.
Il y a deux informations sur les groupes : id_default_group et associations/groups.
Etape 1 : recopier l’intégralité des données XML
En XSLT, il faut utiliser la méthode template. Le fichier XSLT va ressembler à cela :
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output omit-xml-declaration="yes" indent="yes"/>
<xsl:strip-space elements="*"/>
<xsl:template match="node()|@*">
<xsl:copy>
<xsl:apply-templates select="node()|@*"/>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>
Etape 2 : supprimer les groupes et groupe par défaut
Ensuite, pour supprimer les nœuds XML que je ne souhaite pas, il ne faut pas les recopier :
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output omit-xml-declaration="yes" indent="yes"/>
<xsl:strip-space elements="*"/>
<xsl:template match="node()|@*">
<xsl:copy>
<xsl:apply-templates select="node()|@*"/>
</xsl:copy>
</xsl:template>
<xsl:template match="/prestashop/customer/id_default_group">
</xsl:template>
<xsl:template match="/prestashop/customer/associations/groups">
</xsl:template>
</xsl:stylesheet>
Mon fichier XSLT est prêt, je n’ai plus qu’a le tester. Dans le dépôt Mercurial, vous trouverez un script php permettant de tester un fichier XSLT (fichier test.php).
Déploiement
Rien de plus simple, c’est indiqué dans la documentation, il suffit de déplacer le fichier XSLT dans le dossier approprié et y appliquer la charte de nommage, dans notre cas :
SDK_IDinstallation_customers_put_before.xsl
Il n’y a plus qu’à tester, en prenant bien sûr garde d’avoir fait une sauvegarde avant !
