Choose from various mechanisms for upgrading features on the platform.
You can upgrade the features existing on the platform using these mechanisms:
- Use the Update Manager user interface (File -> Application -> Install -> Search for new features to install) to manually install new versions of features.
- Distribute new feature versions through the Composite Application Infrastructure (CAI) and provisioning from the server.
- Distribute new feature versions through the Client Management server.
- Use an alternative management system to provide a provisioning manifest and call the ProvisioningApplication to install new updates.
- Configure the platform to use an automatically scheduled Scan for Updates.
The Scan for Updates mechanism scans the set of update sites defined by features on the platform and the policy, as filtered by the white list processing. You can set preferences so that it looks for updates to existing features on the platform, searches for only new features to install, or searches for both new features and updates to existing features. The set of features located will be proposed as updates to the platform. To configure the platform to scan for updates automatically, use the Automatic Updates preferences page.
For any of the processes outlined above, the updated features will be installed and enabled in the current configuration. According to the setting for the com.ibm.rcp.provisioning/feature.history.size
preference, once a feature with an updated version has been installed and enabled, previous versions can be removed.
Unless the platform provisioning manifest (defined in the rcplauncher.properties and defaulting to the rcp\deploy\install.xml file) is updated to reflect these feature updates, new workspace creation will attempt to use the previously defined feature versions. If these previous feature versions are no longer installed, new workspace creation might fail.
The mergemanifest command of the platform global install handler provides a mechanism for automatically updating the provisioning manifest to stay consistent with the installed features and provides a powerful mechanism for updating the platform. Using the mergemanifest reduces the focus from updating several features, to focusing on the update of one feature, which will then drive the remainder of the feature updates. The following scenario illustrates how the mergemanifest command for the platform global install handler can be used:
- Define a feature called CompanyApplications and give it a version 1.0.0. This feature does not need to contain any plug-ins. Distribute the CompanyApplications feature on an update site.
- Create an update policy XML file on a Web or shared file server that refers all scan for updates to the update site containing only the CompanyApplications feature.
- Customize the initial platform installation to include the CompanyApplications feature.
- Customize the plugin_customization.ini file to include the update policy URL preference and configure the platforms to automatically scan for updates.
- Install the platform, which will now install the CompanyApplications feature. The provisioning manifest will contain the CompanyApplications feature, and, if a new workspace is required to be created, the CompanyApplications feature will be in all platforms.
When there are updates to be applied to the platform, perform the following steps:
- Create a provisioning manifest file that references the new or updated features that need to be distributed to the clients and containing the appropriate mergeaction tags. Include the provisioning manifest file in the feature.
- Create a handler.properties file to contain the mergemanifest command referencing the provisioning manifest included in the feature
- Update the CompanyApplications feature to a new version, such as 1.0.1.
- Distribute the other new or updated features to a second update site. (By using a second update site, the scan for updates will only identify the CompanyApplications feature to be updated, reducing the confusion in the number of features to be distributed).
- Distribute the updated CompanyApplications feature to the update site referenced by the update policy.
As the clients perform their scheduled scan for updates, they will detect the new CompanyApplications feature and propose the installation of the feature. When the feature is installed and enabled, the mergemanifest command will be processed, which results in an update to the provisioning manifest and an update to the provisioning.manifest.version property in the rcplauncher.properties file. On restart of the platform, the platform launcher will detect the difference in the provisioning.manifest.version from its previous setting (compared to the value in the rcpinstall.properties file) and process the contents of the provisioning manifest file. Since new or updated features were merged into the provisioning manifest by the mergemanifest command, the ProvisioningApplication will process those changes, installing or enabling the new or updated features for each workspace.
While this scenario uses the scan for updates, the same basic process can be repeated by distributing the CompanyApplications feature in other ways, such as through the Client Management server or through the Portal server.
The Lotus® Expeditor platform branding feature contains a mergemanifest command for its install handler, referring to a install.xml contained within the branding feature. If the Lotus Expeditor branding feature is installed from an update site, it will merge the contents of the install.xml with the provisioning manifest on the platform.
As the Lotus Expeditor provides future platform upgrades by updating the branding feature on the platform, other updates will automatically be installed using the provisioning manifest.
Parent topic: Deploying features to the platform: XPD621