Portlet deployment in clustered environment

If your WebSphere Portal server is installed on top of WAS ND or WAS XD, which most probably would be the case in non development environment then deployment of portlet would be little different than how you work on DEV environment.

When you deploy portlet on cluster using Portal Admin Console or XMLAccess first changes would be made in the portal database and then the portal server would forward control to Deployment manager which will push changes to all the servers in that portal once the changes are copied to all the nodes the portlet should be activated.

In case of clustered environment follow this procedure for either installing or updating the portal.

1. Deploy your portlets using either the WebSphere Portal Administration page or the XML configuration interface utility (xmlaccess command).


2. Activate the deployed portlets in the cluster by running the "WPSconfig.bat activate-portlets" command. In addition to activating the portlets, this step causes the deployment manager to synchronize the changes across the cluster members.

Second approach of installing portlets would be to first install it as Enterprise application using WAS and then allow DMGR to synchronize changes to all the nodes once that is done then inform Portal server about the portlet using XMLAccess pre deployed command. This approach is useful when you want to combine your portlet with other resources such as EJB, Web Services or other web modules. Follow these steps for deploying portlet

1. Install the EAR through Deployment Manager, using either the Applications > Install New Application option within the Administration Console, or the AdminApp install command within the wsadmin scripting client


2. Map the application to each cluster where it is to run, using either the MapModulesToServers option of the AdminApp install command within the wsadmin scripting client, or the Map modules to servers option under that application’s entry under Applications > Enterprise Applications .


3. Synchronize the new application with each node in all clusters, and start the application in each cluster. By default, synchronization will automatically occur with each node hosting servers and cluster members, or both, to which the enterprise application is mapped.


4. Use the XMLAccess application to import a portlet definition into each portal cluster using the predeployed attribute, where the element of the points to the binaries directory where the portlet application's WAR contents are contained. Choose only one cluster member in a cluster against which to run the XMLAccess import, and as a result all cluster members receive the update.

Manage deployment and removal of portal application

When you deploy a portlet on WPS two things happen first that portlet gets installed as Enterprise application on the underlying WebSphere Application Server and in addition to that WPS reads the portlet.xml and stores the configuration information in the database.

Now there are two different approaches of deploying portlet

1. Deploy portlet using WPS: In this approach you can deploy a portlet through the WPS infrastructure either by using the Manage Web Modules portlet or using XMLAccess script. When you deploy portlet through WPS, it first takes whatever configuration information it needs from the portlet’s WAR file, and then it generates a unique object ID for this portlet. WebSphere Portal then wraps the portlet’s WAR within an EAR definition, giving it a name based on the portlet’s display name, suffixed with the generated object ID. This guarantees that the portlet’s underlying enterprise application name is unique to this portal.



2. Deploy portlet using WAS: Other approach of deploying portlet is first deploying EAR file using WAS Admin Console and then using XMLAccess script to inform WPS about the portlet i.e. activating portlet. This approach is useful if you want your portlet to access an EJB, in that case create EAR file containing EJB and portlet. Or second approach is you want to package more than one portlet applications into one EAR file(might be useful if those applications share some third party jar)