Workspaces in WebSphere Commerce Search

Business users work on catalog-related changes in an isolated environment when you work with workspaces in WebSphere Commerce Search. They can then preview their changes in the storefront before you submit them for approval. Content approvers or workspace managers then use the Workspace Management tool in the Management Center to preview a workspace, undo submitted tasks, reject, cancel, or approve task groups. A task group is scheduled for publishing after it is approved.

A separate search index is created for each allocated workspace to preview non-approved changes in a search-based navigation storefront in an authoring environment. This workspace search index has an identical schema structure as the base (also known as approved content) search index. However, the workspace search index contains only non-approved changes for the workspace. The approach is similar to the database-write schema used for each workspace.

When updates are made in a workspace for a product, a search index record copy with the required update is added to the workspace search index. During store preview, the search runtime switches to a workspace index reader capable of overlaying the workspace search index over the approved content search index. Business users then preview non-approved tasks in workspaces. After the task group is approved, the base search index starts reindexing while the workspace index is cleaned to dispose of approved content from the task group. WebSphere Commerce Search utilities work with search indexes and workspace indexes with the following utilities:

Search index setup utility

Configures the Solr cores by creating all core instances for the specified master catalog.

Workspace cores are either created for all available workspaces, including non-allocated workspaces, or only for allocated workspaces.

Search index preprocess utility

Prepares the WebSphere Commerce data for indexing.

Preprocessing targets the search index and workspace index.

Search index build utility

Updates the information in the Master Index using the Data Import Handler (DIH) service to build the index. The index is built either partially through delta index updates, or completely through full index builds.

Index building targets the search index and workspace index.

The Data Import Handler (DIH) accesses the workspace read schema to populate the workspace core. This behavior is configured in the wc-data-config.xml file.

The workspace index reader then combines the results from the workspace core and the production-ready core. This behavior is configured in the solrconfig.xml file.

WebSphere Commerce Search workspaces overall flow

The following list highlights the high-level task flow for working with workspaces in WebSphere Commerce:

1. IT administrators enable workspaces, either with the Configuration Manager or by running the enableContentManagement script, to prime the workspace database schemas.

2. Business users create workspaces in the Workspace Management tool in Management Center.

3. IT administrators build the search cores for the allocated workspace, using the procedure described in Building the WebSphere Commerce Search index. If the authoring environment is clustered, all the search subordinate servers must be updated with the new workspace core.

4. Business users view the workspace index in store preview for viewing unapproved content. A task group is scheduled for publishing after it is approved.

The following list highlights the high-level task flow when WebSphere Commerce Search indexes data for use in store preview:

1. Changes within a workspace task group can be previewed by each business user that uses store preview. Their changes are queued and processed in sequence, with the indexing status shown in the preview window header respective to each user's preview launch request.

2. When business users start store preview, the runtime automatically submits an indexing request to a FIFO queue. Ensure that there is at most one indexing job running at any time.

3. While the indexing job is running in the background, business users can still start store preview. The preview window is not blocked, as the indexing request is queued for processing.

4. The indexing status in the preview window header shows the indexing status for the current preview request. It can be refreshed manually at any time. As the business user refreshes the preview status, the message that is returned tells the user whether the indexing job is complete. After the status indicates complete, the changes within the workspace task group will be visible in the preview session. The background indexing job might still be running, since other requests may be pending at the time when indexing status becomes ready. However, those requests are not related to this current preview session.

5. When you preview non-approved content, only the current supported languages of the current preview store are indexed. Other non-related languages are not changed. After the content is approved, the indexing scheduler job updates all the languages in the system.

WebSphere Commerce Search tasks with workspaces

The tasks that are run when managing search are typically run regularly, or on schedule. They include setting up the WebSphere Commerce Search index structure, preparing your data for indexing by preprocessing, and indexing the data either partially through delta index updates or completely through full index builds. These tasks include extra parameters to support working with the WebSphere Commerce workspace schema. For example:

• The setup search index utility contains parameters to pass DBA user credentials to access the read and write schemas. It also contains a parameter to create cores for all available workspaces, including non-allocated workspaces. See Setting up the search index and Building the WebSphere Commerce Search index.

Synchronizing changes between the base index and workspace index

Temporary database tables are used to detect and synchronize changes between the base index and workspace index. The following temporary database tables store changes waiting to be indexed for each workspace:

• TI_DELTA_CATENTRY

• TI_DELTA_CATGROUP

The following temporary tables store all changed records for each workspace:

• TI_CATENTRY_WS

• TI_CATGROUP_WS

The temporary database tables with _WS are used to track the workspace history. They check the content that is contained in the workspace index and act as an overlay to track the delta changes of the workspace.

Related concepts
WebSphere Commerce Search index schema
WebSphere Commerce Search index schema definition
Temporary table schema definition
Index synchronization and delta updates in WebSphere Commerce Search
Workspace Management tool
Store preview