Staging server

The WebSphere Commerce staging server is a part of the production environment where business and technical users can update and manage store data and preview changes. The changes can then be propagated to the production server.

Since online stores can operate 24 hours a day, 365 days of the year, completing maintenance or changes to a site and testing or previewing these changes can be difficult. By using the staging server, business and technical users can work to prepare, update, and preview changes while isolated from the live store or site on the production server. This separation allows users to avoid any impact to customers, such as incorrect information or unexpected behavior while customers are browsing store pages.

For example, business users can use the staging server to complete merchandising or marketing tasks, such as testing the display of new products, prices, and advertisements without affecting the products and pages that customers can view. Technical users, such as developers, can deploy and test changes to JSP pages, EJBs, and commands. After the users verify the changes on the staging server, the changes can be propagated to the production server.

The staging server consists of components that are divided into the following categories:

WebSphere Commerce application server environment

The staging server environment is a replica of the production server environment. These similarities allow a user to test changes on the staging server as if it were the production server. Changes that run correctly on the staging server, run correctly on the production server. The staging server environment can differ from the production server environment in some areas as identified in the following table:

Table 1. Staging server environment

summary for complex table

Setup Staging server Production server
Hardware same same
Software version same same
Operating system version same same
Configuration same same
Nodes The staging server does not have to have the same number of nodes as the production environment. For example, a production environment can have the database on one physical system, the WebSphere Commerce Server on another physical system and the HTTP server on a third system. The staging environment can have these elements on a single physical system. See Delta data capturing function for the reason for this flexibility.
WebSphere Application Server same same
WebSphere Commerce Server same same
Database server same same
Database same same
WebSphere Commerce instance Normally, the staging instance is created on a dedicated system on your network.
Application content Same EAR, WAR, and database schema.
Data content Same JSP pages, HTML pages, Java files, and data in the database.
Function Can perform the same actions on each server such as opening the WebSphere Commerce Accelerator, performing a shopping flow, loading the database with the loading utilities, or publishing a store.

Once the testing completes, a user might want a function to automatically propagate the changes to the production server. The following two sections describe commands that facilitate this automation.

Staging server data

There are two types of data: configuration and operation.

Configuration tables

Configuration tables contain data such as stores, catalogs, catalog entries, languages, taxes, and discounts. These tables are under Site Administrator control.

Operation tables

Operation tables contain data such as customer information, address, and orders data.

The staging server manages only configuration tables. Data in operation tables is not published or copied between the staging and production databases.

Note: It is important to ensure that tables managed by the staging server do not contain any foreign key references to operation tables. Otherwise, the publication could fail due to a potential primary key deletion from the production database. Before you use the staging server, ensure that only the organization owns the operational data, not the individual user, such as a catalog administrator.

Delta data capture function

The staging server uses a delta data capture function to determine which database data changed and needs to be propagated to the production server. This function is used internally by the staging server, and no manual intervention is required. The delta data capture function and its ability to identify changes in the production-ready data is a major advantage over a simple test server.

The delta data capture function does not capture all changed data on the staging server:

  1. The staging server does not cover non-managed files in the delta data capture and data propagation. You must manually copy the non-managed files between the staging server and the production server. Managed files are moved with the fileprop utility. See Copying non-managed files to the production server.
  2. The staging server does not cover all data in the database. It covers the configuration data, not the operational data.

The data capture function consists of two parts, the staging triggers and the STAGLOG table.

Content data is the static data assets that are fully controlled by the administrator, such as currency, language, product, and catalog. Configuration tables that contain the content data are staging-enabled. Three staging triggers are created on each staging-enabled table to capture the INSERT, UPDATE, and DELETE actions on the staging-enabled table.

These staging triggers log the data changes that happen on the staging tables to the STAGLOG table. Changes are written to the STAGLOG table that is read by the stagingprop command. With the information in the STAGLOG, the staging utility command can propagate the delta data from the production-ready data to the production database.