The installation process for the portal will be pretty familiar to those of you who’ve done any before, although there are a LOT of new options, as Oracle has chosen to bundle together most of the new stuff into three uber-installers (Portal, Collab, Analytics).

The portal installer in particular really throws in everything and the kitchen sink – even things like the IDK and Documentum Crawlers are all bundled in there:

Details after the break.

For reference, the installer options are:

• Portal Services and Components
• Administrative Portal
• Automation Service
• Portal
• API Service
• Image Service
• Search
• Document Repository Service
• Content Upload Service
• Directory Service
• Remote Portlet Service
• Notification Service
• Tagging Engine Service
• Search Service
• Crawler Services
• Documentum Content Service
• UCM Content Service
• Lotus Notes Content Service
• Windows File Content Service
• Exchange Content Service
• Identity Services
• LDAP Identity Service
• Active Directory Identity Service
• Development Tools
• Interaction Development Kit (IDK)
• JSR 168 Container
• .NET Integration Services
• Console for Sharepoint

I ran through the installer on Windows Server 2003 using SQL Server 2005, and the experience was pretty much the same as it has been for years. I got some unexpected/unspecific errors, but it turns out that they were related to me trying to install components (like the Documentum Crawler) without the appropriate prerequisites (DFC Runtime).

What really has me interested here is that Oracle really has thrown in the “Kitchen Sink” – including a bunch of very old apps that have floated around but never really got Oracle support, including:

• Pathways
• Enterprise Poke
• KD Browser
• my picture profile
• posted links
• profile portlet

Fun times importing all those PTEs!

Stay tuned, as we’ll be taking a look at most of those pieces of “new” functionality soon!

Contrary to my previous report, you can still find the installation package in the usual “Oracle BEA” media pack, and the installers sit alongside all the others:

Still painfully missing is Publisher, which technically isn’t supported on the new Windows platforms (Windows Server 2008, SQL Server 2008). And since Publisher needs to reside in the same database as the portal, well, this stack still isn’t “fully supported” if your IT department is nagging you to get your existing portal stack off Windows Server 2003 or SQL Server 2005. I’m still looking for an official (or unofficial) response from Oracle on this oversight: we know Publisher is end-of-life’d, but are we at least going to get the existing Publisher 6.5 binaries certified on these platforms? Or is the official party line that we HAVE to move to UCM? And if so, where are the migration tools?

Oh, and while we’re “nitpicking” (if you could call such a glaring omission “nitpicking”), Brad mentions that he’s been informed there are over 200 bug fixes. Sooo… why isn’t Oracle providing a list of significant fixes in this release like they have in every past release? I mean, the release notes list 36 “known issues”, but has no “resolved issues” section. Strange, huh?

Today Oracle announced WCI 10gR4 through their blog and tech network. The problem is: the download isn’t available yet, and there’s already some conflicting information out there.

Following the instructions on the download page, you can see that you’re no longer supposed to find the download via the Oracle Software Delivery Cloud using the “Oracle BEA” Media pack, but the “Oracle Application Server 10g Release 3 (10.1.3) Media Pack”.

No 10.3.3 yet:

Aside from the conflicting information about the version being available and not being there, there’s more conflicting info after the break. Stay tuned, though, as I’m sure this’ll all be worked out soon, and we’ll keep you posted on new features and functionality!

Analytics is still a bit of a mystery. Here and here, the version for WebCenter Interaction is 10gR4 (aka 10.3.3.0.0), and WebCenter Collaboration is 10.3.3.0.0, but WebCenter Analytics is 10.3.0.2.0. Fine, so Analytics didn’t get a full point release, that’s OK, right? The problem is, the Certification Matrix shows that Windows Server 2008 isn’t supported:
.

But, the online release notes say that Windows Server 2008 is supported. So here’s to hoping that’s just an oversight, and when we go to update our full Plumtree stack, we’re not going to be stuck with running Analytics on Windows Server 2003.

Even if Analytics is supported on the latest OS, there’s a bigger problem here. You’ll notice that Publisher is conspicuously absent – is THAT going to be supported in Windows Server 2008 or SQL Server 2008? I’m glad to see the new software is backwards-compatible with the older platforms, but almost every WCI customer from the Plumtree and BEA ALUI days uses Publisher. And Publisher has to connect to the WCI database. So if Publisher isn’t certified to run on the newer version of Windows or SQL Server, then where does that leave us if we want to do a platform upgrade of OS and DB?

I really hope for those clients who would like to do a full platform upgrade that we’re not going to have to deal with a Frankenvironment until there’s a Spaces migration plan.

Try this query to get hit counts for each card in the KD, and marvel in the awesomeness that is your popular documents – regardless of how many times your Analytics collector dies:

SELECT     ptc.name, ptcs.CARDID, ptcs.POPULARITY, ptcs.HITCOUNT, ptcs.LASTHIT
FROM         PTCARDSTATISTICS ptcs, PTCARDS ptc
WHERE     (LASTHIT > GETDATE() - 30) AND (HITCOUNT > 0) and (ptcs.cardid = ptc.objectid)
ORDER BY HITCOUNT DESC

Interesting side note – notice how all those document hit counts are a multiple of 10? The reason for this is a scalability approach that Plumtree came up with years ago. The idea is that rather than writing to the database every single time a document is downloaded, the code only increases the hit count 10% of the time, but increases the count by 10 each time. So, statistically, the counts are accurate over time, but the database is written to much less frequently.

So, spend 47 seconds to activate HTTP by editing this value in %PT_HOME%\configmgr\2.0\settings\config\private.xml:

<setting name="EAS:httpEnabled">
<value xsi:type="xsd:boolean">true</value>
</setting>


Viola! You now don’t have to use SSL to access the configuration manager. In 1,000 days, your 47 second time investment of time will have paid off:

BTW, you should probably just set the “BEA AL Configuration Manager” service to manual to save a couple megamajigs of RAM – once things are set up you shouldn’t bother leaving the service running anyway.

Oh, and don’t bother wasting the additional 5 minutes trying to turn on Basic Authentication because you think all the cool kids are doing it. That janx don’t work:

<!-- Authentication type. Should be blank for none, and set to either "JAAS" or "BASIC" if enabled. -->
<setting name="EAS:authType">
<value xsi:type="xsd:string">BASIC</value>
</setting>
<!-- EAS:basicAuthUser = username of the sole user allowed to access this server. Note: This user is given the role EAS:name iff authtype == "BASIC" then this setting takes effect -->
<setting name="EAS:basicAuthUser">
<value xsi:type="xsd:string">user</value>
</setting>
<!-- EAS:basicAuthUser = password of the sole user allowed to access this server. Note: This user is given the role EAS:name iff authtype == "BASIC" then this setting takes effect -->
<setting name="EAS:basicAuthPassword">
<value xsi:type="xsd:string">password</value>
</setting>



# JSComponents need to directly access the imageserver from the Publisher
# machine in order to obtain some configuration information. By default it uses
# the image server URL which is provided by the portal for portal end-users,
# but you may also specify an alternate image server URL to be tried first instead,
# such as in the case where the system topography prevents the Publisher
# from accessing that end-user URL.
#JSComponents.AlternateImageServerUrl=http://machinehost:port/imageserver


Problem is, it doesn’t seem to work for the diagnostic tool, and may not work when Publisher needs to load community-themes.txt (which it needs in order to provide the style sheet drop-down for header portlets). So Publisher still needs to connect to the image server – but if the image server is configured to only use SSL, you’re likely going to see an error like this:


Exception Message: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target


The solution – import the SSL certificate from the imageserver – is after the break.

[Credit goes to mkyong for outlining the majority of the procedure. The link for the code referenced there was broken, so I found it on code.google.com.]

The steps are pretty straightforward:

1. Download InstallCert.java
2. Remove the first line referencing the package to make compilation easier
3. Run: C:\bea\alui\ common\jre\1.5.0_32\ bin>javac InstallCert.java
4. Run: C:\bea\alui\ common\jre\1.5.0_32\ bin>java InstallCert portal.site.com:443
5. Run the same command again to validate the certificate: C:\bea\alui\ common\jre\1.5.0_32\ bin>java InstallCert portal.site.com:443
6. Move jssecerts to C:\bea\alui\ common\jre\1.5.0_32\ lib\security

No Publisher restart needed – Publisher’s diagnostic tool should now go all green-lighty for you:

But, what if you’ve customized the portal navigation and aren’t using the out-of-the-box header bar? We’ve gotchya covered – there are actually three ways this can be done.

Add the Adaptive Tags to your own header
The following code comes from \imageserver \plumtree\portal \private\pagelayouts \basepagelayout.html. You can stick this code into any header (or footer, or portlet) to get the Debug link to show up, and it will only show up for the appropriate users.

    <pt:core.comment><!-- DCA - get the Rules Debug link; if we don't have access to the rules debug page, the variable won't exist --></pt:core.comment>
    <pt:ptdata.rulesdebugdata pt:id="rulesDebugLink" />
    <pt:logic.existexpr pt:data="rulesDebugLink" pt:key="canAccessRulesDebug"/>
    <pt:logic.if pt:expr="$canAccessRulesDebug">
        <pt:logic.iftrue>
            <pt:core.comment><!-- DCA - there should only be 1 --></pt:core.comment>
            <pt:logic.foreach pt:data="rulesDebugLink" pt:var="link">
                <li><pt:core.html pt:tag="a" target="_blank" href="$link.url"><pt:core.html pt:tag="img" src= "pt://images/plumtree/portal/private/img/icon_subportal_rule.gif" alt="$link.title"/></pt:core.html><pt:core.html pt:tag="a" target="_blank" href="$link.url"><pt:logic.value pt:value="$link.title"/></pt:core.html></li> &amp;nbsp;|
            </pt:logic.foreach>
        </pt:logic.iftrue>
    </pt:logic.if>

Access the URL
The debug Messages page is available at /portal /server.pt? open=space &name=RulesDebugMSGAS. You can just drop that URL in there and the browser should display the debug page if you have access.

Use the MemoryDebug space
Finally, the portal session object stores this information so that it can be accessed through the MemoryDebug page we’ve discussed before. Just flip your URL to /portal /server.pt /debug /memory and you’ll see something that’s a little less readable, but still a functional alternative to the above two methods:

One caveat to all of these methods is if you have Community-based rules. Because sometimes the debug page itself applies its own URL for the rules, in some cases that means you’re no longer in any communities, so that could mean you get a false-negative for that condition. Your mileage may vary.

In analyzing our logs, fewer than 5% of our roughly 5,000 users were actually using IE9. And in our testing, most of the site worked with IE9, so we didn’t want to prevent these users from accessing the majority of the site. Finally, we didn’t want to send an email or put a message on the site that didn’t apply to the other 95% of users. The solution? A piece of Javascript in the header that would display a warning to only those users accessing the site with IE9:

This JavaScript is based on a function I found here. It’s pretty simple, and can obviously be tailored for other purposes – like IE9 not working in ALUI Publisher.

<script>
function getInternetExplorerVersion()
// Returns the version of Internet Explorer or a -1
// (indicating the use of another browser).
{
  var rv = -1; // Return value assumes failure.
  if (navigator.appName == 'Microsoft Internet Explorer')
  {
    var ua = navigator.userAgent;
    var re  = new RegExp("MSIE ([0-9]{1,}[\.0-9]{0,})");
    if (re.exec(ua) != null)
      rv = parseFloat( RegExp.$1 );
  }
  return rv;
}
function checkVersion()
{
  var msg = "IE9 is not supported.\nYou're using an UNSUPPORTED version of Internet Explorer.";
  var ver = getInternetExplorerVersion();

	if ( ver >= 8.0 ) {
		alert(msg);
		ie_alert = document.createElement('div');
		ie_alert.setAttribute('id', 'timeoutwarning');
		ie_alert.style.display='block';
		ie_alert.style.backgroundColor='#FFFF66';
		ie_alert.style.padding='15px 15px 15px 15px';
		ie_alert.innerHTML=msg;
		document.body.insertBefore(ie_alert, document.body.firstChild);
	}
}
window.onload = function() {
	checkVersion();
};
</script>

Experience Definitions are useful constructs in the portal that allow you to customize the header/footer, navigation, and Adaptive Layouts based on Experience Rules – which can be applied based on the host IP, community, user/group, or user-agent header. So you can apply different rules based on any of those criteria and heavily customize the experience based on any of those conditions.

An useful feature that was introduced with Experience Definitions was the “Debug Mode”, which can be accessed from Administration -> Select Utility -> Portal Settings -> User Settings Manager:

When this option is selected, a new link for “Show Debug Messages” is shown in the standard topbar, or in the out-of-the-box Adaptive Layout:

From this link, you can see the “Rules Debugging Messages”, which explains each rule, whether it matched the condition, and how long the evaluation took:

You can view the original post for the source code and a description of how this filter works, but recently I’ve discovered that the MIME types in the original post should be updated for recent Office documents (.docx and .xlsx). Instead of “application/msword”, the config file should use the MIME types provided by Microsoft. Specifically, the configuration file for OpenerFilter should look more like the following:

<?xml version="1.0"?>
<IntegrystOpener>
 <default>
  <removeContentDisposition value="0" />
  <replaceContentDispositionWithInline value="1" />
  <fixContentType value="1" />
 </default>
 <extension-map>

  <doc value="application/msword" />
  <dot value="application/msword" />
  <dotx value="application/vnd.openxmlformats-officedocument.wordprocessingml.document" />
  <docx value="application/vnd.openxmlformats-officedocument.wordprocessingml.document" />
  <xlt value="application/vnd.ms-excel" />
  <xls value="application/vnd.ms-excel" />
  <xlst value="application/vnd.openxmlformats-officedocument.spreadsheetml.sheet" />
  <xlsx value="application/vnd.openxmlformats-officedocument.spreadsheetml.sheet" />

  <pdf value="application/pdf" />
  <gif value="application/octet-stream" />
  <jpg value="application/octet-stream" />
  <png value="application/octet-stream" />

 </extension-map>
</IntegrystOpener>