Migrating custom configuration files

Search-related configuration updates under the WebSphere Commerce EAR application extension directories can be moved into the corresponding extension directories under the WebSphere Commerce search EAR application. For example, the com.ibm.commerce.catalog-ext and com.ibm.commerce.foundation-ext directories.

Note: You must restart the WebSphere Commerce server after you change the search configuration files.

Procedure

Register custom search profiles by associating them to a REST service.
Note:
- Any custom search profiles that are defined in the WebSphere Commerce server must be redefined in the WebSphere Commerce Search server extension directory.
- Any custom search profiles that extend a default search profile in the WebSphere Commerce server must be updated. New default search profiles are introduced in the search server that contain different names or naming conventions.
- Any custom search profiles that use any of the default search query providers, processors, or search result filters must be updated. New alternatives are introduced in the search server that contain different names or use different naming conventions.
1. Locate the Search-Rest\WEB-INF\config\com.ibm.commerce.rest\wc-rest-resourceconfig.xml file.
2. Identify which REST service the custom search profile should be listed under.
3. Append your custom search profile to the end of the defined list of search profiles.
  
  For more information about the search profile mappings, see Mapping between WebSphere Commerce Search profiles.
  
  For more information about the search configuration properties in the wc-search.xml file, see WebSphere Commerce Search configuration file (wc-search.xml) (Search EAR).
Reapply custom configurations that are made in the wc-component.xml file.

Most of the search-related custom properties that are defined in the wc-component.xml file can be reused in the search server, except for the global price mode property. The price mode configuration is instead performed by using the STORECONF table.

For more information about the search configuration properties in the STORECONF table, see Search configuration properties in the STORECONF table.

For more information about the search configuration properties in the wc-component.xml file, see Search properties in the component configuration file (wc-component.xml) (Search EAR).
Reapply custom object mediators that are made in the wc-business-object-mediator.xml file.
The search server does not support business object mediators. Therefore, any customizations that are performed under the wc-business-object-mediator.xml file must be moved to the wc-component.xml file. For example, mappings between a userData custom field to an internal index field or database field must instead use the correct mappings under the wc-component.xml file.
The following example shows how an existing userData mapping under the WebSphere Commerce server wc-business-object-mediator.xml file can be moved into the search server custom wc-component.xml file:
```
<_config:mediator-property name="CatalogEntryView/UserData[(Name='SKU')]" value="partNumber_ntk" />
```
In the search server, the mapping between internal and external names is done using the valuemappingservice defined in the wc-component.xml file. There are different maps for CatalogEntry UserData and CatalogGroup UserData. The corresponding mapping in the search server wc-component.xml file can be achieved as:
```
<_config:valuemapping externalName="CatalogEntryUserDataFieldNameMapping" internalName="CatalogEntryUserDataFieldNameMapping">
   <_config:valuemap externalValue="SKU" internalValue="partNumber_ntk" />
</_config:valuemapping>
```
The following is the CatalogGroup UserData mapping service:
```
<_config:valuemapping externalName="CatalogGroupUserDataFieldNameMapping" internalName="CatalogGroupUserDataFieldNameMapping">
</_config:valuemapping>
```
Where the mappings are being populated by the following postprocessors:
```
<_config:postprocessor classname="com.ibm.commerce.foundation.server.services.rest.search.postprocessor.solr.SolrRESTSearchCatalogEntryViewUserDataQueryPostprocessor" />

<_config:postprocessor classname="com.ibm.commerce.foundation.server.services.rest.search.postprocessor.solr.SolrRESTSearchCatalogGroupViewUserDataQueryPostprocessor" />
```
Note: Ensure that the required postprocessors are included in the search profile you are using.

Reapply custom database query template (.tpl) files.

The search server supports DSL. However, it does not support EMFs, SDOs, and logical schemas. Therefore, any retrieved data from the database must be parsed by custom code and added into the main response as applicable. Any search-related custom queries can be reused in the search server. For more information, see Creating a custom query postprocessor.

The search server does not support any Query template tags. That is, each of the query parameters must be passed into the query services as query parameters. For schema parameters, create two versions of the query; one as the original query, and another where the table names are prefixed by the schema name. For example:


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

At run time, use the following helper method to get the schema name, and therefore call the correct query template:


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