Defining remote servers

To test, debug, or profile a portlet project within the workbench, you can also define a remote server for testing portlet projects.

About this task

Before you test or debug a project on a remote portal server, see Configuring remote servers.

Procedure

To create and configure a remote portal server:

  1. Switch to the Servers view by selecting Window > Show View > Servers
  2. In the Servers view, right-click and select New > Server.
  3. Select the appropriate WebSphere Portal server from the server type list.
  4. Provide the host name of the remote WebSphere® Portal server. Click Next.
  5. On the Websphere Settings page, define the following options.
    1. Set the RMI Port if you want to use this connection type. Clear the checkbox if you do not need it.
    2. Set the SOAP Port if you want to use this connection type. Clear the checkbox if you do not need it.
    3. Select Security is enabled on this server and specify the administrator ID and password for the portal server.
  6. Define the following settings and click Next :
    1. Define the Context Root. (The default is /wps)
    2. Define the Default Home. (The default is /portal )
    3. Define the Personalized Home. (The defaults is /myportal).
    4. Define the Install location, which is the WebSphere Portal installation root. For example, the directory on the target server might be C:\Program Files\WebSphere\PortalServer ; however, if the <portal home> directory on the target server has been mapped as a network drive, the path to the <portal home> directory might be E:\Portalserver. Consult your systems administrator for the exact path, specify this information only when you use the deploy action on Portal or Portlet Projects.
    5. Specify the WebSphere Portal Administrator User ID and password.
    6. If you elect to enable automatic login, then provide a user ID and password for a WebSphere Portal user. You must create the user on the Portal Administration page on the remote server before testing or debugging. Edit permission is automatically assigned to the user and the user ID is used as part of the label. To use a single WebSphere Portal server for multiple users, use different user ID for each person.
  7. Select Enable the server to start remotely if you want to start and stop the server.
    If you select the Enable the server to start remotely option, then all the input options on the page are enabled, define the following options:
    1. Define server platform as Windows or Linux.
    2. Specify the server profile path, for Windows the path is\\<host name>\<drive>$\<PathToProfile> and for Linux the path is /opt/IBM/wp_profile.
    3. Select one of the following system logon method:
      • Operating system logon - specify the username and the password
      • Secure shell (SSH) - specify the private key file, the user ID and the pass phrase
    If you do not select Enable the server to start remotely, then all the input options stay disabled.
  8. Click Next. On the Add and Remove Projects page, select one or more projects and select the Add or Remove button to associate or disassociate the project with the server. During publishing, all projects associated with the publishing server are deployed.
  9. Click Finish.
  10. The server instance for the remote server is defined, right-click on the instance and select Start.

What to do next

Additional options for remote servers can be viewed and changed by double-clicking on the server in the Servers view. This opens the server configuration editor. You can change any of the settings that were defined previously. In addition, the Portal tab has additional settings for Portlet Publishing.

Settings for Portlet publishing

The default set of XML access delegates that are invoked during the portlet publishing operation include the following:

Pre-publishing
  • These delegates are disabled for remote WebSphere Portal servers.
Publishing
  • Create pages for portlets - This creates a page on the portal server under the default label "Rational® Components" and adds the published portlet to the page.
  • Use separate pages for each project - This creates separate pages for multiple projects published to the server.
In addition, under the Portlet Publishing delegates, you can select the check box to 'Enable anonymous user access'. This option enables you to test portlets in the not-logged-in state.
Post-publishing
  • These options enable you to run specific XML access scripts after publishing has completed.

Feedback