Extend the WebSphere Commerce Search base index schema
The base index schema can be extended to suit your business needs. For example, to separate data into different indexes that are based on their refresh intervals.It can be extended by creating a new separate index schema and linking it to the base index. In some cases, it is more desirable to separate data into different indexes. In this scenario, you create a new separate index schema and link it to the base index.
For example, the product base index is used to store static data for the product, such as product identifier, name, and short description. These values typically do not change often. However, dynamic information such as product inventory or ratings change more frequently. Therefore, it is put into a separate index, where it can be refreshed at different intervals than the base product index.
The WebSphere Commerce Search base index schema is customized according to the following flow:
Where:
- The extension index artifacts must be created first, and placed in a specific directory under the deployed Solr home directory. The extension index schema structure is defined in the Solr schema.xml configuration file.
For the base index to be able to reference an extension index, the extension index schema must define what is similar to a foreign key that matches the unique field name and type in the base index schema. The referenced field data type must be a simple data type such as String, Integer, or float. It must match the unique key name and type of the base index.
Avoid common field names between extension indexes and the base index, other than the referenced field. IBM recommends to use a naming convention that prefixes the extension index fields to avoid naming collisions.
- The extension index cores must be registered under the solr.xml file, as the Solr server loads indexes registered under the solr.xml file. This file also contains the mapping between the base index and extension index.
- The extension index must be registered in the WebSphere Commerce database. The WebSphere Commerce run time looks up all Solr indexes that are registered in the SRCHCONFEXT table. Extension indexes are registered as index subtypes of the base index.
Note: The Product Ranking index is used to demonstrate the steps that are needed to extend the Catalog Entry base index schema for master catalog ID 10001 in WebSphere Commerce Developer. The index type is CatalogEntry. The new index subtype is Ranking, and the new index core name is MC_10001_CatalogEntry_Ranking_generic.
Procedure
- Create the extension index in the Solr server.
- Locate the sampleIndexCore template under the following directory: workspace_dir\components\foundation\samples\SolrIndex\template.
- Make a copy of the sampleIndexCore under the deployed Solr home generic\CatalogEntry directory. If the directories do not exist, create them: workspace_dir\search\solr\home\MC_10001\generic\CatalogEntry.
- Rename the copied sampleIndexCore to Ranking.
The index core directory therefore becomes: workspace_dir\search\solr\home\MC_10001\generic\CatalogEntry\Ranking
- Update the schema.xml file under the conf core directory to add the new Ranking field:
<field name="ext_ranking" type="tfloat" indexed="true" stored="true" multiValued="false" />
- Register the extension index in the solr.xml file.
- Locate and edit the solr.xml file under the Solr home directory: workspace_dir\search\solr\home
- Append the extension index core to the end of the listed cores:
<core instanceDir="MC_10001\generic\CatalogEntry\Ranking\" name="MC_10001_CatalogEntry_Ranking_generic"> <property name="notifyOnChange" value="MC_10001_CatalogEntry_en_US"/> </core>
- Save and close the file.
- Register the extension index core into the SRCHCONFEXT table.
INSERT INTO srchconfext (srchconfext_id,indextype,indexscope,indexsubtype,config) VALUES(-100,'CatalogEntry','10001','Ranking','SearchServerName=localhost,SearchServerPort=80');
- Restart the test server.
- Verify the extension index at the following URL:
- http://localhost/solr/MC_10001_CatalogEntry_Ranking_generic/select?q=*
The response from the URL should resemble the following snippet:
<?xml version="1.0" encoding="UTF-8"?> -<response> -<lst name="responseHeader"> <int name="status">0</int> <int name="QTime">62</int> -<lst name="params"> <str name="q">*</str> </lst> </lst> <result name="response" start="0" numFound="0"/> </response>
What to do next
To work with an inventory index in WebSphere Commerce Search, complete the following tutorial: Set up and building the inventory index.
- Extending the WebSphere Commerce search base index schema
The Search index is set up automatically during Search server startup. Search cores are created according to the configuration settings defined in the SRCHCONF and SRCHCONFEXT database tables. We can customize these tables to control the creation of search index cores.- Customizing indexing
The indexing process requires mapping data from an external source (database or file) to index fields to create index records or index documents. Depending on the complexity of the source data and index schema design, preprocessing the data might be required. Otherwise, indexing can be directly performed by using either the Data Import Handler (DIH) to index data from the database, or Solr APIs to index data from a file.- Customizing the search run time
We can customize several areas of the search run time.- Adding custom index fields in REST responses
We can add custom index fields to be returned in REST responses by updating the wc-component.xml file.- Customizing search profiles
WebSphere Commerce Search uses search profiles to control the storefront search experience at a page-level. Search profiles group search runtime parameters (search index name, search index fields, expression providers and result filters, paging and sorting), and search feature configurations (text highlight, facets, and spelling correction). Search profiles are defined in the WebSphere Commerce Search configuration file, wc-search.xml.- Customizing WebSphere Commerce Search in the Management Center
We must customize WebSphere Commerce Search when we are adding new indexed catalog entry properties to search rule actions or targets.- Customizing WebSphere Commerce Search in the storefront
We can customize WebSphere Commerce Search in the storefront to suit your business needs. We can customize WebSphere Commerce Search according to your role within the WebSphere Commerce site.- Category navigation rules
We can use navigation rules to sort products in a category via a specific criterion such as price.- Customizable components of the final Solr query
We can customize components of the final Solr query by using query parsers. A query parser is a component responsible for parsing the textual query and converting it into corresponding Lucene Query objects.- Search term association handling
Search term associations are used to suggest more, different, or replacement products in search results. Search term associations can also link search terms to a selected landing page in the store. Business users manage search term associations in the Management Center by using the Catalogs tool.- Limitations of WebSphere Commerce Search
The following limitations exist in WebSphere Commerce Search.