March 2007 Archives

Using Google Portlets in ALUI

| | Comments (0)
I was asked to take a look at the Google-powered "gadgets" that can quickly be added to an ALUI portal as portlets.

My first response is that I like Google's terminology. Ahh, the good old days before Plumtree changed its jargon to the "industry standard" of "portlets" instead of the arguably better "gadgets."

And functionally? Google's offerings are standard JavaScript-driven syndicated gadgets. Basically, they provide content you can display within your own portal. You can go to the Google gadgets website, read up on the concept, then click into the list of gadgets to see whether any are appropriate for you. The selection is great. Some are pure fun, designed for your blogging teenage sibling or child, such as the Tetris game. Others are likely candidates for a company's intranet, such as the weather and stock quotes portlets. Here's the (depressed) BEA stock quote as it displayed in my portal:


It's very easy to add this stuff to your portal. You pick the content you want, fill out some parameters for the desired size and colors, maybe a zip code for a weather portlet or a stock symbol, then click to get the HTML that you'll use for your portal to grab the content. The HTML string they provide is a single line. The format will be something like this:

<script src=";output=js"></script>

If you want to get content into your portal quickly, this content could be very attractive to you.

On the other hand, the Google solution isn't perfect. For example, the content displays in your portal with its own stylesheet information, so it's likely that your portal stylesheet won't match the Google content's stylesheet. Portal managers are all over the map as far as how much they care about consistent look and feel. Some will find this anathema, and others won't even notice. Take a look at this, for example, where neither the font nor color of the Google portlet matches my portal:


Also, you may find it annoying that users are one click away from leaving your portal if you use these. You can't keep the clicked content within your portal, like you would with a custom portlet. For example, if you submit flight details into the portlet above, you'll go to the website outside of the portal. Even if you were to set the URL of the content-provider as a gateway URL prefix for the web service and specified that gatewayed content should display under the portal banner, you still wouldn't be able to affect this behavior. That's because the content loads up directly by the user's browser via JavaScript instead of getting passed through the portal server where it would have its URLs manipulated based on those web service settings.

It's important to realize that Google's gadgets provide just one example of what many sites are doing: providing content that you can stick in your portal. Google is great because you can be confident it won't go away, and it's a magnet for content providers. But there are other options out there:, which many years ago started providing news content this way, still lives. They provide great options for customizing presentation, since instead of just giving a single line to describe the content, they give you many dozens of lines that include their stylesheet definition, whether to include dates, and so forth. See how nicely the New York Times headlines appear in my portal:


Also, many of the originators of content let you sign up to get a snippet of code to create a portlet., for example, offers it here.

And then there are vast catalogs, filled with junk, but with jewels too, such as what you find at or I was feeling cheery, so I grabbed a nice terror alert portlet from widgetbox:


Anyway, the point is that this content is abundant. And how do you put this stuff into your ALUI portal exactly? Any customer can follow these steps:

  1. Create an html file such as stockquote.html that contains the code snippet from Google (or whomever).
  2. Place that file on a webserver of your choosing. You might drop in on your image server (I know you have one) in %pt_home%\ptimages\imageserver\RemoteGadgets.
  3. Browse to the page to make sure you have the URL right:
  4. Create a new web service, selecting a remote server object that points to your web server and entering the URL of your portlet:
  5. Create a new portlet based on your web service.
  6. Add the new portlet to your MyPage or Community page.

The folks who suggested I post about Google's gadgets? They gave me screenshots showing how this can be even easier with the ALUI Publisher product. The nice thing there is that you can use Publisher's Announcement template to immediately create a portlet that takes arbitrary HTML content (your Google gadget snippet) without requiring you to put anything on the file system as in my previous instructions. It's basically driven by portlet preferences, and if you know much about those, then you know that you can create this same affect with a custom-written preferences portlet that won't require you to purchase a big product like Publisher. Here are those Publisher screenshots, and you can imagine how this would work with your own prefs portlet too:

  • Create a new Announcement portlet in the portal (AquaLogic Interaction). In the administrative preferences for that portlet toggle to the source view:


  • Insert the tag and click finish:


  • Add the portlet to your page.


Often ALUI customers deploy portals accessed through a single URL that doesn't go directly to the portal servers. This may be the URL of an SSL accelerator, a load balancer, or a proxy. Unless the customer deploys their portal with an extra URLMapping or two, then portal administrators or IT staff may find themselves inconvenienced in that they can only access the portal through the single public URL. It can be much easier to debug load balancer problems or troubleshoot an SSL portal if the admins can access the system through administrative URLs. The portal's URLMapping feature can allow this.

This article will explain the URLMapping feature, show a common but limiting configuration with proxies or SSO, and show alternate configurations that are more flexible.

What are URLMappings?
The portal needs to know how to write its HTML so that links go to URLs that make sense to the end user. In the simplest portal configuration, users browse directly to the portal (http://simple/portal/, and the portal returns a page with links that continue to use http://simple/portal/ No mapping required. But consider a more advanced configuration that involves a load balancer. Users browse to http://public/portal/, then the load balancer fowards traffic to http://serverA/portal/ and http://serverB/portal/ The portals needs to return HTML to the end user with the base of http://public instead of http://serverA. URLMappings instruct the portal how to do this.

How URLMappings Work
URLMappings are configured in \plumtree\settings\portal\portalconfig.xml or \plumtree\ptportal\5.0\settings\config\x_config.xml. You can create as many URLMappings on a system as you'd like. Each mapping has three elements:

  • URLFromRequest is the URL the portal sees in the incoming request. This isn't necessarily what the user typed in, such as when the portal is behind a load balancer or proxy. The portal tries to match the incoming request to the URLFromRequest value, and if it finds a match, then it will map according to the values found in the next two elements. You can look in PTSpy for a message like this one to know what the portal sees: Entering handleRequest: GET http://serverA:80/portal/
  • ApplicationURL is the base URL the portal will use to rewrite links for HTTP traffic.
  • SecureApplicationURL0 is the base URL the portal will use to rewrite links for SSL traffic.

The portal evaluates each URLMapping in its config file, and once it finds a matching URLFromRequest, it can rewrite URLs. The portal must find a match though, and so you must make the final URLFromRequest setting an asterisk to handle any case not matched by prior URLMapping rules (an IP address, for example).

Common Configurations
I show examples in the XML format used by 5.x portals since visually its more concise than the 6.x format. The concept is the same in both versions though. By default, the URLMapping section looks like this in 5.x portals:

<URLFromRequest0 value="*" /> 
<ApplicationURL0 value="*" /> 
<SecureApplicationURL0 value="*" /> 
That is essentially a pass-through mapping. Users can go to http://simple/portal/ or https://simple.fully.qualified/portal/, and the portal will write links to keep them on the same base they first entered.

With a load balancer, the URLMapping section could be as simple as this in the case that the user types in http://public to get to the load balancer, then the load balancer forwards traffic to http://serverA:

<URLFromRequest0 value="*" />  
<ApplicationURL0 value="http://public/portal/" />  
<SecureApplicationURL0 value="https://public/portal/" /> 

Advanced Configurations
Many customers don't go further than the above mappings. But lets say you have http://serverA and http://serverB behind your load balancer, and you want to be able to browse to a specific server. You could use the following URL mapping to do this. It tests whether the user requested a specific machine. If they did, they'll stay on that machine. Otherwise, they'll use the load balaner's URL:

<URLFromRequest0 value="http://serverA/portal/" />  
<ApplicationURL0 value="http://serverA/portal/" />  
<SecureApplicationURL0 value="https://serverA/portal/" /> 

<URLFromRequest1 value="http://serverB/portal/" /> 
<ApplicationURL1 value="http://serverB/portal/" /> 
<SecureApplicationURL1 value="https://serverB/portal/" /> 

<URLFromRequest2 value="*" />  
<ApplicationURL2 value="http://public/portal/" />  
<SecureApplicationURL2 value="https://public/portal/" /> 
It's also possible that for security purposes, you want to require all traffic to go through an URL protected by an SSO product or through a proxy. How can your system administrator debug, such as when you think a problem is caused by your proxy? You could configure an URLMapping so that when the system administrator logs into the server console, he or she can then access the portal at http://localhost/portal/
<URLFromRequest0 value="http://localhost/portal/" />  
<ApplicationURL0 value="http://localhost/portal/" />  
<SecureApplicationURL0 value="https://localhost/portal/" /> 

<URLFromRequest1 value="*" /> 
<ApplicationURL1 value="http://public/portal/" /> 
<SecureApplicationURL1 value="https://public/portal/" /> 
There are other ways to put URLMappings to work for you, but this discussion should give you the base understanding required to get started.
And a Bug
[Added July 23, 2007]

It turns out there's a bug. Basically, gatewayed portlet content has URLMapping rules applied to it twice. So let's say initial configuration were this:

URLMapping0: http://internal1/portal/ -> http://proxy1/portal/
URLMapping1: http://internal2/portal/ -> http://proxy2/portal/
URLMapping3: http://internal3/portal/ -> http://proxy3/portal/
URLMapping4: * -> http://everything.else/portal/

So a user browses to their My Page, and the URL for links to portal infrastructure such as other My Pages or Communities would propertly rewrite from http://internal1/portal/ to http://proxy1/portal/ But within the gatewayed content of the portlet, a second rewriting would occur. In this case it would rewrite http://proxy1/portal/ (which matches to *) to be http://everything.else/portal/

The workaround isn't too hard. All you need to do is have a URL mapping section that matches the external URL and says "when this URL is encountered, leave it alone."

You would add mappings such that:

URLMapping0: http://internal1/portal/ -> http://proxy1/portal/
URLMapping1: http://internal2/portal/ -> http://proxy2/portal/
URLMapping3: http://internal3/portal/ -> http://proxy3/portal/
URLMapping4: http://proxy1/portal/ -> http://proxy1/portal/
URLMapping5: http://proxy2/portal/ -> http://proxy2/portal/
URLMapping6: http://proxy3/portal/ -> http://proxy3/portal/
URLMapping7: * -> http://everything.else/portal/