Staging server

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 WebSphere Commerce 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.

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


 

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 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 may have the database on one physical machine, the WebSphere Commerce Server on another physical machine and the HTTP server on a third machine. The staging environment can have these three elements on one physical machine. See Delta data capturing function for the reason for this flexibility.
Components
WAS same same
WebSphere Commerce Server same same
Database server same same
Database same same
WebSphere Commerce Server instance Normally, the staging server instance is created on a dedicated machine on your network.
Content
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, access control, 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.

 

Staging server utilities

The
staging server uses the following utilities:


 

stagingcopy utility

The stagingcopy utility allows an administrator to copy data from the production database to the production-ready data. You can copy the data into site-related tables, merchant-related tables, or individual tables. After running the stagingcopy utility, the staging database data is aligned with that of the production database, so that any changes made to staging database afterwards, can be logged and later be published to the production database.

The stagingcopy utility differs from the stagingprop utility command in two ways:

The stagingcopy utility should only be used in specific administrative situations, such as setting up a new staging server or synchronizing the configuration data in the staging and production databases.

Do not use stagingcopy often as it does copy all database assets and store file assets are not copied to the staging server.

 

stagingcheck utility

The stagingcheck utility command checks for unique index conflicts between the tables in the production-ready data and the production database. A unique index conflict can occur when content data is changed in the production database instead of the production-ready data. For example, if you create a product on the staging server, then create a different product on the production server, and the two different products have the same product ID.

Run the stagingcheck utility before publishing data to the production server using the stagingprop utility.

Based on the stagingcheck utility report, you can fix you data in the production-ready data manually and then propagate the delta to the production database.

Run this utility before stagingprop utility to find any unique index conflicts. To avoid unique index conflicts, update content data on the staging server only and propagate it to the production server.

If you do not use the stagingcheck utility, key conflicts found when running the stagingprop utility are indicated in the stagingprop log file.

 

stagingprop utility

After creating the authoring and staging servers, run the stagingcopy utility, before running stagingprop.

The stagingprop utility publishes the delta database data from the production-ready data to the production server. It processes each record in the STAGLOG table. The stagingprop utility is the most frequently used of the staging utilities. For example, you may use the stagingprop utility nightly to publish the delta from the production-ready data to the production database.

Processed records are indicated in the STAGLOG table by a 1 in the STGPROCESSED column. These processed records are not deleted and can be used for future analysis or troubleshooting.

Key conflicts found when running the stagingprop utility are indicated in the stagingprop log file.

 

fileprop utility

The fileprop utility publishes managed files from the production-ready data to the WebSphere Commerce EAR file on the production server. Managed files are not copied to the database on the production server.

 

Related Concepts


The stagingcopy utility and the production database
Authoring server
Managed files

 

Related tasks


Testing a site on a staging server
Create a staging server
Create triggers for custom tables

 

Related Reference


Staging server limitations
stagingcopy utility
stagingprop utility
fileprop utility