Bill Benac

Today Oracle released  WebCenter Interaction 10gR3, the first Oracle-branded incarnation of the BEA's Aqualogic User Interaction product. I was eager to get started on upgrading a customer's ALUI 6.5 MP1 system to 10gR3. I encountered an "unexpected consideration" in the installer that you might call a bug. In my experience, on Windows the installer fails unless you explicitly allocate virtual memory.

I installed on five lab servers that had been running ALUI 6.5 MP1. The first succeeded, but on the second two servers, the installers failed.

In addition to working for Oracle, I'm a student these days. Periodically I'm asked by a class to watch a lecture on YouTube. Most recently, I've been watching this lecture by thought-leader Jyri Engeström in which he discusses objects around which communities socialize (photos, mobile phones, potato harvests, cats, etc) and what makes compelling services around these social objects. It turns out his lecture doesn't rely heavily on his slides, and I found myself wanting to listen to this through my mp3 player instead of sitting tethered in front of my computer. Yeah, yeah, I know I wouldn't have this problem if I had an iPhone, but...

Here's how I converted a YouTube lecture to MP3:

* Grabbed the mp4 video by going to http://keepvid.com, entering the YouTube URL, then clicking the download button. At this point, the video was on my laptop
* Used MMConvert to "Convert to MP3" as its left menu offers. I had it use the video as the source instead of the audio files it expected.

That's great, but... don't you figure there's an easier way?

Turns out someone else set up a service to do this conversion. You can use http://www.flv2mp3.com/ for this.

Of course, some YouTube content just isn't suited for MP3 format. An example is of my favorite video lectures by an anthropologist and interpreter of Web 2.0, Michael Wesch. Over the summer he gave an incredible lecture for the Library of Congress entitled An Anthropological Introduction to YouTube." Instead of converting the visual content into audio content, it will convert the YouTube hater into a YouTube lover.

As much as I sometimes feel afflicted by the distractions of frivolity of social media, I can't ignore that they can provide critical community, career opportunities, entertainment, advice, and so forth. So I'm glad to learn ways to interact with and manipulate content that might otherwise look locked in a delivery channel (e.g. YouTube) or format (video). I hope you'll benefit from these too.

The URLMapping section of portalconfig.xml isn't the most elegant part of the ALUI portal configuration. You are required, for each URL you intend to support, to repeat a block of settings but with incremented index values. I'm working with a customer using dozens of URLMappings, and we realized there had to be a better way than updating these individually. Enter Excel.

I created two spreadsheets, and the one you use depends on your environment and preferences. The simpler urlmapping-generator.xls creates a single mapping for each single URL you want to use, and this is what you would expect is required. However, as I wrote last year, there's a bug in how URLMappings are handled when a proxy or load balancer is involved, and the way to fix it is with an extra URLMapping. I have an advanced spreadsheet, urlmapping-generator-proxybugfix.xls for this situation, and it creates both the first mapping you would expect as well as the second mapping to handle the bug.

I hope this is helpful.

I'm working with a Collab deployment where we want to disable the search feature. This involves two things: disabling index requests from Collab to the Search Server and removing the search form from Collab's web UI.

Disabling Index Requests from Collab to Search

The easy part is disabling index requests from Collab to the Search Server. Just open %ALUI_HOME%\ptcollab\4.5\settings\config\config.xml and change the value for "search enabled" from "yes" to "no."

Removing Search from Project Explorer UI

For whatever reason, the Project Explorer view of Collab shows a search form even when the app is configured to not have its content index. This is shown below:

I spend a lot of time in web-based email systems, and I've lost way too many email messages to a timed-out session. If I'm writing something both important and complicated, then I often am still composing after my session times out. Then when I click send? I get an error message.



























Today though I realized that since the content of my message is still in my browser and resubmitted every time I refresh that error page, I can actually retrieve it. In Firefox, I have a HTTP header monitor called TamperData that shows me my headers, including the POST section from my web-based emails. In MSIE, I would use Fiddler, though I've not tested this exact use case there. In any case, I can indeed retrieve the message.

















The next problem though is the message is encoded with plus+signs+between+the+words and without line breaks separating paragraphs. I realized I could write some simple Javascript to decode the message properly. You may want to do the same thing. I'll put the code here for you to read/take, and I'll also put the form here for my use and yours.

Enjoy.

<script>
function getit(sin) {
mystr=unescape(sin)
mystr=mystr.replace(/\+/g," ")
document.myform.theoutput.value=mystr
}
</script>
<form name=myform>
<hr><b>Enter your encoded message:</b><br>
<textarea rows=4 cols=80 name=theinput></textarea>
<br>
<input type=button value="Decode it!"onclick=getit(theinput.value)>
<br>
<textarea rows=20 cols=80 name=theoutput></textarea>
</form>
 

---

Enter your encoded message:

Recently I had a conversation with someone about the features available in ALUI for portlet developers. We spoke mostly about what the IDK offers, but there's more too. The IDK is largely about data access and content transformation on the back end, either at the remote server level or in the portal's "gateway" processing space. But much can be done on the browser side too using adaptive portlets. I wrote a guide for this a long while ago, and it's still relevant and helpful. So I'll post it here.

The guide starts with a Word document that gives an overview and screenshots of adaptive portlets. Then it gives installation instructions for the samples that are provided with the guide in its zip file. I'll put the first few pages of the Word document in this post so you can know whether you want to download the entire guide with its sample code.

Getting Started with  Adaptive Portlets

BEA uses the term "Adaptive Portlets" to refer to portlets using AJAX--technologies generally based in JavaScript and XML that allow richer application development.  A simple introduction to this technology is provided through the "Intro to Adaptive Portlets" community with its associated portlets. This document describes that community and how to install it on your own system.

The "Intro to Adaptive Portlets" community consists of several pages. The main page describes the adaptive portlet technology.  Subsequent pages of the community illustrate different design patterns individually, and then the last page shows all technologies together in a cacophonous celebration. Screenshots of the pages are below.

Main Page


Auto Refresh


Inline Navigator


Inline Post


Master/Detail


Broadcast Listener


All in One!

Let's get to know how to easily do what the Collab installer doesn't let you do easily: manage its individual components.

At my current client, we're upgrading ALUI Collab 4.2 to 4.5 as part of our upgrade to ALUI 6.5. One feature of the new ALUI suite is that it offers a "common notification service" that replaces the collab-specific notification service that had been part of 4.2. Accordingly, we don't need the old Collab notification service. The official upgrade documentation says "If you have an existing Notification Service from your previous installation of Collaboration, disable or uninstall it." But how do you do that?

If you run the Collab 4.2 or 4.5 uninstaller on a machine with more than one Collab component, it will remove every component. That doesn't work well since you're trying to upgrade the Collab piece and remove the notification piece. Similarly, you may realize that you installed Collab 4.5's Search Service on the Collab box when you really want it on the Search box, so how do you remove just the Search Service?

In either case, you can use the batch file that is part of the undesired component, remove the service, then delete the files from the file system. In the case of the 4.2 notification, use this batch file: %ALUI_HOME%ptnotification\4.2\bin\ptnotificationserverd.bat, and in the case of the Search Service, use this batch file: %ALUI_HOME%searchservice\1.1\bin\searchservice.bat. Pass in the parameter "remove" and you're done.

Enjoy!

Are you familiar with the routine of opening the HTML source of an ALUI portal page, scrolling to the bottom, and checking for the name of the host server? This is something I've done countless times in load balanced environments when trying to test or debug a server.

I decided to make a Firefox plugin that will extract that portal host information then display it at the bottom of the browser so that I can immediately see the portal host.

I've had several other people try this plugin, and they found it useful. I hope you'll find it helpful too. To install it, download the plugin, then drag it onto your Firefox browser. It's been tested on FF versions 1.5 through 3.1.

Enjoy!

To access the public Internet from many enterprise environments, one needs to configure the browser on his or her laptop to go through a proxy server. Sometimes, this requirement applies as well to the servers that run ALUI as well. With a browser, it's a fairly straight forward point-and-clickety-clickety-click to enter the proxy information, but with ALUI products, it's more involved. It seems like I always need to check my old emails to find configuration instructions, so I'll post here to make it easier for me, and hopefully easier for you too.

Of the several core ALUI products, only a few need proxy information. Products like the Search or Document Repository server of course do not need to make requests to resources outside of the ALUI servers. The portal is the most obvious component for doing so. You might have a some portlets provide by Google for example that users should be able to access. The portal's proxy is configured by updating %ALUI_HOME%\settings\common\serverconfig.xml to use the following settings:

<component name="openhttp" type="http://www.plumtree.com/config/component/types/openhttp"> <!-- Leave the following ProxyServer value blank if you have no HTTP Proxy Server. --> <setting name="openhttp:ProxyURL"> <value xsi:type="xsd:string">http://www-proxy.myco.com:31060</value> </setting> <setting name="openhttp:ProxyUsername"> <value xsi:type="xsd:string"> </value> <setting name="openhttp:ProxyPassword"> <value xsi:type="xsd:string"> </value> <setting name="openhttp:ProxyBypassLocal"> <value xsi:type="xsd:boolean">true</value> </setting> <!-- Use semicolon-separated list for local addresses, --> <!-- e.g., www.example.com;*.plumtree.com --> <setting name="openhttp:ProxyBypass"> <value xsi:type="xsd:string">localhost;*.myco.com</value> </setting> </setting></setting></component>

A less obvious component that should be configured for proxy access is the automation server.  In some cases, portal administrators and content managers may choose to create a job that runs a portlet web service as its operation. One reason to do this is to generate the HTML that comes from a slow-running dynamic portlet. Antoer reason to do this could be if the code behind an URL ran some job. The automation server uses the same proxy setting configuration that the portal does in %ALUI_HOME%\settings\common\serverconfig.xml.

Finally, the new Remote Portlet Service's RSS Reader needs a proxy configured in order to get feeds outside the enterprise. The settings are to be put in %ALUI_HOME%\remoteps\1.0\settings\config\wrapper.conf. In myco's case, the proper settings were:

wrapper.java.additional.22=-Dhttp.proxyHost=www-proxy.myco.com
wrapper.java.additional.23=-Dhttp.proxyPort=31060
wrapper.java.additional.24=-Dhttp.nonProxyHosts="localhost|*.myco.com"

It is important to follow the example settings in the file correctly. The nonProxyHosts setting needs to be in quotation marks, but the proxyHost and proxyPort should not be.

It is also important to not follow the example settings with regard to the setting number. The file suggests:

#wrapper.java.additional.19=-Dhttp.proxyHost=
#wrapper.java.additional.20=-Dhttp.proxyPort=
#wrapper.java.additional.21=-Dhttp.nonProxyHosts=

However, 19, 20, and 21 are used by previous settings, so the proper wrapper.java.additional numbers will be increased as shown in the myco example.

Enjoy!

A colleague, Jeff, called today to ask about various performance-related items including ALUI portal caching.  Many people know that portlet developers and administrators can coordinate to control caching of portlet content. This lets the company news portlet content, for example, be fetched once in an hour into memory and then be shared between all users, while the paycheck content is fetched for each individual user. Less well known though is that the system administrator can tune how the portal server handles the cache. How many of those paychecks for example should be stored in memory before being replaced?

So Jeff and I chatted a bit about the options and effects of tuning portal server caching today. I was reminded of analysis I did at one customer which was interested in whether performance (on version 5.0.4) could be improved by using more of its spare portal server memory for caching. We found that it isn't worth the trouble to tune away from the default settings because the system works great out of the box. I believe the analysis applies to current versions as well.

I'm not writing this as a blind fanboy who sees nothing but the brilliance of the ALUI product. Rather, after a careful analysis, I realized the tunings really are fine. You'll probably agree with me when you consider how the portal caching works. Basically, the portal stores content in its cache based on how recently used it is. So the more frequently used content is, the more likely it is to regain its place on the top of the list of items to cache. When an item is infrequently used, it will be pushed down the cache list by other items and ultimately get pushed out. But this means that the most important content, the most frequently used, is always on the top of the list. All that content toward the bottom of the list doesn't get used frequently anyway, so who cares if it gets pushed out of cache? And if you triple the cache size, then you just store several times more unimportant content in cache.

If you never knew the portal cache settings could be tuned, then forget you read this post because it doesn't matter. But if you were casting about on the Internet looking for information about this topic, stop while you're ahead! Don't bother fixing what isn't broken. It would be better for you to tinker with your image server's content expiration headers for something that will really have impact.

Want data? Feel free to read the presentation I did on the results of my analysis. You'll see that when we tripled the cache size, we gained only insignificant reduction in requests to remote servers.