Using Solr search with Next.js stores

Name-Entity-Recognition does not work with when Ruby stores use the Solr engine

The Elasticsearch-based search service can perform Name-Entity-Recognition (NER) because it uses the CoreNLP natural language processing modules. NER allows the storefront to work with search strings more flexibly than Solr. For example, if you type "Home design" in a store's search field and select "Brand selection," you will receive a set of related brands if the underlying search engine is the V9.1 Elasticsearch version, but only the results of a plain text search on the words "Home" and "design" if the engine is Solr.

Price filtersdo not work in Ruby store searches that use Solr

The expected behavior in HCL Commerce Search is that if you search for a cabinet over $100, you expect to receive a listing of products with prices above $100. When a Ruby store uses the Orchestration service and the Solr search engine, responses include products with prices below $100.

This behavior occurs because Solr does not have Natural Language Processing capability. It can only perform plain text searches. Solr cannot perform a descriptive price condition that includes a price range or other modifier.

Price rules are not updated after price indexing

Price rules are expected to be up-to-date. When you use a Ruby store with the Solr search solution, rules are not automatically updated after reindexing. You can correct this behavior using the following SQL command:

Certain misspelled words return a null response

Solr presently does not support auto spell correction. So, when Ruby is served up by Solr, auto spell correction is not performed, which is why looking for misspelled words may produce an empty search result.

Description

Some misspelled words do not give any response in Solr when it is used in the Ruby storefront.

Expected Behavior

Searching using the misspelled term "Stockholm Lighing" yields no results, while searching with "bender home fashion" yields results.

Actual Behavior

If you search with any misspelled term like 'Stockholm Lighing,' you get a response.

Steps to Reproduce

1. The misspelled term "Stockholm Lighing" yields no results whether searched on the storefront or in the API.

   • {
     "recordSetCount": 0,
     "metaData":
     
     { "price": "1", "spellcheck": [ "stockholm lighting", "stockholm living", "lighting", "living" ] }
     ,
     "resourceId": "https://search:3738/search/resources/store/41/productview/bySearchTerm/Stockholm%20Lighing?storeId=41&searchTerm=Stockholm%20Lighing&profileName=HCL_findProductsBySearchTerm_extended",
     "recordSetStartNumber": 0,
     "resourceName": "productview",
     "total": 0,
     "recordSetTotalMatches": 0,
     "recordSetComplete": "true"
     }

SKU search in store front giving multiple products as results: no auto-suggestion for partnumber

Unlike Elasticsearch, Solr does not suggest part numbers. Part numbers are treated as regular search terms, and the "starts with" action is used to look for matches. Solr does not work the same way as Elasticsearch.

Image path prefix

The Ruby storefront has a single default setting in the wc-component.xml file to define the prefix string to be prepended to each image path. They are called storeWebAlias and StorePreviewPrefix. For example, if you needed to define a path at an Asset Store level the path needs to be defined as the Asset Store level. In that case, the STORECONF database table can be used instead to override the default image path prefix by adding hcl.imagePath with the corresponding Asset Store ID as the owning store. If further refinement is needed at the Store level, insert an additional entry for hcl.imagePath into the STORECONF STORECONF table, which contains the required Store ID as the store owner for this entry.