As a WebSphere AppServer or PortalServer administrator, your world can be a constant learning curve as new applications come along that utilize different aspects of the IBM middleware platforms. You may, for example, have mastered the art of deploying portal configurations using full or partial portal exports. This is convenient and easy to do. However, it may not give you the flexibility required for that new upcoming portal application that is being conceived in the minds of your company's Java developers. Luckily for you, XMLAccess is quite flexible.

Assuming you are familiar with the basic concepts of XMLAccess, the following refinements to the process should be straightforward. Instead of taking a full export from your production environment, suppose you wish to only export the portlets? In XMLAccess, the portlet is represented by the object type "web-app." Naturally you could generate an export of the portlets using the following XML (which is included in the samples shipped with Portal):

<?xml version="1.0" encoding=
  "UTF-8"?>
<request
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation
      ="PortalConfig_1.3.xsd"
    type="export">
    <portal action="locate">
        <web-app action="export"
          objectid="*"/>
    </portal>
</request>

By importing this xml file, we direct the portal to export only the web-app object called '*' which is a wildcard for all web-apps. The command would be as follows:

xmlaccess.bat -in C:\temp\export_
  all_portlets.xml -user wpsadmin 
  -pwd wpsadminpwd -url http://
  portal.example.com/wps/config 
  -out C:\temp\outputfile_all_
  portlets.xml

Right, so very easy. However, this sort of thing is useful only if we already have a portal configured with all of the portlets. If we're exporting all "web-app" objects, this assumes we have some to export in the first place. Suppose you have 50 new portlets that all need to be installed, but you have no existing portal that has all of them in place. Are you going to use the portal admin interface and click-click-click your way through installing 50 portlets, assigning permissions, creating pages, putting the portlets on the pages, etc. etc. etc.? Probably not - at least, I know I wouldn't.

How can we use XMLAccess to build a portal configuration if we are deploying portal elements for the very first time? This task won't involve exporting a config from somewhere, since we don't have things configured in any environment yet. Instead we're going to construct our XML files from scratch and import them into a blank portal in order to build our configuration.

The various XML files referred to from this point forward are printed at the end of this article.

The Blank Portal
When installing WPS, it is often desirable to deploy the portal without the sample pages and labels and portlets; it is simply too much clutter. To install a blank portal, use the following command when invoking the installation program:

install.bat -W installPortlets
  Sequence.active="false"

Proceed through the portal install sequence as you normally would. When complete, start the portal and go the portal home page. You should now see the blank portal.

Before continuing, be sure to have all of your necessary files in place. That is, if you are installing a theme, place the folder containing the theme on the PortalServer in the correct location. The same goes for skins, portlet WARs, etc.

Theme folders go into:
C:\WebSphere\AppServer\installedApps\<nodename>\wps.ear\wps.war\themes\html\

Skin folders go into:
C:\WebSphere\AppServer\installedApps\<nodename>\wps.ear\wps.war\skins\html\

By default, portlet WAR files need to be placed in:
C:\WebSphere\PortalServer\installableApps

With our blank portal installed, and with our component files in place, let's begin constructing our new portal. We'll start with the skins and themes.

Install Skins and Themes
The XML to install the theme will of course include the standard XML header for WPS 5.1. After that, we will do the required locate action on the "portal" object. After this we will instruct XMLAccess to perform an "update" on our skin with the parameters that we specify as show in Listing 1.

The skin object we specified includes the objectid, uniquename, and resourceroot parameters. Objectid will be the skin's referential id within the portal database. For ease of use, we also have a uniquename specified for this skin so that we can easily refer to the skin from this point forward. The resourceroot indicates the case-sensitive folder name of our skin that we placed in the skins\html\ directory.

Let's save this file as import_skins.xml. Once we import this file, we will have installed the skins into our portal:

xmlaccess.bat -in C:\temp\import_
  skins.xml -user wpsadmin -pwd  
  wpsadminpwd -url http://portal.
  example.com/wps/config 

To install our themes, we need an XML file with similar information (see Listing 2).