Choosing your index model

You have two options for indexing Extended Site (eSite) stores, the legacy eSite Store indexing model, or the Catalog Asset Store (CAS) model. The CAS model is recommended because of its speed and scalability.

In the eSite Store indexing model used before Version 9.1.11, each eSite maintains its own copy of indexable documents (such as catalogs, categories and products). In this model, you build the index separately for each eSite store. This eSite Store indexing model provides advantages by distributing resources, and in the autonomy of each eSite. This approach does not scale to a large number of eSites, however. For this reason, an alternative indexing approach for eSites has been introduced, the Asset Store Index (CAS) model.

If you maintain many eSite stores, the CAS model is the more efficient of the two ways you can index eSites. In the CAS model, shared catalogs, categories and products maintain one copy. You only need to build the index once for all eSite stores.

If you maintain a small set of eSites, or have existing customizations, you can use the eSite Store indexing model that was standard in previous versions of HCL Commerce. Note that you can only use one of the models at a time.

eSite Store indexing

In the eSite Store indexing model, each process stage sends updates for all of its products to Elasticsearch. This approach has some advantages, since any storefront impacts related to search updates are isolated to a single store. It also provides greater search relevancy when overrides and language fallback occur, and it allows each store to scale independently. You may find these features advantageous if you maintain a small set of eSite stores with differing traffic and inventory expectations.

The model comes with certain processing expectations. In the eSite based index design, each eSite retains its own copy of documents (catalogs, categories and products). The index needs to be built for each eSite store. If you have a large number of eSite stores, this design does not scale well.

Asset Store indexing

The main reasons that the CAS model is preferred are:

Scalability: CAS lets you index at the catalog asset store instead of Extended Site level.
Compatibility: The existing Storefront APIs are backward compatible and will generally not affect your existing customizations during upgrades.
Performance: Your existing Storefront APIs should have similar performance when using the CAS indexing model, compared with those using Extended Site indexing model.

The indexing command

For the eSite Store indexing model, the REST endpoint is

POST http://Ingest Server:Ingest Port/connectors/auth.reindex/run?storeId=eSite Store Id

Where eSite Store Id is the numerical ID of an eSite store (1 in the default configuration). If there are more than one eSite stores, you will run this service multiple times, once for each eSite store. For example:

POST http://myingestserver:30800/connectors/auth.reindex/run?storeId=1

The endpoint for the Asset Store indexing process is:

POST http://Ingest Server:Ingest Port/connectors/auth.reindex.cas/run?storeId=Catalog Asset Store Id

Where Catalog Asset Store Id is the numerical ID of a catalog asset store; for example, in the HCL Commerce sample catalogs, you can use 10501 for the Aurora B2B CAS, or 12001 for the Marketplace. This command instructs the system to build indexes for all eSite stores under this catalog asset store. There is only one logical flow to the indexing process regardless of the number of eSites, languages or catalogs. For example:

POST http://myingestserver:30800/connectors/auth.reindex.cas/run?storeId=10501

Activating the CAS Model

eSite indexing is activated by default. If you want to use the CAS model, activate it by setting a flag in the STORECONF database table.

Table 1. STORECONF indexing model
STOREENT_ID	NAME	VALUE
0	`wc.search.CASIndexModel`	`true`

The following SQL can be used to enable CAS models for all stores:

UPDATE STORECONF SET VALUE='true' WHERE name = 'wc.search.CASIndexModel' AND STOREENT_ID = 0;

If the store ID is a catalog asset store ID and the value is true, then all eSite stores under this catalog asset store use the Asset Store model. The store ID must be a catalog asset store ID, or 0 (site level). The NiFi gateway service looks in this table to find out if a store the Asset Store indexing model or not. If the value is true, then the Asset Store model is used; if the value is false or no such row is defined, the eSite indexing model is used.

If the store id is set to 0, all catalog asset stores and the eSite stores under them use the Asset Store model.

Migration and legacy customization support

HCL Commerce Search supports both eSite Store indexing and Asset Store indexing. If you have existing e-Site Ingest and Query customizations that are affected by SQL and index schema changes, you may need to migrate these when switching over to CAS.

A setting in the STORECONF database table controls which index model is used. If you want to continue to use the eSite model (for instance, if you have a large number of existing customizations that assume that model), you can continue to use it. If you want to use the CAS index mode instead, see Configuring Catalog Asset Stores for instructions on how to activate it.

Once the flag is set, rebuild the index, because the schema will have changed. You may need to modify your NiFi customizations based on the new schema, however none of the eSite elements have been removed from the Asset Store schema.

If you have made customizations to the Query service, you may need to make corresponding changes there. There are no Query service API changes, however, Query service version 9.1.11 or later is required.

Restriction: Language fallback is not supported for the CAS model. However, do not disable the language fallback flag when using CAS.

Configuration for indexing inventory for fulfillment center

The ability to switch on or off indexing inventory for all fulfillment centres has been introduced as a new configuration called flow.inventory.indexFulfillmentCenter. Store-level inventory will be indexed together with an inventory of the store's default fulfillment centre if flow.inventory.indexFulfillmentCenter is set to false. Moreover, it will index store-level inventory and the inventory from every fulfillment centre if flow.inventory.indexFulfillmentCenter is set to true.

A PATCH call similar to the one below is used to enable flow.inventory.indexFulfillmentCenter:

http://data-query/search/resources/api/v2/configuration?nodeName=ingest&envType=auth

Where data-query is the address of your data query Docker container.

Method: PATCH

Body:
{
    "global": {
        "connector": [
            {
                "name": "attribute",
                "property": [
                    

{                         "name": "flow.inventory.indexFulfillmentCenter",                         "value": "true"                     }
        
                ]
            }
        ]
    }
}