Migration de classes Java personnalisées de la recherche basée sur BOD vers la recherche basée sur REST

Vous pouvez faire migrer des classes Java personnalisées soit en les réutilisant le cas échéant, soit en les mettant à nouveau en œuvre d'une autre manière.

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.

Procédure

  1. Vous pouvez réutiliser vos fournisseurs d'expression personnalisés.

    Pour la recherche basée sur BOD, 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.

    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 les versions précédentes de HCL Commerce, 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.