WebSphere Commerce Search
WebSphere Commerce comes with a powerful and fully integrated search function. The search functions in WebSphere Commerce provide an enriched customer experience, with features such as automatic search term suggestions and spelling correction. Since it is built on open standards, WebSphere Commerce Search is highly flexible and extensible. Starter stores can use the search engine's most sophisticated features without requiring extra customization. A key feature of Search is that sales personnel can create and manage search term associations, and search-based merchandising rules, from within the Management Center and Store view.
- Shoppers can look for products and browse the storefront by using an intuitive and highly responsive interface that can anticipate their needs. Basic functions include guided navigation, landing pages, and dynamic merchandising suggestions.
- Business users can influence product selection and display order using the Management Center or the Commerce Insights Store view.
- Relevant content is easier to find because the Search system uses a combination of relational database and unstructured text-searching modules.
- Search can be deployed on a dedicated server or cluster, fully decoupled from the transaction processing component of the store. Large numbers of complex search queries can run in parallel with order processing with no degradation in response time. Scalability is not a problem.
- Deployment and ownership costs are lower, since all of these capabilities come included with WebSphere Commerce.
How WebSphere Commerce Search works
At the front end, WebSphere Commerce Search interacts with users and other components of the store environment by using HTTP REST requests. On the server, it merges the speed of relational databases with the flexibility of unstructured XML. As queries come in, they are transformed into XML documents whose content is compared against a detailed index by the Apache Solr engine.
- A customer enters a search string in the browser. Autosuggest and look-ahead make this process easier. The browser submits the request to the storefront by HTTP, in the form of an XML expression.
- Depending on the size of the store, the search expression can go directly to the WebSphere Commerce Server, or be diverted to one of a cluster of dedicated web servers. You can use load balancers to coordinate high volumes of traffic.
- The expression is routed to the search interface on the main server or a dedicated Search server. The search interface can accommodate multiple languages and high-volume transaction environments. The interface parses the expression and applies spelling corrections, thesaurus-lookup, and other optimizations. It also assigns a search profile to the incoming expression (declaring it to be a ProductView request, for instance).
- Any number of business and merchandiser rules can now come into play in expression preprocessing of the query. Customer profiles and segments can also alter the expression before it is processed. Dynamic states such as the current contents of the customer's cart can also influence the query at this stage. In B2B situations, access and entitlement rules can filter the results.
- The search processor compares the finalized contents of the search expression to the fields in the index.
- The results of this search can be processed again by using a customizable expression post-processing provider. A response is built, taking advantage of the storefront's customer-centric features, such as faceted navigation, previewing, and catalog navigation.
- The response is returned as XML and be further processed and presented in an appropriate manner, by using a landing page, preview, suggestion or within a widget.
The search server
The search server consists of a set of REST services, a search runtime framework, and a set of WebSphere Commerce foundation services that also provide access to the production database. The search runtime engine includes the search expression providers and expression processor.
REST services
The search interface uses REST to convert the incoming request into a specific resource call, for
instance a ProductView call. The resulting expression is handed off to the
expression processor, where more business logic will be applied.
Expression providers
Depending on the search profile of the request, various business components might get involved, such as Marketing for search-based merchandising rules, or Contracts for entitlement. Each business component can contribute a portion of the search expression through its own expression provider. Each contribution is combined with the main search expression that is generated by the REST services. The resulting search expression is run by the search processor.
The expression processor
The expression processor uses the Solr engine to run the search against the index, and captures the result for post-processing and final response.
The search index
The search index is the key to the system's power. This index is a large flat table that contains data fields that are optimized for search performance. Each field consists of a name, its content, and metadata that tells WebSphere Commerce Search how to handle the content. Typically, fields can contain Boolean values, numbers, or strings. A field is flexible, so you can define your own type in the system's schema file.
Catalog items must be in the index to be searchable. Therefore, before Search is deployed an indexing step is required. The index can be updated at regular intervals or as needed during the operation of the store. During the indexing step, Solr collects, parses, and files catalog data from the store to facilitate fast and accurate retrieval of information. In its emphasis on building and optimizing an index, the Solr engine acts more like a traditional database than a web server or transaction processor. It is its own application, and can reside on its own dedicated server.