Update a Portal Application Archive (PAA) file
Portal v8.5 improves the process of updating PAA file content on the portal server.
Instead of removing and uninstalling the previous version, then installing or deploying an updated version of the PAA file, and possibly breaking existing links between pages or portlets created outside of the PAA file deployment, v8.5 only overwrites resources changed since the new PAA file was released.
Some resource types are difficult to update without removing the existing version and redeploying the new resource. For example, Web Content Manager libraries. In these cases, we must decide whether the library needs to be replaced or whether the existing version is good.
The install-paa-update task...
- Verifies if existing PAA files are installed to the ConfigEngine
- Backs up the current set of files to directory...
profile_dir/paa/backup
- The existing PAA file is removed from the ConfigEngine registry
- Most of the files from the expanded PAA file directory are deleted.
Auto-generated code files are not replaced during this step because the PAA files might be different. Removal tasks are still available to the Solution Installer if called by custom code.
The Solution Installer registers the new PAA file as an update, and records the location of the previous backed up version. This information allows the deploy-paa task to run only update-related tasks and not all the Ant tasks registered for the PAA file.
It would be difficult for the Solution Installer to establish what pieces of the PAA file are deployed as part of the update. The developer is in the best position to provide this input. The Solution Installer does not attempt to generate any default installation code for the update tasks. Instead, when the deploy-paa task detects that a PAA file is an update, it runs only extension point implementation tasks where the suffix is updateSIFeaturePack, rather than applySIFeaturePack. For example, instead of...
deploy-apps-applySIFeaturePack
...the Solution Installer uses...
deploy-apps-updateSIFeaturePack
Any new resources added, for example another ear file created in,...
components/componentName/installableApps/ear
...must be deployed with custom code.
Although these update tasks are not automatically generated, the Solution Installer can automatically register them with the component level sdd.xml. After an extension point implementation task is provided, add your custom code to the PAA file.
The Solution Installer automatically registers the task. For example...
<target name="action-deploy-apps-updateSIFeaturePack-components/componentN"> </target>
In a similar fashion, the rollback of the update with the remove-paa-update task runs the extension points with the rollbackSIFeaturePack suffix. This task removes all the update PAA resources and restore the artifacts from the backup. When complete, the Solution Installer runs any extension point with the rollbackSIFeaturePack suffix.
It is the developers responsibility to generate the tasks that can remove the resources and then deploy the previous versions. The original Ant tasks both custom and auto-generated are available and can be called from the custom Ant tasks. The following is an example of a rollback task:
<target name="action-remove-apps-rollbackSIFeaturePack-components/componentN"> </target>
Tasks with the updateSiFeaturePack and rollbackSIFeaturePack suffix are run only when the PAA file is registered as an update during the install-paa-update task. If the installation is on a fresh system, only the applySIFeaturePack and removeSIFeaturePack extension points are run.