Administering IBM WebSphere Portal 8.

5: A
comprehensive workshop
Thomas Hurek (thurek@us.ibm.com), Software Architect, IBM
Chet Tuttle (tuttlec@us.ibm.com), Software Engineer, IBM
Falk Posch (Falk.Posch@de.ibm.com), Software Engineer, IBM
September 2014
Copyright International Business Machines Corporation 2014. All rights reserved.
Summary: The goal of this white paper is to explain the various administration and
configuration tools offered by IBM WebSphere Portal 8.5. Learn about which tool to use for
which task and about the new capabilities of WebSphere Portal 8.5, 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.............................................................................5
3 Installing WebSphere Portal....................................................................................................5
4 Understanding the WebSphere Portal file system structure..................................................25
5 Installing the latest Combined Cumulative Fix.......................................................................32
6 Command line tools...............................................................................................................42
6.1 ConfigEngine.................................................................................................................42
6.2 ConfigWizard.................................................................................................................44
6.3 Command line tools: WAS scripting...............................................................................53
6.4 XMLAccess....................................................................................................................56
6.5 WebSphere Portal scripting...........................................................................................64
6.6 ReleaseBuilder...............................................................................................................69
6.7 Solution Installer.............................................................................................................72
7 Administration user interface: Admin portlets.........................................................................77
7.1 Accessing Portal.............................................................................................................79
7.2 Admin portlets: Manage User and Groups.....................................................................81
7.3 Admin portlets: Virtual Portal Manager...........................................................................85
7.4 Administration GUI's: Managed Pages...........................................................................89
6.5 Theme Analyzer...........................................................................................................104
7.6 Admin portlets: Web Application Bridge.......................................................................109
7.7 Personalization rules....................................................................................................123
7.8 WebDAV......................................................................................................................132
8 Conclusion...........................................................................................................................142
9 Resources...........................................................................................................................142
10 Author biographies.............................................................................................................143

1 Introduction
In this white paper, we explore the newly added and already existing administration tools for
managing IBM WebSphere Portal 8.5 on IBM WebSphere Application Server 8.5.5.
The exercise is separated into the following sections:

Briefly introduce WebSphere Portal and how configuration information is used.

Step through installing WebSphere Portal.
An overview of the new File System structure.
Install the latest maintenance.
An introduction to ConfigEngine and listing the virtual portals using ConfigEngine.
Explore modifying portal security using the Configuration Wizard.
WebSphere Application Server scripting.
Use XML Access to create a baseline, then use XML Access to deploy a portlet and page.
Create a page using the Portal Scripting interface.
Create a comparison release (delta) using the Releasebuilder tool.
Use the Solution Installer tool to install the Scripting Portlet package.
Explore the Portal UI.
Learn how to manage users and groups
Check out virtual Portals
Explore the new 8.5 UI to manage pages.
Use the Theme Analyzer.
Explore Web Application Bridge it is a new proxy solution in WebSphere Portal to integrate
backend web sites fast and easy.
Learn to create and use Personalization Rules.
Learn to use WebDav, a newly supported standard to update Portal settings.
Finally we will use the WebSphere Application Server 8.5.5 Admin Console.

If you are more interested in the command line tools, then you can start with Section 5; if you are
more interested with the user interface, you could start directly with Section 6.

Formatting/hints
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. Our server
name here is localhost. Replace these server names with your local host name on which
WebSphere Portal is installed.

Environment
During the install, WebSphere Portal does the following:

Installs the IBM Installation Manager (IIM), if not already there

Creates WAS 8.5.5
Lets you choose the Installation directory; for example, C:\ibm\PortalServer or
/opt/IBM/WebSphere (you can choose another directory, but you then must adjust
2

references in this document accordingly)

Creates the Derby database, which contains the WebSphere Portal tables
Enables file-based security after the install
Creates the Portal Administrative user, wpsadmin / wpsadmin (you can choose another
password during install, but then you must adjust references in this paper accordingly)

2 What is WebSphere Portal?

IBM WebSphere Portal products provide enterprise web portals that help companies deliver a
highly-personalized, social experience for their customers. WebSphere Portal products give users
a single point of access to the applications, services, information and social connections they
need. These products help increase visitor response and reduce web operations cost while
offering a range of capabilities to meet your business needs.
WebSphere Portal is installed on top of WAS, 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
Industry and Business Partner Solutions
Pure ApplicationSystems

SoftLayer

Web Experience Hypervisor Patterns

for WebSphere Portal and WCM

Web Experience Hypervisor Patterns

for WebSphere Portal and WCM

Worklight Server

WebSphere Portal Server

Server & Client
Side Aggregat ion

Page and Content Aggregation Services

Rules

Dynamic
Content

Themes &
Skins

Page & Content

Handlers

WevDAV

Feed Provider

XML Access & Port al

Scripts

WebSphere Portal Port let Container and Services

Port let API &
REST Interfaces

Impersonization

Feed Reader

WCM Rendering

Tagging & Rating

Search

Live Text &

Port let Wiring

Port al Model

AJAX Proxy

Portlet
Preferences

Site
Administ ration

Credent ial Vault

Personaliizat ion

Sit e Analyt ics

Web Application
Bridge

Rich Text
Edit or
WCM Social Media
Publisher

XML Access & Port al

Scripts
Mobile Devices

WCM API &

REST Interfaces

Site Design

Authoring

Content
Provisioning

Content
Approvals

Syndicat ion

Web Content
Integrator

Projects

WebSphere Application Server Network Deployment

Serlet Engine

Social Software
& Services

Ent erprise Apps &

Content

Feeds

Tools

Web Content Manager

J2EE

Remot e Port let

Consumer

Web Services

BPM & Workflow

Engines

JDBC

Securit y/SSO

Remote Portlet
Producer

Forms Experience
Builder
Process Designer
Worklight Consumer
Edition
Rational Application
Developer
Web Experience
Factory

EMM - Analytics
Engines

Clients as browsers or mobile devices gain access to the portal via the HTTP(s) protocol, and the
request arrives at WAS, which routes it to the WebSphere Portal servlets, portlets, widgets, and
other server side components.
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
3

Web page is then sent via the HTTP(s) protocol back to the client device, which renders the
response including execution of javascript frameworks and, depending on the client, the response
can be returned in a different form of html (responsive or adaptive design).

2.1 Configuration information

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

WebSphere Portal uses the underlying WAS to serve requests

WebSphere Portal configuration data is stored in both the databases and the file system
WAS 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, to connect to your databases or LDAP Server(s), to IBM Lotus Domino mail
servers, to 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 document are for the Microsoft Windows / RedHat Linux
operating systems. It is possible to use any other multi-platform operating system, but the
directories would need to be adjusted accordingly.
4

First, obtain the WebSphere Portal V8.5 install media, which can be retrieved from, for example,
the IBM Passport Advantage Web site.
Section 3 provides a step-by-step guide through the install of WebSphere Portal. If you already
have an install, you can start directly with Section 4.

3 Installing WebSphere Portal

In this section we show how to install WebSphere Portal. If you have already installed WebSphere
Portal 8.5, you can skip this chapter or just read over the figures to better understand how to
perform the install.
IBM Installation Manager (IM) is an eclipse-based tool that is used to install WebSphere Portal, as
well as several other IBM products. Customers who already have this tool (at the v1.7.1 level or
later) can use it to install WebSphere Portal directly from Passport Advantage. You can also
download electronic images or request physical DVDs which provide everything you will need if
starting from scratch. This image/DVD will install IM, if it is not already present, then launch IM to
install:

IBM WebSphere Application Server including the Java Virtual Machine

Recommended Application Server fixes that will allow Portal to work better

IBM WebSphere Portal binaries and the Configuration Wizard profile

The WebSphere Portal install offers multiple options to customize the install:
Mode of Install: Installing from local media or network
IBM Installation Manager: If not existing it will install an IBM Installation Manager instance for
you

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)

Language: The Install Language of the Portal.

URI: URL of the Portal.

Profile configuration options like name of the profile, ports, creating additional profiles.

Profile Definition: For WebSphere Portal you can choose to create a profile during installation
or perform a binary only install and create the profile later.

* IBM(R) Installation Manager for Rational(R) Software Delivery Platform is an installation

management tool that installs and maintains Installation-Manager-based software packages. IBM
Installation Manager enables you to modify feature sets, search for updates, uninstall, and
manage the licenses of installed software.

WebSphere Portal is using the IBM Installation Manager to install WebSphere Application
Server and WebSphere Portal. You can either use the Install shell provided by Portal or
install directly with IBM Installation Manager. The minimum version of IBM Installation
Manager required is 1.7.1.
1.

From the WebSphere Portal 8.5 media launch the ./setup.sh (Linux or Unix) or setup64.exe
(Windows) command:

Figure 3. Starting the Installation

This brings up the WebSphere Portal Launchpad.

2.

Select Install Portal and select Install IBM WebSphere Portal if you have local media or
expanded electronic images.

3.

Select Install IBM Installation Manager only to install just the IBM Installation Manager tool on
its own and then install WebSphere Portal from it e.g. from the Passport Advantage site.

New with this release we provide the ability to install DB2 from the Launchpad as a shortcut.
Figure 4. Triggering the installation

If you do not have IBM Installation Manager installed the install will prompt you to install it.
4.

In the install panel click Next.

Figure 5. Verifying installation of IBM Installation Manager

In the licensing panel verify the license, select I accept the terms in the license agreement and
click Next.
Figure 6. Accepting the license of IBM Installation Manager

5.

In the next window choose an installation directory for the IIM and click Next (see figure 7).

Figure 7. Choose a location for the IIM

6.

In the Summary window, verify the information and click Install (see figure 8).

10

Figure 8. Verify the IIM installation information

7.

After the install finishes a Status window displays. Click Restart Installation Manager
to trigger the install of Portal.

11

Figure 9. Status of the IIM installation

8.

After the IIM has restarted, the Start window displays. You can install products, modify the
installation of the products (for example, by adding new features), update the products (for
example, apply ifixes or fix packs), undo changes, manage licenses, or uninstall products.
Select Install to trigger the install of Portal.

12

Figure 10. IIM Start window

The Install Packages panel allows you to select the packages you want to install. Since we do not
have an existing install of WebSphere Application Server 8.5.5.2, we select not only WebSphere
Portal Server but also WebSphere Application Server and the JDK version 7. The WebSphere
Portal Enable is an additional package to the WebSphere Portal package adding an additional
content feature that WebSphere Portal Server package does not include.
9.

After selecting all check boxes select the Show all Versions box and click on the check for
Other Versions, Fixes and Extensions button to check for the latest versions. In the
Authentication window enter your IBM ID and click OK.

13

Figure 11. Select packages to install

10. The next panel allows you to select the additional fixes for both WebSphere Portal and
WebSphere Application Server. We need the two on the list select them and click Next to
trigger the Install of Portal.

14

Figure 12. Select fixes to be installed

11. In the next panel you can review the license agreement click I accept and then click Next.

15

Figure 13. License Agreement

12. In the next window, select the location where WebSphere Portal and WAS will be installed;
click Next (see figure 14).

16

Figure 14. Select directories for WebSphere Portal and WAS

13. Select additional language packages that need to be installed; click Next (see figure 15).

17

Figure 15. Select installed languages for WebSphere Portal and WAS

18

The next panel allows to customize which features are installed.

For WebSphere Portal, you can choose to create a Portal Server Profile. You can add the Portal
Server Profile later with the Configuration Wizard as well. For this exercise we will have it created
as part of the installation.
14. Review the information in the panel and click Next .
Figure 16. Select components

19

15. In the next panel you need to determine the initial administrative user and profile

configuration for the ConfigWizard profile as well as the WebSphere Portal profile (if it
was selected in the last screen).
For this exercise we have used wpsadmin as userid and wpsadmin as password.
Continue with Enter the Administrator user ID and password for the Portal Server.
Figure 17. Entering the Portal admin ID and password

16. You will enter the node name (it can be any unique name) and the fully qualified host
name you are performing the install on as well as the cell name of the WebSphere cell
that Portal is created in. The node name is relevant for operations inside WebSphere
Application Server when building a cluster (multiple Portals). For the latter exercises
you will need the host name. Also enter the administrative userid and password. For
this exercise we have used wpsadmin as userid and wpsadmin as password.

20

Figure 18. WebSphere Portal profile Configuration

17. In the Advanced mode you can specify a custom context root (instead of /wps/portal) and
custom ports, as well as a custom directory for the profile and the profile name (see figure 19
). Continue with Next.
Figure 19. Advanced Configuration options

21

16. The final window shows a summary of what will be installed (see figure 20). If the values are
as you would like, click Install for the install to start.
Figure 20. Reviewing the Installation settings

22

17. The final panel shows a summary of what will be installed. If the values are correct then click
Install for the install to start.
Figure 21. Finishing the installation

23

24

18. Once the install finished successfully you will see the following panel (sample from Windows
).Click Finish to end the install. If you select to start the Configuration Wizard a browser with
the Configuration Wizard URL will be opened.
You can also create an additional profile with the profile management tool or a Portal
development profile.
Figure 22. Finishing the Installation

4 Understanding the 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
View log files
Install updates

You would not use the WebSphere Portal file system for modifying internal configuration files
directly, bypassing administration / configuration tools.

25

Nearly all the alternative tools mentioned in this topic modify the file system in some way.
In the following pages we will explore the WebSphere Portal file system structure, including the
following:

AppServer directory

PortalServer directory

Profile directory

Profile directory logs

Profile directory WIM/VMM

ConfigEngine directory

ConfigWizard profile directory

Installation Manager Directory

1.

Open a File Explorer and navigate to /opt/IBM/WebSphere/AppServer.

The following are a few of the directories in the figure below that are important when working with
WebSphere Portal:

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 as well as the 1.7 JDK, including
the Java Runtime Edition.

Figure 23. AppServer directory

26

2.

Open a File Explorer Explorer and navigate to /opt/WebSphere/PortalServer. The

directories worth noting in the figure below are:

The PortalServer directory, containing mainly the binaries for WebSphere Portal. In
WebSphere Portal 8.5 the binaries and the configuration and tools are separated;
therefore, the PortalServer directory no longer needs to be touched.

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,

Javascript, Portal Application Archive sample files.

27

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. We would recommend though to define a custom shared library if needed.

Figure 24. PortalServer directory

3.

Open a File Explorer Explorer and navigate to /opt/WebSphere/wp_profile. The Profile

directory (see figure below) 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
28

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
Solution Installer no longer needs to be installed from the Web it is laid down at Install
time.
All the tools are used later.

Figure 25. Profile directory

4.

The runtime logs of WebSphere Portal can be found inside the log directory (see figure 25).
Open a File Explorer and navigate to
/opt/WebSphere/wp_profile/logs/WebSphere_Portal.
The log directory contains a directory for every server instance. For a standalone setup the
29

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 server.
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 26. Profile directory--Logs

The next directory we want to point out is the Virtual Member Manager (VMM) config directory
(see figure below). Navigate to
/opt/IBM/WebSphere/Profiles/wp_profile/logs/WebSphere_Portal/config/cells/wpvmCell_1/wim/con
fig.
5. It contains the user repository configuration data. In some previous releases the configuration
was stored in the WebSphere Member Manager Configuration files (wmm.xml).
Figure 27. Profile directory - WIM/VMM

30

6.

The ConfigEngine directory exists two times in the installation one time inside the profile and
once outside of it. The reason for the ConfigEngine in the root installation directory is to be
able to create and manage additional profiles independent of the existing profile or for a
binary only installation in which no ConfigEngine exists. Navigate to
/opt/IBM/WebSphere/ConfigEngine.

Figure 28. ConfigEngine directory

7.

The Configuration Wizard is a user interface based tool to configure the Portal. With version
8.5 we have extended it a lot to make the configuration easier. It resides within its own profile.
Navigate to /opt/IBM/WebSphere/Profiles/cw_profile.
Similar to the wp_profile the same directories exist for this profile. Important subdirectories are the
logs directory to see the logs and the bin directory to administer the profile.

31

Figure 29. ConfigWizard profile directory

5 Installing the latest Combined Cumulative Fix

In this section, we discuss how to upgrade WebSphere Portal and Web Content Manager to the
latest available Combined Cumulative Fix (CCF).
WebSphere Portal regularly provides maintenance in form of CCFs, which are a rollup of single
fixes bundled as a single tested package. The packages are cumulative, meaning you can install
the latest available CCF without having to install any CCFs in between. CCFs contain single fixes

32

from all components: WebSphere Portal Base, Web Content Manager, Personalization, etc.
Starting with version 8 the maintenance packages can be installed in the following two ways:

Using the IIM User Interface

Using the command line options of the IIM, either passing parameters via the command line
or via a response file

In this exercise we will install the latest CCF with the IIM User Interface. At the time this document
is written, the latest CCF for WebSphere Portal 8.5 is CCF 01; however, be aware that a later CCF
might be available as you read this. We recommend to take the latest available CCF. For the
instructions for installing a CCF, refer to the wiki article, IBM WebSphere Portal 8.5.0.0 Combined
Cumulative Fix Readme stand-alone.
Although we cover only the installation of the Portal CCF in this document, we also recommend
upgrading WAS; the process is similar and is also done via the Installation Manager.
1.

The Portal Server must be stopped to install maintenance. To do this, open a command
window, switch to the directory /opt/IBM/WebSphere/wp_profile/bin , and then
execute the following command (see figure 29):
./stopServer.sh WebSphere_Portal -user wpsadmin -password wpsadmin
On Windows you would run stopServer.bat WebSphere_Portal -user wpsadmin
-password wpsadmin

Figure 30. Stopping WebSphere Portal

2.

Start the IIM User Interface by triggering (on Windows) the executable Installation
Manager\eclipse\IBMIM.exe or, on Linux,
/opt/IBM/InstallationManager/eclipse/IBMIM
The IIM Welcome window displays (see figure 30); click the Update button.

33

Figure 31. Starting the IIM for Update

3.

In the next window, you can select which packages to update (see figure 31). In our case we
want to update WebSphere Portal to CCF01. Select IBM WebSphere Portal Server
v8.5 and select Next.

34

Figure 32. Select the product to be updated

After selecting the product, IIM connects to the IBM Maintenance and Support site and searches
for fixes that are applicable to the installed version (see figure 32). Select the latest available CCF,
in our case, CCF1, and click Next.

35

Figure 33. Select the CCF

4.

The License agreement displays; click Accept and click Next.

36

Figure 34. License window

The Update Packages window lets you select certain features of Portal to be updated (see figure
34). Do not change the selection; just click Next.
Figure 35. Update Packages window

37

5.

Verify the information in the Summary window and then click Update, to trigger the update
process (see figure 36).

38

Figure 36. Summary window

The update process involves downloading the fix pack, applying the updates to the binary files,
and then running several configuration tasks to update the deployed .ear files and possibly also
perform database updates.
If the upgrade was successful you should see a success window as shown in figure 37; click
Finish to complete the upgrade process.

39

Figure 37. Final update window

After running the Installation Manager it is necessary to run a set of configuration tasks to update
the profile.
6.

Open a command prompt and change to the directory

/opt/WebSphere/wp_profile/ConfigEngine. Then execute the config task
ConfigEngine.sh PRE-APPLY-FIX. See the syntax below. On Windows you would use
ConfigEngine.bat.

Figure 38. Pre-Apply fix command

After running the config task check for the success message:
Figure 39. Success

40

7.

Open a command prompt and change to the directory

/opt/WebSphere/wp_profile/ConfigEngine. Then execute the config task
ConfigEngine.sh APPLY-FIX -DPortalAdminPwd=wpsadmin -DWasPassword=wpsadmin. See
the syntax below.

Figure 40. Pre-Apply fix command

After running the config task check for the success message:
Figure 41. Success

41

At the end of the process Portal is left started, so you can continue with the next exercise.

6 Command line tools

Now let's focus on the command line tools.

6.1 ConfigEngine
The ConfigEngine command line tool is used to execute all WebSphere Portal Config tasks. Use
the tool for configuration changes such as 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).
Note: With WebSphere Portal 8.5 the ConfigWizard has been extended and is the tool of choice
for executing configuration tasks. We recommend to use the ConfigWizard where possible (not all
tasks have been included) but support using the ConfigEngine tasks as well.

42

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 below).
Figure 42. ConfigEngine Input values via property files

The most important input property files are:

The wkplc.properties file, which is the main configuration file

wkplc_comp.properties, containing Advanced Security, Process Integration, URL
configuration
wkplc_dbdomain.properties, containing the configuration settings for Database
configuration.
wkplc_dbtype.properties, containing the configuration settings for Database driver
configuration.

Execute the command in the directory, /opt/WebSphere/wp_profile/ConfigEngine, as

follows (see figure below):
./ConfigEngine.sh list-all-virtual-portals -DPortalAdminPwd=wpsadmin
-DWasPassword=wpsadmin
Figure 43. Triggering the ConfigEngine command

43

where the syntax is as follows:

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

The Figure below shows the output of the command.

Figure 44. ConfigEngine command output

6.2 ConfigWizard
he ConfigWizard tool lets you execute configuration changes from an easy-to-use UI that guides
the user through the complete flow and allows executing the tasks.
Use it for:

Database transfer
44

Adding a ldap repository

Clustering
Creating a Deployment Manager
Adding an additional Cluster Node
Installing/Uninstalling a Portal Application Archive
Creating/Deleting a profile with Portal
Migration

Don't use it if:

no graphical interface is available

config tasks other than the ones that are part of the ConfigWizard must be executed

Alternative tools are as follows:

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

As an example task, let's show the beginning steps for how to add an LDAP repository:
1.

First, to start the ConfigWizard server, change directory to

/opt/IBM/WebSphere/AppServer/profiles/cw_profile/bin and invoke
./startServer.sh server1 (see figure 41).

Figure 45. configwizard.sh

Start a browser with following URL: http://localhost:10200/ibm/wizard and login with

wpsadmin/wpsadmin by clicking Log in (see figure below).
Figure 46. ConfigWizard Login screen

45

3. Click on Configuration Wizard to see the Configuration Wizard Welcome screen (see figure
below).
Figure 47. Configuration Wizard Welcome Screen

46

4. Take a look at each of the different parent topics and the sub tasks. You can go back by
clicking Home.
For this exercise choose Set Up a Stand-alone Server, select the Enable Federated security
link (see figure below).
Figure 48. Configuration Wizard - Workflow selection

47

4. Keep the default operating system Linux as well as the other default settings for the profile.
Note the forward and backward buttons as well as the cookie trail at the top to go back
when needed. Click the right arrow icon to move forward (see figure below).
Figure 49. Choose operating system

48

5. Leave the settings in the next screen as is; click Right Arrow (see figure below).
Figure 50. Confirm default settings

49

6. In the next window (see figure below), enter all the detailed information for your LDAP.
Choose some sample values (e.g. see screenshot below). Afterwards click the Right Arrow.
Figure 51. Filling out sample values

50

7.

In the next window (see figure below), enter the information specifically for your LDAP.
Choose some sample values (e.g. see screenshot below). Afterwards click the Right Arrow.

Figure 52. Filling out sample values

51

8. In the final window (see figure below), you will see all the steps that will be executed by the
Wizard one by one. There can be automatic and manual steps. You can see the command that
will be called by each step when you click the View Step Command. On the right hand side you
can see the status of each step.
Figure 53. Review and execution screen

52

In consideration of time scroll down and hit the Cancel button.

Figure 54. Cancel the execution

6.3 Command line tools: WAS scripting

53

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
Console.
The Figure below shows the WebSphere Application Server Scripting syntax, where we do the
following:
Change to /opt/IBM/WebSphere/Profiles/wp_profile/bin
Enter ./wsadmin.sh -h
Figure 55. WebSphere Application Server Scripting syntax

54

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 below):
./wsadmin.sh -host localhost -port 10033 -user wpsadmin -password wpsadmin
Figure 56. 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.
2. Enter the following commands to enable tracing (see figure below):
$AdminControl completeObjectName
type=TraceService,node=wpvmNode_1,process=WebSphere_Portal,*
set ts [$AdminControl completeObjectName
type=TraceService,process=WebSphere_Portal,*]
$AdminControl setAttribute $ts traceSpecification com.ibm.wps.engine.*=all
Figure 57. Enable Tracing with wsadmin

4. Access WebSphere Portal in the browser by opening a browser and entering the following
URL:
http://localhost:10039/wps/portal

55

5. Verify that a trace file trace.log was created in the

/opt/IBM/WebSphere/Profiles/wp_profile/logs/WebSphere_Portal directory.
Figure 58. Checking trace.log

6. Disable the tracing again by running the following (see figure below):
$AdminControl setAttribute $ts traceSpecification com.ibm.wps.engine.*=all=disabled
7. Exit the tool by running the exit command.
Figure 59. Disable tracing with wsadmin

6.4 XMLAccess
his command line tool is used to create, modify, and export WebSphere Portal artifacts.
56

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) or the Solution Installer.
The figure below shows the syntax for XMLAccess by invoking ./xmlaccess.sh in
/opt/IBM/WebSphere/Profiles/wp_profile/PortalServer/bin.
Figure 60. XMLAccess syntax

57

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 below shows sample files in /opt/IBM/WebSphere/PortalServer/doc/xml-samples.
Figure 61. Sample .xml files

58

he Figure below shows the import file.

Figure 62. Import file

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

First, change to the /opt/IBM/WebSphere/Profiles/wp_profile/PortalServer/bin directory, and

then trigger the export via the following command (see figure below):
/xmlaccess.sh -in /opt/IBM/WebSphere/PortalServer/doc/xml-samples/ExportRelease.xml
-out InitialRelease.xml -url http://localhost:10039/wps/config -user wpsadmin -password
59

wpsadmin
Figure 63. Triggering the export

The result should look like figure 57.

Figure 64. Request successful message

2. Then, check the result file C:\ibm\WebSphere\wp_profile\PortalServer\bin\InitRelease.xml

(see figure below). In the file, comments are listed at the beginning, and then the different
resources are exported with their settings. e.g. use notepad InitialRelease.xml
Figure 65. Result file

60

61

Check the file for a sample, such as a page:

The tag name content-node shows this is a page or label

The parameter action="update" is used if this file is used as import file and means a contentnode will be updated (or created if not there)
Parameter domain="rel" indicates that this configuration is from the release database
The uniquename identifies the content-node uniquely
Each resource has an internal objectid
A local title for English has been set.
There is a set of parameters
The user and privileged user role have been granted on the page to the group all
authenticated portal users
A content mapping to a piece of WCM content exists

62

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"?>

<request build="20140424-1749" type="update" version="8.5.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="PortalConfig_8.5.0.xsd">
<portal action="locate">
<web-app action="update" active="true" domain="rel"
objectid="Z1_0OKIHCK0KGV000AC87V79N2001" removable="true"
uid="wcmsupport.WCMSupportTools.26e0076942.webmod">
<url>file://localhost/tmp/WCMSupportTools80.war</url>
<context-root>/wps/PA_WCMSupportTools</context-root>
<display-name>PA_WCMSupportTools</display-name>
<access-control externalized="false" owner="undefined" private="false"/>
<servlet action="update" active="true" domain="rel" name="WCMSupportTools"
objectid="ZV_0OKIHCK0KGV000AC87V79N2003" remote-cache-dynamic="false"/>
<portlet-app action="update" active="true" defaultlocale="en" domain="rel"
name="wcmsupport.WCMSupportTools.26e0076942"
objectid="Z2_0OKIHCK0KGV000AC87V79N2005"
uid="wcmsupport.WCMSupportTools.26e0076942">
<access-control externalized="false" owner="undefined" private="false"/>
<portlet action="update" active="true" defaultlocale="en" domain="rel"
name="WCMSupportTools" objectid="Z3_0OKIHCK0KGV000AC87V79N2007"
provided="false" servletref="ZV_0OKIHCK0KGV000AC87V79N2003">
<access-control externalized="false" owner="undefined" private="false">
<role actionset="User" update="set">
<mapping subjectid="all authenticated portal users"
subjecttype="user_group" update="set"/>
</role>
</access-control>
</portlet>
</portlet-app>
</web-app>
</portal>
</request>

63

The WCM Support tools portlet (you can find it here) WCMSupportTools80.war will be imported
from the path /tmp, and you can use the sample file, DeployPortlet.xml, in the directory /tmp:
1. Open command line, change to /opt/IBM/WebSphere/Profiles/wp_profile/PortalServer/bin,
copy the war file in the expected location, and trigger following commands (see figure
below):
./xmlaccess.sh -in /tmp/DeployPortlet.xml -out DeployPortlet_out.xml -url
http://localhost:10039/wps/config -user wpsadmin -password wpsadmin
Figure 66. Open command line and trigger

2. Check the output file, DeployPortlet_out.xml in the

/opt/IBM/WebSphere/Profiles/wp_profile/PortalServer/bin directory:
Figure 67. Check result file

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

6.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 when:

Creating or modifying a limited set of WebSphere Portal resources like pages or portlets
Combining with wsadmin WAS scripts to modify WAS 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).

64

WebSphere Portal Scripting modes

There are two modes in WebSphere Portal Scripting:

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

The second is Scripting mode, which allows us to 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:

/opt/IBM/WebSphere/Profiles/wp_profile/PortalServer/bin

2.

Invoke the scripting interface, using the jython scripting language:

./wpscript.sh -lang jython

3.

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

Figure 68. Login at the Target Server window

4. Log on to the portal, using the following script command (see figure 62):
Portal.login(wpsadmin,wpsadmin)
Figure 69. Log on to the portal

65

5. List all available projects by running the following command :

Project.listall()
6. List all Content Libraries for the current virtual Portal with the following command:
DocumentLibrary.listall()
Figure 70. List all libraries

7.

Select the parent page of our new page by first finding the parent page (see figure below)
Content.find(all, uniquename, ibm.portal.Home)
and then selecting the page:
Content.select("Z6_00000000000000A0BR2B300GO2")
Figure 71. Find and select page

6. Create an empty page and immediately select this new page (see figure below):
Content.create(page,TestPage,html,public,select)
Figure 72. Create and select empty page

66

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

Content.set(uniquename,wp.test.page)
Figure 73. Set unique name

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

67

Scripting mode
Now let's modify the created test page, this time using the Scripting mode:
1. Create a file UpdateLayout.py in the directory
/opt/IBM/WebSphere/Profiles/wp_profile/PortalServer/bin with the content in listing 2 (you
can use the UpdateLayout.py file in the /tmp directory):
Listing 2. Script for UpdateLayout.py

# login to portal
Portal.login("wpsadmin","wpsadmin")
print " 1. login done."
# select page
Content.select(Content.find("all","uniquename","wp.test.page"))
print " 2. page selected"
# search portlet
portletA = Portlet.find("portlet", "name", "WCMSupportTools")
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 support portlet."
# logout again
Portal.logout()
print " 6. logout."
print
print " Processing done."
where # denotes a comment, print prints a message to the command line, and the
sequence of the script is:
Login
Locate the page
Create a container on the page to hold the portlet
Put the portlet into the container
Logout
The script will update the page we created earlier with the Interactive mode, and the portlet
deployed earlier with XMLAccess will be added to the page.

68

2. Invoke the script to set the layout for the new test page (see figure below):
./wpscript.sh -user wpsadmin -password wpsadmin -lang jython -f /tmp/UpdateLayout.py
Figure 75. Invoke script

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

6.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 Managed pages feature.
You use ReleaseBuilder to generate a diff file. Before you can use ReleaseBuilder, however, you
must generate the next release export using xml access:
1.

Open a command prompt and change to directory

/opt/WebSphere/wp_profile/PortalServer/bin

2.

Generate the release export by invoking following command (see figure 68):
./xmlaccess.sh -in /opt/WebSphere/Portal/doc/xmlsamples/ExportRelease.xml -out ChangedRelease.xml -url
http://localhost:10039/wps/config -user wpsadmin -password wpsadmin

Figure 76. Generate the release export

69

The result should look like that shown in figure 69.

Figure 77. Release export result

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

From the directory /opt/WebSphere/wp_profile/PortalServer/bin, start

./releasebuilder.sh without any parameter to check the syntax (see figure 70).

70

Figure 78. Start releasebuilder

2.

Now we generate the difference between the release export we did at the beginning of this
paper and the release export we just created. To do this, execute the following command (see
figure 71):
./releasebuilder.sh -inOld InitialRelease.xml -inNew
ChangedRelease.xml -out ReleaseDiff.xml

Figure 79. Generate the difference

3.

Check the resulting ReleaseDiff.xml, as shown in figure below (for example, gedit
ReleaseDiff.xml).

71

Figure 80. Resulting ReleaseDiff.xml

Notice that the file contains the Web application defining the portlet as well as the page
(content-node) and the portlet on the page. Also note the new proxy-config settings the
former AJAX proxy configuration is now part of XMLAccess and so can easily be staged.
4.
Now check for the page we created (TestPage) and the portlet
(WCMSupportTools80.war) we deployed after the initial export.
The ReleaseDiff.xml file can be used to import your changes to another system that's
prepared to receive these changes.

6.7 Solution Installer

You can use the Solution Installer to install, uninstall, and update solutions or applications to an
IBM WebSphere Portal server instance. The Solution Installer uses the Portal Application
Archive (PAA) format as the standard format for application distribution.
Portal Administrators can use the Solution Installer to install existing PAA-formatted applications to
the WebSphere Portal server instance. Portal Solution Developers can use the Solution Installer to
install PAA-formatted applications they develop for their company.
The solution installer can be used to deploy different artifacts:

Enterprise Applications

Portlets

Run XMLAccess
72

Run ant scripts

Run Portal or WAS Scripting
Deploy and Update WCM Libraries
Deploy Personalization rules

It is frequently used to deploy Portal Catalog solutions that are provided by the Portal and WCM
Development Teams but it is also possible to use it to create your own application packages.
While with previous releases of WebSphere Portal the Solution Installer had to be installed
separately, it is part of WebSphere Portal 8.x.
Alternative tools are Portal XML Access and Portal Admin Portlets (limited set of tasks) or Portal
Scripting.
New with version 8.5:
You can export the artifacts into an initial Portal Application Archive on the source system
including themes, war files, pages and portlets,
After the initial release you can build a differential release with the Portal Application Archive
format.
In this exercise we will deploy the IBM Script Portlet package that is provided on the catalog at the
following URL:
https://greenhouse.lotus.com/plugins/plugincatalog.nsf/assetDetails.xsp?
action=editDocument&documentId=DDB5C467D991413285257C67002476E0
The package consists of a portlet and WCM content.
Later on we will try out the task to export all artifacts for an initial staging.

73

The installation of a PAA archive consists of two steps the install that lays down the files and the
deployment that invokes the configuration steps and scripts.
Execute the following command in the directory,
/opt/IBM/WebSphere/Profiles/wp_profile/ConfigEngine, as follows (see figure below):
./ConfigEngine.sh install-paa -DPAALocation=/tmp/scriptportlet.paa
-DWasPassword=wpsadmin -DPortalAdminPwd=wpsadmin
Figure 81. Triggering the Install PAA command

Verify that the output looks like in the following figure:

Figure 82. Verifying the Install PAA command

Now that we have installed the PAA we need to trigger the deployment.
In the same command line trigger the following command:
./ConfigEngine.sh deploy-paa -DappName=scriptportlet-app -DWasPassword=wpsadmin
-DPortalAdminPwd=wpsadmin
Figure 83. Triggering the Deploy PAA command

Verify that the output looks like in the following figure:

Figure 84. Verifying the Install PAA command

74

Next we will try out the new configuration task to export the initial release for a staging to
production using the Portal Application Archive.
Execute the following command in the directory,
/opt/IBM/WebSphere/Profiles/wp_profile/ConfigEngine, as follows (see figure below):
./ConfigEngine.sh build-initial-release-paa -DdestPAADir=/tmp -DWasPassword=wpsadmin
-DPortalAdminPwd=wpsadmin
Figure 85. Triggering the export initial release PAA command

Verify that the output looks like in the following figure:

Figure 86. Verifying the export PAA command

You can add the following parameters to customize the build-initial-release-paa task:
sharedAppResourcesRootDir
The directory for .jar files, classes, and compressed files that are then stored in the shared/app
directory.
sharedExtResourcesRootDir
The directory for .jar files, classes, and compressed files that are then stored in the shared/ext
directory.
appsToExtract
A comma-separated list of applications to extract from the source environment. For example,
you might extract the wps_theme,iehs,dojo_resources files. They are then packaged in the PAA
file.
exportWebDavTheme
Enter a value of true to download and include the themes.zip file from WebDAV.
exportWcmData
Enter a value of true to export all Web Content Manager libraries. The export-wcm-data task is
run when you use exportWcmData.
Restriction: Do not use this parameter in place of syndicating the libraries from the target
environment.
The export we took is from the default base Portal. When having virtual Portals additional
commands need to be run for each Virtual Portal.

75

Let us investigate next what is part of the created PAA. The PAA format is basically a renamed zip
file. Unzip the file /tmp/WebSpherePortal.paa and investigate the different directories:
2 Components WebSpherePortal.shared for data shared across all Portals,
WebSpherePortal.unique for the virtual/base Portal we just exported from.
The subdirectories of each contain the war files, WAS configuration, xmlaccess for the Portal
artifacts, PZN rules, WCM Libraries,
Figure 87. Analyzing the exported PAA file

The exported PAA file can be imported into a target system that has been emptied first.
76

Subsequently you can generate differential PAA releases by using the syntax:
./ConfigEngine.sh build-initial-release-paa -DdestPAADir=directory_to_store_PAA
-DpreviousPAA=initial_PAA -DWasPassword=password -DPortalAdminPwd=password

7 Administration user interface: Admin portlets

The Admin portlets are available with the WebSphere Portal installation and are placed in the
Administration area of WebSphere Portal. By default, as administrator you have access to these
portlets.
Here are some examples of what you can do with the Admin portlets (see figure below):

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 (for example, define and manage search collections)

manage WebSphere Portal analyses and virtual portals

Figure 88. Admin portlets navigation pane

77

Portlets related to Web Content Management, Personalization Rules, as well as Collaboration and
Messaging are located below the Applications tab (see figure below).
Figure 89. Application portlets navigation pane
Sametime
Integration

Personalization
Rules

BPM
Integration

Web Content
Creation

Web Content
Preview

In this section, we choose to 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 new tool bar to create and update a page, Web Content creating, explore project
management, page previewing, and impersonation

understand and leverage vanity URLs

investigate how to use tagging and rating

leverage the new theme analyzer portlet

explore the new Scripting portlet

use the Web Application Bridge to integrate an existing web site

use WebDav to connect to Portal and explore the new theme profiles

78

7.1 Accessing Portal

In this topic we learn how to access the Portal and what the different artifacts in the Portal markup
are.
1.

Open a browser with the URL http://localhost:10039/wps/portal/Home

You will see the Portal UI for the anonymous user:

the Welcome link is a page that is also currently selected

the links on the banner for Sign Up and Login are also pages that can be used for login and
signing up to create a new user id

Note the new toolbar with the drop down for navigation across root pages
Figure 90. Anonymous start page

79

2.

Click the login link and log in with userid wpsadmin and password wpsadmin.

Figure 91. Login to Portal

After the login the default page Getting Started is displayed. The page contains a portlet
displaying some welcome information. The structure of the web site is defined by the theme
which links are displayed, how the navigation looks like, the colors, branding,
See the next figure for details:
Figure 92. Authenticated Area after Portal Login

Currently selected Page

Currently logged in
user

Sibling pages below Home

Portlet on the current page

80

Additional Actions
e.g. for Analytics

Logout

New with version 8.5 we have introduced the Universal Toolbar it can be used for:

Navigation e.g. to the Administration area

Project Management
Management of Pages and Labels

Creating a page

Deleting a page

Modifying a page and its content

Moving a page or label

Preview

See the next figure for details:

Figure 93. Universal Toolbar
Project Selection

Toggle Edit Mode

Toggle Modification
Options

Navigation

7.2 Admin portlets: Manage User and Groups

In this topic we use the Manage Users and Groups portlet (see figure below) to add an 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 94. Manage User and Groups portlet

81

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:
1. Open a browser with http://localhost:10039/wps/portal and log in with userid wpsadmin and
password wpsadmin.
2. Use the toolbar to go to Access:
Figure 95. Navigating to User and Groups

3.

Then go to Users and Groups, and click the New User button (see figure below).

Figure 96. Create new user

82

3. Enter at least following information to create a user (see figure below):

User ID
Password
Confirm Password
Last Name
Figure 97. Enter user information

83

4. Confirm the user creation by clicking OK; you should see the User created successfully
message (see figure below).
Figure 98. Success message

84

7.3 Admin portlets: Virtual Portal Manager

We use this admin portlet to create a new virtual portal (see figure below) 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 99. 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.

85

To create the new virtual portal:

1. Use the Toolbar to navigate to Virtual Portals > Manage Virtual Portals, and then click the
New Virtual Portal button (see figure below).
Figure 100. Create new virtual portal

2. Complete the virtual portal's information as follows (see figure below):

Virtual portal name: accounts
Virtual portal description: The accounts Virtual Portal
URL Context: accounts
Initial admin user group: wpsadmins

86

Figure 101. Enter virtual portal's information

3. Click OK.

87

You should see the created successfully message and our new The Accounts Virtual Portal listed
in the portlet (see figure below).
Figure 102. Confirmation of creation

4. Log in to the newly created Virtual Portal (see figure below) by specifying the URL context
(http://localhost:10039/wps/portal/accounts). Click Login.
Figure 103. Login screen

88

The figure below shows the Administration area of a virtual portal, within which you have a limited
set of administration tools.
Figure 104. Administration area

7.4 Administration GUI's: Managed Pages

Managed pages and the Universal Toolbar streamline site management in your portal by
simplifying how you create pages and add content. Because page information and content are
stored in web content libraries, you can more easily coordinate and publish changes with
syndication.
Managed pages are portal pages that are stored in IBM Web Content Manager. By managing
portal pages from within Web Content Manager, you can apply features like workflow, version
control, and syndication to portal pages.
When you perform a new installation of IBM WebSphere Portal, managed pages are enabled by
default.
The following administrative capabilities are exposed inside the theme without having to use the
Admin portlets under the Administration tab:
The following already existed with Portal 7:

Creating a Page, Deleting a Page, Moving a Page

Modifying a page:

Adding or removing portlets

Modifying portlet properties and settings

Changing the style

Changing the layout

89

Assign Permissions
Tagging and Rating

These were added with Portal 8.0:

Creating and managing a project

Analytics
Preview
Approval

New with Portal 8.5:

Managing Labels

Vanity URLs

Dojo is not used any more for the main window during edit mode

Edit mode is now enabled for mobile devices

Workflow enhancements to manage items inside a project

The page management now happens as part of a WCM project. You can combine WCM and
Portal page modifications into the same project. Projects have their own life cycle they follow an
approval process and allow to use versions.
A test user must be previously created, and alternative tools are XML Access and the Manage
Pages portlet.
We will first create a project that we will use to make the page changes with.
To create a project:
1. If still logged in, logout.
2. Log in to the default Portal as wpsadmin (http://localhost:10039/wps/portal)
3. Select the Published Site link.
4. Click the New Project button (see figure below).
Figure 105. Trigger project creation

90

5. Enter a name for the project. Note the new ability to use project templates that already
define certain default settings.
Hit the Create button.
Figure 106. Creating a project

After creating the project the Theme directly switches to the Edit Mode of the current page.
Note that there is a link now to jump back to the View Mode to view the changes you have made.
Also note that the display now happens as part of the project we created. The project
MyFirstProject is selected. The items that are part of the project are displayed at the moment
there is no item. The new project menu allows you to configure the project, exit it and additional
options like creating a project template out of the current project.
Figure 107. Success screen for project creation

91

We want to create a new page next.

1.
2.
3.

Select the Create Button

In the new dialog select the Next Sibling of current Page option. It will create a page at the
same level as the currently selected page.
Enter a page name and friendly url and hit Create. Note the Page Template option. A page
template defines a structure and settings for a page e.g. the assigned Web Content
Management Site Library or the portlets on the page. You can create your own templates and
reuse them later.

Figure 108. Creating an empty page

92

See the newly created page being displayed and selected. At the moment there is no content on
the page.
Select the Applications link in the shortcut section.
Figure 109. Edit the empty page

93

Note the different categories of Applications one can add.

Enter Script Portlet in the search dialog.
Figure 110. Edit the empty page

94

Click the plus icon besides the portlet or use drag and drop to put the portlet on the page.
See figure below.
Figure 111. Adding the script portlet

95

Enter Syndicated Feed Portlet in the search dialog and drag and drop it on the page.
Figure 112. Add a feed portlet

After having added the feed portlet to the page you can see that both portlets were added. The
feed portlet is pointing to a default feed while the script portlet does not show anything yet.
Let's see how it looks like for an end user by using the preview function. Note that a normal user
would not see the current page as it is in draft mode and the project has not been published.
The Preview mode allows us to see how an end user would see the page after it has been
published.
Select Menu -> Preview As User.
Figure 113. Previewing the Page

In the Impersonation dialog select a user to impersonate by entering the name of the user we
created earlier (user1) into the search field and click the search icon.
In the resulting dialog select the radio button in front of the user and click the Impersonate button.
With that you effectively become this user and so can review what he will see after the page has
been published.
Figure 114. Impersonating the user

96

After triggering the Impersonation you can see the page as the user would see it. Note the
selected project. Also note the userid that is displayed you know show as user1 that you
impersonated.
Click the Stop Previewing button to undo the impersonation and become the admin user again.
Figure 115. Previewing the page as impersonated user

97

Now that we are the admin user again we want to continue modifying our page.
Select the Page -> Style section and select a style.
Figure 116. Selecting a style

The layout of the page determines which content is displayed where on the page.
Select the Layout tab and select a different layout.
Figure 117. Selecting a layout

98

The new vanity URL feature let's you create a short URL for a resource in Portal outside of
hierarchy.
Select the Vanity URL tab and enter a URL.
Figure 118. Entering a vanity URL

99

In the View mode you can see how the page will look like. Note that you see the page version as it
is part of the project you created. It is still a draft page.
Select the project and select the Published Site state to see how the page looked before the
modifications we made.
Figure 119. Viewing the page

In the published state we can see that the page does not even exist.
Let's go back to the project and publish it.
Select Published Site and select our project.
Figure 120. Viewing the published state

Select the Project at the top and click the Manage link.
Figure 121. Entering Project Management

100

Notice that all the items we worked on are part of the project.
Select the different items and click More Approve. Typically this task would be handled by a
different person or group e.g. your boss.
Figure 122. Project management

101

Notice that after the Approval the documents / page are now in Publish Pending state.
We will now publish the project by pressing the Publish Project button.
Figure 123. Publishing the project

102

Note that now that we have published the page the new page is showing in the Published Site
state.
Select the new page and have a look.
Figure 124. Viewing the modified page after publication

103

Let us try the vanity URL we created. Enter the following URL and notice that the URL changes to
our page: http://localhost:10039/wps/vanityurl/MyFirstPage
Typically you would create a rewrite rule at the HTTP server that would redirect the vanityurl
/MyFirstPage to the longer form as we entered and so you could have tiny URLs.
Figure 125. Using a vanity URL

6.5 Theme Analyzer

WebSphere Portal 8 introduced the Theme Analyzer on the Catalog. With version 8.5 we ship the
Analyzer out of the box. In this exercise we will explore it.
Use the Theme Optimization Analyzer to view, but not edit, all parts of the theme optimization
framework inside of WebSphere Portal. With the portlet, you can easily see which pages have
specific profiles that are set or inherited. You can also see which profiles are available and belong
to which theme.
Additionally you can browse and explore all aspects of the available modules: You can see what
modules are loaded for a specific profile or all modules of the whole system. You can drill down
into the dependency hierarchy to understand interdependencies and get different views on it, such
as a parent view. The module explorer also features a rich search set so that you can easily find
modules that contribute certain resources or capabilities, or browse all exposed data.
If you encounter problems, you can also export your set of data as a compressed file and share it
with others. They can then import your data set and examine your profiles and modules.
Home is the welcome screen of the portlet and provides a selection of features that are supported
by this portlet.
1.
2.

Login to Portal as admin (wpsadmin/wpsadmin).

Use the Toolbar to navigate to Portal Analysis and select the Theme Analyzer.

Figure 126. Initial View of the Theme Analyzer

104

3.

Select Examine page profile information. Then drill down to the two new pages we created
and verify the assigned profile.

Figure 127. Examine a page

105

4.

Go back to Home and then select Utilities -> Control Center. Select the Dynamic Content Spot
(Inline) Debug.

Figure 128. Saving tags for a page

106

5.

Go back to Home to one of our pages and examine the inline debug mode it shows which
component / jsp is providing which part of the page.

Figure 129. Dynamic content spot debug mode

107

6.

After examining the content spots use the toolbar to switch back to the Analytics portlet and
turn off the the debug mode.

Figure 130. Disabling debug mode

108

7.6 Admin portlets: Web Application Bridge

The web application bridge uses reverse proxy technology to integrate web-based content
providers, such as the Microsoft SharePoint 2007 server, with IBM WebSphere Portal.
Administrators must first define the virtual web applications or content providers. A lightweight
IFrame portlet displays the content from the backend applications. Users can then access the
IFrame on a page without requiring direct network access to the backend application. A special
engine maps Uniform Resource Identifiers (URIs) on the iFrame portlet to real URIs from the
content providers.
Integrating the web application bridge with WebSphere Portal is a multi step process. The first part
109

of the process is creating an application component from the Web application bridge manager
portlet. The second part requires that you add the Web Dock portlet on a page and then configure
it to point to the appropriate application component.
To begin, let's open a sample Web page, for example:
http://lucene.apache.org/core/
We will integrate this web page with the Web Application Bridge.
Figure 131. Open sample Web page

Before you can use Web Application Bridge the context root of the Web Application Bridge .ear
file must be adjusted. This is a one-time operation and does not need to be performed every time
you are integrating another backend application into Portal.
To perform this change we use the WAS Administrative Console:
1.

Log in to the Integrated Solutions Console (see figure below) by opening a browser and
entering: https://localhost:10032/ibm/console/logon.jsp

2.

For both the User ID and Password fields, enter wpsadmin; click the Log in button.

Figure 132. Log-in screen

110

3.

Select Applications Application Types WebSphere Enterprise Applications. Click the

Show Filter Function button, enter wp.vwat.servlet.ear, and click Go (see figure below).

111

Figure 133. Applications Start window

4.

In the next window you see the wp.vwat.servlet.ear file for which you searched. Click the .ear
file to access the properties of the application (see figure below).

Figure 134. Applications Search Result window

5.

In the properties window for the .ear file, locate and select the Context Root for
Modules link (see figure below).

112

Figure 135. Application Properties window

6.

Change the Context Root field to / as shown in figure below; click OK.

Figure 136. Application Context Root window

7.

On the next window, click Save.

113

Figure 137. Application Properties window

8.

If needed, search again for the wp.vwat.servlet.ear application, select the check box in front of
it, and then click Stop (see figure below).

Figure 138. Stop the application

9.

After the application has been stopped, select it again and this time click Start (see figure
below).

114

Figure 139. Start the application

10. Verify that you see the successful start message and then log out of the console by clicking
the Logout button (see figure below).
Figure 140. Start the application and log off

Now that we are done with the WAS change let's switch back to Portal:
1. Now switch back to the browser as admin (wpsadmin/wpsadmin)
115

2. Select in the Toolbar Portlet Management > Virtual Web Application Manager
3. Then select Create Content Provider Profile.
Figure 141. Web Application Bridge Admin portlet

Enter a unique title and enter the URL http://lucene.apache.org. Then press Save.
Figure 142. Create a Content Provider Profile

116

Next we will a policy to allow users to access the backend.

Click Add Policy.
Figure 143. Web Application Bridge Admin portlet

In the next screen we can define multiple configuration settings for the Content Provider, including
Single Sign-On settings. Enter a unique name for the policy and click Save.
Figure 144. Creating access policy

117

Next we will create a web dock portlet application that we can then add to pages.
Select the Web Dock Applications tab and click Create Web Dock Application.
Figure 145. Creating web dock application

118

Next we will fill out the required information for the application and click Save .
Title: Lucene
Content provider profile: Apache
Resource path: /core
Figure 146. Creating a web dock application

119

The next step is to create another Portal page and add the Web Dock portlet to it.
Switch back to Home.
Then make sure that Published Site is selected and toggle the Edit Mode button.
We will this time create the page outside of a project the change is visible immediately then and
no versions are kept.
Then click the Create button.
Figure 147. Switch to Home and trigger Edit

In the Edit mode of the page enter a title and select Next Sibling of current page. Then click the
Create page button.
Figure 148. Result screen

120

Switch to the Page -> Layout area and select the 1 Column layout.
Figure 149. Changing the layout of a page

After the page layout has been modified go to the Menu -> Edit Page Properties option.
Figure 150. Page Properties

Go to the Advanced area and select Web Dock as the profile for the page. The profile determines
which resources are loaded for the page e.g. javascript, css files.
The theme modularization was introduced with WebSphere Portal 7.0.0.2.
The intention of the theme modularization work is to decouple feature enablement from the theme
code itself. This allows themes to be developed more easily from an outside in approach with little
knowledge about the details of how underlying code for a particular feature in Portal works. The
result of this work is to provide logical points where modules can contribute data into a theme at
runtime and to optimize those contributions by combining them when possible.
Scroll all the way down and press the Save button.

121

Figure 151. Changing the profile

Next we will add the portlet to the page. Switch back to Create -> Applications, search for Lucene
and drag it onto the page.
Figure 152. Adding the portlet to the page

122

Switch back to the View Mode and see the integrated backend site that is now proxied via Portal.
Check the links on the page and note that they point to the Portal Server and not the apache Site.
Figure 153. Reviewing the resulting page

7.7 Personalization rules

WebSphere Portal Personalization provides automatic customization of Web site content for
individual users and user groups. Personalization can recognize a specific user based on a profile
or can determine characteristics of a user based on previous purchases, products, pages viewed,
and so forth. Personalization then selects content that is appropriate for that profile.
For example, if a person has a high salary range, Personalization can be configured to retrieve
information about a commercial Web site premium product. If an individual belongs to a particular
geographic region, content specific to that region may be targeted to the individual. When the
page is assembled with the proper personalized information, users see their personalized page.
123

In this simple sample case we create a visibility rule that controls when a page is displayed, only
on a certain day of the week.
We use the Personalization Navigator and Editor admin portlets to create the rule and then use
the Manage Pages portlet to associate the rule with the page. Instead of using the administration
portlets it is also possible to export and import rules using the pznload command line utility. In this
exercise we focus on the admin portlets.
1.

Log in to Portal as Administrator (wpsadmin/wpsadmin) and use the toolbar to go to

Personalization -> Business Rules. The Personalization Navigator lists all the
defined Personalization objects and allows you to create, edit, and delete Personalization
objects like rules (see figure below).

Figure 154. Business Rules tab

124

2.

Select New -> Rule, to bring up the window to create a new rule (see figure below).

Figure 155. Create a new Business rule

3.

In the next window, define the following (see figure below):

Name of the Rule:
Description:
Monday.
Rule Type:
attribute *:
value *:

Monday Rule
This is a visibility rule to display a portlet or page only if today is
Select Visibility Rule from the drop-down box
Select Date Weekday from the drop-down box
Select Monday and then click Submit.

Click Save at the bottom of the page.

Figure 156. Configure a new Business rule

125

4.

In the next window you can see that your Monday Rule has been created (see figure below).

Figure 157. Business Rule creation screen

126

Figure 158, continued

Now that we have created the rule we want to associate it with one of our pages and test that it
works:
1.

To associate the page with the rule, use the toolbar to select Portal User Interface Manage
Pages, and then select Content Root Home and click the Edit Page Properties button as
shown in the figure below.
Note that if you were to select a project before making this change, the association of the rule
to the page would be part of the project. In our case we make the change without a project,
and so the change is visible immediately without a separate approval / review cycle.

Figure 159. Select a page

127

2.

In the Edit Page properties window (see figure below), scroll down, expand the Advanced
options menu, and click the little icon to map a rule. In the pop-up menu, select the Select
Rule option.

Figure 160. Edit Page properties window

128

3.

In the Select Rule window (see figure below), select the Monday Rule we just created and
click OK.

Figure 161. Select Rule window

129

4.

Verify that the correct rule has been selected and then leave the Edit Page properties section
by clicking OK (see figure below).

Figure 162. Edit Page properties

130

5.

Verify that the rule works by navigating to Home and checking which pages are displayed; if
you are doing this exercise on a Monday, the page should appear. On all other days the page
should not display as shown in the figure below; instead, the next page is selected and
displayed.

Figure 163. Executing the rule

131

The Personalization Rules component in Portal is quite powerful. It can be used with Web Content
Manager data as well as Portal data for campaigns and many other scenarios, and the rules can
execute custom logic to have full flexibility.

7.8 WebDAV
Our goal here is to use WebDAV to review the profile configuration of the theme. WebDAV can be
used for managing pages, static content, 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.
Alternative tools are XMLAccess.
We will use the built in Linux client for webdav. In case you are using Windows use a client
software for WebDav like Anyclient
Click on Places -> Connect to Server.
Figure 164. Starting webdav connection

132

Note that there are multiple entry points with WebDav for Portal:
/themelist

Administration of themes

Title, description, metadata (maps directly to DB)

/skinlist

Administration of skins

Title, description, metadata (maps directly to DB)

/fs-type1

Modify static resources directly

Themes, skins, layouts, common resources, iwidgets

/contentmodel

Portal pages
/content

Web Content Manager data

133

For our exercise we will connect to the themelist entry point and explore the profile configuration.
Click New Site and enter the following information...
Service Type:
Server:
Port:
Folder:
User Name:

WebDAV (HTTP)
localhost
10039
/wps/mycontenthandler/dav/themelist/
wpsadmin

Click Connect. When prompted enter the password wpsadm1N

Figure 165. Connecting to Portal

In the resulting screen you can see the list of themes that are deployed in WebDav.
1.
2.

Select the Portal 8.5 theme the name is ibm.portal.85Theme.

Take a look at the files inside the theme and then select the profiles folder.

Figure 166. Exploring the theme

134

Open one of the profiles in the profile folder to look at the profiles (You can right click on the file
and use gedit to look at the file). The structure defines the different modules that are loaded as
part of the model. The deferred profile is the default with 8.5. It defines a minimum set of
components loaded during viewing the page and loads more in case of edit mode.
With 8.5 we introduced hidden profiles that will not show up in the Admin Console that are used
for special pages in Portal.

135

Figure 167. Reviewing the profile definitions

8. WebSphere Application Server Admin User Interface

We will 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, for the management of a cluster or remote nodes.
136

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 tasks we will explore the new features of WebSphere Application Server 8 and 8.5.5
as well as classic operations done via WebSphere Application Server.
To see what is new with WebSphere Application Server 8.5 check:
http://www.redbooks.ibm.com/redpapers/pdfs/redp4870.pdf
To log in to the Integrated Solutions Console (see figure below):
1. Open a browser and enter https://localhost:10041/ibm/console/logon.jsp
2. Enter wpsadmin/wpsamin for User ID and Password fields.
Figure 168. Log-in screen

Take a look at some of the new features in WebSphere Application Server 8.x like the new
automatic directory deployment in the figure below. Select Applications->Global deployment
settings to get to the new feature. It allows to specify a directory WebSphere Application Server
regularly scans for ear files and automatically deploys them if they exist or removes them when
deleting them. That can save quite some administration effort ;)
Figure 169. Automatic directory deployment mode

137

Another new interesting feature is the Extended Repository Service. It allows you take snapshots
of the WebSphere configuration for certain intervals and then compare those to current
configuration or even roll back to them (note though that this does not roll back Portal changes in
the database).
Figure 170. Extended Repository Service

138

Let us have a look at the installed Applications we will see the Portlets and Portal system
applications. Go to Applications -> Application types -> WebSphere enterprise applications
Figure 171. Investigating installed applications

The majority of configuration of Portal is stored inside Resource Environment Providers. Select
Resources -> Resource Environment -> Resource Environment Providers.
In the name column you can see all the different categories of properties we define.
Figure 172. Property configuration

139

Select the WP NavigatorService -> Custom properties. Take a look at the defined settings e.g.
the reload for public pages was set to 3600 seconds.
Figure 173. Review WP NavigatorService Settings

140

As part of the Java Batch Feature pack integration you can now schedule batch jobs from within
the WebSphere Application Server.
Click System Administration->Job Scheduler to get to the job scheduler.
Figure 174. Job scheduler

141

Another new feature we want to point out is the new High Performance Extensible Logging. The
feature speeds up logging and tracing. It also provides more flexible access to log and trace data:
Command line access to filter and format, Administrative console GUI to filter and format local or
remote logs and trace, even when the remote server is down, Programmatic access to filter,
format, and merge local or remote logs and trace.
Select Troubleshooting->Logs and Trace->WebSphere Portal.
Figure 175. Logging and Tracing

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 recommend to use
command line tools.

9 Resources
developerWorks WebSphere Portal zone:
http://www.ibm.com/developerworks/websphere/zones/portal/
WebSphere Portal Family wiki:
http://www-10.lotus.com/ldd/portalwiki.nsf
WebSphere Portal and Lotus Web Content Manager product documentation:
http://www.ibm.com/developerworks/websphere/zones/portal/proddoc.html
WebSphere Portal and Lotus Web Content Manager 8.5 tuning guide:
http://www10.lotus.com/ldd/portalwiki.nsf/dx/IBM_WebSphere_Portal_V_8.5_Performance_Tuning_Guide

142

Recommended Updates for WebSphere Portal and IBM Web Content Manager V8.5:
http://www-01.ibm.com/support/docview.wss?uid=swg24037802
Administering IBM WebSphere Portal 8.0: A comprehensive workshop:
http://www.ibm.com/developerworks/websphere/zones/portal/proddoc/portal8adminworkshop/

10 Author biographies

Thomas Hurek is a Software Architect at IBM's Research Triangle Park Development Lab. He
has worked on the WebSphere Portal development team since 2002, focusing on various
components including security and virtual portals. In his current role he is responsible for Fix
Packs and serves as a Consultant on the Portal Lab Based Services (SEAL) Team. You can
contact Thomas at thurek@us.ibm.com.

Chet Tuttle is an Senior Software Developer for IBM WebSphere Portal / Digital Experience
development team. He has worked as a developer, support engineer, and WCM specialist on
various components of the Digital Experience software at IBM's RTP Development Lab. You can
reach Chet at tuttlec@us.ibm.com.

Falk Posch is a Senior Software Developer for IBM WebSphere Portal. Since 2002 he has
worked as a developer, team lead, and performance expert on various components of
WebSphere Portal at IBM's Germany Development Lab. In his current role he works on
performance and scalability improvements of WebSphere Portal. You can reach Falk at
Falk.Posch@de.ibm.com.

Trademarks

developerWorks, Domino, IBM, Lotus, Notes, Quickr, Rational, and WebSphere, the IBM logo, and

143

ibm.com 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 Oracle and/or
its affiliates.

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.

144