Overview

A Websphere Commerce runtime installation consists of the base product and one or more instances. The base product is used to define the instance. To apply a maintenance package, you install it on the base product first and then on the instance. This article uses the term maintenance package to refer to both interim fixes (ifixes) and fix packs.

As described in the WebSphere Commerce information center (see Resources), a fix pack is a collection of fixes that you apply to a specific product version or release. Applying fix pack 1 to WebSphere Commerce version 7.0.0.0 changes the version to 7.0.0.1. Fix packs are cumulative. For example, when you install fix pack 2, you get all the fixes that are included in both fix pack 1 and fix pack 2.

Websphere Commerce also publishes ifixes, which are solutions to particular product problems. Each Websphere Commerce ifix contains fixes for one or more APARs. An Authorized Program Analysis Report (APAR) is a formal report to IBM of a problem caused by a suspected defect in a current release of an IBM product. An ifix is made available on the web or through the WebSphere Commerce support team. WebSphere Commerce maintains a list of the latest fixes. Review this list regularly (see Resources).

Feature packs are optional add-on packages that you can install on WebSphere Commerce to apply new functionality to the product. Feature packs do not contain fixes to the base WebSphere Commerce product. Feature packs are cumulative: they include all of the features from previous feature packs.

Back to top

Preparing to install a maintenance package

This section discusses the tools to verify and install a maintenance package.

Installing the latest version of WebSphere Commerce Update Installer

The Websphere Commerce Update Installer (UPDI) is a separate tool that you must install before you can install any maintenance package on Websphere Commerce. APARs are tested with the latest version of UPDI, so ensure that you download the latest version of this tool. You can check the version of the UPDI by viewing the UPDI.product file in the UPDI_Install/properties/version folder. See Resources to download the latest version of UPDI.

Downloading and verifying a maintenance package

You can download ifixes from Fix Central or fix packs from the WebSphere Commerce support portal (see Resources). After you download the media files, always verify that files are not corrupted. You can use MD5 files that come with the download to verify the integrity of a package. Details about how to verify a download package are available in the WebSphere Commerce information center (see Resources).

Back to top

Installing maintenance on the base product

Applying a maintenance package to the base product updates the template files of Java® ARchive (JAR) files in the Websphere Commerce installation directory. Websphere Commerce copies the relevant files from the maintenance package into the installation location. When you patch the base product, any new instances are created at the level of the maintenance package. Updating the base product is simpler than installing maintenance on the instance level, because it does not involve a deployment to the Enterprise Edition Archive (EAR) file, as described in Updating the WebSphere Commerce EAR file.

Some ifixes apply to the base product only, and require no action on the instance. Utilities such as the stagingprop utility and the dataload utility are used by the product as a whole. In general, fixes for such product utilities require changes only to the product and do not apply to the instance.

When you update the base product, all utilities are updated to the latest fix-pack level. Carefully read the readme document that accompanies any ifix before you start the installation.

Back to top

Installing maintenance on the instance

As described in the WebSphere Commerce information center (see Resources), every Websphere Commerce installation requires at least one instance to function. Instance-level installation applies maintenance to existing instances. Before you apply the maintenance package on the instance, you must apply the maintenance package on the base product.

Updating the Websphere Commerce EAR file

The Websphere Commerce artifacts are packaged into a single EAR file that deploys the modules onto the Websphere Application Server. The EAR file contains XML files and descriptors of the module deployment.

Installing the maintenance package onto the instance updates the Websphere Commerce EAR file with the required changes. There are two locations where the Websphere Commerce EAR file can be found:

• Expanded EAR file (runtime location)

  This is a directory (not an EAR file) that contains the expanded copy of the Websphere Commerce application, including the application binaries. At run time, this directory loads WebSphere Commerce application classes and JavaServer Pages (JSP) files. The default location for this EAR file is:

  WASinstallDir/profiles/instance/installedApps/WC_instance_cell/WC_instance.ear

• Master EAR file (collapsed EAR)

  This is a collapsed (compressed) version of the Websphere Commerce application that is used by the Websphere Application Server application management utilities. For example, if you export the application, it is the master EAR file that is returned. This collapsed copy is also used when the application server distributes the application to the nodes that are part of a cluster.

  In a non-clustered environment, the master EAR file is:

  WASinstallDir/profiles/instance/config/cells/WC_instance_cell/applications/WC_instance.ear

  In a clustered environment, the master EAR file is:

  DMGR_WASinstallDir/profiles/instance/config/cells/cell_name/applications/WC_instance.ear

Deploying custom assets

Before you install a maintenance package on the instance, ensure that your custom assets are properly deployed - that the changes you made exist in the master EAR file. During the installation process, the master EAR file is patched with the new files before it is deployed by using WebSphere Application Server deployment tools. If the runtime EAR file in the installedApps folder is different from the master EAR file, you lose any changes that were added manually to the runtime EAR file. The WebSphere Commerce information center describes how to properly deploy custom assets so that you don't lose the changes that you manually added to the runtime EAR file. (See Resources.)

Updating an instance in a stand-alone server versus a cluster environment

In a cluster environment, a deployment manager (DMGR) manages multiple Websphere Application Server nodes running Websphere Commerce. The approach to update a Websphere Commerce instance on a stand-alone application server is slightly different from the approach to update an instance in a cluster environment.

When you install WebSphere Application Server, Network Deployment, two profiles are created:

• A stand-alone application server profile named "default"
• A deployment manager profile named "dmgr"

The deployment manager is an administration application. It runs in a special application server that is created when either:

• You install the WebSphere Application Server, Network Deployment product.
• You create a management profile by using the deployment manager profile template.

With the deployment manager, you can administer multiple Websphere Application Server nodes. The deployment manager profile-configuration files start and manage the deployment manager server. The profile also provides everything necessary to configure and manage the Websphere Application Server profiles, or nodes, that are in the deployment manager cell.

Installing maintenance on a stand-alone server

Figure 1 depicts the process flow when you apply a maintenance package to a stand-alone server:

1. Export the collapsed master EAR file into a temporary directory.
2. Unzip the collapsed master EAR file.
3. Patch the expanded EAR file with the new changes.
4. Zip the patched EAR file into a collapsed EAR file.
5. Copy the updated collapsed EAR file to the master EAR-file location in the folder:
   WAS_Install\profiles\WC_Instance_Name\config\cells\WC_Instance_Name_cell\applications
6. Deploy the master EAR file to the runtime location as an expanded EAR file by using Websphere Application Server deployment tool. The deployment target location is:
   WAS_profileDir/installedApps/WC_instance_cell/
7. Clear the temporary directories.

Installing maintenance on a cluster

The EAR file from the DMGR is the master EAR file for the entire cluster. Apply the maintenance package to the DMGR first, by using the process to install on a stand-alone server. After you update the DMGR EAR file, copy the collapsed EAR file to each node and deploy it to the runtime location as an expanded EAR file. Do this sequentially for each node, until all the node members of this cluster are updated.

Figure 2 depicts the process flow when you apply maintenance to a cluster:

1. Export the collapsed master EAR file on the DMGR into a temporary directory.
2. Unzip the collapsed master EAR file.
3. Patch the expanded EAR file with the new changes.
4. Zip the patched EAR file into a collapsed EAR file.
5. Copy the collapsed EAR file to the master EAR-file location in the DMGR folder:
   DMGR_WAS_Installdir\profiles\WC_Instance_Name\config\cells\WC_Instance_Name_cell\applications
6. Copy the DMGR master EAR file to each node in the cluster.
7. Deploy the master EAR file to runtime location as an expanded EAR file using the Websphere Application Server deployment tool. The deployment target location is:
   WAS_profileDir/installedApps/WC_instance_cell/
8. Clear the temporary directories.

Back to top

Deconstructing instance installation

This section deconstructs the major steps of installing maintenance on the instance to give you a better understanding of the exportEAR, updateDB, and deployEAR processes.

exportEAR

exportEAR is the first step of the installation process. The corresponding xml file, exportEAR.xml, is located in the WC_installdir\config\deployment\xml folder. The exportEAR step copies the master EAR file into the temporary directory. These subtasks run during the export process:

• stopWCApplications - Stop the Commerce application.
• exportWCEar - Export the Commerce instance EAR-file target.
• expandEar - Expand the Commerce instance EAR-file target.
• expandAllRarInEar - Expand all resource adapter archive (RAR) files in the instance EAR-file target.
• expandArchive - Expand the archive file.
• saveBackupInfo - Save the instance backup information.

Listing 1 is a snippet from the exportEar.log which shows the temporary directory being created followed by the exporting of the EAR file to the temporary directory:

exportWCEar:
 
-exportWithSecurity:

-startTime:
     [echo] Target started: 2011.06.27_17.23.48.758
    [mkdir] Created dir: C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\1\wcupdate\WC_demo
  [wsadmin] profileName=demo registry=C:\IBM\WebSphere\AppServer\properties
\profileRegistry.xml
  [wsadmin] profileHome=C:\IBM\WebSphere\AppServer\profiles\demo
  [wsadmin] WASX7209I: Connected to process "server1" on node WC_demo_node using SOAP 
connector;  
The type of process is: UnManagedProcess
  [wsadmin] Exporting WC_demo to C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/1/wcupdate/WC_demo
/temp.ear

updateDB

This step applies only to installing fix packs. The updateDB script allows you to update the database level to the WebSphere Commerce fix-pack level, which is an optional step during the installation process. If you defer this process during installation, you can manually run it later, as described in the WebSphere Commerce information center (see Resources). Make sure you backup the database before you install.

The WC_installdir\components\Fix Pack\xml\configureDatabaseFix Pack.xml file updates the database. The main subtasks are:

ApplyDBFix Pack

• GenerateANTProperties - Generates properties by using the createInstance.properties file.
• checkProperties - Verifies that the required ANT properties are set.
• eCDatabaseVersionInfo - Reads the SITE table to determine the database fix-pack level.

UpdateFix Pack

• RunSQLFile - Executes the SQL statements that are necessary to update the database level.
• UpdateSiteTable - Updates the SITE table to the new database level.

When you update the database during fix pack installation, the updatetrace.txt file contains trace information similar to Listing 2, signifying an updated database level:

******************************************************************************
(Jun 27, 2011 5:45:02 PM), Install, com.ibm.ws.install.ni.ismp.actions.InstallNIFMainten
ance, msg1, Updating component: updatedatabase, percent complete: 8%

(Jun 27, 2011 5:45:02 PM), Install,com.ibm.ws.install.ni.ismp.actions.InstallNIFMainten
ance, msg1, updatedatabase --> Update DB value: true

…

updatedatabase --> Update DB Log location: IBM\WebSphere\CommerceServer70\logs\update
\updatedb-demo.log

(Jun 27, 2011 5:47:02 PM), Install, com.ibm.ws.install.ni.ismp.actions.InstallNIFMainten
ance, msg1, updatedatabase --> Update DB return code: 0

(Jun 27, 2011 5:47:02 PM), Install, com.ibm.ws.install.ni.ismp.actions.InstallNIFMainten
ance, msg1, updatedatabase --> 
 
Successfully applied the update to the database associated with the WebSphere 
Commerce instance, "demo".

******************************************************************************

The SITE table is also updated to reflect the change to the database level. The database level corresponds to the "BASE" COMPNAME in the SITE table. For example, after updating the database level to version 7, fix pack 1, the SITE table looks like Table 1.

If the updateDB step fails, look for errors in these files:

• WC_installdir/instances/instance_name/logs/trace.txt
• WC_installdir/instances/instance_name/logs/messages.txt
• WC_installdir/logs/updatedb.log

deployEAR

The deployEAR step uninstalls the original Websphere Commerce EAR file in the Websphere Application Server and, in its place, installs the newly updated EAR file from the temporary folder. The important subtasks are:

• backupEar - Backs up the patched EAR file.
• collapseEar - Zips the patched EAR file to prepare for deployment.
• deployWCEar - Deploys the collapsed EAR file to the Websphere Application Server.
• setEARPermissions - Sets the correct permissions on the EAR file.
• deleteBackupInfo - Deletes backup information after the deployment succeeds.

Listing 3 is a section of the updatetrace.txt file that shows the deployment step. The log for the EAR file deployment is named deploy_WC_Instance_name.log.

******************************************************************************
(Jun 27, 2011 5:48:07 PM), Install,
com.ibm.ws.install.ni.ismp.actions.InstallNIFMaintenance, 
msg1, Deploying EAR..., 
percent complete: 85%
(Jun 27, 2011 5:48:07 PM), Install, com.ibm.ws.install.ni.ismp.actions.InstallNIFMainten
ance, msg1, deployEAR Package type: install
(Jun 27, 2011 5:48:07 PM), Install, com.ibm.ws.install.ni.ismp.actions.InstallNIFMainten
ance, msg1, 
List of the maintenance packages selected to be installed: 
C:/Program Files/IBM/WebSphere/UpdateInstaller1/maintenance/7.0.0-WS-WCServer-FP003.pak
(Jun 27, 2011 5:48:07 PM), Install, com.ibm.ws.install.ni.ismp.actions.InstallNIFMainten
ance, msg1, 
The current maintenance package to be installed: 
C:/Program Files/IBM/WebSphere/UpdateInstaller1/maintenance/7.0.0-WS-WCServer-FP003.pak
(Jun 27, 2011 5:48:07 PM), Install, com.ibm.ws.install.ni.ismp.actions.InstallNIFMainten
ance,msg1, 
Deploying the WebSphere Commerce instance from 
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\1\wcupdate directory.
(Jun 27, 2011 5:59:41 PM), Install,
com.ibm.ws.install.ni.ismp.actions.InstallNIFMaintenance, msg1, 
Successfully deployed the WebSphere Commerce instance from C:\DOCUME~1\ADMINI~1
\LOCALS~1\Temp\1\wcupdate directory.
******************************************************************************

When the deployment step completes, the temporary directory is cleaned to remove unnecessary files that can interfere with future deployments.

Back to top

Maintence installation reference table

Table 2 lists the steps to apply a maintenance package to an instance in chronological order, along with the relevant log files. You can use this table as a reference when you troubleshoot an installation problem.

Back to top

Maximizing site availability during maintenance installation

When you install a maintenance package on an instance, you bring down the server and the Java virtual machine (JVM) is restarted. For a better customer experience, activate your maintenance page when you install a maintenance package on an instance. It is not necessary to bring down the site to apply a maintenance package on the base product.

Timing the update

You can apply a maintenance package to the WebSphere Commerce product installation directory before your maintenance window. Doing this does not affect the WebSphere Commerce application, and it can free up time for other tasks during your maintenance window. A manual way to minimize downtime is also discussed in the developerWorks article "Tip: Achieving minimal downtime for a WebSphere Commerce application."

Using the roll-out update option

This option provides high availability when you apply an ifix to a Websphere Commerce application that is deployed in a clustered environment. This option is not available for fix packs or feature packs. With the roll-out update option, the DMGR shuts down the server only on the node that is being updated. After the changes are synchronized for the node, the server is restarted. The process is repeated for the remainder of the nodes in the cluster.

This option is available only for ifixes that specify “This fix is roll-out update enabled.” Look for this statement in the readme file that comes with the ifix package. The WebSphere Commerce information center has more detail about the roll-out update option (see Resources).

Back to top

Validating maintenance installation

There are several ways to confirm that you installed a maintenance package correctly.

Using the installation log file

To confirm that an installation was successful, look for this message in the WC_installdir\logs\update\Maintenance_name_.install\updatetrace.txt file:

(Jun 27, 2011 5:10:01 PM), Install, 27, 2011 5:10:01 PM), Install,
com.ibm.ws.install.ni.ismp.actions.InstallNIFMaintenance, msg1, Updating
component: update.base, percent complete: 99%(Jun 27, 2011 5:10:01 PM),
Install, com.ibm.ws.install.ni.ismp.actions.InstallNIFMaintenance, msg1,
Updating component: update.base, percent complete: 100%(Jun 27, 2011
5:10:02 PM), Install,
com.ibm.ws.install.ni.ismp.actions.SettleNIFRegistryAction, msg1, Current
install/uninstall process is successful. Process type is: maintenance(Jun
27, 2011 5:10:02 PM), Install,
com.ibm.ws.install.ni.ismp.actions.SetExitCodeAction, msg1, CWUPI0000I:
EXITCODE=0(Jun 27, 2011 5:10:02 PM), Install,
com.ibm.ws.install.ni.ismp.actions.ISMPLogSuccessMessageAction, msg1,
INSTCONFSUCCESS

Using the COMMERCE.PRODUCT file

You can use the COMMERCE.PRODUCT file to verify that the fix-pack installation was successful. After a fix-pack installation is complete, the COMMERCE.PRODUCT file shows the latest fix pack level. The file is located in different places for the product and the instance:

• Product - WC_installdir/properties/version
• Instance - WC_installdir/instances/instance_name/properties/version

A COMMERCE.PRODUCT file for Websphere Commerce Server version 7 with fix pack 1 looks like Listing 5. If you apply the fix pack to both the product and the instance, the COMMERCE.PRODUCT file in both locations reflects the new fix pack level.

              
            <?xml version="1.0" encoding="UTF-8"?>
            <!DOCTYPE product PUBLIC "productId" "dtd/product.dtd">
            <product name="IBM WebSphere Commerce">
             <id>wc.server.be</id>
             <version>7.0.0.1</version>
             <build-info date="03/05/10" level="100502sup"/>
            </product>

Using the NIFStack.xml file

On a successful installation of a maintenance package, the NIFStack.xml file is updated with the ifix number. The NIFstack.xml file is located in different places for the product and the instance:

• Product - WC_installdir/properties/version/update/backup/NIFStack.xml
• Instance - WC_installdir/instances/instance_name/properties/version/update/backup

If you apply the maintenance package to both the product and the instance, the Nifstack.xml file in both locations is updated to reflect the newly installed maintenance package.

Listing 6 is taken from the NIFstack.xml file after successfully installing ifix 1376.

             
<maintenance name="Interim Fix 1376" order="6"> 
<param name="features" value="commerce;commerceear;configcommon;configmanager;docs;
fep.foundation.70;fep.management-center.70;fep.store-enhancements.70;fep1.primary;
update"/>
<param name="uritoreinstall" value=""/>
<param name="isenablingifix" value="false"/>
<param name="producttype" value="NA"/>
<param name="wasinstalledasmaintenance" value="true"/>
<param name="packagetype" value="NA"/>
<param name="wasinstalledasprimary" value="true"/>
<param name="uninstallablebyupdi" value="true"/>
<param name="filename" value="7.0.0.1-WS-WCServer-IF1376.pak"/>
<param name="info" value="This fix is to resolve NumberFormatException thrown by Cart 
and Product tags."/>
<param name="hasprofileupdates" value="false"/>
<param name="supercedesapars" value=""/>
<param name="supercedes" value=""/>
<param name="builddate" value="2011/02/13"/>
<param name="autouninstallable" value="true"/>
<param name="iscopyjdkrequired" value="false"/>
<param name="isbackuppackage" value="false"/>
<param name="apars" value="JR38884;JR38895;JR37003;"/>
<param name="isofficialfix" value="true"/>
<param name="targetsubproductids" value="wc.server.be;wc.server.pro;wc.server.express"/>
<param name="targetproductids" value="wc.server.be;wc.server.pro;wc.server.express"/>
</maintenance>
            

Back to top

Avoiding common mistakes

The following is a list of some common mistakes made by Websphere Commerce users when installing maintenance packages:

• Not enough space in the temporary directory
  

  Ensure that the temp directory has more than 2 GB of space. On Linux® systems, the temporary directory is /tmp/wcupdate. On Microsoft® Windows® systems, it is Documents and Settings\user_ID\Local Settings\Temp\wcupdate.

• Incorrect user on Linux
  

  Always run UPDI as root user.

• Incorrect permission on UPDI directory
  

  The UPDI directory and its content should have 755 permission and the user's umask should be set to 022.

• Installation fails during the prerequisite check step

There are several possible reasons for installation to fail during the prerequisite check step:

• The maintenance package that you are applying does not match the currently installed Websphere Commerce version.
  

  For example, you are applying an APAR built for Websphere Commerve 7.0.0.5 on a Websphere Commerce 7.0.0.4 installation.

• The maintenance package is corrupted and you need to download the package again.
• The COMMERCE.PRODUCT file in your Websphere Commerce installation is wrong.
  

  It is very common for Websphere Commerce users to deploy the COMMERCE.PRODUCT file from the developer environment into the server environment. When this happens, the <id> tag in the COMMERCE.PRODUCT file contains "wc.toolkit.be" instead of "wc.server.be":

  The installation scripts that apply a runtime ifix onto your server environment first verify the environment type and the version in the COMMERCE.PRODUCT file in the Websphere Commerce installation folder. When the <id> tag refers to a developer environment and not to a server environment, the installation fails with the prerequisite failure message.

  To resolve this error, deploy the correct COMMERCE.PRODUCT file from the Websphere Commerce installation directory (WC_installdir\instance_name\properties\version\) to both the expanded EAR file and the collapsed EAR file in the WebSphere Application Server directory. To do this, use the single-file update option in the WebSphere Application Server console. Otherwise, manual changes are lost during the next deployment operation.

Back to top

Sample troubleshooting case

The first step is to isolate exactly where the failure occurred. You can use the maintenance installation reference table to identify the step where installation failed. Then you can review the relevant log file for the failure message.

In one case, a client reported the error below in the exportEAR.log file when installing an ifix on the instance:

 
               
BUILD FAILED/usr/IBM/WebSphere/CommerceServer70/config/deployment/xml/exportEar.xml:49:
The following error occurred while executing this line:
/usr/IBM/WebSphere/CommerceServer70/config/deployment/xml/exportEar.xml:305:
taskdef class com.ibm.ws.install.ant.tasks.ForEachAntTask cannot be found 

Total time: 23 minutes 57 seconds 

The stack trace lead to this task in the exportEAR.xml file, which matched the error in the logs:

<!-- Expand all RAR files in instance ear target -->
<target name="expandAllRarInEar" depends="initialize">
<antcall target="-startTime"/><taskdef name="foreach"                    
classname="com.ibm.ws.install.ant.tasks.ForEachAntTask" 
classpathref="classpath"/>
<foreach target="expandArchive" propertyName="archiveFile">
<fileset dir="${tempear.path.instance}"><include name="*.rar"/>
</fileset></foreach><antcall target="-finishTime" />
</target>
            

The error message in the log suggests that the class does not exist. The investigation determined that the com.ibm.ws.install.ant.tasks.ForEachAntTask class was located in the update.jar file in the UPDI folder. However, the permissions on the directory that contained the update.jar file did not allow the UPDI user to access that class. Not all problems are this easy to resolve, but the XML files that contain the ANT tasks used in the installation steps provide helpful guidance.

Back to top

Conclusion

This article shows you the behind-the-scene steps involved in installing a maintenance package, both on the Websphere Commerce product and on the instance. It discusses troubleshooting steps and some common mistakes. With a deeper understanding of the installation mechanism, you are better equipped to troubleshoot and resolve installation problems. Most importantly, it is crucial to follow all the steps outlined in the WebSphere Commerce information center when performing an installation.

Back to top

Acknowledgements

The author would like to thank Andres Voldman for his help in reviewing the technical content of the article.

Resources

Learn

• Read and follow the maintenance installation instructions in the WebSphere Commerce information center.
  
  
• Review the WebSphere Commerce recommended fixes and settings.
  
  
• Read how to manually minimize downtime during maintenance installation in "Tip: Achieving minimal downtime for a WebSphere Commerce application" (developerWorks, 2011).
  
  
• Browse for similar articles and resources in the developerWorks® Commerce zone.
  
  
• Stay current with developerWorks technical events and webcasts that focus on a variety of IBM products and IT industry topics.
  
  
• Attend a free developerWorks Live! briefing to get up-to-speed quickly on IBM products and tools as well as IT industry trends.
  
  
• Follow developerWorks on Twitter.
  
  
• Watch developerWorks on-demand demos ranging from product installation and setup demos for beginners, to advanced functionality for experienced developers.
  
  

Get products and technologies

• Download UPDI, the latest version of WebSphere Commerce Update Installer.
  
  
• Download maintenance packages from Fix Central.
  
  
• Download fix packs from the WebSphere Commerce support portal.
  
  
• Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.
  
  

Discuss

• Get involved in the My developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.
  
  

About the author

Salman Khan is a Support Analyst at the IBM Toronto Research Lab, Canada. He has been a member of the Websphere Commerce Support Team for over 3 years and is a subject matter expert on installation and staging components. Prior to his current position, he was part of the Rational Installation team, where he worked on customizing the installation mechanism for Rational products. He graduated from York University with a specialized honours in Computer Science in 2009.

Rate this article

Comments

Back to top

Table of contents

• Overview
• Preparing to install a maintenance package
• Installing maintenance on the base product
• Installing maintenance on the instance
• Deconstructing instance installation
• Maintenance installation reference
• Maximizing site availability
• Validating installation
• Avoiding common mistakes
• Sample troubleshooting case
• Conclusion
• Acknowledgements
• Resources
• About the author
• Comments

Dig deeper into Commerce on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers