Administer > Stage server

Stage server limitations

You should be aware of certain limitations before using the staging server.

• IBM recommends to use the WebSphere Commerce Accelerator to make changes to the staging database. If you connect to the database directly, you can break some of the limitations required by staging. For example, if you change the category for a catalog entry within WebSphere Commerce Accelerator, first the old relationship will be deleted, and then a new relationship will be inserted. If you connect directly to the database, only an update is performed and the staging server will not find the ID of the record, as it will have changed. Note: You can modify the triggers to perform a delete and insert, however it is not recommended.

• You cannot use the staging server with the buyer organization self-administration features.

• The MEMBER_ID column of all staging tables (excluding MEMBER, MBRREL, MBRROLE, and MBRATTRVAL) must be organizations or member groups, and not users. Users are indicated by a value of U in the type column of the MEMBER table. If the MEMBER_ID references a user in the MEMBER table, stagingcopy may fail. For example, the PARTICIPNT table has a foreign key to the MEMBER table. When creating a contract participant, the value in the MEMBER_ID column in the PARTICIPNT table cannot reference a MEMBER_ID in the MEMBER table that has a value of U in the type column. For more information see Troubleshoot: Staging server.

• For all site tables, the MEMBER_ID must be -2001 or 0. For all tables containing both site and merchant data, the MEMBER_ID for rows related to site data must be 0 or -2001.

• You cannot create or update RFQs on a staging server. If you use RFQs, they must be managed on the production server only.

• You cannot use the stagingcopy utility if you are using RFQ features on the production system. Before you launch the production site, create the staging server and set up production-ready data. Deploy and test the data on the staging server, then propagate to the production server using the stagingprop utility.

• You must manually propagate database schema changes from the staging to the production database. For example, if you create a new index or table in a production-ready data, manually create the index or table in the production database.

• Triggers are not created on all Commerce tables. In specific, the Product Advisor search space tables do not have triggers set up by default. You must configure these triggers manually.

  To see which tables have triggers, issue the following SQL command:

  select DISTINCT(TABNAME) from SYSCAT.TRIGGERS where
  TRIGNAME like 'STAG%' and TRIGSCHEMA='SCHEMA_NAME'
  

  For more information about migrating Product Advisor data from a staging server to a production server see the related topic below.

• The stagingprop utility cannot propagate records loaded by the Loader package (load mode) or the DB2 load utility since both bypass the staging triggers. If you used either utility, use the stagingcopy utility to resynchronize the database tables. You must never use the loading utilities (load mode) or DB2 load utility on a production-ready data or a production database while stagingprop, or stagingcopy is running.

• Do not run the Database Cleanup utility on the staging server except to clean the STAGLOG table.

• To delete a WebSphere Commerce object from the MEMBER table, review the following scenarios:

  • If the deletion is not to be staged, drop the staging triggers before running the deletion. Restore the staging triggers after the deletion is completed.

  • If the deletion is to be staged, complete the following tasks:

    1. Delete all the related record in the child tables of MEMBER.

    2. Delete the MEMBER record.

• If you delete categories on the staging server and to publish these changes to the production server, turn SQL batch update off when running the stagingprop utility. Turn SQL batch updates off by specifying setting the -batchsize parameter to 0.

If the staging server contains Web activities, promotions, or content spots, refresh the registry before any updates display on the site.

Stage database migration

You cannot migrate the staging database. See Create a staging server on a migrated environment for more information.

Key splitting

In general, when a staging server is available, you should only make content data change in the staging server and then propagate the data to the production server. However, there are scenarios when make an update on both the staging server and the production server. For example, in the reseller marketplace, the host (Site Administrator) updates the data on the staging server, while the reseller updates the data on the production server. This potentially causes a primary key collision.

WebSphere Commerce uses a key manager to generate primary keys for tables, and the key range is defined in the KEYS table. If the production server and staging server use the same key range, the key manager can allocate the same primary key value for the same table, on both the production and staging server, causing primary key collision. As a result, the key range must be split immediately after the staging instance and production instance are created. This ensures that the staging server and production server will use different key ranges.

There are different ways to split the key range. One approach is to change the values of the UPPERBOUND, LOWERBOUND, and COUNTER in the KEYS table. The following are sample SQL statements to split the key range on the staging and production servers:

Portion one

update keys set upperbound=(upperbound-lowerbound)/3 + lowerbound
where tablename in (select tabname from stgmertab) or tablename
 in (select tabname from stgsitetab)

Portion two

update keys set upperbound = (upperbound-lowerbound)/3*2 + lowerbound, 
lowerbound = (upperbound-lowerbound)/3 +lowerbound+1, counter = 
counter+(upperbound-lowerbound)/3 +1 where tablename in
 (select tabname from stgmertab)
 or tablename in (select tabname from stgsitetab)

Portion three

update keys set lowerbound = (upperbound-lowerbound)/3*2 + lowerbound +1
, counter = counter +(upperbound-lowerbound)/3*2 +1 where tablename in
(select tabname from stgmertab) or tablename in (select tabname from stgsitetab)

The first SQL statement, portion one, must be run on the production server. This ensures that the production server will occupy one third of the full key range. The second SQL statement, portion two, must be run on the staging server. This means that the staging server will occupy the second one third of the full key range. The third SQL statement, portion three, can be kept for a second potential staging server in the future.

The preceding key splitting SQL statements need to be run manually by the database administrator after the new staging server instance and the production server instance are created.

If key splitting needs to be done after the production server or staging server have been running for some time, then the preceding SQL statements may not work. This is because the current key counter may already be beyond one third of the full key range. If this is the case, check the details of the KEYS table and split the key range properly.

Update primary keys

The stagingprop utility does not support updating primary keys. The primary key of a table can be referenced by other data using either explicit foreign keys or implicit IDs; therefore, changing the primary key has many implications. Database management systems do not allow primary key changes when the primary key is referenced by a foreign key.

To update the primary key, you can delete it or, you can update all child rows in every child table to use another primary key.

Related concepts

Stage server utilities

Related tasks

Test the site on a staging server

+

Search Tips   |   Advanced Search