Enabling content versioning in Management Center

To create versions in Management Center, first enable the Content Versioning feature. Using this feature, you can manage versions of business objects (sales catalog, category, and catalog entry) in WebSphere Commerce environments.

Tip: In runtime environments, only the staging and authoring environments are supported.

When you enable content versioning, the following tables are created in the base schema: CMACTVERSN, CMVERSNCHGLOG, CMVERSNCOLL, CMVERSNCOLLREL, CMVERSNINFO. These tables are also added to the workspace schemas if you have workspaces enabled.

Before you begin

Ensure that you have WebSphere Commerce Version 7 Feature Pack 2 or a later installed.
Ensure that the test server is stopped and that Rational Application Developer is not running.
Ensure that your administrative server is started. For example:
- If WebSphere Commerce is managed by WebSphere Application Server Deployment Manager (dmgr), start the deployment manager and all node agents. Your cluster can also be started.
- If WebSphere Commerce is not managed by WebSphere Application Server Deployment Manager (dmgr), start the WebSphere Application Server server1.

When you enable Content Versioning, the Management Center and Foundation features are also enabled.

Procedure

Complete one of the following tasks:
- Log on as a WebSphere Commerce non-root user (for example, wasuser).
- Log on with a user ID that is a member of the Windows Administration group.
- Log on with a user ID that has *SECOFR authority.
As the WebSphere Commerce non-root user, increase the file handle limit with the following command:
```
ulimit -n 8192
```
Note: You must run the enablement script in the same command window that you ran the ulimit command in. The ulimit setting is lost (and you must rerun this step) when you close this command window.
Navigate to the following directory:
- WC_installdir/bin
- WCDE_installdir\bin
Run the enablement script:
Running the Content Versioning feature enablement script also enables the Management Center feature. That is, if the Management Center feature is disabled, it is enabled after you run the Content Versioning feature enablement script.
- ```
config_ant.bat -buildfile WC_installdir/components/common/xml/enableFeature.xml 
-DinstanceName=instance_name -DfeatureName=content-version -DdbUserPassword=db_password -DdbaPassword=dba_password 
[-DversionSchemaName=custom_versionschema_name] [-DdebugMode=true] 
[-DSolrWASAdminUser = solr_wasadminuser] [-DSolrWASAdminPassword = solr_wasadminpassword]
[-Dscchost=HostForScheduledJobs] [search_server_config] 
[-DsearchPort=searchPort]
[-DpasswordFile=passwordFile]
```
- ```
./config_ant.sh -buildfile WC_installdir/components/common/xml/enableFeature.xml 
-DinstanceName=instance_name -DfeatureName=content-version -DdbUserPassword=db_password -DdbaPassword=dba_password  
[-DversionSchemaName=custom_versionschemaname] [-DdebugMode=true] [-DgenerateSQLStatementsOnly=true] [DgenerateVersionSQLStatementsOutputFile=SQLlog_fullpathname] 
[-DSolrWASAdminUser = solr_wasadminuser] [-DSolrWASAdminPassword = solr_wasadminpassword] 
[search_server_config] [-Dscchost=HostForScheduledJobs]
[-DsearchPort=searchPort]
[-DpasswordFile=passwordFile]
```
- ```
./config_ant.sh -buildfile WC_installdir/components/common/xml/enableFeature.xml 
-DinstanceName=instance_name -DfeatureName=content-version -DdbUserPassword=db_password  
[-DversionSchemaName=custom_versionschemaname] [-DdebugMode=true] [-DgenerateSQLStatementsOnly=true] [DgenerateVersionSQLStatementsOutputFile=SQLlog_fullpathname] 
[-DSolrWASAdminUser = solr_wasadminuser] [-DSolrWASAdminPassword = solr_wasadminpassword] 
[search_server_config] [-Dscchost=HostForScheduledJobs]
[-DsearchPort=searchPort]
[-DpasswordFile=passwordFile]
```
- enableFeature.bat -DfeatureName=content-version [-DdbUserPassword=db_password] -DdbaPassword=dba_password [-DversionSchemaName=custom_versionschemaname] [-DdebugMode=true] [-DgenerateSQLStatementsOnly=true] [DgenerateVersionSQLStatementsOutputFile=SQLlog_fullpathname]
- enableFeature.bat -DfeatureName=content-version -DdbUserPassword=db_password -DdbaPassword=dba_password [-DversionSchemaName=custom_versionschemaname] [-DdebugMode=true] [-DgenerateSQLStatementsOnly=true] [DgenerateVersionSQLStatementsOutputFile=SQLlog_fullpathname]
- enableFeature.bat -DfeatureName=content-version [-DversionSchemaName=custom_versionschemaname] [-DdebugMode=true] [-DgenerateSQLStatementsOnly=true] [DgenerateVersionSQLStatementsOutputFile=SQLlog_fullpathname]
Where:
instanceName

The name of the WebSphere Commerce instance with which you are working (for example, demo).
Note: If you do not include the versionSchemaName parameter, your instance name is used to generate the version schema name. If your instance name includes characters that are invalid for the version schema name, the version schema creation can fail. The version schema name can include only alphanumeric characters and the underscore "_" character. If your instance name includes other special characters, choose a new version schema name that does not include those characters. Include this new name as the value for the versionSchemaName parameter when you enable the content versioning feature.

featureName

The name of the WebSphere Commerce feature to enable (for example, content-version).

dbUserPassword

The password for the user who is connecting to the database.

dbaPassword

The dbaPassword is required when you enable this feature for an instance that uses a database management system that is either DB2 or Oracle.

scchost

The name of the host (server) on which the scheduled job runs. Use this parameter if your organization chooses to schedule jobs to run only on a specific host.
The WebSphere Commerce scheduler runs the RefreshRegistry command to ensure that the latest data from the CMDREG table is used by the WebSphere Commerce CommandRegistry. The job runs only if the CMDREG table was modified. It runs only once, shortly after enablement is completed. By default, this scheduled job run is set to run on any host. If you want to run on a specific host, use this parameter to define the specific host.

versionSchemaName

The name of your version schema. If you do not specify this parameter, the default version schema name (VCW_instance_name) is used.
Note: If the value for instance_name includes characters that are invalid for the version schema name, the version schema creation can fail. The version schema name can include only alphanumeric characters and the underscore "_" character. If your instance name includes other special characters, choose a new version schema name and use this new name as the value for the versionSchemaName parameter.

debugMode
When this parameter is set to true, a trace file generates within the following directory:

WC_installdir/logs

WCDE_installdir\logs
generateSQLStatementsOnly

When this parameter is set to true, SQL statements generate in the log file but the process does not run the SQL statements. The database administrator can manually run the generated SQL statements.
If you set this parameter to true, you can specify the SQL log file location by using the -DgenerateVersionSQLStatementsOutputFile parameter.

passwordFile

Optional: The full path to the password properties file. The properties file can contain encrypted passwords that might be required when running the utility. For example, you can store encrypted database administrator (dbaPassword) or database user (dbUserPassword) passwords. Passwords that are entered on the command line take precedence over the passwords that are in the password file. For more information, see Changing config_ant utility password properties file.
When you run enableFeature.xml, there are two new optional parameters:
```
-DSolrWASAdminUser=solr_wasadminuser -DSolrWASAdminPassword=solr_wasadminpassword
```
Where solr_wasadminuser and solr_wasadminpassword are the WebSphere Administration Server administrative user and password for the Solr cell. These parameters are required only if all three of the following conditions are met:
- You enabled a previous version of Search from an earlier WebSphere Commerce feature pack
- You enabled WebSphere Administration Server administrative security on the Search server
- You are not specifying remoteSearchEngine=true
The search_server_config options help automate updating the web server configuration for IBM HTTP Server. If you do not use this option, you must manually configure your web server after you run the enablement script, as described in the next step. When the search_server_config options are used, WebSphere Commerce search helps automate creating the web server configuration. This automation is achieved by passing in more configuration parameters when you run the enablement scripts.
Important: The automated web server configuration supports IBM HTTP Server (IHS) only. That is, it does not support or include steps for configuring non-IHS web servers such as IIS and SunOne. For other types of web servers, consult the documentation that is provided by the web server vendor to update the configuration.
This approach includes the following considerations:
- The WebSphere Commerce search web server's httpd.conf file is automatically created.
- You can set up a valid configuration where the WebSphere Commerce search and WebSphere Commerce web servers have separate configuration files. That is, you do not need to manually update the plugin-cfg.xml files.
- If preferred, you do not need to install another copy of IBM HTTP Server. The same installation can be shared with the WebSphere Commerce web server.
  A second IHS process is started to handle search HTTP requests that use the same IHS installation. A second process ensures that the configurations do not collide, while it eases configuration and maintenance.
Important: You can skip updating the web server configuration if you previously enabled the feature foundation and passed in the search_server_config parameters during the enablement. You can also skip the update if your Solr web server is already configured.
The following list shows the available parameters with brief explanations of each. Examples can be seen in the following task, along with more-detailed descriptions of each parameter and when it is needed and not needed:
- ../../com.ibm.commerce.component-services.doc/tasks/../../com.ibm.commerce.developer.doc/tasks/tsdsearchwebserver.html
The scripts validate the values that are provided for any mandatory parameters. If values for mandatory parameters are blank, the scripts do not proceed. The error message indicates which values must be specified. An example of such an error can be viewed in the following troubleshooting reference:
- Troubleshooting: Ant properties error occurs during feature enablement
Where search_server_config includes the following parameters that help automate updating the web server configuration for IBM HTTP Server:
searchPort

The WebSphere Application Server virtual host port number to listen on for the WebSphere Commerce search application.

The value must be a valid and available TCP port.

The default value is 3737.
After the enablement script run is complete, the following log file is generated:
- WC_installdir/logs/Create_version_db_instance_name.sql.log
- WCDE_installdir\logs\Create_version_db_demo.sql.log
The database administrator can review the SQL statements that are generated in the log file.
Configure the Web server for the Solr application
The following configuration options are available, depending on your web server and WebSphere Commerce Feature Pack version:
- WebSphere Commerce search deployment tasks include steps to manually update the web server configuration for IBM HTTP Server (IHS).
  This approach includes the following considerations:
  
  You created the WebSphere Commerce search web server httpd.conf file.
  
  A directive to listen on the search virtual host port is added.
  
  The web server plug-in is installed on the web server host.
- WebSphere Commerce search deployment tasks include steps to help automate updating the web server configuration when you use IBM HTTP Server (IHS). This automation is achieved by optionally passing in more configuration parameters when you are running the enablement scripts during the previous step. For more information, see the previous step.
- For configuring non-IHS web servers such as IIS and SunOne, consult the provided documentation to update the configuration.
If the script runs successfully in the runtime environment, a BUILD SUCCESSFUL message appears in the command window where you ran the script and in the WC_installdir/instances/instance_name/logs/enablecontent-version_timestamp.log file.
If the script runs successfully in the development toolkit, you see an enableFeature.bat completed message in the command window where you ran the script. For enablement details, refer to log file:
- WCDE_installdir\logs\enablecontent-version_timestamp.log
- WCDE_installdir\logs\enableFeature.log
If you specified the -debug parameter in the previous step, an extra log file is generated:
- WC_installdir/logs/Application.version.enablement.messages_timestamp.log
- WCDE_installdir\logs\Application.version.enablement.messages_timestamp.log
Republish the application:
1. Open WebSphere Commerce Developer and switch to the Enterprise Explorer view.
2. Right-click LOBTools and select:
  - OpenLaszlo Migration > Compare Customizations
    Tip: The Compare Customizations window opens in the upper right corner. To view the contents more easily, hold and drag the title bar and move it to the bottom window.
  - OpenLaszlo Migration > Launch Migration Tool

Results

After you enable Content Versioning, you can begin to use the Management Center to manage versions of business objects.

What to do next

First steps after enabling features
Perform one of the following tasks:
- Working with content versioning.
- Customizing content versioning.