Administer > Stage server > Staging server utilities
stagingprop utility
The stagingprop utility copies data and managed files from the production-ready data to the production server.
You cannot create or update RFQ objects on the staging server.
The stagingprop utility uses the STAGLOG table to identify changed records in the production-ready data and update the corresponding tables in the production database.
After creating the authoring and staging servers, run the stagingcopy utility, before running stagingprop.
To run the stagingprop utility, type the following from a command line on a system that can connect to both the staging server and the production server database.
If the staging server contains either Web activities, or content spots, refresh the registry before any updates display on the site.
To run shell scripts:
- Log on as a user profile that has a CCSID other than 65535.
- Start a Qshell session.
- Run the utility...
WC_INSTALL/bin/stagingprop.sh _all_ -dbtype db_type -sourcedb dbstage -sourcedb_user staging_db_user -sourcedb_passwd staging_dbuser_password -destdb dbprod -destdb_user production_db_user -destdb_passwd production_dbuser_password -log stagingprop_log_file
Utility command
The stagingprop utility has the following file name:
stagingprop.sh
stagingprop.bat
Parameter values
- -dbtype
- Optional: Specify DB2. This is the default database type and you can omit the -dbtype parameter from the command.
- Required: Specify one of the following values:
- DB2/OS400
- Specify DB2/OS400 when using the native i5/OS JDBC driver.
- DB2/OS400ToolBox
- Specify DB2/OS400ToolBox when using the IBM Toolbox for Java JDBC driver.
Required: Specify Oracle.- -scope
- Required: The table scope level for the publication to the production server. Use this parameter to filter the publication by table.
Set one of the following parameters:
- _all_
- Specify _all_ to publish all records.
- Copies both records related to the site and to all merchants.
Records are copied in the following order:
- Site records are copied from STGSITTAB
- Site records are copied from STGMRSTTAB
- Merchant records are copied from STGMERTAB
- Merchant records are copied from STGMRSTTAB
- Site records are copied from STGSITTAB
- _site_
- Specify _site_ to publish only site-related records. This is data that is common to all merchants. For example, the language and country or region code used by the system. This data comes from the STGSITTAB table.
- _merchant_
- Specify _ merchant_ to publish only merchant-related records. For example, store information is customized for individual merchants, and rows from the store tables could be specific for each merchant. Note that copy all data for all merchants, not just data for one individual merchant. This data comes from the STGMERTAB table.
- s
- Specify a custom scope list as defined in the file specified by the -configfile parameter. If you specify a custom scope, specify the -configfile parameter. You can specify multiple scope lists by separating the scope list names with a slash character ("/").
The stagingprop utility follows the order of the database tables in the list or lists provided. When creating the database table lists ensure that any referenced tables appear in the list before the referencing tables.
- -configfile
- The full path to the file containing scope information for the custom scope. For instructions on creating this file, refer to
- Create a database table filter list.
If you do not set the scope to _all_:
- Propagate site data before merchant data, since the site data is used by all merchants. Otherwise, the propagate will fail due to a mismatch between the foreign and primary keys.
- When you use the parameter cleanup_stage_db to clean the site data, merchant data can be deleted because of the cascade delete. You should clean the merchant data followed by the site data then propagate the site data followed by the merchant data.
- -dbtable
- (Deprecated) This parameter is deprecated. Use -scope parameter and specify a custom scope to publish a specific table.
The name of any specific table to be published. All changed records in this table will be published, provided the records are within the scope specified by the -scope parameter; otherwise, no records will be published.
- -sourcedb
- Required: The name of the database on the staging server.
- If the -dbtype parameter is DB2/OS400, specify the name of the database on the staging server, as displayed in the relational database directory.
- If the -dbtype parameter is DB2/OS400ToolBox, specify the host name of the server on which the production-ready data resides.
- If the -dbtype parameter is DB2/OS400, specify the name of the database on the staging server, as displayed in the relational database directory.
- For DB2 UDB databases, the Type 2 database name is deprecated, where the database names do not contain a prefix.
That is, the DB2 Type 4 JDBC driver is used instead, where the Type 4 database name is prefixed with the database server and port. For example, db_server:db_port/db_name.
See the DB2 Information Center for more information:
- -sourcedb_user
- Required: The logon ID of the database schema owner who created either the source or production database schema. If not specified, the ID of the user currently invoking the utility is used.
The user profile associated with the commerce instance.
This is the same as the source database schema.
- -sourcedb_passwd
- Required: The password of the logon ID that is specified by the sourcedb_user parameter.
- -destdb
- Required: The name of the database on the production server.
- If the -dbtype parameter is DB2/OS400, specify the name of the database on the production server, as displayed in the relational database directory.
- If the -dbtype parameter is DB2/OS400ToolBox, specify the host name of the server on which the production database resides.
- If the -dbtype parameter is DB2/OS400, specify the name of the database on the production server, as displayed in the relational database directory.
- For DB2 UDB databases, the Type 2 database name is deprecated, where the database names do not contain a prefix.
That is, the DB2 Type 4 JDBC driver is used instead, where the Type 4 database name is prefixed with the database server and port. For example, db_server:db_port/db_name.
See the DB2 Information Center for more information:
- -destdb_user
- Required: The logon ID of the database schema owner who created either the source or production database schema. If not specified, the ID of the user invoking the utility is used. This parameter is mandatory when using a remote database.
The user profile associated with the commerce instance. This is the same as the production database schema.
- -destdb_passwd
- Required: The password of the logon ID that is specified by the destdb_user parameter. If not specified, the system prompts you to enter the password. This parameter is mandatory when using a remote database.
- -destdb_locktimeout
-
- Optional: Specifies the number seconds the stagingprop utility connection to the production database should wait to obtain a lock on the database it is updating. If the stagingprop utility cannot obtain a lock within the specified number of seconds, the database transaction is rolled back.
Specify a value of zero (0) to have the stagingprop utility wait until it can it obtain a lock on the database record it wants to update.
If you do not specify this parameter, the stagingprop utility waits for the default time set in the database configuration. Contact the database administrator to find out the default lock timeout value.
- Optional: Specifies the number seconds the stagingprop utility connection to the production database should wait to obtain a lock on the database it is updating. If the stagingprop utility cannot obtain a lock within the specified number of seconds, the database transaction is rolled back.
- -transaction
- Optional: Specifies the number of changes that occur before the changes are committed to the production database. If you do not specify this parameter, change logs are committed according to the one action.
- one
- The stagingprop utility runs as a single transaction and is committed only after publication is successful. If the publication fails, the transaction rolls back returning the production database to the state before the stagingprop utility began.
- list
- Changes to the production database are committed after all of the change logs for the list of database tables specified by the -scope parameter have been processed. You must specify the -scope and -configfile parameters to specify this transaction level.
- table
- Changes to the production database are committed after all operations for a production database table have been processed.
- n
- Changes to the production database are committed after every n transactions are processed. If you specify the -batchsize parameter along with this -transaction parameter value, changes to the production database are committed according to a multiple of the -batchsize value that meets or exceeds the -transaction parameter value.
For example, if you specify -transaction 35 and -batchsize 20, changes to the production database are committed every 40 changes. 40 is the closest number of changes that is a multiple of the -batchsize parameter that meets or exceeds the -transaction parameter value. If you specify -transaction 20 and -batchsize 35, changes to the production database are committed every 35 operations.
- -filter
- Optional: Specify the filter mark value to select which records to publish. Use this parameter to file the publication by record.
By default, the -filter option checks for the filter mark value in the STGFILTER column of the STAGLOG table. If you have filter mark values in a different column of the STAGLOG table, use the -filtercolumn option to specify the column in which you have defined the filter mark value.
Filter mark values must be positive integers. Filter marks values of zero or negative integers are reserved for IBM internal use.
WebSphere Commerce does not provide tools to set or validate filter mark values. You must ensure that a set of changes using one filter mark value do not have the same filter mark value as another set of changes.
- -filtercolumn
- Optional: Specifies which column in the STAGLOG table contains the filter mark values. The column specified must have a type of INTEGER.
- -batchsize
- Optional: Turns SQL batch updates on or off and specifies the number of consolidated change log records to include in one SQL batch.
If you do not specify this parameter, the -batchsize parameter is set to a value of 100.
Set the -batchsize parameter to a value of 0 (zero) turns SQL batch update off.
Turn SQL batch off if you are publishing any of the following changes from the production-ready data to the production server:
Using a workspace to delete a WebSphere Commerce object that involve the MEMBER table. This includes objects such as users, organizations, customer segments, member groups, customer territory groups, or customer price groups.
When SQL batch update is turned on, change log records are sorted by change type (insert, update, or delete). Each batch will only contain changes of one type. For example, if you have 102 insert changes and the -batchsize parameter is set to 100, two SQL batches will be created: one batch will have 100 insert operations and the other will have two insert operations.
Use SQL batch updates improves the speed with which the stagingprop utility updates the production database.
- -retry
- Optional: Specify the number of times the stagingprop utility should reattempt a transaction when it encounters a transaction rollback.
- -waittime
- Optional: Specify the number of seconds the stagingprop utility should wait between retry attempts.
- -log
- Optional: The path and name of the file in which the stagingprop utility records its activities and errors. The timestamp might be appended to the file name, for example, myLog_ yyyy.mm.dd_hh.mm.ss.zzz.log.
If this parameter is not specified, a log file called stagingprop_ yyyy.mm.dd_hh.mm.ss.zzz.log is created in the following log directory.
- WC_INSTALL/logs
- WC_USER/instances
- WC_INSTALL\logs
- -waspath
- Optional: This parameter is required for the stagingprop utility to publish managed files to the production server. The parameter has no effect if the stagingprop utility is used only to copy data to the production server.
You must specify this parameter with the -profilename, -appname, and -modulename parameters to publish managed files using the stagingprop utility. If you miss specifying one parameter, managed files are not published by the stagingprop utility.
The full path to the location of the WebSphere Commerce profile. This path will be used to locate the wsadmin.sh or wsadmin.bat file on staging or authoring server.
- -profilename
- Optional: This parameter is required for the stagingprop utility to publish managed files to the production server. The parameter has no effect if the stagingprop utility is used only to copy data to the production server.
You must specify this parameter with the -waspath, -appname, and -modulename parameters to publish managed files using the stagingprop utility. If you miss specifying one parameter, managed files are not published by the stagingprop utility.
The name of the WebSphere Application Server profile on the staging server that contains WebSphere Commerce. By default, the profile name is the same as the WCS instance name. Verify the staging server and the production server are in the same federated environment.
- -appname
- Optional: This parameter is required for the stagingprop utility to publish managed files to the production server. The parameter has no effect if the stagingprop utility is used only to copy data to the production server.
You must specify this parameter with the -waspath, -profilename, and -modulename parameters to publish managed files using the stagingprop utility. If you miss specifying one parameter, managed files are not published by the stagingprop utility.
The value of WC_enterprise_application on the production server.
- -modulename
- Optional: This parameter is required for the stagingprop utility to publish managed files to the production server. The parameter has no effect if the stagingprop utility is used only to copy data to the production server.
You must specify this parameter with the -waspath, -profilename, and -appname parameters to publish managed files using the stagingprop utility. If you miss specifying one parameter, managed files are not published by the stagingprop utility.
The name of the application module to which managed files are copied. This is typically Stores.war.
- -wsadmin_user
- Optional: This parameter is optional when the stagingprop utility publishes managed files to the productions server. The parameter has no effect if the stagingprop utility is used only to copy data to the production server.
A WebSphere Application Server administrative user ID.
This parameter is required if WebSphere Application Server global security is enabled. See the Administrative security topic in the WebSphere Application Server Information Center for more information.
- -wsadmin_passwd
- Optional: This parameter is optional when the stagingprop utility publishes managed files to the productions server. The parameter has no effect if the stagingprop utility is used only to copy data to the production server.
The password for the user ID specified by the wsadmin_user parameter.
This parameter is required if WebSphere Application Server global security is enabled. See the Administrative security topic in the WebSphere Application Server Information Center for more information.
-ILogConfigPath- Optional: This parameter applies only to staging servers configured for ILOG JRules integration.
This parameter is required for the stagingprop utility to propagate ILOG JRules rule data from the staging Rule Execution Server to the production Rule Execution Server. The parameter value is the path where the ILOG JRules configuration property files are stored. This path is the WebSphere Commerce Enterprise Archive for the staging server instance, for example:
/opt/IBM/WebSphere/AppServer/profiles/demo/installedApps/WC_demo_cell/WC_demo.ear
For default paths for various platforms, see WC_EAR.
- Filter data published using the stagingprop utility
Filtering allows to you to selectively publish updates from the production-ready data to the production data. The stagingprop utility allows you filter data by tables, by change record, or a combination of both. - Create a database table filter list
You can specify the -scope parameter of the stagingprop utility so that only data from selected tables is published to the production server. The -scope parameter accepts three predefined table sets - all tables, site data tables only, and merchant data only. You can also specify a custom list of database tables with the -scope and -configfile parameters. - Examples of propagating data to the production database
The following examples illustrate how you propagate changed records from production-ready data to a production database.
Related concepts
Installation overview for WebSphere ILOG JRules as a pricing rule engine with rule management