Bill Benac's Blog

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.

• WindowsKey-Break to open the System Properties Window
• Go to the Advanced tab
• Open the Performance settings
• Go to the Advanced tab
• In the Virtual Memory area, select Change
• Specify "Custom Size" and enter intitial of 2046 and max of 4092
• Click Set, then OK, then acknowledge you need to restart, then close apps, restart, and run the installer.

Properly set memory could look something like this:

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

Originally posted on http://blog.billbenac.com.

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!

Originally posted on http://blog.billbenac.com.

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.

Originally posted on http://blog.billbenac.com.

I've seen a couple questions lately about ways to connect to the ALUI API Service. There are two ways to use the EDK to connect to the API server. Which way you connect depends on the intend of the specific application.

One way to connect is with a specific username and password. That works well if you need the API server to access information or do actions not necessarily available to the browsing user. Let's take the example where you want to report the number of portlets in the system.

If you want all users to see the total number of portlets including portlets they do not have access too, then you would specify a privileged user for the API connection so that it could query everything. This would be hardcoded or set in admin preferences.

If you want users to see only the number of portlets to which they have access, then you would make the API connection using the credential of the current user. This uses something called the login token, and it is obtained programmatically.

I'll give example code for both, but let me first say that in either case, a variable should be set in the web.config file. The API call will want to know where the PTHOME directory is, and that's is best set in web.config rather than hardcoded. So with either solution, this should be in web.config:

  <appSettings>
    <add key="pthome" value="i:\\apps\\plumtree"/>
  </appSettings>

Then either case, you'll grab that variable from your code.

So if you want to connect using a specific user (usually one with elevated permissions), then you would do it like this:

  // create a session to portal and connect
  string sAdminName = ConfigurationSettings.AppSettings["admin-name"];
  string sAdminPass = ConfigurationSettings.AppSettings["admin-pass"];
  string sPTHome = ConfigurationSettings.AppSettings["pthome"] + "";
  com.plumtree.openkernel.config.IOKContext context = com.plumtree.openkernel.factory.OKConfigFactory.createInstance( sPTHome + "\\settings", "portal");
  PortalObjectsFactory.Init(context);
  IPTSession session = PortalObjectsFactory.CreateSession();
  try
  {
           session.Connect(sAdminName,sAdminPass,null);
  }

The admin-name and admin-pass for a production application should be set with an administrative preference and retrieved through the EDK so that they are not visible in the source file.

And if you want to connect with the individual user's context, then do this:

  // connect a session
  string sPTHome = ConfigurationSettings.AppSettings["pthome"] + "";
  com.plumtree.openkernel.config.IOKContext context = com.plumtree.openkernel.factory.OKConfigFactory.createInstance( sPTHome + "\\settings", "portal");
  PortalObjectsFactory.Init(context);
  session = PortalObjectsFactory.CreateSession();
  // we'll use the context of the logged in user
  try
  {
            session.Reconnect(edk.GetRequest().GetLoginToken());
  }

I have a sample portlet application attached that uses the user's individual context to connect to the API service and gather some information. Its zip file is here. It has a folder called install-resources with some install instructions.

I hope that helps,

Bill