Portal, V6.1
Manage portlets in your cluster
Because all WebSphere Portal servers in the cluster share the same database, any node can be used to manage portlets. Cluster nodes do not need to be stopped when managing portlets. When you deploy a portlet, WebSphere Portal stores the portlet configuration data in the WebSphere Portal database and then forwards the portlet application's Web module and associated configuration to the deployment manager. The deployment manager is responsible for pushing the Web module to each node in the cluster. Because all WebSphere Portal servers in the cluster share the same database, any node can be used to manage portlets. Cluster nodes do not need to be stopped when managing portlets. The deployed portlets must be activated before they can be used, which cannot be accomplished until the deployment manager has synchronized the associated Web modules to each node in the cluster.
Auto-synchronization of the Web modules to each node in the cluster might not happen immediately, or at all, depending on how the administrator has auto-synchronization configured in the deployment manager. For this reason, WebSphere Portal cannot guarantee that the portlet has been successfully synchronized to each node in the cluster and thus cannot automatically activate the portlet during deployment.
To manage your portlets:
- Deploy your portlets using either the WebSphere Portal Administration page or the XML configuration interface utility (xmlaccess command).
- Run the following task to activate the deployed portlets and to synchronize the changes across all cluster members:
If you run the activate-portlets task while you are logged in to WebSphere Portal, log out and log back in before you can see the updated status for the portlets.
Option Description Windows ConfigEngine.bat activate-portlets task from the WP_PROFILE\ConfigEngine directory UNIXWindows ./ConfigEngine.sh activate-portlets task from the WP_PROFILE/ConfigEngine directory i5/OS ConfigEngine.sh activate-portlets from the... WP_PROFILE/ConfigEngine
...directory where profile_root is the name of the WAS profile where WebSphere Portal is installed; for example, wp_profile
- Use the following information to provide portlets as WSRP services:
By providing a portlet as WSRP service, a Producer makes the deployed portlet available remotely to Consumers. The WebSphere Portal database stores information about whether a portlet deployed in the cluster is provided as a WSRP service. Because the WebSphere Portal database is shared between the nodes in a cluster, all nodes are updated when providing a portlet as a WSRP service.
The URLs of the Producer services definitions in the Web Services Description Language (WSDL) document always automatically point to the Web server performing load balancing in the cluster. This ensures that all requests of Consumers invoking WSRP services of the Producer will be correctly load balanced.
The Producers URLs are generated by first checking the settings of the WSRP SOAP ports, as described in the WSRP documentation. If the SOAP port values are not set, the values of the host.name and host.port properties in ConfigService are used. These values typically point to the load balancing traffic dispatcher. If no values are specified for either the SOAP ports or in ConfigService, the host.name and port of the request used to reference the Producer WSDL document is used.
- Uninstall portlets in a clustered environment the same way as in a stand-alone environment. Because uninstalling the portlet removes the portlet configuration from the databases and all cluster members share the same database the uninstalled portlet will be unavailable to all other members automatically.
Perform the following additional tasks to manage your portlets:
- Portlet deployment
Although portlets are a type of enterprise application, portlet deployment is typically done through WebSphere Portal, or if done directly to WAS, WebSphere Portal has to be notified separately because WebSphere Portal maintains configuration information extracted from the portlet descriptor (portlet.xml) during portlet deployment.- Deploying portlets common to a cluster
You can deploy portlets as a standard EAR through the Deployment Manager and then notify each cluster. A pre-deployed application can only be updated by updating the EAR file in IBM WebSphere Application Server and subsequently updating the contained WAR file by using the XML configuration interface. Cross updates of a pre-deployed EAR file with a real WAR and vice versa are not possible. You can also install it as a standard portlet within one cluster, then map the underlying enterprise application to the other cluster and use the XML configuration interface to notify the other cluster members. For simplicity and ease of administration, common portlet applications should be administered as standard EARs first, so there is no need to remember which cluster owns the original deployment.- Delete portlets common across clusters
Use the XMLAccess task to delete a portlet common across clusters. If the portlet was predeployed as a standard EAR, then each cluster must be first notified of the portlet removal before the EAR can be uninstalled. The administrator must use the XMLAccess application to import a <web-app> definition similar to the ones used in the previous two sections, except the action is to delete the definition instead of update it. For example:<web-app action="delete" active="true" uid="com.ibm.wps.portlets.welcome" />.- Deploying portlets unique to a cluster
You can deploy portlets that are unique to a cluster using the Portal Administration User Interface or the XML Configuration Interface.- Updating portlets common across clusters
Use the Deployment Manager or the XML configuration interface to update portlets. If the portlet was predeployed as a standard EAR, then only the EAR needs to be updated through Deployment Manager and the results synchronized to every cluster to which this application is mapped. If a portlet's configuration is being updated, for instance with new access control definitions or configuration parameter values, then the XML configuration interface must be used to update every cluster's configuration with this same information. In this case you would use an updated <web-app> element.
Parent topic
Manage your cluster