administering ibm websphere portal 6.1.0 and 6.1.5: a workshop
TRANSCRIPT
Administering IBM WebSphere Portal 6.1.0 and 6.1.5: A workshop
Thomas HurekSoftware ArchitectWebSphere Portal Lab Services Consultant & Chief Programmer Fix PacksIBM Software GroupDurham, NC USA
Falk PoschSoftware EngineerWebSphere Portal Server DevelopmentIBM Software GroupBoeblingen, Germany
June 2010
© Copyright International Business Machines Corporation 2010. All rights reserved.
Summary: The goal of this white paper is to explain the various administration and configuration tools offered by IBM® WebSphere® Portal. Learn which tool to use for which task and about the new capabilities of WebSphere Portal 6.1.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 the different tools.
Table of Contents1 What is WebSphere Portal? .................................................................................................... 2
1.1 Configuration information ................................................................................................. 3 1.2 Preparing to install WebSphere Portal ............................................................................. 4
2 WebSphere Portal file system structure .................................................................................. 4 3 Command line tools ............................................................................................................... 10
3.1 ConfigEngine .................................................................................................................. 10 3.2 ConfigWizard .................................................................................................................. 13
4 Command line tools: WebSphere Application Server scripting ............................................ 18 4.1 XMLAccess .................................................................................................................... 20 4.2 WebSphere Portal scripting ........................................................................................... 24 4.3 ReleaseBuilder ............................................................................................................... 28
5 Administration user interface: Admin portlets ........................................................................ 30 5.1 Admin portlets: Manage User and Groups .................................................................... 31 5.2 Admin portlets: Virtual Portal Manager .......................................................................... 33 5.3 Admin portlets: Resource Manager Portlet .................................................................... 37 5.4 Administration GUI's: Page Builder ................................................................................ 44 5.5 Admin portlets: Manage Pages ...................................................................................... 51
1
5.6 WebDAV ......................................................................................................................... 57 5.7 Mashup integration ......................................................................................................... 59
6 WebSphere Application Server Integrated Solutions Console ............................................. 64 7 Conclusion ............................................................................................................................. 68 8 Resources .............................................................................................................................. 68 About the authors ..................................................................................................................... 68
1 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 size 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.
.
Widgets
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
2
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.
The WebSphere Portal servlets and portlets 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, the response can be returned in form of html, wml, etc.
1.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, 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
3
WebSphere Portal is quite flexible and, depending on your use case, more than one tool can be used to achieve your goals.
1.2 Preparing to install WebSphere PortalThe references to directories in this article are for the Microsoft® Windows® Operating System. It is possible to use any other multi-platform operating system, but the directories would need to be adjusted accordingly.
First, install WebSphere Portal V6.1.5, using a fresh, out-of-the-box install. The Install Media can be retrieved from, for example, the IBM Passport Advantage Web site.
During the install, WebSphere Portal does the following:
• Creates WebSphere Application Server 6.1• 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 Portal tables• Enables file-based security after the install• Creates the Portal Administrative user, wpsadmin / wpsadmin (you can choose another
password during install as well, but then must adjust references in this document accordingly)
Sample files used here are provided in the PortalAdminSampleFiles.zip file as a Download.
When the install completes, you are ready to start.
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.
Our server name here is testserver or localhost. Replace these server names with your local host name on which WebSphere Portal is installed.
2 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• View log files
4
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 topic modify the file system in some way.
Figures 3—7 illustrate the WebSphere Portal file system structure, including the AppServer directory, PortalServer directory, Profile directory, Profile directory logs, and Profile directory – WIM/VMM.
The following are a few of the directories in figure 3 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.5, including the Java Runtime Edition.
Figure 3. AppServer directory
5
The directories worth noting in figure 4 (below) are:
• The PortalServer directory, containing mainly the binaries for WebSphere Portal. In WebSphere Portal 6.1 the binaries and the configuration and tools have been separated; therefore, the PortalServer directory no longer needs to be touched as often as 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.
• The doc subdirectory, which holds API/SPI documentation as well as XMLAccess sample files.
• The installableApps directory, in which are found the Portal application enterprise archive files (.war and .ear files). Most of them are deployed out of the box, but some can be deployed later on (such as business portlets).
• The migration directory, containing all tools necessary to migrate from a previous version of WebSphere Portal.
• 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 4 is the version directory, which holds the corrective service registry. Also, note that the uninstall directory contains the uninstall code.
6
Figure 4. PortalServer directory
The Profile directory (see figure 5) contains the configuration as well as command line tools for WebSphere Portal and WebSphere Application Server:
• The bin directory contains all the command line tools related to the profile, for example, for starting and stopping the server.
• The config directory holds the configuration for the WebSphere Application Server. • ConfigEngine is the command line tool to trigger configuration tasks in WebSphere Portal (it
replaces the WPSConfig tool used in previous releases). The log directory inside the ConfigEngine directory contains the Portal Install and Configuration Logs.
• The installedApps directory holds the installed J2EE applications, including portlets.
7
Figure 5. Profile directory
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 Configuration Wizard can be found in the wizard directory.
All the tools are explained in later in this paper. The runtime logs of WebSphere Portal can be found inside the log directory (see figure 6). The log directory 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:
8
• 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 file would have a custom name, for example, Verbosegc.
Figure 6. Profile directory--Logs
The last directory we want to point out is the Virtual Member Manager (VMM) config directory (see figure 7). It contains the user repository configuration data. In previous releases the configuration was stored in the WebSphere Member Manager Configuration files (wmm.xml).
9
Figure 7. Profile directory - WIM/VMM
3 Command line tools Now let's focus on the command line tools.
3.1 ConfigEngineThe 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).
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 8).
10
Figure 8. ConfigEngine – Input values via property files
The most important input property files are:
• The wkplc.properties file, which is the main configuration file• The wkplc_comp.properties, containing the configuration settings for Database configuration• The 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 9):
ConfigEngine list-all-virtual-portals -DPortalAdminPwd=wpsadmin -DWasPassword=wpsadmin
11
Figure 9. Triggering the ConfigEngine command
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
Figure 10 shows the output of the command.
Figure 10. ConfigEngine command output
12
3.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
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 invoke the ConfigWizard, change directory to c:\ibm\wp_profile\PortalServer\wizard and invoke configwizard.bat (see figure 11).
Figure 11. configwizard.bat
2. The Welcome screen displays; click Next (see figure 12).
13
Figure 12. Configuration Wizard Welcome screen
3. To modify the security configuration, select the Configuring security radio button; click Next (see figure 13).
14
Figure 13. Configuring security option
4. Enter uid=wpsadmin,o=defaultWIMFileBasedRealm in the Username field, and enter wpsadmin in the Password field; click Next (see figure 14).
15
Figure 14. Specify username and password
5. Select the Configuring Federated Repository option; click Next (see figure 15).
16
Figure 15. Configuring Federated Repository option
6. In the next window (see figure 16), click Cancel (otherwise, we'd require an LDAP server).
Figure 16. Cancel the Add Federated LDAP Repository option
17
4 Command line tools: 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 17 shows the WebSphere Application Server Scripting syntax, where we do the following:
Change to C:\ibm\wp_profile\binEnter wsadmin -h
Figure 17. WebSphere Application Server Scripting syntax
18
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 18):
wsadmin -host testserver -port 10033 -user wpsadmin -password wpsadmin
Figure 18. Connect to the server
The command connects to the testserver 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 19). Replace wpsbvt with your node name, as follows:
$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 19. Enable Tracing with wsadmin
4. Access WebSphere Portal in the browser by entering the following URL:
http://localhost:10040/wps/portal
5. Verify that a trace file trace.log was created in the C:\ibm\wp_profile\logs\WebSphere_Portal directory.
6. Disable the tracing again by running the following (see figure 20):
$AdminControl setAttribute $ts traceSpecification com.ibm.wps.engine.*=all=disabled
19
Figure 20. Disable tracing with wsadmin
7. Exit the tool by running the exit command.
4.1 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 21 shows the syntax for XMLAccess.
Figure 21. XMLAccess syntax
20
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 22 shows sample files in c:\ibm\PortalServer\doc\xml-samples.
Figure 22. Sample .xml files
Figure 23 shows the import file.
21
Figure 23. 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 24):
xmlaccess -in c:\ibm\PortalServer\doc\xml-samples\ExportRelease.xml -out InitialRelease.xml -url http://localhost:10040/wps/config -user wpsadmin -password wpsadmin
Figure 24. Triggering the export
The result should look like figure 25.
Figure 25. Request successful message
2. Then, check the result file C:\ibm\wp_profile\PortalServer\bin\InitialRelease.xml (see figure 26). In the file, comments are listed at the beginning, and then the different resources are exported with their settings.
22
Figure 26. Result file
3. Check the file for a sample, such as URL Mapping:
<url-mapping-context action="update" domain="rel" label="Home" objectid="C_CGAH47L0084G00I4BONHCQ10U5">
<access-control externalized="false" owner="undefined" private="false"/> <portal-url resourceref="6_CGAH47L0084G00I4BONHCQ10I3" update="set"/></url-mapping-context>
XMLAccess - ImportNow let's deploy a sample portlet with the XMLAccess input script shown in listing 1:
23
Listing 1. XMLAccess script<?xml version="1.0" encoding="UTF-8"?><request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" type="update" xsi:noNamespaceSchemaLocation="PortalConfig_6.1.0.xsd"> <portal action="locate"> <web-app action="update" active="true" uid="SPFStandardStockQuote.war.webmod"> <url>file:///$server_root$/installableApps/SPFStandardStockQuote.war</url> </web-app> </portal></request>
The portlet SPFStandardStockQuote.war will be imported, and you can use the sample file, DeployPortlet.xml, provided as part of the package:
1. Open command line and trigger (see figure 27):
xmlaccess.bat -in DeployPortlet.xml -out DeployPortlet.xmlOut.xml -url http://localhost:10040/wps/config -user wpsadmin -password wpsadmin
Figure 27. Open command line and trigger
2. Check the output file, DeployPortlet.xmlOut.xml:
<request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" build="wp6103_201_01" type="update" version="6.1.0.3" xsi:noNamespaceSchemaLocation="PortalConfig_6.1.0.2.xsd">
<status element="all" result="ok"/></request>
The portlet is now imported and can be used in our next exercises.
4.2 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 when:
• Creating or modifying a limited set of WebSphere Portal resources like pages or portlets• Combining 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.
24
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 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 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 28), enter wpsadmin in both the User Identity and User Password fields; confirm by clicking OK.
Figure 28. Login at the Target Server window
4. Log on to the portal, using the following script command (see figure 29):
Portal.login(”wpsadmin”,”wpsadmin”)
25
Figure 29. Log on to the portal
5. Select the parent page of our new page by first finding the parent page (see figure 30)
Content.find(”all”, ”uniquename”, ”ibm.portal.Home”)
and then selecting the page:
Content.select(”6_CGAH47L0084G00I4BONHCQ10I3”)
Figure 30. Find and select page
6. Create an empty page and immediately select this new page (see figure 31):
Content.create(”page”,”TestPage”,”html”,”public”,”select”)
Figure 31. Create and select empty page
7. Set a unique name for this page (see figure 32):
Content.set(”uniquename”,”wp.test.page”)
Figure 32. Set unique name
26
8. Quit the interactive mode, using the quit command (see figure 33).
Figure 33. 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 that was provided):
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:
LoginLocate the pageCreate a container on the page to hold the portletPut the portlet into the containerLogout
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.
2. Invoke the script to set the layout for the new test page (see figure 34):
27
wpscript -user wpsadmin -password wpsadmin -lang jython -f UpdateLayout.py
Figure 34. Invoke script
The command executes the script contained in UpdateLayout.py under the user identity wpsadmin.
4.3 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).
You use ReleaseBuilder to generate a diff file. 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 35):
xmlaccess -in c:\ibm\PortalServer\doc\xml-samples\ExportRelease.xml -out ChangedRelease.xml -url http://localhost:10040/wps/config -user wpsadmin -password wpsadmin
Figure 35. Generate the release export
The result should look like that shown in figure 36.
28
Figure 36. 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 37).
Figure 37. 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 38):
releasebuilder -inOld InitialRelease.xml -inNew ChangedRelease.xml -out ReleaseDiff.xml
Figure 38. Generate the difference
3. Check the resulting ReleaseDiff.xml, as shown in figure 39.
29
Figure 39. 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.
4. Now check for the page we created (TestPage) and the portlet (SPFStandardStockQuote.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.
5 Administration user interface: Admin portletsThe 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 40):
• 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 (URL mappings, supported markups and clients)• modify WebSphere Portal content (Web Content libraries, syndication, feeds)• manage search administration (for example, define and manage search collections)• manage WebSphere Portal analyses and virtual portals
30
Figure 40. Admin portlets navigation pane
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• move pages between Virtual Portals with Site Management• explore the Page Builder Theme to create a blog and share it with another user• create a static page with the Manage Pages portlet• use WebDav to modify the created static page
5.1 Admin portlets: Manage User and GroupsIn this topic we use the Manage Users and Groups portlet (see figure 41) to add an 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).
31
Figure 41. Manage User and Groups portlet
Later, the non-admin user is used to demonstrate the Site Management functionality and is also needed to show the Page Builder scenario.
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:
1. Open a browser with http://testserver:10040/wps/portal and log in with wpsadmin.
2. Select Administration > Access > Users and Groups, and click the New User button (see figure 42).
Figure 42. Create new user
3. Enter at least following information to create a user (see figure 43):
User IDPassword
32
Confirm PasswordLast Name
Figure 43. Enter user information
4. Confirm the user creation by clicking OK; you should see the “User created successfully” message (see figure 44).
Figure 44. Success message
5.2 Admin portlets: Virtual Portal ManagerWe use this admin portlet to create a new virtual portal (see figure 45) 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.
33
Figure 45. Virtual Portal Manager portlet
We'll use this later to demonstrate the possibility for use in Site Management. 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 46).
Figure 46. Create new virtual portal
2. Complete the virtual portal's information as follows (see figure 47):
Virtual portal name: accountsVirtual portal description: The accounts Virtual PortalURL Context: accounts
34
Virtual portal hostname: vptestserverInitial admin user group: wpsadmins
Figure 47. Enter virtual portal's information
3. Click OK; if the entered virtual portal host name does not resolve to the original hostname (e.g. localhost), add the entry to the host's Windows system file so that it can be resolved.
You should see the created successfully message and our new The Accounts Virtual Portal listed in the portlet (see figure 48).
35
Figure 48. Confirmation of creation
4. Log in to the newly created Virtual Portal (see figure 49) by specifying the URL context (http://testserver:10040/wps/portal/accounts) or by using the host name of the virtual portal (for example, modifying the hosts file to point to the same server).
Figure 49. Login screen
Figure 50 shows the Administration area of a virtual portal, within which you have a limited set of administration tools.
36
Figure 50. Administration area
5.3 Admin portlets: Resource Manager PortletOur goal here is to publish a page to a target server and promote the published page on the server. Note that the Site Management functionality might be used to integrate pages on an integration server, and that the test page, a non-admin user, and the virtual portal must already be created.
Alternatively, XMLAccess can be used to move pages from one server to another (no preview, or backup by default), and the Portal scripting interface also provides the site management functionality.
To add a source server:
1. Log in to default via WebSphere Portal, select Administration > Portal User Interface > Site Management, expand Manage servers, and select Add new server (see figure 51).
37
Figure 51. Add a new server
2. Enter following information to set up the source server (see figure 52):
Host: testserverPort: 10040Path: /wps/mycontenthandler (default)Assign a unique name: source
Figure 52. Source server information
3. Click OK and then the Show details buttons, to display the success message.
To create the target server:
1. Repeat Step 1 above and enter following information for the target server (see figure 53):
Host: testserverPort: 10040Path: /wps/mycontenthandler/accountsAssign a unique name: target
38
Figure 53. Target server information
2. Alternatively, you can use the host name during setup (see figure 54):
Host: vptestserverPort: 10040Assign a unique name: target
Figure 54. Host name setup information
Now, specify the credentials to access source/target servers:
1. Select Manage servers > Manage server access in the Resource Manager Portlet window.
2. Enter this information in the Manage server accounts window; click Save (see figure 55):
Server: Select source from the drop-down listUser name: wpsadminPassword: password
Figure 55. Credentials for source server
1 2
3
3 4 5
39
3. In the next window, select target, enter your user name and password, click Save, and then Done (see figure 56).
Figure 56. Credentials for target server
Now, to publish the test page to the target server:
1. Select source, and then target, in the Resource Manager Portlet, and then navigate to TestPage > Publish to > target (see figure 57).
Figure 57. Manage servers window
2. In the Publish Page window, enter the Parent page unique name of the target server; click OK (see figure 58).
7 8 9
40
Figure 58. Publish page window
3. The “TestPage is successfully published” message should display (see figure 59). Note the published TestPage (blue page icon) listed in the target server navigation page.
Figure 59. Successfully published
4. Log in to the target server as a non-admin user. On the target server (vptestserver) the non-admin user (user1) should not see the published TestPage (see figure 60); verify by logging in with user1.
41
Figure 60. Logged in as non-admin user
5. Now log in to the target server as an admin user. On the target server (vptestserver) the admin user (wpsadmin) does see the published TestPage (see figure 61); verify by logging in with wpsadmin.
Figure 61. Logged in as admin user
Finally, we promote the test page to the target server:
42
1. Log back in to the default Portal as admin. Select TestPage > Promote this page, on the published TestPage (see figure 62).
Figure 62. Promote this page
2. The “TestPage is successfully promoted” message should display (see figure 63). Note the promoted test page in the target server navigation pane (green page icon).
Figure 63. Successfully promoted
3. Log in to the target server as a non-admin user. On the target server (vptestserver) the non-admin user (user1) can see the promoted TestPage (see figure 64).
43
Figure 64. Promoted TestPage
5.4 Administration GUI's: Page BuilderPage Builder is a new V6.1.5 theme that lets administrators and users customize pages easily and with which you can do the following:
• Create, modify, delete a page• Create, modify, delete blogs, wikis, and feed readers• Add/remove portlets• Share pages with other users
A test user must be previously created, and alternative tools are XML Access and the Manage Pages portlet.
To create a Page Builder page:
1. Log in to the default Portal as wpsadmin2. Click the Pencil icon to open the Toolbar and select New Page (see figure 65).3. Enter a name for the page, make it private, and click the Create Page button.
44
Figure 65. Create page
4. After the page is created, click the Customize button; here you can add portlets to the page (see figure 66).
5. Click the Plus button beside Blog, name your blog “My Blog,” and click Add.
1.2.
3.
4.5.
45
Figure 66. Add a blog
6. In the next screen, click the Change Style option and select a new style (see figure 67).
Figure 67. Change the style
46
7. Click the Change Layout option to change to one of the available layouts; click Save (see figure 68).
Figure 68. Change the layout
Now that the page is created the way we want, let's modify our blog. To do this, click Create Post, and add a few lines for your readers; click Save and Close (see figure 69).
Figure 69. Create post
47
Now that we have created the page and blog, we want a colleague review the page:
1. Click Share, and select Share Page (see figure 70).
Figure 70. Share Page
2. Search for the user we created earlier (user1), click the Add to View column, and click Save (see figure 71).
48
Figure 71. Add user to view
3. Log out and log in with the previously created test user1.
4. Click the Pencil icon, click Share, and select Add Pages Shared with Me (see figure 72).
49
Figure 72. Add shared pages
5. Click the Add button besides the page shared by wpsadmin; click Save. Now the user can see the page as created by the admin (see figure 73).
50
Figure 73. Log in as wpsadmin
6. Log out and log in again as admin for the next exercises.
5.5 Admin portlets: Manage 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. Static pages can be created using standard HTML editor.
The static page will be updated to demonstrate the WebDAV feature in Section 5.6. Alternative tools are Portal scripting interface, XMLAccess, and WebDAV.
To begin, let's open a sample Web page, for example:
http://www-01.ibm.com/software/lotus/events/lotusphere2010/content/
1. Select File > Save Page As (see figure 74).
51
Figure 74. Open sample Web page
2. Save and compact the sample Web page (see figure 75):
• Enter the name of the sample page, SamplePage.html• Select a folder• Choose WebPage, complete• Click Save
Figure 75. Save and compact
52
3. Create a compressed version of the saved sample file (*.zip), as shown in figure 76.
Figure 76. Create compressed version
Now open Manage Pages portlet and navigate to the location (see figure 77):
1. Select Administration > Portal User Interface > Manage Pages.
2. Select Content Root Home and then click New Page.
Figure 77. Manage Pages portlet
3. In the Page Properties window (see figure 78), enter the following general information for the new page:
• Title: StaticTestPage• Name: wp.test.page.static• Friendly URL name: staticTestPage• Theme: PortalWeb2
1
2
3
4
53
4. For the Type of Page, select “Static Content,” and then click the “Set page layout properties” link (see figure 78).
Figure 78. General information
5. Now enter page properties, specific for the static page – replace the location with your location (see figure 79):
• Static Page Layout File: SamplePage.html• ZIP or HTML File Location: /home/pof/sampleWebPage/sampleWebPage.zip
6. Click OK to confirm, and click OK on the parent page as well, to create the static page.
54
Figure 79. Page properties
7. Now, an additional page is created, called StaticTestPage (see figure 80).
Figure 80. StaticTestPage listed
8. Click Home, to navigate to the new page (see figure 81).
55
Figure 81. Complete static page
9. Click the StaticTestPage link to see the complete static page (see figure 82).
Figure 82. URL for static page
Note that the URL for the static page is still within WebSphere Portal.
56
5.6 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.
It can also be used to browse through the page hierarchy, and to change globalization information and metadata of pages. For static pages, users can browse, read, create, update, save, copy, move, and delete static content.
Note that the test static page must be previously deployed. Alternative tools are XMLAccess, Portal scripting, and Admin portlets.
To modify the title of a static page, open a Web dav browser (see figure 83):
Linux®: Open nautilus, for example, and navigate to
dav://testserver:10040/webdav/dav/contentmodel/wps.content.root/ibm.portal.Home/wp.test.page.static
Windows: Add a network place with the location
http://testserver:10040/webdav/dav/contentmodel/wps.content.root/ibm.portal.Home/wp.test.page.static
Figure 83. Web dav browser (Nautilus)
And then Modify localized_en.properties, changing the title to “StaticTestPage_Update_via_WebDAV” (see figure 84).
Figure 84. Modify localized_en.properties
57
To modify layout of the sample page:
1. Navigate to the URL (see figure 85):
dav://testserver:10040/webdav/dav/contentmodel/wps.content.root/ibm.portal.Home/wp.test.page.static/staticcontent
Figure 85. URL location
2. Modify SamplePage.html to include the static page in the portal layout by removing the <HTML> and </HTML> tags (see figures 86 and 87); save the page.
Figure 86. Remove <html> tag
Figure 87. Remove </html> tag
3. Refresh the static page to see the updated name and the portal layout with the static page (see figure 88).
58
Figure 88. Updated static page
5.7 Mashup integrationNow we create a mashup page within WebSphere Portal, so that you are able to consume, create, and update mashup pages. An alternative tool would be Mashup Center.
For this exercise, let's first add a Feed Reader widget:
1. Select My Mashups > Go to Edit > Favorites (see figure 89).
Figure 89. My Mashups
2. Drag & drop the Feed Reader widget on the free area (figure 90).
59
Figure 90. Drag & drop widget
To customize the Feed Reader widget:
1. Click the tools icon and select Edit Settings (see figure 91).
Figure 91. Edit Settings option
2. Select the option “Make article links available to other widgets,” deselect Show more details, and click Save (see figure 92).
60
Figure 92. Feed Reader Edit window
To add a Web Site Displayer widget:
1. Select Tools, and drag & drop “Web Site Displayer” on, for example, the area circled in red in figure 93.
Figure 93. Drag & drop widget
2. Figure 94 shows our current mashup page, in which both the Feed Reader and Web Site Displayer widgets are displayed. Click the wire widgets icon (circled in red) in the Feed Reader.
61
Figure 94. Mashup page
3. In the Wiring window (see figure 95), under “Select content to send,” choose “Selection as URL (HTML).”
Figure 95. Wiring window for Feed Reader
4. Now choose the Web Site Displayer widget and select the action, “URL using URL (HTML)” (see figure 96).
62
Figure 96. Wiring window for Web Site Displayer
6. Optionally, you can click the Show Graph button to display the current wiring (see figure 97); Click Done.
Figure 97. Wiring Graph
7. Save the page and go to the view mode (see figure 98).
63
Figure 98. View mode
8. Finally, click a link within the RSS feed; the Web Site Displayer displays the URL behind this link (see figure 99).
Figure 99. RSS link URL displayed in Web Site Displayer
6 WebSphere Application Server Integrated Solutions ConsoleIn this section we create a 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.
64
It cannot be used for modifying WebSphere Portal runtime data like pages and portlets. Alternative tools are WebSphere Application Server Scripting, ConfigWizard, or ConfigEngine.
Our sample task is to modify the Java heap setting of the WebSphere Portal Server.
To log in to the Integrated Solutions Console (see figure 100):
1. Open a browser and enter http://testserver:10027/admin
2. For both the User ID and Password fields, enter wpsadmin; click the Log in button.
Figure 100. Log-in screen
To navigate the Integrated Solutions Console:
1. Select Servers > Application servers > WebSphere Portal (see figure 101).
Figure 101. Navigation
2. Under the Server Infrastructure section at the bottom of the next screen, expand “Java and Process Management” and select Process Definition (see figure 102).
65
Figure 102. Configuration
3. Under Additional Properties, select Java Virtual Machine (see figure 103).
Figure 103. Java Virtual Machine
66
4. After selecting the Java Virtual Machine link you will see the window shown in figure 104. Set the Initial Heap Size and the Maximum Heap Size fields to the recommended values from the WebSphere Portal and Lotus Web Content Management 6.1.x Performance Tuning Guide:
• Windows 2003: 1408 MB• Linux: 2048 MB
Click Apply and then OK.
Figure 104. Set the Heap Sizes
Note that the recommendation differs depending on whether you're using the 32- or 64-bit Java Virtual Machine.
Also, the WebSphere Portal 6.1.x Performance Guide has details on many additional recommendations for best performance.
5. Finally, click the Save link to store the changes to the master configuration (see figure 105).
Figure 105. Confirm changes to configuration
67
7 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 recommend to use command line tools.
8 ResourcesWebSphere Portal and Lotus Web Content Management 6.1.x Performance Tuning Guide:http://www-10.lotus.com/ldd/portalwiki.nsf/xpViewCategories.xsp?lookupName=WebSphere%20Portal%20and%20Lotus%20Web%20Content%20Management%206.1.x%20Performance%20Tuning%20Guide
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 Management product documentation:http://www.ibm.com/developerworks/websphere/zones/portal/proddoc.html#v61infocenters
About the authorsFalk Posch is an 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 Germany Development Lab. In his current role he works on performance and scalability improvements of WebSphere Portal. You can reach Falk at [email protected].
Thomas Hurek is a software architect at IBM's Research Triangle Park Development Lab. He has worked on the WebSphere Portal development team for seven years, 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 [email protected] and Contact Details
Trademarks• developerWorks, Domino, IBM, Lotus, Notes, Quickr, Rational, and WebSphere 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.
68