Tips and Tricks around Portal Application Archives

The Portal Application Archive allows to bundle different artifacts into a single package and deploy it. That includes deploying ear files, portlets, running xmlaccess, wsadmin scripts and any ant task. A paa is easy to build since it is a zipped up set of directories - no dedicated packaging utility is required.
The versatility of the paa packaging and ease of build makes it an ideal vehicle to deploy a release - and thinking this further to leverage the paa packaging and deployment for continuous delivery. We have also used the PAA model to package a set of settings and artifacts that all of the Digital Experience servers need - as an initial seeding of the configuration that does not require UI interaction.

In this blog post I will outline a few Tips and Tricks:

How to ensure that the portlets have consistent objectIDs across environments?

When packaging the portlet war files in the installableApps\portlets directory they are automatically deployed but the objectID will be different for each deployment. Instead package the portlet war files into the installableApps\war folder and create a xmlaccess script to deploy the portlets, specifying the objectID. Now that brings up the question how to reference the portlet location from within the xmlaccess script - when placing war files in the installableApps\war folder of the paa they are automatically copied to the installableApps directory of the profile - to reference that you could e.g. use:

Custom files like jython scripts, custom shared libraries or other artifacts can be placed in the components/<component-name>/<customFolder> directory with an arbitrary folder name. To reference the custom files from within ant scripts the reference ${Components/MyPAAHome} where MyPAAHome stands for the name of the component - sample below:

<property name="CustomPath" value="${Components/MyPAAHome}/custom" />

Is it possible to call existing tasks in Digital Experience from within the ant tasks?

The default tasks are implemented in a way that deployments of artifacts to WAS are only implemented on the primary node while file system actions like copying a shared library or synching the applications is executed on the secondary nodes. In case of implementing custom tasks, these can be flagged to only be executed on the primary node by adding the isSecondNode property like in the sample below:

<target name="mysampletask" unless="isSecondNode">
...
</target>

Note that the paa should be installed, deployed on every node/JVM.

How to structure the update of a PAA?

With version 8.5 the update task install-paa-update was introduced. The task adds flexibility in how to handle updates - e.g. which components should be updated. The following document describes details:

Alternatively it is also possible to uninstall the paa and install the new version. This also allows flexibility since the uninstall tasks can be overwritten and e.g. xmlaccess to remove pages not be executed.

In case of a continuous delivery model with e.g. Docker or VMWare images one could reinit those every time and so guarantee a clean install.