Indexing with Quick Publish for emergency fixes

When indexing with Quick Publish, emergency fixes are applied directly to the production system by using workspaces, and bypassing staging. Quick Publishing is a two-step procedure, where:

  1. The requested data is put into a production-ready area in an authoring environment.

  2. The data is published directly into the production system.

Note: Workspaces must be enabled in this scenario. Before starting, complete the following actions.

  1. To directly reindex in production, for instance for emergency fixes, perform the following high-level tasks:

    1. Quick Publish must first be configured and working with the production system.

    2. With the search index set-up in production, update the SRCHCONF and SRCHCONFEXT database tables in production to point to the host name and port number of the repeater.Important: The repeater must reside in Production, as it relies on the production database to perform emergency updates.

    3. Set the same namespace binding in WebSphere Application Server for each WebSphere Commerce Production server.

      1. In the WebSphere Application Server administrative console, go to Environments > Naming > Name space bindings > scope:Node=WC_demo_node,Server=server1.

      2. Add the following name-value pair. 

          name: com.ibm.commerce.foundation.server.services.search.indexing.hostname
value: hostname of repeater
name: com.ibm.commerce.foundation.server.services.search.indexing.port
value: search port of repeater

    4. Ensure a recurring UpdateSearchIndex scheduler command is created. The UpdateSearchIndex job can optionally include the mode parameter, which indicates the type of reindexing you should do. When indicated, the fullBuild job parameter is ignored. The default value is 0, which does a full reindexing and a delta reindexing.

  2. We can automatically synchronize cache invalidation using the UpdateSearchIndex scheduler command.

    Ensure that the replication configuration file (solrHome\replication.csv) is updated to match your WebSphere Commerce Search environment:

      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 by the wcs_encrypt utility.

      If application security is not enabled, set this value to null.

  3. The following considerations must be noted when both catalog data and asset files are published to production:

    • The next time the reindexing scheduler command is run.

    • The approximate amount of time that the reindexing might take to complete.

    • The next time replication occurs between the production search index and the repeater.

    • The approximate amount of time that the index replication might take to complete.


Search index flow with Quick Publish and the workspace index for emergency fixes

The following diagram depicts the use of applying an emergency fix by using Quick Publish in an authoring environment and how the search index in production is updated with the workspace index:


Timeline of events

The following diagram illustrates the timing of events we must consider when indexing with Quick Publish for emergency fixes:

Where:

  1. A reindex operation is run when the UpdateSearchIndex scheduler job is started.

  2. After indexing is completed, the index replication begins.

  3. The scheduler then monitors the progress of the index replication on all the search subordinate servers in production.

  4. After all of the index replications are complete, the scheduler job issues a cache invalidation instruction by inserting into an entry of type restart into the CACHEIVL table. This insert is done using the start time of the scheduler job as the time to start cache invalidation.

In this flow, the following high-level steps are involved:

  1. A task group for Quick Publish is created in a workspace environment where all required business operations are done.

  2. After the entire task group is ready for publishing, the approver is notified to preview and approve the content.

  3. When the content is approved in the workspace, a job is submitted to publish the changes to production. A post-publish task is assigned as part of publishing to update the TI_DELTA_CATENTRY and TI_DELTA_CATGROUP tables in production with the corresponding affected catalog changes. This task makes the search runtime aware of what products or categories require reindexing.

  4. After the Quick Publish task is completed and the transaction is committed, the search runtime detects the changes and runs the appropriate reindexing operation in production. This task is run through a recurring UpdateSearchIndex scheduler command that runs in production.

  5. A manual cache invalidation for the storefront must be done before the updated changes are visible in production. We can use a configurable option in the wc-component.xml file to configure a reasonable amount of delay before the cache invalidation is activated. Ensure that the UpdateSearchIndex scheduler command is configured, and then invalidate the storefront cache.

  6. Cache invalidation for the storefront must be done before the updated changes are visible in production. An automated cache invalidation can be run using the UpdateSearchIndex scheduler job.