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 you begin, ensure that you have completed the following conditions:
  1. To perform the reindexing directly in production for emergency fixes, the following high-level tasks must be performed:
    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. Ensure a recurring UpdateSearchIndex scheduler command is created. The UpdateSearchIndex job can optionally include the mode parameter, which indicates the type of reindexing to perform. When indicated, the fullBuild job parameter is ignored. The default value is 0, which performs a full reindexing and a delta reindexing.
  2. Cache invalidation can be automatically synchronized 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:
Applying emergency fixes by using Quick Publish

Timeline of events

The following diagram illustrates the timing of events you must consider when indexing with Quick Publish for emergency fixes:
Timeline of events when indexing with Quick Publish for emergency fixes
Where:
  1. A re-index operation is launched when the UpdateSearchIndex scheduler job is started.
  2. Once 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. Once all of the index replications have completed successfully, the scheduler job issues a cache invalidation instruction by inserting into an entry of type restart into the CACHEIVL table, using the start time of the scheduler job as the time to start performing 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 performed.
  2. Once 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 makes the search runtime aware of what products or categories require reindexing.
  4. Once the Quick Publish task is completed and the transaction is committed, the search runtime detects the changes and performs the appropriate reindexing operation in production. This task is performed through a recurring UpdateSearchIndex scheduler command that runs in production.
  5. A manual cache invalidation for the storefront must be performed before the updated changes are visible in production. There is a configurable option in the wc-component.xml file that enables IT administrators 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 performed before the updated changes are visible in production. An automated cache invalidation can be performed using the UpdateSearchIndex scheduler job.