+

Search Tips   |   Advanced Search

Manage portlets 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. 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 dmgr. The dmgr is responsible for pushing the Web module to each node in the cluster.

The deployed portlets must be activated before they can be used, which cannot be accomplished until the dmgr 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 dmgr. 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.


Manage the portlets

  1. Deploy the portlets using either the WebSphere Portal Administration page or xmlaccess.sh utility .

  2. To activate deployed portlets and to synchronize the changes across all cluster members:

    If you run the activate-portlets task while we are logged in to WebSphere Portal, you must log out and log back in before we can see the updated status for the portlets.

      cd $WP_PROFILE/ConfigEngine
      ./ConfigEngine.sh activate-portlets -DWasPassword=foo task

  3. 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 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.

  4. Uninstall portlets in a clustered environment the same way as in a standalone 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.


Manage the portlets

  1. Portlet deployment
  2. Deploy portlets common across clusters
  3. Change the authentication mode for portlet deployment
  4. Delete portlets common across clusters
  5. Deploy portlets unique to a cluster
  6. Update portlets common across clusters
  7. Apply updates to custom applications


Parent: Manage the cluster