Perficient

One of the great advantages of the WebSphere software platform is that it's been built with a great deal of flexibility. A product simply wouldn't bear the WebSphere name if there weren't several different ways to do things. WebSphere Portal Server is no exception. With the release of version 5.1 IBM has added another way to administer the configuration of the Portal. This is sure to delight the poor, overworked Portal administrator who doesn't want to learn the art of XMLAccess and wants to avoid the use of a Web-based administration interface all costs.

This new feature, named the Portal Scripting Interface, lets the portal administrator configure the system via the command line. It's an extension of the wsadmin command-line interface for WebSphere Application Server and so it uses a similar syntax including the ability to take JACL script files as input (hooray!). Believe me, this is an advance that many Portal professionals have been waiting for ever since the introduction of the wsadmin tool for AppServer.

The end result is an interface that automates portal admin tasks and eases the burden of making minute changes to nested Portal objects or transferring new portal configurations from a developer workstation.

The Portal Scripting Interface, which I'll call PSI from now on (not to be confused with pounds per square inch or some reference to psionic powers), is invoked from within the WPS_HOME\bin directory. The syntax would normally look like this:

WPS_HOME\bin\wpscript.bat

But of course it really isn't that simple. There are some implied parameters in that command. The first one is the connection type, or conntype. By default this value is SOAP, which indicates that the interface should connect to the Portal via the SOAP protocol. Another possible value could be RMI indicating that the interface should connect over IIOP. A third possible value could be NONE indicating that only the command shell should be launched and not explicitly connected to any running instance of the Portal (and not very useful for administering the portal).

The second implied parameter is the port on which to connect to the Portal. If you're using the default SOAP connection type, then the default value for the port parameter is 8882. In a Network Deployment configuration, you'd want to use the default port 8879 to make this connection. The SOAP connection port value of the server you're attempting to connect to can be viewed in the WebSphere Administration Console under Application Servers>WebSphere_Portal>End Points>SOAP Connector Address.

So an explicit string for launching the tool would look like this:

WPS_HOME\bin\wpscript.bat - conntype SOAP -port 8882

As you might expect, when WebSphere Security is enabled for the Portal, proper security credentials have to be supplied:

WPS_HOME\bin\wpscript.bat -conntype SOAP -port 8882 -
user wpsadmin -password password

Once the PSI has been launched, you must actually log into the Portal you're attempting to administer. This command, executed in the PSI, uses the syntax of the underlying wsadmin interface for AppServer. Familiarity with JACL or wsadmin would help at this point but it isn't necessary. Suffice it to say that commands are entered in a hierarchical format. They simply represent underlying Beans that are being invoked to do particular tasks. For our Portal login command, we have to invoke the Portal bean. After invoking PSI log into the Portal with:

$Portal login wpsadmin password

Congratulations! You're now connected to the Portal and ready to issue administration commands.

If you're using the new virtual portal feature of WPS 5.1, you can log into your virtual portal using a sub-command of the Portal bean. Let's say your virtual portal URI is /wps/myportal/blueportal (where the "blueportal" part of the URI indicates the name of the virtual portal), then the following commands

$Portal setvp blueportal
$Portal login wpsadmin password

will get you logged into the desired virtual portal.

Get Help Fast
Each of the beans available in this tool have help options. If I wanted to get a list of all of the available help options for the Portal bean, I could simply type

$Portal help

This would return the top-level list of help for the Portal bean. If I was more curious about just the login method of the Portal bean (which we used to log into the portal), I could type

$Portal help login

This would return help information specific to that method. The available beans in the PSI are:

$Portal
$Content
$Layout
$Portlet
$Look
$Access
$PacList

Experiment with the help function on each of them to gain a better idea of the hierarchical structure of this interface.

Work Those Index Paths!
Let's say I have a portal page hierarchy that looks like this:

	Content Root
	My Portal (label, uniquename:wps.myportal)
    	Home (page, uniquename:wps.myportal.home)
	Corporate Directory (page,uniquename: wps.myportal.CorpDir)
	WorkPlace (label, uniquename: wps.myportal.WorkPlace)
	Email (page, uniquename: wps.myportal.WorkPlace.Email)
	Docs (page, uniquename:wps.myportal.WorkPlace.Docs)

Let's think about this content-node hierarchy. If you were to think about the page structure in our example, you could assign some hierarchical values to the objects. For instance, the Content-Root we could say is at the root location of the tree, or simply /. If this were the case, then we could say that the My Portal content-node is one level down in the tree. Sort of like a directory off the root filesystem in Unix, this would be /0/1. The Home content-node, as a child of /1 would be at /0/1/2. This is called an index path.

Some examples of these index paths are as follows:

/ 	The root content node.
/0 	The first child of the root content node.
/1 	The second child of the root content node.
/0/0 	The first child of the first child of the root content node.
/0/1 	The second child of the first child of the root content node.
/0/2	The third child of the first child of the root content node.
0 	The first child of the current content node.
1 	The second child of the current content node.