Feature Pack 4Feature Pack 5Feature Pack 3Feature Pack 6

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

  1. 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.
  2. Introduced in Feature Pack 2Ensure that you complete the following tasks in your earlier version of WebSphere Commerce:
  3. Introduced in Feature Pack 3Ensure 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

During this task, you perform the following high-level steps:
  1. Prepare your environment for migration by installing the new feature pack version and running the foundation enablement script.
  2. If you are migrating from Feature Pack 2, 3, or 4, migrate facetable attributes.
  3. Run the automated search index setup migration utility on all existing master catalog IDs.
  4. Manually compare and copy customized WebSphere Commerce search configuration files into the new search version.
  5. Populate and build the full search index data.
  6. Update your storefront JSP files if you are migrating from Feature Pack 2 and do not have interim fix #1590 installed.
  7. 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).
  8. Reconfigure clustering and replication, if your previous search deployment is in a clustered environment.
During this task, you do not perform any steps to migrate the following areas, as they are automatically migrated:
  • Storefront features
  • Search rules

Procedure

  1. 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.
    • 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.
    Standard configuration:
    1. Install the new feature pack version that you want to use on the WebSphere Commerce server.
    2. Complete one of the following tasks:
      • SolarisLinuxAIXLog on as a WebSphere Commerce non-root user.
      • WindowsLog on with a user ID that is a member of the Windows Administration group.
    3. 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.
    4. WebSphere Commerce DeveloperEnsure that the test server is stopped and that Rational Application Developer is not running.
    5. Go to the following directory:
      • WC_installdir/bin
      • WebSphere Commerce DeveloperWCDE_installdir\bin
    6. Start the server1 instance:
      • SolarisLinuxAIX./startServer.sh server1
      • WindowsstartServer.bat server1
    7. Run the enablement script:
      For enabling WebSphere Commerce search:
      • Windowsconfig_ant.bat -buildfile WC_installdir/components/common/xml/enableFeature.xml -DinstanceName=instance_name -DfeatureName=foundation -DdbUserPassword=db_password [-DsolrHome=solrhome] Feature Pack 3[-DSolrWASAdminUser=solr_wasadminuser -DSolrWASAdminPassword=solr_wasadminpassword] Feature Pack 5[search_server_config]
      • SolarisLinuxAIX./config_ant.sh -buildfile WC_installdir/components/common/xml/enableFeature.xml -DinstanceName=instance_name -DfeatureName=foundation -DdbUserPassword=db_password [-DsolrHome=solrhome] Feature Pack 3[-DSolrWASAdminUser=solr_wasadminuser -DSolrWASAdminPassword=solr_wasadminpassword] Feature Pack 5[search_server_config]
      • For IBM i OS operating system./config_ant.sh -buildfile WC_installdir/components/common/xml/enableFeature.xml -DinstanceName=instance_name -DfeatureName=foundation -DdbUserPassword=db_password Introduced in Feature Pack 3[-DSolrWASAdminUser = solr_wasadminuser] [-DSolrWASAdminPassword = solr_wasadminpassword] Feature Pack 5[-Dscchost=HostForScheduledJobs] Feature Pack 5[search_server_config]
      • WebSphere Commerce DeveloperenableFeature.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:
      • WebSphere Commerce DeveloperWCDE_installdir/search/solr/home
      • SolarisLinuxAIXWindowsWC_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.
      When:
      • 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.
    8. Enable the starter store enhancements feature again.
    9. Restart the WebSphere Commerce application server.
    Advanced configuration:
    1. Install the new feature pack version that you want to use on the WebSphere Commerce server.
    2. Complete one of the following tasks:
      • SolarisLinuxAIXLog on as a WebSphere Commerce non-root user.
      • WindowsLog on with a user ID that is a member of the Windows Administration group.
    3. 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.
    4. WebSphere Commerce DeveloperEnsure that the test server is stopped and that Rational Application Developer is not running.
    5. Ensure that your WebSphere Commerce server is running.
    6. Go to the following directory:
      • WC_installdir/bin
      • WebSphere Commerce DeveloperWCDE_installdir\bin
    7. Run the enablement script for enabling WebSphere Commerce search:
      • Windowsconfig_ant.bat -buildfile WC_installdir/components/common/xml/enableFeature.xml -DinstanceName=instance_name -DfeatureName=foundation -DdbUserPassword=db_password -DremoteSearchEngine=true Feature Pack 5[search_server_config]
      • SolarisLinuxAIX./config_ant.sh -buildfile WC_installdir/components/common/xml/enableFeature.xml -DinstanceName=instance_name -DfeatureName=foundation -DdbUserPassword=db_password -DremoteSearchEngine=true Feature Pack 5[search_server_config]
      • For IBM i OS operating system./config_ant.sh -buildfile WC_installdir/components/common/xml/enableFeature.xml -DinstanceName=instance_name -DfeatureName=foundation -DdbUserPassword=db_password -DremoteSearchEngine=true Feature Pack 5[search_server_config]
      Where setting -DremoteSearchEngine=true indicates that the Advanced deployment option applies.

    8. Ensure that the script runs successfully. If the script runs successfully:
      • SolarisLinuxAIXWindowsThe message BUILD SUCCESSFUL is displayed in the console and in the WC_installdir/instances/instance_name/logs/enablefoundation_timestamp.log file.
    9. Enable the starter store enhancements feature again.
    10. Restart the WebSphere Commerce application server.
  2. Feature Pack 5 or later If you are migrating from Feature Pack 2, 3, or 4 to Feature Pack 5 or later, migrate facetable attributes.
    1. Go to the following directory:
      • WC_installdir/bin
      • WebSphere Commerce DeveloperWCDE_installdir\bin
    2. For attribute dictionary facetable attributes, run the search faceted attributes migration utility:
      • WebSphere Commerce DevelopermigrateSearchFacet.bat
      • WindowsmigrateSearchFacet.bat -instance instance_name -dbuser db_user -dbuserpwd db_password
      • SolarisLinuxAIXmigrateSearchFacet.sh -instance instance_name -dbuser db_user -dbuserpwd db_password
    3. For facetable attributes not in the attribute dictionary, manually migrate the faceted attributes:
      1. 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
        
      2. 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
        
      3. 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 to facet-classicAttribute:
        
        update srchattrprop set propertyname='facet-classicAttribute' where srchattr_id='SRCHATTR_ID'
        
        Where SRCHATTR_ID contains the matching row value. For example, 1030.
      4. 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.
      5. 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);
        
      6. Trigger a delta update or perform a full index update.
    4. 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);
      
  3. 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.
    1. Go to the following directory:
      • WC_installdir/components/foundation/subcomponents/search/bin
      • WebSphere Commerce DeveloperWCDE_installdir\components\foundation\subcomponents\search\bin
    2. 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

      DB2The name of the user that is connecting to the database.

      OracleThe user ID connecting to the database.

      dbuserpwd
      The password for the user that is connecting to the database.
      Feature Pack 5 or laterOracledbURL
      Feature Pack 5 or laterOracle1 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:
      • WebSphere Commerce DeveloperWCDE_installdir/search/solr/home
      • SolarisLinuxAIXWindowsWC_installdir/instances/instance_name/search/solr/home
      • For IBM i OS operating systemWC_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.
    3. For a local server:
      • WebSphere Commerce DevelopermigrateSolrSearch.bat -masterCatalogId masterCatalogId
      • WindowsmigrateSolrSearch.bat -instance instance_name -masterCatalogId masterCatalogId -dbuser db_user -dbuserpwd db_password [-searchServerName searchServerName] [-searchServerPort searchServerPort]
      • SolarisLinuxAIXmigrateSolrSearch.sh -instance instance_name -masterCatalogId masterCatalogId -dbuser db_user -dbuserpwd db_password [-searchServerName searchServerName] [-searchServerPort searchServerPort]
    4. 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
        Where working_dir is a location of your choice on your remote machine for where to copy the WebSphere Commerce search scripts.
        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:
      • WebSphere Commerce DevelopermigrateSolrSearch.bat -masterCatalogId masterCatalogId -action configWCforSolrMigration [-searchServerName searchServerName] [-searchServerPort searchServerPort] [-searchServiceContextRoot searchServiceContextRoot]
      • WindowsmigrateSolrSearch.bat -instance instance_name -masterCatalogId masterCatalogId -action configWCforSolrMigration -dbuser db_user -dbuserpwd db_password [-searchServerName searchServerName] [-searchServerPort searchServerPort] [-searchServiceContextRoot searchServiceContextRoot]
      • SolarisLinuxAIXmigrateSolrSearch.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:
      • WebSphere Commerce DevelopermigrateSolrSearch.bat -masterCatalogId masterCatalogId -action configSolrCoresMigration -solrhome solrhome -wasHomeWAS_home [-searchServerName searchServerName] [-searchServerPort searchServerPort
      • WindowsmigrateSolrSearch.bat -instance instance_name -masterCatalogId masterCatalogId -dbuser db_user -dbuserpwd db_password -action configSolrCoresMigration -solrhome solrhome -wasHomeWAS_home [-searchServerName searchServerName] [-searchServerPort searchServerPort
      • SolarisLinuxAIXmigrateSolrSearch.sh -instance instance_name -masterCatalogId masterCatalogId -dbuser db_user -dbuserpwd db_password -action configSolrCoresMigration -solrhome solrhome -wasHomeWAS_home [-searchServerName searchServerName] [-searchServerPort searchServerPort
    5. 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:
      • WebSphere Commerce DevelopermigrateSolrSearch.bat -masterCatalogId masterCatalogId
      • WindowsmigrateSolrSearch.bat -instance instance_name -masterCatalogId masterCatalogId -dbuser db_user -dbuserpwd db_password [-searchServerName searchServerName] [-searchServerPort searchServerPort]
      • SolarisLinuxAIXmigrateSolrSearch.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:
      1. Copy the following directory from your WebSphere Commerce machine:
        • WC_installdir/components/foundation/subcomponents/search
      2. To the following directory on your remote machine:
        • working_dir/search
        Where working_dir is a location of your choice on your remote machine for where to copy the WebSphere Commerce search scripts.
        Note: If you have a previous version of a working directory on your remote machine, you must delete its contents first before proceeding.
      3. 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
      4. Log on to the Solr server DMGR administrative console.
      5. Update the Solr application with the home.zip file.
      6. 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.
      7. Change the Solr.zip file name to Solr.war.
      8. Log on to the Solr server DMGR administrative console.
      9. Deploy the Solr.war file, replacing the old file. You must keep the previous server mappings and virtual host mappings.
      10. Browse to WebSphere enterprise applications > Solr_application_name > Context Root For Web Modules.
      11. Ensure that the value is /solr. If the value is different, update it to /solr and save your changes.
      12. Restart the WebSphere Commerce search cluster.
      On the WebSphere Commerce server:
      • WebSphere Commerce DevelopermigrateSolrSearch.bat -masterCatalogId masterCatalogId -action configWCforSolrMigration [-searchServerName searchServerName] [-searchServerPort searchServerPort] [-searchServiceContextRoot searchServiceContextRoot]
      • WindowsmigrateSolrSearch.bat -instance instance_name -masterCatalogId masterCatalogId -action configWCforSolrMigration -dbuser db_user -dbuserpwd db_password [-searchServerName searchServerName] [-searchServerPort searchServerPort] [-searchServiceContextRoot searchServiceContextRoot]
      • SolarisLinuxAIXmigrateSolrSearch.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:
      • WebSphere Commerce DevelopermigrateSolrSearch.bat -masterCatalogId masterCatalogId -action configSolrCoresMigration -solrhome solrhome -wasHomeWAS_home [-searchServerName searchServerName] [-searchServerPort searchServerPort
      • WindowsmigrateSolrSearch.bat -instance instance_name -masterCatalogId masterCatalogId -dbuser db_user -dbuserpwd db_password -action configSolrCoresMigration -solrhome solrhome -wasHomeWAS_home [-searchServerName searchServerName] [-searchServerPort searchServerPort
      • SolarisLinuxAIXmigrateSolrSearch.sh -instance instance_name -masterCatalogId masterCatalogId -dbuser db_user -dbuserpwd db_password -action configSolrCoresMigration -solrhome solrhome -wasHomeWAS_home [-searchServerName searchServerName] [-searchServerPort searchServerPort
    6. WebSphere Commerce DeveloperClean the test server.
      1. Start Rational Application Developer.
      2. Right-click the test server. Then, select Clean....
    7. 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:
      • WebSphere Commerce DeveloperWCDE_installdir\components\foundation\subcomponents\search\config\migrate-solr-search-logging.properties
      • SolarisLinuxAIXWindowsWC_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
  4. Compare and copy your customized search configuration files into the new search version.
    1. If you customized the WebSphere Commerce search preprocessor configuration files:
      1. Go to the following directory:
        • WC_installdir/instances/instance_name/search/pre-processConfig
        • WebSphere Commerce DeveloperWCDE_installdir\search\pre-processConfig
      2. Manually compare all the files in the MC_masterCatalogId.timestamp directory with the files in the MC_masterCatalogId directory.
      3. 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.
    2. If you customized the default WebSphere Commerce search Solr configuration files:
      1. Go to the following directory:
        • WC_installdir/instances/instance_name/search/solr/home/MC_masterCatalogId/locale_name/indextype
        • WebSphere Commerce DeveloperWCDE_installdir\search\solr\home\MC_masterCatalogId\locale_name\indextype
      2. 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.
      3. 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.
  5. 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.

    1. 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.
      Feature Pack 5 or laterIf 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:
      Feature Pack 5 or laterdbauser
      Feature Pack 5 or laterThe name of the DBA user. This parameter is required with the dbauserpwd parameter to create the workspace indexes.
      Feature Pack 5 or laterdbauserpwd
      Feature Pack 5 or laterThe password of the DBA user. This parameter is required with the dbauser parameter to create the workspace indexes.
    2. Complete the following task: Preprocessing the WebSphere Commerce search index data
      Important: You must preprocess both the CatalogEntry index and the CatalogGroup index. That is, ensure that the full-path parameter includes the CatalogEntry index.

      Including CatalogEntry index in the full-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.

    3. 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 the CatalogEntry index.

      If you do not use the indextype parameter, both the CatalogEntry and CatalogGroup indexes are built by default.

  6. Feature Pack 5 or laterUpdate 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.
    1. Open the following file:
      • For IBM i OS operating systemSolarisLinuxAIXWindowsWC_eardir/Stores.war/storedir/Snippets/ReusableObjects/SearchFacetsDisplay.jspf
      • WebSphere Commerce Developerworkspace_dir\Stores\Web Content\ storedir\Snippets\ReusableObjects\SearchFacetsDisplay.jspf
    2. Find all occurrences of the following snippet.
      
      parentCatgroup_id_facet
      
    3. Replace all occurrences with the following snippet:
      
      parentCatgroup_id_search
      
    4. 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>
      
    5. 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>
      
    6. Save your changes and close the file.
    7. Open the following file:
      • For IBM i OS operating systemSolarisLinuxAIXWindowsWC_eardir/Stores.war/storedir/Snippets/Search/SearchSetup.jspf
      • WebSphere Commerce Developerworkspace_dir\Stores\Web Content\ storedir\Snippets\Search\SearchSetup.jspf
    8. 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));
      
    9. 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")));
      
    10. Save your changes and close the file.
    11. Open the following file:
      • For IBM i OS operating systemSolarisLinuxAIXWindowsWC_eardir/Stores.war/storedir/include/BreadCrumbTrailDisplay.jsp
      • WebSphere Commerce Developerworkspace_dir\Stores\Web Content\ storedir\include\BreadCrumbTrailDisplay.jsp
    12. 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,'}','')}" />
      
    13. 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,'}','')}" />
      
    14. Save your changes and close the file.
    15. Restart your WebSphere Commerce server.
    16. Deploy the changes for the JSP files you updated. For more information, see Deploying J2EE assets for a single file.
  7. Set price ranges to index and display in starter stores:
  8. For a clustered search server:
    1. 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
    2. Reconfigure WebSphere Commerce search for replication.
    3. Restart your WebSphere Commerce search cluster and WebSphere Commerce cluster.

What to do next

After you complete the migration steps, publish a starter store and go to the storefront to confirm that WebSphere Commerce search is functioning correctly.
1 Feature Pack 5You must apply the interim fix for APAR #JR44514 to use this parameter.