Migrating WebSphere Commerce search
To migrate from Feature Pack 2, 3, 4, or 5, BOD-based search deployment to Feature Pack 6 or earlier BOD-based search model follow this procedure.
When you migrate, WebSphere Commerce search updates the existing WebSphere Commerce search cores and configuration files to the latest version of WebSphere Commerce search. Your existing customizations are also considered during the migration steps to ensure that your latest version also contains your earlier changes to WebSphere Commerce search behavior.
Before you begin
- If you want to publish a new starter store, you must migrate the WebSphere Commerce search server first, and then publish the new starter store after feature enablement.
- Ensure that you complete the following tasks in your earlier version of WebSphere Commerce:
- Ensure that you complete the following tasks
in your later version of WebSphere Commerce, where:
- A previous version of WebSphere Commerce search is enabled from an earlier Feature Pack version, and
- WebSphere Application Server administrative security is enabled on the search server and Solr cell.
About this task
- Prepare your environment for migration by installing the new feature pack version and running the foundation enablement script.
- If you are migrating from Feature Pack 2, 3, or 4, migrate facetable attributes.
- Run the automated search index setup migration utility on all existing master catalog IDs.
- Manually compare and copy customized WebSphere Commerce search configuration files into the new search version.
- Populate and build the full search index data.
- Update your storefront JSP files if you are migrating from Feature Pack 2 and do not have interim fix #1590 installed.
- Set price ranges to index and display in starter stores by updating search properties in the search configuration file (wc-search.xml) and component configuration file (wc-component.xml).
- Reconfigure clustering and replication, if your previous search deployment is in a clustered environment.
- Storefront features
- Search rules
Procedure
- Your previous WebSphere Commerce search configuration affects
how you will migrate to a newer version. Review Deploying the search server to determine which configuration
was used to set up your WebSphere Commerce search implementation.
Standard configuration:
- Complete the steps that are outlined in Standard configuration if your previous WebSphere Commerce search deployment was set up as a standard deployment.
- Complete the steps that are outlined in Advanced configuration if your previous WebSphere Commerce search deployment was set up as an advanced deployment.
- Install the new feature pack version that you want to use on the WebSphere Commerce server.
- Complete one of the following tasks:
- Log on as a WebSphere Commerce non-root user.
- Log on with a user ID that is a member of the Windows Administration group.
- Ensure that your administrative server is started. For example:
- If WebSphere Commerce is managed by WebSphere Application Server Deployment Manager (dmgr), start the deployment manager and all node agents. Your cluster can also be started.
- If WebSphere Commerce is not managed by WebSphere Application Server Deployment Manager (dmgr), start the WebSphere Application Server server1.
- Ensure that the test server is stopped and that Rational Application Developer is not running.
- Go to the following directory:
- WC_installdir/bin
- WCDE_installdir\bin
- Start the server1 instance:
- ./startServer.sh server1
- startServer.bat server1
- Run the enablement script:For enabling WebSphere Commerce search:
- config_ant.bat -buildfile WC_installdir/components/common/xml/enableFeature.xml -DinstanceName=instance_name -DfeatureName=foundation -DdbUserPassword=db_password [-DsolrHome=solrhome] [-DSolrWASAdminUser=solr_wasadminuser -DSolrWASAdminPassword=solr_wasadminpassword] [search_server_config]
- ./config_ant.sh -buildfile WC_installdir/components/common/xml/enableFeature.xml -DinstanceName=instance_name -DfeatureName=foundation -DdbUserPassword=db_password [-DsolrHome=solrhome] [-DSolrWASAdminUser=solr_wasadminuser -DSolrWASAdminPassword=solr_wasadminpassword] [search_server_config]
- ./config_ant.sh -buildfile WC_installdir/components/common/xml/enableFeature.xml -DinstanceName=instance_name -DfeatureName=foundation -DdbUserPassword=db_password [-DSolrWASAdminUser = solr_wasadminuser] [-DSolrWASAdminPassword = solr_wasadminpassword] [-Dscchost=HostForScheduledJobs] [search_server_config]
- enableFeature.bat -DfeatureName=foundation [-DsolrHome=solrhome]
Where:- solrhome
- The location of the Solr home directory path that contains the index data of Solr. The value must be an absolute path.
- The default value is:
- WCDE_installdir/search/solr/home
- WC_installdir/instances/instance_name/search/solr/home
- solr_wasadminuser
- The WebSphere Application Server administrator user ID for the Solr cell.
- solr_wasadminpassword
- The WebSphere Application Server administrator password for the Solr cell.
- search_server_config
- Automates updating the web server configuration for IBM HTTP Server.
- For more information, see tsdsearchwebserver.html.
- A previous version of WebSphere Commerce search is enabled from an earlier Feature Pack version (for example, Feature Pack 2), and
- WebSphere Application Server administrative security is enabled on the search server and Solr cell, and
- When not specifying
remoteSearchEngine=true
.
- Enable the starter store enhancements feature again.
- Restart the WebSphere Commerce application server.
Advanced configuration:- Install the new feature pack version that you want to use on the WebSphere Commerce server.
- Complete one of the following tasks:
- Log on as a WebSphere Commerce non-root user.
- Log on with a user ID that is a member of the Windows Administration group.
- Ensure that your administrative server is started. For example:
- If WebSphere Commerce is managed by WebSphere Application Server Deployment Manager (dmgr), start the deployment manager and all node agents. Your cluster can also be started.
- If WebSphere Commerce is not managed by WebSphere Application Server Deployment Manager (dmgr), start the WebSphere Application Server server1.
- Ensure that the test server is stopped and that Rational Application Developer is not running.
- Ensure that your WebSphere Commerce server is running.
- Go to the following directory:
- WC_installdir/bin
- WCDE_installdir\bin
- Run the enablement script for enabling WebSphere Commerce search:
- config_ant.bat -buildfile WC_installdir/components/common/xml/enableFeature.xml -DinstanceName=instance_name -DfeatureName=foundation -DdbUserPassword=db_password -DremoteSearchEngine=true [search_server_config]
- ./config_ant.sh -buildfile WC_installdir/components/common/xml/enableFeature.xml -DinstanceName=instance_name -DfeatureName=foundation -DdbUserPassword=db_password -DremoteSearchEngine=true [search_server_config]
- ./config_ant.sh -buildfile WC_installdir/components/common/xml/enableFeature.xml -DinstanceName=instance_name -DfeatureName=foundation -DdbUserPassword=db_password -DremoteSearchEngine=true [search_server_config]
-DremoteSearchEngine=true
indicates that the Advanced deployment option applies. - Ensure that the script runs successfully. If the script runs successfully:
- The message BUILD SUCCESSFUL is displayed in the console and in the WC_installdir/instances/instance_name/logs/enablefoundation_timestamp.log file.
- Enable the starter store enhancements feature again.
- Restart the WebSphere Commerce application server.
-
If you are migrating from Feature Pack 2, 3, or 4 to Feature
Pack 5 or later, migrate facetable attributes.
- Go to the following directory:
- WC_installdir/bin
- WCDE_installdir\bin
- For attribute dictionary facetable attributes, run the
search faceted attributes migration utility:
- migrateSearchFacet.bat
- migrateSearchFacet.bat -instance instance_name -dbuser db_user -dbuserpwd db_password
- migrateSearchFacet.sh -instance instance_name -dbuser db_user -dbuserpwd db_password
- For facetable attributes not in the attribute dictionary,
manually migrate the faceted attributes:
- Run the following SQL query:
select distinct srchfieldname from clsattrsrchconf where attrname is not null;
Note the result for comparison. For example:SRCHFIELDNAME ------------------ CAS_F1
- Run the following SQL query:
select srchattr_id, propertyvalue, propertyname from srchattrprop where propertyname in ('facet', 'facet-classicAttribute') and propertyvalue not like 'price%'
Note the result for comparison. For example:SRCHATTR_ID |PROPERTYVALUE ------------------------------------------------------------------------------------------------------ -7000000000000000127 |ads_f10001_ntk_cs -7000000000000000125 |ads_f10501_ntk_cs -7000000000000000123 |ads_f11001_ntk_cs -1002 |mfName_ntk_cs -1039 |parentCatgroup_id_facet -1013 |parentCatgroup_id_search -2000 |xf_ads_f1_ntk_cs 1030 |cas_f1_ntk_cs
- Find and update the record that begins with the SQL select statement
result from Step 5.c.i. in the propertyvalue column
(case insensitive). For example, the SRCHATTR_ID with 1030 matches
the sample snippets.Set the propertyname value from
facet
tofacet-classicAttribute
:
Where SRCHATTR_ID contains the matching row value. For example, 1030.update srchattrprop set propertyname='facet-classicAttribute' where srchattr_id='SRCHATTR_ID'
- Insert a row for each of the classic attributes into the FACET table. Ensure that the facet_id does not conflict
with any existing values. For example:
insert into facet (facet_id, attr_id, srchattr_id, selection, sort_order, keyword_search, zero_display, storeent_id, max_display, sequence, field1, field2, field3, optcounter) values (-1039, null, 1030, 0, 0, 1, 0, 10901, 20, 0.0, null, null, null, 0)
Note: Ensure that your statement matches your environment. For example, by updating the correct storeent_id value. - Insert a row in the FACETDESC table for
the attributes. For example, if the attribute name is
Color
:insert into facetdesc values(-1039, -1, 'Color', 'classic attribute COLOR', null, null, null, 1);
- Trigger a delta update or perform a full index update.
- Run the following SQL query:
- To ensure that the migrated attributes display in the
storefront, set the FACETABLE column of the ATTR table to 1:
UPDATE ATTR SET FACETABLE = 1 WHERE ATTR_ID IN (list_of_facetable_attribute_ids);
- Go to the following directory:
- Run the search index setup migration utility:Important: If you have multiple master catalog IDs, for example, 10001 and 10002, you must migrate all of them separately. That is, if you migrate only 10001, but do not migrate 10002, Solr configuration errors occur when you build the search index.
- Go to the following directory:
- WC_installdir/components/foundation/subcomponents/search/bin
- WCDE_installdir\components\foundation\subcomponents\search\bin
- Run the search index setup migration utility, depending
on your environment and feature pack. For example, for a local server,
remote server, or clustered server.Where:
- action
- The migration action, depending on the machine that is running the utility.
- For example, configWCforSolrMigration when it is running on the WebSphere Commerce server, or configSolrCoresMigration when it is running on the remote search server.
- instance_name
- The name of the WebSphere Commerce instance with which you are working (for example, demo).
- masterCatalogId
- The ID of the master catalog (for example, 10101).
- If you do not know the master catalog ID, run the following SQL:
SQL: select * from catalog where IDENTIFIER='STORE_IDENTIFIER'
- dbuser
-
The name of the user that is connecting to the database.
The user ID connecting to the database.
- dbuserpwd
- The password for the user that is connecting to the database.
- dbURL
- 1 The database URL the utility uses to connect to the database. If not provided, the utility constructs a database URL based on the default database value.
- solrhome
- The location of the Solr home directory path that contains the index data of Solr. The value must be an absolute path.
- The default value is:
- WCDE_installdir/search/solr/home
- WC_installdir/instances/instance_name/search/solr/home
- WC_instance_root/instances/instance_name/search/solr/home
- wasHome
- The installation path for WebSphere Application Server.
- searchServerName
- The search server host name. Required if the search server host name was changed from the default name before migration.
- searchServerPort
- The search server port. Required if the search server port was changed from the default port before migration.
- searchServiceContextRoot
- The search service context root. For the Solr related actions such as configSolrCores and configWCforSolr, the default value is /solr.
- For a local server:
- migrateSolrSearch.bat -masterCatalogId masterCatalogId
- migrateSolrSearch.bat -instance instance_name -masterCatalogId masterCatalogId -dbuser db_user -dbuserpwd db_password [-searchServerName searchServerName] [-searchServerPort searchServerPort]
- migrateSolrSearch.sh -instance instance_name -masterCatalogId masterCatalogId -dbuser db_user -dbuserpwd db_password [-searchServerName searchServerName] [-searchServerPort searchServerPort]
- For a remote search server:Prepare your remote machine:
- If one exists, backup your existing working_dir/search directory by renaming it to working_dir/search.bak.
- Copy the following directory from your WebSphere Commerce machine:
- WC_installdir/components/foundation/subcomponents/search
- To the following directory on your remote machine:
- working_dir/search
Note: If you have a previous version of a working directory on your remote machine under working_dir/search, you must delete its contents first before proceeding. - Create a home.zip archive of all the files under the working_dir/search/solr/home directory (including the home directory). For example, home.zip/home/home_dir_files.
- Log on to the Solr server WebSphere Application Server administrative console.
- Update the Solr application with the home.zip file.
- Create a Solr.zip archive of all the files under the working_dir/search/solr/home/Solr.war archive (not including the Solr.war directory). For example, Solr.zip/Solr.war_files.
- Change the Solr.zip file name to Solr.war.
- Log on to the Solr server WebSphere Application Server administrative console.
- Deploy the Solr.war file, replacing the old file. You must keep the previous server mappings and virtual host mappings.
- Browse to WebSphere enterprise applications > Solr_application_name > Context Root For Web Modules.
- Ensure that the value is /solr. If the value is different, update it to /solr and save your changes.
- Restart the WebSphere Commerce search application server.
On the WebSphere Commerce server:- migrateSolrSearch.bat -masterCatalogId masterCatalogId -action configWCforSolrMigration [-searchServerName searchServerName] [-searchServerPort searchServerPort] [-searchServiceContextRoot searchServiceContextRoot]
- migrateSolrSearch.bat -instance instance_name -masterCatalogId masterCatalogId -action configWCforSolrMigration -dbuser db_user -dbuserpwd db_password [-searchServerName searchServerName] [-searchServerPort searchServerPort] [-searchServiceContextRoot searchServiceContextRoot]
- migrateSolrSearch.sh -instance instance_name -masterCatalogId masterCatalogId -action configWCforSolrMigration -dbuser db_user -dbuserpwd db_password [-searchServerName searchServerName] [-searchServerPort searchServerPort] [-searchServiceContextRoot searchServiceContextRoot]
On the remote search server, from working_dir\search\bin:- migrateSolrSearch.bat -masterCatalogId masterCatalogId -action configSolrCoresMigration -solrhome solrhome -wasHomeWAS_home [-searchServerName searchServerName] [-searchServerPort searchServerPort
- migrateSolrSearch.bat -instance instance_name -masterCatalogId masterCatalogId -dbuser db_user -dbuserpwd db_password -action configSolrCoresMigration -solrhome solrhome -wasHomeWAS_home [-searchServerName searchServerName] [-searchServerPort searchServerPort
- migrateSolrSearch.sh -instance instance_name -masterCatalogId masterCatalogId -dbuser db_user -dbuserpwd db_password -action configSolrCoresMigration -solrhome solrhome -wasHomeWAS_home [-searchServerName searchServerName] [-searchServerPort searchServerPort
- For a clustered search server:If your search cluster is federated from a local search server, run the local instructions for the search index setup migration utility:
- migrateSolrSearch.bat -masterCatalogId masterCatalogId
- migrateSolrSearch.bat -instance instance_name -masterCatalogId masterCatalogId -dbuser db_user -dbuserpwd db_password [-searchServerName searchServerName] [-searchServerPort searchServerPort]
- migrateSolrSearch.sh -instance instance_name -masterCatalogId masterCatalogId -dbuser db_user -dbuserpwd db_password [-searchServerName searchServerName] [-searchServerPort searchServerPort]
If your search cluster is federated from a remote search server, run the remote instructions for the search index setup migration utility:
Prepare your remote machine:- Copy the following directory from your WebSphere Commerce machine:
- WC_installdir/components/foundation/subcomponents/search
- To the following directory on your remote machine:
- working_dir/search
Note: If you have a previous version of a working directory on your remote machine, you must delete its contents first before proceeding. - Create a home.zip archive of all the files under the working_dir/search/solr/home directory (including the home directory). For example, home.zip/home/home_dir_files.01
- Log on to the Solr server DMGR administrative console.
- Update the Solr application with the home.zip file.
- Create a Solr.zip archive of all the files under the working_dir/search/solr/home/Solr.war archive (not including the Solr.war directory). For example, Solr.zip/Solr.war_files.
- Change the Solr.zip file name to Solr.war.
- Log on to the Solr server DMGR administrative console.
- Deploy the Solr.war file, replacing the old file. You must keep the previous server mappings and virtual host mappings.
- Browse to WebSphere enterprise applications > Solr_application_name > Context Root For Web Modules.
- Ensure that the value is /solr. If the value is different, update it to /solr and save your changes.
- Restart the WebSphere Commerce search cluster.
On the WebSphere Commerce server:- migrateSolrSearch.bat -masterCatalogId masterCatalogId -action configWCforSolrMigration [-searchServerName searchServerName] [-searchServerPort searchServerPort] [-searchServiceContextRoot searchServiceContextRoot]
- migrateSolrSearch.bat -instance instance_name -masterCatalogId masterCatalogId -action configWCforSolrMigration -dbuser db_user -dbuserpwd db_password [-searchServerName searchServerName] [-searchServerPort searchServerPort] [-searchServiceContextRoot searchServiceContextRoot]
- migrateSolrSearch.sh -instance instance_name -masterCatalogId masterCatalogId -action configWCforSolrMigration -dbuser db_user -dbuserpwd db_password [-searchServerName searchServerName] [-searchServerPort searchServerPort] [-searchServiceContextRoot searchServiceContextRoot]
On the remote search server, from working_dir\search\bin:- migrateSolrSearch.bat -masterCatalogId masterCatalogId -action configSolrCoresMigration -solrhome solrhome -wasHomeWAS_home [-searchServerName searchServerName] [-searchServerPort searchServerPort
- migrateSolrSearch.bat -instance instance_name -masterCatalogId masterCatalogId -dbuser db_user -dbuserpwd db_password -action configSolrCoresMigration -solrhome solrhome -wasHomeWAS_home [-searchServerName searchServerName] [-searchServerPort searchServerPort
- migrateSolrSearch.sh -instance instance_name -masterCatalogId masterCatalogId -dbuser db_user -dbuserpwd db_password -action configSolrCoresMigration -solrhome solrhome -wasHomeWAS_home [-searchServerName searchServerName] [-searchServerPort searchServerPort
- Clean the test server.
- Start Rational Application Developer.
- Right-click the test server. Then, select Clean....
- Ensure that the utility runs successfully by reviewing
the log file to see the results of the migration. The log file is
located is the location that is specified in the migrate-solr-search-logging.properties file.
By default, you can find the log at the following location:
- WCDE_installdir\components\foundation\subcomponents\search\config\migrate-solr-search-logging.properties
- WC_installdir\components\foundation\subcomponents\search\config\migrate-solr-search-logging.properties
If the utility did not run successfully, you can modify the logging configuration file as needed, specifically the logging level:Logging configuration file parameters Parameter Value Logging level - INFO
- The typical logging level to use for the utility. This level also lists all SQL statements that you can use to roll back the migration.
- FINEST
- This level lists all details as the utility runs. Use this level if you encounter errors or exceptions during the migration and you need additional information for troubleshooting.
Log file location java.util.logging.FileHandler.pattern=../log/migrate-solr-search-logging.log
- Go to the following directory:
- Compare and copy your customized search configuration files
into the new search version.
- If you customized the WebSphere Commerce search preprocessor
configuration files:
- Go to the following directory:
- WC_installdir/instances/instance_name/search/pre-processConfig
- WCDE_installdir\search\pre-processConfig
- Manually compare all the files in the MC_masterCatalogId.timestamp directory with the files in the MC_masterCatalogId directory.
- Identify all the changed files, and merge the specific Feature Pack 7 changes from the MC_masterCatalogId.timestamp directory to the files with the same names in the MC_masterCatalogId directory.
- Go to the following directory:
- If you customized the default WebSphere Commerce search
Solr configuration files:
- Go to the following directory:
- WC_installdir/instances/instance_name/search/solr/home/MC_masterCatalogId/locale_name/indextype
- WCDE_installdir\search\solr\home\MC_masterCatalogId\locale_name\indextype
- For each core, manually compare the solrconfig.xml, wc-data-config.xml, and schema.xml files in the conf.timestamp directory with the files in the conf directory.
- Identify all the changed files, and merge the specific previous Feature Pack changes from the conf.timestamp directory to the files with the same names in the conf directory.
- Go to the following directory:
- If you customized the WebSphere Commerce search preprocessor
configuration files:
- Populate and build the full search index data:
You must perform these tasks, as extra parameters are required in later feature packs, when a previous version of WebSphere Commerce search is enabled from an earlier Feature Pack version.
- If you are migrating from Feature Pack 2, complete the following
tasks, specifying the indextype as CatalogGroup when
you run the search index setup utility.Setting up the search index, either:If you have enabled workspaces and activate a task group and tasks, you must include the following parameters to create the workspace-related workspace tables and search configuration files:
- dbauser
- The name of the DBA user. This parameter is required with the dbauserpwd parameter to create the workspace indexes.
- dbauserpwd
- The password of the DBA user. This parameter is required with the dbauser parameter to create the workspace indexes.
- Complete the following task: Preprocessing the WebSphere Commerce search index dataImportant: You must preprocess both the CatalogEntry index and the CatalogGroup index. That is, ensure that the
full-path
parameter includes theCatalogEntry
index.Including
CatalogEntry
index in thefull-path
parameter processes the configuration files for both CatalogEntry and CatalogGroup by default.The directory that contains the configuration files for CatalogGroup is one level below the directory for CatalogEntry.
- Restart the WebSphere Commerce search server, then complete the
following task: Building the WebSphere Commerce search index.Important: You must build the catalog entry index when indexing WebSphere Commerce search. That is, at a minimum, the catalog entry index must be rebuilt when migrating WebSphere Commerce search. That is, ensure that the
indextype
parameter includes theCatalogEntry
index.If you do not use the
indextype
parameter, both theCatalogEntry
andCatalogGroup
indexes are built by default.
- If you are migrating from Feature Pack 2, complete the following
tasks, specifying the indextype as CatalogGroup when
you run the search index setup utility.
- Update your storefront JSP files:
Note: This step is only required if you are migrating from Feature Pack 2 to Feature Pack 5 or later, and you do not have interim fix #1590 installed.
- Open the following file:
- WC_eardir/Stores.war/storedir/Snippets/ReusableObjects/SearchFacetsDisplay.jspf
- workspace_dir\Stores\Web Content\ storedir\Snippets\ReusableObjects\SearchFacetsDisplay.jspf
- Find all occurrences of the following snippet.
parentCatgroup_id_facet
- Replace all occurrences with the following snippet:
parentCatgroup_id_search
- Find the following snippet:
<c:if test="${totalCount > 1}"> <c:forEach var="facetField" items="${globalfacets}"> <c:if test="${facetField.value eq 'parentCatgroup_id_search'}"> <c:if test="${fn:length(facetField.entry) > 1}"> <%@ include file="../../Snippets/Search/CategoryFacetDisplay.jspf" %> <c:set var="f" value="${f + 1}" /> </c:if> </c:if> </c:forEach>
- Replace it with the following snippet:
<c:if test="${totalCount > 0}"> <c:forEach var="facetField" items="${globalfacets}"> <c:if test="${facetField.value eq 'parentCatgroup_id_search'}"> <c:if test="${fn:length(facetField.entry) > 0}"> <%@ include file="../../Snippets/Search/CategoryFacetDisplay.jspf" %> <c:set var="f" value="${f + 1}" /> </c:if> </c:if> </c:forEach>
- Save your changes and close the file.
- Open the following file:
- WC_eardir/Stores.war/storedir/Snippets/Search/SearchSetup.jspf
- workspace_dir\Stores\Web Content\ storedir\Snippets\Search\SearchSetup.jspf
- Find the following snippet:
request.setAttribute("handledSearchTerm" ,SpecialCharacterHelper .getHandledString(searchTerm, false)); request.setAttribute("handledFilterTerm" ,SpecialCharacterHelper .getHandledString(wcp.get("filterTerm"), false)); request.setAttribute("handledManufacturer" ,SpecialCharacterHelper .getHandledString(wcp.get("manufacturer"), false));
- Replace it with the following snippet:
request.setAttribute("handledSearchTerm" ,SpecialCharacterHelper .escapeDollar(searchTerm)); request.setAttribute("handledFilterTerm" ,SpecialCharacterHelper .escapeDollar(wcp.get("filterTerm"))); request.setAttribute("handledManufacturer" ,SpecialCharacterHelper .escapeDollar(wcp.get("manufacturer")));
- Save your changes and close the file.
- Open the following file:
- WC_eardir/Stores.war/storedir/include/BreadCrumbTrailDisplay.jsp
- workspace_dir\Stores\Web Content\ storedir\include\BreadCrumbTrailDisplay.jsp
- Find the following snippet:
<c:if test="${fn:startsWith(breadcrumbLabel, '({')}"> <c:set var="rangeLabel" value="${fn:replace(breadcrumbLabel,'({','')}" /> <c:set var="rangeLabel" value="${fn:replace(rangeLabel,'})','')}" /> <c:set var="rangeLabel" value="${fn:replace(rangeLabel,'}','')}" />
- Replace it with the following snippet:
<c:if test="${fn:startsWith(breadcrumbLabel, '{')}"> <c:set var="rangeLabel" value="${fn:replace(breadcrumbLabel,'{','')}" /> <c:set var="rangeLabel" value="${fn:replace(rangeLabel,'}','')}" />
- Save your changes and close the file.
- Restart your WebSphere Commerce server.
- Deploy the changes for the JSP files you updated. For more information, see Deploying J2EE assets for a single file.
- Open the following file:
- Set price ranges to index and display in starter stores:
- Set the query property for price to mixed mode (2) in the wc-search.xml file. For more information, see WebSphere Commerce search configuration file (wc-search.xml) (WC EAR).
- Set the Search profiles global defaults property for SearchProfilesPrice to mixed mode (2) in the wc-component.xml file. For more information, see Search properties in the component configuration file (wc-component.xml) (WebSphere Commerce EAR).
- For a clustered search server:
- Manually copy the Solr home directory from the first
WebSphere Commerce search application server that is running the search
index setup migration utility to all clustered servers. The default
Solr home is in the following location:
- working_dir/search/instance_name/search/solr/home
- Reconfigure WebSphere Commerce search for replication.
- Restart your WebSphere Commerce search cluster and WebSphere Commerce cluster.
- Manually copy the Solr home directory from the first
WebSphere Commerce search application server that is running the search
index setup migration utility to all clustered servers. The default
Solr home is in the following location: