The following list is an example set of requirements that would motivate an IT department to implement these portals in a single, scalable installation of WebSphere Portal V5.
- Multiple user populations belonging to different organizational units or companies
- A desire to offer each group a different user experience, including different:
- Anonymous pages
- Themes
- Page layouts
- Allow all of these end users to collaborate using a single Sametime community
- Many common portlets
- Many common requirements for the infrastructure (common services)
- A desire to have a single, large and scaled infrastructure instead of many smaller sets of servers for each portal
We refer to these independent portals within WebSphere Portal as virtual portals. The term virtual is used because the typical assumption is that a WebSphere Portal installation includes a single portal; these independent portals extend the typical environment.
The concept of virtual portals has been a requirement for some time now. Many changes in WebSphere Portal V5 have been developed to support this functionality. Although the product documentation does not yet officially describe the virtual portal concept, or provide procedures for creating them, the V5 release includes support which can be used to begin implementing virtual portals.
If you look closely at the new default theme for WebSphere Portal V5 you can see some building blocks for virtual portals.
The new toolbar at the top of the portal page enables you to provide links to several different areas of your portal. It already contains links to the default portal, the administration pages, and the user profile editor.
The Manage Pages administration portlet lets you create several content roots. Each content root defines an independent hierarchy of pages within the portal infrastructure. These independent hierarchies form the basis for virtual portals. In effect, the MyPortal and Administration content roots are examples of virtual portals. The development team often implements new capabilities for their own use in the administration pages that are hints of new capabilities that will soon be offered as documented capabilities in the product.
Now, look at two key features in WebSphere Portal V5 that you can use to start implementing virtual portals. Following this description, the article takes you through specific steps to define multiple virtual portals within a single portal installation.
In previous versions of WebSphere Portal you were only allowed to create a single hierarchy of portal pages. In the new Manage Pages administration portlet you can now define multiple, independent hierarchies of portal pages. The top of each hierarchy is known as a content root. While visiting pages in one hierarchy, you do not see links to the pages in the other hierarchies within your navigation.
Before V5, it was rather difficult to create a URL from an outside source to a particular page within the portal. Portal URLs are full of unique identifiers that represent specific pages and portlets. These URLs are normally created with tags or APIs that are only available from within the portal framework.
URL mapping enables you to define your own fixed URL schema which can be easily used outside of the portal framework. You can then create user friendly URLs, which can be mapped to any specific page in any of the content roots.
Steps to implement virtual portals
Now you see how to use these new features to implement a set of virtual portals. The high level tasks for implementing a virtual portal are to:
- Define a new content root
- Define URL mappings
- Change your theme to provide a login path unique to the virtual portal
You need to define a new content root for each virtual portal. In this section, you see how to define two new content roots; each root contains the hierarchy of pages for its virtual portal.
- Logon to the portal as an administrator.
- Click the Administration link in the toolbar.
- Select the Manage Pages portlet; that is, on the left navigation, click Manage Pages.
- Ensure the content roots are displayed.
Figure 1. Content root list
- Click the New label button.
Title:
Virtual Portal
Theme:Engineering
Figure 2. Virtual Portal 1 definition
- Click OK.
- Select Virtual Portal 1.
- Create a Welcome page under Virtual Portal 1.
Figure 3. Welcome page definition
- Click OK.
- Place two portlets on the Welcome page; for example, About WebSphere Portal and World Clock, as shown below.
Figure 4. Adding two portlets to the page
- Click Done.
- Create a Work page.
Figure 5. Creating the Work page
- Click OK.
- Place two portlets on the Work page; for example, QuickLinks and Bookmarks.
Figure 6. Adding two portlets to the Work page
- Click Done.
Virtual Portal 1 should now have two pages defined, as shown below.
Figure 7. Virtual Portal 1 with two pages
Now repeat the last few steps to create the Virtual Portal 2 content root with a different theme and two similar pages. The following shows the two content roots, Virtual Portal 1 and Virtual Portal 2.
Figure 8. Revised content roots list with both virtual portals
You have defined several new portal pages. How do you display them in a browser? Because these new pages have been defined in separate page hierarchies, the navigation for the default portal does not include links to them.
In order to display them, you must define new portal URLs and associate them with the new virtual portals. When you choose a content root, the theme displays navigation links to the rest of the pages you have defined in that hierarchy.
- Logon to the portal as an administrator.
- Click the Administration link in the toolbar.
- Click the Portal Settings link.
- Click the URL Mapping link.
- Click New Context.
- Define a link to the first virtual portal (VPortal1).
- Map this link to Virtual Portal 1 using the Edit Mapping icon
. - Define a link to the second virtual portal (VPortal2).
- Map this link to Virtual Portal 2 using the Edit Mapping icon .
The URL mappings should look like this:
Figure 9. URL mappings for the two context roots
Navigating to the two virtual portals
So far, you have now created both the virtual portals and mapped new URLs to them. In order to use these new URL mappings, you need to know how to build a complete URL. The complete URL must begin with either the public or protected portal URI path. The default public URI path is /wps/portal and the default protected URI path is /wps/myportal. The URL mapping labels defined here follow this URI.
- Type the following into your browser's address bar to display the Welcome page for Virtual Portal 1. Notice that a link to the Work page is displayed in the navigation bar.
<your-host>/wps/myportal/VPortal1
- Log in as the same user that created the virtual portal pages.
Important: If you have changed the default protected URI path for your portal use that instead of
/wps/myportal. - Type the following into your browser's address bar to display the Welcome page for Virtual Portal 2. A link to the Work page displays in the navigation bar.
<your-host>/wps/myportal/VPortal2
Defining access control for the pages
So far you have been able to see the new virtual portals because your userid created them. Now you see how to differentiate anonymous content from protected content. You define the Welcome pages in both virtual portals to be viewable by anyone who can find the virtual portals, and you define the Work page to be restricted to only those users who have authenticated with the portal.
- Logon to the portal as an administrator.
- Click the Administration link in the toolbar.
- Click the Manage Pages link and display the content roots.
- Click the Set Page Permission icon
for the Virtual Portal 1 label. - Click the Edit Role icon
for the Privileged User role. - Click the Add action.
- Select the all Authenticated Users group.
All pages under Virtual Portal 1 inherit this access.
Tip: You could create different groups in LDAP and associate each virtual portal with a different group.
- Go back to the Manage Pages portlet and display the Content Roots again.
- Select Virtual Portal 1 to display the pages under that label.
- Click the Set Page Permission icon for the Welcome page.
- Click the Edit Role icon for the User role.
- Click the Add action.
- Select the anonymous portal user group.
- Repeat the above steps for Virtual Portal 2.
Now the Welcome page can be displayed by anonymous users. Try the following links:
<your-host>/wps/portal/VPortal1 <your-host>/wps/portal/VPortal2 |
If you use one of the following links, and you log in as a defined user, then you can see both pages in the virtual portal.
<your-host>/wps/myportal/VPortal1 <your-host>/wps/myportal/VPortal2 |
Now that you have defined anonymous content for your virtual portals, you need to allow users to login from within the virtual portal. Currently the login link in the toolbar at the top of the page is a direct link to the login screen. The portal automatically adds parameters to this URL to specify the theme to use for the login screen. It also remembers the page the user first requested and redirects them back to that page. Therefore, with these defaults the user sees the login screen displayed under the theme that matches the virtual portal that they are working with and they are redirected back to the anonymous page for the virtual portal.
Next, you need to change the themes to provide links to your virtual portals.
Because the current text is static, on the theme for each virtual portal, you can change the text for My Portal to Virtual Portal 1 or Virtual Portal 2. For the Administration theme, you can assume that the admin user has permission to access both virtual portals and place links from the URL mappings for both virtual portals into the admin theme. This is also a safe assumption if both virtual portals have anonymous content.
By default the log out link is a reference to the LogoutUser command, which redirects the user to the default portal. You might think this is hardcoded to be My Portal, but it is actually just a screen that is mapped to the LoggedOut screen name. This is mapped to the Home screen by default and can be changed in the Finder Service properties file.
.../PortalServer/shared/app/config/services/FinderService.properties |
There is currently a bug in the default theme that displays both the place bar and the page bar navigation items for the default portal. You can fix this situation by making the highlighted changes below in the Default.jsp.
<%-- Don't show navigation in solo mode --%> <wps:if portletSolo="no" screen="Home,LoggedIn"> <%@ include file="./PlaceBarInclude.jsp" %> <%@ include file="./PageBarInclude.jsp" %> </wps:if> |
What we really need is a way to specify a parameter on the LogoutUser command to identify the URL to be used when redirecting the user after logout. If you can get access to the LogoutUser.java source code, you can change it to accept this parameter and re-deploy the wps.ear.
The following describes limitations of this implementation.
WebSphere Application Server only allows a connection to a single LDAP directory. This means that there is only a single pool of users and groups in the LDAP directory to work with and that there can be only one set of super Portal administrators. This limitation can be somewhat mitigated by delegating administrative authority to each page hierarchy to a different group of users. All these users must have authority to see and install portlets because there is only one global set of portlets and portlet applications.
All portals must use the same common domain suffix if they want to make use of the single sign-on feature provided by WebSphere Application Server.
Not all resources can be protected and limited to a particular virtual portal. For example, themes and skins will be made available to all virtual portals without restrictions.
Credential Vault, Portlet Services, and Portal Services are common for an entire installation. They cannot be scoped to a particular virtual portal.
The settings which are defined in the portal properties files apply for the entire installation. It is not possible to have specific settings for particular virtual portals.
Automatic theme selection for screens
Screens are global objects and can be referenced from any page in any virtual portal. Therefore, screens do not have any themes associated with them. The assumption is that the screen should be displayed under the theme associated with the last page displayed.
When the user requests a protected page and is redirected to the login screen there is no established previous page or theme. In this case, the portal currently defaults to using the default portal theme. It may be possible in future versions of the portal to determine the theme associated with the requested URL and use that theme for the login screen.
WebSphere Portal Version 5 begins to fulfill the requirement for virtual portals. The simple example described here illustrates techniques you could use to begin implementing your own virtual portals. Each of these portals can have a different set of anonymous pages and a different set of portal themes, and yet all be supported by a single installation of WebSphere Portal.
The current infrastructure might not support everything you want to provide for your users, but it does let you get started. If there are additional things you would like to see in the product please submit your requirements to IBM.
-
WebSphere Portal product documentation is the primary resource for installation, configuration, and development information.
- See the
WebSphere Portal zone for additional articles, samples, tutorials, and references for developing portals.
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
