Add-ons

Les besoins d’une migration se situent souvent entre deux extrêmes. La migration prise en charge par défaut peut convenir sur le plan structurel, tout en laissant à l’entreprise le besoin de mieux contrôler les enregistrements transférés, la destination de certaines valeurs ou la façon dont certaines valeurs doivent être modifiées avant d’arriver dans la boutique cible. C’est précisément le rôle des Add-ons dans les services de migration Next-Cart.

La décision ne consiste donc pas simplement à déterminer si le nom d’un Add-on semble correspondre au besoin. Chaque Add-on traite un type différent de manipulation des données, et plusieurs Add-ons peuvent être combinés lorsqu’une même exigence comporte plusieurs étapes. Comprendre ces différences permet de distinguer les améliorations prises en charge du travail plus large qui relève de Custom Service.

Les Add-ons répondent à des besoins de traitement clairement délimités

Les Add-ons étendent le traitement pris en charge par la migration sans modifier le parcours de migration fondamental. Un besoin pertinent commence par le résultat métier attendu, puis identifie l’opération précise nécessaire pour l’obtenir.

Quatre questions permettent de distinguer clairement les Standard Add-ons :

• Quels enregistrements doivent poursuivre la migration ? C’est une question de Data Filter.
• Quel champ cible compatible doit recevoir un champ source pris en charge ? C’est une question d’Advanced Data Mapping.
• Le besoin exige-t-il de mettre en correspondance un champ ou une colonne de base de données pris en charge lorsque la plateforme source et la plateforme cible sont toutes deux Open-Source ?C’est une question d’Advanced Database Mapping.
• Comment la valeur d’un champ cible sélectionné doit-elle être modifiée pendant la migration ?C’est une question de Data Transformation.

Ces fonctions sont liées, mais elles ne sont pas interchangeables. Le filtrage modifie l’ensemble des enregistrements concernés. La mise en correspondance modifie leur destination. La mise en correspondance de base de données peut intervenir au niveau des structures sous-jacentes dans les limites de son périmètre pris en charge. La transformation modifie la valeur cible sélectionnée.

Quatre Standard Add-ons pour quatre décisions différentes

Les quatre Standard Add-ons se comprennent le mieux par la partie du résultat de migration qu’ils contrôlent. Il ne s’agit pas de quatre variantes d’une même fonction. L’un détermine quels enregistrements participent, deux déterminent où les valeurs prises en charge sont représentées, et le dernier détermine quelle valeur finale est produite dans la cible.

Standard Add-on	Rôle principal	Signal indiquant une forte adéquation	Rôle dans un traitement combiné	Prix fixe
Data Filter	Sélectionner les enregistrements à migrer à l’aide de conditions prises en charge sur les champs d’un type de données.	L’entreprise ne souhaite migrer qu’un sous-ensemble défini d’enregistrements par ailleurs éligibles.	S’exécute en premier et définit l’ensemble d’enregistrements traité par tous les Add-ons suivants.	$50
Advanced Data Mapping	Réaffecter un champ source pris en charge à un champ cible compatible sans modifier sa valeur dans l’opération de mise en correspondance.	La valeur source est déjà correcte, mais doit être placée dans un autre champ cible pris en charge.	S’exécute après le filtrage et définit les destinations des champs pris en charge avant la mise en correspondance au niveau de la base de données.	$50
Advanced Database Mapping	Mettre en correspondance des champs et des colonnes de base de données sous-jacentes pris en charge vers des champs ou colonnes cibles compatibles, y compris certains champs propres à une plateforme ou personnalisés.	Le besoin dépend de la représentation au niveau de la base de données et pas uniquement de la couche de champs standard prise en charge.	S’exécute après Advanced Data Mapping et peut établir la valeur ou la destination que Data Transformation recevra ensuite. Disponible uniquement lorsque les deux plateformes sont Open-Source.	$100
Data Transformation	Transformer les valeurs de champs cibles sélectionnés pendant la migration.	La valeur cible finale doit être recalculée, normalisée, reformatée ou modifiée selon une règle prise en charge.	S’exécute en dernier et travaille sur la valeur cible disponible après les étapes de mise en correspondance.	$50

Ce tableau est utile parce qu’une même exigence métier peut réunir plusieurs de ces signaux. Une demande telle que « migrer uniquement ces produits, placer une valeur source dans un autre champ, utiliser une valeur personnalisée de base de données pour Price, puis appliquer une marge » n’est pas une seule demande de personnalisation vague. Elle se décompose en quatre opérations distinctes, qui peuvent être évaluées séparément puis combinées dans l’ordre de traitement requis.

Data Filter : contrôler les enregistrements qui participent

Data Filter constitue le bon point de départ lorsque l’entreprise peut définir quels enregistrements doivent faire partie du résultat de migration au moyen de conditions prises en charge sur des champs.

Les questions typiques sont notamment :

• Faut-il inclure uniquement les produits actifs ?
• Faut-il limiter les commandes à une période d’activité ou à un statut défini ?
• Faut-il conserver uniquement les clients qui répondent à une condition convenue sur un champ ?
• Faut-il limiter un type de données de contenu aux enregistrements pertinents pour la nouvelle boutique ?

La limite importante est que Data Filter modifie la participation des enregistrements, et non la destination de leurs champs ni leurs valeurs. Un produit exclu par le filtre n’atteint pas les étapes de traitement suivantes des Add-ons pour le périmètre concerné. Un produit qui passe le filtre poursuit la migration avec les données prises en charge disponibles pour les étapes de mise en correspondance et de transformation qui suivent.

Cette fonction est particulièrement importante dans les besoins combinés. Si une règle de mise en correspondance ou de transformation ultérieure ne doit s’appliquer qu’à une partie du catalogue, le filtrage définit d’abord cette population au lieu de demander à un Add-on ultérieur de distinguer des enregistrements qu’il n’est pas conçu pour sélectionner.

Les Entity Points restent un concept de capacité distinct. produits, clients, commandes et articles de blog peuvent consommer des Entity Points selon leurs pondérations respectives, mais le nombre d’Entity Points ne permet pas d’identifier quels enregistrements individuels doivent migrer. Data Filter répond à cette décision de sélection.

Cas d’utilisation autonomes de Data Filter

Cas d’utilisation : migrer uniquement les produits activés. Un marchand retire des enregistrements de catalogue abandonnés ou désactivés et souhaite que le périmètre de migration contienne uniquement les produits dont le champ de statut pris en charge indique qu’ils sont activés. Data Filter est le contrôle pertinent, car la décision métier porte sur les enregistrements produit qui participent, et non sur la destination ou la modification de leurs valeurs. La condition exacte reste soumise aux champs et opérateurs pris en charge pour le parcours de migration sélectionné.

Cas d’utilisation : limiter les commandes à une période d’activité définie. Une entreprise peut n’avoir besoin que des commandes créés après une date convenue pour le projet de migration, tandis que les commandes historiques plus anciens restent hors du périmètre prévu. Lorsque le champ de date requis et l’opération de comparaison sont pris en charge, Data Filter peut définir cet ensemble d’enregistrements avant l’évaluation des règles de mise en correspondance ou de transformation ultérieures. Le filtrage ne change pas la signification des commandes retenus ; il détermine quels enregistrements continuent.

Advanced Data Mapping : conserver la valeur et changer sa destination prise en charge

Advanced Data Mapping convient lorsque la valeur source est correcte, mais pas sa destination cible prise en charge.

Le modèle mental est une réaffectation directe :

supported source field -> compatible target field

Par exemple, si le parcours de migration sélectionné prend en charge les champs produit Short Description et Description, le besoin peut consister à faire de la valeur source Short Description la valeur du champ cible Description. La valeur n’a pas besoin d’être recalculée. La migration a seulement besoin d’une autre destination prise en charge.

Cette distinction est utile en pratique :

• « Placer cette valeur source prise en charge dans ce champ cible compatible » oriente vers Advanced Data Mapping.
• « Modifier cette valeur avant qu’elle n’arrive dans la boutique cible » oriente vers Data Transformation.
• « La valeur se trouve dans une colonne de base de données sous-jacente qui nécessite un traitement au niveau de la base de données » peut orienter vers Advanced Database Mapping si le parcours de plateformes est éligible.

Dans un traitement combiné, Advanced Data Mapping ne reçoit que les enregistrements qui ont passé Data Filter. Il établit les destinations des champs pris en charge avant l’exécution d’Advanced Database Mapping et de Data Transformation. Lorsque des étapes ultérieures concernent une destination cible liée ou identique, l’ordre détermine la valeur disponible pour le traitement suivant.

Advanced Data Mapping conserve néanmoins des limites. Le champ source et le champ cible doivent être pris en charge et compatibles, et les données Tax sont exclues du périmètre Standard de mise en correspondance. Changer de destination ne garantit pas non plus que les applications, thèmes, extensions ou règles métier de la plateforme cible utiliseront la valeur mise en correspondance d’une manière particulière.

Cas d’utilisation autonomes d’Advanced Data Mapping

Cas d’utilisation : utiliser Product Short Description comme Description cible. Le texte source est déjà correct, mais la boutique cible doit recevoir cette valeur prise en charge dans un autre champ compatible. Advanced Data Mapping convient parce que le besoin est un changement direct de destination : Short Description -> Description. L’opération de mise en correspondance conserve la valeur au lieu de la réécrire.

Cas d’utilisation : réaffecter une valeur de contact client prise en charge. Une migration peut contenir un champ de contact client pris en charge dont la valeur doit arriver dans un autre champ de contact cible compatible, parce que les deux plateformes organisent différemment les informations client. Lorsque les deux champs sont pris en charge et que la cible peut représenter correctement la valeur source, Advanced Data Mapping peut effectuer cette réaffectation sans transformer un problème de destination de champ en besoin de transformation ou de Custom Service.

Advanced Database Mapping : travailler avec une représentation éligible au niveau de la base de données

Advanced Database Mapping devient pertinent lorsqu’un besoin ne peut pas être décrit uniquement comme le déplacement d’un champ applicatif pris en charge vers un autre champ pris en charge. Il étend la mise en correspondance aux champs et colonnes de base de données sous-jacentes éligibles, y compris certains champs spécifiques à la plateforme ou personnalisés qui restent dans les limites de la capacité Standard.

Sa disponibilité est volontairement plus restreinte, car le traitement au niveau de la base de données dépend de l’architecture des deux côtés de la migration. La plateforme source et la plateforme cible doivent toutes deux être Open-Source. Si l’une des deux est Non-Open-Source, Advanced Database Mapping n’est pas disponible.

Cette condition d’architecture ne répond qu’à la première question d’éligibilité. Un parcours de plateformes éligible ne rend pas automatiquement tous les champs ou toutes les colonnes mappables. Le besoin réel doit encore être vérifié au regard des éléments suivants :

• participation du champ source ou de la colonne de base de données au périmètre pris en charge ;
• existence d’un champ ou d’une colonne cible compatible ;
• compatibilité suffisante des types de valeur ;
• relations et signification des données prises en charge ;
• exclusion des données Tax du périmètre Standard de mise en correspondance.

L’Add-on est donc particulièrement utile lorsque l’entreprise peut identifier clairement la valeur au niveau de la base de données qui doit être conservée, l’emplacement compatible qu’elle doit occuper dans la boutique cible et les éléments de validation qui permettront de confirmer que le résultat mis en correspondance est exploitable.

Dans la séquence de traitement, Advanced Database Mapping s’exécute après Advanced Data Mapping et avant Data Transformation. Cette position est importante lorsqu’une mise en correspondance au niveau de la base de données établit une valeur qui doit ensuite être recalculée ou reformatée. Data Transformation reçoit le résultat disponible après les deux étapes de mise en correspondance ; la mise en correspondance de base de données peut donc devenir l’entrée directe de la règle finale qui modifie la valeur.

La mise en correspondance de base de données reste également distinct de la mise en œuvre sur la plateforme cible. Le fait d’enregistrer correctement une valeur dans un champ ou une colonne cible compatible ne prouve pas qu’un thème, une extension, un workflow applicatif, une règle fiscale ou une fonction de la vitrine interprétera ou affichera cette valeur comme prévu. Ces résultats doivent être validés séparément.

Cas d’utilisation autonomes d’Advanced Database Mapping

Cas d’utilisation : utiliser une colonne produit numérique personnalisée prise en charge comme valeur de prix cible. Sur un parcours éligible Open-Source vers Open-Source, un marchand peut disposer d’une colonne personnalisée de base de données prise en charge telle que regional_base_price, qui doit alimenter un champ ou une colonne de prix cible compatible. Advanced Database Mapping est pertinent parce que la valeur source se situe au niveau de la base de données. Le critère d’architecture ne suffit toutefois pas : la colonne source exacte, la destination cible, la compatibilité des types de valeur et le périmètre Standard doivent toujours être confirmés.

Cas d’utilisation : conserver une valeur de base de données propre à une plateforme. Une plateforme source Open-Source peut stocker une valeur produit importante dans une colonne de base de données propre à la plateforme plutôt que dans la couche de champs standard. Si la plateforme cible Open-Source sélectionnée dispose d’une destination compatible prise en charge et si le besoin reste une mise en correspondance directe qui conserve la valeur, Advanced Database Mapping peut transférer cette valeur vers le champ ou la colonne cible prévu. Cela ne signifie pas que chaque thème, application, extension ou workflow de la cible utilisera automatiquement la valeur enregistrée.

Data Transformation : modifier la valeur cible finale

Data Transformation convient lorsque la destination est connue, mais que la valeur qui doit s’y trouver doit être modifiée.

Les schémas courants comprennent :

• l’application d’une règle arithmétique à une valeur numérique ;
• l’ajout, la suppression ou la restructuration de texte à l’aide d’une expression prise en charge ;
• la normalisation de valeurs vers une représentation cible convenue ;
• le calcul d’une valeur finale à partir de données établies par une étape de mise en correspondance antérieure.

La distinction essentielle est simple : la mise en correspondance répond à la question où cette valeur doit-elle aller ? La transformation répond à la question quelle doit être la valeur finale ?

Comme Data Transformation s’exécute en dernier, il travaille avec la valeur cible disponible après Advanced Data Mapping et, lorsque le parcours est éligible, Advanced Database Mapping. Il est donc particulièrement utile comme dernière étape d’un besoin composé. Si la mise en correspondance au niveau de la base de données établit le Price cible, par exemple, une transformation ultérieure peut calculer le Price final à partir de cette valeur mise en correspondance plutôt qu’à partir d’une hypothèse portant sur un champ source antérieur.

Data Transformation ne choisit pas les enregistrements qui participent et ne décide pas quel champ ou quelle colonne cible doit recevoir une valeur source. Ces décisions appartiennent aux étapes précédentes. Une transformation bien définie part donc d’un champ cible connu, d’une valeur d’entrée connue après mise en correspondance et d’une règle prise en charge clairement définie pour produire le résultat attendu.

Cas d’utilisation autonomes de Data Transformation

Cas d’utilisation : augmenter le prix cible obtenu de 12 %. Un marchand peut vouloir que le Regular Price cible soit supérieur de 12 % à la valeur établie par l’étape de mise en correspondance précédente. Data Transformation convient parce que la destination est déjà connue et que la valeur finale doit changer. Un calcul pris en charge tel que Regular Price x 1.12 relève donc d’une transformation, et non d’une décision de mise en correspondance.

Cas d’utilisation : normaliser une valeur texte cible. Une source et une cible peuvent représenter la même valeur métier avec des conventions textuelles différentes. Lorsqu’une règle de transformation prise en charge peut normaliser le texte cible final dans la représentation requise, Data Transformation est l’Add-on pertinent. La règle agit sur la valeur cible disponible après les étapes de mise en correspondance applicables ; elle ne sélectionne pas les enregistrements et ne décide pas quel champ cible doit recevoir la valeur source.

Pourquoi l’ordre de traitement des données par les Add-ons est important

Lorsque plusieurs Add-ons sont utilisés ensemble, ils sont traités dans un ordre fixe :

Data Filter -> Advanced Data Mapping -> Advanced Database Mapping -> Data Transformation

Cette séquence fournit un cadre simple pour raisonner sur les besoins de migration composés :

1. Sélection : quels enregistrements sont autorisés à continuer ?
2. Destination du champ : où les champs source pris en charge doivent-ils être représentés ?
3. Destination au niveau de la base de données : une migration éligible Open-Source vers Open-Source nécessite-t-elle la mise en correspondance prise en charge d’un champ ou d’une colonne de base de données au-delà de la couche de champs standard ?
4. Valeur finale : quelle doit être la valeur cible obtenue une fois la mise en correspondance terminée ?

Chaque étape applicable travaille à partir du résultat établi par les étapes précédentes. Cela ne signifie ni que chaque migration a besoin des quatre Add-ons, ni que chaque Add-on doit affecter le même champ. Cela signifie que le besoin doit être conçu comme un seul parcours ordonné des données, et non comme une série de règles indépendantes configurées isolément.

Combinaisons courantes d’Add-ons

De nombreux besoins réels n’exigent que deux ou trois étapes. Reconnaître le schéma aide à évaluer l’adéquation avant de conclure qu’un travail personnalisé est nécessaire.

Type de besoin métier	Combinaison probable d’Add-ons	Pourquoi cette combinaison convient
Migrer uniquement un sous-ensemble défini d’enregistrements, puis modifier l’une de leurs valeurs cibles.	Data Filter + Data Transformation	Le filtrage définit les enregistrements concernés ; la transformation modifie la valeur requise uniquement pour ces enregistrements.
Envoyer un champ source pris en charge vers un autre champ cible compatible, puis modifier la valeur obtenue.	Advanced Data Mapping + Data Transformation	La mise en correspondance définit la destination ; la transformation agit ensuite sur la valeur disponible à cet emplacement.
Utiliser une valeur éligible de base de données comme valeur cible, puis appliquer une règle de calcul ou de normalisation.	Advanced Database Mapping + Data Transformation	La mise en correspondance de base de données établit la valeur cible ; la transformation produit la valeur finale. Les deux plateformes doivent être Open-Source pour l’étape de mise en correspondance de base de données.
Limiter les enregistrements, réaffecter des champs pris en charge, puis modifier les valeurs cibles obtenues.	Data Filter + Advanced Data Mapping + Data Transformation	Le traitement combine le contrôle du périmètre des enregistrements, la destination des valeurs et la modification de la valeur finale sans nécessiter de mise en correspondance au niveau de la base de données.
Limiter les enregistrements, appliquer une mise en correspondance de champs pris en charge, utiliser une mise en correspondance éligible au niveau de la base de données, puis transformer le résultat final.	Les quatre Standard Add-ons	Chaque étape traite une partie différente du même besoin composé et fournit le résultat nécessaire à l’étape suivante.

La présence de plusieurs étapes ne transforme pas à elle seule le projet en cas de Custom Service. Si chaque opération reste dans le périmètre Standard pris en charge de son Add-on, le besoin combiné peut toujours être traité au moyen de Standard Add-ons. Un traitement personnalisé devient pertinent lorsqu’une opération nécessite elle-même une modification, une interprétation de données non prise en charge, une logique sur mesure ou une autre capacité qui dépasse les limites Standard.

Une méthode pratique consiste à partir du résultat attendu dans la boutique cible et à remonter la séquence. Identifiez d’abord la valeur ou la représentation finale, puis déterminez si elle nécessite une transformation, une mise en correspondance au niveau de la base de données, une mise en correspondance de champs, un filtrage des enregistrements ou une combinaison de ces contrôles.

Exemple : les quatre Add-ons se complètent pour répondre à un besoin de migration concret

Prenons une migration OpenCart vers WooCommerce dans laquelle les champs produit requis sont pris en charge et la colonne personnalisée de base de données sélectionnée satisfait aux vérifications applicables de mise en correspondance et de compatibilité. Les deux plateformes sont Open-Source ; le parcours de migration peut donc être évalué pour Advanced Database Mapping.

Le marchand souhaite obtenir quatre résultats liés :

• migrer uniquement les produits activés et encore en stock ;
• utiliser le Short Description source comme Description cible ;
• utiliser une colonne produit numérique personnalisée prise en charge, nommée regional_base_price, comme Regular Price cible ;
• augmenter ce Regular Price obtenu de 12 % pendant la migration.

Aucun Add-on ne répond à lui seul à l’ensemble du besoin.

Étape 1 : sélectionner les enregistrements produit

Data Filter applique les conditions produit convenues, par exemple un statut activé et une quantité en stock supérieure à zéro. Les produits qui ne satisfont pas ces conditions ne poursuivent pas le traitement des Add-ons pour ce périmètre de migration.

Le filtre ne résout que la question de la sélection. Il ne détermine pas la façon dont les descriptions ou les prix seront représentés dans la boutique cible.

Étape 2 : réaffecter le champ de description pris en charge

Advanced Data Mapping mappe le champ source Short Description pris en charge vers le champ cible compatible Description.

Cette opération modifie la destination de la valeur prise en charge tout en restant distincte de toute modification ultérieure de cette valeur.

Étape 3 : établir le prix à partir d’une source au niveau de la base de données

Advanced Database Mapping mappe la valeur numérique personnalisée regional_base_price prise en charge vers la destination cible compatible Regular Price.

Dans cet exemple, cette étape est possible uniquement parce que les deux plateformes du parcours de migration sont Open-Source et que le champ ou la colonne concerné est supposé satisfaire aux critères d’éligibilité du Standard Add-on. Une colonne personnalisée ne doit jamais être présumée éligible au seul motif qu’Advanced Database Mapping existe.

Étape 4 : calculer le prix cible final

Data Transformation applique ensuite le calcul requis à Regular Price, par exemple :

Regular Price x 1.12

Comme Data Transformation s’exécute après les deux étapes de mise en correspondance, il agit sur le Regular Price établi par Advanced Database Mapping, et non sur une autre valeur de prix antérieure.

Le résultat final montre pourquoi les Add-ons doivent être évalués comme une séquence coordonnée de traitement. Data Filter définit les produits concernés, les étapes de mise en correspondance déterminent où les informations pertinentes sont représentées et Data Transformation produit le prix final calculé.

Le résultat migré doit encore être validé. Cet exemple illustre le traitement des données ; il ne garantit pas que chaque règle de tarification en aval, thème, extension, règle fiscale ou présentation de vitrine soit automatiquement configuré par la migration.

Comment les Add-ons interagissent lorsqu’ils concernent les mêmes données

Les Add-ons combinés peuvent interagir de plusieurs façons. Comprendre la nature de cette interaction est plus important que de simplement compter le nombre d’Add-ons présents.

Type d’interaction	Ce qui se passe	Conséquence pour l’évaluation
Mêmes enregistrements, champs différents	Data Filter définit les enregistrements qui participent, tandis que des règles de mise en correspondance ou de transformation distinctes affectent différents champs au sein de ces enregistrements.	Les Add-ons sont coordonnés par le périmètre d’enregistrements, même s’ils n’agissent pas sur la même destination.
Étapes de mise en correspondance différentes, même destination	Advanced Data Mapping et Advanced Database Mapping peuvent tous deux contribuer à la manière dont une destination cible est établie. La dernière étape de mise en correspondance applicable détermine la valeur disponible pour le traitement suivant.	Les règles de mise en correspondance qui se chevauchent doivent exprimer une seule stratégie délibérée pour le résultat final, et non des intentions indépendantes.
Mapping suivi d’une transformation	Une étape de mise en correspondance établit la valeur ou la destination cible, puis Data Transformation modifie la valeur qui existe après la mise en correspondance.	Les règles de transformation doivent être conçues à partir du résultat mis en correspondance, et non d’une valeur source antérieure qui n’est plus l’entrée pertinente.
Filtrage suivi de traitements ultérieurs	Data Filter exclut des enregistrements de la population de migration avant tout mise en correspondance ou toute transformation.	Les Add-ons suivants doivent être évalués par rapport à la population filtrée qui les atteindra réellement.

Ce modèle d’interaction facilite l’examen des besoins composés. Le marchand peut séparer une demande métier en périmètre d’enregistrements, destination, représentation au niveau de la base de données et règle de valeur finale, puis vérifier si ces éléments se renforcent ou créent des hypothèses contradictoires.

Le cas le plus sensible apparaît lorsque plusieurs règles de mise en correspondance affectent le même champ ou la même colonne cible. Dans ce cas, l’ordre de traitement détermine la valeur mise à la disposition de Data Transformation. La conception la plus sûre part de la valeur finale attendue dans la boutique cible et remonte la séquence pour confirmer quelle étape doit établir chaque résultat intermédiaire.

Cette vérification à rebours est également utile lorsque les Add-ons affectent des champs différents. Elle permet de repérer des règles inutiles, des destinations incapables de représenter correctement le sens de la source, des transformations qui s’attendent à une mauvaise valeur d’entrée ou des enregistrements qui auraient dû être exclus avant les traitements suivants.

La compatibilité ne se résume pas au nom des champs

Deux champs peuvent avoir des libellés proches sans être compatibles. Une décision de mise en correspondance doit tenir compte de la capacité de la plateforme cible à représenter correctement la valeur source.

Pour les Add-ons de mise en correspondance, le champ ou la colonne cible doit disposer d’une capacité de type de valeur suffisante pour la valeur source. Une valeur numérique source peut souvent être représentée dans une destination textuelle, alors qu’un texte arbitraire ne peut pas être traité comme un nombre simplement parce que quelques valeurs d’exemple ont une apparence numérique. En cas d’incertitude, la compatibilité doit être validée et non supposée.

Les Add-ons de mise en correspondance ont également des limites fonctionnelles. Les données Tax sont exclues du périmètre pris en charge par Advanced Data Mapping et Advanced Database Mapping. Les besoins impliquant des types de données, champs, colonnes, relations, scripts ou comportements applicatifs non pris en charge peuvent nécessiter un Tailored Add-on, un Custom Add-on ou une analyse plus large dans le cadre de Custom Service.

Standard, Tailored et Custom Add-ons

La fonction nécessaire et le niveau de personnalisation nécessaire sont deux décisions distinctes.

Niveau d’Add-on	Signification	Traitement tarifaire
Standard Add-on	Add-on préconstruit utilisé dans son périmètre fixe pris en charge.	Prix fixe du catalogue.
Tailored Add-on	Fonction d’un Standard Add-on qui nécessite un ajustement, une modification ou un périmètre élargi au-delà de la capacité Standard.	Examiné et chiffré dans le cadre de Custom Service.
Custom Add-on	Fonctionnalité Add-on sur mesure en dehors du périmètre fonctionnel du catalogue Standard Add-on.	Examiné et chiffré dans le cadre de Custom Service.

Un besoin ne relève pas de Custom Service simplement parce que plusieurs Standard Add-ons sont combinés. Si chaque opération respecte le périmètre Standard applicable, le traitement combiné peut rester entièrement composé de Standard Add-ons.

De même, les expressions custom field ou database column n’établissent pas automatiquement qu’il s’agit d’un projet personnalisé. Il faut d’abord vérifier le besoin par rapport au périmètre pris en charge d’Advanced Data Mapping ou d’Advanced Database Mapping. Custom Service devient pertinent lorsque le résultat souhaité dépasse ce que ces contrôles pris en charge peuvent fournir.

Add-ons et Custom Service répondent à des problèmes différents

Les Add-ons répondent à des besoins de traitement des données clairement délimités. Custom Service prend en charge un travail plus large, adapté ou non standard lorsque le besoin ne peut pas être satisfait par la migration prise en charge et le fonctionnement des Standard Add-ons.

Custom Service devient pertinent lorsque l’opération requise ne tient plus dans le modèle délimité des Standard Add-ons. Les signaux typiques comprennent des données d’applications ou d’extensions tierces non prises en charge, des scripts ou traitements API sur mesure, des relations ou règles de migration non standard, ainsi qu’une fonction d’Add-on qui doit être adaptée ou développée au-delà du catalogue Standard. Le périmètre non standard plus large est traité dans les contenus consacrés à Custom Service ; l’enjeu ici est de reconnaître le moment où un Add-on ne suffit plus à décrire le travail.

Une migration peut également utiliser des Standard Add-ons dans un périmètre plus large de Custom Service. La présence de Custom Service ne change pas le rôle de chaque Add-on ; elle modifie le traitement global requis pour le travail propre au projet.

Relation entre les Add-ons, les Entity Points et la tarification

Les Entity Points et les Add-ons répondent à des questions de planification différentes.

Les Entity Points mesurent la capacité de migration comptabilisée pour produits, clients, commandes et articles de blog. Les Add-ons contrôlent certains traitements pris en charge. Un Add-on ne crée pas de nouvelle pondération d’Entity Points, et un type de données non comptabilisé ne devient pas comptabilisé simplement parce qu’un Add-on lui est appliqué.

Les prix fixes des Standard Add-ons indiqués dans le catalogue ci-dessus sont distincts de la capacité en Entity Points. Les Tailored et Custom Add-ons n’utilisent pas ces prix fixes Standard comme devis final, car leur travail supplémentaire est examiné dans le cadre de Custom Service.

Lorsqu’un Add-on éligible est ajouté ultérieurement à la même migration achetée, l’upgrade applicable suit le principe de tarification sur la différence uniquement. L’Add-on modifie le package de service associé à cette migration ; il ne change pas le parcours fixe entre la plateforme source et la plateforme cible et ne redémarre pas la durée du service.

Comment évaluer l’adéquation d’un Add-on à un besoin réel

Une bonne évaluation commence par le résultat recherché dans la boutique cible plutôt que par le nom des Add-ons. Le besoin métier peut ensuite être décomposé selon les décisions réellement contrôlées par les quatre étapes.

Question d’évaluation	Ce que la réponse indique
Quels enregistrements doivent participer au résultat ?	Si Data Filter est nécessaire.
La valeur source est-elle déjà correcte mais destinée à un autre champ cible pris en charge ?	Si Advanced Data Mapping est nécessaire.
Le besoin dépend-il d’un champ ou d’une colonne de base de données sous-jacente, et les deux plateformes sont-elles Open-Source ?	Si Advanced Database Mapping doit être évalué.
Une fois la mise en correspondance terminée, la valeur cible elle-même doit-elle changer ?	Si Data Transformation est nécessaire.
Quels éléments permettront de confirmer que la valeur, la destination, la relation et la signification métier obtenues sont correctes ?	Ce qui doit être validé avant de considérer le besoin comme satisfait.

Le vocabulaire utilisé dans une demande fournit souvent de bons indices. Les mots inclure, exclure, uniquement ou condition décrivent généralement une sélection d’enregistrements. Mettre en correspondance, placer, envoyer ou destination décrivent généralement une mise en correspondance de champs. Les références à des colonnes de base de données, des champs propres à une plateforme ou des champs personnalisés peuvent nécessiter Advanced Database Mapping lorsque l’ensemble du parcours de plateformes et le périmètre pris en charge sont éligibles. Calculer, normaliser, ajouter, supprimer, convertir ou restructurer indiquent généralement une transformation de valeur.

Il s’agit d’indices de diagnostic, pas d’approbations automatiques. Un champ au bon nom peut avoir un type de valeur incompatible. Un champ personnalisé peut entrer dans le périmètre d’un Standard mise en correspondance Add-on, tandis qu’un autre peut dépendre d’une logique non prise en charge et nécessiter Custom Service. Un parcours Open-Source vers Open-Source peut être éligible sur le plan architectural à Advanced Database Mapping, alors que la colonne de base de données précise reste hors du périmètre pris en charge.

Le besoin le mieux défini décrit donc cinq éléments ensemble : le type de données et les enregistrements concernés, la valeur source, la destination cible prévue, toute règle finale de modification de valeur et les éléments de validation qui confirmeront le résultat. Une fois ces éléments explicites, la combinaison d’Add-ons peut être évaluée par rapport aux limites prises en charge plutôt que choisie uniquement à partir du nom d’une fonction.

Cette approche orientée résultat évite deux erreurs opposées. Elle empêche d’escalader vers Custom Service un besoin pris en charge simplement parce que plusieurs contrôles sont impliqués, et elle évite également d’étendre un Standard Add-on au-delà de sa fonction prise en charge uniquement parce que son nom semble lié à la demande.

Conclusion

Les Add-ons Next-Cart sont plus faciles à utiliser correctement lorsqu’ils sont compris comme des étapes distinctes d’un même modèle de traitement des données, plutôt que comme une liste de fonctions sans relation. Data Filter sélectionne les enregistrements, Advanced Data Mapping change la destination des champs pris en charge, Advanced Database Mapping étend la mise en correspondance aux champs et colonnes de base de données pris en charge lorsque la plateforme source et la plateforme cible sont toutes deux Open-Source, et Data Transformation modifie les valeurs cibles obtenues.

Leur ordre de traitement fixe fait partie de la décision. Chaque étape applicable travaille avec le résultat établi plus tôt dans la séquence ; les besoins combinés doivent donc être conçus à partir du résultat final attendu dans la boutique cible puis validés comme un traitement coordonné.

Les Standard Add-ons restent des capacités prises en charge dans des limites définies. Lorsque la fonction requise nécessite une modification, une logique étendue, un développement sur mesure ou un traitement non pris en charge, le besoin relève d’un Tailored Add-on, d’un Custom Add-on ou d’un périmètre plus large de Custom Service plutôt que d’étendre la capacité Standard au-delà de ses limites prévues.

Questions fréquentes

Comment déterminer si une entreprise a besoin d’un seul Add-on ou de plusieurs ?

Décomposez le besoin en quatre dimensions : sélection des enregistrements, destination des champs, représentation au niveau de la base de données et modification de la valeur finale. Si le résultat métier comporte plusieurs de ces opérations, plusieurs Add-ons peuvent convenir. Leur nombre importe moins que le fait que chaque étape résolve une partie distincte et prise en charge du même résultat.

Plusieurs Standard Add-ons peuvent-ils être utilisés dans la même migration sans Custom Service ?

Oui. Combiner plusieurs Standard Add-ons ne suffit pas à faire de la migration un cas de Custom Service. Chaque opération doit rester dans le périmètre Standard pris en charge de son Add-on, les étapes doivent former une stratégie de traitement cohérente et le résultat combiné doit être validé par rapport au résultat métier attendu.

L’ordre des Add-ons est-il important lorsqu’ils sont utilisés ensemble ?

Oui. La séquence de traitement est Data Filter, Advanced Data Mapping, Advanced Database Mapping, puis Data Transformation. Chaque étape applicable travaille à partir du résultat établi par les étapes précédentes ; les règles qui se chevauchent doivent donc être conçues comme une seule séquence.

Advanced Database Mapping est-il disponible lorsque seule la plateforme cible est Open-Source ?

Non. La plateforme source et la plateforme cible doivent toutes deux être Open-Source pour qu’Advanced Database Mapping soit disponible. Si l’une des deux est Non-Open-Source, l’Add-on n’est pas disponible.

Quelle est la différence entre Advanced Data Mapping et Data Transformation ?

Advanced Data Mapping change la destination cible compatible d’un champ source pris en charge sans modifier la valeur pendant l’opération de mise en correspondance. Data Transformation modifie la valeur du champ cible elle-même. Lorsque les deux sont utilisés, la mise en correspondance établit d’abord où la valeur doit arriver, puis la transformation applique la règle finale prise en charge qui modifie cette valeur.

Deux Add-ons de mise en correspondance peuvent-ils affecter la même destination cible ?

Ils peuvent participer à un besoin qui converge vers la même destination, mais les règles doivent être conçues comme une seule séquence et non comme des correspondances indépendants. Advanced Database Mapping s’exécute après Advanced Data Mapping ; la valeur établie par la dernière étape de mise en correspondance applicable est donc celle dont dispose Data Transformation.

Un champ personnalisé ou une colonne de base de données peut-il malgré tout entrer dans le périmètre d’un Standard Add-on ?

Potentiellement. Un champ personnalisé ou une colonne de base de données doit d’abord être évalué par rapport au périmètre pris en charge d’Advanced Data Mapping ou d’Advanced Database Mapping. Le mot custom ne signifie pas automatiquement Custom Service, mais tout fonctionnement non pris en charge ou sur mesure nécessite un examen supplémentaire.

Advanced Data Mapping et Advanced Database Mapping prennent-ils en charge les données Tax ?

Non. Les données Tax sont exclues du périmètre pris en charge des deux mise en correspondance Add-ons.

Les Add-ons modifient-ils le calcul des Entity Points ?

Non. Les Entity Points continuent de suivre le modèle comptabilisé pour produits, clients, commandes et articles de blog. Les Add-ons affectent séparément le traitement pris en charge et la tarification, sans modifier la capacité en Entity Points.

Quand un besoin d’Add-on doit-il passer par Custom Service ?

Custom Service devient approprié lorsque le besoin dépasse les capacités de migration et de Standard Add-on prises en charge, notamment pour un travail Tailored ou Custom Add-on ou pour toute autre logique de traitement des données sur mesure ou non prise en charge. Le critère déterminant est la limite de ce qui est pris en charge, et non le simple fait d’utiliser plusieurs Add-ons, un champ personnalisé ou une colonne de base de données.