Customizing the Portal Admin Tool (PAT)

Monday, June 23, 2008

The Portal Administration Tool, aka the PAT, is a great tool for allowing administrators to manage a portal deployment. However sometimes you want to extend the console to add extra features that are missing or specific to your application to enable administrators to control everything from one place. Fortunately in WLP 10 this is now supported and here is a little example I put together showing how easy this can be.

The documentation for extending the PAT is quite easy to follow and is located at http://edocs.bea.com/wlp/docs100/extendadmin/extend.html. This documentation lays out the steps to setup your customized PAT skeleton quite well and I am not going to repeat them here. Instead I will talk about moving beyond the skeleton to create something a little more concrete.

If you have been reading my blog for awhile you have probably noticed I have been covering WSRP quite a lot in the last year or so. This is because I have been heavily involved in a large federated portal project at a financial institution here in Canada. Thus continuing with the WSRP theme, the example extension I built addresses a specific pain point with with respect to the operational aspects of a federated portal, namely how do aoperational staff disable a producer when it is down for maintenance.

Starting in WLP 10, the com.bea.wsrp.consumer.management.producer.ProducerManager class allows for producers to be pro grammatically disabled or enabled as needed. Unfortunately this API has not yet been exposed in the PAT meaning that if someone wishes to use it a custom interface to the API needs to be built. Rather then writing a standard servlet or JSP I thought it would make much more sense to write a little console extension to do it and integrate the API right into the PAT.

The first thing that needed to be done was to create a page flow portlet to manage this new functionality. I am not going to go into the code in huge amounts of detail as you can download the code and have a look for yourself, however we do need to cover some of the highlights. This extension is built as a portlet but you can also build extensions as pages and books as well. The location of an extension in the PAT is controlled by the netuix-extension.xml file and is covered in the PAT extension documentation I linked to earlier. Here is the netuix-extension.xml file this example is using.

<?xml version="1.0" encoding="UTF-8" ?> 
<weblogic-portal-extension xmlns="http://www.bea.com/servers/portal/weblogic-portal/8.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/servers/portal/weblogic-portal/8.0 netuix-extension-1_0_0.xsd">
<provider-info>
	<title>BEA PS - WSRP Production Operations Extension</title> 
	<description>UNSUPPORTED EXTENSION - An extension that adds support for WSRP production operations, this is unsupported do not contact BEA Support for assistance.</description> 
	<author>BEA PS Canada - Gerald Nunn</author> 
</provider-info>
<portal-file>/portal.portal</portal-file>
<page-extension>
	<page-location>
		<parent-label-location label="portalProducerSummaryPage"/>
		<page-insertion-point placeholder-position="99"/>
	</page-location>
	<portlet-content content-uri="/portlets/producerOperations/producerOperations.portlet" instance-label="ptlProducerOperations_1"  title="Producer Operations"/>
</page-extension>
</weblogic-portal-extension>

The extension above tells the PAT to place this portlet on the producer summary page by specifying the parent-label-location label as portalProducerSummaryPage. Next the placeholder-position="99" in the page-insertion-point element is sufficiently large to have the PAT place the portlet at the end of all other portlets on this page. The content-uri attribute tells the PAT where to look for the portlet in our extension WAR.

In terms of the code itself, this portlet needs to integrate with the tree selection on the left side of the PAT since we need to know what portlet is active. To do this we use the com.bea.jsptools.patterns.tree.TreeStateBean class. Important. A big word of warning though, this class is not documented and supported by BEA so it may change in the future, use this with care and do not open support cases if it changes. I do have a support case open about this as the example here (http://edocs.bea.com/wlp/docs100/extendadmin/portletreuse.html) dealing with the reuse of PAT portlets also uses undocumented code from the same package. When I learn more I will post an update.

To use this class to get the current producer handle, I use the following code:

TreeStateBean bean = TreeStateBean.getTreeStateBean(getRequest(), false);
String producerHandle = bean.getSelectedNodeLabel();

Once you get the handle it is straightforward to enable and disable the producer as required, feel free to browse the code to see the specifics. Here is a closeup image of the portlet, click on it to see a full screen view of the PAT with the portlet.

The example code to download is adminConsole.zip. To use the example, simply unzip it into a directory and then import it into an empty workspace using the Workshop option "Import existing projects". Once this is done you can create a Portal domain using the Configuration Wizard and then deploy these projects from Workshop into the new domain. One aspect I did not cover here that I will likely talk about in a future post is creating a customized admin console as a shared library to improve reusability and seperate the development of the extended console from the portal project.

One final word about the usefulness of this extension in a production environment. The ProducerManager APIs to enable and disable producers can be useful in certain situations however it does have a flaw in that it does not provide a message to the user that the portlet is not available. As a result users could be left scratching their heads wondering why certain portlets are not appearing in the Portal. To counter that you may want to integrate a message somewhere to notify them of what is happening. For example, the home page could have an alert portlet listing what producers are down or the message could be integrated into the portal's header or footer.

Posted by Gerald Nunn at 9:08 AM | Categories: WebLogic | | | Permalink