To migrate from Feature Pack 2, 3,
4, 5, or 6 BOD-based search deployment to Feature Pack 7 or later
REST-based model follow this procedure.
Feature Pack 8 provides a significant upgrade to search architecture that was introduced in
Feature Pack 7. You are recommended to migrate to Feature Pack 8 from any earlier Feature Pack.
In Feature Pack 7, WebSphere Commerce search introduced the REST-based search runtime programming
model. The search runtime contains a new architecture, deployment strategy, and REST APIs to program
against the search server. This programming model and architecture was improved with Feature Pack
8.
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.
Important: If you need to continue to receive support for WebSphere Application Server,
you must upgrade to WebSphere Application Server to version 8.5.5 with Java 8. Earlier versions of
WebSphere Application Server are no longer supported. You can only update to use IBM SDK, Java
Technology Edition Version 8 if your existing WebSphere Commerce runtime instance is on WebSphere
Commerce version 7 Feature Pack 6, 7, or 8, and has Fix Pack 9 installed. For more information, see
Support for JDK 8, WebSphere Application Server V8.5.5.5, and Rational Application Developer V9.5.0.2
Before you begin
- Review the following WebSphere Commerce search topologies and
terminology differences between feature pack releases:
- Standard configuration (local deployment)
- The standard configuration mode creates and deploys a separate
search profile and Web module on the same machine as the WebSphere
Commerce profile.
- For more information about the standard configuration, see the Standard configuration
overview.
- Advanced configuration (federate and cluster)
- The advanced configuration allows you to federate and cluster
WebSphere Commerce search. First, in the standard configuration, it
creates and deploys a separate search profile and web module on the
same machine as the WebSphere Commerce profile. Then, federates them
across nodes by using the deployment manager (DMGR).
- For more information about the advanced configuration, see the Advanced configuration
overview.
- 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 lower version
of WebSphere Commerce:
- Deploying the WebSphere Commerce search server
- Setting up the search index
- Preprocessing the WebSphere Commerce search index data
- Building the WebSphere Commerce search index
- Ensure that you complete the following task in your later version
of WebSphere Commerce:
About this task
During this task, you perform the following high-level
steps:
- 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, depending on your feature pack
version.
- Secure the search server, if your previous version of WebSphere
Commerce search had security enabled.
- Set price ranges to index and display in starter stores by updating
search properties in the component configuration file (wc-component.xml).
- Reconfigure clustering and replication, if your previous search
deployment is in a clustered environment.
- Configure the JVM custom properties for the cluster members, so
that the Solr multi-index reader can read resources that are located
outside its instance.
During this task, you do not perform any steps to migrate
the following areas, as they are automatically migrated:
- Storefront features
- Search rules
Procedure
-
Prepare your environment for migration.
- Install the new feature pack version that you want to use on the WebSphere Commerce server.
- If you did not enable the foundation feature on your latest feature pack that is installed, then
enable foundation. Enabling foundation also enables WebSphere Commerce search. For more information,
see Enabling WebSphere Commerce foundation.
- If you did not enable the starter store enhancements feature on you latest feature pack that is
installed, then enable starter store enhancements. For more information, see Enable the starter
store enhancements feature.
- Restart the WebSphere Commerce application server.
- If you are migrating
from Feature Pack 2, 3, or 4, 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
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.
- 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.
- 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);
- 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
migrateSolrSearch.bat -masterCatalogId masterCatalogId
migrateSolrSearch.bat -instance instance_name -masterCatalogId masterCatalogId -dbuser db_user -dbuserpwd db_password [-searchServerName searchServerName]
[-searchServerPort searchServerPort] [-indexsubtype indexsubtype]
[-dbauser dbauser] [-dbauserpwd dbauserpwd]


migrateSolrSearch.sh -instance instance_name -masterCatalogId masterCatalogId -dbuser db_user -dbuserpwd db_password [-searchServerName searchServerName]
[-searchServerPort searchServerPort] [-indexsubtype indexsubtype]
[-dbauser dbauser] [-dbauserpwd dbauserpwd]
Where:
- 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.
- 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.
- indexsubtype
- Specify -indexsubtype Inventory if you
set up the inventory index in an earlier feature pack version.
- If specified, the migrateSolrSearch script
migrates the catalog entry, catalog group, unstructured, and inventory
indexes for the master catalog at the same time.
- If not specified, the migrateSolrSearch script
migrates the catalog entry, catalog group, and unstructured indexes
by default.
- dbauser
- The name of the DBA user. This parameter is required with the dbauserpwd parameter
if you set up workspaces in an earlier feature pack version.
- dbauserpwd
- The password of the DBA user. This parameter is required with
the dbauser parameter if you set up workspaces
in an earlier feature pack version.
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.
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 |
If you deployed the WebSphere Commerce search cluster,
ensure that the EAR changes are propagated to all the nodes.
- 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.
- 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.
- Populate and build the full search index data:
You
must perform these tasks, as extra parameters are required in Feature
Pack 7 or later, 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.
- 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.
- If you are migrating from Feature Pack 4 or lower, remove the
Solr data for every workspace, language, and master catalog. For example,
from the following locations:
- solrhome/MC_masterCatalogId/locale/CatalogGroup/data
- solrhome/MC_masterCatalogId/locale/CatalogEntry/data
- solrhome/MC_masterCatalogId/locale/CatalogEntry/unstructured/data
- 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.
If the index
build fails with multiple languages due to OutOfMemoryError
issues,
you must increase the search server heap size. For example, increase
it to 2 GB. For more information, see Troubleshooting: Out of memory error from building the search index with multiple languages.
- Update your storefront JSP files, depending on your feature
pack version.
- If you are migrating from Feature Pack 2, update your
storefront JSP files:
Note: This step is only required
if interim fix #1590 is not 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.
- If you are migrating from Feature Pack 6, update your
storefront JSP files to ensure that the advanced search feature works
correctly:
- Open the following file:




WC_eardir/Stores.war/storedir/Layouts/CategoryNavigationResults.jsp
workspace_dir\Stores\Web
Content\storedir\Layouts\CategoryNavigationResults.jsp
- Find the following snippet:
<c:when test="${!empty WCParam.searchTerm || !empty WCParam.manufacturer || !empty WCParam.facet || !empty WCParam.metaData}">
- Replace it with the following snippet:
<c:when test="${!empty WCParam.searchTerm || !empty WCParam.manufacturer || !empty WCParam.filterTerm || !empty WCParam.facet || !empty WCParam.metaData}">
- Save your changes and close the file.
- Open the following file:




WC_eardir/Stores.war/storedir/Layouts/SearchBasedCategoryPage.jsp
workspace_dir\Stores\Web
Content\storedir\Layouts\SearchBasedCategoryPage.jsp
- Find the following snippet:
<c:when test = "${empty WCParam.searchTerm && empty WCParam.manufacturer && empty WCParam.facet && empty WCParam.metaData}">
- Replace it with the following snippet:
<c:when test = "${empty WCParam.searchTerm && empty WCParam.manufacturer && empty WCParam.facet && empty WCParam.filterTerm && empty WCParam.metaData}">
- Save your changes and close the file.
- Deploy the changes for the JSP files you updated. For more information,
see Deploying J2EE assets for a single file.
- If you are migrating from Feature Pack 6 or lower, update
your storefront JSP files for Feature Pack 7 or later:
- Open the following file:
- Find the following snippet:
<%@ page import="org.apache.solr.client.solrj.impl.CommonsHttpSolrServer" %>
- Replace it with the following snippet:
<%@ page import="org.apache.solr.client.solrj.impl.HttpSolrServer" %>
- Find the following snippet:
if(solrServer instanceof CommonsHttpSolrServer ){
serverURL = ((CommonsHttpSolrServer )solrServer).getBaseURL();
- Replace it with the following snippet:
if(solrServer instanceof HttpSolrServer){
serverURL = ((HttpSolrServer)solrServer).getBaseURL();
- Save your changes and close the file.
- Deploy the changes for the JSP files you updated. For more information,
see Deploying J2EE assets for a single file.
- If your previous version of WebSphere Commerce search had
security enabled, complete the following task: Securing the WebSphere Commerce search server. This ensures that the WebSphere
Commerce search server is secured after migration.
- Set price ranges to index and display in starter stores:
- For a clustered
search server:
- Set up the search cluster again, based on the local
search server by completing the steps in Clustering WebSphere Commerce search. For example, when you
migrate from an Advanced search deployment that is federated and clustered
from a remote search server.
- Copy the WC_installdir/components/foundation/subcomponents/search/solr/home/replication-config.xml file
to WC_installdir/instances/instance_name/search/solr/home.
Then, edit the file to match your master machine and subordinate machine
configurations.
- 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.
Configure the JVM custom properties
for the cluster members.This step enables the solr.allow.unsafe.resourceloading flag,
which is required for the Solr multi-index reader to read resources
that are located outside its instance.
- Log on to the WebSphere Application Server administrative
console for the DMGR profile of the search cluster.
- Go to .
- Click the cluster that you created in this task.
- Under Additional Properties,
click cluster members. All the servers in the
current cluster are listed.
- Set the following JVM custom properties for each server:
- Click the server name.
- Under Server Infrastructure, go to .
- Under Additional Properties, click Java
Virtual Machine.
- Under Additional Properties, click Custom
Properties.
- Click New and set the following values:
Custom properties
Name |
Value |
solr.allow.unsafe.resourceloading |
true |
By default, the resource loader does not load files from external
servers for security reasons.
- Click Apply.
- Save your changes to the master configuration and ensure
that all nodes are synchronized.
What to do next
After you complete the migration steps, you can migrate WebSphere
Commerce search customization assets. Then, publish a starter
store and go to the storefront to confirm that WebSphere Commerce
search is functioning correctly.