Limitations of WebSphere Commerce Search

The following limitations exist in WebSphere Commerce Search.

Workspaces

• Web content (articles and videos) is not content managed when we are working with WebSphere Commerce search and workspaces.

  When the index of a workspace with default parameters is building, a local copy of the web content index is created under the workspace. This copy is not invalidated when changes are made to the base web content index. Specify the indextype and indexsubtype parameters to avoid creating the workspace copy of the web content index. If the web content index is created under the workspace, the -webcontentDelete parameter can be used to delete the workspace copy of the web content index.

• Manage facets is not supported in workspaces by default.

• Multiple workspace indexes are not supported by default.

Language fallback

If a catalog object, for example, catalog, catalog group, or catalog entry, displays text in the storefront that is not defined for a certain language, it might include limited language fallback support, depending on your feature pack version. That is, if the text is not defined in a certain language, the object containing the missing text instead uses the store's default language as a fallback, if the text is available in the default locale. If the store's default language does not contain the text, the object either is not returned, or returned with missing properties. The missing data is looked up in the database, which includes the product name, short description, long description, thumbnail, full image, and keywords. Limited language fallback is supported for catalog entries under the following conditions:

• A description is defined for all catalogs and categories in each supported language. If these descriptions are not defined for the language that a customer is browsing the store in, the catalog or category and the catalog entries within it do not display.

• The display to customer setting for catalog entries must be selected and saved within Management Center in each language that the store supports. By default, this setting can display as selected when a business user views the catalog entry properties in Management Center for a language. This setting, however, might not be saved in the database as selected. If this setting is not selected, the catalog entry does not display when a customer visits the store in that language. By explicitly saving this setting as selected within Management Center, a business user can ensure that the catalog entry does displays when a customer visits the store in that language. Then, if no descriptive information exists for the catalog entry in that language, the fallback language information displays.

• If the site uses an extended site store model and uses description overrides, a description (either an asset store or extended site store description) must exist for the catalog entry in each language. If you do not have an extended site store-specific description that is defined for the current language that is displaying, the asset store description for that language displays. If there is no extended site store-specific description and no inherited asset store description that is defined for the current language, no description displays for the catalog entry.

• Fallback languages are not supported for catalogs or categories.

• Fallback languages are not supported for facet values.

• When the DisplayEntryWithNoName parameter in the catalog component configuration file (wc-component.xml) (Search EAR) is set to false, language fall back is not supported. That is, when set to false, products with no name are not displayed by default, ignoring any fallback behavior for catalog entries with missing properties.

Utilities

• When the build index RESTful service is called, the data cache is invalidated (SRCHATTR, CATGROUP, CATGRPDESC, CATGRPREL), but the storefront cache is not invalidated.

• When we are running reindexing scripts, such as di-buildindex, from the command line, cached contents from the storefront are not automatically invalidated. These cached contents can either be evicted using the WebSphere Application Server Cache Monitor, or by inserting the appropriate invalidation strings directly into the CACHEIVL table. However, if reindexing is performed by the UpdateSearchIndex scheduler job, then the cache invalidation can be issued programmatically. See the following topics

  • Caching and invalidation in WebSphere Commerce Search

  • Creating and scheduling the UpdateSearchIndex job

  • Cache monitor

  • CACHEIVL

• (Developer) The store publish task cannot be run while the UpdateSearchIndex job is in progress, due to deadlock. To avoid this issue, delete the scheduler job, or reduce its frequency so that it does not collide with the store publish task.

General

• IBM Digital Analytics, formerly known as Coremetrics Analytics is not preconfigured for WebSphere Commerce Search by default.

• The WebSphere Commerce Search dictionary might contain more words from items or products in the master catalog, not available to the current store. For example, this difference can occur when the name or description of a SKU contains more information than the product description. This difference can result in missed searches on suggested keywords, where suggested keywords contain no search results.

• When we are creating a category or renaming an existing category, we might need to evict cached content with the WebSphere Application Server Cache Monitor. Otherwise, the newly created category or updated category might not be visible in the storefront.

• Catalog filters based on categories show all the products in the storefront. To avoid this issue, we must exclude the master catalog to show only the specific category.

• The storefront supports the master catalog in the following scenarios:

  • The auto-suggest menu for suggested keywords supports the master catalog, and does not scope to any category or sales catalog. That is, it does not support the catalog ID setting such as a sales catalog by default.

  • The breadcrumb trail for linked categories supports the master catalog. That is, it does not match the catalog ID setting such as a sales catalog hierarchy by default.

  • Catalog entries that are marked as unpublished (publish flag set to false) do not get published in any supported languages, since the search index published field is not language-specific.

• Business rules such as search term associations and search rules cannot be applied to auto-suggest. This is due to the suggestion source being the CatalogEntry index-based product data in the master catalog.

• Replacement terms for search term associations cannot contain multiple words. To work around this issue, create multiple rules that include the words to replace.

• The Solr query returns all products in the index when a comma is used in the filter query of a tokenized field. To ensure that search results are filtered correctly, avoid by using commas in the search query.