Administering IBM WebSphere Portal 7.0: A comprehensive workshop

Thomas Hurek (thurek@us.ibm.com ) , Software Architect, IBM

Falk Posch (Falk.Posch@de.ibm.com), 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 Contents1 Introduction..........................................................................................................................22 What is WebSphere Portal?.................................................................................................3

2.1 Configuration information.............................................................................................42.2 Preparing to install WebSphere Portal..........................................................................4

3 WebSphere Portal installation..............................................................................................54 WebSphere Portal file system structure.............................................................................155 Command line tools...........................................................................................................20

5.1 ConfigEngine..............................................................................................................205.2 ConfigWizard..............................................................................................................225.3 WebSphere Application Server scripting.....................................................................265.4 XMLAccess.................................................................................................................295.5 WebSphere Portal scripting........................................................................................345.6 ReleaseBuilder...........................................................................................................37

6 Administration user interface: Admin portlets.....................................................................386.1 Accessing WebSphere Portal.....................................................................................406.2 Manage Users and Groups.........................................................................................416.3 Virtual Portal Manager................................................................................................436.4 Administration GUI's: Page Builder.............................................................................476.5 Tagging and rating......................................................................................................686.6 Admin portlets: Manage Static Pages.........................................................................746.7 WebDAV.....................................................................................................................79

7 WebSphere Application Server Admin user interface.........................................................878 Conclusion.........................................................................................................................959 Resources..........................................................................................................................9510 About the authors.............................................................................................................95

1 IntroductionIn 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.

Formatting/hintsThe following color codes are used in this paper:

Magenta: A file or directoryBlue: A command to be executedGreen: A name, title, value, file content, or program outputRed: 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.

EnvironmentDuring 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 PortalAdminSampleFiles.zip file as a Download.

2

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, SOA-based 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

JCA JMS

EnterpriseData, Applications,Internet Content

Process Server

Remoteportlet producer

Desktopand mobileBrowsers,

Mashups and offline Clients

Remoteportlet

consumer.

.

Widg ets

HTTP

WebSphere Portal

Portlet API Security

Mashups Page Aggregation

Composite Applications

Personalization Web Content Management Collaboration

Many many additional components and APIs

WebSphere Application Server

WebServices EJBJDBC

Servlet SecurityCaching

Many many additional components and APIs

Sametime, Quickr, Connections,

Java Virtual Machine

Security Standards like JDBC, . Platform Abstraction

Operating System

Integration and Abstraction

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.

3

2.1 Configuration informationThe 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 PortalThe 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.

4

3 WebSphere Portal installationIn this section we demonstrate how to install WebSphere Portal 7.0. The install creates multiple components:

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 features

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.

1. From the WebSphere Portal 7 Enable Media, launch the install.bat (Windows) or ./install.sh (Linux or UNIX) command (see figures 3a and 3b, respectively).

Figure 3a. Starting the installation on Windows

5

Figure 3b. Starting the installation on Linux

2. 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.

6

Figure 4. Selecting the licensed product

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

7

Figure 5. License window

4. 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).

8

Figure 6. Selecting Full installation option

5. 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 Next.

9

Figure 7. Selecting the Install location

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

10

Figure 8. Selecting the node and host name

7. 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 password.

11

Figure 9. Selecting the Admin ID

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

12

Figure 10. Choose Windows Service creation

9. 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

13

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

14

4 WebSphere Portal file system structureIn 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.

15

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.

16

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:

17

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

18

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 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 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).

19

Figure 17. Profile directory - WIM/VMM

5 Command line toolsNow let's focus on the command line tools.

5.1 ConfigEngineThe 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).

20

Figure 18. ConfigEngine Input values via property files

The most important input property files are:

wkplc.properties, 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, 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

21

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 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 ConfigWizardThe 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

22

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 initial steps for adding an LDAP repository:

1. 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

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

Figure 22. Configuration Wizard Welcome screen

23

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

Figure 23. Configuring security option

4. Enter uid=wpsadmin,o=defaultWIMFileBasedRealm in the Username field, and enter wpsadmin in the Password field; click Next (see figure 24).

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

25

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 scriptingThis 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.

Figure 27 shows the WebSphere Application Server Scripting syntax, where we do the following:

Change to C:\ibm\wp_profile\binEnter wsadmin -h

26

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.

27

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

$AdminControl completeObjectName type=TraceService,node=wpsbvt,process=WebSphere_Portal,*

set ts [$AdminControl completeObjectName type=TraceService,process=WebSphere_Portal,*]

$AdminControl setAttribute $ts traceSpecification com.ibm.wps.engine.*=all

Figure 29. Enable tracing with wsadmin

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

4. 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

28

5. Disable the tracing again by running the following (see figure 31):

$AdminControl setAttribute $ts traceSpecification com.ibm.wps.engine.*=all=disabled

Figure 31. Disable tracing with wsadmin

6. Exit the tool by running the exit command.

5.4 XMLAccessThis 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 XMLAccess.

Figure 32. XMLAccess syntax

29

XMLAccess - ExportFor 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.

30

Figure 34. Import file

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

1. 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

2. 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.

31

Figure 37. Result file

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

where

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,

http://localhost:10039/wps/myportal/Administration. 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.

32

XMLAccess - ImportNow let's deploy a sample portlet with the XMLAccess input script shown in listing 1.

Listing 1. XMLAccess script

file:///$server_root$/installableApps/SPFStandardStockQuote.war

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

1. 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

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

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

33

5.5 WebSphere Portal scriptingThis 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 modesThere 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 modeAs 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.

3. 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

34

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

Portal.login(wpsadmin,wpsadmin)

Figure 40. Log on to the portal

5. 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:

Content.select("Z6_CGAH47L008LG50IAHUR9Q330A3")

Figure 41. Find and select page

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

Content.create(page,TestPage,html,public,select)

Figure 42. Create and select empty page

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

Content.set(uniquename,wp.test.page)

Figure 43. Set unique name

35

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

Figure 44. Quit interactive mode

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

1. Create a file UpdateLayout.py in the directory C:\ibm\wp_profile\PortalServer\bin with the content in listing 2 (you can use the UpdateLayout.py file provided as part of the package):

Listing 2. Script for UpdateLayout.py# login to portalPortal.login("wpsadmin","wpsadmin")print " 1. login done."# select pageContent.select(Content.find("all","uniquename","wp.test.page"))print " 2. page selected"# search portletportletA = Portlet.find("portlet", "name", "Struts Standard Stock Quote")print " 3. portlet found: " + portletA# create a vertical containerLayout.create("container", "vertical", "select")print " 4. vertical container created."# create a control with the portletLayout.create("control", portletA)print " 5. create control with stock portlet."# logout againPortal.logout()print " 6. logout."printprint " 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.

2. Invoke the script to set the layout for the new test page (see figure 45):

wpscript -user wpsadmin -password wpsadmin -lang jython -f UpdateLayout.py

36

Figure 45. Invoke script

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

5.6 ReleaseBuilderThis 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:

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

2. 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 wpsadmin

Figure 46. Generate the release export

The result should look like that shown in figure 47.

37

Figure 47. Release export result

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

1. 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

2. 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 portletsThe 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.

38

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

39

6.1 Accessing WebSphere PortalIn this topic we learn how to access Portal and about the different artifacts in the Portal markup:

1. 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

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

Figure 53. Log in window

40

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 GroupsIn this topic we use the Manage Users and Groups admin portlet (see figure 55) to add a non-administration 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

41

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. Select Administration Access Users and Groups, and click the New User button (see figure 56).

Figure 56. Create new user

3. Enter at a minimum the following information to create a user (see figure 57):

User IDPasswordConfirm PasswordLast Name

42

Figure 57. Profile Management window

4. 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 ManagerWe 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.

43

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:

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

Figure 60. Create new virtual portal

2. Complete the virtual portal's information as follows (see figure 61); click OK:

Virtual portal name: accountsVirtual portal description: The accounts Virtual PortalURL Context: accountsVirtual portal hostname: vptestserverInitial admin user group: wpsadmins

44

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).

45

Figure 62. Confirmation of creation

3. 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 (http://vptestserver:10039/wps/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.

46

Figure 64. Administration area

6.4 Administration GUI's: Page BuilderPage 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 portlet.

To use the Page Builder theme to create a page:

1. Log in to the default Portal as wpsadmin (http://localhost:10039/wps/portal ) 2. Click on Actions to open the Toolbar.

47

3. Click the New Child Page button (see figure 65).4. 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 permissions.

Figure 65. Create page

5. 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.

1.

2.

3.

4.

5.

48

Figure 66. Edit the empty page

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

7. Click the plus-sign button beside the Wiki entry to add a wiki to the page (see figure 67).

Figure 67. Customizing a page

8. 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).

49

Figure 68. Adding a wiki to a page

9. 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):

http://www-947.ibm.com/systems/support/myfeed/xmlfeeder.wss?feeder.requid=feeder.create_public_feed&feeder.feedtype=RSS&feeder.maxfeed=25&OC=SSHRKX&feeder.subdefkey=swgws&feeder.channel.title=WebSphere%20Portal&feeder.channel.descr=The%20latest%20updates%20about%20WebSphere%20Portal

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).

50

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.

51

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.

52

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:

1. 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.).

2. Then click Save and Close.

53

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:

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

54

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.

2. 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

55

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:

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

Figure 77. Triggering the sharing of a page

2. 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).

56

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:

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

Figure 79. Adding a shared page to the user interface

57

3. 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

58

Working with a client-side page containing widgets and portletsIn 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.

1. 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

2. 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 name.

3. 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.

4. Finally, click the Create Page button.

59

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:

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

Figure 84. Modifying Page properties

60

2. 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.

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

61

Figure 86. Modifying Page properties

2. 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

3. 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.

62

Figure 88. Adding a portlet to the page

4. 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

63

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.

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

7. This portlet allows us to modify the feed. For the Feed URL field you can use http://www.ibm.com/products/specialoffers/us/en/software.rss 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

64

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:

1. 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

2. Click the Settings button in the Wiring pop-up window.3. 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

65

4. 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

5. 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).

66

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).

67

Figure 96. Reviewing the resulting page

6.5 Tagging and ratingWebSphere 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:

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

68

Figure 97. Selecting to tag a page

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

Figure 98. Adding tags to a page

69

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

Figure 99. Saving tags for a page

4. 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

70

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

Figure 101. Selecting Tag Center link

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

7. 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.

71

Figure 103. Finding a page via tags

8. 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

72

9. 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.

73

Figure 106. Reviewing the ratings of a page

6.6 Admin portlets: Manage Static PagesHere 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.

1. To begin, let's open a sample Web page, for example, http://www-01.ibm.com/software/websphere/portal/

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

74

Figure 107. Open sample Web page

3. Now switch back to the browser as admin (wpsadmin/wpsadmin).4. Open the Manage Pages portlet and navigate to the location (see figure 108).5. Select Administration --- Portal User Interface --- Manage Pages, and then select Content Root -

Home; then click New Page.

75

Figure 108. Manage Pages portlet

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

Title: StaticTestPage Unique Name: wp.test.page.static Friendly URL name: staticTestPage

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

76

Figure 109. Page Properties window

8. 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\portal.zip

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

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

77

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 112).

78

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 WebDAVOur 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.

79

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:

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

Figure 114. Map Network Drive in Windows

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

Figure 115. Open WebDAV with Windows

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

80

Figure 116. Add Network Place Wizard Welcome window

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

Figure 117. Select the location

81

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

http://localhost:10039/wps/mycontenthandler/dav/contentmodel/wps.content.root/ibm.portal.Home/wp.test.page.static

Figure 118. Enter URL

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

82

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

Figure 120. Choose name for network place

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

Figure 121. Successful completion

83

We now have access to the WebDAV interface of Portal and, based on the URL, are connected to the page wp.test.page.static (see figure 122). So now we can, for instance, change the title of the page in the file localized_en.properties 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):

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

Figure 123. Copy the static content for editing

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

84

Figure 124. Remove tag

85

Figure 125. Remove tag

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

86

4. 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 interfaceHere 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.

87

Figure 127. Log-in window

To navigate the Integrated Solutions Console:

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

Figure 128. Navigate to User Management

88

2. 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

3. 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).

89

Figure 130. Assigning a role

4. 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).

90

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).

91

Figure 132. Confirm changes to configuration

6. Next we create the Administrative Authorization Group and assign our user by selecting Security Administrative Authorization Groups on the left-hand navigator; click Next.

7. 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.

92

Figure 133. Administration authorization groups window

8. Select the newly created Authorization Group and, in the next window, select Administrative user roles; click Add.

9. 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.

93

Figure 134. Add user to mapped role

10. Save the change, and log out and log in as the newly created user serveradmin (password serveradmin).

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).

94

Figure 135. Server administration

8 ConclusionAs 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 ResourcesRead 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 authorsThomas 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 thurek@us.ibm.com with any questions on the material in this paper.

95

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 Falk.Posch@de.ibm.com.

Trademarks developerWorks, Domino, IBM, Lotus, Notes, Quickr, Rational, and WebSphere, the IBM logo, and 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 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.

96

1 Introduction2 What is WebSphere Portal?2.1 Configuration information2.2 Preparing to install WebSphere Portal

3 WebSphere Portal installation4 WebSphere Portal file system structure5 Command line tools5.1 ConfigEngine5.2 ConfigWizard5.3 WebSphere Application Server scripting5.4 XMLAccess5.5 WebSphere Portal scripting5.6 ReleaseBuilder

6 Administration user interface: Admin portlets6.1 Accessing WebSphere Portal6.2 Manage Users and Groups6.3 Virtual Portal Manager6.4 Administration GUI's: Page Builder6.5 Tagging and rating6.6 Admin portlets: Manage Static Pages6.7 WebDAV

7 WebSphere Application Server Admin user interface8 Conclusion9 Resources10 About the authors