Administer >


Staging server

  1. Overview
  2. WebSphere Commerce application server environment
  3. Delta data capturing function
  4. Staging server data



Overview

Most online stores operate 24 hours a day, 365 days of the year, making it difficult to perform maintenance or test changes to the system. The staging server allows the Site Administrator to update the data on the staging server and test the changes, and then propagate the change to the production server. This is useful for testing updates to the product catalog, but it is also important for testing new shopping process commands.

The staging server is useful for both technical and business users. For example, technical users can test changes to JSP pages, EJBs and commands, and business users can test new products, prices and product descriptions. Verifying these changes in a test environment ensures that the changes do not cause incorrect or unexpected situations in the production environment. Once tested successfully, the changes can be moved to the production server.


WebSphere Commerce application server environment

WebSphere Commerce on a staging server is very similar to WebSphere Commerce on a production server. The following chart displays which items are similar on each server:

Setup Stage vs Prod
Hardware Same
Software version Same
Operating system version Same
Configuration Same
Nodes Stage has fewer nodes than production

For example, a production environment may have DB, WCS, and HTTP server on three different physical systems. The staging environment can have these three elements on one physical system.

WebSphere Application Server Same
WebSphere Commerce Server Same
Database server Same
Database Same
WCS instance Normally, the staging instance is created on a dedicated system on the 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 using the loading utilities, or publishing a store.

These similarities allow a user to test changes on the staging server as if it were the production server. These tests reassure users that changes that run correctly on the staging server will run correctly on the production server. This is the basic philosophy of the staging server.

Once the testing completes, a user may 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.

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, you should ensure that only the organization owns the operational data, not the individual user, such as a catalog administrator.


Delta data capturing function

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

The delta data capturing 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 capturing and data moving. You must manually copy the non-managed files between the staging server and the production server. Managed files are moved using the fileprop utility. See Copy non-managed files to the production server.

  2. The staging server does not cover all data in the database. It only covers the configuration data, not the operational data.

The data capturing 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, catalog, and so on. Configuration tables containing 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 which 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.


Related concepts

Performance enhancements


Related tasks

Reuse custom staging triggers


+

Search Tips   |   Advanced Search