Propagating the search index

We can propagate the WebSphere 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 the catalog changes are populated into the WebSphere 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 WebSphere 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 WebSphere Commerce Search in production. See Propagating the WebSphere Commerce Search index with the repeater.

If we are using the call to replicate the search index, we must update the replication configuration file (solrHome\replication.csv) on the staging server to match the WebSphere Commerce search environment.

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

For more information about using the indexprop call, see Propagating the WebSphere 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 permitted values are catalog, inventory, or price. The default is catalog.

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. We 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

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.

Related concepts
Indexing contract prices in WebSphere Commerce Search
Indexing with staging propagation
Indexing without staging propagation

Related tasks
Propagating the WebSphere Commerce Search index with the repeater