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 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. The repeater must reside in production and rely on the production database for emergency updates.
    3. Run the engine command in the transaction container, for example, in the Docker Compose environment, to set the namespace binding for each HCL Commerce Production server.
      run set-jndi-entry com.ibm.commerce.foundation.server.services.search.indexing.hostname <hostname of repeater>
     run set-jndi-entry com.ibm.commerce.foundation.server.services.search.indexing.port <search port of repeater>
    4. Restart transaction server.
      Note: For Kubernetes environment, a custom image for ts-app must be built with about configuration added.
  2. You can automatically synchronize cache invalidation by using the UpdateSearchIndex scheduler command.
  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 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 by 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. You 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 by using the UpdateSearchIndex scheduler job.