Migrar la búsqueda basada en BOD de Feature Pack 6 IBM Websphere Commerce Version 7

Migre las configuraciones y el índice de HCL Commerce Search del Feature Pack 6 IBM Websphere Commerce Version 7 a HCL Commerce versión 9.0.0.3+.

HCL Commerce Version 9 utiliza Solr 5.5.4, de forma que los datos del índice de una versión anterior de Solr no son compatibles con Solr 5.5.4.

Revise la información siguiente para comprender qué arquitectura y funcionalidad de HCL Commerce Search han cambiado en HCL Commerce Version 9.

La búsqueda basada en BOD es discontinua en HCL Commerce Version 9.
El servidor de HCL Commerce Search tiene su propio contenedor en el entorno de producción. Despliegue el servidor de HCL Commerce Search como parte del conducto CI/CD.
El modelo de programación para HCL Commerce Search ha cambiado para coincidir con la nueva compilación y el proceso de despliegue en HCL Commerce Version 9. La base del nuevo modelo de programación es separar elementos de HCL Commerce Search personalizados del código de producto, que reduce el coste de recursos de mantenimiento y funcionamiento. Las personalizaciones de IBM Websphere Commerce Version 7 siguientes se deben actualizar para el nuevo modelo de programación:
- El tiempo de ejecución de Solr se actualiza a 5.5.4, de modo que las personalizaciones en Solr se deben actualizar para seguir el nuevo modelo de programación.
- Los programas de utilidad de HCL Commerce Search se sustituyen por el servicio del programa de utilidad del contenedor, que incluye di-preprocess, di-buildindex, di-calculateprice y indexprop. El programa de utilidad SetupSearchIndex se deja de mantener. El directorio principal del índice se sincroniza automáticamente con la tabla SRCHCONF y la tabla SRCHCONFEXT cuando se ha iniciado el servidor HCL Commerce Search. Esto le permite crear un nuevo núcleo maestro, núcleo de extensión o lenguaje para mantener las tablas SRCHCONF y SRCHCONFEXT. El núcleo del espacio de trabajo se crea automáticamente si el servidor de HCL Commerce Search detecta el esquema del espacio de trabajo en un entorno de creación.
- En HCL Commerce Version 9, la vista de la tabla se utiliza para realizar el preproceso y la creación del índice; por consiguiente, las personalizaciones en la creación del preproceso y del índice se deben reconfigurar según la nueva guía de programación.
- En HCL Commerce Version 9, el planificador común basado en la fundación está habilitado en el servidor HCL Commerce Search. Los entornos de creación utilizan el planificador para replicar el índice de los entornos de creación al repetidor de HCL Commerce Search.
- HCL Commerce Version 9 se ha movido a JAX-RS 2.0(JSR-339). Además, la API de la documentación es Swagger 2.0.
- IBM Websphere Commerce Version 7 utilizaba llamadas JDBC directas, que atravesaban DSL (data service layer) a la base de datos. En HCL Commerce Version 9, se utiliza la consulta nativa JPA 2.1 (EclipseLink). Las consultas personalizadas de versiones anteriores se transfieren al nuevo servicio de consulta. No se requiere ninguna configuración adicional.
- En HCL Commerce Version 9, cuando el precio o el inventario funcionan como núcleos ampliados, SolrJoin conserva la relación de documento entre el núcleo principal de CatalogEntry y el subnúcleo de precio e inventario. MultipleQueryComponent y MultipleFacetComponent, que se utilizaron para unir o filtrar los subnúcleos en IBM Websphere Commerce Version 7, ahora están inhabilitados de forma predeterminada. Para gestionar los campos de facetas y resultados de índices de extensión, un nuevo SearchCatalogEntryExtensionIndexPostprocessor realiza una subconsulta en cada uno de los índices, a continuación se une con el índice principal. También se ha introducido un nuevo parámetro de unión en wc-search.xml. Es necesario implementar cualquier personalización de IBM Websphere Commerce Version 7 en un índice de extensión para utilizar SolrJoin.
  Nota: Si es necesario, puede restaurar la funcionalidad anterior de MultipleQueryComponent y MultipleFacetComponent.

Antes de empezar

Descarte todas las tablas temporales y temporales personalizadas de su base de datos, excepto las siguientes tablas temporales:
- TI_DELTA_CATENTRY
- TI_DELTA_CATGROUP
- TI_DELTA_INVENTORY
Sus tablas temporales usan un prefijo TI_. Mientras que sus tablas temporales personalizadas usan un prefijo XI_.
Los cambios realizados en las tablas temporales entre las versiones anteriores de HCL Commerce y HCL Commerce Version 9. Si no se logran descartar las tablas temporales pueden producirse errores de preproceso, por ejemplo, SQLSTAE=56098. Para obtener más información sobre las tablas de búsqueda temporales HCL Commerce, consulte definición de esquema de tabla temporal.

Procedimiento

Migre los núcleos de índice personalizados. Los siguientes subpasos ilustran cómo migrar el núcleo ampliado xCatalogEntry para el catálogo maestro 10001 como ejemplo. Estos pasos deben repetirse para todos los núcleos de índice personalizados que desee migrar.
1. Registre el núcleo de índice personalizado ejecutando la siguiente sentencia SQL. Durante el inicio del servidor de búsqueda, el tiempo de ejecución de búsqueda crea automáticamente el núcleo registrado.
```
insert into srchconfext (srchconfext_id, indextype, indexscope, language_id, indexsubtype, config) values(srchconfext_id,’CatalogEntry’,10001,’xCatalogEntry’,NULL);
```
  Donde:
  
  SRCHCONFEXT_ID
  
  Clave primaria para la tabla.
  
  INDEXTYPE
  
  Indica el índice del motor de búsqueda para configurar. Los valores válidos para la columna son:
  
  CatalogEntry
  
  Configura el índice para entradas de catálogo en el catálogo maestro.
  
  CatalogGroup
  
  Configura el índice para categorías en el catálogo maestro.
  
  INDEXSCOPE
  
  El ámbito de los datos indexados. Por ejemplo, si el ámbito es el catálogo maestro, especifique aquí el ID del catálogo maestro.
  
  LANGUAGE_ID
  
  Indica qué idioma utilizar para el correspondiente subtipo de núcleo de índice de búsqueda. Para obtener una lista de los ID de idioma, consulte la columna LANGUGAE_ID en la tabla LANGUAGE.
  Nota: "LANGUAGE_ID" debe ser nulo para Inventario o Precio.
  
  INDEXSUBTYPE
  
  Indica qué subtipo está configurado para el núcleo del índice de búsqueda. Los valores válidos son:
  
  Structured
  
  Configura el índice para el contenido estructurado.
  
  Unstructured
  
  Configura el índice para el contenido no estructurado.
  
  WebContent
  
  Configura el índice para el contenido de sitio.
  
  Inventario
  
  Configura el índice para datos de inventario.
  
  Precio
  
  Configura el núcleo de índice externo para los datos de precio.
  
  CONFIG
  
  Indica configuraciones adicionales para el núcleo de índice de búsqueda especificado. Por ejemplo, puede establecer BasePath y StoreId para el núcleo del índice del subtipo WebContent. BasePath indica la vía de acceso del contenido del sitio rastreado e StoreId indica la tienda en la que se creará el índice. Separe las diferentes configuraciones con comas. Por ejemplo:
```
     BasePath=W:\IBM\WebSphere\Liberty\usr\servers\searchServer\resources\search\index\crawler\cache\2017-11-01\1\,StoreId=10501 
```
  Nota: Si el núcleo del índice personalizado es un núcleo maestro, como CatalogEntry o CatalogGroup, debe añadir registros a la tabla SRCHCONF. Si el núcleo de índice personalizado es un núcleo ampliado, como Inventory o Price, debe añadir registros a la tabla SRCHCONFEXT.
2. Cree el directorio siguiente.
  
  Liberty_installdir/usr/servers/default/resources/search/index/managed-solr/config/v3-core-extension
3. Cree un directorio denominado v3-core-extension en el directorio xCatalogEntry. A continuación, agregue los siguientes archivos de configuración central de Solr extendidos a la carpeta xCatalogEntry.
  - schema.xml
  - solrconfig.xml
  - wc-data-config.xml
4. Reinicie el servidor de búsqueda.
  El núcleo de índice personalizado se crea automáticamente durante el inicio y se puede encontrar en el directorio siguiente.
  Search_ServerDir/default/resources/search/index/managed-solr/config/v3-core-extension
Vuelva a implementar los campos de índice personalizados y los scripts de preproceso y de creación de índice.
1. Registre todos los núcleos de índice en la tabla SRCHCONF.
2. Migre las personalizaciones de esquema de índice. En HCL Commerce Version 9, las definiciones de fieldType de la entrada del catálogo usan dos plantillas:
  - Una plantilla no personalizable: search-config/src/main/resources/managed-solr/config/v3/common/schema-field-types.xml.
    Nota: Cuando se crea el primer índice, este archivo XML se copia en el directorio resources/search/index/managed-solr/config/v3/common. Tras la creación del índice, otros índices comparten esta definición .Tras la creación del índice, otros índices comparten esta definición fieldType.
  - Una plantilla personalizable: search-config-ext/src/main/resources/index/managed-solr/config/v3/common/x-schema-field-types.xml.
    Nota: Cuando se crea el primer índice, este archivo XML se copia en el directorio resources/search/index/managed-solr/config/v3-core-extension/common. Tras la creación del índice, otros índices comparten esta definición fieldType personalizable.
3. Migre el esquema personalizado fieldType mediante el ejemplo siguiente.
  Si ha creado un nuevo campo x_textSpell para el entorno local fr_FR en una versión HCL Commerce anterior, ha actualizado el archivo schema.xml, que se encontraba en el directorio de configuración núcleo específico del entorno local fr_FR. En HCL Commerce Version 9, debe agregar el tipo de campo x_textSpell_fr al archivo x-schema-field-types.xml de la siguiente manera.
```

<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. Después de que se haya definido el nuevo tipo de campo x_textSpell_fr en el archivo x-schema-field-types.xml, defina una entrada en el archivo x-schema.xml utilizando el ejemplo siguiente.
```
<field name="spellCheck" type="x_textSpell_fr" indexed="true" stored="false" multiValued="true" />
```
  Notes:
  - Si desea definir todos los idiomas de soporte, debe crear un tipo de campo para cada idioma en el archivo x-schema-field-types.xml y, a continuación, añadir la definición de campo siguiente en el archivo x-schema.xml.
    <field name="spellCheck" type="x_textSpell_${lang:en}" indexed="true" stored="false" multiValued="true" />
5. Migre sus palabras frecuentes personalizadas.
  En IBM Websphere Commerce Version 7, puede cambiar el archivo stopwords.txt para cada directorio de configuración de núcleo. Por ejemplo, si ha personalizado stopwords.txt para el idioma inglés, solo necesita cambiar el archivo stopwords.txt en el núcleo en_US. Al migrar a la versión HCL Commerce Version 9, los esquemas de índice se comparten en varios idiomas. Para personalizar stopwords.txt para un idioma específico, HCL Commerce Version 9 requiere que apunte al archivo en la tabla de la base de datos SRCHCONFEXT. Si desea más información sobre la personalización de stopwords.txt, consulte Personalización del archivo stopwords.txt. Ejecute el mandato SQL siguiente para poner stopwords.txt en los campos de configuración:
```
Update srchconfext set config='stopwords_en=../../../../managed-solr/config/v3-core-extension/common/stopwords.txt' 
where indextype=’CatalogEntry’ and indexscope=’$MASTERCATALOGID’
```
  Cuando se reinicia el servidor de búsqueda HCL Commerce, los siguientes contenidos se agregan en x-core.properties en el directorio de datos de índice en_US.
```
stopwords_en=../../../../managed-solr/config/v3-core-extension/common/stopwords.txt
```
  Si necesita cambiar el archivo stopwords.txt que está en el directorio workspace_dir\search-config-ext\src\index\managed-solr\config\v3\common, el nuevo stopwords.txt se copia en el directorio Liberty_installdir\resources\search\index\managed-solr\config\v3-core-extension\common como parte de la configuración de su ejecución secuencial de CI/CD y WCB.
  Por ejemplo, en IBM Websphere Commerce Version 7 ha añadido una nueva palabra frecuente en inglés: puede. Los siguientes pasos le muestran cómo migrar esta personalización.
  1. Agregue puede al final de su archivo HCL Commerce Version 9 workspace_dir\search-config-ext\src\index\managed-solr\config\v3\common\stopwords.txt.
  2. Agregue la ruta personalizada stopwords.txt en la columna CONFIG de la tabla SRCHCONFEXT ejecutando la siguiente sentencia SQL:
    Update srchconfext set config='stopwords_en=../../../../managed-solr/config/v3-core-extension/common/stopwords.txt' where indextype='CatalogEntry' and indexscope='10001';
6. Migre los archivos de preproceso personalizados.
  En IBM Websphere Commerce Version 7, cuando ha creado un archivo personalizado preprocess.xml para indexar datos externos, el archivo personalizado se encuentra en el directorio solrhome/pre-processConfig/MC_MasterCatalog/Dbtype. En HCL Commerce Version 9, dichos archivos XML de preproceso residen en el directorio WCDE_installdir/xml/search/dataImport/v3/Dbtype/.
  Copie el archivo wc-dataimport-preprocess-custom.xml del entorno IBM Websphere Commerce Version 7 en el directorio WCDE_installdir/xml/search/dataImport/v3/Dbtype/ en HCL Commerce Version 9. Además, copie los archivos a los que hace referencia el archivo wc-dataimport-preprocess-custom.xml en HCL Commerce Version 9 y actualice el archivo wc-dataimport-preprocess-custom.xml para asegurarse de que apunte al archivo de ruta correcto si cambia la ubicación del archivo en HCL Commerce Version 9. Por ejemplo, es posible que haya especificado un archivo de entrada en el modo wc-dataimport-preprocess-custom.xml siguiente.
```

<_config:property name="inputFile" value="W:\WCDE_INT70\bin\Ratings.xml"/>
```
  Si es así, debe copiar el archivo Ratings.xml de IBM Websphere Commerce Version 7 a HCL Commerce Version 9.0.0.1+ y colocarlo en la ubicación WCDE_installdir\bin y actualizar wc-dataimport-preprocess-custom.xml para que apunte a la nueva ubicación.
```

<_config:property name="inputFile" value="W:\WCDE_v9\bin\Ratings.xml"/>
```
7. Migre los archivos de manejador de importación de datos personalizados.
  Si desea indexar más datos en IBM Websphere Commerce Version 7, ha cambiado el archivo wc-data-config.xml en el directorio de núcleo específico. Por ejemplo, si desea indexar más datos de la tabla X_RATING en el idioma inglés, edite el archivo wc-data-config.xml en el directorio de núcleo en_US para permitir query y deltaImportQuery para unirse a la tabla X_RATING. En HCL Commerce Version 9, Solr DataImportHandler (DIH) obtiene datos de la vista VI_CE_#INDEX_SCOPE_TAG#_#lang_tag# y X_VI_CE_#INDEX_SCOPE_TAG#_#lang_tag#. Añada esta nueva tabla personalizada a la vista X_VI_CE_#INDEX_SCOPE_TAG#_#lang_tag# en wc-dataimport-preprocess-x-finalbuild.xml. Para obtener más información, consulte Configurar la correlación de Data Import Handler.
  
  Después de añadir las tablas personalizadas a la tabla X_VI_CE, DIH puede devolver y hacer accesible a Solr los datos personalizados. Defina la asignación de campo-columna para que Solr pueda transferir la nueva columna personalizada a los campos de Solr. Actualice el archivo search-config-ext/src/main/resources/index/managed-solr/config/v3/CatalogEntry/x-data-config.xml para agregar la asignación de campo.
  El siguiente es un ejemplo de la nueva asignación. Con esta correlación, la columna RATING de la vista X_VI_CE se correlaciona con el campo customerRanking en el índice de entrada de catálogo.
```
<field column="RATING" name="customerRanking"/>
```
8. Migre la tabla SRCHATTRPROP para habilitar las consultas de rango de precios.
  En HCL Commerce versión 8.0, la faceta de rango de precios predeterminado adopta el formato siguiente.
```
"price_USD:{* 100} 100;{100 200} 200;{200 300} 300;{300 400} 400;{400 500} 500;{500 *}"
```
  En Solr versión 7.3.1, este formato causa un error de sintaxis en el analizador de consultas. Si utiliza HCL Commerce versión 9.0.0.5+, cambie la cadena de consulta en el formato siguiente.
```
 "price_USD:{* TO 100];{100 TO 200];{200 TO 300];{300 TO 400];{400 TO 500];{500 TO *}" 
```
  Nota: Convierta los formatos de consulta de rangos anteriores que tienen la forma "({lower upper} upper)" en "({lower TO upper])". Migre cualquier otra personalización que implique pasar del formato de consulta antiguo al nuevo.
9. Migre los tipos de campo de esquema predeterminados.
  A partir de Solr versión 7.0.0, los campos de Trie*Field están en desuso. Sustitúyalos por *PointField. El valor predeterminado conserva los campos de tipo de datos antiguos (por ejemplo, int, tint, sint) y crea nuevos campos (por ejemplo, pint, pint). Aunque los campos antiguos siguen funcionando, para una compatibilidad futura, actualice el tipo de datos antiguo al nuevo. Se siguen utilizando algunos campos en desuso, por ejemplo, tipos de campo protegidos, para las consideraciones compatibles.
10. Migre los parámetros personalizados de solrconfig.xml.
  Para Solr versión 7.3.1, mueva el parámetro de configuración solr.mergeFactor en el archivo solrconfig.xml a la columna SRCHCONFEXT.CONFIG. Se sustituye por dos parámetros: solr.mergePolicy.maxMergeAtOnce y solr.mergePolicy.segmentsPerTier. Si ha establecido previamente el valor en algo parecido a <mergeFactor>5</mergeFactor>, sustitúyalo por solr.mergePolicy.maxMergeAtOnce=5,solr.mergePolicy.segmentsPerTier=5.
11. Reinicie el servidor de búsqueda.
12. Cree su índice de búsqueda.
Migre los archivos de configuración de búsqueda. Las actualizaciones de configuración que haya realizado en los directorios IBM Websphere Commerce Version 7 WC_eardir deben copiarse en los directorios de extensión correspondientes en el directorio Search_eardir en HCL Commerce Version 9. Los directorios de extensión son com.ibm.commerce.foundation-ext y com.ibm.commerce.search-ext.

Registre los perfiles de búsqueda personalizados asociándolos a un servicio REST.

Vaya al siguiente directorio.

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

Cree un archivo y asígnele el nombre wc-rest-resourceconfig.xml y, a continuación, añada el siguiente texto repetitivo de XML.

<?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>

Identifique bajo qué servicio REST se debe listar el perfil de búsqueda personalizado.
Añada el perfil de búsqueda personalizado al final de la lista definida de perfiles de búsqueda.
Guarde y cierre el archivo.

Vuelva a aplicar todas las configuraciones personalizadas al archivo wc-search.xml.
Notes:
- Suprima todas las configuraciones de conexión que pertenezcan a un servidor de Solr remoto. En el servidor de búsqueda de HCL Commerce Version 9, la conexión con Solr está incorporada.
- Puesto que los núcleos se leen ahora desde las tablas SRCHCONF y SRCHCONFEXT, elimine todos los núcleos registrados del archivo wc-search.xml.
- Los perfiles de búsqueda personalizados definidos en el servidor de HCL Commerce se deben volver a definir en el directorio de extensión de servidor de búsqueda de HCL Commerce.
- Se deben actualizar los perfiles de búsqueda personalizados que amplían un perfil de búsqueda predeterminado en el servidor de HCL Commerce. En el servidor de búsqueda, se han introducido perfiles de búsqueda predeterminados nuevos que contienen diferentes nombres o convenios de denominación.
- Se deben actualizar los perfiles de búsqueda personalizados que utilizan cualquiera de los proveedores de consulta de búsqueda, procesadores o filtros de resultados de búsqueda predeterminados. En el servidor de búsqueda se han introducido alternativas nuevas que contienen diferentes nombres o utilizan diferentes convenios de denominación.
Vuelva a aplicar las configuraciones personalizadas que haya realizado en los archivos wc-component.xml en los directorios com.ibm.commerce.foundation-ext y com.ibm.commerce.search-ext.

La mayoría de las propiedades personalizadas relacionadas con la búsqueda que se definen en el archivo wc-component.xml se pueden volver a utilizar en el servidor de búsqueda, excepto la propiedad de modalidad de precio global. La configuración del modo de precio ahora se almacena en la tabla STORECONF.  Para obtener más información sobre las propiedades de configuración de búsqueda en la tabla STORECONF, consulte Propiedades de configuración de búsqueda en la tabla STORECONF.

Migre los mediadores de objetos personalizados que haya realizado en el archivo IBM Websphere Commerce Version 7 wc-business-objectmediator.xml a HCL Commerce Version 9 wc-component.xml.

El servidor de búsqueda no soporta los mediadores de objetos de negocio. Por lo tanto, las personalizaciones que haya aplicado al archivo wc-business-object-mediator.xml deben trasladarse al archivo wc-component.xml.

Por ejemplo, las correlaciones entre un campo personalizado userData con un campo de índice interno o campo de base de datos debe utilizar ahora las correlaciones correctas en el archivo wc-component.xml. El ejemplo siguiente muestra cómo una correlación userData existente en el archivo wc-business-object-mediator.xml del servidor de HCL Commerce se puede mover al archivo wc-component.xml personalizado del servidor de búsqueda.

Abra su wc-business-object-mediator.xml y localice la línea de código siguiente:

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

Abra wc-component.xml de búsqueda y añada la correlación correspondiente.

En el servidor de búsqueda, la correlación entre nombres internos y externos se realiza utilizando la sección valuemappingservice del archivo wc-component.xml. Hay diferentes correlaciones para CatalogEntry - UserData y CatalogGroup - UserData.

Para la correlación CatalogEntry - UserData, añada el código siguiente al archivo wc-component.xml.

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

Para la correlación CatalogGroup - UserData , añada el código siguiente al archivo 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" />

Asegúrese de que los posprocesadores necesarios se incluyen en el perfil de búsqueda.

Vuelva a aplicar los archivos (TPL) de plantilla de consulta de base de datos personalizada.

El servidor de búsqueda soporta DSL. Sin embargo, no soportan los EMF, SDO y los esquemas lógicos. Por lo tanto, los datos recuperados de la base de datos se deben analizar por código personalizado y añadir a la respuesta principal donde sea aplicable. Las consultas personalizadas relacionadas con la búsqueda se pueden volver a utilizar en el servidor de búsqueda. Para obtener más información, consulte Crear un postprocesador de consulta personalizado.

El servidor de búsqueda no soporta ningún código de plantilla de consulta. Cada uno de los parámetros de consulta debe pasarse a los servicios de consulta como parámetros de consulta.
Para permitir que la consulta personalizada se ejecute bajo el esquema del espacio de trabajo, añada bull$SCHEMA$ a la tabla.

Si la consulta personalizada tiene una sintaxis de consulta diferente para Oracle, defina un nombre de consulta nuevo. En el código, utilice un nombre de consulta diferente después de determinar dbType, por ejemplo:

<!-- ======================================================================================= --> 
<!--  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

Todos los elementos personalizados que necesitan recuperar datos de la base de datos, deben utilizar SearchQueryService para leer datos, tal como se ve en el ejemplo de código siguiente:

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); 
  }

Migre los elementos Java personalizados.

Debido al uso de contenedorización, todas las personalizaciones deben ser creadas por el script WCB e implementadas por su canalización CI/CD. De forma predeterminada, los activos de configuración personalizados se pueden agregar en el directorio search-config-ext y los activos de Java personalizados se pueden agregar en el directorio search-logic-ext. A continuación, la secuencia de comandos WCB predeterminada y la canalización CI/CD pueden crear e implementar esos activos en el contenedor de búsqueda.
1. Puede reutilizar proveedores de expresión personalizados.
  
  Para los servicios basados en BOD de IBM Websphere Commerce Version 7, todos los proveedores de expresiones predeterminados se empaquetan bajo com.ibm.commerce.catalog.facade.server.services.search.expression.solr. Para HCL Commerce Version 9, todos los proveedores de expresiones se mueven al paquete com.ibm.commerce.search.internal.expression.provider. El patrón de nombres también se cambió. Por lo tanto, su proveedor de expresiones personalizado debe cambiarse para anular el nuevo proveedor de expresiones. La lógica principal debe seguir siendo compatible con la búsqueda de BOD.
2. Puede reutilizar preprocesadores de expresión personalizados.
  
  En IBM Websphere Commerce Version 7, los preprocesadores de consulta de búsqueda basados en BOD que funcionan en el objeto físico SolrQuery nativo heredado del siguiente padre AbstractSolrSearchQueryPreprocessor, empaquetado en com.ibm.commerce.foundation.internal.server.services.search.query.solr.
  
  En HCL Commerce Version 9 Search, el padre está empaquetado en com.ibm.commerce.search.internal.expression.preprocessor.
3. Vuelva a aplicar los posprocesadores de resultados de consultas personalizados.
  Si sus posprocesadores personalizados operan en la consulta nativa, pueden reutilizarse anulando el posprocesador relacionado. Sin embargo, si el postprocesador personalizado opera en la SolrCatalogNavigationViewImpl, no se puede reutilizar.
  De forma alternativa, cambie el código personalizado para que opere en el SearchResponse. Por ejemplo, el fragmento de código siguiente muestra cómo usar SearchResponse:
```
List<Map<String, Object>> catalogEntryViews = (LinkedList<Map<String, Object>>)iSearchResponseObject.getResponse().get("external object name");
```
  Donde el nombre de objeto es el nombre de objeto externo. Para obtener más información sobre la resolución de nombres externos, consulte los posprocesadores personalizado de ejemplo en el archivo wc-search.xml.
4. Reimplemente los filtros de resultado de consulta de búsqueda personalizados.
  
  Los filtros de resultados personalizados que operan en el nombre lógico CatalogNavigationViewType no son compatibles con el servidor de HCL Commerce Version 9 Search. Todos los filtros de resultados personalizados se deben reimplementar utilizando posprocesadores de consulta de búsqueda. Para obtener más información, consulte Crear un postprocesador de consulta personalizado.
5. Reimplemente sus mediadores de objetos de negocio.
  
  En IBM Websphere Commerce Version 7, los mediadores de objetos de negocio operan en el nombre lógico CatalogNavigationViewType. Ya no es compatible con el servidor de búsqueda. En su lugar, puede utilizar posprocesadores de consultas de búsqueda. Todos los mediadores personalizados que amplían la clase padre de AbstractReadBusinessObjectPartMediatorImpl se deben reimplementar utilizando posprocesadores de consulta de búsqueda.

Migre servicios de búsqueda de escaparate.

En IBM Websphere Commerce Version 7, la navegación de catálogo utilizaba getDataTag. En HCL Commerce Version 9, puede utilizar RESTTag equivalente basado en REST.

Las páginas de escaparate personalizado que utilizan los servicios BOD CatalogNavigationView deben actualizarse para utilizar los nuevos servicios REST correspondientes. Por ejemplo, el siguiente fragmento de código es un servicio de búsqueda de BOD getData que se utiliza para obtener productos por categoría:

<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}"/>

El siguiente fragmento de código es el servicio basado en REST equivalente:

<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}"/>

Los datos de respuesta se formatean en una respuesta de notación de puntos parecida a BOD a fin de minimizar los cambios que son necesarios en el escaparate. En algunos casos, la respuesta se simplifica y se aplana en parejas de nombre-valor más simples, en lugar de utilizar correlaciones internas para agrupar determinados campos.

Puede examinar la respuesta JSON imprimiendo el objeto de respuesta utilizando el código siguiente:

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

Correlacione los servicios de BOD con los servicios de REST.

Todos los servicios de búsqueda de BOD pueden ser cubiertos por servicios de búsqueda REST. Hay tres manejadores de búsqueda principales: CategoryViewHandler, ProductViewHandler y SiteContentHandler. Cada uno de ellos realiza una función de búsqueda diferente. Por ejemplo, ProductViewHandler puede buscar por Category, productId, ProductID, partNumber, partNumbers y searchTerm.

Utilice la tabla siguiente para ayudar a correlacionar los servicios de BOD con los servicios de REST.

Tabla para mostrar la correlación entre los servicios BOD y REST.
Servicio BOD	Creador de expresiones	Recurso REST	Servicio REST
CatalogNavigationView	getCatalogNavigationView	ProductViewHandler (Búsqueda)	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 (Búsqueda)	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 (Búsqueda)	store/{storeId}/sitecontent/webContentsBySearchTerm/{searchTerm}
			store/{storeId}/sitecontent/brandSuggestions
			store/{storeId}/sitecontent/categorySuggestions

Importe EnvironmentSetup.jspf en la página donde ha utilizado para llamar al servicio de BOD para seguir la guía de programación JSP. En este archivo JSPF, searchHostName y searchContextPath se definen, de modo que en el JSP donde desea llamar a REST de búsqueda, esta variable puede utilizarse directamente.
Utilizando la correlación entre BOD con la búsqueda REST, busque el servicio REST equivalente y, a continuación, cambie getDataTag a RESTtag.
Con la solicitud de BOD, la parte de la tienda podría utilizar el nombre CatalogNavigationViewType para recuperar el objeto necesario de la respuesta de la solicitud de BOD; este nombre básicamente representa una respuesta de negocio de una solicitud de examinación de catálogo.

Correlacione los perfiles de búsqueda de BOD para los perfiles de búsqueda de REST.

La tabla siguiente ilustra la correlación entre los perfiles de búsqueda que utilizan los servicios de CatalogNavigationViewBOD y los perfiles de búsqueda de REST correspondientes. Hay varios factores que diferencian los perfiles de búsqueda entre ellos. Al comparar los perfiles de búsqueda, tenga en cuenta los factores siguientes.

Campos de consulta: Controla el ámbito de búsqueda.
Campos de resultados: Controla los campos devueltos.
Proveedores de expresiones: Contribuye al objeto de criterios de selección.
Preprocesadores: Prepara el objeto de expresión de búsqueda final.
Postprocesadores: Media la respuesta de búsqueda y contribuye al objeto de respuesta final.

Correlación entre perfiles de búsqueda de BOD y REST.
Perfil de búsqueda de BOD	Perfil de búsqueda de REST
`IBM_ComposeProductListByCategoryId`	`IBM_findProductsByCategory`
`IBM_ComposeCategoryFacetListByCategoryId`	En desuso por `IBM_findProductsByCategory`
`IBM_BreadCrumb`	`IBM_BreadCrumbByCategoryUniqueId`
`IBM_findFacetsByCategory`	En desuso por `IBM_findProductsByCategory`
I`BM_ComposeFacetListByCategoryId`	`IBM_ComposeFacetListByCategoryId`
`IBM_findCatalogEntryWithoutDescriptionByNameAndShortDescription`	`IBM_findProductsBySearchTerm`
`IBM_findCatalogEntryWithoutDescriptionByNameAndShortDescriptionInDetail`	En desuso por `IBM_findProductsBySearchTerm`
`IBM_findCatalogGroupByFacet`	En desuso por `IBM_findProductsBySearchTerm`
`IBM_findCatalogEntryByName`	`IBM_findProductsByNameOnly`
`IBM_findCatalogEntryByUnstructureField`	`IBM_findProductsByUnstructureOnly`
`IBM_findCatalogEntryByNameAndShortDescriptionOnly`	`IBM_findProductsByNameAndShortDescriptionOnly`
`IBM_findCatalogEntryByNameAndShortDescription`	En desuso por `IBM_findProductsByNameAndShortDescriptionOnly`
`IBM_findCatalogEntryByNameAndShortDescriptionInDetail`	En desuso por `IBM_findProductsByNameAndShortDescriptionOnly`
`IBM_findCatalogEntryIdByNameAndShortDescription`	En desuso por `IBM_findProductsByNameAndShortDescriptionOnly`
`IBM_findCatalogEntryDetails`	`IBM_findProductByIds_Details`
`IBM_findCatalogEntryAll`	En desuso por `IBM_findProductByIds_Details`
`IBM_findCatalogEntryAll_PriceMode`	En desuso por `IBM_findProductByIds_Details`
`IBM_findCatalogEntrySKUs`	En desuso por `IBM_findProductByIds_Details`
`IBM_findCatalogEntryDetailsWithComponents`	En desuso por `IBM_findProductByIds_Details`
`IBM_findCatalogEntryDetailsWithComponentsAndAttachments`	En desuso por `IBM_findProductByIds_Details`
`IBM_findCatalogEntryDetailsWithMerchandisingAssocDetails`	En desuso por `IBM_findProductByIds_Details`
`IBM_findCatalogEntryDetails_PriceMode`	En desuso por `IBM_findProductByIds_Details`
`IBM_findComponentsSummary`	En desuso por `IBM_findProductByIds_Details`
`IBM_findComponentsSummaryDetails`	En desuso por `IBM_findProductByIds_Details`
`IBM_findCatalogEntryDetailsWithMerchandisingAssocSummary`	En desuso por `IBM_findProductByIds_Details`
`IBM_fetchRelatedCatalogEntryDetailedInfo`	En desuso por `IBM_findProductByIds_Details`
`IBM_findCatalogEntrySummary`	`IBM_findProductByIds_Summary`
`IBM_findCatalogEntryByID`	En desuso por `IBM_findProductByIds_Summary`
`IBM_findCatalogEntryPrice`	En desuso por `IBM_findProductByIds_Summary`
`IBM_findCatalogEntryDynamicKitSummary`	En desuso por `IBM_findProductByIds_Summary`
`IBM_fetchRelatedCatalogEntrySummaryInfo`	En desuso por `IBM_findProductByIds_Summary`
`IBM_CatalogEntryCategoryEntitlement`	En desuso por `IBM_findProductByIds_Summary`
`IBM_CatalogEntryEntitlement`	En desuso por `IBM_findProductByIds_Summary`
`IBM_findCatalogEntryPriceWithAttributes_PriceMode`	En desuso por `IBM_findProductByIds_Summary`
`IBM_findCatalogEntryAttachments`	`IBM_findProductByIdsWithAttributesAndAttachments`
`IBM_findCatalogEntryDetailsWithAttachments`	En desuso por `IBM_findProductByIdsWithAttributesAndAttachments`
`IBM_findCatalogEntryPriceWithAttributes`	En desuso por `IBM_findProductByIdsWithAttributesAndAttachments`
`IBM_findAttachmentByCatentryId`	En desuso por `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`	En desuso por `IBM_findWebContentsBySearchTerm`
`IBM_findNavigationSuggestion_Brands`	`IBM_findNavigationSuggestion_Brands`
`IBM_findNavigationSuggestion_Categories`	`IBM_findNavigationSuggestion_Categories`
`IBM_Global`	No hay ninguna coincidencia exacta para este perfil de búsqueda en el servidor de búsqueda de HCL Commerce Version 9. Tenga en cuenta los siguientes perfiles de búsqueda como sustituciones: `IBM_findProductsByCategory` (para navegación) `IBM_findProductsBySearchTerm` (para búsqueda de palabra clave) `IBM_findProductByIds_Details` (para página de visualización de producto)
`IBM_Global_Unstructured`	No hay ninguna coincidencia exacta para este perfil de búsqueda en el servidor de búsqueda. Tenga en cuenta los siguientes perfiles de búsqueda como sustituciones: `IBM_findWebContentsBySearchTerm` (para contenido web) `IBM_findProductsByUnstructureOnly`(para buscar adjuntos de producto)
`IBM_findNavigationSuggestions`	No hay ninguna coincidencia exacta para este perfil de búsqueda en el servidor de búsqueda. Tenga en cuenta los siguientes perfiles de búsqueda como sustituciones: `IBM_findNavigationSuggestion_Categories` (para sugerencias de categorías) `IBM_findNavigationSuggestion_Brands` (para sugerencias de marcas)

Correlacione los proveedores de expresiones de BOD para proveedores de expresiones de REST haciendo referencia a la tabla siguiente.


Proveedor de expresión de búsqueda basada en BOD	Proveedor de expresión de búsqueda basada en REST	Descripción:
`SolrSearchBasedMerchandisingExpressionProvider`	`SearchBasedMerchandisingExpressionProvider`	Llama al componente de marketing para ejecutar las reglas de búsqueda.
`SolrSearchByCatalogExpressionProvider`	`SearchByCatalogExpressionProvider`	Maneja la búsqueda por catálogo, teniendo en cuenta el catálogo de ventas en el contexto de negocio actual.
`SolrSearchByCategoryExpressionProvider`	`SearchByCategoryExpressionProvider`	Maneja la búsqueda por categoría, teniendo en cuenta el catálogo de ventas en el contexto de negocio actual.
`SolrSearchByCustomExpressionProvider`	`SearchByCustomExpressionProvider`	Incluye expresiones personalizadas que están almacenadas en `_wcf.search.expr`.
`SolrSearchByFacetExpressionProvider`	`SearchByFacetExpressionProvider`	Maneja la búsqueda por solicitudes de faceta.
`SolrSearchByKeywordExpressionProvider`	`SearchByKeywordExpressionProvider`	Maneja la búsqueda por solicitudes de palabra clave.
`SolrSearchByKeywordRelevancyExpressionProvider`	`SearchByKeywordRelevancyExpressionProvider`	Maneja la búsqueda por solicitudes de palabra clave que utilizan el analizador de consultas dismax.
`SolrSearchByManufacturerExpressionProvider`	`SearchByManufacturerExpressionProvider`	Maneja la búsqueda por solicitudes de nombre de marca.
`SolrSearchByPriceExpressionProvider`	`SearchByPriceExpressionProvider`	Maneja la búsqueda por solicitudes de rango de precios generadas desde la página Búsqueda avanzada.
`SolrSearchByPublishedEntryOnlyExpressionProvider`	`SearchByPublishedEntryOnlyExpressionProvider`	Genera condiciones para restringir los resultados de búsqueda solamente a las entradas publicadas.
`SolrSearchByStorePathExpressionProvider`	`SearchByStorePathExpressionProvider`	Genera condiciones para manejar la vía de acceso de tienda.
`SolrSearchCategoryEntitlementExpressionProvider`	`SearchCategoryEntitlementExpressionProvider`	Realiza la autorización de categoría.
`SolrSearchFacetConditionExpressionProvider`	`SearchFacetConditionExpressionProvider`	Genera una lista de facetas relacionadas con atributos y facetas de rango de precios específicos de moneda para la solicitud de búsqueda actual.
`SolrSearchInventoryExpressionProvider`	`SearchInventoryExpressionProvider`	Maneja la búsqueda relacionada con el índice de inventario.
`SolrSearchProductEntitlementExpressionProvider`	`SearchProductEntitlementExpressionProvider`	Realiza la autorización de producto.
`SolrSearchSequencingExpressionProvider`	`SearchProductSequencingExpressionProvider`	Organiza las entradas de productos en el resultado de búsqueda por rango.
`SolrSearchTermAssociationExpressionProvider`	`SearchTermAssociationExpressionProvider`	Obtiene sinónimos y sustituye el término de búsqueda para captar el resultado final.
`SolrSearchTypeExpressionProvider`	`SearchTypeExpressionProvider`	Maneja el tipo de coincidencia para solicitudes de búsqueda por palabra clave, como Cualquiera y Excluir SKU.
`SolrSearchWebContentStoreInfoExpressionProvider`	`SearchWebContentStoreInfoExpressionProvider`	Maneja la adición de condiciones para buscar contenido de sitio específico de tienda

Correlacione los posprocesadores de BOD para posprocesadores REST haciendo referencia a la tabla siguiente.


Preprocesador de búsqueda basada en BOD	Preprocesador de búsqueda basada en REST
`SolrSearchResultGroupingQueryPreprocessor`	`SearchResultGroupingQueryPreprocessor`
`SolrSearchDebugQueryPreprocessor`	`SearchDebugQueryPreprocessor`
`SolrSearchEDismaxQueryPreProcessor`	`SearchEDismaxQueryPreProcessor`
`SolrSearchFacetQueryPreprocessor`	`SearchFacetQueryPreprocessor`
`SolrSearchHighlighterQueryPreprocessor`	`SearchHighlighterQueryPreprocessor`
`SolrSearchMainQueryPreprocessor`	`SearchMainQueryPreprocessor`
`SolrSearchPaginationQueryPreprocessor`	`SearchPaginationQueryPreprocessor`
`SolrSearchPreviewQueryPreprocessor`	`SearchPreviewQueryPreprocessor`
`SolrSearchResultFieldQueryPreprocessor`	`SearchResultFieldQueryPreprocessor`
`SolrSearchSortingQueryPreprocessor`	`SearchSortingQueryPreprocessor`
`SolrSearchSpellCorrectionQueryPreprocessor`	`SearchSpellCorrectionQueryPreprocessor`

Nota: Los siguientes son posprocesadores nuevos:

SearchCustomQueryPreprocessor
SearchJoinQueryPreprocessor
SearchManualSequenceOverrideQueryPreprocessor
SearchProductSequenceDebugInfoQueryPreprocessor
SearchRelevancyByProductGroupingQueryPreprocessor
SearchResponseFormatQueryPreprocessor

Correlacione los posprocesadores y los filtros de resultados de búsqueda de BOD para posprocesadores y filtros de resultados de búsqueda de REST haciendo referencia a la tabla siguiente.


Filtro de resultados de búsqueda basados en BOD	Posprocesador de búsqueda basada en REST
`SearchCatalogEntryMerchandisingAssocResultFilter`	`SearchCatalogEntryViewMerchandisingAssocQueryPostprocessor`
`SearchCatalogEntryViewAttachmentsResultFilter`	`SearchCatalogEntryViewAttachmentsQueryPostprocessor`
`SearchCatalogEntryViewAttributesAllowedValueResultFilter`	`SearchCatalogEntryViewAttributesQueryPostprocessor`
`SearchCatalogEntryViewAttributesResultFilter`	`SearchCatalogEntryViewAttributesQueryPostprocessor`
`SearchCatalogEntryViewDescriptionResultFilter`	`SearchCatalogEntryViewDescriptionQueryPostprocessor`
`SearchCatalogEntryViewPackageBundleResultFilter`	`SearchCatalogEntryViewComponentsQueryPostprocessor`
`SearchCatalogEntryViewPriceResultFilter`	`SearchCatalogEntryViewPriceQueryPostprocessor`
`SearchCatalogEntryViewSingleSKUResultFilter`	La lógica que está en desuso mediante la indexación del campo `childCatentry_id`.
`SearchCatalogEntryViewSKUResultFilter`	`SearchCatalogEntryViewSKUQueryPostprocessor`
`SearchCatalogEntryViewStoreDisplayAttributesResultFilter`	`SearchCatalogEntryViewAttributesQueryPostprocessor`
`SearchCatalogGroupEntitlementResultFilter`	`SearchCategoryEntitlementQueryPostprocessor`, `SearchChildCategoryEntitlementQueryPostprocessor`
`SearchCatalogNavigationViewDynamicKitResultFilter`	`SearchCatalogEntryViewDynamicKitQueryPostprocessor`
`SearchCatalogNavigationViewPreviewResultFilter`	`SearchPreviewQueryPostprocessor`
`SearchCatalogNavigationViewSEOTitleMetaDataFilter`	El servidor de búsqueda no devuelve metadatos SEO. Se devuelven metadatos del servidor de WebSphere Commerce.
`SearchNavigationSuggestionsResultFilter`	`SearchCategorySuggestionQueryPostprocessor`, SearchBrandSuggestionQueryPostprocessor

Vuelva a aplicar sus personalizaciones de Solr.

HCL Commerce Version 9utiliza Solr 5.5.4. Toda la personalización basada en las versiones anteriores de Solr debe implementarse en Solr 5.5.4.
Migre los servicios de búsqueda personalizados.
1. Cree un punto final HCL Commerce Version 9 en su entorno de desarrollo.
  1. Vaya al directorio <WCDE_installdir>\workspace\search-ear.
  2. Copie search-rest.war en search-rest-ext.war.
  3. Importe el archivo WAR haciendo clic con el botón derecho en el proyecto search-rest-ext.war y, a continuación, en Propiedades > valores del Proyecto web.
  4. Cambie la raíz de contexto a search/ext/resource.
  5. Escriba su código Java y guárdelo en el directorio src en el proyecto search-logic-ext.
  6. Registre esa clase en resources.properties en el directorio search-rest-ext/WebContent/WEB-INF/config.
    Nota: Elimine cualquier clase existente del archivo de propiedades.
  7. Cree preprocesadores y posprocesadores en el directorio src del proyecto search-logic-ext .
  8. Cree un perfil de búsqueda utilizando preprocesadores y posprocesadores en el archivo wc-search.xml, que se encuentra en el directorio /src/runtime/config/com.ibm.commerce.search .
  9. Asocie el perfil de búsqueda con el método correspondiente en el archivo wc-rest-resourceconfig.xml, que se encuentra en el directorio /src/runtime/config/com.ibm.commerce.rest de la carpeta.
2. Configure WCB para Búsqueda.
  1. Descargar el archivoWCBSamples.zip
  2. Extraiga el archivo ZIP. Copie WCBSamples/search/wcbd en su directorio <WCDE_installdir>/wcbd. A continuación, copie WCBSamples/search/Build_Local_Repository en <WCDE_installdir>.
  3. Abra el archivo build-local-search.properties y actualice las siguientes propiedades con los valores específicos de su entorno.
```
wc.home=W:/WCDE_V9
was.home=W:/IBM/WebSphere/AppServer
web.module.list=search-rest-ext
```
  4. Abra el archivo extract-local-search.properties y actualice la siguiente propiedad con el valor específico de su entorno.
```
local.extract.dir=W:/WCDE_V9/Build_Local_Repository/search
```
  5. Borre el contenido del directorio <WCDE_installdir>\Build_Local_Repository\search\workspace.
  6. Copie las carpetas search-config-ext, search-logic-ext y search-rest-ext en el directorio <WCDE_installdir>\Build_Local_Repository\search\workspace.
  7. Abra un símbolo del sistema, vaya al directorio <WCDE_installdir>\wcbd y, a continuación, ejecute el siguiente mandato.
```
wcbd-ant.bat -buildfile wcbd-build.xml -Dbuild.type=local -Dapp.type=search -Dbuild.label=demo
```
  8. Vaya al directorio <WCDE_installdir>\wcbd\dist\server y verifique que su paquete wcbd-deploy-server-local-search-demo.zip esté creado. Extrae este paquete en el siguiente paso.
3. Prepare la imagen personalizada del Docker de búsqueda. Este paso supone que está utilizando Docker Compose en un entorno de creación. Para obtener más información sobre la creación de este entorno, consulte Implementación de un entorno de autoría HCL Commerce versión 9.0.0.0 a 9.0.1.17 mediante Docker Compose.
  1. Cree un directorio con el nombre cust para albergar su archivo docker-compose.yml. A continuación, cree un directorio cust/search para alojar su paquete personalizado, el archivo application.xml y archivo Docker.
  2. Extraiga su wcbd-deploy-server-local-search-demo.zip al directorio cust/search/CusDeploy y, a continuación, copie el archivo <WCDE_installdir>\workspace\search-ear\META-INF\application.xml al directorio cust/search.
  3. En el directorio cust/search, cree un archivo Docker con el siguiente contenido.
```
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. Inicie el entorno Docker-Compose.
  1. Vaya al directorio \cust para ejecutar el siguiente mandato:
```
docker-compose up -d --build
```
  2. Después de iniciar todos los servicios, cree su índice ejecutando el siguiente mandato curl:
```
curl -X POST -k -u spiuser:<password> https://localhost:5443/wcs/resources/admin/index/dataImport/build?masterCatalogId=10001
```
  3. Una vez creado el índice, navegue a la siguiente URL para verificar que el sitio funciona como se esperaba:
```
https://localhost:3738/search/ext/resources/store/1/extproductview/byCategory/10001?currency='USD'&searchSource='O'&pageSize=2&pageNumber=1&langId=-1
```
Migre la memoria caché de datos.

En HCL Commerce Version 9, la memoria caché de datos está habilitada en el servidor de búsqueda. Para obtener más información sobre la memoria caché de datos, consulte Habilitación del supervisor de memoria caché.
Migre los trabajos planificados personalizados.
En HCL Commerce Version 9, existe un planificador en el servidor de búsqueda. Puede utilizar la tabla siguiente para volver a crear los trabajos de búsqueda planificados.
- SRCH_SCHACTIVE
- SRCH_SCHBRDCST
- SRCH_SCHCONFIG
- SRCH_SCHERRLOG
- SRCH_SCHREPORT
- SRCH_SCHSTATUS

Qué hacer a continuación

El siguiente paso en el proceso de migración es crear y desplegar sus contenedores personalizados. Después de que se hayan desplegado estos contenedores, puede crear el índice. Para obtener más información sobre la creación del índice, consulte Creación del índice de HCL Commerce Search.