Posts Tagged ‘Analytics’

Analytics – SAML2Keystore value

Saturday, July 17th, 2010

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?

The dependencies of WebCenter Analytics

Wednesday, June 16th, 2010

Analytics straddles this weird middle ground between being a patch and a full release (you download it from, not like a typical patch from

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:

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…

Bug Blog 5: Broken Filters in WebCenter Analytics 10.3.0

Thursday, May 27th, 2010

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:


Logging in WebCenter Analytics with

Wednesday, May 19th, 2010

Stay tuned for a flurry of Analytics posts, boys and girls, because recently I had a really bad day fighting WCI Analytics after a 10gR3 upgrade.  Let’s kick this off with something simple: logging.  Well, you’d THINK logging would be simple, right?  You’d just go into PT_HOME\ptanalytics\10.3.0\settings\config\wrapper.conf, and change some of the settings under “# Wrapper Logging Properties”, and restart the service. 

No, friends, that would be too easy.  This setting only controls the WRAPPER log, which pretty much does nothing but write thousands of messages like this if you turn on DEBUG:

DEBUG  | wrapperp | 2010/04/14 01:12:33 | send a packet PING : ping
INFO   | jvm 1    | 2010/04/14 01:12:33 | Received a packet PING : ping
INFO   | jvm 1    | 2010/04/14 01:12:33 | Send a packet PING : ok
DEBUG  | wrapperp | 2010/04/14 01:12:33 | read a packet PING : ok
DEBUG  | wrapper  | 2010/04/14 01:12:33 | Got ping response from JVM

Instead you have to edit the file.  Another piece of cake, right?  There’s a log4j file in that config folder for hibernate, synch, analytics25Update, and analyticsLoadEvents, so it’s got to be somewhere in there.

No, friends, THAT would be too easy.  Instead, the log4j file you actually need to change to get usable debug messages in analyticsui.log is packaged inside the analytics.war file itself.  There are lot of ways to change and repackage the file into the .war while still preserving the WEB-INF/classes path, but here’s how I did it with my old friend, Beyond Compare.  Basically, I pull the out of the .war, edited it, and use Beyond Compare to jam it back in there:

Bonus tip – if you find Analytics is writing a ton of entries to the application event log, this one IS actually in the wrapper.conf file.  Just set the following to some high threshold like FATAL:

# Log Level for sys/event log output.  (See above for log levels)

Upgrading Analytics 2.5 to 10.3.0 – missing documentation

Tuesday, May 11th, 2010

If someone can find this in the documentation SOMEWHERE, let me know and I’ll update this post.  Until then, consider yourself one of the lucky few who are now aware of a missing step in the 2.5 and 10gR3 WebCenter Analytics Upgrade guides:

Aqualogic Analytics 2.5 QuickStart Guide

WebCenter Analytics 10gR3 Upgrade Guide

The step:  In addition to running the Analytics25Update.bat file with no parameters:


… you need to also run it with a “collab” parameter to properly partition the Collaboration tables:

PT_HOME\ptanalytics\\bin\Analytics25Update.bat collab

Wall of Shame Rant: Oracle Support and Maintenance

Saturday, March 27th, 2010

In my last Wall of Shame rant, I blasted some shady spammer and had no qualms about it.  But this time is different:  I’m writing this post in a sincere effort to get Oracle to look at some of its policies and procedures, specifically around support.  Oracle has some stellar products and decent support, and in defense of Oracle’s support organization, support people have a tireless, thankless job, dealing with irate customers who think that software should never have problems.  So, while occasionally customers have it tough, customer support often has it much tougher (NSFW for a LOT of language; kudos to that Dell support guy for keeping his cool and staying on the line).

Oracle support, I salute you for the tireless, thankless job you have, but please stop telling clients their problems will be fixed with an upgrade when you’re not sure it will, or worse, know that it won’t.  Also, please honor Oracle’s support policy and don’t withold patches until a client gets to the latest version of the software, knowing that by the time they do, another patch release will probably come out, starting the whole cycle all over.  Of course, it’d be different if the upgraded version actually fixed the problem, but in the below rant, my client couldn’t even submit a patch request that affected the 10gR3 version of Analytics because they weren’t on the “latest version”, which was ridiculous because the latest version didn’t fix the problem either.


WebCenter Analytics Status Check

Sunday, January 17th, 2010

We’ve all done countless restarts of the portal stack, and many of us have done countless WebCenter 10gR3 Analytics upgrades.  This one’s a quick and easy tip to ensure that Analytics is actually working after a restart or upgrade.

I used to check if ALUI Analytics was working by simply going to the Analytics Console in the portal and viewing traffic data.  But this is only half the picture: if you’ve just done an upgrade or reboot, getting valid traffic reports only shows you that the Analytics CONSOLE/UI is running.  It doesn’t tell you if the COLLECTOR is running and properly capturing metrics.

Instead, whenever I’m testing whether the full Analytics stack is working, I check the Collector and the UI by simply doing a quick search for a unique term.  For example, I can search for MATTTEST, which is a string I’m reasonably sure noone else has searched for today:

WebCenter Analytics Search

WebCenter Analytics Search

Next, go to the Analytics Console and check to make sure that that search term appears in the list of Phrases by going to the Analytics Console, then “Other Metrics”, then “Search”.  There you can view results for “Today” and make sure that a) your search query was accurately captured by the Analytics Collector, and b) the Analytics Console is properly reporting it:

Analytics Results

Analytics Results