Pourquoi CommerceML est obsolète et comment le remplacer

Il y a trois mois, une connaissance m'a appelé - le propriétaire d'une entreprise de vente en gros d'huiles et de lubrifiants industriels. Catalogue pour seize mille postes, WooCommerce, sept ans de fonctionnement du site, trafic stable, les commandes arrivent. Il semblerait que tout va bien. Mais il n’a pas appelé parce que sa vie était belle. "Écoutez", dit-il, "mon catalogue est à nouveau cassé. L'échange avec 1C a gelé à mi-chemin, la moitié des marchandises avaient disparu, les images avaient disparu, les prix étaient vieux. Les gestionnaires vérifient manuellement chaque article. Nous passons trois jours à restaurer ce qui aurait dû être mis à jour en une heure. Peut-être qu'il y a quelque chose à la place de CommerceML, ou est-ce normal et tout le monde vit comme ça ? "

Je ne lui ai pas dit que « tout le monde vit comme ça ». Parce que ce n'est pas vrai. C’est ainsi que vivent les gens bloqués en 2005, année de création du format CommerceML. Oui, vous avez bien entendu : la technologie que des milliers de boutiques en ligne utilisent aujourd'hui pour échanger des données entre 1C et le site a été conçue il y a vingt et un ans. À une époque où l’iPhone n’existait pas encore, Google venait de s’introduire en bourse, et le mot « cloud » désignait un phénomène exclusivement atmosphérique. Et ce format, né dans une ère technologique complètement différente, reste toujours la norme de facto pour l'intégration de 1C aux boutiques en ligne en Russie et dans la CEI. Je pense qu'il est temps d'avoir une conversation honnête sur pourquoi cela s'est produit, pourquoi cela ne fonctionne plus et que faire à ce sujet.

Je ne suis ni théoricien ni évangéliste d'une technologie particulière. J'ai vécu avec CommerceML pendant sept ans dans une production réelle - avec ses problèmes, ses pannes, ses produits en double et ses nuits blanches où j'avais un besoin urgent de réparer le catalogue avant l'envoi du matin. Et à un moment donné, j'ai réalisé qu'il était inutile de traiter les symptômes - il fallait changer toute l'approche. Cet article raconte comment nous sommes arrivés à cette décision, ce que nous avons vécu et ce que nous avons finalement obtenu. Si vous avez également des difficultés avec l'échange de 1C et du site, cela vous évitera peut-être ces mêmes trois jours de restauration nerveuse du catalogue.

Comment nous en sommes arrivés à ce point de la vie : sept ans sur CommerceML

Pour comprendre pourquoi CommerceML pose problème, vous devez d'abord comprendre son fonctionnement. L'idée est simple : 1C génère des fichiers XML d'une certaine structure - catalogue de produits, offres (prix et soldes), images - et les télécharge sur le site via un script PHP spécial. Le site analyse à son tour ces fichiers XML et met à jour la base de données. Cela semble logique, non ? En 2005, c'était même élégant. XML était à la mode, l'API REST n'était pas encore devenue un standard et les catalogues des boutiques en ligne dépassaient rarement quelques milliers d'articles.

Le problème est que le monde a changé, mais pas CommerceML. Le format est resté presque le même qu’il a été créé. Oui, il y a eu des mises à jour mineures, oui, la version 2.10 est apparue, mais architecturalement c'est toujours la même approche : générer un XML géant, le transférer entièrement sur le site, l'analyser entièrement et mettre à jour la base de données. C'est comme envoyer par e-mail l'intégralité du fichier à un collègue chaque fois que vous souhaitez mettre à jour une ligne dans une feuille de calcul Excel de dix mille lignes. Cela semble absurde ? Mais c'est exactement ainsi que fonctionne CommerceML.

Lorsque nous avons démarré ce projet, le catalogue comprenait environ quatre mille articles. CommerceML a fait le travail. L'échange a duré environ quinze à vingt minutes, les erreurs étaient rares et c'était vivable. Nous avons utilisé l'un des plugins les plus populaires pour WooCommerce - woocommerce-synchronization-1c. Il a fait son travail honnêtement : il a accepté le XML de 1C, l'a analysé, créé des produits, mis à jour les prix. Pendant sept ans, il a subi des dizaines de mises à jour de WordPress, WooCommerce, PHP - et à chaque fois quelque chose tombait en panne, mais dans l'ensemble, cela fonctionnait.

Et puis le catalogue s'est agrandi jusqu'à seize mille articles. Et c’est l’enfer qui s’est déchaîné.

La première chose que nous avons rencontrée a été le temps d'échange. Le déchargement complet d'un catalogue ne prenait plus vingt minutes, mais deux à trois heures. Parfois quatre. De plus, CommerceML est conçu de telle manière que chaque échange est en fait un déchargement complet. Oui, il existe formellement un mécanisme « d'échange de modifications », mais dans la pratique, il fonctionne de manière si peu fiable que la plupart des paramètres 1C utilisent un déchargement complet. Et imaginez : chaque nuit (et l'échange doit être mis en place la nuit, car pendant la journée cela crée une charge sur le serveur et ralentit le site) 1C télécharge seize mille produits dans des fichiers XML d'un volume total d'environ un gigaoctet, puis les télécharge sur le serveur, et le script PHP essaie de tout traiter. PHP, qui a par défaut une limite de temps d'exécution de script de trente secondes et une limite de mémoire de 256 mégaoctets. Bien sûr, nous avons augmenté les limites - à la fois à 512 et à un gigaoctet - mais ce ne sont que des béquilles et non une solution.

La seconde concerne les produits en double. C'est peut-être le problème le plus douloureux de CommerceML, et pour une raison quelconque, peu de gens en parlent ouvertement. Le mécanisme est le suivant : chaque produit en 1C a un identifiant unique (GUID). Lors du téléchargement, ce GUID est transmis au site et le plugin l'utilise pour rechercher un produit existant à mettre à jour. Cela semble fiable ? Peu importe comment c'est. Dès qu'un produit dans 1C change d'une certaine manière - par exemple, il a été déplacé vers un autre groupe, ou le type d'élément a été modifié, ou une sorte de réorganisation interne du répertoire s'est produite - et le GUID peut changer. Ou, pire encore, restent les mêmes, mais le plugin ne le trouve pas en raison de champs méta désynchronisés dans WordPress. Résultat : un doublon apparaît sur le site. Produit portant le même nom mais un identifiant différent. Et quand vous avez seize mille positions, il est presque impossible de détecter manuellement ces doublons. Nous avons trouvé des situations dans lesquelles la même huile moteur était présente sur le site en triple exemplaire - avec des prix différents, des stocks différents et des URL différentes. C'est un désastre pour le référencement, une confusion pour les utilisateurs et un casse-tête pour les managers.

Le troisième problème concerne les images. CommerceML fournit des images de produits ainsi que des fichiers XML sous forme de pièces jointes binaires. En théorie, c'est pratique - tout est dans un seul paquet. En pratique, avec un catalogue de seize mille articles, où chaque produit comporte de une à cinq images, le volume de déchargement devient monstrueux. Mais ce n’est même pas l’essentiel. L'essentiel est le mécanisme de mise à jour des images. CommerceML ne dispose pas d'un moyen fiable pour déterminer si l'image d'un produit a changé ou non. Par conséquent, de nombreuses implémentations téléchargent simplement à nouveau toutes les images à chaque échange. Il s'agit de gigaoctets de trafic, d'heures de travail de script et, ce qui est le plus désagréable, de pertes périodiques d'images. Nous découvrons régulièrement que les photos de certains produits disparaissent après échange. Parfois à cause d'un timeout, parfois à cause d'une erreur d'analyse, parfois sans raison apparente. Les responsables ont passé des heures à télécharger manuellement des images que l'échange avait « perdues ».

Le quatrième problème concerne les champs personnalisés. C'est ce qui m'a finalement convaincu que je devais mettre fin à CommerceML. Notre société vend des huiles et lubrifiants industriels - un produit aux caractéristiques techniques complexes. Viscosité à différentes températures, point d'écoulement, point d'éclair, classe de viscosité ISO, agréments des équipementiers, GOST ou TU, type de base (minérale, synthétique, semi-synthétique), densité, domaine d'application - chaque produit possède des dizaines de paramètres spécifiques. Dans 1C, tous ces paramètres sont stockés sous forme de « détails supplémentaires » - un système flexible qui vous permet de créer des caractéristiques arbitraires pour tout type d'élément. Essayez maintenant de transmettre tout cela via CommerceML.

CommerceML a un schéma rigide. Il existe un certain ensemble de champs qu'il peut transférer : titre, description, article, groupe, images, prix, solde et plusieurs détails standard. Des champs personnalisés ? Formellement - à travers le mécanisme des « propriétés » et des « valeurs de propriété ». Mais la mise en œuvre est si rigide qu'en pratique, il est presque impossible de transmettre des données structurées complexes - comme plusieurs types de viscosité à différentes températures - sans une personnalisation sérieuse du traitement côté 1C. Et la personnalisation du traitement nécessite un programmeur 1C, qui coûte trois mille roubles par heure et qui doit expliquer la structure de votre site. Et chaque fois que vous ajoutez un nouveau paramètre de produit dans 1C, cette personnalisation doit être mise à jour. Un cercle vicieux.

Je me souviens du moment où nous avons essayé d'ajouter un nouvel attribut au site - les approbations des fabricants (c'est-à-dire une liste de marques d'équipements pour lesquelles cette huile convient). Dans 1C, cela était stocké sous forme de section tabulaire répertoriant les tolérances. CommerceML ne sait tout simplement pas comment transmettre des parties de table. Nous avons passé deux semaines à négocier avec un programmeur 1C qui a essayé de « regrouper » ces données dans des propriétés CommerceML standard, créant ainsi un système complexe de valeurs composites, qui ont ensuite dû être analysées côté site. Le résultat a fonctionné, mais était si fragile qu'il cassait une mise à jour 1C sur deux.

Et cinquièmement - rompt avec les grands répertoires. Il s'agit d'un problème technique, mais il a des implications commerciales directes. Le script PHP qui traite le XML de CommerceML fonctionne au sein d'une seule requête HTTP. Oui, de nombreuses implémentations divisent le traitement en morceaux et utilisent des importations étape par étape, mais le mécanisme de base reste le même : le script doit lire le XML, l'analyser, le faire correspondre avec les produits existants dans la base de données, mettre à jour ou créer de nouveaux enregistrements - le tout dans les contraintes de PHP. Avec un catalogue de seize mille positions avec des dizaines d'attributs pour chaque produit, le script plantait régulièrement. Parfois silencieusement, il a simplement cessé de fonctionner en raison d'un délai d'attente, laissant le répertoire à moitié mis à jour. Parfois avec une erreur de mémoire. Parfois à cause d'un verrouillage de la base de données - parce que seize mille requêtes INSERT/UPDATE consécutives créent une charge importante sur MySQL. Et chacun de ces échecs signifiait que certains produits étaient mis à jour, mais d'autres non. Les prix de certains produits sont actuels, tandis que d'autres sont ceux d'hier. Le reste a été mis à jour à certains endroits, pas à d’autres. Les gestionnaires ne savent pas à quelles données du site on peut se fier. Les acheteurs passent des commandes pour des produits qui ne sont plus en stock. Il ne s’agit pas d’inconvénients techniques, mais de pertes d’argent et de réputation.

Quand j'ai arrêté de traiter les symptômes

Voilà : j'ai longtemps essayé de résoudre chaque problème séparément. Produits en double ? Écrivons un script pour vérifier les doublons. Des images perdues ? Ajoutons la journalisation et le rechargement. Des délais d'attente ? Augmentons les limites PHP et divisons l'échange en portions plus petites. Des champs personnalisés ? Nous embaucherons un programmeur 1C pour personnaliser le traitement. À chaque fois, un autre patch sur l'ancienne couverture. Et chaque correctif ajoutait de la complexité, créait de nouveaux points de défaillance et nécessitait une assistance. À un moment donné, nous avions un système d'échange tellement personnalisé qu'aucun nouveau développeur ne pouvait le comprendre sans une semaine d'immersion. Bien sûr, il n'y avait aucune documentation - parce que le système s'est développé de manière organique, de problème en problème, et personne n'avait prévu qu'il devienne aussi complexe.

Le tournant s'est produit lorsque nous avons perdu une commande importante. Une entreprise cliente a passé une commande pour un lot d'huile hydraulique - deux cents litres, une quantité décente. Le site indiquait « en stock » car l'échange avec 1C s'est gelé hier soir et les soldes n'ont pas été mis à jour. Mais en réalité, cette huile n'était plus dans l'entrepôt : elle avait été expédiée la veille à un autre client. Le responsable a appelé le client, s'est excusé et lui a proposé d'attendre la livraison. Le client a refusé et s'est adressé à un concurrent. Non pas parce que nous avons un mauvais produit ou des prix élevés, mais parce que notre système d'échange de données n'a pas pu mettre à jour le solde d'un produit à temps. J’ai alors pensé : combien de ces cas ne remarquons-nous même pas ? Combien de clients voient « en stock », ajoutent l’article à leur panier, puis le responsable les rappelle avec des excuses ? Et combien d’entre eux partent simplement en silence sans laisser d’ordre ?

C'est à ce moment-là que j'ai commencé à réfléchir sérieusement à des alternatives. Ce n'est pas un autre plugin pour CommerceML - il y en a beaucoup, mais ils sont tous limités par les capacités du format lui-même. Et sur une approche fondamentalement différente de l'intégration de 1C et du site. Et c'est ici que j'ai remarqué OData pour la première fois.

Pour ceux qui ne l'ont pas rencontré : OData est un protocole standard de création et d'utilisation d'API REST. Il a été développé par Microsoft et est largement utilisé dans le monde entier pour accéder aux données. Le mot clé ici est « standard ». Il ne s’agit pas d’un format propriétaire d’une entreprise, ni d’une solution de fortune pour une tâche spécifique. Il s'agit d'un protocole ouvert avec une spécification claire, la prise en charge de la pagination, des filtres, du tri, de la sélection de champs spécifiques - tout ce que vous attendez d'une API moderne. Et voici ce qui est important : 1C prend en charge OData dès le départ. A partir de la version 8.3, toute configuration 1C peut donner accès à ses données via l'interface OData. Sans traitement supplémentaire, sans composants tiers - activez simplement la publication OData dans les paramètres du serveur Web 1C et vous obtenez une API REST à part entière pour tous les répertoires, documents et registres de votre base de données.

Lorsque j'ai essayé pour la première fois d'interroger un catalogue d'articles via OData, j'ai été étonné. Au lieu d'attendre que 1C génère un fichier XML de la taille d'un gigaoctet, j'ai envoyé une requête HTTP et une seconde plus tard, j'ai reçu JSON avec les cent premiers produits. J'ai envoyé la demande suivante et j'ai reçu la centaine suivante. Et chaque requête renvoyait exactement les données dont j'avais besoin : pas l'intégralité du catalogue, mais des champs spécifiques pour des produits spécifiques, filtrés selon des critères spécifiques. Je pourrais demander « donnez-moi tous les produits du groupe Huiles hydrauliques dont le prix a changé au cours des deux dernières heures » et obtenir une réponse en quelques secondes. Essayez ceci avec CommerceML.

Mais ne me permettez pas d'idéaliser. OData n’est pas un bouton magique « bien faire ». Il s’agit d’un outil qui nécessite une approche différente de l’intégration. Et y passer ne consiste pas simplement à remplacer un plugin par un autre. Il s'agit d'un changement dans l'architecture d'échange de données entre 1C et le site. Voyons quelle est la différence fondamentale.

CommerceML fonctionne sur le principe du « batch upload ». 1C génère un package de données (fichiers XML), le télécharge sur le site et le site le traite. Il s’agit d’une opération par lots, unidirectionnelle et hors ligne. 1C ne sait pas ce qui se passe sur le site. Le site ne sait pas ce qui se passe en 1C entre les échanges. Les données sont synchronisées avec un délai - d'une heure à un jour, selon le calendrier. OData fonctionne différemment. Il s'agit d'une API - une interface de programmation pour un accès direct aux données. Le site peut accéder à 1C à tout moment et recevoir des informations à jour : le prix actuel du produit, le solde actuel dans l'entrepôt, une liste de caractéristiques, des images. Pas besoin d'attendre le téléchargement, pas besoin d'analyser XML, pas besoin de stocker des fichiers intermédiaires. Les données sont disponibles en temps réel.

Et ici se pose la première question que tout le monde me pose : "Et la charge sur 1C ? Si le site extrait constamment des requêtes 1C, il tuera la base de données !" Bonne question. Réponse : vous n'avez pas besoin de retirer 1C à chaque fois que vous consultez un produit sur le site. Une architecture appropriée est différente. Les données produits sont importées de 1C dans la base de données du site via OData - exactement de la même manière qu'avec CommerceML. La différence est qu'avec OData, vous pouvez le faire de manière incrémentielle. Ne téléchargez pas l’intégralité du catalogue, mais demandez uniquement des modifications : « donnez-moi les produits dont la date de modification est supérieure à l’heure de la dernière synchronisation ». Pour un catalogue de seize mille articles, où dix à vingt articles changent généralement par heure, cela signifie traiter dix à vingt entrées au lieu de seize mille. La différence de performance est de deux à trois ordres de grandeur.

Ajoutez maintenant des webhooks à cela. Webhook est un mécanisme dans lequel 1C lui-même informe le site des modifications. Le prix du produit a-t-il changé ? 1C envoie une requête POST au site : « produit tel ou tel, nouveau prix tel ou tel ». Le stock en stock a-t-il été mis à jour ? Une autre requête POST. Le site reçoit une notification et met à jour le produit spécifique en quelques millisecondes. Il n'est pas nécessaire d'attendre les échanges programmés, ni de parcourir tout l'annuaire à la recherche de modifications. Les données sur le site sont mises à jour en temps réel - avec un délai de quelques secondes et non d'heures. Vous vous souvenez de ce cas de commande perdue en raison de soldes périmés ? Cela n'arriverait pas avec les webhooks. Le solde serait mis à jour sur le site Web au moment où les marchandises sont expédiées en 1C.

Je dois être honnête : configurer des webhooks depuis 1C n'est pas une tâche anodine. Dans les configurations en boîte (UT, ERP, KA), un tel mécanisme n'existe pas. Vous devez soit rédiger un abonnement à un événement dans 1C, qui enverra une requête HTTP lorsqu'un produit change, soit utiliser une extension. Nous utilisons une extension qui se déclenche lors du traitement de documents affectant les soldes et les prix, et envoie une notification au site. Le développement a pris quelques jours, mais le résultat en vaut la peine - désormais, le reste du site est mis à jour dans les cinq à dix secondes après la publication du document dans 1C. Les gestionnaires ont cessé de vérifier manuellement la pertinence des données sur le site. Les clients ont cessé de recevoir des appels d'excuses. Il ne s’agit pas seulement d’une amélioration technique, mais d’un changement qualitatif dans la manière dont l’entreprise fonctionne.

Une cartographie qui ne rompt pas à chaque éternuement

L'un des sujets les plus pénibles dans l'intégration de 1C et du site est la correspondance des champs. Dans 1C, les données sont stockées dans une structure, sur le site Web - dans une autre. CommerceML propose un schéma rigide : le nom du produit est dans le champ « Nom », la description est dans le champ « Description », l'article est dans le champ « Article », etc. Si votre structure de données diffère ne serait-ce que légèrement de ce que suppose CommerceML, les problèmes commencent.

Voici un exemple précis issu de notre pratique. En 1C, notre produit « Huile hydraulique HVLP 46 » porte le nom complet « Huile hydraulique HVLP 46 (fût de 200 l) » et le nom abrégé « HVLP 46 ». CommerceML transmet un champ « Nom » – lequel ? La valeur par défaut est pleine. Mais sur le site Web, nous souhaitons afficher un nom dans le titre du produit, un autre dans le catalogue et un troisième dans le fil d'Ariane. Avec CommerceML, pour cela, vous devez soit modifier le traitement de déchargement dans 1C, soit analyser les chaînes côté site, en extrayant le volume et l'unité de mesure du nom complet. Les deux options sont des béquilles. Avec OData, j'interroge simplement les deux champs : « Description » et « NameFull » - et je les mappe aux champs WooCommerce requis. L'un dans le titre, l'autre dans le champ méta. Pas de personnalisation 1C, pas d'analyse de chaînes, pas d'habitués fragiles.

Mais ceci est un exemple simple. La situation avec des détails supplémentaires est beaucoup plus intéressante. Comme je l'ai déjà dit, en 1C nos produits ont des dizaines de caractéristiques techniques. Viscosité, densité, températures, tolérances - tout cela est stocké dans la partie tabulaire « Détails supplémentaires » de l'article. Chaque attribut possède une clé (GUID du type de caractéristique) et une valeur (chaîne, numéro ou lien vers un élément d'annuaire). CommerceML ne sait pas comment travailler directement avec cette structure - vous avez besoin d'un programmeur 1C qui écrira un traitement qui « étend » la partie tabulaire dans l'ensemble de propriétés CommerceML. Et chaque fois qu'un nouvel attribut est ajouté à 1C, ce traitement doit être mis à jour.

Ce n'est pas le cas avec OData. OData fournit des détails supplémentaires sous la forme d'un tableau imbriqué d'objets, chacun avec une clé et une valeur. Côté site, nous lisons simplement ce tableau et mappons chaque attribut à l'attribut WooCommerce correspondant. Et voici la partie amusante : la découverte automatique. Notre module, lors de la première connexion à 1C via OData, analyse automatiquement les métadonnées de la base de données, trouve tous les types de caractéristiques du produit et propose une cartographie : "J'ai trouvé 99 caractéristiques uniques dans 1C. Les voici. Lesquelles dois-je créer comme attributs WooCommerce ? Quel type de méta-champs ? Lesquelles dois-je ignorer ? Vous configurez la correspondance une fois, puis elle fonctionne automatiquement. Avez-vous ajouté un nouvel attribut "Classe de propreté NAS" à 1C ? Lors de la prochaine synchronisation, le module détectera un nouvel attribut et proposera de créer un attribut pour celui-ci sur le site sans programmeur 1C, sans traitement de mise à jour, sans configuration manuelle.

Nous avons trouvé 99 caractéristiques uniques dans la base de données 1C et créé 121 taxonomies à partir d'elles dans WooCommerce. Pourquoi 121 et pas 99 ? Étant donné que certaines caractéristiques avaient plusieurs valeurs (par exemple, les « approbations du fabricant » contenaient plusieurs valeurs pour un seul produit), il était plus pratique pour ces caractéristiques de créer des taxonomies distinctes avec des capacités de choix multiples. Avec CommerceML, une telle flexibilité n'existe tout simplement pas : vous obtenez ce que donne le traitement de téléchargement et vous ne pouvez pas modifier la logique de mappage à la volée.

Je voudrais également dire quelque chose sur la personnalisation. Dans CommerceML, le mappage est intégré au code du plugin ou au traitement 1C. Si vous souhaitez changer quel champ 1C va où sur le site, vous devez accéder au code PHP ou à la configuration 1C. Avec OData, le mappage est un paramètre dans le panneau d'administration du site. Vous voyez un tableau : à gauche se trouvent les champs 1C, à droite se trouvent les champs WooCommerce. Faites glisser, modifiez, ajoutez des règles de transformation (par exemple, « si la valeur du champ « Type d'huile » est « Minéral », écrivez la valeur « Minéral » dans l'attribut « Type de base »). Les modifications sont appliquées instantanément, sans déployer de code, sans redémarrer l'échange. C'est quelque chose qu'un gestionnaire de catalogue peut faire, pas seulement un développeur.

Je me demande pourquoi CommerceML est resté le standard pendant si longtemps, malgré toutes ses limites. Et je suis arrivé à la conclusion que la raison en est l'inertie. CommerceML est intégré aux configurations 1C standard. Cela fonctionne « prêt à l'emploi » - activez l'échange, spécifiez l'adresse du site, appuyez sur le bouton. Pas besoin de comprendre l'API, pas besoin d'écrire du code. Pour un petit magasin proposant quelques centaines de produits, c'est vraiment suffisant. Mais lorsque le catalogue s'agrandit, lorsque des attributs complexes apparaissent, lorsqu'une entreprise a besoin de données pertinentes en temps réel, les limites de CommerceML commencent à coûter de l'argent. Argent réel - sous forme de commandes perdues, de travail manuel des gestionnaires et de paiement des heures de programmeurs 1C.

À quoi ressemble la transition en pratique

Je comprends qu'à ce stade, le lecteur peut se demander : "D'accord, OData est meilleur que CommerceML, je comprends. Mais comment s'y prendre ? J'ai déjà mis en place un échange, les produits sont synchronisés, le catalogue fonctionne. Avons-nous vraiment besoin de tout démolir et de le reconstruire ?"

Non, ce n'est pas nécessaire. Et c’est peut-être là le principal argument en faveur de l’approche OData : la transition peut se faire progressivement. Vous ne désactivez pas CommerceML dès le premier jour. Vous connectez le module OData en parallèle, configurez le mappage, effectuez des tests de synchronisation, comparez les résultats - et seulement lorsque vous êtes sûr que tout fonctionne correctement, désactivez l'ancien échange.

C'est exactement ce que nous avons fait. La première étape consiste à se connecter à OData 1C et à migrer les connexions existantes. Nous avions 16 844 produits dans notre base de données WordPress, chacun comportant un champ méta_id_1cavec l'ancien identifiant de CommerceML. Le module a parcouru tous les produits, les a comparés aux enregistrements dans 1C via OData et a créé un mappage dans un tableau séparé - 18 850 enregistrements (y compris les variantes). Ce processus a duré environ deux heures, mais il s’agissait d’une opération ponctuelle.

La ​​deuxième étape consiste à configurer la synchronisation incrémentielle. Nous avons configuré le module OData pour mettre à jour uniquement les produits modifiés. Toutes les quinze minutes, le module demande à 1C : « Quels produits ont changé depuis le dernier contrôle ? OData vous permet de faire une telle demande sur une seule ligne - filtrer par date de modification. La réponse est un JSON avec dix à vingt produits, qui sont mis à jour dans WooCommerce en quelques secondes. Comparez cela à un téléchargement de catalogue complet via CommerceML, qui a pris trois heures.

La troisième étape consiste à configurer des webhooks pour les données critiques. Les prix et les soldes arrivent désormais instantanément sur le site, via les requêtes POST de 1C. Cela a nécessité une petite modification du côté 1C - une extension qui se déclenche lors de la comptabilisation des documents de vente, des reçus et des ajustements de prix. Mais cette modification se fait une seule fois, puis elle fonctionne automatiquement.

Quatrième étape : désactivation de CommerceML. Nous l'avons fait un mois après le lancement du module OData, lorsque nous étions convaincus que toutes les données étaient correctement synchronisées. Nous avons désactivé l'ancien plugin woocommerce-synchronization-1c et désactivé le traitement des échanges dans 1C. Le site a continué à fonctionner comme si de rien n'était - car les données arrivaient désormais d'une manière différente.

Qu'avons-nous obtenu comme résultat ? Regardons des chiffres précis. Le temps de synchronisation complète des annuaires a été réduit de trois à quatre heures à vingt minutes - alors que la synchronisation complète n'est nécessaire que lors de la configuration initiale ou après des modifications majeures dans la structure de l'annuaire 1C. En mode normal, une mise à jour incrémentielle prend quelques secondes. Le délai de mise à jour des prix et des soldes est passé d'un jour (échange une fois par jour) à quelques secondes (webhooks). Le nombre de doublons de produits sur trois mois est nul. Parce qu'OData utilise des identifiants 1C stables (Ref_Key), qui ne changent pas lorsqu'un produit est déplacé entre des groupes ou lorsque ses propriétés changent. Le nombre d'images perdues est nul. Parce que les images sont chargées via un point de terminaison distinct, avec le hachage du fichier vérifié, et ne sont mises à jour qu'en cas de changement réel. Le nombre d'appels à un programmeur 1C pour personnaliser un échange est nul au cours des six derniers mois. Parce que le mappage est configuré dans le panneau d'administration du site et que la découverte automatique trouve elle-même de nouveaux détails.

Mais au-delà des chiffres, il existe un autre changement difficilement quantifiable, mais qui pourrait être encore plus important. Les managers n'ont plus peur du catalogue. Auparavant, la matinée de chaque journée de travail commençait par une vérification : "l'échange a-t-il réussi ? tout est-il en place ? Les prix sont-ils actuels ? Maintenant, ils fonctionnent simplement. Les données sur le site sont toujours à jour, les produits ne sont ni perdus ni dupliqués, les attributs sont mis à jour automatiquement. Cela a libéré une quantité importante de temps de travail qui était auparavant consacré à la vérification manuelle et à la correction des erreurs d'échange. "

Séparément, je voudrais parler de l'assistant de configuration - ce que nous appelons l'assistant. L'une des raisons pour lesquelles CommerceML est si populaire est sa facilité de configuration initiale. J'ai activé l'échange en 1C, spécifié l'adresse - ça marche. Pour OData, le seuil d'entrée est plus élevé : vous devez activer la publication OData sur le serveur Web 1C, configurer les droits des utilisateurs et comprendre les points de terminaison. Nous avons passé beaucoup de temps à essayer d'abaisser ce seuil et avons fini par créer un assistant étape par étape qui guide l'utilisateur tout au long de la configuration en quinze minutes. La première étape consiste à fournir l’URL et les informations d’identification OData. L'assistant vérifie la connexion, affiche la version 1C et le nom de la base de données. La deuxième étape consiste à sélectionner des ouvrages de référence pour la synchronisation (nomenclature, caractéristiques, unités de mesure). L'assistant analyse les métadonnées 1C et affiche les entités disponibles. La troisième étape consiste à configurer le mappage de champ. L'assistant propose une cartographie par défaut (qui couvre 90% des cas) et donne la possibilité de la modifier. La quatrième étape consiste à exécuter un test d'importation de dix produits et à vérifier le résultat. La cinquième étape consiste à exécuter une importation complète. Tout. Quinze minutes, pas de programmeur 1C, pas de paramètres de traitement.

Pour être honnête, lorsque nous avons montré cet assistant aux premiers utilisateurs, la réaction a été inattendue. Je m'attendais à des questions telles que « où est le paramètre de téléchargement dans 1C ? » ou "comment puis-je modifier le traitement de l'échange ?" Au lieu de cela, les gens ont demandé : "Attendez, c'est tout ? J'ai juste indiqué l'adresse, et il a trouvé mes marchandises tout seul ? Où est le piège ? Il n'y a pas de piège. OData est une interface 1C standard qui fournit des données dans un format structuré. Il n'est pas nécessaire de configurer quoi que ce soit du côté 1C (sauf pour activer la publication OData et créer un utilisateur avec les droits nécessaires). Tous les paramètres sont du côté du site, dans le panneau d'administration WordPress familier.

Conversation honnête sur les inconvénients

Je serais malhonnête si je présentais l'approche OData comme une solution sans inconvénients. Cela a ses limites et il convient d’en discuter ouvertement.

Premièrement, OData dans 1C n'est pas idéal. Il est plus lent que les requêtes directes vers la base de données 1C car il fonctionne via HTTP et passe par une couche de logique métier. Pour une requête sur un répertoire contenant des centaines de milliers d’éléments, cela peut être perceptible. Nous résolvons ce problème par pagination - nous demandons des données par portions de 300 enregistrements et traitons chaque portion via le planificateur d'actions (planificateur de tâches intégré à WooCommerce). Cela permet de répartir la charge dans le temps et de ne bloquer ni 1C ni le site.

Deuxièmement, toutes les données ne sont pas accessibles de la même manière via OData. Par exemple, les répertoires subordonnés (comme « Caractéristiques de l'élément » dans UT) peuvent ne pas prendre en charge les opérations standard de filtrage et de sélection de champs. Nous sommes confrontés au fait qu'une requête avec des paramètres$sélectionnerou$filtrea renvoyé HTTP 400 au répertoire des caractéristiques. J'ai dû télécharger tous les enregistrements complets et filtrer du côté PHP. Ce n'est pas critique, mais vous devez être conscient de ces fonctionnalités.

Troisièmement, les images. OData dans 1C n'envoie pas les données binaires des fichiers joints via un point de terminaison standard/$valeur. Au moins, cela n'a pas fonctionné dans notre configuration. J'ai dû utiliser une extension supplémentaire (service HTTP) pour recevoir des fichiers image. Ce n'est pas techniquement difficile, mais nécessite une modification minime du côté 1C.

Quatrièmement, les webhooks nécessitent également des améliorations 1C. Les configurations typiques ne disposent pas de mécanisme intégré pour envoyer des notifications lorsque les données changent. Vous devez écrire une extension. Pour une personne familiarisée avec 1C, c'est une tâche qui prendra plusieurs heures, mais pour ceux qui travaillent uniquement avec le site internet et ne touchent pas à 1C, c'est une barrière supplémentaire. Cependant, les webhooks sont facultatifs : vous ne pouvez travailler qu'avec une synchronisation incrémentielle via OData, avec juste un délai de mise à jour des données légèrement plus long.

Cinquièmement - OData nécessite qu'un service Web soit publié sur le serveur 1C. Cela signifie que IIS ou Apache doivent être configurés pour servir les requêtes HTTP à la base de données 1C. Sur la plupart des serveurs 1C, cela a déjà été fait (par exemple, pour un client léger via le Web), mais il existe des cas où la publication Web n'est pas configurée. Ensuite, vous devez impliquer un administrateur 1C pour la configuration initiale.

Toutes ces limitations sont réelles, mais aucune d'entre elles ne dépasse les avantages d'OData par rapport à CommerceML. C'est comme comparer une voiture électrique à une locomotive à vapeur : oui, une voiture électrique a besoin de recharger sa batterie, et il y a encore moins de bornes de recharge que de stations-service. Mais cela ne signifie pas que vous devez continuer à conduire une locomotive à vapeur, car le bois de chauffage peut être trouvé dans n'importe quelle forêt.

Autre question souvent posée : « Et si j'ai un site Web Bitrix/OpenCart/personnalisé, et non WooCommerce ? OData est un protocole universel. Il n'est pas lié à WordPress ou WooCommerce. Toute plate-forme capable d'envoyer des requêtes HTTP et d'analyser JSON peut fonctionner avec OData 1C. Le module spécifique dont je parle est implémenté dans le cadre d'un plugin WooCommerce, mais les principes sont les mêmes : API REST au lieu de fichiers XML, mises à jour incrémentielles au lieu d'un déchargement complet, mappage personnalisé au lieu d'un schéma rigide. Si vous travaillez avec une autre plateforme, recherchez des solutions similaires ou mettez en œuvre l'intégration vous-même, car OData fournit une API propre et documentée.

Et si vous le regardiez de l'autre côté - du côté des franchisés 1C et des développeurs 1C ? J'ai parlé avec plusieurs partenaires 1C et leur réaction à l'approche OData a été mitigée. D'une part, ils comprennent les limites de CommerceML - ils en font eux-mêmes l'expérience chaque jour. D'un autre côté, CommerceML est leur pain et leur beurre. Personnaliser le traitement des échanges, configurer les téléchargements, corriger les erreurs de synchronisation - ce sont des heures rémunérées régulières. Le passage à OData les prive d'une partie de leurs revenus, car le client peut mettre en place lui-même l'intégration, sans programmeur 1C. Il ne s’agit pas d’une conspiration ou d’une malveillance, mais simplement d’une réalité économique. Mais pour une entreprise qui paie pour l'intégration, c'est un argument en faveur d'OData : moins de dépendance vis-à-vis d'un sous-traitant, des coûts de support inférieurs, plus de contrôle.

Savez-vous ce qui me surprend le plus dans toute cette histoire ? Les avantages non techniques d’OData sont évidents pour quiconque possède même une petite compréhension des technologies Web. Je suis surpris que la transition ait pris autant de temps. Nous avons lutté avec CommerceML pendant sept ans, connaissant ses limites, et à chaque fois nous avons trouvé une raison de ne pas changer notre approche. « Ce n’est pas le moment », « ça marche, n’y touchez pas », « et si ça empire ». Des raisons classiques pour maintenir le statu quo. Ce n’est que lorsque la perte d’une commande spécifique a rendu évident le coût de l’inaction que nous avons finalement franchi le pas.

Il existe un autre aspect dont on parle rarement, mais qui dans la pratique s'avère d'une importance cruciale : le débogage et le diagnostic des problèmes. Lorsque quelque chose se brise dans l'échange CommerceML (et cela se brise régulièrement), le diagnostic se transforme en histoire policière. Un fichier XML de plusieurs dizaines de mégaoctets dans lequel vous devez trouver le nœud problématique. Journaux PHP qui indiquent uniquement « Erreur d'analyse » sans spécifier d'emplacement spécifique. Journaux 1C qui écrivent « Échange terminé avec des erreurs » - et quel type d'erreurs, découvrez-le vous-même. Nous avons passé des heures à essayer de comprendre pourquoi un produit spécifique n'était pas mis à jour ou pourquoi un groupe spécifique de produits avait perdu des images. Parfois, la raison s'avérait triviale - par exemple, un caractère spécial dans le nom du produit qui cassait l'analyseur XML. Parfois, cela est mystérieux, lié à l'ordre de traitement des fichiers ou aux fuseaux horaires du serveur.

Les diagnostics sont transparents avec OData. Vous envoyez une demande spécifique et recevez une réponse spécifique. Erreur? C'est dans une réponse HTTP avec un code et une description clairs. Le produit n'est pas mis à jour ? Regardez la demande et la réponse dans le journal – tout est visible. Nous enregistrons chaque opération de synchronisation dans une table séparée (wpaic_1c_sync_log) avec des détails : quel produit, quels champs ont été mis à jour, combien de temps cela a pris, s'il y a eu une erreur. Le responsable peut accéder au panneau d'administration et voir l'historique de synchronisation de chaque produit. Ce n’est pas seulement une question de commodité : c’est un autre niveau de contrôle sur le processus.

Et voici autre chose que j'ai remarqué après la transition. Lorsque les données du site sont toujours à jour, lorsque l’échange fonctionne de manière fiable et prévisible, l’attitude de toute l’équipe à l’égard du site change. Auparavant, le site était perçu comme « une vitrine qui montre parfois les bonnes données ». Les gestionnaires dupliquaient les informations dans Excel car « on ne peut pas faire confiance au site ». Les clients ont appelé pour vérifier la disponibilité car « elle n'est peut-être pas à jour sur le site Web ». Désormais, le site est une source de vérité. Les managers y font référence lorsqu'ils communiquent avec les clients. Les clients passent eux-mêmes leurs commandes sans rappeler. La direction examine les analyses des ventes sur le site Web, sachant que les données sont fiables. Ce changement est difficile à surestimer : il affecte l'efficacité de l'ensemble de l'entreprise, et pas seulement le travail du service informatique.

Je souhaite également aborder la question de la sécurité car elle revient souvent dans les conversations sur le remplacement de CommerceML. "OData permet d'accéder à la base de données 1C via Internet - c'est une faille de sécurité !" C'est une préoccupation légitime, mais essayons de trouver une solution. CommerceML fonctionne également via HTTP - le même script PHP sur le site qui accepte le XML de 1C est accessible depuis Internet. Et souvent, il n'est protégé que par un identifiant et un mot de passe, qui sont transmis en texte clair. OData peut être configuré de manière plus sécurisée : HTTPS avec TLS obligatoire, authentification via Basic Auth ou OAuth, restriction d'accès par adresse IP, un utilisateur 1C distinct avec des droits minimaux (lecture uniquement des répertoires nécessaires). De plus, vous pouvez utiliser un VPN entre les serveurs 1C et le site Web, fermant complètement le point de terminaison OData de tout accès externe. Du point de vue de la sécurité, OData constitue donc un pas en avant plutôt qu'en arrière.

Je suis sûr que dans trois à cinq ans, CommerceML deviendra aussi anachronique que le téléchargement de fichiers FTP vers un hébergement ou une mise en page dans une feuille de calcul l'est aujourd'hui. La technologie évolue, les exigences des entreprises augmentent et le format créé il y a vingt et un ans pour un monde qui n'existe plus cédera inévitablement la place aux approches modernes. La seule question est de savoir si vous allez faire cette transition maintenant - ou attendre de perdre votre « grosse commande ».

Si vous travaillez actuellement avec CommerceML et avez identifié vos problèmes dans cet article, alors vous êtes prêt pour un changement. Il ne faut pas avoir peur de la transition. Il n’est pas nécessaire de casser ce qui fonctionne en une journée. Commencez petit : activez OData sur votre serveur 1C, essayez d'envoyer la première requête, regardez les données de votre catalogue au format JSON. Vous verrez vos produits, vos prix, vos détails - uniquement dans un format pratique, lisible et moderne. Et vous comprendrez alors qu’il n’y aura pas de retour aux fichiers XML de la taille d’un gigaoctet.

Nous avons rassemblé toute notre expérience - tant positive que négative - dans un module d'intégration 1C via OData pour WooCommerce. Assistant de configuration, attributs de découverte automatique, synchronisation incrémentielle, prise en charge des webhooks, mappage de champs flexible - tout ce dont j'ai parlé dans cet article. Si vous souhaitez voir comment cela fonctionne dans la pratique, jetez un œil à la page du module sur notre site Web. Et si vous avez des questions sur l'intégration de 1C et WooCommerce, écrivez, je suis toujours heureux de partager mon expérience. Parce que chaque magasin qui s'éloigne de CommerceML rend l'ensemble du marché du commerce électronique un peu plus moderne.