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
- Delta data capturing function
- Staging server data
- Staging server utilities
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.
There are two types of data: configuration and operation.
Configuration tables contain data such as stores, catalogs, catalog entries, languages, taxes, and discounts. These tables are under Site Administrator control.
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.
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:
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.
The
staging server uses the following utilities:
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.
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.
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.
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.