Feature Pack 4Feature Pack 2Feature Pack 5Feature Pack 3Feature Pack 6

Propagating the WebSphere Commerce search index with the repeater

You can use the indexprop utility to propagate the WebSphere Commerce search index. It issues an HTTP request to the search index repeater to start replicating with the staging search index. This process ensures that your 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. Once 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 index cluster are configured to poll changes from the repeater on a regular pre-configured fixed-time interval. This time interval is defined in the solrconfig.xml file under replication.

Replicating between the repeater and all search index clusters 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.
Feature Pack 6 or laterThe following diagram illustrates the timing of events you must consider when indexing with staging propagation:
Timeline of events when indexing with staging propagation

Before you begin

  • WebSphere Commerce DeveloperEnsure that the test server is stopped and that Rational Application Developer is not running.
  • Ensure that your administrative server is started. For example:
    • If WebSphere Commerce is managed by WebSphere Application Server Deployment Manager (dmgr), start the deployment manager and all node agents. Your cluster can also be started.
    • If WebSphere Commerce is not managed by WebSphere Application Server Deployment Manager (dmgr), start the WebSphere Application Server server1.
  • Complete the following tasks:
  • Feature Pack 6 or laterIf you have enabled global security, ensure that security credentials for replication are set up for all search servers.

Procedure

  1. Complete one of the following tasks:
    • SolarisLinuxAIXLog on as a WebSphere Commerce non-root user.
    • WindowsLog on with a user ID that is a member of the Windows Administration group.
  2. Feature Pack 6 or laterIf you are using the utility to replicate the search index, update the replication configuration file on the staging server to match your WebSphere Commerce search environment:
    1. Open the replication.csv file for editing.

      The default location of the file is solrHome\replication.csv. The replication.csv file should be copied to a location outside the Solr home directory. This avoids replication automatically taking place every time the UpdateSearchIndex scheduler job is run. For example, copy the replication.csv to the WC_installdir/instances/instance_name/search directory. Then pass the -solrHome value when running the indexprop command.

    2. Update the replication configuration file with the following information:
      SearchServerName
      The subordinate server name.
      SearchServerPort
      The subordinate server port.
      CoreName
      The core name to replicate.
      UserName
      The user name for the application security-enabled subordinate server.
      If application security is not enabled, set this value to null.
      Password
      The password for the application security-enabled subordinate server.
      The password must be encrypted using the wcs_encrypt utility.
      If application security is not enabled, set this value to null.
      For more information on how to update the replication configuration file (replication.csv), download and extract the following archive containing sample CSV files:
    3. Ensure that the core to replicate is configured in the solr.xml file on all the search servers.
  3. Feature Pack 4Feature Pack 5Feature Pack 3For a remote search server, copy the solr.xml file from the Solr server solrHome directory to the WebSphere Commerce staging server. For example, WC_installdir/instances/instance_name/search, then pass the -solrHome WC_installdir/instances/instance_name/search parameter in the indexprop utility.
  4. Go to the following directory:
    • SolarisLinuxAIXWC_installdir/bin
    • WebSphere Commerce DeveloperWCDE_installdir\bin
  5. Run the indexprop utility:
    Introduced in Feature Pack 3To run the utility:
    • Windows indexprop.bat -searchServerName searchServerName -searchServerPort searchServerPort -solrHome solrHome
    • SolarisLinuxAIX./indexprop.sh -searchServerName searchServerName -searchServerPort searchServerPort -solrHome solrHome
    • WebSphere Commerce Developerindexprop.bat -searchServerName searchServerName -searchServerPort searchServerPort -solrHome solrHome
    Where:
    searchServerName
    The search repeater server host name.
    searchServerPort
    The search repeater server port.
    SolarisLinuxAIXWindowsThe default value is 3737.
    solrHome
    The location of the Solr home directory path that contains the search index data. The value must be an absolute path. The default value is: WC_installdir/instances/instance_name/search/solr/home
    Feature Pack 6 or laterTo run the utility to perform cache invalidation on the production server, use the replication.csv configuration file and the following syntax:
    • Windows indexprop.bat -solrHome solrHome -masterCatalogId masterCatalogId -instance instance_name -dbuser dbuser -dbuserpwd dbuserpwd [-destdb destdb] [-destdb_user destdb_user] [-destdb_passwd destdb_passwd] [-restartTime restartTime] [-dbtype dbtype] [-destdb_schema destdb_schema] [-destdb_url destdb_url]
    • SolarisLinuxAIX./indexprop.sh -solrHome solrHome -masterCatalogId masterCatalogId -instance instance_name -dbuser dbuser -dbuserpwd dbuserpwd [-destdb destdb] [-destdb_user destdb_user] [-destdb_passwd destdb_passwd] [-restartTime restartTime] [-dbtype dbtype] [-destdb_schema destdb_schema] [-destdb_url destdb_url]
    Where:
    solrHome
    The location of the directory that contains the replication configuration file (replication.csv).
    masterCatalogId
    The ID of the master catalog (for example, 10101).
    instance_name
    The name of the WebSphere Commerce instance with which you are working (for example, demo).
    dbuser

    DB2The name of the user connecting to the database.

    OracleThe user ID connecting to the database.

    dbuserpwd
    The password for the user connecting to the database.
    dbtype
    The production database type to connect to.
    This parameter is required for IBM i when performing cache invalidation on the production server.
    The accepted values are DB2/OS400 or DB2/OS400ToolBox.
    destdb
    The production database name to connect to.
    This parameter is required when performing cache invalidation on the production server.
    If the database type is DB2/OS400, specify the database name of the production server. For example, db_name.
    If the database type is DB2/OS400ToolBox, specify the database host of the production server. For example, db_host.
    If the database type is DB2 or Oracle, specify the database host, database server port, and database name of the production server. For example, db_host:db_port/db_name.
    destdb_user
    The production database user name to connect with.
    This parameter is required when performing cache invalidation on the production server.
    destdb_passwd
    The production database password to connect with.
    This parameter is required when performing cache invalidation on the production server.
    destdb_schema
    The production database schema to connect to.
    This parameter is optional when performing cache invalidation on the production server.
    Oracledestdb_url
    OracleThe production database URL to connect to.
    OracleThis parameter is optional when performing cache invalidation on the production server.
    Note: This parameter is only required for Oracle Real Application Clusters (RAC).
    restartTime
    The restart time to begin invalidating the cache on the production server. That is, the timestamp when the last stagingprop command starts running.
    This parameter is required when performing cache invalidation on the production server.
    Accepted values are long values that return milliseconds in the following format: MM/dd/yyyy_HH:mm:ss.
  6. Ensure that the utility runs successfully.
    Inspect the following log file for errors:
    • SolarisLinuxAIXWindowsWC_installdir\logs\wc-indexprop.log
    To get more logging information, update the logging level from INFO to FINEST in the WC_installdir/instances/instance_name/xml/config/dataimport/indexprop-logging.properties file:
    
# Default global logging level, INFO
.level=FINEST

    After you propagate the WebSphere Commerce search index, you can verify the changes in the storefront.