First steps after creating a custom store

Browsing your newly created custom store

After you have published a store, the new published store can be browsed directly without restarting the transaction server, if the cache invalidation function is enabled. To enable this behavior, update the registry from the Administration Console after the remoteStoreDataload scheduler and DynaCacheInvalidation schedule have completed. The DynaCacheInvalidation schedule has been predefined in scheduler by default. If Kafka is configured to invalidate cache from transaction server to store server, then the store server need not to be restarted. This assumes that no new store assets (such as JSP or XML files) were added during publication of the store. If new store assets were added, then the store server must be restarted .

Publishing your custom store to your runtime production environment

With your custom store created within your development environment, you need to package and deploy your initial store assets to your runtime production environment so that your store is available in that environment.

Unlike in previous versions of HCL Commerce, you do not need to repeat the same store creation process in your runtime production environment that you completed within your development environment. Instead, you need to package and deploy your custom store from your development environment to your runtime production environment.

When you are packaging your newly created store files to initially publish your store, you need to publish all files and assets for your custom store. To ensure that all the required files and paths for your custom store are included when you build your initial custom store Docker image, you need to include both the default published files and any custom files and assets. This combination of assets only needs to be packaged and deployed once to create a custom Docker image in your production environment that includes your custom store. Once you have a custom store available in a Docker image, you only need to package and deploy your custom store files to update your custom store and apply your customizations.

To simplify the files that your need to package to initially create your custom store in your production environment, consider packaging and deploying your newly created custom store before your begin customizing the store.

Packaging and deploying store assets

When your are packaging your initial store files to create your store in your runtime production environment or to later apply customization and configuration changes to the environment, your packaged files need to follow a specific structure. This structure is required so that the default deployment logic can determine how to apply your changes correctly when building a new custom Docker image to use for updating your production environment. The default deployment logic, which is defined with the /SETUP/applyCustomization.sh file is used to parse your custom package for any included files and changes and then apply those changes.

For more information about the required package structure, see Repository structure for building stores (crs) packages.

If you need to package and deploy changes to other server applications, Transaction server (ts-app), Customization server (xc-app), and Search server (search-app), you must structure your repository to package those assets separately from your store assets.

Customizing your store

Enabling and configuring store features

Along with customizing your store pages, you can enable and configure different default provided store functions so that the behavior of these features can better meet your business needs. For instance, you can enable shopper account activation by email,