Migration des fichiers de configuration personnalisés

Les mises à jour de configuration liées à la recherche dans les répertoires d'extension d'application EAR HCL Commerce peuvent être déplacées dans les répertoires d'extension correspondants dans l'application EAR de recherche HCL Commerce. Par exemple, les répertoires com.ibm.commerce.catalog-ext et com.ibm.commerce.foundation-ext.

Remarque : Vous devez redémarrer le serveur HCL Commerce après avoir modifié les fichiers de configuration de recherche.

Procédure

  1. Enregistrez les profils de recherche personnalisés en les associant à un service REST.
    Remarque :
    • 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 HCL Commerce Search.
    • 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.
    1. Recherchez le fichier search-config-ext/src/runtime.config/com.ibm.commerce.rest/wc-rest-resourceconfig.xml-template.xml.
    2. Identifiez le service REST sous lequel le profil de recherche personnalisé doit être répertorié.
    3. Ajoutez votre profil de recherche personnalisé à la fin de la liste définie de profils de recherche.

      Pour plus d'informations sur les propriétés de configuration de recherche dans le fichier wc-search.xml, voir HCL Commerce Search fichier de configuration (wc-search.xml).

  2. Réappliquez les configurations personnalisées effectuées dans le fichier wc-component.xml.

    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 quant à elle effectuée à l'aide de 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.

    Pour plus d'informations sur les propriétés de configuration de recherche dans le fichier wc-component.xml, voir Propriétés de recherche dans le fichier de configuration de composant (wc-component.xml).

  3. Réappliquez les médiateurs d'objets personnalisés effectués dans le fichier wc-business-object-mediator.xml.

    Le serveur de recherche ne prend pas en charge les médiateurs d'objets métier. Par conséquent, toutes les personnalisations effectuées sous le 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 un champ d'index interne ou un champ de base de données doivent utiliser les mappages corrects sous le fichier wc-component.xml.

    L'exemple suivant montre comment un mappage userData existant sous le fichier HCL Commerce serveur wc-business-object-mediator.xml peut être déplacé dans le fichier personnalisé du serveur de recherche wc-component.xml :
    
    <_config:mediator-property name="CatalogEntryView/UserData[(Name='SKU')]" value="partNumber_ntk" />
    
    Dans le serveur de recherche, le mappage entre les noms internes et externes se fait à l'aide du valuemappingservice défini dans le fichier wc-component.xml. Il existe différentes cartes pour CatalogEntry UserData et CatalogGroup UserData. Le mappage correspondant dans le fichier serveur de recherche wc-component.xml peut être réalisé comme suit :
    
    <_config:valuemapping externalName="CatalogEntryUserDataFieldNameMapping" internalName="CatalogEntryUserDataFieldNameMapping">
       <_config:valuemap externalValue="SKU" internalValue="partNumber_ntk" />
    </_config:valuemapping>
    
    Voici le service de mappage CatalogGroup UserData :
    
    <_config:valuemapping externalName="CatalogGroupUserDataFieldNameMapping" internalName="CatalogGroupUserDataFieldNameMapping">
    </_config:valuemapping>
    
    Lorsque les mappages sont remplis par les post-processeurs suivants :
    
    <_config:postprocessor classname="com.ibm.commerce.search.internal.expression.postprocessor.SearchCatalogEntryViewUserDataQueryPostprocessor" />
    
    <_config:postprocessor classname="com.ibm.commerce.search.internal.expression.postprocessor.SearchCatalogGroupViewUserDataQueryPostprocessor" /> 
    Remarque : Assurez-vous que les post-processeurs requis sont inclus dans le profil de recherche que vous utilisez.
  4. 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. Autrement dit, chacun des paramètres de requête doit être transmis aux services de requête en tant que paramètre de requête. Pour les paramètres de schéma, créez deux versions de la requête ; l'une comme requête d'origine, et l'autre où les noms de table sont précédés par le nom du schéma. Par exemple :
    
    BEGIN_SQL_STATEMENT
    	name=X_GET_CUSTOM_FIELD_QUERY
    	base_table=tableName
    	sql=SELECT *
    	FROM tableName
    	WHERE CATALOG_ID=?catalogId? AND LANGUAGE_ID=?languageId? AND STOREENT_ID=?storeentId?
    END_SQL_STATEMENT
    
    BEGIN_SQL_STATEMENT
    	name=X_GET_CUSTOM_FIELD_QUERY_WORKSPACE
    base_table=tableName
    	sql=SELECT *
    	FROM $SCHEMA$.tableName
    	WHERE CATALOG_ID=?catalogId? AND LANGUAGE_ID=?languageId? AND STOREENT_ID=?storeentId?
    END_SQL_STATEMENT
    
    Au moment de l'exécution, utilisez la méthode auxiliaire suivante pour obtenir le nom du schéma et ainsi appeler le modèle de requête correct :
    
    queryParameters.put("languageId", Arrays.asList("-1"));
    queryParameters.put("catalogId", Arrays.asList("10001"));
    queryParameters.put("storeentId", Arrays.asList("10051"));
    
    String readSchema = SolrSearchConfigurationRegistry.getInstance(
    "com.ibm.commerce.catalog").getReadSchema();
    if (readSchema != null && readSchema.length() > 0) {
    queryParameters.put("$SCHEMA$",Arrays.asList(readSchema));
    results = service.executeQuery("X_GET_CUSTOM_FIELD_QUERY_WORKSPACE", queryParameters);
    } else {
    results = service.executeQuery("X_GET_CUSTOM_FIELD_QUERY", queryParameters);
    }