Webcenter Interaction Blogs (aka Aqualogic Interaction)

It’s not without some controversy (OK, “spirited discussion”), but I’ve strongly recommended the use of host files to aid environment portability.  If you’re a believer in this “alias” approach, you’ll find that for some components, it isn’t very obvious how to set up those aliases.  This isn’t quite a host file hack, but serves the same purpose:  when you migrate the database from one environment to the other, you want to avoid having to change as many settings as possible.

One of these settings is the ALUI Automation Server: in “Select Utility: Automation Service”, you get a list of servers running the Automation Service, and can set which administrative folders are associated to which Job (aka Automation) Servers.  If you migrate the portal database between environments, you might have one entry show up for “PRODPORTAL3″ (in prod) and another for “PORTALDEV9″ (in dev).  But then in the dev environment you have to re-register every one of the folders that was associated with the prod folder. 

What if you could just create an alias that worked in both environments?  Fortunately, you can, and the tweak is easy:  Just edit %PT_HOME%\settings\configuration.xml in both environments, and change the value below to be the same thing.  Then, when the automation server in either environment starts up, it’ll look for jobs registered with that same name:

<component name="automation:server" type="http://www.plumtree.com/ config/component/types/automation">
<setting name="automation-server:server-name">
<value xsi:type="xsd:string">WCI-AUTOMATION</value>
</setting>

Oh, and if you’re a “UI” kind of person, you can achieve the same result by changing the name through the Configuration Manager:

You can do a lot with a few simple SQL queries against the ALUI / WCI database.  Oracle (and I) strongly discourage any direct database updating without using the API, but there’s nothing out there that says you can’t QUERY the database – heck, for Analytics server, it’s actually encouraged (PDF Link).

So, today’s post is an easy one that answers the question: “which pages and communities are my portlets displayed on”?  The SQL is simple:

 select
                        ptcommunities.name community_name,
                        ptpages.name page_name,
                        ptgadgets.name portlet_name
from
                        ptcommunities,
                        ptpages,
                        ptpagegadgets,
                        ptgadgets
where
                        ptcommunities.folderid = ptpages.folderid
and                ptpagegadgets.gadgetid = ptgadgets.objectid
and                ptpages.objectid = ptpagegadgets.pageid

… and you’ll get a list of communities, pages and portlets that you can sort or filter any way you want:

For those of you that use the Oracle DB in your portal stack (or for pretty much anything), you know what an atrocity Oracle’s SQL*Plus is (it’s more dated than Plumtree / ALUI!).  I’ve looked on and off over the years for a simple Oracle client that works as well as Microsoft’s SQL Server Management Studio, and I want to thank Hani Atalla for turning me on to this one: Benthic Software’s Golden.  It’s hyper-simple to use, and even has all the “creature comforts” like being able to copy a result set into an Excel Spreadsheet (try doing THAT with SQL*Plus!).  It does require Oracle’s Instant Client to work, but even I (as a non-Oracle DBA) was able to install both in a matter of minutes.

If you’ve sweated through SQL*Plus sessions for way too long, definitely check this tool out – it’s cheap, at only $40.  If you’ve got a better tool for quick and easy Oracle DB queries, I’d love to hear about it in the comments!

Look, I’ll make this quick and profess my ignorance:  I’m not really sure what the whole “Key Service” thing is in WebCenter Analytics; it’s obviously a security token that needs to be set in multiple places (the Configuration Manager and Java Keystore) to work properly.  A little while ago, I had a client accidentally change the value, and Analytics wouldn’t work.  The keystore passphrase no doubt exists somewhere in the Analytics JRE, but I couldn’t find out where to reset it.  So, I couldn’t find out where to change it in the JRE, and didn’t know what it was suppose to be, so Analytics was DOA.

I got lucky on this one, and hopefully if you found this post through a Google Search, you’ll have saved yourself the headache of trying to figure out what value should be in there.  The answer is in the Analytics Configuration Worksheet (PDF link):

That’s right: it’s “saml2keystore“.  Anyone know how to reset the actual value in Java’s Keystore for Analytics?

Government work can be a challenge with all the rules, regulations, and procedures that come with it.  But there’s one thing I have to continually remind myself when dealing with that “way too much paperwork” thing: whether I’m administering a government web site, ALUI portal, or any other web application is that security can and MUST be taken seriously at all times. 

So, consider this a friendly reminder – especially if you’re exposing your portal on the Internet: stay vigalent, and take all threats seriously.  About 18 months ago, I got an alert in the middle of the night that we were out of drive space on a portal server at one of my semi-government clients.  No big deal; it happens all the time.  Only this time it was different.  Overnight, our logs had exploded from roughly 20MB/day to 2GB/day:  something was seriously wrong.  The logs were so big they were hard to even open, but when i did finally crack them open, here’s a snippet of what I found:

Basically, there were GIGABYTES of these requests – someone was scanning our servers, alternating in different object IDs for different spaces, looking for incorrectly secured communities or other portal objects.  They were basically just scanning different activity spaces, making all kinds of semi-random requests with different IDs a couple times a second.

It turned out that these particular baddies weren’t that sophisticated: they were making no effort to conceal their source IPs through some sort of distributed attack, and their algorithm clearly didn’t demonstrate a deep knowledge of how portal URLs are constructed.  And honestly, we were lucky for even finding this attack in the first place because at the time we didn’t regularly audit the logs, and only caught it because of that benign disk space warning.

In the end, we blocked the entire subnet (from China, a notorious hacker hangout), and the attacks stopped.  We should have reported the attempted breach, and I certainly would if it happened again, but I’m sharing this story with a single moral: no matter how “little” you think your site may be or how you think “noone cares about my little corner of the internet”, the bad guys are out there, and they don’t discriminate when they’re looking for victims.

So, take a minute today to check your security settings one more time, and keep an eye on those log files for anything suspicious!

The Plumtree Server stack has had a long history, forming a decent patchwork of usable applications, but never quite getting to the point where every part of the stack is consistently configured.  When it became ALUI (AquaLogic User Interaction), there was a movement towards putting configuration settings in one place – the Configuration Manager – but unfortunately now that Oracle is holding the reins and the future of the stack is in question, it looks like we’ll never have that utopian vision of single, centralized way of configuring all applications the same way.

Case in point:  configuring the memory parameters for Collaboration Server.  While Publisher utilizes a config file for memory settings, Collaboration Server passes memory parameters via the service startup path.  So, if you’ve got a decently large Collaboration install, you might find that you’re running relatively low on memory:

To up the amount of RAM available to Collaboration Server, you need to edit the registry (and yeah, back it up first!).  The key you need to change is in HKLM\ SYSTEM\ CurrentControlSet\ Services\ ptcollaborationserver, and it’s called “ImagePath”:

Change the “-Xmx” value to something larger, restart Collab, and you’ll have more RAM breathing room:

Many of you have developed WebCenter Interaction portlets (and ALUI before that, and Plumtree before that), and you likely know the difference between the WebCenter Interaction Development Kit (IDK) and the Portal Server API. The difference is pretty straightforward: the IDK provides a relatively simple way to get started and provides Portal Remote Calls (PRC) to manipulate various objects. But it’s not all that powerful, and there are a LOT of things you simply can’t do with the PRC. That’s where the Server API comes in: it can pretty much do anything the portal itself can, but it is significantly more involved to setup. This has to do with how they both work:

• The IDK / PRC makes remote SOAP calls to the WS API server in the portal stack. The WS API server (and, in some cases, Collaboration Server or Publisher Server) are the services that actually do the heavy lifting, like manipulating the database.
• The API, on the other hand, is essentially a fully working portal loaded using either .jars (Java) or .DLLs (.NET), so it has full access to do anything the portal can, but also needs all the portal configuration files and secondary libraries (such as for the search server) installed on the machine.

The easiest way to use the API on a remote server is to install a portal component such as the portal itself, or Automation Server. But in some cases, this isn’t desirable; you just want your application running on the remote tier without actually installing the portal. In this case, you will need to do a pseudo-install by copying all the correct files to your portlet server, updating the configuration properly, and setting various environment variables so the portal code can find the files it needs. I should also point out that there is no harm in using Java files on the remote tier even if you’re using a .NET portal; the code is the same, and fundamentally serves the same purpose – handling updates to the database.

So, here’s a quick guide on how to set up a portlet on a remote server that doesn’t have the portal installed:

1. Make sure your application has the same .jar files (or .dlls, if it’s a .NET app) as the portal is using in your environment: you want to make sure that your remote libraries are exactly the same as the portal libraries so they do the same thing when run.
2. Copy the ptportal, settings, and common directories from %PT_HOME% on one of your portal servers to a folder on your remote server – in my case, I’m using C:\integryst\, so you should have the following subfolders:
   1. c:\integryst\ptportal
   2. c:\integryst\settings
   3. c:\integryst\common
3. Update c:\integryst\settings\configuration.xml: replace all instances of c:\bea\alui\ptportal\10.3.0\webapp with c:\integryst (or whatever source/destination folders you’re using). Also, replace the original machine name with the remote server’s machine name.
4. Set the following environment variables:
   1. ICU_PATH=C:\integryst\common\icu\2.6\bin\native
   2. INXIGHT_PATH=C:\integryst\common\inxight\3.7.7\bin\native
   3. OUTSIDEIN_PATH=C:\integryst\common\outsidein\8.1.9\bin\native
   4. PORTALLIB_PATH=C:\integryst\ptportal\10.3.0\bin\native
   5. PORTAL_HOME=C:\integryst\ptportal\10.3.0
   6. PTHREADS_PATH=C:\integryst\common\pthreads\2002.11.04\bin\native
   7. PT_HOME=C:\integryst
   8. PATH= C:\integryst\ptportal\10.3.0\bin\native; C:\integryst\common\pthreads\2002.11.04\bin\native; C:\integryst\common\outsidein\8.1.9\bin\native; C:\integryst\common\inxight\3.7.7\bin\native; C:\integryst\common\icu\2.6\bin\native;

… and that should do it! Now, when you run your application, if you have PTSpy installed (or even if you don’t), you should see messages in there when the app starts up that look just like the portal startup messages, because that’s essentially what you’re doing in your code – loading the entire portal and leveraging any APIs that are available to the portal itself!

The back story

I recently had the misfortune of being the victim of theft. As a frequent traveller, I keep many of my most important items (technology, travel documents, iPhone charger, breath mints) close at hand in a single bag. At a moments notice I can be out the door and on a plane to help my favorite portal customer. This particular theft reminded me that no matter how much I back up important documents, it doesn’t stop someone from stealing the physical backup media.

Years of experience (i.e. viruses, windows crashes, drive failures, drink spilling, and fumbles) have taught me to always backup. I carry an external harddrive along with my laptop that has a backup of my most important personal and professional documents. For the critical items, I also have a solid state media (flash drive) just to be sure. To make travel easier, I usually have said backup devices parked right alongside my laptop for easy access.

GASP!!! You could hear a pin-drop when I realized someone had decided my bag was much better looking in his/her possession. My immediate disgust wasn’t because of the $2,000+ worth of electronics I would have to replace, but the information on those devices. Countless hours of design, development, and documentation work were suddenly gone.

A Public Service Announcement from your friendly Function1 Consultants

As good netizens, we decided to offer some alternative solutions to this problem in the hopes that our beloved clients don’t have to feel the sting of regret.

Prey: They can run but they can’t hide

I was amazed by how little the police could do to retrieve my laptop and web stats like “97% of stolen laptops are never recovered” doesn’t make me feel any better. Prey is an open source initiative that installs a small application on your laptop. You activate the application via a web interface if your laptop happens to go missing. Once activated, Prey will send you screenshots, IP information, and (if you have a webcam) a picture of the user. If the laptop has wifi in use, Prey will also try to geo-locate your laptop by triangulating wifi access points. Best of all, its FREE!

http://preyproject.com/

Backup: You can’t steal the Internet

As high-speed internet and cloud computing have grown, online backup has become a realistic solution for joe consumer (i.e. me). I found a ton of information on solutions to online backup, but as a tech geek I wanted the coolest of the cool (and cheap too).

It took me a while to find an online backup solution that could meet all my needs as a tech-geek, gadgeteer, and professional IT type. I wanted sync tools, “set-and-forget”, lots of gigabytes, and maybe a cool iPhone app. Sugar sync covers virtually all of the features I could cook up in a backup solution, then throws in some neat utilities. The interface is extremely straight forward and I was up and running within a couple of minutes. Compared to other backup solutions, sugarsync wasn’t the lowest price per gb; but it has by far the most features.

Pro’s:

• Choose any folder on your PC to sync with the “cloud”
• Sync the same files with up to 5 different computers.
• Real-time sync when you’re online
• Version history
• File resume, so you don’t have to wait for a sync to finish before powering down.
• Online edit mode lets you edit from your personal sugarsync website
• iPhone app gives you access to your files anywhere
• 256bit encryption

Con’s

• Not the cheapest per gigabyte of storage. Microsoft Skydrive at $0 for 25gb was the largest free storage solution. Carbonite was a close second at around $55 for unlimited space.
• Cannot sync with a local external harddrive. I was hoping I could sync my files with the “cloud” and also update a local copy for backup.

http://www.sugarsync.com

(I also checked out Microsoft Skydrive, Dropbox,  Mozy, Box.Net, and Carbonite before deciding where to drop my $$$. Each had its short-comings and benefits.)

There are a lot of things I WISH I had done, so I hope my experience prompts our clients to keep all that hard work and sensitive information within reach no matter the circumstances.

After upgrading from ALUI 6.1 to WCI 10gR3, all of our portlets looked … wrong.  The background color had reverted the blue, and they were cutting off on the right side so you couldn’t see the toolbar buttons.  Strangely, this was only happening in IE, so we weren’t able to use Firefox’s FireBug.  Fortunately, there’s a similar type of tool offered by IEInspector Software called IE Web Developer 2.

Similar to FireBug, it offers basic HTTP tracing, JavaScript debugging, and, in this case, DOM/CSS analysis.  This allows you to higlight an item on the page – in this case, a portlet – and view all the styles applied to that item.  it also shows you where the style definitions are coming from:

Using it, we were able to determine that the CSS files had changed, and there was an addition of “table-layout:fixed’ and a ’background-color’ definition in the CSS definitions for the column layouts.  Removing these definitions from the CSS restored the look and feel back to the way we had prior to the upgrade.

How did we update the hundreds of CSS files we had?  Well, that’s a post for another day…

.layoutOneColumn { /* table-layout: fixed; */ }
.layoutOneColumn .columnOne { width: 100%; }
.layoutTwoColumnNarrowWide { /* table-layout: fixed; */ }
.layoutTwoColumnNarrowWide .columnOne { width: auto; }
.layoutTwoColumnNarrowWide .columnOne .portletBody { /* background-color: #fff */ }
.layoutTwoColumnNarrowWide .columnTwo .portletBody { /* background-color: #FFFFFF; */ }
.layoutTwoColumnWideNarrow { /* table-layout: fixed; */ }
.layoutTwoColumnWideNarrow .columnOne .portletBody { /* background-color: #FFFFFF; */ }
.layoutTwoColumnWideNarrow .columnTwo { width: auto; }
.layoutTwoColumnWideNarrow .columnTwo .portletBody { /* background-color: #fff */ }
.layoutThreeColumn { /* table-layout: fixed; */}
.layoutThreeColumn .columnOne { width: auto; }
.layoutThreeColumn .columnOne .portletBody { /* background-color: #fff */ }
.layoutThreeColumn .columnTwo .portletBody { /* background-color: #FFFFFF; */ }
.layoutThreeColumn .columnThree { width: auto; }
.layoutThreeColumn .columnThree .portletBody { /* background-color: #fff */ }

What does a web proxy server placed in front of the Portal give you, in terms of security (or anything else), when there is already an SSL Accelerator (F5 BigIP) managing the portal? The end user would still access the Portal on port 80.  Either way.  What does the extra server buy you?

In hopes a larger audience might find my answer useful, here you go. First though, I'll try the "picture is worth a thousand words" approach, using a slide from a presentation I did a couple years ago:

*sigh*.  You’ve upgraded from ALUI to WCI 10gR3, and your Knowledge Directory links got all screwed up, didn’t they?  HTML files now throw an open/save dialog, some documents don’t open, you can’t copy links by just right-clicking them and choosing “Copy Shortcut”, and IE throws a popup blocker when you click a link in the Knowledge Directory, doesn’t it? 

You got the “To help protect your security, Internet Explorer blocked this site from downloading files to your computer” blues, huh?

I’ve tried creating a Plumtree Filter, and that worked pretty well, but not quite enough.

I’ve tried tweaking the Portal’s Javascript files, and THAT worked pretty well, but again, not quite well enough.

So, today, my friend’s, third time’s a charm:  rather than trying to fix this on the server side, we’re going to knock out this issue once and for all on the client side.  Check out those previous blog entries for a more detailed description of the problem, but basically, it’s because the portal uses a crazy convoluted way of opening documents via javascript. 

What we’re going to do today is stick some javascript in the footer of the page.  This JavaScript is going to simply find all those back-asswards links and replace them with NORMAL <a href=xxx target=_new> links.  If you add it to the footer of your site (specifically, the footer used for the KD, but the code is smart enough not to do anything if it’s on all pages), it should be able to take care of the rest.  Just make sure you add it to the Presentation Template and not the Content Item, because you-know-who only knows what a mess the out-of-the-box rich text editor is with javascript and adaptive tags.

The code after the break should be self-explanatory, but as always, if you’ve got a question or comment, feel free to post it here.  Also note that this code only fixes the download links; it doesn’t kill that “Open/Save” dialog box for things like HTML files.  For that you’ll still need the Plumtree Filter.

<pt:common.transformer pt:fixurl="off" xmlns:pt='http://www.plumtree.com/xmlschemas/ptui/'/>
<script>
try
{
       // only run in the KD
       if (document.title=="Directory")
       {
              // get all links
              var anchors = document.links;
              for (x=0; x<anchors.length; x++) {

                     // get only those with an onclick event
                     onclickJS = anchors[x].onclick;
                     if (onclickJS != null)
                     {
                           onclickJS = "" + onclickJS;
                           var locCommonOpener = onclickJS.indexOf("PTCommonOpener.openInNewWindow");
                           var locpos = onclickJS.indexOf("currentWin.location");

                           // only process links that have the broken PTCommonOpener.openInNewWindow
                           if ((locpos>=0) &amp; &amp; (locCommonOpener>=0))
                           {
                                  // extract the URL from the broken onclick function
                                  var url = onclickJS.substr(locpos);
                                  var locstart = url.indexOf("'");
                                  if (locstart>=0)
                                  {
                                         url = url.substr(locstart+1);
                                         var locend = url.indexOf("'");
                                         if (locend>=0)
                                         {
                                                // update the URL by clearing the onclick and setting the URL to open in a new window
                                                url = url.substring(0,locend);
                                                anchors[x].href=url;
                                                anchors[x].target="_new";
                                                anchors[x].onclick=null;
                                         }
                                  }
                           }
                     }
              }
       }
}
catch (err)
{
       // ignore errors
}
</script>

Analytics 10.3.0.1 straddles this weird middle ground between being a patch and a full release (you download it from edelivery.oracle.com, not like a typical patch from support.oracle.com).

In the release notes, it looks like kind of a pain to install, since there’s mention of having to install other software before you can install Analytics:

• Oracle WebCenter Analytics leverages Hibernate 3.0.5 for persistence. You must install Hibernate 3.0.5 before you install Oracle WebCenter Analytics. Hibernate 3.0.5 can be downloaded from http://sourceforge.net/project/showfiles.php?group_id=40712&package_id=127784.
• Oracle WebCenter Analytics leverages Cewolf 0.10.3 for its charting engine. You must install Cewolf 0.10.3 before you install Oracle WebCenter Analytics. Cewolf can be downloaded from http://sourceforge.net/projects/cewolf/files/cewolf/cewolf-0.10.3/cewolf-0.10.3.zip/download.

And, given that the versions provided are significantly further back than what’s currently available (as of this writing, Hibernate is now at version 3.5.2 and Cewolf is now at 1.0), you might be inclined to hold off on the upgrade until the next release – I know I was initially.

The good news is that now that I’ve actually been through this upgrade, it turns out that it’s not as hard as it sounds.  Contrary to the release notes, you don’t need to “install [the apps] before you install Oracle WebCenter Analytics”.  You just need to download the zips, run the installer, and point the installer at wherever you’ve saved those files.  Pretty straightforward, actually…

This is annoying, right? 

Ah, we’ve all seen that wacky IE warning: “This website wants to run the following add-on: ‘MSXML 5.0 from ‘Microsoft Corporation’…”  Sure you could just accept it and move on, like we’ve been doing for years:

… but your users were trained better than that, right?  They know not to accept an add-on unless they know what it does.  And, well, since even I have no idea what this does, let’s take a look at how to just get rid of this message.  I found this little gem of a fix in Oracle’s Support Center; apparently this has been a bug since Jan 2007: 

On the portal-side, workaround this problem by editing the following two files:
\imageserver\plumtree\common\private\js\jsxml\217438\\PTXML.js
\imageserver\plumtree\common\private\js\jsxml\latest\PTXML.js
I tried this out, and it seems to work well – no more annoying security warnings!  I will mention that I only had to edit one file (the LATEST\PTXML.js) in three places, not two.  And, of course, this is an IMAGESERVER file, so there is no need to restart the portal for this to take effect! 

1. Search for “MSXML” in these files.
2. Comment out or delete all references to ‘MSXML 4.0′ and ‘MSXML 5.0′ found in XML version arrays.
3. After removing those references, only MSXML 3.0, MSXML 2.6 and the default should be listed.
4. Parser arrays are present in three places in the file.
5. Restart the WCI portal for the changes to take effect.

In three places in that file, you’ll find arrays defined like this; just comment out the 5.0 and 4.0 lines: 

var transportTypes = new Array(
//  'Msxml2.XMLHTTP.5.0',
//  'Msxml2.XMLHTTP.4.0',
  'MSXML2.XMLHTTP.3.0',
  'MSXML2.XMLHTTP',
  'Microsoft.XMLHTTP'
 );�

When configuring a WebCenter Interaction portal, it’s highly recommended to use host files on your machines to provide aliases for the various services.

For example, instead of referencing Publisher’s Remote Server as http://PORTALPROD6.site.org:7087/ptcs/, create a host file in C:\Windows\System32\drivers\etc\hosts, and add a line like this:
wci-publisher 10.5.38.12 #IP Address for Publisher in this environment
… then set your Remote Server to http://wci-publisher:7087/ptcs/.

I’m always surprised how many times the knee-jerk reaction to this suggestion is that this is a poor “hack”, or something worse like this:
“Host files??? Host files on local servers need to be avoid and you should use DNS in AD for the Portal servers. Host files, again, are an antiquated and unmanageable configuration in this day and age and, in my opinion, should only be used when testing configurations—not for Production systems. I haven’t seen host files used locally on servers in a decade…is that how you are configuring this portal system? If so, I would highly recommend you try to use the AD DNS instead.”

Yes, that’s an actual response from an IT guy who prefers telling others what idiots they are rather than actually listening to WHY this approach is being used.  In all fairness, most knee-jerk reactions are based in the reality that host files are more difficult to maintain on many servers rather than DNS entries on a single server.  But hopefully, if you’re reading this blog, you’ve got an open mind, and will agree with this approach once you see the list of benefits below.

Benefits of using host files in your portal environments:

1. Security.  When you access a service through the portal’s gateway, the name of the remote server shows up in the URL: http://www.integryst.com/site/integryst.i/gateway/ PTARGS_0_200_316_204_208_43/ http%3B/wci-pubedit%3B8463/publishereditor/ action?action=getHeader.  For most people, this isn’t a huge problem, but allowing the name of the servers to be published in this way can be perceived as a security risk.  By using host files, you’re essentially creating an alias that hides the actual name of the server.
2. Service Mobility.  Take the NT Crawler Web Service, for example.  When you crawl documents into the portal, the name of the server is included in the document open URL.  Now suppose the NTCWS is giving you all sorts of grief and you decide to move it to another server.  If you use host files, you can just install the NTCWS somewhere else and change the IP address that the wci-ntcws alias points to.  This way, the portal has no idea the service is being provided by another physical system  If you used a machine name, all documents would get crawled in as new the next time you ran the crawler, because the card locations will have changed.
3. Maintainability.  This one’s a pretty weak argument, but is based on the fact that most of the time, the Portal Admin team doesn’t have access to create DNS entries and has to submit service requests to get that done.  By bringing “DNS-type services” into host files, the portal team can more easily maintain the environment by shifting around services without having to submit “all that paperwork” for a DNS entry (your mileage may vary with this argument).
4. Environment Migration.  Here’s the clincher!  Most of us have a production and a development environment, and occasionally a test environment as well.  Normally, code is developed in dev and pushed to test, then to prod, but content is created in prod, and periodically migrated back to test and dev, so those environments are reasonably in synch for testing.  This content migration is typically done by back-filling the entire production database (and migrating files in the document repository, etc.).  The problem is, all kinds of URLs (Remote Servers, Search, Automation server names, etc.) are stored in this database, so if you’re using server names in these URLs, your dev/test environments will now have Remote Servers that point to the production machines, and you need to go through and update all of these URLs to get your dev environment working again!  If, however, you use host files, then you can skip this painful step:  your Publisher server URL (http://wci-publisher:7087/ptcs/) can be the same in both environments, but the host files in dev point to different machines than the ones in production.  Cool, huh?
5. Disaster Recovery.  This is essentially the same as the “Environment Migration” benefit:  When you have a replicated off-site Disaster Recovery environment, by definition your two databases are kept in synch in real-time (or possibly on a daily schedule of some sort).  If a disaster occurs and you lose your primary environment, you’re going to want that DR site up as soon as possible, and not have to go through changing all those URLs to get the new environment running with new machine names.  Of course, unlike “Environment Migration” (where your dev, test, and prod environments typically share the same DNS server), this argument is also slightly weaker.  Since the DR site will likely have its own DNS server, you could conceivably just use different DNS entries at the two different sites and all will work fine.

So that’s it – hopefully you’re convinced that host files are the way to go for configuring ALUI / WCI portals; if so, stay tuned for helpful tips on how to set this up for various servers.  While Remote Servers are a no-brainer, configuring things like Automation Server and Search can be a little trickier.

Checking the Error Message in the stdout, you'll see something like below:

root@lucid:/opt/Oracle/Middleware/utils/bsu# ./bsu.sh
javax.xml.rpc.ServiceException: Error processing WSDL document:
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: algorithm check failed: MD2withRSA is disabled
at org.apache.axis.client.Service.initService(Service.java:250)
at org.apache.axis.client.Service.(Service.java:165)
at org.apache.axis.client.ServiceFactory.createService(ServiceFactory.java:198)
at com.bea.plateng.patch.AbstractPatchServicesImpl.init(AbstractPatchServicesImpl.java:90)
at com.bea.plateng.patch.DefaultPatchProducerServicesImpl.(DefaultPatchProducerServicesImpl.java:8)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at com.bea.plateng.patch.PatchServicesFactory.create(PatchServicesFactory.java:180)
at com.bea.plateng.patch.PatchLoginManager.login(PatchLoginManager.java:90)
at com.bea.plateng.patch.gui.PatchGUIHelper$1.call(PatchGUIHelper.java:192)
at com.bea.plateng.patch.gui.PatchGUIHelper$1.call(PatchGUIHelper.java:189)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:98)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:207)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)

Cause

Aha, we caught the fish: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: algorithm check failed: MD2withRSA is disabled

There were some unknown changes in Sun JDK 1.6.0 update 20, old certificate paths are not recognized for some reason.

Workaround

Use JRockit as the JVM instead. Suppose JRockit is installed in /opt/jrmc-4.0.0-1.6.0

1. Session Wide (temporary)

Open a terminal, set session wide environment variables:

export JAVA_HOME=/opt/jrmc-4.0.0-1.6.0/jre
export CLASSPATH=.
export PATH=$JAVA_HOME/bin:$PATH

run ./bsu.sh from this Termial

java -jar patch-client.jar

2. Permanent workaround

edit utils/bsu.sh

update JAVA_HOME

JAVA_HOME="/opt/jrmc-4.0.0-1.6.0/jre"

Run

./bsu.sh

Reference:

http://forums.oracle.com/forums/thread.jspa?threadID=1066924

Let’s face it: sometimes even the simplest actions in the portal can take WAY too many clicks.  Take creating a single community:  you need to pick a community template, create pages, create Publisher portlets and add them to the pages, create Collab Projects, set security, etc.  And many times, most of this information is the same for every new community.  Community Templates help, but it still requires a LOT of clicks.

Integryst’s Automater product tackles this problem by allowing you to script multiple portal actions, only prompting for the unique information each time.  For example, at one client they wanted to create a “Network”, which consists of 7 communities, dozens of portlets, and multiple admin and regular users.  It literally would take over 100 clicks each time – and eventually there are going to be 100+ of these “networks”.  Tha’ts a lot of clicks!

Not using Automater, though.   Administrators just enter the information that’s unique to each network, and those 100 clicks are rolled into one:

All kinds of actions can be scripted – and secured so that only certain groups have access to specific actions:

Automater works off of XML files that define each “Action” (shown in the screen shot above), and any number of “steps” within that action.  The “Create Network” action, for example, has 44 distinct steps that do everything from creating Collab Projects to Publisher Content Items to Users, then setting security for each appropriately based on the user list provided.

Want to see a demo?  Drop me a line!

Don’t

As you likely know, PTSpy messages are UDP messages generated by all services in the WebCenter stack. PTSpy / WebCenter Logging Utility is just a receiver for these messages.  Things can go wrong some times, though: UDP is not a guaranteed message protocol, and log events may be lost.  But more importantly, occasionally these applications don’t report themselves properly, and as a consequence, PTSpy doesn’t display them in the filter list.

What I didn’t know until recently is that just because an application doesn’t show up in the message sender list doesn’t mean the application isn’t generating messages.  Typing the name of the sender into the text field sometimes works too.  Take this example; I was trying to diagnose a problem with the Portal Notification Service, but the CNS didn’t show up in the list of message senders:

In the CNS log, I found this line:

INFO   | jvm 1    | 2010/05/09 19:35:26 | Using OpenLog Application Name ‘cns.NRC372DR.plumtree’ for CNS SPY logging

So on a whim, I tried just typing that string into the “Message Sender” field.  That couldn’t possibly work, could it?  I mean, if PTSpy doesn’t detect the Sender, it won’t capture messages being generated by it, right?

Glad I was wrong on that one:

WebCenter Analytics 10.3.0 has a feature to “Select All/Top/Bottom Options” when you edit various roles.  In theory, this is a nice feature because it allows you to select, well, “all”, “top” or “bottom” of different kinds of lists.  In practice, it’s tragically broken, and you’ll have absolutely no idea why if you look at the logs without upping the logging threshold to debug.  In fact, even once you turn on debugging in the logs, you’re still not in much better shape.

The Symptom: Filters don’t work when the “Select All/Top/Bottom Options” option is turned on for a Role in Analytics Administration.

The Solution: Turn off the “Select All/Top/Bottom Options” for the various roles within Analytics (under “Select Utility: Analytics Administration”), and restart the Analytics UI service.

The Use Case:

I have “Select All/Top/Bottom Options” turned on.  My UI for the “Page Traffic Report Preferences” seems decent enough – I’ve got a drop-down showing different types of pages and an option to filter on certain communities.  Here I’ve picked all pages, and chosen only TWO communities from the list:

… but when I view the Page Traffic Report on my community, in the report I see every single page in the entire portal – no filter applied:

Diagnostic Steps:

After figuring out how to get Analytics to log debug messages, I fortunately had access to one portal that had a working filter and one that didn’t.  So I found some “PREFERENCES” text in the logs, and used (you guessed it!) Beyond Compare again to diff the two different portlet prefs:

That “targetOption” preference looked suspicious, so I did some decompiling to figure out what they meant.  I found this in com.plumtree.analytics.core.preference.Preferences.java:

public boolean isTargetAll() {
  return (getTargetOption() == 3);
}
public boolean isTargetList() {
  return (getTargetOption() == 4);
}

So, realizing that the drop-downs looked different under the “Display” section in the portal that had working filters – it showed “Specify Communities” instead of the “Top/Bottom” items -  I was able to figure out that the “broken” portal was using the “All Pages” setting and was completely ignoring the “targetListValue” preference:

The Fix:

I don’t have one, aside from turning off that option in Analytics Administration.  But Oracle should fix this by either COMBINING the “display” with the “filter” (so that, for example, users can choose the top 5 pages in a particular community or set of communities), or making it clear that they’re EXCLUSIVE (by adding “Select Communities” to the “Display” dropdown so users can either choose a “top” or “bottom” option, or “Specify Communities” in that dropdown.  Bonus points if the “Select Communities” option gets greyed out to indicate it’s not actually doing anything if a user doesn’t choose “Specify Communities”).

Ah, Plumtree Publisher.  We had a good run; I’ve loved you, I’ve hated you.  I’ve even tried to throw you a bone by developing a better editor to replace your terrible WYSIWYG editor in AquaLogic Publisher 6.5, and a utility to replacing glaringly absent features. But I mean, c’mon, it’s like you don’t even try any more.

If you, dear reader, have written similar missives to the oft-maligned Publisher editor, this tip is for you.  Specifically, if you’re getting JavaScript errors in various Publisher administrative pages and it seems hopelessly broken, chances are the problems are with the new jSpell spellchecker (you’ll see file names like jspellSettings_UTF-8.js in the IE error window):

This problem typically occurs when you have multiple experience definitions and are accessing your WebCenter portal with different base URLs.  The reason is that Publisher creates absolute URLs to the spell checker JavaScript files, and the portal’s link transformation seems to be broken by creating the wrong base URLs for the gateway (more on this another time; I can only rant about one thing at a time…).  Consequently, Internet Explorer refuses to run the Javascript when it’s being executed from a different base URL.

It appears (although I haven’t done extensive testing) that if you have explicit mapping URLs for each distinct experience definition, the portal gateway works OK and picks the correct base URL.  But, if you just use wildcards in your mapping URLs, things get hairy, the gateway chokes, and the browser gets the wrong base URL for the gateway link.

What to do?  Remove the absolute URL in Publisher and provide the portal with a relative one.  I would say “proceed at your own risk” with this fix because I imagine this absolute link code is there for a reason, but we all read The Daily WTF, right?  Sometimes there just is no rhyme nor reason why crazy code exists.  (I’ll update this post if I find one).

The fix: Edit the following four files in the /ptcs/6.5/webapp/ptsc.war file:

1. /portlet_packages/community_portlet.jsp
2. /portlet_packages/portlet.jsp
3. ciEditor.jsp
4. ci_editor_jr.jsp

Find the lines that look like this:

<script language=”JavaScript” TYPE=”text/javascript” src=”<%=sURLGatewayBase%>/jspellEvolution/jspellEvolution_UTF-8.js” CHARSET=”UTF-8″></script>
<script language=”JavaScript” TYPE=”text/javascript” src=”<%=sURLGatewayBase%>/jspellEvolution/jspellSettings_UTF-8.js” CHARSET=”UTF-8″></script>
<script language=”JavaScript” TYPE=”text/javascript” src=”<%=sURLGatewayBase%>/jspellEvolution/jspellClient_UTF-8.js” CHARSET=”UTF-8″></script>

… and change them to this:

<script language=”JavaScript” TYPE=”text/javascript” src=”/jspellEvolution/jspellEvolution_UTF-8.js” CHARSET=”UTF-8″></script>
<script language=”JavaScript” TYPE=”text/javascript” src=”/jspellEvolution/jspellSettings_UTF-8.js” CHARSET=”UTF-8″></script>
<script language=”JavaScript” TYPE=”text/javascript” src=”/jspellEvolution/jspellClient_UTF-8.js” CHARSET=”UTF-8″></script>

So yeah, sorry Publisher; it’s not really yoru fault that you’re providing an absolute link instead of a relative link to these JS files – they point to the same files.  I might have done the same thing if i were you.  But, uh, Mr. Portal Link Transformation Engine, I’m eyein’ you for this one…