Staging server | How staging server works


Staging server introduction


+

Search Tips   |   Advanced Search


The WebSphere Commerce server application server environment on a staging server is very similar to the production server. The staging server requires exactly the same hardware and software and operating system configuration as the production server. Both the staging and production environments include the WebSphere Application Server, WebSphere Commerce Server, a database server, and a database. The versions of the software and operating systems must also be the same.

These similarities allow a user to test changes on the staging server as though 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.

The staging server consists of the following components:

Tests and modifies your data.

Creates the staging tables and triggers for the staging database. The staging database contains the same schema and tables as the production database, plus a set of triggers to log changes made in the staging database. The staging database schema scripts add triggers to the database. Changes are logged to the STAGLOG table (a staging table) using database triggers. Whenever you change a database table record in the staging database, the STAGLOG table records this change.

Allows an administrator to copy data from the production database to the staging database. You can copy the data into site-related tables, merchant-related tables, or individual tables. The stage copy utility should only be used in specific administrative situations, such as setting up a new staging server or recovery from a corrupt staging server database. An administrator should not make day-to-day changes on the production server or routinely use stage copy to copy the data to the staging server.

Allows an administrator to propagate changes from the staging database to the production database. The information in the STAGLOG table identifies the records in the staging database that must be inserted, updated, or deleted in the production database. The identified records are then updated in the production database. Processed records are indicated in the STAGLOG table by a 1 in the STGPROCESSED column.

Allows an administrator to check for potential unique index key conflicts between two tables on a staging server and a production server.
xxxx