<<

. 24
( 87 .)



>>

tion to the portal while export is used for extracting information.
Each request has actions associated with it. For update, only locate, create,
update, and delete are permitted while export is limited to locate and export.
The locate action ¬nds the portal resource associated with a speci¬c XML
element. Create action creates a portal resource with attributes you spec-
ify. Update action modi¬es the corresponding portal resource with a given
con¬guration data. Delete action removes the portal resource based on the
speci¬ed XML element. Finally, export action generates an XML represen-
tation of the portal resource.
To understand how to set up a con¬guration request, let™s walkthrough a
sample request ¬le provided by IBM. You can ¬nd this code at <WebSphere
>\PortalServer\doc\xml-samples. Normally you would look for a
sample that performs a function similar to what you want to do and perform
any necessary modi¬cations. This XML request ¬le will create the user
Homer Simpson and add it to the group Spring¬elders. Note that in the
update request, we set create-oids to “true.” This enables object IDs to be
symbolically created and valid only within the XML script which prevents
the portal from choosing an already existing object-id and overwriting it.
<?xml version="1.0" encoding="UTF-8"?>
<request
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-06 WY009-BenNatan-v1.cls May 9, 2004 9:35




122 Chapter 6


xsi:noNamespaceSchemaLocation="PortalConfig_1.2.xsd"
type="update" create-oids="true">
<portal action="locate">
<user action="update" name="hsimpson" firstname="Homer"
lastname="Simpson" password="secret">
<description>My favorite TV star</description>
<parameter name="preferredLanguage" type="string"
update="set">en</parameter>
</user>
<group action="update" name="springfielders">
<description>Inhabitants of Spring
field</description>
<member-user update="set" id="hsimpson"/>
</group>
</portal>
</request>




XML Con¬guration Interface Special Properties
The XML Con¬guration Interface has some special properties of which
you should be aware. Since the portal is represented in XML, the XML
Con¬guration utility must have some way of representing the order of
elements on a GUI screen or the sorting order. This is done using three
methods. If the resource is identi¬ed as an integer, it will be sorted into
position relative to the ordinals of existing siblings. If a position indicator
is speci¬ed (hash (#) mark followed by an integer), it will appear in that
position in its content parent. Lastly, you can specify the special values
with ¬rst and last, which indicates that the resource is sorted either in the
¬rst or last position.
You should also be careful with unique names in XML scripts especially if
these scripts run on many portal installations. If a unique name is assigned
by the XML script and that unique name is already used on the system, the
script will fail.


XML Con¬guration Interface Transactional Support
The XML Con¬guration Interface provides limited transactional support.
Changes in the portal database are grouped into transactions when you cre-
ate, update, or delete resources. All changes that are part of the transaction
are either executed completely or not executed at all.
The main request element has a transaction attribute, which de¬nes the
grouping value. The value can be Resource (default value), which means
that every top-level resource is processed in one separate transaction or
Request, which means the entire XML script is executed in one transaction.
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-06 WY009-BenNatan-v1.cls May 9, 2004 9:35




Migrating to WebSphere Portal Version 5.0 123


The transactional support is limited because it only applies to changes to
the portal database. This means changes to portlets, users, and groups stored
in LDAP, or role assignments in external access control systems cannot
be rolled back if a transaction fails. Similarly, if the latter changes failed,
changes to the database will not be rolled back.


Changes in XML Con¬guration Interface for Version 5.0
The XML Con¬guration Interface utility is not compatible between differ-
ent versions of WP. Version 5.0 of the utility has been enhanced using the
following steps:

Use of XML Schema instead of DTD ¬le.
Support for mandatory type attribute.
Support for event handlers, URL Mappings, and property broker
wires. A wire connects a source and a target portlet instance enabling
changes to the source to be propagated to the target.
Ability to manage users and groups.
Support of object IDs, unique names, and the ordinal attribute
Support of role administration.

In version 4.2 the portal navigation structure was expressed as a tree of
components of type layered inside Root.Composition while in WebSphere
Portal version 5.0, labels and pages are organized in a tree that is expressed
by their content-parentref attributes. The navigation structure in the portal
is the same as the structure of the content tree. There is no root composition
de¬ned in the XML scripts anymore.
Do the following to migrate your XML Con¬guration scripts to WP V5.0,

1. Open a command prompt on your WebSphere Portal V5.0 machine
(sandbox5.rigorconsultants.com) and go to <wps_root>\
migrate directory.
2. Enter
WPmigrate migrate-xmlaccess-script -DScriptPath=<path>
-DScriptSrc=<scriptname> -DScriptDest=<convertedscriptname>

where <path> is the complete path to your script ¬le,
<scriptname> is the script ¬le name to be converted, and
<convertedscriptname> is the name of the converted script ¬le.
3. Wait for the Build Successful message and then check the
MigrationReport.xml ¬le for any errors.
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-06 WY009-BenNatan-v1.cls May 9, 2004 9:35




124 Chapter 6


Summary
In this chapter we reviewed the tasks and tools that are provided to assist
you in migration. We clearly did not cover all the situations such as migra-
tion of collaboration portlets, portlets based on struts, portlet toolkit, and
portlets using transcoding technology. We also did not bother with migra-
tion of WPCP and Personalization since they are both being replaced by
WCM.
The purpose of this chapter was to help you in the migration of the most
common components. For more detail information, we refer you to the
WebSphere Portal Migration manual.
At the end of the chapter, you are probably saying to yourself, “boy this
is complicated.” Well it is, and partly this is due to the rapid infusion of
functionality with each version of WebSphere Portal. With version 5.x, you
are seeing the product mature and the product becoming simpler to use.
We believe that migrations in the future will become easier as more effort
is put into delivering con¬guration and migration wizards.
Well, now that you have got WebSphere Portal up and running, it is now
time to actually use the product. In the next chapter, you will learn how to
easily de¬ne the look-and-feel components of your portal.
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-07 WY009-BenNatan-v1.cls May 17, 2004 18:43




PART
II
Building and
Administering Portals
with WPS




125
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-07 WY009-BenNatan-v1.cls May 17, 2004 18:43




126
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-07 WY009-BenNatan-v1.cls May 17, 2004 18:43




CHAPTER

7

De¬ning Portals and Pages

Portals and pages provide the framework for content delivery within Web-
Sphere Portal. Everything the user sees upon entering your portal is part of
a page. In this chapter you will learn the basic skills required to de¬ne and
customize the content delivered by your portal.
Pages are essentially scaffold around which your portal is built, and in
this chapter we focus on de¬ning portal structure. The concepts involved
are quite simple, and we will guide you through the most common tasks
associated with the construction and customization of your portal.



Portals and Pages
Complex data is usually stored in hierarchical structures, a common ex-
ample being ¬les and folders in an operating system. WebSphere Portal
follows this approach and uses a hierarchical structure to maintain the set
of resources and components used to generate the user experience.
In order to view the structure of the portal, you click the Administration
tab in the portal toolbar. To do this, you must be logged in as an administra-
tor. As we saw in Chapter 2, to log in as administrator, you need to access
the URL http://<hostname>:<port>/wps/portal, where hostname
is the server on which WebSphere Portal Server is installed and port is 9081
(unless you modi¬ed the default settings), and click Log in. Once you are
in the Administration tab, click Manage Pages under Portal User Interface.
WebSphere Portal Server will con¬gure your Portal Settings.



127
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-07 WY009-BenNatan-v1.cls May 17, 2004 18:43




128 Chapter 7


Logical Structure of a Portal
The Manage Pages window allows you to add, delete, edit, and reorder
pages in your portal. The portal uses a treelike hierarchical structure, where
the root of the tree is called Content Root. Nodes in this hierarchy belong
to one of the following types:

Pages
Labels
URLs

Pages are the basic building block used for displaying content in the form
of portlets. Page nodes may contain other nodes, including other pages.
A label is a placeholder for pages. Labels may contain other nodes, but
display no content, and are used to provide logical grouping of nodes.
This logical grouping is used to de¬ne common attributes such as access
permissions. URLs are used to access any resource that can be addressed
with a URL. URLs obviously do not contain any other nodes. URLs are
useful for addressing external Web sites or another part of the portal.
Note that there is no built-in notion of a “portal.” You may de¬ne multiple
portals inside WebSphere Portal by using the abstractions of pages or labels.
For example, you can create different subhierarchies for different sets of
users and consider each such subhierarchy as a portal.
Figure 7-1 shows the composition of the Content Root as per the default
con¬guration, immediately following product installation. We have ¬ve dif-
ferent nodes under Content Root of which three are labels and two are pages.
My Portal is a label containing the default portal con¬guration shipped
with the product. By default, users who do not have administrative priv-
ileges can only access this node. The Administration label is accessible by
users with administrative privileges, and incidentally is the label through
which you have reached the current page. The last label is Page Customizer,
which contains several portlets used for con¬guring page layout and con-
tent. This label is not accessible directly, but is invoked through the button in
the portal toolbar. The two pages under Content Root are Page Properties
and Organize Favorites. As the names imply, the former shows a portlet
used to edit some properties of pages, and the latter allows users to or-
ganize favorites through the My Favorites drop-down menu in the portal
banner. Note that Page Properties is hidden from navigation, which means
you cannot see a corresponding entry in the portal toolbar.
This is in fact the default behavior for entries that are directly under
Content Root. Typically, one would add new content at lower levels, for
example, under My Portal (in the next chapter you will see how to customize
the portal toolbar allowing you to access from there entries that are directly
P1: FCH/SPH P2: FCH/SPH QC: FCH/SPH T1: FCH
WY009-07 WY009-BenNatan-v1.cls May 17, 2004 18:43

<<

. 24
( 87 .)



>>