Propagating the search index

You can propagate the HCL Commerce search index by calling the indexprop REST API. Use Indexprop to request that the search index repeater replicate with the staging search index. This replication ensures that your catalog changes are populated into the HCL Commerce search index in production.

The search index repeater is used as both a master and a subordinate for search replication.

It is used as a subordinate when replicating with the staging search index, where the staging search index is the master and the repeater is the subordinate acting as a backup of the search index for production. After the first replication is completed from staging, the repeater communicates the changes to its subordinate nodes that are in production.

The repeater then becomes the master, where all nodes from the search subordinates are configured to poll changes from the repeater on a regular preconfigured fixed-time interval. This time interval is defined in the solrconfig.xml file under replication.

Replicating between the repeater and all search subordinates in production can be automated, as the indexed data in the repeater always matches the indexed data in production. The search index repeater must be a subordinate to the staging search server and master to the production search server.

Important: The repeater must reside in Production, as it relies on the production database to perform emergency updates.
The indexprop REST API is used to propagate the HCL Commerce Search index:
  • The indexprop RESTful call is used by IT administrators to initiate the search index replication from the staging environment to the repeater, and perform cache invalidation for HCL Commerce Search in production. For more information, see Propagating the HCL Commerce Search index with the repeater.

For more information about the index propagation lifecycle, see Indexing with staging propagation.

For more information about using the indexprop call, see Propagating the HCL Commerce Search index with the repeater.

To run the call to perform replication, use the POST method and basic authentication in the header (spiuser and its password).
 http://search_hostname:search_http_port/search/admin/resources/index/replicate
Where the supported optional parameters are:
indexId
The ID of the master catalog. The default is all.
indexName
The default value is catalog. Permitted values for a standard installation are catalog, inventory, or price, however, you can replicate any core including custom cores by including their name in this parameter. For example, to replicate MyCustomCoreName, simply invoke the command as follows:
 http://search_hostname:search_http_port/search/admin/resources/index/replicate?indexName=MyCustomCoreName
langId
Default is all.
To check the status of replication, use the GET method and basic authentication in the header.
http://search_hostname:search_http_port/search/admin/resources/index/replicate/status?jobStatusId=jobId
The rest response shows the replication status as a number.
  • -1: Job running.
  • -2: Job id not found.
  • 0: Job finished successfully.
  • 1: Job failed.
To check the Search server index version, use the GET method and basic authentication. You can compare the index version numbers of the search master node and repeater node to verify that replication was successful.
http://search_hostname:search_http_port/solr/core_name/replication?command=indexversion
You can obtain core_name from the response to the following REST call. The core_name can be found in the 'name' field in the response. The call uses GET and basic authentication.
http://search_hostname:search_http_port/solr/admin/cores

Troubleshooting

On the Search server, enable "com.ibm.commerce.search.*=all" trace level. The related trace data is available in the trace.log file.