Before using the staging server, you should be aware of the following limitations:
- 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 organization or member groups, and not the user. 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, staging copy 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 Troubleshooting: 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 Stage Copy utility if you are using RFQ features on your production system. Before you launch your production site, create the staging server and set up staging database. Deploy and test your data on the staging server, then propagate to the production server using the Stage Propagate 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 staging database, you must manually create the index or table in the production database.
- The Stage Propagate 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 Stage Copy utility to resynchronize your database tables. You should never use the Loader package (load mode) or DB2 Load on a staging database or a production database while Stage Propagate, Stage Check or Stage Copy is running.
- The staging server does not support DB2 Text Extender.
- Do not run the Database Cleanup utility on the staging server except to clean the STAGLOG table.
Key splitting
In the reseller marketplace, IBM and the Site Administrator update data on the staging server, while resellers update 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.
Currently, WebSphere Commerce uses the following SQL statements to split the key range on the staging and production servers. The SQL statements split the current key range into three equal portions.
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
db2 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
db2 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 above key splitting SQL statements are already integrated with the instance configuration process. You do not need to run them manually.