Enabling the Management Center

The Management Center is enabled by default in WebSphere Commerce version 7. If you do not have a feature pack installed, you can disable the Management Center for a specific instance, but once disabled, it cannot be enabled again for that instance. If you disable the Management Center for a specific instance, you must re-create an instance to re-enable it.

Introduced in Feature Pack 1 Once you install a WebSphere Commerce Feature Pack, you must follow these steps to enable the Management Center feature for the Feature Pack you installed. The Management Center feature that is delivered in a Feature Pack can be successfully re-enabled if you disabled it.

Before you begin

To use the Management Center to manage your catalogs, promotions, and marketing, you must first enable the feature. Before you enable the Management Center, complete the following prerequisites:

Review the minimum Hardware prerequisites for installing WebSphere Commerce.
Ensure that your system meets all of the prerequisites for the feature pack.
Review the prerequisite steps in Enabling features.
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. Optionally, 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.
Ensure that the test server is stopped and that Rational Application Developer is not running.
Back up your database:
- Backup overview.
- See the database vendor's user manual for information about backup and restore procedures.
- See the database vendor's user manual for information about backup and restore procedures.
The database updates that are included in this feature cannot be undone. If you want to undo a database update after you enable the Management Center feature, you must restore your database backup.
If you use a staging server, you must ensure that your production server and staging server stay synchronized. To keep them in sync, you must perform the following steps before you enable the feature on the staging server:
1. Optional: It is recommended that you run the stagingprop utility:
  To ensure that stagingprop is run successfully:
  1. Check the stagingprop log file.
  2. Check the STAGLOG table in the staging database and confirm that no unprocessed records exist. An unprocessed STAGLOG record is a record in which the STGPROCESSED column has a value of 0.
2. Stop all activities on the staging server. Any data changes on the staging server are not captured or propagated from this point until feature enablement is completed.
3. Issue the following SQL statement and make note of the number of the latest record in the STAGLOG table in the staging database
```
SELECT MAX(STGRFNBR) FROM STAGLOG
```
If you use a staging server, you must conduct more steps at the end of the procedure to enable the feature. Ensure that you first enable your feature on the staging server, then on the production server.
Determine how you are going to deploy the WebSphere Commerce search server:
In the standard configuration:
- Deploying the WebSphere Commerce search server locally in the standard configuration
- Deploying the WebSphere Commerce search server locally in the standard configuration
In the advanced configuration:
- Federating and clustering the WebSphere Commerce search server in the advanced configuration
- Deploying the WebSphere Commerce search server remotely in the advanced configuration

Procedure

Complete one of the following tasks:
- Log on as a WebSphere Commerce non-root user.
- 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.
Navigate to the following directory:
- WC_installdir/bin
- WCDE_installdir\bin
Run the enablement script:
- ```
config_ant.bat -buildfile WC_installdir/components/common/xml/enableFeature.xml 
-DinstanceName=instance_name -DfeatureName=management-center -DdbUserPassword=db_password 
[-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=management-center -DdbUserPassword=db_password  
[-DSolrWASAdminUser = solr_wasadminuser] [-DSolrWASAdminPassword = solr_wasadminpassword] 
[-Dscchost=HostForScheduledJobs] [search_server_config] 
[-DsearchPort=searchPort]
[-DpasswordFile=passwordFile]
```
- enableFeature.bat -DfeatureName=management-center
Where:

instanceName

The name of the WebSphere Commerce instance with which you are working (for example, demo).

featureName

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

dbUserPassword

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

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.

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
If the script runs successfully in the runtime environment, you see a BUILD SUCCESSFUL message in the command window where you ran the script and a BUILD SUCCESSFUL message in the WC_installdir/instances/instance_name/logs/enablemanagement-center_timestamp.log file.
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:
For enablement details, refer to log file:
- WC_installdir/instances/instance_name/logs/enablemanagement-center_timestamp.log
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\enableFeature.log
Note: The following warning messages in the feature pack enablement log can be safely ignored:
- +++ Warning +++: Tue Mar 10 15:45:50 EDT 2009 java.lang.NoClassDefFoundError: com.ibm.commerce.catalog.facade.CatalogFacade at java.lang.ClassLoader.defineClassImpl(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:258)
- Attribute value cannot be migrated ${parent.width} in file D:\IBM\WCDE_P~1\components\management-center\backup\LOBToolsCustom\WebContent\WEB-INF\src\lzx\commerce\shell\ApplicationMenuItems.lzx Attribute value cannot be migrated ${this.getPromptText(this.parent.parent.promptText)} in file D:\IBM\WCDE_P~1\components\management-center\backup\LOBToolsCustom\WebContent\WEB-INF\src\lzx\commerce\promotion\restricted\objectDefinitions\BasicCodePatternBuilder.lzx Attribute value cannot be migrated ${parent.assetGroup.visible} in file D:\IBM\WCDE_P~1\components\management-center\backup\LOBToolsCustom\WebContent\WEB-INF\src\lzx\commerce\marketing\propertiesViews\WebActivityBuilder.lzx
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.
Republish the application:
1. Open WebSphere Commerce Developer and switch to the Enterprise Explorer view.
  Note: The following warning message in the Problems view can be safely ignored:
```
The source path "/.apt_generated" cannot be resolved
```
2. Right click LOBTools and select OpenLaszlo Migration > Compare Customizations.
3. Rebuild any projects that need to be rebuilt in the workspace.
  For example:
  - Rebuild LOBTools. Right-click LOBTools, then select Build OpenLazlo Project
4. Start the WebSphere Commerce Test Server.
  Some errors are displayed in the console. These errors can be safely ignored.
5. In the Servers view, right-click the test server then click Publish.
6. Wait for the application to finish publishing and to restart. Ensure that no errors are displayed.
7. If you customized a previous version of Management Center, see Migrating Management Center to migrate those customizations to the latest Management Center version.

Optional: If you have a remote web server, propagate your plugin-cfg.xml file to your remote machine.

Option	Description
IBM HTTP Server web server	The plugin-cfg.xml is propagated automatically through the WebSphere Application Server Administrative Console. To set up the automatic propagation of your plugin-cfg.xml file, see Selecting a Web server topology diagram and roadmap . Note: The IBM HTTP Server must be running for auto-propagation to function properly. If you create a userid and password to access your IBM HTTP Server, you must update the web server definition in the WebSphere Application Server Administrative Console with this information. If you do not update the web server definition, auto-propagation fails.
All other web servers	Propagate the plug-in configuration file by manually copying the plugin-cfg.xml file. Copy the file from the `WC_profiledir`/config/cells/`cell_name`/nodes/`node_name`/servers/`web_server_name` directory on your WebSphere Commerce machine, to the Remote Configuration Directory that was specified during the instance creation process.

Option

Description

IBM HTTP Server web server

The plugin-cfg.xml is propagated automatically through the WebSphere Application Server Administrative Console. To set up the automatic propagation of your plugin-cfg.xml file, see Selecting a Web server topology diagram and roadmap .

Note: The IBM HTTP Server must be running for auto-propagation to function properly. If you create a userid and password to access your IBM HTTP Server, you must update the web server definition in the WebSphere Application Server Administrative Console with this information. If you do not update the web server definition, auto-propagation fails.

All other web servers

Propagate the plug-in configuration file by manually copying the plugin-cfg.xml file. Copy the file from the WC_profiledir/config/cells/cell_name/nodes/node_name/servers/web_server_name directory on your WebSphere Commerce machine, to the Remote Configuration Directory that was specified during the instance creation process.

If you are running WebSphere Commerce in a clustered environment or if your server is configured with LDAP server, restart your WebSphere Commerce Server.
Verify that the enablement script ran successfully by accessing this URL: https://host_name:8000/lobtools
If you enabled Management Center successfully, you the Management Center logon screen appears.

If you have both a staging and a production environment, you must perform the following steps:

Option Description

If you are enabling the feature on the staging server

Option	Description
If you are enabling the feature on the staging server	Mark all the STAGLOG records inserted during fix pack installation `UPDATE STAGLOG SET STGPROCESSED=1 where STGRFNBR > lastnum` where `lastnum` is the number of the last record, which was determined in the prerequisite steps required on the staging server. As the database is updated on the staging server, corresponding staging triggers will get fired, and these changes are captured in the STAGLOG table. If this STAGLOG data is not clean up, it will cause duplicate exceptions the next time that stagingprop is run because the production server will have the same data after the fix pack is installed and the production database is updated. Return to Step 1 to enable the feature on the production server.
If you are enabling the feature on the production server	By default Access Control Policy tables are not staged. If you manually added Access Control Policy tables to the staging configuration, you must run the stagingcopy utility. If you encounter problems with stagingcopy, complete the following steps: Update the STMTHEAP database configuration parameter for both staging and production server databases, `db`, to a higher value. For example: `db2 update database configuration for db using stmtheap 240000` Similarly, update the APPLHEAPSZ database configuration parameter for both staging and production server databases, `db`, to a higher value. For example: `db2 update database configuration for db using applheapsz 3000` Disconnect all users from both staging and production server databases. Run the stagingcopy utility.

Mark all the STAGLOG records inserted during fix pack installation
```
UPDATE STAGLOG SET STGPROCESSED=1 where STGRFNBR > lastnum
```
where lastnum is the number of the last record, which was determined in the prerequisite steps required on the staging server.
As the database is updated on the staging server, corresponding staging triggers will get fired, and these changes are captured in the STAGLOG table. If this STAGLOG data is not clean up, it will cause duplicate exceptions the next time that stagingprop is run because the production server will have the same data after the fix pack is installed and the production database is updated.
Return to Step 1 to enable the feature on the production server.

If you are enabling the feature on the production server

By default Access Control Policy tables are not staged. If you manually added Access Control Policy tables to the staging configuration, you must run the stagingcopy utility.

If you encounter problems with stagingcopy, complete the following steps:

Update the STMTHEAP database configuration parameter for both staging and production server databases, db, to a higher value. For example:
db2 update database configuration for db using stmtheap 240000
Similarly, update the APPLHEAPSZ database configuration parameter for both staging and production server databases, db, to a higher value. For example:
db2 update database configuration for db using applheapsz 3000
Disconnect all users from both staging and production server databases.
Run the stagingcopy utility.

Results

Once enabled, you can begin to use the Management Center to manage business operations for your store.

What to do next

First steps after enabling features