Indexing without staging propagation

While staging propagation is recommended for WebSphere Commerce search, a Quality Assurance (QA) server can be used for testing and previewing changes in a non-staging environment before propagating to production.

The following diagram depicts how a business user applies changes to a non-staging configuration using a QA server:
QA propagation for the search index

In this flow, a business user applies changes to a QA area, which is later propagated into the production environment by an IT administrator. The following is the high-level process of this flow:

Catalog changes are made in WebSphere Commerce using the Management Center or Data Load utility in a staging or authoring environment. Business users test and preview all the changes in this preproduction environment before publishing it into the production servers. In this scenario, there is a dedicated search index for the QA environment and the delta update procedure for synchronizing the catalog changes is the same as in a non-QA environment.
Once the business user is satisfied with their changes, the data is then released and published into production using your own internal procedures. The TI_DELTA_CATENTRY table must be updated accordingly during data loading to reflect what products have been created, updated, or deleted. This step is required and allows the search runtime to be notified on what products are refreshed in the search index.
When both catalog data and asset files are published to the production system, a delta or full index build is required against the search index repeater. The search index repeater contains a snap shot of the current version of the index in production. Once the first replication is completed from staging, the repeater then communicates the changes to its subordinate nodes that are in production. This approach is similar with the Indexing with staging propagation approach, except that the index is rebuilt in production, rather than replicated from Staging. Search index rebuilding must be launched from the production system either using the UpdateSearchIndex scheduler command, or by directly invoking the buildSearchIndex script from the command line by an IT administrator.
The following considerations must be noted when both catalog data and asset files are published to production:
- The next time the re-indexing scheduler command is run.
- The approximate amount of time that the re-indexing 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.
Cache invalidation for the storefront must be performed before the updated changes are visible in production.
- A manual cache invalidation must be performed.
- An automated cache invalidation can be performed using the indexprop utility and UpdateSearchIndex scheduler job.

Making catalog changes directly onto the production server

It is possible that a WebSphere Commerce platform can be deployed without a staging environment and without a QA server for testing and previewing, with changes instead being made directly into a production environment. Typically this type of deployment configuration can be found in small to medium size Web sites. This configuration, however, while possible, is not recommended.