Introduced in Feature Pack 3

Setting up a second WebSphere Commerce cell with a shared database

Create a dual cell environment by setting up a second WebSphere Commerce cell and configuring the cell to share the same database as the first cell.

Before you begin

This task assumes that you have an existing WebSphere Commerce cell with a WebSphere Commerce cluster and WebSphere Commerce search cluster. This existing cell is referred to as cell1.
  • Ensure that the following software levels are the same for both cells (cell1 and cell2):
    Software How to verify software version
    WebSphere Application Server Issue the versionInfo command. For example:
    WAS_installdir/bin/versionInfo.sh -long
    WebSphere Commerce fix pack and feature pack Issue the versionInfo command. For example:
    WC_installdir/bin/versionInfo.sh -long
    DB2 Issue the db2level command.
  • Make note of the features that are enabled on cell1. You have to enable the same features on cell2. To see a list of enabled features, run the checkEnablementStatus command on cell1.

Procedure

  1. On the second cell (cell2), install WebSphere Commerce and WebSphere Commerce search like you completed for cell1.
    Note:
    • For information about installing WebSphere Commerce, see Installing WebSphere Commerce.
    • Ensure that you install the same maintenance level (fix pack and feature pack) that is installed on cell1. For more information about installing maintenance, see Installing maintenance for WebSphere Commerce.
    • When you create an instance, ensure that you use the same non-root account that you used in cell1 to create the instance.
    • When you create an instance, a database is also created. Consider this a dummy database. In step 3, you configure cell2 to use cell1's database.
    • Ensure that you use the same security configurations (merchant key and session key) that are used in cell1:
      • You can find the encrypted merchant key in the WC_installdir/instances/cell1_instance_name/cell1_instance_name.xml file.
      • You can find the session key in the WebSphere Application Server Administrative console:
        1. WebSphere Application Server Administrative console, select Environment > Naming > Name space bindings
        2. Choose a search server in the Scope section and select com.ibm.commerce.foundation.server.services.commerce.integration.sessionkey .
        3. Verify that the String value fields are the same in both cells.
        4. Repeat to verify the session keys in all search servers.
  2. Enable the same features on cell2 that are enabled on cell1.
  3. Configure a shared database by changing cell2 database settings to point to cell1's database.
  4. Repeat step 3 on the WebSphere Application Server Administration Console for Solr to update the search data source.
    For example, update the WebSphere Commerce Search DB2 DataSource cell2WCinstance data source.
  5. Copy storefront assets (Stores.war directory) from cell1 to cell2.
    You can copy the Stores.war directory from any node in cell1.
    For example, copy WC_profiledir/installedApps/WC_cell1instance_cell/WC_cell1WCinstance.ear/Stores.war to WC_profiledir/installedApps/WC_cell2instance_cell/WC_cell2WCinstance.ear/
    Note:
    • You might want to use a file transfer protocol such as SCP or SFTP.
    • The Stores.war directory should be owned by the wasuser or non-root user for cell2.
  6. Update cell2 search index by completing one of the following options:
    OptionDescription
    Build the search index by running the following three commands in cell2:
    1. Run the setupSearchIndex utility.
    2. Run the di-preprocess utility.
    3. Run the di-buildindex utility.
    Copy Solr files from cell1 to cell2.
    1. Copy the Solr files from solrhome/MC_catalogId in cell1 to the same location in cell2.
  7. Test the store on both cells by visiting the same store page with different host names.

What to do next

  1. Review the following topics for tips about setting up WebSphere Commerce search and dynamic caching:
  2. Configure the load balancer to allow access to both cells from a single host name, while preserving session affinity.
    Important: If you do not enable session affinity, your shoppers might encounter invalid caches in failover scenarios.