Intro | Performance considerations


How staging server works


+

Search Tips   |   Advanced Search


The staging server uses the following four utilities.


Staging copy 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 a production database, so that any changes made to the staging database afterwards can be logged and later published to the production database.


Staging check 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).

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

IBM recommends running the stagingcheck utility before publishing data to the production server using the stagingprop utility.


Staging prop utility

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.


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.

The general approach to create a staging server is described below. You can use it as instructions along with the WebSphere Commerce Installation Guide to create a staging server:

  1. Install WebSphere Commerce and its supporting software using the custom installation option of the WebSphere Commerce installation wizard.

  2. Prepare the staging server to connect to the production database:
    • Install a database client suitable for communication with your production database.
    • Catalog the remote production database so that is accessible from your staging server.

  3. Create a new WebSphere Commerce instance:

    • Start the WebSphere Commerce Instance Creation wizard.
    • Complete the pages of the wizard.
    • On the Staging page of the wizard, ensure that you select Use staging server. If you do not select this check box, the resulting WebSphere Commerce instance will be a production WebSphere Commerce instance.
    • Ensure that caching is not enabled in the Cache page. When the instance creation process complete, you will have a staging server instance.

  4. Configure the staging database and the production database for use with the staging utilities.

  5. If you have any custom tables that you want to enable for staging, create triggers for the custom tables.

    Note: The staging server should be run on a separate system or machine partition from your production server.