Create our custom store in your programming environment

We can create our custom store in your Externalized Customization workspace through the configuration and execution of a Gradle script. We can then use your Externalized Customization workspace to customize that store.

Note: We can create custom stores only in your programming environment. After you have created, customized, and tested our custom store, we can deploy it to the authoring or live environment. See the Deployment documentation.

Task info

When you create our custom store by using a Gradle command, all the necessary store files are copied to a new store directory on the Store server from the default sample store pages, based on the specified store type. A new Spring configuration folder is also created for the new store containing the -ext controller and view configuration files. These files are then updated and customized for our individual store as changes are deployed from the Externalized Customization workspace.

This process can be repeated for each store to customize for the WebSphere Commerce service.

Procedure

1. Open the WCDE_installdir/storepublish/gradle.properties file for editing.

2. Update the store publish parameters in the file to override default values during store creation.

   We can add any of the following parameters to further customize the store. For example, we can override default values to create an extended sites store to use an existing catalog asset store. To keep default values, then you do not have to add the parameters. Where:

   dataTemplate

   Indicates which data template file is used by the addStore scheduler job to generate store publish data.

   The default value uses the WCDE_installdir/starterstores/DataTemplate.zip file, which contains the store's sample data. To use our own custom data template file, create the ZIP file in the WCDE_installdir/starterstores directory, and then specify the file name as the parameter value.

   crsCreateESiteStore

   Indicates whether to create extended site store data. Supported values are yes and no.

   If the value is no, we can manually load store data in the proceeding task.

   crsESiteStoreIdentifier

   The name of the store that shoppers access. Avoid spaces and other non-alphanumeric characters in the store name.

   crsESiteStoreDirName

   The name of the store directory.

   crsCreateStoreFrontAssetStore

   Indicates whether to generate data files of a new storefront asset store. Supported values are yes and no.

   Set this value to yes when to create a new storefront asset store that is based on the following two input parameters: crsFrontAssetStoreIdentifier and crsFrontAssetStoreDirName.

   Set this value to no when we want to publish an extended site store that is based on an existing storefront asset store. Then, we must indicate the existing store identifier with crsFrontAssetStoreIdentifier, and indicate the existing store directory name with crsFrontAssetStoreDirName.

   crsFrontAssetStoreIdentifier

   The storefront asset store identifier name.

   crsFrontAssetStoreDirName

   The name of the storefront asset store directory

   crsCreateCatalogAssetStore

   Indicates whether to generate data files of a new catalog asset store. Supported values are yes and no. Set this value to no when you only want to publish a store based on an existing catalog asset store.

   If yes, update crsCatalogStoreIdentifier and crsCatalogStoreDirName.

   If no, update crsCatalogStoreIdentifier, indicating the existing store's directory name to crsCatalogStoreDirName.

   crsCatalogStoreIdentifier

   The catalog asset store identifier name.

   crsCatalogStoreDirName

   The name of the catalog asset store directory.

   crsGenerateSampleData

   Indicates whether to generate sample data for the store, such as sample categories, products, marketing activities, and store locations. Default is yes.

   crsStoreLocale

   This name represents the default store locale for our new created store, only one value can be added here.

   Default is en_US. To create stores for multiple locales, complete this task again and indicate your required locale each time you complete this step. For more information about the supported store locales, see Supporting globalization.

   crsInventoryModel

   This name represents the inventory model for our new created store. The following inventory models are supported:

   Non-ATP

   The non-ATP inventory model supports inventory operations that are only based on existing on-hand inventory.

   ATP

   Use the ATP inventory model, we can allocate stock from existing inventory or backorder from expected inventory. We can also obtain an estimated availability time for each order item after it is added into the shopping cart. The ATP also supports allocating stocks for future order processing.

   DOMInv

   DOM inventory is used for WebSphere Commerce distributed order management integration. For the DOM inventory system, WebSphere Commerce calls outbound services to allocate inventory externally. Integration with Sterling Order Management is based on the DOM inventory model. The DOM inventory system differs from the external inventory model in the following ways:

   • The DOM inventory model supports the local inventory cache in WebSphere Commerce. The external inventory model does not support the use of the local inventory cache.

   • The DOM inventory model uses the new logical schema and outbound service interfaces. The external inventory model uses the legacy inventory outbound service interfaces.

   ExtInv

   External inventory is used to integrate WebSphere Commerce with external inventory systems. External inventory is the legacy inventory implementation model where WebSphere Commerce directly consumes the inventory information from an external system.

   NoInv

   The no inventory model assumes that all products have infinite quantities. When the products in a store are virtual products, digital downloadable products, or electronic assets, such as downloadable images or music, we can use this model.The no inventory model has three typical characteristics that differentiate it from the other inventory models:

   1. All products have unlimited available quantities. Any check of inventory always returns a positive result.

   2. Since all products have infinite available quantities, all order items are successfully allocated after an 'allocate inventory' operation. Specifically, the INVENTORYSTATUS column of the ORDERITEMS table is always set to 'ALLC'.

   3. The No inventory system does not support RTF (Release to Fulfillment), Pick batch, and Ship Confirmation. Order management functions can be supported by custom integration with an existing order management system.

   Default is Non-ATP.

   For more information about inventory models, see Inventory allocation.

   crsStoreType

   Indicates whether the store is a B2C or B2B store. Default is b2c, if not overridden.

   For example, indicate the following values to create a B2B extended site:

   dataTemplate=w:/starterstores/DataTemplate.zip
   crsCreateESiteStore=yes
   crsESiteStoreIdentifier=AuroraB2BEsite
   crsESiteStoreDirName=AuroraB2BEsite
   crsCreateStoreFrontAssetStore=no
   crsFrontAssetStoreIdentifier=AuroraB2BStorefrontAssetStore
   crsFrontAssetStoreDirName=AuroraB2BStorefrontAssetStore
   crsCreateCatalogAssetStore=no
   crsCatalogStoreIdentifier=Extended Sites Catalog Asset Store
   crsCatalogStoreDirName=ExtendedSitesCatalogAssetStore
   crsGenerateSampleData=yes
   crsStoreLocale=en_US
   crsInventoryModel=Non-ATP
   crsStoreType=b2b

3. On your programming environment within the WCDE_installdir/storepublish directory, run the following command to create a store.

   This command creates all the store's front-end assets in your programming environment workspace and generates all the data to create the store in the database.

   • gradlew addStore

   Note: Gradlew looks for the Java runtime among the system environment variables. If you receive an error similar to "Please set the JAVA_HOME variable in the environment to match the location of your Java installation," run WCDE_installdir/bin/setenv.bat, then retry the gradlew command.

Results

The following files and directory structure are created after you run the command:

• New storefront assets, such as JSP files and JavaScript, are saved to the WCDE_installdir/workspace/crs-web/WebContent/StoreFrontAssetDirectoryName directory.

• New catalog assets, such as image files, are saved to the WCDE_installdir/workspace/crs-web/WebContent/CatalogAssetStoreDirectoryName directory.

• All required generated data is saved to the WCDE_installdir/storepublish/generateData directory. In the next task, you populate this data into the database by performing a one-time scheduler job. Then, we can leverage SFTP and the scheduler job to periodically populate the store's data.

Example

Sample usages of the addStore script for creating custom stores
Next topic: Populating the store's bootstrap data into the database