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:
- Switch to the Servers view by selecting
- In the Servers view, right-click and select .
- Select the appropriate WebSphere Portal server
from the server type list.
- Provide the host name of the remote WebSphere® Portal server. Click Next.
- On the Websphere Settings page, define the following options.
- Set the RMI Port if you want to use this connection
type. Clear the checkbox if you do not need it.
- Set the SOAP Port if you want to use this connection
type. Clear the checkbox if you do not need it.
- Select Security is enabled on this server and
specify the administrator ID and password for the portal server.
- Define the following settings and click Next :
- 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, specify this information only 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, 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.
- 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:
- Define server platform as Windows or Linux.
- Specify the server profile path, for Windows the path is\\<host name>\<drive>$\<PathToProfile> and
for Linux the path is /opt/IBM/wp_profile.
- 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.
- Click Next. On the page,
select one or more projects and select the or button to associate or disassociate the project with
the server. During publishing, all projects associated with the publishing
server are deployed.
- Click .
- 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.