Migrating IBM Websphere Commerce Version 7 Feature Pack 7 BOD-based Search
Migrate your BOD-based HCL Commerce Search index and configurations to REST-based Search in HCL Commerce version 9.0.0.3+.
Starting with Version 9.0.0.5, HCL Commerce Version 9 uses Solr 7.3.1. Your index data from earlier versions of Solr is unsupported by Solr 7.3.1. This document includes instructions on converting your index data so that it can be used by the new version.
- BOD-base search is discontinued in HCL Commerce Version 9.
- The HCL Commerce Search server has its own container within your production environment. You deploy your HCL Commerce Search server as part of your CI/CD pipeline.
- The programming model for HCL Commerce Search is changed to coincide with the new build
and deployment process in HCL Commerce Version 9. The basis of the new programming model is to
separate custom HCL Commerce Search assets and configuration settings from the product code,
which reduces the resource cost of maintenance and operation. The following IBM Websphere Commerce Version 7 customizations must be updated for the new programming model:
- Solr runtime is upgraded to 5.5.4, so any customizations to Solr must be updated to follow new programming model.
- HCL Commerce Search utilities are replaced by the container utility service, which includes di-preprocess, di-buildindex, di-calculateprice, and indexprop. The SetupSearchIndex utility is discontinued. The index core directory is now automatically synchronized with the SRCHCONF table and the SRCHCONFEXT table when the HCL Commerce Search server is started. To create a new master core, extension core, or language you must maintain the SRCHCONF and SRCHCONFEXT tables. The workspace core is created automatically if the HCL Commerce Search server detects that the workspace schema is on an authoring environment.
- In HCL Commerce Version 9, the table view is used for preprocessing and index building, so any customizations to preprocessing and index building must be reconfigured according to the new programming guide.
- In HCL Commerce Version 9, the common foundation-based scheduler is enabled on the HCL Commerce Search server. Authoring environments use the scheduler to replicate indexes from authoring environments to the HCL Commerce Search repeater.
- HCL Commerce Version 9 moved to JAX-RS 2.0(JSR-339). Also, the documentation API is Swagger 2.0.
- IBM Websphere Commerce Version 7 used direct JDBC calls, which went through DSL(data service layer) to the database. In HCL Commerce Version 9, JPA 2.1 (EclipseLink) native query is used. Custom queries from previous versions are ported over to the new query service. No additional configure is required.
- In HCL Commerce Version 9, when Price or Inventory are worked as extended cores,
SolrJoin
preserves the document relationship between the mainCatalogEntry
core and the Price and Inventory subcore.MultipleQueryComponent
andMultipleFacetComponent
, which were used to join or filter the subcores in IBM Websphere Commerce Version 7, are now disabled by default. To handle facet and result fields from extension indexes, a newSearchCatalogEntryExtensionIndexPostprocessor
makes a subquery against each of the extension indexes, then joins back with the main index. A new join parameter was also introduced in wc-search.xml. Any IBM Websphere Commerce Version 7 customization to an extension index needs to be implemented to useSolrJoin
.Note: If needed, you can restore the previous functionality ofMultipleQueryComponent
andMultipleFacetComponent
.
Before you begin
- Drop all of the temporary and custom temporary tables from your database, except for the
following temporary tables:
TI_DELTA_CATENTRY
TI_DELTA_CATGROUP
TI_DELTA_INVENTORY
Your temporary tables use a
TI_
prefix. Whereas, your custom temporary tables use aXI_
prefix.Changes were made to the temporary tables between the previous versions of HCL Commerce and HCL Commerce Version 9. Failure to drop the temporary tables might result in preprocess errors, for example, SQLSTAE=56098. For more information about temporary HCL Commerce Search tables, see Temporary table schema definition.
Procedure
- Migrate your custom index cores. The following substeps illustrate how to migrate the
extended core
xCatalogEntry
for master catalog10001
as an example. These steps should be repeated for all of your custom index cores that you want to migrate. - Reimplement your custom index fields, and your preprocessing and build index scripts.
- Migrate your Search configuration files. Any configuration updates that you made under the IBM Websphere Commerce Version 7 WC_eardir directories must be copied to the corresponding extension directories under the Search_eardir directory in HCL Commerce Version 9. The extention directories arecom.ibm.commerce.foundation-ext and com.ibm.commerce.search-ext.
- Register your custom search profiles by associating them to a REST service.
- Reapply
all of your custom configurations to your wc-search.xml file.Notes:
- Delete all connection configurations that pertain to a remote Solr server. In the HCL Commerce Version 9 Search server, the connection to Solr is embedded.
- Because your cores are now read from the SRCHCONF and SRCHCONFEXT tables, remove all registered cores from your wc-search.xml file.
- Any custom search profiles that are defined in the HCL Commerce server must be redefined in the HCL Commerce Search server extension directory.
- Any custom search profiles that extend a default search profile in the HCL 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.
- Reapply any
custom configurations that you made in the wc-component.xml files under the
com.ibm.commerce.foundation-ext and
com.ibm.commerce.search-ext directories.
Most of the search-related custom properties that you 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 now stored in the STORECONF table. For more information about the search configuration properties in the STORECONF table, see, Search configuration properties in the STORECONF table.
- Migrate any custom object mediators that you made in the IBM Websphere Commerce Version 7
wc-business-objectmediator.xml file to HCL Commerce Version 9
wc-component.xml.
The Search server no longer supports business object mediators. Therefore, any customizations that you applied to 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 now use the correct mappings under the wc-component.xml file. The following example shows how an existinguserData
mapping under the HCL Commerce server wc-business-object-mediator.xml file can be moved into the Search server custom wc-component.xml file. - Reapply any 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 where 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. Each of the query parameters must be passed into the query services as query parameters.
- To allow the customized query to run under workspace schema, append
bull$SCHEMA$
to the table. - If the customized query has different query syntax for Oracle, define
a new query name. And in the code, use a different query name after determining the
dbType
, for example:<!-- ======================================================================================= --> <!-- Retrieve search configuration for given master catalog by all store's default language --> <!-- ======================================================================================= --> ... BEGIN_SQL_STATEMENT name=SELECT_SRCHCONF_DEFAULT_ORACLE base_table=SRCHCONF sql= SELECT STORECAT.CATALOG_ID, STORE.LANGUAGE_ID, SRCHCONF.INDEXSCOPE, SRCHCONF.CONFIG FROM $SCHEMA$.STORECAT STORECAT, $SCHEMA$.STORE STORE, $SCHEMA$.SRCHCONF SRCHCONF WHERE STORECAT.MASTERCATALOG = '1' AND STORECAT.STOREENT_ID = STORE.STORE_ID AND STORE.STATUS IN (?status?, 1) AND TO_CHAR(STORECAT.CATALOG_ID) = SRCHCONF.INDEXSCOPE AND SRCHCONF.INDEXTYPE = ?indexType? END_SQL_STATEMENT
All customized assets that need to retrieve data from the database, must useSearchQueryService
to read data, as seen in the following code example:SearchQueryService service = new SearchQueryService(); HashMap parameters = new HashMap(); ArrayList list = new ArrayList(); list.add(getMasterCatalog(coreName)); parameters.put(STR_MASTER_CATALOG_ID, list); list = new ArrayList(); list.add(tokens[1]); parameters.put(STR_INDEX_TYPE, list); list = new ArrayList(); list.add(getLanguageId(coreName)); parameters.put(LANGUAGE_ID, list); List<Object[]> results = service.executeQueryName("SELECT_SRCHCONFEXT", parameters); if (results.size() > 0) { indexSubtype = new ArrayList<String>(); final String STR_INDEXSUBTYPE = "INDEXSUBTYPE"; for (Object[] row : results) { indexSubtype.add((String) row[1]); } imapSearchIndexSubtype.put(coreName, indexSubtype); }
- Migrate your custom Java assets.
Due to the use of containerization, all customizations must be built by WCB script and deployed by your CI/CD pipeline. By default, custom configuration assets can be added under the search-config-ext directory, and custom java assets can be added under search-logic-ext directory. Then, the default WCB script and CI/CD pipeline can build and deploy those assets to Search container.
- Migrate your storefront search services.
In IBM Websphere Commerce Version 7, catalog navigation used the
getDataTag
. In HCL Commerce Version 9, you can use the REST-based equivalentRESTTag
.Any custom storefront pages that use theCatalogNavigationView
BOD services must be updated to use the corresponding REST services. For example, the following snippet is agetData
BOD search service that is used to get products by category:<wcf:getData type="com.ibm.commerce.catalog.facade.datatypes.CatalogNavigationViewType" var="catalogNavigationView" expressionBuilder="getCatalogEntrySearchResultsByIDView" scope="request" varShowVerb="showCatalogNavigationView" maxItems="100" recordSetStartNumber="0" scope="request"> <c:forEach var="marketingSpotData" items="${marketingSpotDatas.baseMarketingSpotActivityData}"> <c:if test='${marketingSpotData.dataType eq "CatalogEntryId"}'> <wcf:param name="UniqueID" value="${marketingSpotData.uniqueID}"/> </c:if> </c:forEach> <wcf:contextData name="storeId" data="${WCParam.storeId}" /> <wcf:contextData name="catalogId" data="${WCParam.catalogId}" /> </wcf:getData> <c:set var="eSpotCatalogIdResults" value="${catalogNavigationView.catalogEntryView}"/>
The following snippet is the equivalent REST-based service:<wcf:getData type="com.ibm.commerce.catalog.facade.datatypes.CatalogNavigationViewType" var="catalogNavigationView" expressionBuilder="getCatalogEntrySearchResultsByIDView" scope="request" varShowVerb="showCatalogNavigationView" maxItems="100" recordSetStartNumber="0" scope="request"> <c:forEach var="marketingSpotData" items="${marketingSpotDatas.baseMarketingSpotActivityData}"> <c:if test='${marketingSpotData.dataType eq "CatalogEntryId"}'> <wcf:param name="UniqueID" value="${marketingSpotData.uniqueID}"/> </c:if> </c:forEach> <wcf:contextData name="storeId" data="${WCParam.storeId}" /> <wcf:contextData name="catalogId" data="${WCParam.catalogId}" /> </wcf:getData> <c:set var="eSpotCatalogIdResults" value="${catalogNavigationView.catalogEntryView}"/>
The response data is being formatted in a dot notation response similar to BOD to minimize the changes that are required in the storefront. In some cases, the response is simplified and flattened to simpler name-value pairs, rather than using internal maps to group certain fields.
You can examine the JSON response by printing the response object by using the following code:
<wcf:json object="${catalogNavigationView}"/>
- Map your BOD services to REST services.
All BOD search services can be covered by REST search services. There are three main search handlers:
CategoryViewHandler
,ProductViewHandler
, andSiteContentHandler
. Each perform different search functionality. For example,ProductViewHandler
can search by Category, productId, productIds, partNumber, partNumbers, and searchTerm.Use the following table to help map your BOD services to REST services.Table to illustrate mapping between BOD and REST services.
BOD service Expression builder REST resource REST service CatalogNavigationView getCatalogNavigationView ProductViewHandler (Search) store/{storeId}/productview/bySearchTerm/{searchTerm} getCatalogNavigationAttachmentView store/{storeId}/productview/bySearchTerm/{searchTerm} getCatalogNavigationViewByCategory store/{storeId}/productview/byCategory/{categoryId} getCatalogNavigationBreadCrumbView store/{storeId}/productview/byCategory/{categoryId} getCatalogNavigationCatalogEntryView store/{storeId}/productview/byId/{productId}, store/{storeId}/productview/byIds getCatalogEntryViewAllWithoutAttachmentsByID store/{storeId}/productview/byId/{productId}, store/{storeId}/productview/byIds getCatalogEntrySearchResultsByIDView store/{storeId}/productview/byId/{productId}, store/{storeId}/productview/byIds getCatalogEntryViewParentInfoByIDNoEntitlementCheck store/{storeId}/productview/byId/{productId}, store/{storeId}/productview/byIds getCatalogEntryViewForShoppingCart store/{storeId}/productview/byId/{productId}, store/{storeId}/productview/byIds getCatalogEntryViewPriceWithAttributesByID store/{storeId}/productview/byId/{productId}, store/{storeId}/productview/byIds getCatalogNavigationCatalogGroupView CategoryViewHandler (Search) store/{storeId}/categoryview/byId/{categoryId}, store/{storeId}/categoryview/byIds getCatalogNavigationCatalogGroupViewByIdentifier store/{storeId}/categoryview/{categoryIdentifier} getCatalogNavigationCatalogGroupViewByCatalogId store/{storeId}/categoryview/@top getCatalogNavigationCatalogGroupViewByParentCatalogGroup store/{storeId}/categoryview/byParentCategory/{parentCategoryId} getWebContentView SiteContentHandler (Search) store/{storeId}/sitecontent/webContentsBySearchTerm/{searchTerm} store/{storeId}/sitecontent/brandSuggestions store/{storeId}/sitecontent/categorySuggestions - Import EnvironmentSetup.jspf in the page where you used to call
BOD service to follow JSP programming guide. In this JSPF file,
searchHostName
,searchContextPath
are defined, so in the JSP where you want to call search rest, this variable could be used directly. - Using the mapping between BOD with search rest, find the equivalent rest service, then
change
getDataTag
toRESTtag
. - With BOD request, store side could use
CatalogNavigationViewType
noun to retrieve needed object from the response of BOD request, this noun basically represents a business response of a catalog browsing request.
- Import EnvironmentSetup.jspf in the page where you used to call
BOD service to follow JSP programming guide. In this JSPF file,
- Map your BOD search profiles to REST search profiles. The following table illustrates the mapping between the search profiles that are used by the
CatalogNavigationViewBOD
services and the corresponding REST search profiles. There are several factors that differentiate search profiles from each other. When you compare search profiles, consider the following factors.- Query fields
- Controls the search scope.
- Results fields
- Controls the returned fields.
- Expression providers
- Contributes to the selection criteria object.
- Preprocessors
- Prepares the final search expression object.
- Postprocessors
- Mediates the search response and contributes to the final response object.
Mapping between BOD Search profiles and REST Search profiles.
BOD search profile REST search profile IBM_ComposeProductListByCategoryId
IBM_findProductsByCategory
IBM_ComposeCategoryFacetListByCategoryId
Deprecated by IBM_findProductsByCategory
IBM_BreadCrumb
IBM_BreadCrumbByCategoryUniqueId
IBM_findFacetsByCategory
Deprecated by IBM_findProductsByCategory
I BM_ComposeFacetListByCategoryId
IBM_ComposeFacetListByCategoryId
IBM_findCatalogEntryWithoutDescriptionByNameAndShortDescription
IBM_findProductsBySearchTerm
IBM_findCatalogEntryWithoutDescriptionByNameAndShortDescriptionInDetail
Deprecated by IBM_findProductsBySearchTerm
IBM_findCatalogGroupByFacet
Deprecated by IBM_findProductsBySearchTerm
IBM_findCatalogEntryByName
IBM_findProductsByNameOnly
IBM_findCatalogEntryByUnstructureField
IBM_findProductsByUnstructureOnly
IBM_findCatalogEntryByNameAndShortDescriptionOnly
IBM_findProductsByNameAndShortDescriptionOnly
IBM_findCatalogEntryByNameAndShortDescription
Deprecated by IBM_findProductsByNameAndShortDescriptionOnly
IBM_findCatalogEntryByNameAndShortDescriptionInDetail
Deprecated by IBM_findProductsByNameAndShortDescriptionOnly
IBM_findCatalogEntryIdByNameAndShortDescription
Deprecated by IBM_findProductsByNameAndShortDescriptionOnly
IBM_findCatalogEntryDetails
IBM_findProductByIds_Details
IBM_findCatalogEntryAll
Deprecated by IBM_findProductByIds_Details
IBM_findCatalogEntryAll_PriceMode
Deprecated by IBM_findProductByIds_Details
IBM_findCatalogEntrySKUs
Deprecated by IBM_findProductByIds_Details
IBM_findCatalogEntryDetailsWithComponents
Deprecated by IBM_findProductByIds_Details
IBM_findCatalogEntryDetailsWithComponentsAndAttachments
Deprecated by IBM_findProductByIds_Details
IBM_findCatalogEntryDetailsWithMerchandisingAssocDetails
Deprecated by IBM_findProductByIds_Details
IBM_findCatalogEntryDetails_PriceMode
Deprecated by IBM_findProductByIds_Details
IBM_findComponentsSummary
Deprecated by IBM_findProductByIds_Details
IBM_findComponentsSummaryDetails
Deprecated by IBM_findProductByIds_Details
IBM_findCatalogEntryDetailsWithMerchandisingAssocSummary
Deprecated by IBM_findProductByIds_Details
IBM_fetchRelatedCatalogEntryDetailedInfo
Deprecated by IBM_findProductByIds_Details
IBM_findCatalogEntrySummary
IBM_findProductByIds_Summary
IBM_findCatalogEntryByID
Deprecated by IBM_findProductByIds_Summary
IBM_findCatalogEntryPrice
Deprecated by IBM_findProductByIds_Summary
IBM_findCatalogEntryDynamicKitSummary
Deprecated by IBM_findProductByIds_Summary
IBM_fetchRelatedCatalogEntrySummaryInfo
Deprecated by IBM_findProductByIds_Summary
IBM_CatalogEntryCategoryEntitlement
Deprecated by IBM_findProductByIds_Summary
IBM_CatalogEntryEntitlement
Deprecated by IBM_findProductByIds_Summary
IBM_findCatalogEntryPriceWithAttributes_PriceMode
Deprecated by IBM_findProductByIds_Summary
IBM_findCatalogEntryAttachments
IBM_findProductByIdsWithAttributesAndAttachments
IBM_findCatalogEntryDetailsWithAttachments
Deprecated by IBM_findProductByIdsWithAttributesAndAttachments
IBM_findCatalogEntryPriceWithAttributes
Deprecated by IBM_findProductByIdsWithAttributesAndAttachments
IBM_findAttachmentByCatentryId
Deprecated by IBM_findProductByIdsWithAttributesAndAttachments
IBM_findCatalogEntryParentInfoNoEntitlementCheck
IBM_findProductByIds_Summary_WithNoEntitlementCheck
IBM_findCatalogEntryForShoppingCart
IBM_findProductByIds_Summary_WithNoEntitlementCheck
IBM_findCatalogGroupSummary
IBM_findCategoryByUniqueIds, IBM_findCategoryByIdentifier
IBM_findCatalogGroupDetails
IBM_findSubCategories
IBM_Global_WebContent
IBM_findWebContentsBySearchTerm
IBM_findAttachmentByContent
Deprecated by IBM_findWebContentsBySearchTerm
IBM_findNavigationSuggestion_Brands
IBM_findNavigationSuggestion_Brands
IBM_findNavigationSuggestion_Categories
IBM_findNavigationSuggestion_Categories
IBM_Global
There is no exact match for this Search profile on the HCL Commerce Version 9 Search server. Consider the following search profiles as replacements: IBM_findProductsByCategory
(for navigation)IBM_findProductsBySearchTerm
(for keyword search)IBM_findProductByIds_Details
(for the product display page)
IBM_Global_Unstructured
There is no exact match for this search profile on the Search server. Consider the following search profiles as replacements: IBM_findWebContentsBySearchTerm
(for web content)IBM_findProductsByUnstructureOnly
(for searching product attachments)
IBM_findNavigationSuggestions
There is no exact match for this search profile on the Search server. Consider the following search profiles as replacements: IBM_findNavigationSuggestion_Categories
(for category suggestions)IBM_findNavigationSuggestion_Brands
(for brand suggestions)
- Map your BOD expression providers to REST expression providers by referencing the
following table.
BOD-based search expression provider REST-based search expression provider Description SolrSearchBasedMerchandisingExpressionProvider
SearchBasedMerchandisingExpressionProvider
Calls the marketing component to run search rules. SolrSearchByCatalogExpressionProvider
SearchByCatalogExpressionProvider
Handles searching by catalog, considering the sales catalog in the current business context. SolrSearchByCategoryExpressionProvider
SearchByCategoryExpressionProvider
Handles searching by category, considering the sales catalog in the current business context. SolrSearchByCustomExpressionProvider
SearchByCustomExpressionProvider
Includes custom expressions that are stored in _wcf.search.expr
.SolrSearchByFacetExpressionProvider
SearchByFacetExpressionProvider
Handles searching by facet requests. SolrSearchByKeywordExpressionProvider
SearchByKeywordExpressionProvider
Handles searching by keyword requests. SolrSearchByKeywordRelevancyExpressionProvider
SearchByKeywordRelevancyExpressionProvider
Handles searching by keyword requests that use the dismax query parser. SolrSearchByManufacturerExpressionProvider
SearchByManufacturerExpressionProvider
Handles searching by brand name requests. SolrSearchByPriceExpressionProvider
SearchByPriceExpressionProvider
Handles searching by price range requests generated from the Advanced Search page. SolrSearchByPublishedEntryOnlyExpressionProvider
SearchByPublishedEntryOnlyExpressionProvider
Generates conditions for restricting search results to only published entries. SolrSearchByStorePathExpressionProvider
SearchByStorePathExpressionProvider
Generates conditions to handle the store path. SolrSearchCategoryEntitlementExpressionProvider
SearchCategoryEntitlementExpressionProvider
Performs category entitlement. SolrSearchFacetConditionExpressionProvider
SearchFacetConditionExpressionProvider
Generates a list of attribute-related facets and currency-specific price range facets for the current search request. SolrSearchInventoryExpressionProvider
SearchInventoryExpressionProvider
Handles searching related to the Inventory index. SolrSearchProductEntitlementExpressionProvider
SearchProductEntitlementExpressionProvider
Performs product entitlement. SolrSearchSequencingExpressionProvider
SearchProductSequencingExpressionProvider
Arranges product entries in the search result by ranking. SolrSearchTermAssociationExpressionProvider
SearchTermAssociationExpressionProvider
Gets synonyms and replaces the search term to fetch the final result. SolrSearchTypeExpressionProvider
SearchTypeExpressionProvider
Handles the match type for keyword search requests, such as Any and Exclude SKU. SolrSearchWebContentStoreInfoExpressionProvider
SearchWebContentStoreInfoExpressionProvider
Handles adding conditions to search store-specific site contents - Map your BOD post-processors to REST post-processors by referencing the following
table.
BOD-based search preprocessor REST-based search preprocessor SolrSearchResultGroupingQueryPreprocessor
SearchResultGroupingQueryPreprocessor
SolrSearchDebugQueryPreprocessor
SearchDebugQueryPreprocessor
SolrSearchEDismaxQueryPreProcessor
SearchEDismaxQueryPreProcessor
SolrSearchFacetQueryPreprocessor
SearchFacetQueryPreprocessor
SolrSearchHighlighterQueryPreprocessor
SearchHighlighterQueryPreprocessor
SolrSearchMainQueryPreprocessor
SearchMainQueryPreprocessor
SolrSearchPaginationQueryPreprocessor
SearchPaginationQueryPreprocessor
SolrSearchPreviewQueryPreprocessor
SearchPreviewQueryPreprocessor
SolrSearchResultFieldQueryPreprocessor
SearchResultFieldQueryPreprocessor
SolrSearchSortingQueryPreprocessor
SearchSortingQueryPreprocessor
SolrSearchSpellCorrectionQueryPreprocessor
SearchSpellCorrectionQueryPreprocessor
Note: The following are new post-processors:SearchCustomQueryPreprocessor
SearchJoinQueryPreprocessor
SearchManualSequenceOverrideQueryPreprocessor
SearchProductSequenceDebugInfoQueryPreprocessor
SearchRelevancyByProductGroupingQueryPreprocessor
SearchResponseFormatQueryPreprocessor
- Map your BOD search result filters and postprocessors to REST search result filters and
postprocessors by referencing the following table.
BOD-based search result filter REST-based search postprocessor SearchCatalogEntryMerchandisingAssocResultFilter
SearchCatalogEntryViewMerchandisingAssocQueryPostprocessor
SearchCatalogEntryViewAttachmentsResultFilter
SearchCatalogEntryViewAttachmentsQueryPostprocessor
SearchCatalogEntryViewAttributesAllowedValueResultFilter
SearchCatalogEntryViewAttributesQueryPostprocessor
SearchCatalogEntryViewAttributesResultFilter
SearchCatalogEntryViewAttributesQueryPostprocessor
SearchCatalogEntryViewDescriptionResultFilter
SearchCatalogEntryViewDescriptionQueryPostprocessor
SearchCatalogEntryViewPackageBundleResultFilter
SearchCatalogEntryViewComponentsQueryPostprocessor
SearchCatalogEntryViewPriceResultFilter
SearchCatalogEntryViewPriceQueryPostprocessor
SearchCatalogEntryViewSingleSKUResultFilter
The logic that is deprecated by indexing the childCatentry_id
field.SearchCatalogEntryViewSKUResultFilter
SearchCatalogEntryViewSKUQueryPostprocessor
SearchCatalogEntryViewStoreDisplayAttributesResultFilter
SearchCatalogEntryViewAttributesQueryPostprocessor
SearchCatalogGroupEntitlementResultFilter
SearchCategoryEntitlementQueryPostprocessor
,SearchChildCategoryEntitlementQueryPostprocessor
SearchCatalogNavigationViewDynamicKitResultFilter
SearchCatalogEntryViewDynamicKitQueryPostprocessor
SearchCatalogNavigationViewPreviewResultFilter
SearchPreviewQueryPostprocessor
SearchCatalogNavigationViewSEOTitleMetaDataFilter
The Search Server does not return SEO metadata. Metadata is returned from the WebSphere Commerce server. SearchNavigationSuggestionsResultFilter
SearchCategorySuggestionQueryPostprocessor
, SearchBrandSuggestionQueryPostprocessor - Reapply your Solr
customizations.
HCL Commerce Version 9 uses Solr 5.5.4. All customization based on the previous Solr versions must be implemented on Solr 5.5.4.
- Migrate any customized search services.
- Migrate your data cache.
In HCL Commerce Version 9, data cache is enabled on the Search server. For more information about data cache, see Enabling cache monitoring.
- Migrate your custom scheduled jobs.In HCL Commerce Version 9, a scheduler exists on the Search server. You can use the following table to recreate your scheduled Search jobs.
- SRCH_SCHACTIVE
- SRCH_SCHBRDCST
- SRCH_SCHCONFIG
- SRCH_SCHERRLOG
- SRCH_SCHREPORT
- SRCH_SCHSTATUS