You are on page 1of 96

Administering IBM WebSphere Portal 7.

0: A
comprehensive workshop
Thomas Hurek (, Software Architect, IBM
Falk Posch (, Software Engineer, IBM

January 2012
Copyright International Business Machines Corporation 2012. All rights reserved.
Summary: The goal of this white paper is to explain the various administration and
configuration tools offered by IBM WebSphere Portal 7.0. Learn about which tool to use for
which task and about the new capabilities of WebSphere Portal 7.0, and understand
differences from previous versions of WebSphere Portal. We take you through exercises for
each tool so you can learn hands-on how to use them.

Table of Contents
1 Introduction..........................................................................................................................2
2 What is WebSphere Portal?.................................................................................................3
2.1 Configuration information.............................................................................................4
2.2 Preparing to install WebSphere Portal..........................................................................4
3 WebSphere Portal installation..............................................................................................5
4 WebSphere Portal file system structure.............................................................................15
5 Command line tools...........................................................................................................20
5.1 ConfigEngine..............................................................................................................20
5.2 ConfigWizard..............................................................................................................22
5.3 WebSphere Application Server scripting.....................................................................26
5.4 XMLAccess.................................................................................................................29
5.5 WebSphere Portal scripting........................................................................................34
5.6 ReleaseBuilder...........................................................................................................37
6 Administration user interface: Admin portlets.....................................................................38
6.1 Accessing WebSphere Portal.....................................................................................40
6.2 Manage Users and Groups.........................................................................................41
6.3 Virtual Portal Manager................................................................................................43
6.4 Administration GUI's: Page Builder.............................................................................47
6.5 Tagging and rating......................................................................................................68
6.6 Admin portlets: Manage Static Pages.........................................................................74
6.7 WebDAV.....................................................................................................................79
7 WebSphere Application Server Admin user interface.........................................................87
8 Conclusion.........................................................................................................................95
9 Resources..........................................................................................................................95
10 About the authors.............................................................................................................95

1 Introduction
In this white paper, we explore the newly added and already existing administration tools for managing
IBM WebSphere Portal 7.0 on IBM WebSphere Application Server 7.0. The exercise is separated
into the following sections:
1. A short introduction on WebSphere Portal and how configuration information is used.
2. Step through installing WebSphere Portal.
3. An overview of the new File System structure.
4. Using the Configuration Engine (ConfigEngine) to list virtual portals.
5. Using the Configuration Wizard (ConfigWizard) to explore modifying portal security.
6. Using WebSphere Application Server scripting.
7. Creating a baseline with XMLAccess and using XMLAccess to deploy a portlet.
8. Using the ReleaseBuilder tool to create a comparison release.
9. Creating a page using the WebSphere Portal Scripting interface.
10. Using some WebSphere Portal administration portlets to explore the created page, create a
user, and see how a virtual portal can be created.
11. Using the new 7.0 UI to manage pages, create wikis, consume feeds, and create pages from
static HTML.
12. Using WebDav, a newly supported standard, to update WebSphere Portal settings.
13. Trying out tagging and rating.
14. Using the WebSphere Application Server 7 Admin Console.
If you are more interested in the command line tools, you can start with Section 4; if you are more
interested in the user interface, you can go directly to Section 10. At the end of the paper is an
overview of the WebSphere Portal administration possibilities---tools that we use in a sample.

The following color codes are used in this paper:
Magenta: A file or directory
Blue: A command to be executed
Green: A name, title, value, file content, or program output
Red: An important value
NOTE: These colors are helpful to see the different types quickly, but they are not necessary to
understand the meaning. So if you are using black and white, that will work as well.
Here our server name is localhost or testserver. Replace these server names with your local host
name on which WebSphere Portal is installed. For the Virtual Portal case we have selected
vptestserver; you can map it to your localhost in your hosts file.

During the install, WebSphere Portal does the following:

Creates WebSphere Application Server 7.0

Lets you choose the Installation directory; for example, C:\ibm\PortalServer (you can choose
another directory, but you then must adjust references in this document accordingly)
Creates the database, Derby, which contains the WebSphere Portal tables
Enables file-based security after the install
Creates the WebSphere Portal Administrative user, wpsadmin / wpsadmin (you can choose
another password during install, but then you must adjust references in this paper accordingly)

Sample files used here are provided in the file as a Download.

2 What is WebSphere Portal?

Let's begin with the marketing message: IBM WebSphere Portal software provides a composite
application or business mashup framework and the advanced tooling needed to build flexible, SOAbased solutions, as well as the unmatched scalability required by any-sized organization.
Quite simply, WebSphere Portal is a framework that lets you easily build a standardized, rich Web
(Portal) solution. It is installed on top of IBM WebSphere Application Server, which contains the JavaTM
Runtime edition that provides APIs and an abstraction layer from the operating system (see figure 1).
Figure 1. WebSphere Portal architecture
and mobile
Brow sers,
Mashups and
offline Clients




WebSphere Portal
Portlet API




Composite Applications

Web Content Managem ent

Many m any additional

components and APIs

Page Aggregation






Standards like JDBC, .

Many many JMS
components and APIs


Java Virtual Machine


Integration and Abstraction


WebSphere Application Server




Platform Abstraction

Operating System

Clients as browsers or mobile devices gain access to the portal via the HTTP protocol, and the
request arrives at WebSphere Application Server, which routes it to the WebSphere Portal servlets
and portlets and widgets.
The WebSphere Portal servlets, portlets, and widgets build a Web page by aggregating information
from the Portal configuration and backends via APIs and connections.
The newly built Web page is then sent via the HTTP protocol back to the client device, which renders
the response and, depending on the client, returns the response in the form of HTML, WML, etc.

2.1 Configuration information

The configuration information is stored as follows (see figure 2):

WebSphere Portal uses the underlying WebSphere Application Server to serve requests.
WebSphere Portal configuration data is stored in both the databases and the file system.
WebSphere Application Server uses only the file system for its configuration data (though
there are some exceptions to this rule, such as session persistence).
The Configuration Tools modify the configuration data in the different repositories.

Figure 2. Configuration information storage

You may want to change the WebSphere Portal configuration to integrate into your environment; for
example, so as to connect to your databases or LDAP server(s), IBM Lotus Domino mail servers,
or IBM Lotus Sametime servers, or to do the following:

customize the look and feel

make the solution secure
achieve high availability
tune performance
deploy your code
enable or disable additional features
perform maintenance

WebSphere Portal is quite flexible and, depending on your use case, more than one tool can be used
to achieve your goals.

2.2 Preparing to install WebSphere Portal

The references to directories in this paper are for the Microsoft Windows operating system. You
can use any other multi-platform operating system, but you must adjust the directories accordingly.
First, retrieve the WebSphere Portal V7.0 install media from from, for example, the IBM Passport
Advantage Web site, and see Section 3 for a step-by-step guide through the install of WebSphere
Portal. If you already have it installed, you can start directly with Section 4.

3 WebSphere Portal installation

In this section we demonstrate how to install WebSphere Portal 7.0. The install creates multiple

The WebSphere Application Server, including the Java Virtual Machine

The WebSphere Portal install
The Derby database that WebSphere Portal uses to store configuration information

In addition, the install offers multiple options for customization:


Edition: Based on your license you are entitled to use different Editions that contain different
Install location: Where you would like to install
Admin user: The userID and password of your administrative user
Node name: The administrative name of your instance-this information is used in case of
clustering (combining multiple installs into a group for high availability)
Base or Full install: With the Base install, only a limited amount of components are installed. For
instance, Web Content Management, Personalization rules, and Collaboration features like Mail
are not installed, but you can add them later using configuration tasks.
From the WebSphere Portal 7 Enable Media, launch the install.bat (Windows) or ./
(Linux or UNIX) command (see figures 3a and 3b, respectively).

Figure 3a. Starting the installation on Windows

Figure 3b. Starting the installation on Linux


The WebSphere Portal Install Wizard Launches. Select IBM WebSphere Portal Enable and click
Next (see figure 4).
WebSphere Portal offers different packages with different capabilities and license conditions; for
this session, we use IBM WebSphere Portal Enable, but the other editions could also be used.

Figure 4. Selecting the licensed product


In the License window, read through the license and select I accept the terms in the license
agreement; click Next (see figure 5).

Figure 5. License window


In the next window, decide between the Base and Full install package. Choose the Full option to
explore all features; click Next (see figure 6).

Figure 6. Selecting Full installation option


Now choose the install location. For Windows you can use, for example, C:\ibm. The sample in
figure 7 shows the install on Linux. For the later exercises you will need the install directory. Click

Figure 7. Selecting the Install location


Next, enter the node name (it can be any unique name) and the fully qualified host name for
which you are performing the install; click Next (see figure 8). The node name is relevant for
operations in WebSphere Application Server when building a cluster (multiple Portals). For later
exercises you will need the host name.


Figure 8. Selecting the node and host name


Enter the user ID and password of the administrator account (you can change them later); click
Next (see figure 9). In the exercises you can use wpsadmin as userid and wpsadmin as


Figure 9. Selecting the Admin ID


On Windows, you can choose to create service definitions to automatically start the WebSphere
Portal server; click Next (see figure 10).


Figure 10. Choose Windows Service creation


The final window shows a summary of all entered values. If the values are as desired, click Next,
to start the install. Our Linux sample is shown in figure 11


Figure 11. Summary of the installation settings

10. Once the install finishes successfully, the window shown in figure 12 displays (sample from
Windows). Click Finish to end the install. If you select Launch First Steps, an additional window
with actions to launch a browser instance with WebSphere Portal or starting/stopping will display.
Figure 12. Finish the installation


4 WebSphere Portal file system structure

In this section, we discuss the directory structure of WebSphere Portal; specifically, the location of the
command line tools, binaries, and configuration of the product.
These are the use cases for which you would work with the WebSphere Portal file system:

Configuration changes like modifying properties files, etc.

Starting and stopping the server
Starting and stopping command line tools
Viewing log files

However, you would not use the WebSphere Portal file system for modifying internal configuration
files directly, bypassing administration/configuration tools. Nearly all the alternative tools mentioned in
this section modify the file system in some way.
Let's now explore the WebSphere Portal file system structure, including the AppServer directory,
PortalServer directory, Profile directory, Profile directory logs, and Profile directory WIM/VMM. A few
of the important directories when working with WebSphere Portal are (see figure 13):

The AppServer directory, containing the binaries of WebSphere Application Server as well as
templates, utilities, and the Java Developer Kit.
The bin directory, containing the WebSphere Application Server command line tools that are
independent of the profile.
The Derby database binaries, found in the derby directory.
The Java directory, containing the Java Developer Kit 1.6, including the Java Runtime Edition.

Figure 13. AppServer directory

The directories worth noting in figure 14 are:

The PortalServer directory, containing mainly the binaries for WebSphere Portal. In
WebSphere Portal 7 the binaries and the configuration and tools have been separated; thus,
the PortalServer directory needs to be touched less often than with previous versions.

The bin subdirectory, containing XMLAccess, Release Builder, version reporting, and other
command line tools. For legacy purposes the tools are still stored in this directory as well as in
the profile directory. New tools in this directory were added for the multiple profile support.

The doc subdirectory, which holds API/SPI documentation as well as XMLAccess sample files.


The installableApps directory, in which are found the Portal application enterprise archive files
(.war and .ear files). Most of them are deployed out of the box, but some can be deployed later
on (such as business portlets).

The shared directory contains the main .jar file binaries of WebSphere Portal. It's possible to
drop class files into the PortalServer/shared/app directory so they're loaded by the classloader.

Another important directory in figure 14 is the version directory, which holds the corrective
service registry. Also, note that the uninstall directory contains the uninstall code.

Figure 14. PortalServer directory

The Profile directory (see figure 15) contains the configuration as well as command line tools for
WebSphere Portal and WebSphere Application Server:

The bin directory contains all the command line tools related to the profile, for example, for
starting and stopping the server.
The config directory holds the configuration for the WebSphere Application Server.
ConfigEngine is the command line tool to trigger configuration tasks in WebSphere Portal (it
replaces the WPSConfig tool used in previous releases). The log directory inside the
ConfigEngine directory contains the Portal Install and Configuration logs.
The installedApps directory holds the Installed J2EE applications, including portlets.
The PortalServer directory contains the Portal command line tools in the bin directory,
configuration files in the config folder, and the Derby database in the derby directory. The
ConfigWizard can be found in the wizard directory. All the tools are used later in this article.

Figure 15. Profile directory


The runtime logs of WebSphere Portal are found inside the log directory (see figure 16), which
contains a directory for every server instance. For a standalone setup the directory name is
WebSphere_Portal. The following files are of interest in this directory:
SystemOut.log, containing the system messages, including warnings and startup information of the
SystemErr.log, containing errors and exceptions.
native_stderr.log, containing the JVM messages, including garbage collection data if verbose
garbage collection is enabled. It's possible to configure a separate file to contain the verbose
garbage collection data, which would have a custom name, for example, Verbosegc.

Figure 16. Profile directory--logs

The last directory we want to point out is the Virtual Member Manager (VMM) config directory (see
figure 17), which contains the user repository configuration data. In previous releases the
configuration was stored in the WebSphere Member Manager Configuration files (wmm.xml).


Figure 17. Profile directory - WIM/VMM

5 Command line tools

Now let's focus on the command line tools.

5.1 ConfigEngine
The ConfigEngine command line tool is used to execute WebSphere Portal configuration tasks such
as changing the security configuration, enabling/disabling components, clustering, and virtual portals,
or if automation is needed.
It cannot be used for all configuration changes, some of which are possible only in WebSphere
Application Server Admin Console/Scripting.
Alternative tools include the ConfigWizard, WebSphere Application Server Scripting, and WebSphere
Application Server Admin Console (limited set of tasks).
As an example task, let's list all available virtual portals. The ConfigEngine takes input parameters
from the command line, property files, and the parent properties file (see figure 18).


Figure 18. ConfigEngine Input values via property files

The most important input property files are:, which is the main configuration file, containing Advanced Security, Process Integration, URL configuration, containing the configuration settings for Database configuration., containing the configuration settings for Database driver configuration

Execute the command in the directory, c:\ibm\wp_profile\ConfigEngine, as follows (see figure 19):
ConfigEngine list-all-virtual-portals -DPortalAdminPwd=wpsadmin -DWasPassword=wpsadmin
Figure 19. Triggering the ConfigEngine command


where the syntax is as follows:

ConfigEngine.bat /
Config task to be executed (in this case, list-all-virtual-portals)
Properties not specified in the property files and/or properties to be overwritten
list-all-virtual-portals lists all existing virtual Portals in the command line

Figure 20 shows the output of the command.

Figure 20. ConfigEngine command output

5.2 ConfigWizard
The ConfigWizard command line tool lets you execute Config tasks from an easy-to-use UI. Use it for
wizard-style configurations for:

Database transfer
Security repository configuration
Database connect

Don't use it if:

automation is needed
no graphical interface is available
config tasks other than those above must be executed


Alternative tools are as follows:

WebSphere Application Server Scripting
WebSphere Application Server Admin Console (limited set of tasks)

As an example task, let's show the initial steps for adding an LDAP repository:

First, to invoke the ConfigWizard, change directory to c:\ibm\wp_profile\PortalServer\wizard and

invoke configwizard.bat (see figure 21).

Figure 21. configwizard.bat


The Welcome screen displays; click Next (see figure 22).

Figure 22. Configuration Wizard Welcome screen



To modify the security configuration, select the Configuring security radio button; click Next (see
figure 23).

Figure 23. Configuring security option


Enter uid=wpsadmin,o=defaultWIMFileBasedRealm in the Username field, and enter wpsadmin in

the Password field; click Next (see figure 24).


Figure 24. Specify username and password

5. Select the Configuring Federated Repository option; click Next (see figure 25).
Figure 25. Configuring Federated Repository option


6. In the next window (see figure 26), click Cancel (otherwise, we'd require an LDAP server).
Figure 26. Cancel the Add Federated LDAP Repository option

5.3 WebSphere Application Server scripting

This command line tool is used when creating, modifying, or deleting WebSphere Application Server
settings like dynamic cache settings and thread pools, or when automation is required. It is not for use
when modifying WebSphere Portal runtime data like pages or portlets.
Alternative tools are ConfigWizard, ConfigEngine, and WebSphere Application Server Admin
Figure 27 shows the WebSphere Application Server Scripting syntax, where we do the following:
Change to C:\ibm\wp_profile\bin
Enter wsadmin -h


Figure 27. WebSphere Application Server Scripting syntax

For our sample exercise, let's enable tracing for the WebSphere Portal Server with wsadmin:
1. Enter the following command to connect to the server (see figure 28):
wsadmin -host localhost -port 10025 -user wpsadmin -password wpsadmin
Figure 28. Connect to the server

The command connects to the server on the given port, using the credentials of the wpsadmin user
and, now that we're connected to the server process, we can trigger commands.


Enter the following commands to enable tracing (see figure 29):

$AdminControl completeObjectName
set ts [$AdminControl completeObjectName
$AdminControl setAttribute $ts traceSpecification*=all

Figure 29. Enable tracing with wsadmin


Access WebSphere Portal in the browser by opening a browser and entering the following URL:


Verify that the trace file, trace.log, was created in the C:\ibm\wp_profile\logs\WebSphere_Portal
directory (see figure 30).

Figure 30. Checking for trace.log



Disable the tracing again by running the following (see figure 31):
$AdminControl setAttribute $ts traceSpecification*=all=disabled

Figure 31. Disable tracing with wsadmin


Exit the tool by running the exit command.

5.4 XMLAccess
This command line tool is used to create, modify, and export WebSphere Portal artifacts. Specifically,
use it to:

Create, modify, and delete WebSphere Portal resources like pages or portlets
Move singular configuration changes between environments
Export WebSphere Portal artifacts
Deploy portlets

It cannot be used to modify WebSphere Application Server configuration settings. Alternative tools are
Portal Scripting and Portal Admin Console (limited set of tasks). Figure 32 shows the syntax for
Figure 32. XMLAccess syntax


XMLAccess - Export
For our sample task, we export a complete release and deploy a portlet. The input file controls what
actions are performed, and we use ExportRelease.xml for a full export in the release format (required
later by Release Builder). Figure 33 shows sample files in c:\ibm\PortalServer\doc\xml-samples.
Figure 33. Sample .xml files

Figure 34 shows the import file.


Figure 34. Import file

The file defines the XML syntax used by XMLAccess to export the release data of WebSphere Portal.

First, change to the C:\ibm\wp_profile\PortalServer\bin directory, and then trigger the export via
the following command (see figure 35):
xmlaccess -in c:\ibm\PortalServer\doc\xml-samples\ExportRelease.xml -out InitialRelease.xml
-url http://localhost:10039/wps/config -user wpsadmin -password wpsadmin

Figure 35. Triggering the export

The result should look like figure 36.

Figure 36. Request successful message


Then, check the result file, C:\ibm\wp_profile\PortalServer\bin\InitialRelease.xml (see figure 37),

in which comments are listed at the beginning, and then the different resources are exported with
their settings.

Figure 37. Result file


Check the file for a sample, such as URL mapping:


The tag name url-mapping-context shows this is a URL mapping.

The parameter action="update" is used if this file is used as import file and means a URL
mapping will be updated (or created if not there).
Parameter domain="rel" indicates that this configuration is from the release database.
The label="Administration" is the mapping you would use in the URL, for example,
Each resource has an internal objectid.
No specific permissions are set.
Another important part is the subtag portal-url that points to the page (objectid), which should be
displayed if the URL mapping is used.

XMLAccess - Import
Now let's deploy a sample portlet with the XMLAccess input script shown in listing 1.
Listing 1. XMLAccess script
<?xml version="1.0" encoding="UTF-8"?>
<portal action="locate">
<web-app action="update" active="true" uid="SPFStandardStockQuote.war.webmod">
<portlet-app action="update" active="true" uid="SPFStandardStockQuote.war">
<access-control externalized="false" owner="undefined" private="false">
<role actionset="Privileged User" update="set">
<mapping subjectid="all authenticated portal users" subjecttype="user_group" update="set"/>

The portlet SPFStandardStockQuote.war will be imported, and you can use the sample file,
DeployPortlet.xml, provided as part of the package:

Open a command line, change to C:\ibm\wp_profile\PortalServer\bin and trigger (see figure 38):
xmlaccess.bat -in DeployPortlet.xml -out DeployPortlet.xmlOut.xml -url
http://localhost:10039/wps/config -user wpsadmin -password wpsadmin

Figure 38. Open command line and trigger


Check the output file, DeployPortlet.xmlOut.xml in the C:\ibm\wp_profile\PortalServer\bin


The portlet is now imported and can be used in our next exercises.

5.5 WebSphere Portal scripting

This wsadmin-based tool is used to create and modify WebSphere Portal artifacts limited by the roles
of the user. You can use it to:

Create or modify a limited set of WebSphere Portal resources like pages or portlets
Combine with wsadmin WebSphere Application Server scripts to modify WebSphere
Application Server settings at the same time

Also, the tool is useful if administration is delegated to sub-Admins.

Do not use it when moving configuration changes between environments or when exporting
WebSphere Portal artifacts and deploying portlets.
Alternative tools are Portal XML Access and Portal Admin Portlets (limited set of tasks).

WebSphere Portal Scripting modes

There are two modes in WebSphere Portal Scripting:

The first is Interactive mode, which lets us trigger single commands and whose response is
directly visible.

The second is Scripting mode, which lets us execute a complete, prepared script consisting of
several actions.

Interactive mode
As an example task, we create a sample portal page, using the Interactive mode:
1. Open a command prompt and change to the directory, c:\ibm\wp_profile\PortalServer\bin.
2. Invoke the scripting interface, using the jython scripting language, wpscript -lang jython.

In the Login at the Target Server window (see figure 39), enter wpsadmin in both the User Identity
and User Password fields; confirm by clicking OK.

Figure 39. Login at the Target Server window


4. Log on to the portal, using the following script command (see figure 40):
Figure 40. Log on to the portal


Select the parent page of our new page by first finding the parent page (see figure 41):
Content.find(all, uniquename, ibm.portal.Home)
and then selecting the page:"Z6_CGAH47L008LG50IAHUR9Q330A3")

Figure 41. Find and select page

6. Create an empty page and immediately select this new page (see figure 42):
Figure 42. Create and select empty page

7. Set a unique name for this page (see figure 43):

Figure 43. Set unique name


8. Quit the interactive mode, using the quit command (see figure 44).
Figure 44. Quit interactive mode

Scripting mode
Now let's modify the created test page, this time using the Scripting mode:

Create a file in the directory C:\ibm\wp_profile\PortalServer\bin with the content

in listing 2 (you can use the file provided as part of the package):

Listing 2. Script for

# login to portal
print " 1. login done."
# select page"all","uniquename",""))
print " 2. page selected"
# search portlet
portletA = Portlet.find("portlet", "name", "Struts Standard Stock Quote")
print " 3. portlet found: " + portletA
# create a vertical container
Layout.create("container", "vertical", "select")
print " 4. vertical container created."
# create a control with the portlet
Layout.create("control", portletA)
print " 5. create control with stock portlet."
# logout again
print " 6. logout."
print " Processing done."

where # denotes a comment, print prints a message to the command line, and the sequence of
the script is:
(1) Login
(2) Locate the page
(3) Create a container on the page to hold the portlet
(4) Put the portlet into the container
(5) Logout
The script updates the page we created earlier with the Interactive mode, and the portlet deployed
earlier with XMLAccess is added to the page.

Invoke the script to set the layout for the new test page (see figure 45):
wpscript -user wpsadmin -password wpsadmin -lang jython -f


Figure 45. Invoke script

The command executes the script contained in under the user identity wpsadmin.

5.6 ReleaseBuilder
This command line tool compares different XMLAccess exports taken over time, generating a
difference XMLAccess file that can be used to move the changes made to the next environment. The
tool is used in staging to production scenarios.
It's not to be used to compare XMLAccess exports between different environments or for other tasks.
Alternative tools are Portal XMLAccess (limited scenario to move single resources) and Portal Admin
Console Site Management (limited scenario to move pages).
ReleaseBuilder is used to generate a diff file but, before you can use it, you must generate the next
release export, using xml access:

Open a command prompt and change to directory, C:\ibm\wp_profile\PortalServer\bin.


Generate the release export by invoking following command (see figure 46):
xmlaccess -in c:\ibm\PortalServer\doc\xml-samples\ExportRelease.xml -out
ChangedRelease.xml -url http://localhost:10039/wps/config -user wpsadmin -password

Figure 46. Generate the release export

The result should look like that shown in figure 47.


Figure 47. Release export result

Now we can use the ReleaseBuilder to generate a diff file that contains all the changed information:

From the directory C:\ibm\wp_profile\PortalServer\bin, start releasebuilder without any parameter

to check the syntax (see figure 48).

Figure 48. Start releasebuilder


Now generate the difference between the release export we did at the beginning of this paper and
the release export we just created, by executing the following command (see figure 49):
releasebuilder -inOld InitialRelease.xml -inNew ChangedRelease.xml -out ReleaseDiff.xml

Figure 49. Generate the difference

6 Administration user interface: Admin portlets

The Admin portlets are available with the WebSphere Portal installation and are placed in the
Administration areal. As administrator you have access to these portlets by default.

Here are some examples of what you can do with the Admin portlets (see figure 51):

adapt the user interface (hierarchy of pages, page layout)

administer Web applications/ portlets (for example, provide portlets for or consume portlets
from other WebSphere Portal servers)
change the access control (users and groups, credential vault, policies)
modify WebSphere Portal settings (e.g., URL mappings, supported markups and clients)
modify WebSphere Portal content (e.g., Web Content libraries, syndication, feeds)
manage search administration (e.g., define and manage search collections)
manage WebSphere Portal analyses and virtual portals

Figure 51. Admin portlets navigation pane

In this section, we demonstrate these use cases:

create a user with the Manage Users and Groups portlet

create a virtual portal using the Virtual Portal Manager portlet
explore the Page Builder theme to create a wiki and feed, and learn to move and share the page
with another user
use the Page Builder theme to create a page of mixed portlets and widgets, and leverage wiring
among them
investigate how to use tagging and rating
create a static page with the Manage Pages portlet
use WebDav to modify the created static page


6.1 Accessing WebSphere Portal

In this topic we learn how to access Portal and about the different artifacts in the Portal markup:

Open a Firefox browser with the URL, http://localhost:10039/wps/portal, or use the bookmark
created for you. You will see the Portal UI for the anonymous user (see figure 52), in which:

the Getting Started and Features tabs are pages

the Sign Up and Log In buttons on the banner are also pages that can be used for logging in
and signing up to create a new user ID

Figure 52. Anonymous start page


Click the Log In button and log in with userid wpsadmin and password wpsadmin (see figure 53).

Figure 53. Log in window


After the log-in, the default Getting Started page is displayed that contains a portlet displaying
some welcome information. The structure of the Web site is defined by the theme; that is, which
links are displayed, how the navigation looks, the colors, branding, etc. (see figure 54).
Figure 54. Authenticated area after WebSphere Portal log-in

6.2 Manage Users and Groups

In this topic we use the Manage Users and Groups admin portlet (see figure 55) to add a nonadministration user. Note that Permissions can be granted to users or groups, and there is a
hierarchical access control model (for example, along page hierarchy).
Figure 55. Manage User and Groups portlet


Later, the non-admin user is used to demonstrate the Page Builder sharing functionality.
Alternatively, you can create users by using XMLAccess or directly in the LDAP, or in the WebSphere
Application Server Admin Console.
To create a new user with the Admin portlet:

Open a browser with http://localhost:10039/wps/portal and log in with userid wpsadmin and
password wpsadmin.


Select Administration Access Users and Groups, and click the New User button (see figure

Figure 56. Create new user


Enter at a minimum the following information to create a user (see figure 57):
User ID
Confirm Password
Last Name


Figure 57. Profile Management window


Confirm the user creation by clicking OK; you should see the User created successfully
message (see figure 58).

Figure 58. Success message

6.3 Virtual Portal Manager

We use this admin portlet to create a new virtual portal (see figure 59) that can be used, for example,
to host many portals within one installation, or as a staging system, or to host different portals with
different user interfaces and user groups.


Figure 59. Virtual Portal Manager portlet

Note that you can also create virtual portals by using the scripting interface and then using
XMLAccess to fill the virtual portal.
To create the new virtual portal:

Select Administration Virtual Portals Manage Virtual Portals, and then click the New Virtual
Portal button (see figure 60).

Figure 60. Create new virtual portal


Complete the virtual portal's information as follows (see figure 61); click OK:
Virtual portal name: accounts
Virtual portal description: The accounts Virtual Portal
URL Context: accounts
Virtual portal hostname: vptestserver
Initial admin user group: wpsadmins


Figure 61. Enter virtual portal's information

You should see the created successfully message and our new The Accounts Virtual Portal
listed in the portlet (see figure 62).


Figure 62. Confirmation of creation


Log in to the newly created Virtual Portal (see figure 63) by specifying the URL context
(http://localhost:10039/wps/portal/accounts) or by using the host name of the virtual portal

Figure 63. Login window

Figure 64 shows the Administration area of a virtual portal, within which you have a limited set of
administration tools.


Figure 64. Administration area

6.4 Administration GUI's: Page Builder

Page Builder is the new version 7 theme that lets administrators and users customize pages easily
and with which you can do the following:

Run widgets and portlets on the same page in either server-side or client-side mode
Combine client- and server-side aggregation of Web 2.0 theme with Page Builder capabilities as
well as mashup integration
Create, modify, delete a page
Create, modify, delete blogs, wikis, and feed readers
Add/remove portlets and wikis
Wire portlets and wikis
Share pages with other users

A test user must be previously created, and alternative tools are XML Access and the Manage Pages
To use the Page Builder theme to create a page:

Log in to the default Portal as wpsadmin (http://localhost:10039/wps/portal)

Click on Actions to open the Toolbar.


Click the New Child Page button (see figure 65).

Enter a name for the page, make it private, and click the Create Page button. Private pages are
visible only to the user creating it, whereas Non-Private pages are visible to all users who have

Figure 65. Create page






An empty page is created (see figure 66). Use the Page Builder theme to modify the layout and
elements of the page by selecting Actions Edit Page.


Figure 66. Edit the empty page


Click the Customize button to modify the content of the page. A window opens that lets you add
portlets and widgets, change the layout of the page, and choose a different user interface style.
Click the plus-sign button beside the Wiki entry to add a wiki to the page (see figure 67).

Figure 67. Customizing a page


A pop-up window opens that lets you specify a wiki name. Enter a name (e.g., My first Wiki) for
your wiki and click the Add button (see figure 68).


Figure 68. Adding a wiki to a page


Now click the plus-sign button beside the Feed name to add a feed portlet to our page that can
display a news feed.
10. In the pop-up window (see figure 69), specify a title for your feed portlet and the URL from which
the feed should be read, for example, the IBM feed for WebSphere Portal (also available as a
bookmark in the browser):
Figure 69. Adding a feed

11. To select a different predefined style that defines the user interface of the page, select Change
Style, and select a different style (see figure 70).


Figure 70. Changing the style

12. The layout of a page defines the columns and rows in which the portlets and widgets are
displayed on it. Select Change Layout, and select a Layout you would like for the page (see figure
71); click Save & Exit, to save the page changes and return to view the page.


Figure 71. Change the layout

Figure 72 shows your newly created page, including the feed and the wiki. You might need to scroll
down for the different elements.


Figure 72. Reviewing the created page

Now that the page has been created as desired, you might want to modify your wiki. To do this:

Click the Edit button in the Welcome section of the page and add a few lines for your readers, for
instance, Display title, Description, Content (see figure 73). (Ignore potential warnings that
optional applets could not be loaded.).


Then click Save and Close.


Figure 73. Editing the wiki

You might want to move the page in the hierarchy to a different place, such as as top-level page. To
do this:

Select Actions --- Move Page, as shown in figure 74.


Figure 74. Triggering the move of a page

A new window opens in which you can select the new parent page in the hierarchy. The Home
page is the parent page of the user area of WebSphere Portal-typically all pages would be in a
hierarchy below it, while the administrative pages are below the Administration page.

In our example let's move the page directly below the Home page to be the top-level page by
selecting Home, making sure As child of selected page is enabled; click Save (see figure 75)..

Figure 75. Triggering the move of a page


As a result the page is now directly below Home, as shown in figure 76.
Figure 76. Result of moving a page

Now that you have created the page and wiki, let's have a colleague review the page. To do this:

Select Actions --- Share Page, as shown in figure 77.

Figure 77. Triggering the sharing of a page


Search for the user you created earlier (e.g., user1) and click Add to Edit, to add the user to the
edit column; click Save (see figure 78).


Figure 78. Sharing a page

Now that we have shared the page as the wpsadmin user, let's log in as another user and view the
shared page:

Log out and log in with the previously created test user (e.g., user1).
Select Actions --- Add shared Pages (see figure 79).

Figure 79. Adding a shared page to the user interface



Click the ADD button beside the page shared by wpsadmin and click Save (see figure 80).

Figure 80. Adding the page

Now user1 can see the Page Builder Page page as created by wpsadmin (see figure 81).
Figure 81. User interface after adding a shared page


Working with a client-side page containing widgets and portlets

In this next exercise we create a page that renders client side and then add portlets and widgets to it.
We also explore wiring to send events between the elements on the page. WebSphere Portal 7 lets
you define the rendering mode for the page to be either client side or server side.

Select the Getting Started page (you will use it as the parent page) and select Actions --- New
Child Page (see figure 82).

Figure 82. Creating a new child page


In the Create Page pop-up (see figure 83), choose a Page name for the new page; the Friendly
URL name is reflected in the URL and is chosen automatically for you while you type the Page
If the page is not created as private, it will be visible automatically to all users who have access
rights, without the need to share the page. Do not select the Make this my private page button.
Finally, click the Create Page button.


Figure 83. Creating a new child page

By default, pages are created so that they use the rendering mode of the parent page. We want the
new page to render client side, so for that we do the following:

Select Actions --- Edit Page Properties, to modify the settings of the page (see figure 84).

Figure 84. Modifying Page properties



Different configuration settings can be changed in the Page Properties window; you want to allow
the page to render on the client. To do that, enable the Client Side Aggregation - Rendering
option and click OK (see figure 85).

Figure 85. Modifying page properties

You still have an empty page, so let's now add some portlets and widgets to the page. With
WebSphere Portal 7 the portlets and widgets can exist on the same page; in the Edit window there is
no longer any distinction between them like in previous versions.

Select Actions --- Edit Page, to modify the page content and layout (see figure 86).


Figure 86. Modifying Page properties


Click the Customize button, to modify the page, and then select All to show all available portlets
and widgets (see figure 87).

Figure 87. Adding content to the page


Search for web site, as shown in figure 88, click the Search icon, and select the Web Site
Display widget by clicking the plus sign.


Figure 88. Adding a portlet to the page


Now search for feed, click the Search icon, and select the Feed Reader widget by clicking the
plus sign; click Save, to save the changes (see figure 89).

Figure 89. Adding a widget to the page


We need to modify the configuration of the widget to point to a different feed. The configuration of
a widget or portlet is stored in the Portal database.

Click the icon across from the Feed Reader widget name (see figure 90) and select Edit Shared
Settings from the menu, to switch to the Edit mode of the portlet/widget that the portlet/widget
developer wrote in addition to the View mode.

Figure 90. Modifying the settings of a portlet or widget


This portlet allows us to modify the feed. For the Feed URL field you can use and then enable the Make article
links available to other widgets checkbox, to allow communication between different
portlets/widgets on the page (see figure 91). Click Save.

Figure 91. Modifying the settings of a portlet or widget


Wiring two portlets or widgets allows them to communicate and share data. You enable wiring to send
a selected feed URL from the Feed Reader widget to the Web Site Displayer widget:

Click the icon across from the Feed Reader widget name (see figure 92) and select Edit Wiring
from the menu.

Figure 92. Triggering the wiring of portlets or widgets


Click the Settings button in the Wiring pop-up window.

In the Matching Mode pop-up window (see figure 93), select Consider semantic types or.and
targets, with the configuration to allow any parameters to be sent between widgets; click Done.

Figure 93. Triggering the wiring of portlets or widgets



As Source, select Feed Reader --- Item Selected as (see figure 94) and, as Target, select Web
Site Displayer --- URL using (1st checkbox); click Done.

Figure 94. Triggering the wiring of portlets or widgets


Click Save and Exit to leave the Edit Page window. Note that a preview of how the page will look
is displayed at the bottom before you save and exit (see figure 95).


Figure 95. Saving the page

Finally, now that we're back in the view mode of the page, you can try out your newly created wire by
clicking, say, the second link in the Feed Reader widget and confirming the result is displayed in the
Web Site Displayer widget (see figure 96).


Figure 96. Reviewing the resulting page

6.5 Tagging and rating

WebSphere Portal version 7 introduced tagging and rating of resources (pages, portlets, etc.), so that
users can tag and rate resources if you allow them to; in addition, the Tag Center lets you explore the
existing tags and manage them.
Let's now try out tagging and rating:

Log in to Portal as admin (wpsadmin/wpsadmin), select one of the pages under the Home label,
and select Actions --- Tag (see figure 97).


Figure 97. Selecting to tag a page


Add some tags, such as Wire Widgets IBM Specials, for the Page (see figure 98); click Save.

Figure 98. Adding tags to a page



Once saved, you will see the tags you created; click Done (see figure 99).

Figure 99. Saving tags for a page


Log out and log in again as another user (e.g., user1), using the Log out and Log in links (see
figure 100).

Figure 100. Re-login



After logging in again, click the Tag Center link in the banner of the page (see figure 101).

Figure 101. Selecting Tag Center link


In the Tag Center (see figure 102) you can see all existing tags and select them (e.g., Specials),
to display resources tagged with them.

Figure 102. Exploring the Tag Center


As figure 103 shows, one result was found for the Specials tag that you just selected, and no one
has yet rated the page (the little star icons on the right-hand side are blank). Select the page link
Client Side Page.


Figure 103. Finding a page via tags


The Client Side Page page is now displayed. If, based on your review of the page, you want to
rate it, select Actions --- Rate (see figure 104).

Figure 104. Rating a page



The pop-up window, Rate Client Side Page, displays (see figure 105). Note that you are the first
to rate it (the Community rating stars are blank). Let's help the community to judge this page by
giving it a rating, say, four stars; click Save.

Figure 105. Rating a page

10. Once saved, you can see statistics of the page's rating (see figure 106). Click Done, to return to
the view mode of the page itself.


Figure 106. Reviewing the ratings of a page

6.6 Admin portlets: Manage Static Pages

Here we create a static page with dynamic content and then add this created page as a static page
into a portal.
The Manage Pages portlet lets us create, edit, activate, order, and delete normal pages---as well as
static pages or external Web pages and labels. A static page can be created by use of a standard
HTML editor and will be updated to demonstrate the WebDAV feature in Section 6.7 of this paper.
Alternative tools are Portal scripting interface, XMLAccess, and WebDAV.

To begin, let's open a sample Web page, for example,

Save the page; to save time the file was provided as part of the package (see figure 107).


Figure 107. Open sample Web page


Now switch back to the browser as admin (wpsadmin/wpsadmin).

Open the Manage Pages portlet and navigate to the location (see figure 108).
Select Administration --- Portal User Interface --- Manage Pages, and then select Content Root Home; then click New Page.


Figure 108. Manage Pages portlet


In the Page Properties window (see figure 109), enter the following general information for the
new page:


Title: StaticTestPage
Unique Name:
Friendly URL name: staticTestPage

For the Type of Page field, select Static Content, and then click the Set page layout properties


Figure 109. Page Properties window


Now enter the page properties that are specific for the static page (see figure 110):

Static Page Layout File: Portal.htm

ZIP or HTML File Location: C:\labfiles\

(The file was provided as part of the package.)


Click OK to confirm, and click OK on the parent page as well, to create the static page.


Figure 110. Page properties

10. Now an additional page, called StaticTestPage, is created and listed (see figure 111).
Figure 111. StaticTestPage listed

11. Click Home at the top of the Manage Pages window, to navigate to the new page (see figure

Figure 112. Complete static page

12. Click the StaticTestPage URL, to see the complete static page (see figure 113). Note that the
URL for the static page is still within WebSphere Portal.
Figure 113. URL for static page

6.7 WebDAV
Our goal here is to use WebDAV to modify our static page. WebDAV can be used for managing
pages and static content, together with mashup integration, and for Web content management as well
as managing themes and skins.
It can also be used to browse through the page hierarchy, and to change globalization information and
metadata of pages. For static pages, users can browse, read, create, update, save, copy, move, and
delete static content.

Note that the test static page must be previously deployed. Alternative tools are XMLAccess, Portal
scripting, and Admin portlets.
There are different WebDAV clients that can be used; in the sample below we show the client that is
part of Windows XP.
To modify the title of a static page, configure a network place in Windows:

Open the Windows explorer and click Tools --- Map Network Drive (see figure 114).

Figure 114. Map Network Drive in Windows


In the Map Network Drive dialog box, select Sign up for online storage or . (see figure 115).

Figure 115. Open WebDAV with Windows


In the Add Network Place wizard, click Next (see figure 116).


Figure 116. Add Network Place Wizard Welcome window


Select Choose another network location and click Next (see figure 117).

Figure 117. Select the location



Enter the following URL addressing our page in the Internet or network address field and click
Next (see figure 118):

Figure 118. Enter URL


Enter wpsadmin / wpsadmin as userid and password, enable the Remember my password option,
and click OK (see figure 119).

Figure 119. Enter user name and password



Choose a name for the network location and click Next (see figure 120).

Figure 120. Choose name for network place


Finally, click Finish (see figure 121). If prompted again, enter wpsadmin/wpsadmin.

Figure 121. Successful completion


We now have access to the WebDAV interface of Portal and, based on the URL, are connected to the
page (see figure 122). So now we can, for instance, change the title of the page in
the file or change the metadata settings.
Figure 122. WebDAV interface of Portal for a page

To modify the layout of the sample page, we go to the directory staticcontent, select the
SamplePage.html file, and copy the file with the WebDAV client (e.g., Windows):

Copy the Portal.htm file (see figure 123) to a directory, for example, C:\temp.

Figure 123. Copy the static content for editing


Modify the copied Portal.htm file to include the static page in the portal layout by commenting out
the <HTML> and </HTML> tags (see figures 124 and 125); save the page.


Figure 124. Remove <html> tag


Figure 125. Remove </html> tag


Save the updated page, copy it, switch to the WebDAV window, and paste in the updated htm file:



Switch back to the browser and refresh the static page to see the updated portal layout with the
static page (see figure 126).

Figure 126. Updated static page

7 WebSphere Application Server Admin user interface

Here we use the user interface to modify WebSphere Application Server configurations. This UI is
used when creating, modifying, or deleting WebSphere Application Server settings like dynamic cache
settings and thread pools, or for the management of a cluster or remote nodes.
It cannot be used for modifying WebSphere Portal runtime data like pages and portlets. Alternative
tools are WebSphere Application Server Scripting, ConfigWizard, or ConfigEngine.
In our sample task we create a new user and grant him access to administer one server instance with
the new fine-grained administration capabilities.
To log in to the Integrated Solutions Console (see figure 127):
1. Open a browser and enter https://localhost:10032/ibm/console/logon.jsp.
2. For both the User ID and Password fields, enter wpsadmin; click the Log in button.


Figure 127. Log-in window

To navigate the Integrated Solutions Console:


Select Users and Groups --- Manager Users, and click Create (see figure 128).

Figure 128. Navigate to User Management



Enter serveradmin as the value for the User ID, First Name, Last Name and Password fields (see
figure 129); click Create.

Figure 129. Create a user


We need to grant the user the Monitor role to be able to log in to the Admin Console. Select
Administrative user roles in the left-hand navigation and click Add (see figure 130).


Figure 130. Assigning a role


In the next window we add the serveradmin user to the Monitor role. To do that, select the Monitor
role, search for the serveradmin user, click the button to create the mapping, and confirm by
clicking OK (see figure 131).


Figure 131. Adding a user to a role

5. Finally, click the Save link, to store the changes to the master configuration (see figure 132).


Figure 132. Confirm changes to configuration


Next we create the Administrative Authorization Group and assign our user by selecting Security
Administrative Authorization Groups on the left-hand navigator; click Next.
In the next window (see figure 133) enter PortalAdmin as name of the Authorization Group,
select WebSphere Portal as entity to be managed by the group, and click OK.


Figure 133. Administration authorization groups window


Select the newly created Authorization Group and, in the next window, select Administrative user
roles; click Add.
In the next window (see figure 134) select Administrator, search for serveradmin, and click the
button to add the user to the mapped role. Click OK.


Figure 134. Add user to mapped role

10. Save the change, and log out and log in as the newly created user serveradmin (password
11. Select Servers - Server Type - WebSphere Application Servers. You can see the function of the
new fine-grained administration feature now; the user can administer WebSphere_Portal but can
only monitor server1 (see figure 135).


Figure 135. Server administration

8 Conclusion
As a WebSphere Portal administrator, you can use different tools to modify administration and/or
configuration data. The decision as to which tool to use depends on the task to be performed and on
the preferences of the administrator. For repeatable tasks, it's always recommended to use command
line tools.

9 Resources
Read the wiki article, WebSphere Portal V 7.0 Performance Tuning Guide.
Refer to the developerWorks WebSphere Portal zone.
Refer to the WebSphere Portal Family wiki.
Refer to the WebSphere Portal and Lotus Web Content Manager product documentation.

10 About the authors

Thomas Hurek is a Software Architect at IBM's Research Triangle Park Development Lab. He has
worked on the WebSphere Portal development team for 10 years, focusing on various components
including security and virtual portals. In his current role Thomas supports clients as a lab-based
services consultant and works as Chief Programmer on the development of the product. You can
contact Thomas with any questions on the material in this paper.


Falk Posch is a Senior Software Developer for IBM WebSphere Portal. In the past seven years he
has worked as a developer, team lead, and performance expert on various components of
WebSphere Portal at IBM's Development Lab in Boeblingen, Germany. In his current role he works on
performance and scalability improvements of WebSphere Portal. You can reach Falk at


developerWorks, Domino, IBM, Lotus, Notes, Quickr, Rational, and WebSphere, the IBM logo, and
are trademarks or registered trademarks of IBM Corporation in the United States, other countries, or both.

Microsoft and Windows are registered trademarks of Microsoft Corporation in the United States, other
countries, or both.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun
Microsystems, Inc. in the United States, other countries, or both.

Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.

Other company, product, or service names may be trademarks or service marks of others.