Migración de archivos de configuración personalizados

Las actualizaciones de configuración relacionadas con la búsqueda bajo los directorios de extensión de aplicaciones EAR de HCL Commerce se pueden mover a los directorios de extensión correspondientes bajo la aplicación EAR Search de WebSphere Commerce. Por ejemplo, los directorios com.ibm.commerce.catalog-ext y com.ibm.commerce.foundation-ext.

Nota: Debe reiniciar el servidor de HCL Commerce después de cambiar los archivos de configuración de búsqueda.

Procedimiento

Registre los perfiles de búsqueda personalizados asociándolos a un servicio REST.
Nota:
- 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 HCL Commerce Search.
- 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.
1. Localice el archivo search-config-ext/src/runtime.config/com.ibm.commerce.rest/wc-rest-resourceconfig.xml-template.xml.
2. Identifique bajo qué servicio REST se debe listar el perfil de búsqueda personalizado.
3. Añada el perfil de búsqueda personalizado al final de la lista definida de perfiles de búsqueda.
  
  Para obtener más información sobre las propiedades de configuración de búsqueda en el archivo wc-search.xml, consulte HCL Commerce Search archivo de configuración (wc-search.xml).
Vuelva a aplicar las configuraciones personalizadas que se realizan en el archivo wc-component.xml.

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 En lugar de ello, la configuración de la modalidad de precio se realiza utilizando 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.

Para obtener más información sobre las propiedades de configuración de búsqueda en el archivo wc-component.xml, consulte Propiedades de búsqueda en el archivo de configuración de componente (wc-component.xml).
Vuelva a aplicar los mediadores de objetos personalizados que se realizan en el archivo wc-business-object-mediator.xml.
El servidor de búsqueda no soporta los mediadores de objetos de negocio. Por lo tanto, cualquier personalización que se realice en el archivo wc-business-object-mediator.xml debe moverse 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 en su lugar las correlaciones correctas en el archivo wc-component.xml.
El ejemplo siguiente muestra cómo una correlación userData existente bajo el archivo HCL Commerce del servidor de wc-business-object-mediator.xml se puede mover al archivo wc-component.xml personalizado del servidor de búsqueda:
```
<_config:mediator-property name="CatalogEntryView/UserData[(Name='SKU')]" value="partNumber_ntk" />
```
En el servidor de búsqueda, la correlación entre nombres internos y externos se realiza utilizando el valuemappingservice definido en el archivo wc-component.xml. Existen diferentes correlaciones para CatalogEntry UserData y CatalogGroup UserData. La correlación correspondiente en el archivo wc-component.xml del servidor de búsqueda puede lograrse como:
```
<_config:valuemapping externalName="CatalogEntryUserDataFieldNameMapping" internalName="CatalogEntryUserDataFieldNameMapping">
   <_config:valuemap externalValue="SKU" internalValue="partNumber_ntk" />
</_config:valuemapping>
```
A continuación se muestra el servicio de correlación de CatalogGroup UserData:
```
<_config:valuemapping externalName="CatalogGroupUserDataFieldNameMapping" internalName="CatalogGroupUserDataFieldNameMapping">
</_config:valuemapping>
```
Donde las correlaciones se están llenando mediante los siguientes postprocesadores:
```
<_config:postprocessor classname="com.ibm.commerce.search.internal.expression.postprocessor.SearchCatalogEntryViewUserDataQueryPostprocessor" />

<_config:postprocessor classname="com.ibm.commerce.search.internal.expression.postprocessor.SearchCatalogGroupViewUserDataQueryPostprocessor" /> 
```
Nota: Asegúrese de que el postprocesadores necesarios se incluyen en el perfil de búsqueda que está utilizando.
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 como 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. Es decir, cada uno de los parámetros de consulta se debe pasar a los servicios de consulta como parámetros de consulta. Para los parámetros de esquema, cree dos versiones de la consulta; una como la consulta original y otra donde los nombres de tabla llevan como prefijo el nombre de esquema. Por ejemplo:
```
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
```
En tiempo de ejecución, utilice el método de ayuda siguiente para obtener el nombre de esquema y, por lo tanto, llamar a la plantilla de consulta correcta:
```
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);
}
```