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 machine that can connect to both the
staging server and the production server database.
I5/OS: To run shell scripts:
- Log on as a user profile that has a CCSID other than 65535.
- Open a QSHELL command window by typing the following command on the command line: STRQSH.
- Run the utility as follows: WC_installdir/bin/stagingprop.sh (parameters . . .)
Utility command
The stagingprop utility has the following file name:
AIX|I5/OS|Linux|Solaris|stagingprop.sh
Windows:
stagingprop.bat
Parameter values
- -dbtype
-
(DB2)
AIX|Linux|Solaris|Windows:
(Optional) Specify DB2. This is the default database type and you can omit the -dbtype parameter from the command.
I5/OS|(DB2) (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.
(Oracle) (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.
Specify one of the following:
_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_
- 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 your 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 your scope to _all_:
- Propagate site data before merchant data, since the site data is used by all merchants. Otherwise, your 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.
I5/OS|
- 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 hostname of the server on which the production-ready data resides.
- -sourcedb_user
- (Required) The logon ID of the database administrator who has created
the source database schema. If not specified, the ID of the user currently
invoking the utility is used.
I5/OS|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.
I5/OS|
- 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 hostname of the server on which the production database resides.
- -destdb_user
- (Required) The logon ID of the database administrator who has created
the 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.
I5/OS: 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.
AIX|I5/OS|Linux|Solaris|Windows:
(DB2) -destdb_locktimeout
-
- (Optional) 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.
If you specify the -retry parameter, the transaction will be reattempted the number of times set by the parameter.
If you specify the -transaction parameter, the stagingprop will try the next transaction if it cannot obtain a database lock for the current transaction. If there are no more transactions to process, the stagingprop utility will fail.
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 your database administrator to find out the default lock timeout value.
- (Optional) 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) 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 your 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.
- Deleting catalog categories.
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 -batachsize 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
attempt to retry 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.
AIX|Linux|Solaris|WC_installdir/logs
I5/OS: WC_userdir/instances
Windows:
WC_installdir\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 utilitiy 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 staginprop utility. If you miss specifying one parameter, managed files are not published by the stagingprop utility.
The full path to the location of the wsadmin.sh or wsadmin.bat file on staging or authoring server. These files are usually located in the following directory:
- WC_profiledir/bin
- -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 utilitiy 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 staginprop utility. If you miss specifying one parameter, managed files are not published by the stagingprop utility.
The name of the WAS profile on the production server that contains WebSphere Commerce. By default, the profile name is the same as the WebSphere Commerce instance name.
- -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 utilitiy 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 staginprop 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 utilitiy 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 staginprop 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 usually 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 utilitiy is used only to copy data to the production server.
A WAS administrative user ID.
This parameter is required if WAS global security is enabled. See the Global 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 utilitiy 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 WAS global security is enabled. See the Global security topic in the WebSphere Application Server Information Center for more information.
Related concepts
Related tasks
Filtering data published using the stagingprop utility
Create a database table filter list
Create triggers for custom tables