Load the WebSphere Commerce database schema

Use a script to load the WebSphere Commerce database schema.

Before beginning

Prepare a Db2 database for use with WebSphere Commerce or Prepare an Oracle database.

Task info

This script completes the following tasks:

• Creates the WebSphere Commerce schema including tables, views, and stored procedures in the database.

• Loads bootstrap data.

• Creates two default users in the database.

  wcsadmin

  The site administrator.

  spiuser

  The internal user with the role "RemoteConfigurationReaders". This user is used for inter-component server API invocation only. The spiuser is configured in Store server, Search server and Customization server,and is used in the API invocation from those servers to the Transaction server. This user cannot be disabled otherwise the component servers cannot connect to the Transaction server.

Procedure

1. Log on to the dedicated server hosting the Utility server Docker container. If a Utility server Docker container was not deployed, see Preparing a Docker host server to launch Utility server Docker container.

2. Enter the Utility server Docker container. For example,

   docker exec -it <utility_container_name> bash

3. Go to the /opt/WebSphere/CommerceServer90/bin directory.

4. Create the WebSphere Commerce database schema.

   • (DB2) .\initdb_db2_sample.bat <type> dbNamedbServer dbPort dbaUserdbaPassword dbUser dbPasswordmerchantKey wcsadminSaltwcsadminPassword spiuserSaltspiuserPassword withSamplesslKeyFile sslKeyPassword

   • (Oracle) .\initdb_oracle_sample.bat typedbName dbServer dbPortdbaUser dbaPassword dbUserdbPassword merchantKeywcsadminSalt wcsadminPasswordspiuserSalt spiuserPasswordwithSample sslKeyfilesslKeyPassword

   type

   The type of environment. Valid values are staging or production.

   staging

   Specify this value to enable workspaces. The default workspace number is five. The script create five Read schema and write schema in the database.

   • For more information about Read and Write schema, see Workspaces data model.

   • For more information about workspaces in an authoring environment, see Administering workspaces

   • For more information about workspaces in a WebSphere Commerce Developer environment, see Configure workspaces

   production

   Specify this value if you do not want to enable workspaces and load a schema for production.

   dbName

   The name of the database createdd.

   dbServer

   The database server hostname.

   dbPort

   The database server port.

   dbaUser

   The database administrator username.

   dbaPassword

   The database administrator password.

   dbUser

   The database username. Ensure that we are not using the same username as the database administrator.

   dbPassword

   The database user password.

   merchantKey

   A plain text unencrypted merchant key.

   • A 32 hexadecimal character must be used. Characters can be one of 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b, c, d, e, or f.

   • Must contain a minimum of one alphabetic character.

   • Must contain a minimum of one numeric character.

   • Must be in lowercase.

   • Cannot contain more than 4 identical consecutive characters.

     For example, 1a1a1a1a1a1a1a1a2b2b2b2b2b2b2b2b.

   .

   wcsadminSalt

   Specify a random string to use to encrypt the wcsadminPassword.

   wcsadminPassword

   This script creates a Site Administrator user named wcsadmin. Specify a password for wcsadmin. Use the username wcsadmin and this password to log in to WebSphere Commerce tools such as Management Center, WebSphere Commerce Accelerator, and Administration Console.

   spiuserSalt

   Specify a random string to use to encrypt the spiuserPassword.

   spiuserPassword

   This script creates an SPI user named spiuser. Contact your administrator who prepared the Docker images in our registry. Use the same plain text spiuserPassword that your administrator used when preparing the Docker images. For more information, see Setting the spiuser password in our Docker images.

   This user is used for inter-component server API invocation only. The spiuser is configured in the Store server, Search server and Customization server, and is used in the API invocation from those servers to the Transaction server. This user cannot be disabled, otherwise the component servers cannot connect to the Transaction server.

   withSample

   Determine whether we want to load sample data for the Aurora sample store. Valid values are sampleData or noSample.

   sampleData

   Load sample data for the Aurora sample store. Specify this value to view the Aurora sample store for learning purposes or to use the store as a validation point. At the end of the set up procedure, if we can view a functional store, then the environment installed correctly. If you specify sampleData, sample catalog data and images are loaded into the database. The following sample stores are loaded:

   • ExtendedSitesHub

   • ExtendedSitesCatalogAssetStore

   • AuroraStorefrontAssetStore

   • AuroraESite

   • AuroraB2BStorefrontAssetStore

   • AuroraB2BESite

   noSample

   Do not load any sample data. Specify this value when you will create our own store.

   To learn how to populate our own data, see Creating and configuring our custom store.

   sslKeyFile

   (Optional) If SSL support is configured on the database server, specify the path to the SSL key file. You might want to contact the database administrator to find out whether SSL support is configured.

   For example, to create a staging database and include sample data for the sample Aurora store:

   • (DB2) .\initdb_db2_sample.bat staging mall mydb.ibm.com 50000 db2inst1 db2instpassword wcs wcs1 1a1a1a1a1a1a1a1a2b2b2b2b2b2b2b2b wcsadminSalt1 wcsadminPwd1 spiuserSalt1 passw0rd sampleData opt/utilities/config/keystore.jks ibmkey

   • (Oracle) .\initdb_oracle_sample.bat staging orcl mydb.ibm.com 1521 system manager wcs wcs1 1a1a1a1a1a1a1a1a2b2b2b2b2b2b2b2b wcsadminSalt1 wcsadminPwd1 spiuserSalt1 passw0rd sampleData opt/utilities/config/keystore.jks ibmkey

   Attention: This script takes approximately 30 minutes to complete. If the script fails, we must restore the database before attempting to rerun the command. For more information about how to restore, see RESTORE DATABASE COMMAND for DB2, or for Oracle, Oracle Database 12c Release 2.

5. Change the WebSphere Commerce default merchant key with our own encrypted merchant key.

   1. Run wcs_encrypt.sh to encrypt the plain text merchant key.

      ./wcs_encrypt.sh merchantKey<KeyEncryptionKey>

      merchantKey

      The same plain text unencrypted merchant key that we used when you ran initdb_db2_sample.

      KeyEncryptionKey

      Use the key that exists in the /opt/WebSphere/AppServer/profiles/default/installedApps/localhost/ts.ear/xml/config/KeyEncryptionKey.xml file.

      For example,

      ./wcs_encrypt.sh 1a1a1a1a1a1a1a1a2b2b2b2b2b2b2b2b 1234567890abcdef1234567890abcdef

   2. Copy the ASCII encrypted string and save the string to a file. We will need to specify the encrypted merchant key to start the Transaction server container.

      • If we are using a configuration center such as Consul/Vault to store the environment configurations, save this encrypted string to the MERCHANTKEY_ENCRYPT configuration parameter.

      • If we are starting our Docker containers in a local environment, we can pass the string through command line or define the string in a docker-compose.yml file. For example, for command line:

         docker run -d -e LICENSE=accept -e MERCHANTKEY_ENCRYPT=<ASCII_encrypted_string>

6. (v9.0.0.1) Run the updatedb utility if we are using WebSphere Commerce Version 9.0.0.1 Docker containers.

   You do not have to run the updatedb utility if we are using any other version.

Previous topic: Preparing an Oracle database