WebSphere Commerce Search extension points and customization tasks

WebSphere Commerce Search contains extension points that can be used for customization. There are mandatory and optional areas to work with, depending on the customization to your WebSphere Commerce Search implementation.

Most customization flows involve indexing new data from either the database or a file, searching against the new indexed fields, displaying the indexed data in the storefront, and creating business rules by using the indexed data field. Other advanced search customization areas require some runtime customization where a custom search expression provider, search result filter, or other runtime search extension points might require customization.

These extension points are described in the following flow diagram:
WebSphere Commerce Search architecture

Where the WebSphere Commerce Search run time is used on the search server. Instead of using BOD and performing object based-mediation, the search REST programming model does not rely on any SDO. It uses POJO and raw data that is returned from the search server to perform simple name-value pair mapping.

Indexing (including preprocessing) is performed and launched from the WebSphere Commerce server. After index preprocessing successfully completes, the Data Import Handler (DIH) can be run from the same WebSphere Commerce server. Solr can start creating and updating the Lucene index from the WebSphere Commerce temporary database tables. If preprocessing is not required, such as for the inventory extension index, the DIH process can be started either from WebSphere Commerce or directly from a URL issued against the WebSphere Commerce Search server.