Migration de la recherche basée sur BOD IBM Websphere Commerce Version 7 Feature Pack 6

Faites migrer votre index et vos configurations HCL Commerce Search de IBM Websphere Commerce Version 7 Feature Pack 6 vers HCL Commerce version 9.0.0.3 ou ultérieure.

HCL Commerce Version 9 utilise Solr 5.5.4, donc vos données d'index issues d'une version antérieure de Solr ne sont pas prises en charge par Solr 5.5.4.

Passez en revue les informations suivantes pour comprendre l'architecture et les fonctionnalités de HCL Commerce Search modifiées dans HCL Commerce Version 9.

La recherche basée sur BOD est obsolète dans HCL Commerce Version 9.
Le serveur HCL Commerce Search comporte son propre conteneur dans votre environnement de production. Vous déployez votre serveur HCL Commerce Search dans le cadre de votre pipeline CI/CD.
Le modèle de programmation pour HCL Commerce Search est modifié pour coïncider avec le nouveau processus de génération et de déploiement dans HCL Commerce Version 9. La base du nouveau modèle de programmation consiste à séparer les ressources HCL Commerce Search personnalisées et les paramètres de configuration du code produit, ce qui réduit les coûts de maintenance et de fonctionnement des ressources. Les personnalisations IBM Websphere Commerce Version 7 suivantes doivent être mises à jour pour le nouveau modèle de programmation :
- L'exécution de Solr est mise à niveau vers la version 5.5.4, de sorte que toute personnalisation de Solr doit être mise à jour pour suivre le nouveau modèle de programmation.
- Les utilitaires HCL Commerce Search sont remplacés par le service utilitaire de conteneur, qui inclut di-preprocess, di-buildindex, di-calculateprice et indexprop. L'utilitaire SetupSearchIndex n'est plus disponible. Le répertoire principal de l'index est maintenant automatiquement synchronisé avec la table SRCHCONF et la table SRCHCONFEXT lorsque le serveur HCL Commerce Search est démarré. Pour créer un nouveau répertoire principal, un répertoire principal d'extension ou un répertoire de langue, vous devez gérer les tables SRCHCONF et SRCHCONFEXT. Le répertoire principal de l'espace de travail est créé automatiquement si le serveur HCL Commerce Search détecte le schéma de l'espace de travail dans un environnement de création.
- Dans HCL Commerce Version 9, la vue tabulaire est utilisée pour le prétraitement et la génération d'index. Par conséquent, toute personnalisation du prétraitement et de la génération d'index doit être reconfigurée conformément au nouveau guide de programmation.
- Dans HCL Commerce Version 9, le planificateur commun basé sur les fondations est activé sur le serveur HCL Commerce Search. Dans les environnements de création, utilisez le planificateur pour répliquer les index des environnements de création vers le répéteur HCL Commerce Search.
- HCL Commerce Version 9 a été déplacé vers JAX-RS 2.0 (JSR-339). En outre, l'API de documentation est Swagger 2.0.
- IBM Websphere Commerce Version 7 utilisait les appels JDBC directs, qui passaient par DSL (couche de service de données) vers la base de données. Dans HCL Commerce Version 9, la requête native JPA 2.1 (EclipseLink) est utilisée. Les requêtes personnalisées des versions précédentes sont transférées vers le nouveau service de requête. Aucune configuration supplémentaire n'est requise.
- Dans HCL Commerce Version 9, lorsque Prix ou Stock est utilisé en tant que répertoire principal étendu, SolrJoin préserve la relation de document entre le répertoire principal CatalogEntry et le sous-répertoire Prix/Stock. MultipleQueryComponent et MultipleFacetComponent, qui ont été utilisés pour joindre ou filtrer les sous-répertoires dans IBM Websphere Commerce Version 7, sont désactivés par défaut. Pour gérer les zones de facettes et de résultats à partir des index d'extension, un nouveau processeur SearchCatalogEntryExtensionIndexPostprocessor crée une sous-requête sur chacun des index d'extension, puis revient à l'index principal. Un nouveau paramètre de jointure a également été introduit dans wc-search.xml. Toute personnalisation IBM Websphere Commerce Version 7 vers un index d'extension doit être implémentée pour utiliser SolrJoin.
  Remarque : Si nécessaire, vous pouvez restaurer les fonctionnalités précédentes de MultipleQueryComponent et MultipleFacetComponent.

Avant de commencer

Déposez toutes les tables temporaires temporaires et personnalisées de votre base de données, à l'exception des tables temporaires suivantes :
- TI_DELTA_CATENTRY
- TI_DELTA_CATGROUP
- TI_DELTA_INVENTORY
Vos tables temporaires utilisent un préfixe TI_ alors que vos tables temporaires personnalisées utilisent un préfixe XI_.
Des modifications ont été apportées aux tables temporaires entre les versions précédentes de HCL Commerce et HCL Commerce Version 9. L'échec de la suppression des tables temporaires peut entraîner des erreurs de prétraitement, par exemple, SQLSTAE=56098. Pour plus d'informations sur les tables temporaires de recherche HCL Commerce, voir Définition temporaire du schéma de table.

Procédure

Faites migrer vos répertoires d'index personnalisés. Les sous-étapes suivantes illustrent comment migrer le répertoire étendu xCatalogEntry pour le catalogue principal 10001 à titre d'exemple. Ces étapes doivent être répétées pour tous vos répertoires d'index personnalisés que vous souhaitez faire migrer.
1. Enregistrez votre répertoire d'index personnalisé en exécutant l'instruction SQL suivante. Pendant le démarrage du serveur de recherche, l'exécution de la recherche crée automatiquement le répertoire enregistré.
```
insert into srchconfext (srchconfext_id, indextype, indexscope, language_id, indexsubtype, config) values(srchconfext_id,’CatalogEntry’,10001,’xCatalogEntry’,NULL);
```
  Où :
  
  SRCHCONFEXT_ID
  
  Clé primaire pour ce tableau.
  
  INDEXTYPE
  
  Indique l'index du moteur de recherche à configurer. Les valeurs correctes de la colonne sont les suivantes :
  
  CatalogEntry (entrée de catalogue)
  
  Définit l'index pour les entrées de catalogue dans le catalogue principal.
  
  CatalogGroup
  
  Définit l'index des catégories du catalogue principal.
  
  INDEXSCOPE
  
  Étendue des données indexées. Par exemple, si l'étendue est le catalogue principal, entrez l'ID du catalogue principal ici.
  
  LANGUAGE_ID
  
  Indique la langue à utiliser pour la base d'index de recherche de sous-type correspondant. Pour obtenir une liste d'ID de langue, voir la colonne LANGUGAE_ID dans la table LANGUAGE.
  Remarque : "LANGUAGE_ID" doit être nul pour Inventory ou Price.
  
  INDEXSUBTYPE
  
  Indique le sous-type défini pour la base d'index de recherche. Les valeurs admises sont les suivantes :
  
  Structuré
  
  Définit l'index pour le contenu structuré.
  
  Non structuré
  
  Définit l'index pour le contenu non structuré.
  
  WebContent
  
  Définit l'index pour le contenu du site.
  
  Inventory
  
  Définit l'index pour les données d'inventaire.
  
  Prix
  
  Définit la base d'index externe pour les données de prix.
  
  CONFIG
  
  Indique des configurations supplémentaires pour une base d'index de recherche spécifiée. Par exemple, vous pouvez définir BasePath et StoreId pour le répertoire d'index de sous-typeWebContent. BasePath indique le chemin d'accès au contenu du site analysé et StoreId indique le magasin dans lequel créer l'index. Séparez différentes configurations par des virgules. Par exemple :
```
     BasePath=W:\IBM\WebSphere\Liberty\usr\servers\searchServer\resources\search\index\crawler\cache\2017-11-01\1\,StoreId=10501 
```
  Remarque : Si votre répertoire d'index personnalisé est un répertoire principal, tel que CatalogEntry ou CatalogGroup, vous devez ajouter des enregistrements dans la table SRCHCONF. Si votre répertoire d'index personnalisé est un répertoire étendu, tel que Inventory ou Price, vous devez ajouter des enregistrements à la table SRCHCONFEXT.
2. Créez le répertoire suivant.
  
  Liberty_installdir/usr/servers/default/resources/search/index/managed-solr/config/v3-core-extension
3. Dans le répertoire v3-core-extension, créez un répertoire appelé xCatalogEntry. Ajoutez ensuite les fichiers de configuration de base Solr étendus suivants au dossier xCatalogEntry.
  - schema.xml
  - solrconfig.xml
  - wc-data-config.xml
4. Redémarrez le serveur de recherche.
  Votre répertoire d'index personnalisé est créé automatiquement pendant le démarrage et se trouve sous le répertoire suivant.
  Search_ServerDir/default/resources/search/index/managed-solr/config/v3-core-extension
Remettez en œuvre vos zones d'index personnalisés et vos scripts d'index de prétraitement et de génération.
1. Enregistrez tous vos répertoires d'index dans votre table SRCHCONF.
2. Faites migrer vos personnalisations de schéma d'index. Dans HCL Commerce Version 9, les définitions de l'entrée de catalogue fieldType utilisent deux modèles :
  - Modèle non personnalisable : search-config/src/main/resources/managed-solr/config/v3/common/schema-field-types.xml.
    Remarque : Lorsque le premier index est créé, ce fichier XML est copié dans le répertoire resources/search/index/managed-solr/config/v3/common. Après la création de l'index, d'autres index partagent cette définition fieldType.
  - Modèle personnalisable : search-config-ext/src/main/resources/index/managed-solr/config/v3/common/x-schema-field-types.xml.
    Remarque : Lorsque le premier index est créé, ce fichier XML est copié dans le répertoire resources/search/index/managed-solr/config/v3-core-extension/common. Après la création de l'index, d'autres index partagent cette définition fieldType personnalisable.
3. Faites migrer votre schéma personnalisé fieldType en utilisant l'exemple suivant.
  Si vous avez créé une nouvelle zone x_textSpell pour l'environnement linguistique fr_FR dans une version antérieure de HCL Commerce, vous avez mis à jour le fichier schema.xml qui se trouvait dans le répertoire de configuration principal spécifique au paramètre régional fr_FR. Dans HCL Commerce Version 9, vous devez ajouter le type de zone x_textSpell_fr au fichier x-schema-field-types.xml comme suit.
```

<fieldType omitNorms="true" positionIncrementGap="100" class="solr.TextField" name="x_textSpell_fr">
<analyzer type="index">
<tokenizer class="solr.WhitespaceTokenizerFactory"/>
<filter class="solr.LowerCaseFilterFactory"/>
<filter class="solr.StopFilterFactory" words="${stopwords_fr:../../../v3/common/stopwords.txt}" ignoreCase="true"/>
<filter class="solr.WordDelimiterFilterFactory" preserveOriginal="0" splitOnNumerics="1" splitOnCaseChange="1" 
    catenateAll="0" catenateNumbers="0" catenateWords="0" generateNumberParts="1" generateWordParts="1"/>
<filter class="solr.ShingleFilterFactory" fillerToken="" tokenSeparator=" " maxShingleSize="3" minShingleSize="2" 
    outputUnigrams="true"/>
<filter class="solr.PatternReplaceFilterFactory" replace="all" replacement=" " pattern="\s{2,}"/>
<filter class="solr.TrimFilterFactory"/>
<filter class="solr.RemoveDuplicatesTokenFilterFactory"/>
</analyzer>

<analyzer type="query">
<tokenizer class="solr.WhitespaceTokenizerFactory"/>
<filter class="solr.LowerCaseFilterFactory"/>
<filter class="solr.StopFilterFactory" words="${stopwords_fr:../../../v3/common/stopwords.txt}" ignoreCase="true"/>
</analyzer>
</fieldType>
```
4. Après que le nouveau type de zone x_textSpell_fr est défini dans le fichier x-schema-field-types.xml, définissez une entrée dans votre fichier x-schema.xml en utilisant l'exemple suivant.
```
<field name="spellCheck" type="x_textSpell_fr" indexed="true" stored="false" multiValued="true" />
```
  Notes :
  - Si vous souhaitez utiliser toutes les langues prises en charge, vous devez créer un type de zone pour chaque langue dans le fichier x-schema-field-types.xml, puis ajouter la définition de zone suivante dans le fichier x-schema.xml.
    <field name="spellCheck" type="x_textSpell_${lang:en}" indexed="true" stored="false" multiValued="true" />
5. Faites migrer vos mots neutres personnalisés.
  Dans IBM Websphere Commerce Version 7, vous pouvez modifier le fichier stopwords.txt de chaque répertoire de configuration de base. Par exemple, si vous avez personnalisé stopwords.txt pour la langue anglaise, il suffit de modifier le fichier stopwords.txt dans la base en_US. Lorsque vous migrez vers HCL Commerce Version 9, les schémas d'index sont partagés entre plusieurs langues. Pour personnaliser stopwords.txt pour une langue spécifique, HCL Commerce Version 9 nécessite que vous pointiez vers le fichier dans la table de base de données SRCHCONFEXT. Pour plus d'informations sur la personnalisation de stopwords.txt, voir Personnalisation du fichier stopwords.txt. Exécutez la commande SQL suivante pour placer stopwords.txt dans la zone config :
```
Update srchconfext set config='stopwords_en=../../../../managed-solr/config/v3-core-extension/common/stopwords.txt' 
where indextype=’CatalogEntry’ and indexscope=’$MASTERCATALOGID’
```
  Lorsque le serveur de recherche HCL Commerce est redémarré, le contenu suivant est ajouté à x-core.properties sous le répertoire de données d'index en_US.
```
stopwords_en=../../../../managed-solr/config/v3-core-extension/common/stopwords.txt
```
  Si vous devez modifier le fichier stopwords.txt qui se trouve sous le répertoire workspace_dir\search-config-ext\src\index\managed-solr\config\v3\common, le nouveau stopwords.txt est copié dans le répertoire Liberty_installdir\resources\search\index\managed-solr\config\v3-core-extension\common dans le cadre de la configuration de votre pipeline WCB et CI/CD.
  Par exemple, dans IBM Websphere Commerce Version 7, vous avez ajouté un nouveau mot neutre en anglais : can. Les étapes suivantes vous montrent comment faire migrer cette personnalisation.
  1. Ajoutez can au bas de votre fichier HCL Commerce Version 9 workspace_dir\search-config-ext\src\index\managed-solr\config\v3\common\stopwords.txt.
  2. Ajoutez le chemin d'accès stopwords.txt personnalisé dans la colonne CONFIG de la table SRCHCONFEXT en exécutant l'instruction SQL suivante :
    Update srchconfext set config='stopwords_en=../../../../managed-solr/config/v3-core-extension/common/stopwords.txt' where indextype='CatalogEntry' and indexscope='10001';
6. Faites migrer vos fichiers de prétraitement personnalisés.
  Dans IBM Websphere Commerce Version 7, lorsque vous avez créé un fichier preprocess.xml personnalisé pour indexer des données externes, le fichier personnalisé se trouve sous le répertoire solrhome/pre-processConfig/MC_MasterCatalog/Dbtype. Dans HCL Commerce Version 9, ces fichiers XML de prétraitement se trouvent sous le répertoire WCDE_installdir/xml/search/dataImport/v3/Dbtype/.
  Copiez le fichier wc-dataimport-preprocess-custom.xml de votre environnement IBM Websphere Commerce Version 7 dans le répertoire WCDE_installdir/xml/search/dataImport/v3/Dbtype/ de HCL Commerce Version 9. En outre, copiez tous les fichiers référencés par le fichier wc-dataimport-preprocess-custom.xml dans HCL Commerce Version 9, et mettez à jour le fichier wc-dataimport-preprocess-custom.xml pour vous assurer qu'il pointe pour corriger le fichier de chemin d'accès si vous modifiez l'emplacement du fichier sur HCL Commerce Version 9. Par exemple, peut-être avez-vous spécifié un fichier d'entrée dans wc-dataimport-preprocess-custom.xml comme suit.
```

<_config:property name="inputFile" value="W:\WCDE_INT70\bin\Ratings.xml"/>
```
  Si tel est le cas, vous devez copier le fichier Ratings.xml de IBM Websphere Commerce Version 7 dans HCL Commerce Version 9.0.0.1+, le placer sous WCDE_installdir\bin et mettre à jour wc-dataimport-preprocess-custom.xml pour pointer vers le nouvel emplacement.
```

<_config:property name="inputFile" value="W:\WCDE_v9\bin\Ratings.xml"/>
```
7. Faites migrer vos fichiers de gestionnaire d'importation de données personnalisés.
  Si vous souhaitez indexer plus de données dans IBM Websphere Commerce Version 7, vous avez modifié le fichier wc-data-config.xml dans le répertoire de base spécifique. Par exemple, si vous souhaitez indexer plus de données de la table X_RATING en anglais, vous avez modifié le fichier wc-data-config.xml sous le répertoire de base en_US pour autoriser query et deltaImportQuery à rejoindre la table X_RATING. Dans HCL Commerce Version 9, le DataImportHandler (DIH) Solr obtient des données de la vue VI_CE_#INDEX_SCOPE_TAG#_#lang_tag# et X_VI_CE_#INDEX_SCOPE_TAG#_#lang_tag#. Ajoutez cette nouvelle table personnalisable dans la vue X_VI_CE_#INDEX_SCOPE_TAG#_#lang_tag# dans wc-dataimport-preprocess-x-finalbuild.xml. Pour plus d'informations, voir Configuration du mappage du gestionnaire d'importation de données.
  
  Une fois que les tables personnalisées sont ajoutées à la table X_VI_CE, les données personnalisées peuvent être renvoyées et rendues accessibles pour Solr grâce au DIH. Définissez le mappage de colonnes de zone afin que Solr puisse transférer la nouvelle colonne personnalisée dans les zones Solr. Mettez à jour le fichier search-config-ext/src/main/resources/index/managed-solr/config/v3/CatalogEntry/x-data-config.xml pour ajouter le mappage de zone.
  Voici un exemple du nouveau mappage. Avec ce mappage, la colonne RATING de la vue X_VI_CE effectue un mappage vers la zone customerRanking dans l'index d'entrée du catalogue.
```
<field column="RATING" name="customerRanking"/>
```
8. Faites migrer la table SRCHATTRPROP pour activer les requêtes de plage de prix.
  Dans HCL Commerce la version 7.0, la facette de la plage de prix par défaut prend le format suivant.
```
"price_USD:{* 100} 100;{100 200} 200;{200 300} 300;{300 400} 400;{400 500} 500;{500 *}"
```
  Dans Solr version 7.3.1, ce format provoque une erreur de syntaxe dans l'analyseur de requête. Si vous utilisez HCL Commerce version 9.0.0.5 ou ultérieure, modifiez la chaîne de requête dans le format suivant.
```
 "price_USD:{* TO 100];{100 TO 200];{200 TO 300];{300 TO 400];{400 TO 500];{500 TO *}" 
```
  Remarque : Convertissez les formats de requête de plage précédents qui prennent la forme "({lower upper} upper)" en "({lower TO upper])". Faites migrer d'autres personnalisations impliquant l'ancien format de requête vers le nouveau format.
9. Faites migrer les types de zones de schéma par défaut.
  A partir de Solr version 7.0.0, les zones Trie*Field sont obsolètes. Remplacez-les par *PointField. Le paramètre par défaut conserve les anciennes zones de type de données (par exemple, int, tint, sint) et crée de nouvelles zones (par exemple, pint, pints). Même si les anciennes zones fonctionnent toujours, mettez à niveau l'ancien type de données vers le nouveau pour garantir la compatibilité future. Certaines zones obsolètes sont encore utilisées, par exemple, des types de zones protégés, pour des questions de compatibilité.
10. Faites migrer des paramètres solrconfig.xml personnalisés.
  Pour Solr version 7.3.1, déplacez le paramètre de configuration solr.mergeFactor du fichier solrconfig.xml dans la colonne SRCHCONFEXT.CONFIG. Il est remplacé par deux paramètres : solr.mergePolicy.maxMergeAtOnce et solr.mergePolicy.segmentsPerTier. Si vous avez précédemment défini la valeur sur quelque chose comme <mergeFactor>5</mergeFactor>, remplacez-la par solr.mergePolicy.maxMergeAtOnce=5,solr.mergePolicy.segmentsPerTier=5.
11. Redémarrez le serveur de recherche.
12. Générez votre index de recherche.
Faites migrer vos fichiers de configuration de recherche. Toutes les mises à jour de configuration que vous avez effectuées sous les répertoires IBM Websphere Commerce Version 7 WC_eardir doivent être copiées dans les répertoires d'extension correspondants sous le répertoire Search_eardir dans HCL Commerce Version 9. Les répertoires d'extension sont com.ibm.commerce.foundation-ext et com.ibm.commerce.search-ext.

Enregistrez vos profils de recherche personnalisés en les associant à un service REST.

Accédez au répertoire ci-dessous.

workspace_dir\search-config-ext\src\runtime\config\com.ibm.commerce.rest

Créez un fichier et nommez-le wc-rest-resourceconfig.xml, puis ajoutez le paragraphe passe-partout XML suivant.

<?xml version="1.0" ?>
<!--
 =================================================================
  Licensed Materials - Property of IBM
  HCL Commerce
  (C) Copyright IBM Corp. 2013, 2017 All Rights Reserved.
  US Government Users Restricted Rights - Use, duplication or
  disclosure restricted by GSA ADP Schedule Contract with
  IBM Corp.
 =================================================================
-->
<!--
	This XML defines services related configuration data for rest services.
	Currently the only configurable attributes are searchProfile for GET methods.
-->
<ResourceConfig>
    
</ResourceConfig>

Identifiez le service REST sous lequelle le profil de recherche personnalisé doit être répertorié.
Ajoutez votre profil de recherche personnalisé à la fin de la liste définie de profils de recherche.
Enregistrez et fermez le fichier.

Réappliquez toutes vos configurations personnalisées à votre fichier wc-search.xml.
Notes :
- Supprimez toutes les configurations de connexion qui se rapportent à un serveur Solr distant. Dans le serveur de recherche HCL Commerce Version 9, la connexion à Solr est incorporée.
- Etant donné que vos bases sont maintenant lues à partir des tables SRCHCONF et SRCHCONFEXT, supprimez toutes les bases enregistrées de votre fichier wc-search.xml.
- Tous les profils de recherche personnalisés définis dans le serveur HCL Commerce doivent être redéfinis dans le répertoire d'extension du serveur de recherche HCL Commerce.
- Tous les profils de recherche personnalisés qui étendent un profil de recherche par défaut dans le serveur HCL Commerce doivent être mis à jour. De nouveaux profils de recherche par défaut sont introduits dans le serveur de recherche qui contient des noms ou des conventions de dénomination différents.
- Tous les profils de recherche personnalisés qui utilisent l'un des fournisseurs de requêtes de recherche, des processeurs ou des filtres de résultats de recherche par défaut doivent être mis à jour. De nouvelles alternatives sont introduites dans le serveur de recherche qui contient des noms différents ou utilisent différentes conventions de dénomination.
Réappliquez toutes les configurations personnalisées que vous avez effectuées dans les fichiers wc-component.xml sous les répertoires com.ibm.commerce.foundation-ext et com.ibm.commerce.search-ext.

La plupart des propriétés personnalisées liées à la recherche définies dans le fichier wc-component.xml peuvent être réutilisées dans le serveur de recherche, à l'exception de la propriété du mode de tarification global. La configuration du mode de tarification est maintenant stockée dans la table STORECONF.  Pour plus d'informations sur les propriétés de configuration de recherche dans la table STORECONF, voir Propriétés de configuration de recherche dans la table STORECONF.

Faites migrer les médiateurs d'objets personnalisés que vous avez créés dans le fichier IBM Websphere Commerce Version 7 wc-business-objectmediator.xml vers HCL Commerce Version 9 wc-component.xml.

Le serveur de recherche ne prend plus en charge les médiateurs d'objets métier. Par conséquent, toutes les personnalisations appliquées au fichier wc-business-object-mediator.xml doivent être déplacées vers le fichier wc-component.xml.

Par exemple, les mappages entre un champ personnalisé userData vers une zone d'index interne ou une zone de base de données doivent maintenant utiliser les mappages corrects sous le fichier wc-component.xml. L'exemple suivant montre comment un mappage userData existant sous le fichier de serveur wc-business-object-mediator.xml HCL Commerce peut être déplacé dans le fichier personnalisé du serveur de recherche wc-component.xml.

Ouvrez votre wc-business-object-mediator.xml et localisez la ligne de code suivante :

<_config:mediator-property naem="CatalogEntryView/UserData [ (Name='SKU') ]" value partNumber_ntk"

Ouvrez votre recherche wc-component.xml et ajoutez le mappage correspondant.

Dans le serveur de recherche, le mappage entre les noms internes et externes se fait à l'aide de la section valuemappingservice du fichier wc-component.xml. Il existe différentes cartes pour CatalogEntry - UserData et CatalogGroup - UserData.

Pour le mappage CatalogEntry - UserData, ajoutez le code suivant à votre fichier wc-component.xml.

<_config:valuemapping externalName="CatalogEntryUserDataFieldNameMapping" internalName="CatalogEntryUserDataFieldNameMapping"> 
        <_config:valuemap externalValue="SKU" internalValue="partnumber_ntk" /> 
</_config:valuemapping>

Pour le mappage CatalogGroup - UserData, ajoutez le code suivant à votre fichier wc-component.xml.

<!-- 
    Custom index field name => CategoryView REST response field name 

    This CatalogGroupUserDataFieldNameMapping mapping is for defining the mapping from a custom index field 
    name used in the CatalogGroup search index to the field name used in the UserData area in the REST response. 
    
    For example, 
    
            <_config:valuemap externalValue="response_field_label" internalValue="my_index_field_name" /> 
    
    The name of the index field name can be a dynamic field and this name pattern must end with "*". 
    There is a restriction when using for dynamic fields - only one dynamic field that matches the 
    given name pattern will be mapped. 
    
    For example, 
    
            <_config:valuemap externalValue="response_field_label" internalValue="my_index_*" /> 

    Note: SearchCatalogGroupViewUserDataQueryPostprocessor must be added to the end of 
          the query section of the search profile in order to activate this configuration. 
          In addition, make sure the custom index field is also defined in the result section of 
          the search profile so that this custom index field can be returned from Solr. 
-->                 
<_config:valuemapping externalName="CatalogGroupUserDataFieldNameMapping" internalName="CatalogGroupUserDataFieldNameMapping"> 
</_config:valuemapping> 


Where the mappings are being populated by the following postprocessors: 
                
    <_config:postprocessor classname="com.ibm.commerce.search.internal.expression.postprocessor.SearchCatalogEntryViewUserDataQueryPostprocessor" />   
                                    
        <_config:postprocessor classname="com.ibm.commerce.search.internal.expression.postprocessor.SearchCatalogGroupViewUserDataQueryPostprocessor" />

Assurez-vous que les post-processeurs requis sont inclus dans votre profil de recherche.

Réappliquez les fichiers de modèle de requête de base de données personnalisés (TPL).

Le serveur de recherche prend en charge DSL. Toutefois, il ne prend pas en charge les EMF, les SDO et les schémas logiques. Par conséquent, toutes les données récupérées à partir de la base de données doivent être analysées par un code personnalisé et ajoutées à la réponse principale, le cas échéant. Toutes les requêtes personnalisées liées à la recherche peuvent être réutilisées dans le serveur de recherche. Pour plus d'informations, voir Création d'un post-processeur de requête personnalisé.

Le serveur de recherche ne prend en charge aucune balise de modèle de requête. Chacun des paramètres de requête doit être transmis aux services de requête en tant que paramètre de requête.
Pour permettre à la requête personnalisée de s'exécuter sous le schéma de l'espace de travail, ajoutez bull$SCHEMA$ à la table.

Si la requête personnalisée présente une syntaxe de requête différente pour Oracle, définissez un nouveau nom de requête. Et dans le code, utilisez un autre nom de requête après avoir déterminé dbType, par exemple :

<!-- ======================================================================================= --> 
<!--  Retrieve search configuration for given master catalog by all store's default language --> 
<!-- ======================================================================================= --> 

...

BEGIN_SQL_STATEMENT 
        name=SELECT_SRCHCONF_DEFAULT_ORACLE 
        base_table=SRCHCONF 
        sql= 
        SELECT STORECAT.CATALOG_ID, 
               STORE.LANGUAGE_ID, 
               SRCHCONF.INDEXSCOPE, 
                   SRCHCONF.CONFIG 
          FROM $SCHEMA$.STORECAT STORECAT, $SCHEMA$.STORE STORE, $SCHEMA$.SRCHCONF SRCHCONF 
         WHERE STORECAT.MASTERCATALOG = '1' 
           AND STORECAT.STOREENT_ID = STORE.STORE_ID 
           AND STORE.STATUS IN (?status?, 1) 
           AND TO_CHAR(STORECAT.CATALOG_ID) = SRCHCONF.INDEXSCOPE 
           AND SRCHCONF.INDEXTYPE = ?indexType? 
END_SQL_STATEMENT

Toutes les ressources personnalisées qui doivent récupérer des données à partir de la base de données doivent utiliser SearchQueryService pour lire les données, comme dans l'exemple de code suivant :

SearchQueryService service = new SearchQueryService(); 
  HashMap parameters = new HashMap(); 
  ArrayList list = new ArrayList(); 
  list.add(getMasterCatalog(coreName)); 
  parameters.put(STR_MASTER_CATALOG_ID, list); 
  list = new ArrayList(); 
  list.add(tokens[1]); 
  parameters.put(STR_INDEX_TYPE, list); 
  list = new ArrayList(); 
  list.add(getLanguageId(coreName)); 
  parameters.put(LANGUAGE_ID, list); 
  List<Object[]> results = service.executeQueryName("SELECT_SRCHCONFEXT", parameters); 
  if (results.size() > 0) { 
          indexSubtype = new ArrayList<String>(); 
          final String STR_INDEXSUBTYPE = "INDEXSUBTYPE"; 
          for (Object[] row : results) { 
                  indexSubtype.add((String) row[1]); 
          } 
          imapSearchIndexSubtype.put(coreName, indexSubtype); 
  }

Faites migrer vos ressources personnalisées Java.

En raison de l'utilisation de la conteneurisation, toutes les personnalisations doivent être générées par le script WCB et déployées par votre pipeline CI/CD. Par défaut, des ressources de configuration personnalisées peuvent être ajoutées sous le répertoire search-config-ext et des ressources java personnalisées peuvent être ajoutées sous le répertoire search-logic-ext. Ensuite, le script WCB par défaut et le pipeline CI/CD peuvent générer et déployer ces ressources dans le conteneur de recherche.
1. Vous pouvez réutiliser vos fournisseurs d'expressions personnalisés.
  
  Pour les services basés sur BOD IBM Websphere Commerce Version 7, tous les fournisseurs d'expression par défaut sont conditionnés sous com.ibm.commerce.catalog.facade.server.services.search.expression.solr. Pour HCL Commerce Version 9, tous les fournisseurs d'expression sont déplacés vers le package com.ibm.commerce.search.internal.expression.provider. Le modèle de dénomination a également été modifié. Votre fournisseur d'expression personnalisé doit donc être modifié pour remplacer le nouveau fournisseur d'expression. La logique principale doit rester compatible avec la recherche BOD.
2. Vous pouvez réutiliser vos préprocesseurs d'expression personnalisés.
  
  Dans IBM Websphere Commerce Version 7, les préprocesseurs de requête de recherche basés sur BOD fonctionnaient sur l'objet SolrQuery physique natif hérité du parent suivant AbstractSolrSearchQueryPreprocessor, conditionné dans com.ibm.commerce.foundation.internal.server.services.search.query.solr.
  
  Dans la recherche HCL Commerce Version 9, le parent est conditionné dans com.ibm.commerce.search.internal.expression.preprocessor.
3. Réappliquez vos post-processeurs de résultats de requête personnalisés.
  Si vos post-processeurs personnalisés fonctionnent sur la requête native, ils peuvent être réutilisés en remplaçant le post-processeur lié. Toutefois, si le post-processeur personnalisé fonctionne sur SolrCatalogNavigationViewImpl, il ne peut pas être réutilisé.
  Vous pouvez également modifier votre code personnalisé pour l'utiliser sur SearchResponse. Par exemple, le fragment suivant montre comment utiliser SearchResponse :
```
List<Map<String, Object>> catalogEntryViews = (LinkedList<Map<String, Object>>)iSearchResponseObject.getResponse().get("external object name");
```
  Où le nom de l'objet correspond au nom de l'objet externe. Pour plus d'informations sur la résolution de noms externes, voir l'exemple de post-processeurs personnalisés dans le fichier wc-search.xml.
4. Réappliquez vos filtres de résultats de requête de recherche personnalisés.
  
  Les filtres de résultats personnalisés qui fonctionnent sur le nom logique CatalogNavigationViewType ne sont pas pris en charge dans le serveur de recherche HCL Commerce Version 9. Tous les filtres de résultats personnalisés doivent être remis en œuvre à l'aide de post-processeurs de requête de recherche. Pour plus d'informations, voir Création d'un post-processeur de requête personnalisé.
5. Réappliquez vos médiateurs d'objets métier.
  
  Dans IBM Websphere Commerce Version 7, les médiateurs d'objets métier fonctionnaient sur le nom logique CatalogNavigationViewType. Cela n'est plus pris en charge sur le serveur de recherche. Au lieu de cela, vous pouvez utiliser des post-processeurs de requête de recherche. Tous les médiateurs personnalisés qui étendent la classe parent AbstractReadBusinessObjectPartMediatorImpl doivent être remis en œuvre à l'aide de post-processeurs de requête de recherche.

Faites migrer vos services de recherche de vitrine.

Dans IBM Websphere Commerce Version 7, la navigation de catalogue utilisait getDataTag. Dans HCL Commerce Version 9, vous pouvez utiliser l'équivalent RESTTag basé sur REST.

Toutes les pages de vitrine personnalisées qui utilisent les services BOD CatalogNavigationView doivent être mises à jour pour utiliser les services REST correspondants. Par exemple, le fragment suivant est un service de recherche BOD getData utilisé pour obtenir des produits par catégorie :

<wcf:getData type="com.ibm.commerce.catalog.facade.datatypes.CatalogNavigationViewType" var="catalogNavigationView"
   expressionBuilder="getCatalogEntrySearchResultsByIDView" scope="request" varShowVerb="showCatalogNavigationView"
   maxItems="100" recordSetStartNumber="0" scope="request">
   <c:forEach var="marketingSpotData" items="${marketingSpotDatas.baseMarketingSpotActivityData}">
       <c:if test='${marketingSpotData.dataType eq "CatalogEntryId"}'>
           <wcf:param name="UniqueID" value="${marketingSpotData.uniqueID}"/>
       </c:if>
   </c:forEach>
   <wcf:contextData name="storeId" data="${WCParam.storeId}" />
   <wcf:contextData name="catalogId" data="${WCParam.catalogId}" />
</wcf:getData>
<c:set var="eSpotCatalogIdResults" value="${catalogNavigationView.catalogEntryView}"/>

Le fragment suivant est le service basé sur REST équivalent :

<wcf:getData type="com.ibm.commerce.catalog.facade.datatypes.CatalogNavigationViewType" var="catalogNavigationView"
   expressionBuilder="getCatalogEntrySearchResultsByIDView" scope="request" varShowVerb="showCatalogNavigationView"
   maxItems="100" recordSetStartNumber="0" scope="request">
   <c:forEach var="marketingSpotData" items="${marketingSpotDatas.baseMarketingSpotActivityData}">
       <c:if test='${marketingSpotData.dataType eq "CatalogEntryId"}'>
           <wcf:param name="UniqueID" value="${marketingSpotData.uniqueID}"/>
       </c:if>
   </c:forEach>
   <wcf:contextData name="storeId" data="${WCParam.storeId}" />
   <wcf:contextData name="catalogId" data="${WCParam.catalogId}" />
</wcf:getData>
<c:set var="eSpotCatalogIdResults" value="${catalogNavigationView.catalogEntryView}"/>

Les données de réponse sont mises en forme dans une réponse de notation décimale semblable à BOD afin de minimiser les changements requis dans la vitrine. Dans certains cas, la réponse est simplifiée et mise à plat en paires de valeur de nom plus simples, plutôt que d'utiliser des cartes internes pour regrouper certaines zones.

Vous pouvez examiner la réponse JSON en imprimant l'objet de réponse à l'aide du code suivant :

<wcf:json object="${catalogNavigationView}"/>

Mappez vos services BOD aux services REST.

Tous les services de recherche BOD peuvent être couverts par les services de recherche REST. Il existe trois principaux gestionnaires de recherche : CategoryViewHandler, ProductViewHandler et SiteContentHandler. Chacun exécute des fonctionnalités de recherche différentes. Par exemple, ProductViewHandler peut effectuer une recherche par catégorie, productId, productIds, partNumber, partNumbers et searchTerm.

Utilisez le tableau suivant pour faciliter le mappage de vos services BOD aux services REST.

Tableau permettant d'illustrer le mappage entre les services BOD et REST.
Service BOD	Générateur d'expression	Ressource REST	Service REST
CatalogNavigationView	getCatalogNavigationView	ProductViewHandler (recherche)	store/{storeId}/productview/bySearchTerm/{searchTerm}
	getCatalogNavigationAttachmentView		store/{storeId}/productview/bySearchTerm/{searchTerm}
	getCatalogNavigationViewByCategory		store/{storeId}/productview/byCategory/{categoryId}
	getCatalogNavigationBreadCrumbView		store/{storeId}/productview/byCategory/{categoryId}
	getCatalogNavigationCatalogEntryView		store/{storeId}/productview/byId/{productId}, store/{storeId}/productview/byIds
	getCatalogEntryViewAllWithoutAttachmentsByID		store/{storeId}/productview/byId/{productId}, store/{storeId}/productview/byIds
	getCatalogEntrySearchResultsByIDView		store/{storeId}/productview/byId/{productId}, store/{storeId}/productview/byIds
	getCatalogEntryViewParentInfoByIDNoEntitlementCheck		store/{storeId}/productview/byId/{productId}, store/{storeId}/productview/byIds
	getCatalogEntryViewForShoppingCart		store/{storeId}/productview/byId/{productId}, store/{storeId}/productview/byIds
	getCatalogEntryViewPriceWithAttributesByID		store/{storeId}/productview/byId/{productId}, store/{storeId}/productview/byIds
	getCatalogNavigationCatalogGroupView	CategoryViewHandler (recherche)	store/{storeId}/categoryview/byId/{categoryId}, store/{storeId}/categoryview/byIds
	getCatalogNavigationCatalogGroupViewByIdentifier		store/{storeId}/categoryview/{categoryIdentifier}
	getCatalogNavigationCatalogGroupViewByCatalogId		store/{storeId}/categoryview/@top
	getCatalogNavigationCatalogGroupViewByParentCatalogGroup		store/{storeId}/categoryview/byParentCategory/{parentCategoryId}
	getWebContentView	SiteContentHandler (recherche)	store/{storeId}/sitecontent/webContentsBySearchTerm/{searchTerm}
			store/{storeId}/sitecontent/brandSuggestions
			store/{storeId}/sitecontent/categorySuggestions

Importez EnvironmentSetup.jspf dans la page où vous appeliez le service BOD pour suivre le guide de programmation JSP. Dans ce fichier JSPF, searchHostName, les searchContextPath sont définis, donc dans le JSP où vous souhaitez appeler le service REST de recherche, cette variable peut être utilisée directement.
En utilisant le mappage entre BOD et REST de recherche, recherchez le service REST équivalent, puis modifiez getDataTag par RESTtag.
Avec la requête BOD, le côté magasin pourrait utiliser le nom CatalogNavigationViewType pour récupérer l'objet nécessaire à partir de la réponse de la requête BOD. Ce nom représente essentiellement une réponse métier d'une requête de navigation de catalogue.

Mappez vos profils de recherche BOD aux profils de recherche REST.

Le tableau suivant illustre le mappage entre les profils de recherche utilisés par les services CatalogNavigationViewBOD et les profils de recherche REST correspondants. Plusieurs facteurs différencient les profils de recherche les uns des autres. Lorsque vous comparez les profils de recherche, prenez en compte les facteurs suivants.

Champs de requête: Contrôle l'étendue de la recherche.
Champs de résultats: Contrôle les champs renvoyés.
Fournisseurs d'expressions: Contribue à l'objet de critères de sélection.
Préprocesseurs: Prépare l'objet d'expression de recherche finale.
Postprocesseurs: Assure la médiation de la réponse de recherche et contribue à l'objet de réponse finale.

Mappage entre les profils de recherche BOD et les profils de recherche REST.
Profil de recherche BOD	Profil de recherche REST
`IBM_ComposeProductListByCategoryId`	`IBM_findProductsByCategory`
`IBM_ComposeCategoryFacetListByCategoryId`	Rendu obsolète par `IBM_findProductsByCategory`
`IBM_BreadCrumb`	`IBM_BreadCrumbByCategoryUniqueId`
`IBM_findFacetsByCategory`	Rendu obsolète par `IBM_findProductsByCategory`
I`BM_ComposeFacetListByCategoryId`	`IBM_ComposeFacetListByCategoryId`
`IBM_findCatalogEntryWithoutDescriptionByNameAndShortDescription`	`IBM_findProductsBySearchTerm`
`IBM_findCatalogEntryWithoutDescriptionByNameAndShortDescriptionInDetail`	Rendu obsolète par `IBM_findProductsBySearchTerm`
`IBM_findCatalogGroupByFacet`	Rendu obsolète par `IBM_findProductsBySearchTerm`
`IBM_findCatalogEntryByName`	`IBM_findProductsByNameOnly`
`IBM_findCatalogEntryByUnstructureField`	`IBM_findProductsByUnstructureOnly`
`IBM_findCatalogEntryByNameAndShortDescriptionOnly`	`IBM_findProductsByNameAndShortDescriptionOnly`
`IBM_findCatalogEntryByNameAndShortDescription`	Rendu obsolète par `IBM_findProductsByNameAndShortDescriptionOnly`
`IBM_findCatalogEntryByNameAndShortDescriptionInDetail`	Rendu obsolète par `IBM_findProductsByNameAndShortDescriptionOnly`
`IBM_findCatalogEntryIdByNameAndShortDescription`	Rendu obsolète par `IBM_findProductsByNameAndShortDescriptionOnly`
`IBM_findCatalogEntryDetails`	`IBM_findProductByIds_Details`
`IBM_findCatalogEntryAll`	Rendu obsolète par `IBM_findProductByIds_Details`
`IBM_findCatalogEntryAll_PriceMode`	Rendu obsolète par `IBM_findProductByIds_Details`
`IBM_findCatalogEntrySKUs`	Rendu obsolète par `IBM_findProductByIds_Details`
`IBM_findCatalogEntryDetailsWithComponents`	Rendu obsolète par `IBM_findProductByIds_Details`
`IBM_findCatalogEntryDetailsWithComponentsAndAttachments`	Rendu obsolète par `IBM_findProductByIds_Details`
`IBM_findCatalogEntryDetailsWithMerchandisingAssocDetails`	Rendu obsolète par `IBM_findProductByIds_Details`
`IBM_findCatalogEntryDetails_PriceMode`	Rendu obsolète par `IBM_findProductByIds_Details`
`IBM_findComponentsSummary`	Rendu obsolète par `IBM_findProductByIds_Details`
`IBM_findComponentsSummaryDetails`	Rendu obsolète par `IBM_findProductByIds_Details`
`IBM_findCatalogEntryDetailsWithMerchandisingAssocSummary`	Rendu obsolète par `IBM_findProductByIds_Details`
`IBM_fetchRelatedCatalogEntryDetailedInfo`	Rendu obsolète par `IBM_findProductByIds_Details`
`IBM_findCatalogEntrySummary`	`IBM_findProductByIds_Summary`
`IBM_findCatalogEntryByID`	Rendu obsolète par `IBM_findProductByIds_Summary`
`IBM_findCatalogEntryPrice`	Rendu obsolète par `IBM_findProductByIds_Summary`
`IBM_findCatalogEntryDynamicKitSummary`	Rendu obsolète par `IBM_findProductByIds_Summary`
`IBM_fetchRelatedCatalogEntrySummaryInfo`	Rendu obsolète par `IBM_findProductByIds_Summary`
`IBM_CatalogEntryCategoryEntitlement`	Rendu obsolète par `IBM_findProductByIds_Summary`
`IBM_CatalogEntryEntitlement`	Rendu obsolète par `IBM_findProductByIds_Summary`
`IBM_findCatalogEntryPriceWithAttributes_PriceMode`	Rendu obsolète par `IBM_findProductByIds_Summary`
`IBM_findCatalogEntryAttachments`	`IBM_findProductByIdsWithAttributesAndAttachments`
`IBM_findCatalogEntryDetailsWithAttachments`	Rendu obsolète par `IBM_findProductByIdsWithAttributesAndAttachments`
`IBM_findCatalogEntryPriceWithAttributes`	Rendu obsolète par `IBM_findProductByIdsWithAttributesAndAttachments`
`IBM_findAttachmentByCatentryId`	Rendu obsolète par `IBM_findProductByIdsWithAttributesAndAttachments`
`IBM_findCatalogEntryParentInfoNoEntitlementCheck`	`IBM_findProductByIds_Summary_WithNoEntitlementCheck`
`IBM_findCatalogEntryForShoppingCart`	`IBM_findProductByIds_Summary_WithNoEntitlementCheck`
`IBM_findCatalogGroupSummary`	`IBM_findCategoryByUniqueIds, IBM_findCategoryByIdentifier`
`IBM_findCatalogGroupDetails`	`IBM_findSubCategories`
`IBM_Global_WebContent`	`IBM_findWebContentsBySearchTerm`
`IBM_findAttachmentByContent`	Rendu obsolète par `IBM_findWebContentsBySearchTerm`
`IBM_findNavigationSuggestion_Brands`	`IBM_findNavigationSuggestion_Brands`
`IBM_findNavigationSuggestion_Categories`	`IBM_findNavigationSuggestion_Categories`
`IBM_Global`	Il n'y a pas de correspondance exacte pour ce profil de recherche sur le serveur de recherche HCL Commerce Version 9. Envisagez de le remplacer par les profils de recherche suivants : `IBM_findProductsByCategory` (pour la navigation) `IBM_findProductsBySearchTerm` (pour la recherche par mot clé) `IBM_findProductByIds_Details` (pour la page d'affichage de produit)
`IBM_Global_Unstructured`	Il n'y a pas de correspondance exacte pour ce profil de recherche sur le serveur de recherche. Envisagez de le remplacer par les profils de recherche suivants : `IBM_findWebContentsBySearchTerm` (pour le contenu Web) `IBM_findProductsByUnstructureOnly` (pour la recherche de pièces jointes à un produit)
`IBM_findNavigationSuggestions`	Il n'y a pas de correspondance exacte pour ce profil de recherche sur le serveur de recherche. Envisagez de le remplacer par les profils de recherche suivants : `IBM_findNavigationSuggestion_Categories` (pour les suggestions de catégorie) `IBM_findNavigationSuggestion_Brands` (pour les suggestions de marque)

Mappez vos fournisseurs d'expression BOD aux fournisseurs d'expression REST en faisant référence au tableau suivant.


Fournisseur d'expressionr de recherche basé sur BOD	Fournisseur d'expressions de recherche basé sur REST	Description
`SolrSearchBasedMerchandisingExpressionProvider`	`SearchBasedMerchandisingExpressionProvider`	Appelle le composant marketing pour exécuter les règles de recherche.
`SolrSearchByCatalogExpressionProvider`	`SearchByCatalogExpressionProvider`	Gère la recherche par catalogue en tenant compte du catalogue de vente dans le contexte métier actuel.
`SolrSearchByCategoryExpressionProvider`	`SearchByCategoryExpressionProvider`	Gère la recherche par catégorie en tenant compte du catalogue de vente dans le contexte métier actuel.
`SolrSearchByCustomExpressionProvider`	`SearchByCustomExpressionProvider`	Inclut les expressions personnalisées stockées dans `_wcf.search.expr`.
`SolrSearchByFacetExpressionProvider`	`SearchByFacetExpressionProvider`	Gère la recherche par requêtes de facettes.
`SolrSearchByKeywordExpressionProvider`	`SearchByKeywordExpressionProvider`	Gère la recherche par requêtes de mots clés.
`SolrSearchByKeywordRelevancyExpressionProvider`	`SearchByKeywordRelevancyExpressionProvider`	Gère la recherche par des requêtes de mots clés qui utilisent l'analyseur de requête dismax.
`SolrSearchByManufacturerExpressionProvider`	`SearchByManufacturerExpressionProvider`	Gère la recherche par requête de nom de marque.
`SolrSearchByPriceExpressionProvider`	`SearchByPriceExpressionProvider`	Gère la recherche par les requêtes de plage de prix générées à partir de la page Recherche avancée.
`SolrSearchByPublishedEntryOnlyExpressionProvider`	`SearchByPublishedEntryOnlyExpressionProvider`	Génère des conditions pour limiter les résultats de recherche aux seules entrées publiées.
`SolrSearchByStorePathExpressionProvider`	`SearchByStorePathExpressionProvider`	Génère des conditions pour gérer le chemin d'accès du magasin.
`SolrSearchCategoryEntitlementExpressionProvider`	`SearchCategoryEntitlementExpressionProvider`	Effectue l'autorisation de catégorie.
`SolrSearchFacetConditionExpressionProvider`	`SearchFacetConditionExpressionProvider`	Génère une liste de facettes liées aux attributs et de gamme de prix spécifiques aux devises pour la requête de recherche en cours.
`SolrSearchInventoryExpressionProvider`	`SearchInventoryExpressionProvider`	Gère la recherche liée à l'index de stock.
`SolrSearchProductEntitlementExpressionProvider`	`SearchProductEntitlementExpressionProvider`	Effectue l'autorisation de produit.
`SolrSearchSequencingExpressionProvider`	`SearchProductSequencingExpressionProvider`	Organise les entrées de produit dans le résultat de recherche par classement.
`SolrSearchTermAssociationExpressionProvider`	`SearchTermAssociationExpressionProvider`	Trouve des synonymes et remplace le terme de recherche pour récupérer le résultat final.
`SolrSearchTypeExpressionProvider`	`SearchTypeExpressionProvider`	Gère le type de correspondance pour les requêtes de recherche de mots clés, telles que Any et Exclude SKU.
`SolrSearchWebContentStoreInfoExpressionProvider`	`SearchWebContentStoreInfoExpressionProvider`	Gère l'ajout de conditions au contenu du site spécifique au magasin de recherche.

Mappez vos post-processeurs BOD aux post-processeurs REST en faisant référence au tableau suivant.


Préprocesseur de recherche basé sur BOD	Préprocesseur de recherche basé sur REST
`SolrSearchResultGroupingQueryPreprocessor`	`SearchResultGroupingQueryPreprocessor`
`SolrSearchDebugQueryPreprocessor`	`SearchDebugQueryPreprocessor`
`SolrSearchEDismaxQueryPreProcessor`	`SearchEDismaxQueryPreProcessor`
`SolrSearchFacetQueryPreprocessor`	`SearchFacetQueryPreprocessor`
`SolrSearchHighlighterQueryPreprocessor`	`SearchHighlighterQueryPreprocessor`
`SolrSearchMainQueryPreprocessor`	`SearchMainQueryPreprocessor`
`SolrSearchPaginationQueryPreprocessor`	`SearchPaginationQueryPreprocessor`
`SolrSearchPreviewQueryPreprocessor`	`SearchPreviewQueryPreprocessor`
`SolrSearchResultFieldQueryPreprocessor`	`SearchResultFieldQueryPreprocessor`
`SolrSearchSortingQueryPreprocessor`	`SearchSortingQueryPreprocessor`
`SolrSearchSpellCorrectionQueryPreprocessor`	`SearchSpellCorrectionQueryPreprocessor`

Remarque : Voici de nouveaux post-processeurs :

SearchCustomQueryPreprocessor
SearchJoinQueryPreprocessor
SearchManualSequenceOverrideQueryPreprocessor
SearchProductSequenceDebugInfoQueryPreprocessor
SearchRelevancyByProductGroupingQueryPreprocessor
SearchResponseFormatQueryPreprocessor

Mappez vos filtres de résultats et post-processeurs de recherche BOD aux les filtres de résultats et post-processeurs de recherche REST vous référant au tableau suivant.


Filtre de résultats de recherche basé sur BOD	Post-processeur de recherche basé sur REST
`SearchCatalogEntryMerchandisingAssocResultFilter`	`SearchCatalogEntryViewMerchandisingAssocQueryPostprocessor`
`SearchCatalogEntryViewAttachmentsResultFilter`	`SearchCatalogEntryViewAttachmentsQueryPostprocessor`
`SearchCatalogEntryViewAttributesAllowedValueResultFilter`	`SearchCatalogEntryViewAttributesQueryPostprocessor`
`SearchCatalogEntryViewAttributesResultFilter`	`SearchCatalogEntryViewAttributesQueryPostprocessor`
`SearchCatalogEntryViewDescriptionResultFilter`	`SearchCatalogEntryViewDescriptionQueryPostprocessor`
`SearchCatalogEntryViewPackageBundleResultFilter`	`SearchCatalogEntryViewComponentsQueryPostprocessor`
`SearchCatalogEntryViewPriceResultFilter`	`SearchCatalogEntryViewPriceQueryPostprocessor`
`SearchCatalogEntryViewSingleSKUResultFilter`	Logique rendue obsolète par l'indexation de la zone `childCatentry_id`.
`SearchCatalogEntryViewSKUResultFilter`	`SearchCatalogEntryViewSKUQueryPostprocessor`
`SearchCatalogEntryViewStoreDisplayAttributesResultFilter`	`SearchCatalogEntryViewAttributesQueryPostprocessor`
`SearchCatalogGroupEntitlementResultFilter`	`SearchCategoryEntitlementQueryPostprocessor`, `SearchChildCategoryEntitlementQueryPostprocessor`
`SearchCatalogNavigationViewDynamicKitResultFilter`	`SearchCatalogEntryViewDynamicKitQueryPostprocessor`
`SearchCatalogNavigationViewPreviewResultFilter`	`SearchPreviewQueryPostprocessor`
`SearchCatalogNavigationViewSEOTitleMetaDataFilter`	Le serveur de recherche ne renvoie pas les métadonnées de SEO. Les métadonnées sont renvoyées par le serveur WebSphere Commerce.
`SearchNavigationSuggestionsResultFilter`	`SearchCategorySuggestionQueryPostprocessor`, SearchBrandSuggestionQueryPostprocessor

Réappliquez vos personnalisations Solr.

HCL Commerce Version 9 utilise Solr 5.5.4. Toutes les personnalisations basées sur les versions précédentes de Solr doivent être mises en œuvre sur Solr 5.5.4.
Faites migrer tous les services de recherche personnalisés.
1. Créez un HCL Commerce Version 9 nœud final dans votre environnement de développement.
  1. Accédez au répertoire <WCDE_installdir>\workspace\search-ear.
  2. Copiez search-rest.war sur search-rest-ext.war.
  3. Importer le fichier WAR en cliquant avec le bouton droit sur le projet search-rest-ext.war, puis cliquez sur Propriétés > Paramètres de projet Web.
  4. Remplacez la racine de contexte par search/ext/resource.
  5. Ecrivez votre code Java et enregistrez-le dans le répertoire src sous le projet search-logic-ext.
  6. Enregistrez cette classe dans resources.properties dans le répertoire search-rest-ext/WebContent/WEB-INF/config.
    Remarque : Supprimez toutes les classes existantes du fichier de propriétés.
  7. Créez vos préprocesseurs et post-processeurs dans le répertoire src du projet search-logic-ext .
  8. Créez un profil de recherche à l'aide de préprocesseurs et de post-processeurs dans le fichier wc-search.xml, qui se trouve dans le répertoire /src/runtime/config/com.ibm.commerce.search .
  9. Associez le profil de recherche à la méthode correspondante du fichier wc-rest-resourceconfig.xml, qui se trouve dans le répertoire /src/runtime/config/com.ibm.commerce.rest de dossier.
2. Configurez WCB pour la fonction de recherche.
  1. Téléchargez le fichier WCBSamples.zip.
  2. Procédez à l'extraction du fichier zippé. Copiez WCBSamples/search/wcbd dans votre répertoire <WCDE_installdir>/wcbd. Copiez ensuite WCBSamples/search/Build_Local_Repository dans <WCDE_installdir>.
  3. Ouvrez le fichier build-local-search.properties et mettez à jour les propriétés suivantes avec les valeurs spécifiques à votre environnement.
```
wc.home=W:/WCDE_V9
was.home=W:/IBM/WebSphere/AppServer
web.module.list=search-rest-ext
```
  4. Ouvrez le fichier extract-local-search.properties et mettez à jour la propriété suivante avec la valeur spécifique à votre environnement.
```
local.extract.dir=W:/WCDE_V9/Build_Local_Repository/search
```
  5. Videz le contenu du répertoire <WCDE_installdir>\Build_Local_Repository\search\workspace.
  6. Copiez les dossiers search-config-ext, search-logic-ext et search-rest-ext dans le répertoire <WCDE_installdir>\Build_Local_Repository\search\workspace.
  7. Ouvrez une invite de commandes, accédez au répertoire <WCDE_installdir>\wcbd, puis exécutez la commande suivante.
```
wcbd-ant.bat -buildfile wcbd-build.xml -Dbuild.type=local -Dapp.type=search -Dbuild.label=demo
```
  8. Accédez au répertoire <WCDE_installdir>\wcbd\dist\server et vérifiez que votre package wcbd-deploy-server-local-search-demo.zip est créé. Vous extrayez ce paquet à l'étape suivante.
3. Préparez l'image Docker de recherche personnalisée. Cette étape suppose que vous utilisiez Docker Composer dans un environnement de création. Pour plus d'informations sur la création de cet environnement, voir Déploiement d'un environnement de création HCL Commerce version 9.0.0.0 à 9.0.1.17 avec Docker Compose.
  1. Créez un répertoire nommé cust pour héberger votre fichier docker-compose.yml. Ensuite, créez un répertoire cust/search pour héberger votre package personnalisé, le fichier application.xml et le fichier Docker.
  2. Extrayez votre wcbd-deploy-server-local-search-demo.zip dans le répertoire cust/search/CusDeploy, puis copiez le fichier <WCDE_installdir>\workspace\search-ear\META-INF\application.xml dans le répertoire cust/search.
  3. Dans le répertoire cust/search, créez un fichier Docker avec le contenu suivant.
```
FROM <Docker_registry>/commerce/search-app
COPY CusDeploy /SETUP/Cus
RUN /SETUP/bin/applyCustomization.sh
COPY CusDeploy/Code/search-app/search-rest-ext.war/profile/apps/search-ear.ear/search-rest-ext.war/ 
COPY application.xml /profile/apps/search-ear.ear/META-INF
```
4. Lancez l'environnement de composition Docker.
  1. Accédez au répertoire \cust, puis exécutez la commande suivante :
```
docker-compose up -d --build
```
  2. Une fois tous les services démarrés, générez votre index en exécutant la commande curl suivante :
```
curl -X POST -k -u spiuser:<password> https://localhost:5443/wcs/resources/admin/index/dataImport/build?masterCatalogId=10001
```
  3. Une fois l'index généré, accédez à l'URL suivante pour vérifier que le site fonctionne comme prévu :
```
https://localhost:3738/search/ext/resources/store/1/extproductview/byCategory/10001?currency='USD'&searchSource='O'&pageSize=2&pageNumber=1&langId=-1
```
Faites migrer votre cache de données.

Dans HCL Commerce Version 9, le cache de données est activé sur le serveur de recherche. Pour plus d'informations sur le cache de données, voir Activation de la surveillance du cache.
Faites migrer vos tâches planifiées personnalisées.
Dans HCL Commerce Version 9, un planificateur existe sur le serveur de recherche. Vous pouvez utiliser le tableau suivant pour recréer vos tâches de recherche planifiées.
- SRCH_SCHACTIVE
- SRCH_SCHBRDCST
- SRCH_SCHCONFIG
- SRCH_SCHERRLOG
- SRCH_SCHREPORT
- SRCH_SCHSTATUS

Que faire ensuite

La prochaine étape du processus de migration consiste à créer et à déployer vos conteneurs personnalisés. Une fois ces conteneurs déployés, vous pouvez créer votre index. Pour plus d'informations sur la génération de votre index, voir Génération de l'index HCL Commerce Search.