Defining remote servers for testing portals
Before you test or debug a project on a remote portal server, you might need to do further configuration on the remote server.
To create and configure a remote portal server:
- Switch to the Servers view by selecting
Window | Show View | Servers
- In the Servers view, right-click and select
New | Server.
- Provide the host name of the remote WebSphere® Portal server.
- Select the appropriate
WebSphere Portal server from the server type list. Click Next.
- On the Websphere Settings page, define the following options.
- Set the RMI Port if you want to use this connection type. Un-check this option if you do not need it.
- Set the SOAP Port if you want to use this connection type. Unheck this option if you do not need it.
- Check the "Security is enabled on this server" checkbox, and specify the administrator ID and password for the portal server.
- Define the following settings:
- Define the Context Root. (The default is /wps)
- Define the Default Home. (The default is /portal )
- Define the Personalized Home. (The defaults is /myportal).
- 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. (Note that you only need specify this information when you use the deploy action on Portal or Portlet Projects.)
- Specify the WebSphere Portal Administrator User ID and password.
- If you elect to enable automatic login, you need to 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 will be automatically assigned to the user. The user ID will also be used as part of the label. To use a single WebSphere Portal server for multiple users, you should use a different user ID for each person.
- Click Next. On the
Publishing Settings page, define the following options:
- Select the
Local Copy or
FTP file transfer option.
- Provide the
Library directory, which maps to the
shared/app directory of the WebSphere Portal server on the remote system. For example, the directory on the target server might be
C:\WebSphere\PortalServer\shared\app. However, if the
shared/app directory on the target server has been mapped as a network drive, the path to the
shared/app directory may be something like
E:\sharedApp. Or, if you are using FTP access, and the FTP root for the user you specify is the
C:\WebSphere directory, the path could be something like
PortalServer/shared/app. Consult your systems administrator for the exact path.
- If you select the FTP option, you will need to provide the following information:
- A user ID and password that has FTP access to the target system.
- The connection timeout value if the default of 10000 milliseconds is not adequate.
- If the target server is beyond a firewall, choose
Use PASV mode or
Use firewall. Additional firewall settings can be set by clicking the
Firewall settings button.
- 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.
- Click
Finish.
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 Portal and Portlet Publishing.
Settings for Portal Publishing:
The default set of XML access delegates that are invoked during the portal publishing operation include the following:
Pre-Publishing:
- (These delegates are disabled for remote WebSphere Portal servers.
Publishing
- Enable placeholder for missing portlets - This creates placeholders for portlets not present in the workspace and not installed on the server.
- Skip Portal configuration if no changes have been made in the workspace - This skips publishing the portal configuration if no changes have been made to the portal topology.
Post-Publishing
- These options enable you to run specific XML access scripts after publishing has completed
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
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.
- Create pages for portlets - This creates a page on the portal server under the default label "Rational Portlets" 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.
Post-publishing
.
- These options enable you to run specific XML access scripts after publishing has completed
Related tasks
Associating servers with projects