Limitations of WebSphere Commerce Search

The following limitations exist in WebSphere Commerce search-enabled starter stores.

Workspaces

  • Feature Pack 3Feature Pack 2Feature Pack 4Previewing non-approved store changes that are made in workspaces are not supported by default, as the workspace schema is not indexed.
  • Feature Pack 5Web content (articles and videos) is not content managed when you 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.

  • Feature Pack 5Managing facets is not supported in workspaces by default.
  • Feature Pack 5Multiple workspace indexes are not supported by default.

Madisons starter store

  • Feature Pack 3WebSphere Commerce DeveloperAfter you publish the Madisons enhancements store archive, WebSphere Commerce search is automatically set up and the search index is built. However, the site content search index subtype is not set up by default and must be manually built.
  • The Madisons mobile starter store does not support WebSphere Commerce search.

    Feature Pack 4 or laterHowever, smartphone and tablet starter stores do support WebSphere Commerce search.

  • Feature Pack 3WebSphere Commerce DeveloperAfter you publish the Madisons enhancements store archive, WebSphere Commerce search is automatically set up and the search index is built. However, the site content search index subtype is not set up by default and must be manually built.
  • The Madisons mobile starter store does not support WebSphere Commerce search.

    Feature Pack 4 or laterHowever, smartphone and tablet starter stores do support WebSphere Commerce search.

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.

The following language fallback behavior occurs, depending on your feature pack version:
  • Feature Pack 3Feature Pack 2Feature Pack 4Language fallback is not supported.
  • Feature Pack 5 or laterLimited 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 your 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 your 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 your database as selected. If this setting is not selected, the catalog entry does not display when a customer visits your 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 your store in that language. Then, if no descriptive information exists for the catalog entry in that language, the fallback language information displays.
    • WebSphere Commerce EnterpriseIf your 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.
    • Feature Pack 8When 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.
    • Fallback languages are not supported for attributes.

Utilities

  • Feature Pack 5 or laterWhen the build index utility is running from the command line, the data cache is invalidated (SRCHATTR, CATGROUP, CATGRPDESC, CATGRPREL), but the storefront cache is not invalidated.
  • When you 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 by 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. For more information, see the following topics
  • Feature Pack 7 or laterApache DerbyWebSphere Commerce DeveloperThe 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

  • is not pre-configured for WebSphere Commerce search by default.
  • Feature Pack 2WebSphere Commerce search does not support category-level SKUs by default. That is, SKUs under a category that are not associated with any product. This type of SKU is used for products that do not have defining attributes.
  • 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.
  • If you are considering integrating with third-party search solution, you must consider the scope of the customization points listed in Integrating WebSphere Commerce with third-party search engines.
  • When you are creating a category or renaming an existing category, you 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, you 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.
  • Feature Pack 7 or laterThe 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.