Intégrations B2B dans Magento 2 : Profiles, Mappings et suivi des synchronisations dans B2B Suite

Intégrer Magento 2 à un ERP, PIM, WMS ou CRM ne se limite pas à envoyer des données vers une API. Il faut identifier l’entreprise, relier les identifiants, vérifier le résultat et gérer les messages refusés. En B2B, cela détermine si la commande arrive en préparation, si le client est reconnu et si le tarif convenu rejoint le bon canal.

Integrations dans Kowal B2B Suite organise ce travail en cinq espaces : Profiles, Mappings, Sync Jobs, Dead Letter Queue et Sync Errors. Voici leur fonctionnement et leur utilisation quotidienne.

La description repose sur l’implémentation vérifiée en novembre 2026. Les exemples sont illustratifs et supposent un adaptateur déployé pour le système et l’opération concernés.

Que fournit Integrations, et que fait l’adaptateur ?

Integrations apporte une infrastructure commune : profils, correspondances d’identifiants, registre de tâches, suivi des tentatives, résultats et historique des erreurs. Un adaptateur réalise la connexion concrète à l’ERP, PIM, WMS ou CRM ; il connaît son API et ses règles d’échange.

Il définit authentification, formats, transformations de champs et exécution. Choisir « ERP » décrit la destination du profil, sans installer automatiquement un connecteur pour n’importe quel ERP.

Enregistrer une tâche ne fait que consigner du travail. Le formulaire ne lance aucun traitement récurrent en arrière-plan. Traitement et sélection des tâches doivent être raccordés au déploiement, par exemple via un exécuteur, un ordonnanceur ou un middleware utilisant la logique et l’API disponibles.

Cinq écrans, cinq questions précises

Ces éléments décrivent le même processus sous différents angles. Le profil fixe le contexte, les correspondances relient les enregistrements, la tâche représente l’opération et les deux dernières vues aident à traiter les échecs.

Profiles : configurer l’intégration pour le bon website

Dans B2B > Integrations > Profiles, vous créez et modifiez les profils. Chacun appartient à un website Magento où B2B est actif. Cela sépare, par exemple, les configurations nationales et export lorsqu’elles utilisent des websites distincts.

Le website est ici l’unité d’organisation d’un canal Magento. Plusieurs vues linguistiques dans un même website ne signifient pas plusieurs intégrations indépendantes.

Config JSON n’impose pas un jeu universel de champs. L’adaptateur interprète les clés. Le formulaire valide le JSON, mais ne remplace pas un test de connexion. Les accès devraient être fournis par des références à une configuration sécurisée, selon les exigences de l’adaptateur.

L’intégrateur utilise ainsi un profil nommé au lieu de répéter les paramètres ERP dans plusieurs scripts. L’opérateur identifie le système et le sens des échanges.

Mappings : relier les identifiants Magento et externes

Une entreprise peut avoir l’ID 42 dans B2B Suite et le code ERP-C-0084 dans l’ERP. Une personne reconnaît un seul client ; l’intégration exige un lien explicite pour lire ou modifier la bonne fiche.

Mappings enregistre website, type de système, type d’entité, identifiants local et externe et métadonnées JSON facultatives. L’interface prévoit entreprises, clients, produits, catégories, grilles tarifaires, commandes, RFQ et documents.

Les valeurs sont des exemples. L’adaptateur choisit la représentation de l’identifiant local par entité. Les correspondances sont recherchables par identifiant local ou externe.

Mappings relie les identités des enregistrements ; ce n’est pas un éditeur visuel de transformation de champs. Une règle comme « le nom client ERP alimente le champ company de Magento » appartient à l’adaptateur. Enregistrer une correspondance ne récupère ni ne synchronise les données.

Le contexte comprend website, type de système et type d’entité, sans se limiter à un profil. Pour plusieurs connexions de même type dans un website, l’intégrateur doit organiser une identification cohérente. La base impose l’unicité des identifiants locaux et externes dans ce contexte.

Sync Jobs : enregistrer le travail et suivre son déroulement

Un Sync Job représente une opération, comme transmettre une commande à l’ERP. Dans Schedule Sync Job, choisissez profil actif, entité et opération. Vous pouvez préciser direction, données JSON, clé d’idempotence, limite de tentatives et échéance. Sans remplacement, la direction provient du profil.

L’adaptateur doit comprendre l’entité et le nom d’opération. export_order peut appartenir à la solution convenue ; saisir ce nom ne crée pas l’export.

View affiche résumé, entrée, résultat de l’adaptateur, journaux et erreurs. Vous vérifiez website, profil, direction, entité, opération, tentatives, clé d’idempotence et heures de programmation, début et fin.

Interprétez success selon le contrat de l’adaptateur. Si l’API externe accepte seulement un message pour traitement ultérieur, déterminez si le résultat confirme sa réception ou l’achèvement du processus métier.

L’échéance informe le processus d’exécution. Saisir une date ne remplace ni son fonctionnement ni les règles de sélection des tâches prêtes.

Idempotence : limiter les tâches en double

Après une coupure, le middleware peut soumettre de nouveau la même opération. Une clé d’idempotence reconnaît la tâche existante. Publier avec la même clé dans le même website renvoie son enregistrement au lieu d’en créer un autre.

La clé doit identifier une opération précise, par exemple exporter une version de commande. Commune au website, elle devrait inclure un contexte reconnaissable de système et d’opération. Réutiliser une ancienne clé ne modifie pas l’entrée de la tâche existante.

Cela protège contre les doubles enregistrements. Prévenir les doubles effets dans l’ERP, comme un second document après une réponse incertaine, demande aussi une gestion par l’adaptateur et les possibilités de l’API externe.

Dead Letter Queue : les tâches nécessitant une décision

Dead Letter Queue affiche les tâches dead. C’est une vue des mêmes enregistrements, sans seconde copie des messages. Elle isole les opérations non terminées dans leur limite de tentatives.

Avec trois tentatives autorisées, le troisième échec de l’adaptateur définit dead. Cela ne lance pas automatiquement trois essais consécutifs. Les exécutions suivantes et leurs délais dépendent du mécanisme de relance et du processus déployés.

L’opérateur ouvre la tâche, analyse et corrige la cause, par exemple une correspondance client absente ou la connexion. Il peut ensuite utiliser Retry Job.

La relance concerne failed et dead. Elle ne crée pas de nouvelle tâche et ne remet pas l’historique des tentatives à zéro. Elle définit retry, programme l’heure actuelle et efface les anciens début et fin. Si la limite est épuisée, elle l’augmente pour autoriser un nouvel essai. L’adaptateur ne s’exécute qu’au traitement suivant.

Sync Errors : historique des erreurs avec leur contexte

Sync Errors présente les erreurs d’exécution de l’adaptateur : code, message, heure et possibilité de relance. La liste les relie au contexte actuel de tâche, profil et website, distinguant un problème client d’une panne générale.

Les détails de tâche donnent les erreurs associées et journaux techniques : début, fin et programmation des relances, notamment. Les données d’erreur conservent aussi une trace utile à l’intégrateur.

Une tâche peut accumuler des erreurs sur plusieurs tentatives. Leur nombre ne correspond donc pas au nombre d’opérations en attente. Une tâche réussie ultérieurement peut garder ses anciennes erreurs.

Retryable dépend ici des tentatives restantes lors de l’erreur. Il ne détecte pas automatiquement une cause temporaire. Relancer ne corrige pas un identifiant invalide, même si une tentative reste autorisée.

La différence essentielle : Sync Errors aide à analyser les causes ; Dead Letter Queue liste les tâches aux tentatives épuisées.

Cas 1 : relier une entreprise B2B à son client ERP

Alfa possède un compte Magento et une fiche ERP existante. L’équipe veut éviter un doublon client.

1. L’intégrateur prépare l’adaptateur ERP et le profil du bon website.
2. Mappings relie l’entreprise 42 à ERP-C-0084.
3. La tâche de l’adaptateur utilise ce lien pour viser la fiche existante.
4. L’opérateur vérifie résultat et identifiants renvoyés dans Sync Jobs.

L’identité client reste cohérente. Les champs mis à jour et leur système de référence relèvent du périmètre convenu.

Cas 2 : transmettre une commande B2B après une coupure

Le client commande et le mécanisme crée une tâche d’export. L’ERP est temporairement indisponible. L’adaptateur échoue, l’erreur est enregistrée et la tâche devient failed ou, après épuisement, dead.

Après rétablissement, l’opérateur vérifie le résultat précédent dans l’ERP et programme Retry sur la même tâche. L’adaptateur doit reconnaître les documents existants pour éviter un doublon si la demande avait été acceptée malgré la réponse perdue.

Le résultat réussi peut contenir l’identifiant du document ERP et l’adaptateur peut enregistrer une correspondance. Contenu et moment de création dépendent de l’implémentation.

Cas 3 : actualiser les tarifs du bon canal B2B

L’ERP est la source des conditions commerciales. Le canal grossiste possède un profil d’import et une correspondance de la grille 7 vers ERP-PRICELIST-DEALERS.

L’adaptateur lit l’ERP, vérifie SKU, devise et paliers puis enregistre selon Pricing. Sync Job suit l’opération ; le résultat peut compter les lignes traitées. En cas de problème, contexte et message sont disponibles.

Integrations gère le déroulement ; Pricing choisit le prix. Voir notre article sur les tarifs B2B et Price List dans Magento 2. Validation, écritures partielles et mise à jour d’index doivent être définies dans l’adaptateur.

Cas 4 : une erreur récurrente exige une correction

Le système d’entrepôt refuse une opération car il ne reconnaît pas un produit. Relancer ne change rien. La tâche épuise ses essais et apparaît dans Dead Letter Queue.

L’opérateur ouvre View Job, lit le message et vérifie les identifiants. Si un lien manque, il corrige Mappings. Après résolution, il choisit Retry Job et contrôle le résultat suivant.

Cela montre l’utilité des correspondances et de l’historique. La file permet de reprendre l’opération ; le diagnostic indique quoi réparer avant la tentative.

Déployer Integrations étape par étape

1. Choisissez le premier processus. Commencez par l’export des commandes plutôt que par tous les domaines.
2. Définissez les sources. Décidez quel système gère client, tarifs ou statut et comment résoudre les conflits.
3. Préparez adaptateur et exécuteur. Fixez opérations, formats, authentification, exécution et relances.
4. Configurez Profiles et Mappings. Vérifiez website, direction et identifiants sur des cas réels.
5. Testez succès et échecs. Incluez API indisponible, données invalides, double soumission et tentatives épuisées.
6. Vérifiez le résultat métier. Confirmez la bonne fiche cible, pas seulement le statut.
7. Attribuez les responsabilités. Définissez qui suit Sync Errors et Dead Letter Queue et corrige données ou connexions.

Vous évaluez ainsi les opérations correctement traitées et le temps de résolution, plutôt que la seule présence d’une API.

Questions fréquentes sur Integrations dans B2B Suite

Un profil ERP fournit-il une intégration prête pour tout ERP ?

Non. Il stocke contexte et configuration. Un adaptateur adapté à l’API et aux processus convenus assure la communication.

Mappings transforme-t-il les champs d’import ?

Il relie les identifiants locaux et externes. Transformation des champs et formatage des données appartiennent à l’adaptateur.

Retry envoie-t-il les données immédiatement ?

Non. Il reprogramme la tâche existante. L’envoi ou la récupération intervient à l’exécution suivante du processus raccordé.

Quelle différence entre Dead Letter Queue et Sync Errors ?

La première montre les tâches dead, le second les erreurs contextualisées. Des erreurs d’opérations ensuite réussies peuvent rester dans l’historique.

Le module relance-t-il automatiquement toutes les quelques minutes ?

Il stocke échéances, statuts et compteurs et permet les relances. Planning, délais et sélection automatique doivent être configurés dans la solution d’exécution.

Peut-on gérer l’intégration par API ?

L’API B2B Suite gère profils, correspondances, publication, traitement et relance des tâches ainsi que lecture des tâches, journaux et erreurs. Elle exige les droits d’intégration et le contexte website lorsque nécessaire.

Une intégration B2B sous contrôle de votre équipe

Profiles organise la configuration, Mappings les identités, Sync Jobs le déroulement et Dead Letter Queue et Sync Errors les échecs. Ensemble, ils forment une base extensible d’intégration Magento 2 avec des adaptateurs adaptés.

Découvrez Kowal B2B Suite pour Magento 2 Open Source ou décrivez votre processus à relier à un ERP, PIM, WMS ou CRM. Commencez par le système, la direction et une opération aujourd’hui manuelle.

À lire aussi : réduire la gestion manuelle des ventes B2B et le coût de gestion manuelle des commandes B2B.