Updating the instance silently

After you install the WebSphere Commerce maintenance package, use the silent method to update any existing instances to the same maintenance level.

Before you begin

Ensure that you completed the following tasks:

Information about clustered environments

If you are installing a maintenance package to your WebSphere Commerce application, which is deployed to a clustered environment, the maintenance package is installed by using the rollout update process. Rollout update is a means to achieve high availability for clustered environments. Not all nodes in the cluster need to be shut down during the process. The deployment manager chooses one node and stops the server only on that specific node. After the updates for the nodes are synchronized, the server is started again. The process is repeated for each node in the cluster. Whether rollout update is safe to use with a deployment highly depends on the deployment payload and its payload dependencies. During the rollout update process, the cluster is in a state where some nodes are updated, but others are not. Deployment payloads that result in a code mismatch between the client/browser and the WebSphere Commerce server are susceptible to failure or unexpected behavior. Also, consider any database changes that client/browser code depends on. If the client/browser and the server are expecting a change to be present in the database, such as a new command in the CMDREG table, then the database should be updated before any code uses it. Performing rollout update on a test cluster while you access the cluster might help reveal any problems.

Rollout update is automatically enabled for clustered environments. Review the following information:

Ensure that you have the latest version of Update Installer.
Ensure that the WebSphere Commerce application is federated and clustered with two or mode nodes.
Ensure that you test the maintenance package on a non-production environment first.
To avoid save conflicts, ensure that the rollout update is not run at the same time as any other actions that also require an EAR update. For more information, see Troubleshooting: Save conflict error.
The WebSphere Commerce application is active when the maintenance packages are applied. The rollout update runs for a longer time when compared to the regular process of applying fixes. The nodes in the cluster are being updated sequentially rather than in parallel. This means that some nodes in your cluster contain updated code while other nodes do not. Ensure that this condition is feasible for your environment, especially if you are using customized code.

If you do not want to use the rollout update process for your clustered environment, then complete the following steps:

Open the WC_installdir/instances/instance_name/properties/earUpdateControl.properties file.
Edit the earUpdateControl.properties file by setting all values to false instead of true.

Important:

If you have a database performance concern, consider having your database administrator tune the database before the maintenance package update to the WebSphere Commerce instance. If the database is poorly tuned, the update command might run a long time. See your database manual for specifics of tuning the database.
Each new WebSphere Commerce instance that is created after you applied the maintenance package to your WebSphere Commerce installation directory, is created at that specific maintenance level.
If you have multiple WebSphere Commerce instances and you disable rollout update, then you must repeat the installation of the maintenance package for each instance.

About this task

For clustered environments, review the following information:

The WebSphere Commerce application is active when the maintenance packages are applied. The rollout update runs for a longer time when compared to the regular process of applying fixes. The nodes in the cluster are updated sequentially rather than in parallel. This means that some nodes in your cluster contain updated code while other nodes do not. Ensure that this condition is feasible for your environment, especially if you are using customized code.
During the rollout update process, if a lower failover time is required OR if the following message is posted in the browser window:
```
Servlet has become temporarily unavailable for service
```
See the plugin-cfg.xml file and make the following changes to decrease the failover time:
- ServerIOTimeout: Reduce to 30
- ConnectTimeout: Reduce to 15
Also, consider modifying the following properties:
- WebContainer custom property: com.ibm.ws.webcontainer.ServletDestroyWaitTime
- JVM Custom Property: com.ibm.ejs.sm.server.quiesceTimeout
- JVM Custom Property: com.ibm.ejs.sm.server.quiesceInactiveRequestTime
If you see application exceptions in the server logs during the rollout update process, the default 60-second wait time might not be enough. Use the com.ibm.websphere.management.application.updatesync.appExpansionTimeout custom JVM property to increase the wait time.

Procedure

Complete the following steps to install the maintenance package to the WebSphere Commerce instance.

Ensure that you are logged in with a user ID that is a member of the Windows Administration group.
Log on.
- Log on as the root user
  - If you are already signed onto the system, issue the command su - root. Do not use the command su root. This command does not load the necessary root user's profile and environment.
- Or log on as a non-root user that owns WC_installdir.
Ensure that your database server is started.
Ensure that the WebSphere Commerce 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.
Note: During the application of maintenance to the WebSphere Commerce instance, the Update Installer stops the WebSphere Commerce application automatically.
Navigate to the UPDI_installdir/responsefiles directory and open the install.txt file in a text editor.
Note: By default, lines with which you must provide information, start with a hash tag (#) character, such as:
```
#-W update.instancename="instance_name"
```
The hash tag comments out the line. Be sure to remove the hash tags on any lines you change to ensure that they are no longer commented out.
Edit the following lines:
1. Update the -W maintenance.package entry with the directory name that contains the maintenance package.
2. Update the -W product.location entry with the location of the WebSphere Commerce installation directory.
3. Update the -W update.instancename entry with the instance_name.
4. Update the -W update.exportearTimeout entry if needed.
  Optional: The maximum amount of allowable time (in minutes) for the export EAR process, which is exporting the WebSphere Commerce Application, to complete. If the export EAR process takes more than interval minutes, then a timeout error occurs. By default, the interval is set to 240 (minutes) but can be changed to suit your system needs. For example, -W update.exportearTimeout=360 allows for 360 minutes.
Run one of the following commands from the UPDI_installdir directory:
- ./update.sh -options UPDI_installdir/responsefiles/install.txt -silent
- update -options UPDI_installdir/responsefiles/install.txt
- update.bat -options UPDI_installdir/responsefiles/install.txt -silent
When the prompt returns wait for the Java process that is associated with the Update Installer to finish.
Check the log files for errors.
The log files are in the following directories:
- WC_installdir/logs/update
- WC_installdir/logs/update/actions/install
For non-clustered environments, if you have a WebSphere Commerce instance, restart the WebSphere Commerce application.
Check the WC_profiledir/logs/server1/SystemOut.log file to ensure that the database version is at the same level as the EAR version.
For example, search for a message similar to the following message.
```
 0000000a SystemOut O WC.SERVER: Enterprise 8.0.0.X / Database: ENT 8.0.0.X
```
where X is the level of fix pack installed.
This message indicates that the EAR version and database version are the same version. The levels are retrieved from:

EAR

WC_profiledir/installedApps/cell_name/WC_instance_name.ear/properties/version/COMMERCE.product

Database

SITE

If the versions are not the same, contact IBM Support.
If you have both a staging and a production environment, you must perform the steps that are outlined in Step 5 of Installing maintenance package for WebSphere Commerce to ensure that the following actions are completed:
1. All the STAGLOG records that are inserted during maintenance package installation and instance update are deleted from the staging database.
2. If Access Control Policy is in a staging environment, run the stagingcopy utility.
If you encounter problems with stagingcopy, complete the following steps:
1. 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
2. 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
3. Disconnect all users from both staging and production server databases.
4. Run the stagingcopy utility.
Update an alias name in three store JSP files.

Note: This steps is needed only if you installed Mod Pack 3, specifically 8.0.3.0.
If you are upgrading from 8.0.0.x or 8.0.1.x to 8.0.3.0 or later, then update your wc-server.xml file that is in your source code repository.

IBM updated the WC_eardir/xml/config/wc-server.xml file in 8.0.3.0.
Review Installing maintenance: Final steps to complete the installation. You might need to enable some fixes that are included in the maintenance package.