Archive for the ‘Coding Tricks’ Category

Replace Collab’s horribly broken file uploader

Sunday, September 27th, 2015

While the entire WebCenter Interaction stack is now dead, there are still some of you out there using the legacy code because it “just works”.

As technology evolves, though, more and more pieces of the stack have started to crumble – including Collaboration Server’s multi-file upload. We’ve talked about issues with it in the past and hacked it more than once, but it pretty much just worked in IE7-9, and wasn’t even available in other browsers like Chrome.

So, enough was enough: in search of a better solution, I came across the awesome FineUploader product, which does an incredible job of allowing multiple uploads with virtually any browser (degrading properly based on available features of each browser), and doesn’t rely on any crap technology like Flash or Java.

Rather than completely re-inventing the wheel, I just cracked open the collab.war file and replaced the old crap code with new code leveraging; uploads themselves are still processed the exact same way that the old java app used to use, so nothing is compromised in terms of features or security. It was really only a few files that needed to be changed, which alters the upload form that used to look like this:
… to now look like this:

Using Collaboration Server with Internet Explorer 11

Friday, April 3rd, 2015

Webcenter Collaboration 10gR4 was released in May 2013. Internet Explorer 11 was officially released in October/November of that year. Why is this a problem? Because, since Oracle has killed the entire product line, users are left high and dry with compatibility issues, getting a degraded version of Collab Explorer that’s missing key features like Bulk Upload:

Why is this? Because the abomination known as Internet Explorer threw developers yet another curveball in IE11: they changed the user agent string to one that doesn’t contain the characters “MSIE”. Sure, Oracle can be faulted for not following best practices on browser detection, but we’ve thrown enough angst Oracle’s way in this blog; it’s Microsoft’s turn today. I mean, they’ve used MSIE in their user agent strings for literally TWENTY YEARS; of course they should change it now to:

Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; AS; rv:11.0) like Gecko

The solution is yet another Collab Hack requiring you to decompile code. Specifically, in collab-core.jar, we need to update There are two places in the code that need to be updated; you’ll note I didn’t even attempt to implement a generic solution, but am specifically looking for this IE11 user agent string. That, of course, is not completely future-proofed, but since WCI is basically dead, and IE is getting killed off, I’m not too worried. The updated code will look something like this:

    private static float parseVersion(HttpServletRequest request, String searchPattern)
        String userAgent;
        userAgent = request.getHeader("User-Agent");

	if(InStr(request.getHeader("User-Agent"), "rv:11.0"))
		return 11.0F;

… and:

    public static String GetBrowser(HttpServletRequest request)
        if(InStr(request.getHeader("User-Agent"), "MSIE"))
            return "IE";
        else {
	        if(InStr(request.getHeader("User-Agent"), "rv:11.0"))
				return "IE";
	            return "NS";


Server-Side Validation – Deleting Knowledge Directory Cards

Monday, April 29th, 2013

Those of you that are familiar with the WebCenter Interaction Knowledge Directory have likely had a need to delete a batch of cards from a folder. But, if you have a lot of cards and try to delete more than 50 at a time, you’re presented with this little gem:

That’s a Javascript popup that refuses to allow you to delete more than 50 cards at a time – but what if you have 25,000 cards that you need to delete? This scenario presented itself to me recently, and I was definitely not looking forward to the prospect of deleting them 50 at a time – 500 separate deletions, which is more complicated by the fact that the Knowledge Directory shows only 20 cards at a time, so for each deletion you have to change the pagination as well.

Importantly, there is a difference between “client-side validation” and “server-side validation” – doing a check in Javascript to prevent users from doing something is completely different than doing a check on the server side for the same reason. Fortunately for me the original developers neglected to do a server-side check that would prevent the deletion of more than 50 cards. So, using the IE Developer Tools (hitting F12), I was able to add a breakpoint at this Javascript condition, and simply use the “Set next statement” option to get this method to return true:

That way, I could get the browser to submit deletion requests for 1,000 or more objects at a time.

Use this as a reminder as you develop your custom code: always confirm data entry both on the client and server sides if you don’t want users doing things they shouldn’t!

Rebuilding WebCenter Collaboration Index By Project

Thursday, April 4th, 2013

Another tip of the hat to Brian Hak for this pretty awesome Hak (see what I did there?).

Last year, Brian was faced with a problem: Some documents in WebCenter Interaction Collaboration Server weren’t properly indexed, and his only option was the rebuild the ENTIRE index (a pain we’re all pretty familiar with). With many thousands of documents, the job would never finish, and end users would be frustrated with incomplete results while the job toiled away after wiping everything out.

So he took it upon himself to write CollabSearchRebuilder. CollabSearchRebuilder allows you to rebuild specific subsets of documents without having to wipe out the whole index and start all over again.

Feel free to download the source and build files and check it out!

Prevent Session Timeouts

Monday, September 24th, 2012

We ran into a problem recently where one of our web applications, Frevvo, was timing out. Because Frevvo is a form building tool and we were conducting an extensive survey, occasionally users would take longer than the standard 15-minute session timeout interval. Consequently, when they submitted the survey, the web app wasn’t able to to reconcile the browser’s cookie with a server-side session, and the submission failed – resulting in a lost survey response and unhappy users.

One option was to increase the session time-out, but that could have resulted in wasted resources for users who had already closed their browser windows. Instead, we wanted users with their browser windows still open to keep their session indefinitely, while others would safely close and conserve server resources. To accomplish this, we used the following JavaScript to ensure that an HTTP request was generated from the browser to the server every 10 minutes.

The request doesn’t actually do anything, but it allows the application server to keep the session alive while the user fills out the survey. Of course, this type of script could be used for any web application that relies on sessions, and I’ve used similar scripts in the past in the Plumtree portal, where a lost session can also cause problems:

     var sessionInterval = 1000 * 60 *10; // milliseconds to minutes
       var sessionRefreshURL = "/frevvo/web/login";

       refreshFrevvoSession = function() {

              // make the request
              var xmlhttp;
              if (window.XMLHttpRequest)
                     xmlhttp=new XMLHttpRequest();  // IE7+, Firefox, Chrome, Opera, Safari
                     xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");  // code for IE6, IE5
    "GET",sessionRefreshURL+"?sessionRefresh="+new Date().getTime(),true);

              // set the timer to run again
              setTimeout (refreshFrevvoSession, sessionInterval);
       setTimeout (refreshFrevvoSession, sessionInterval); // set the initial timer

Don’t send portlet settings you’re not using

Friday, June 15th, 2012

A question came up recently about WCI Portlet Caching, and I thought I’d share with you a little side effect of the caching strategy for portlets.

As you can see in the documentation, portlet caching is pretty intelligent, and has been since the Plumtree days of the MPPE (Massively Parallel Portal Engine) through the Aqualogic User Interaction days of the PPE/LB (Parallel Portal Engine/Load Balancer). The docs basically say that the cache key is created based on the preferences that you send to a portlet.

Which, if you think about it, is really smart: If you’re not sending the user name to the portlet, then it’s likely that the portlet isn’t returning different content based on the user that’s logged in – and therefore you can have one cache entry for that portlet and all users. On the flip side, if you do have a particular preference or user information being sent, then that portlet is likely going to be returning user-specific content based on who’s viewing the portlet, so separate caches have to be maintained for each user.

In other words: to maximize the effectiveness of your cache by preventing cache-thrashing, don’t just blindly check all the boxes in the Web Service configuration. That way, the cache will be able to maintain as few versions as possible for as many users as possible.

Use Adaptive Tags to alternate row colors

Friday, June 8th, 2012

The ability to alternate row colors exists in the WCI portal style sheets, but it’s not completely obvious how to get nice alternating background colors where you’re rendering a list like search results.

There’s some documentation on how to create an adaptive layout Knowledge Base page that’s unusually comprehensive, and it sheds some light on a little trick: Adaptive Tags can do basic math with pt:logic.intexpr.

So for example, you could work your way through a $result list variable and run a mod operator on the index, which basically allows you to compute the remainder of a division operation. Which means, if you divide by 2 for every integer, the remainder will be zero half of the time and 1 the other half.

Using this nugget of knowledge, we can write code like this to alternately apply a background style color to each row of a table:

<pt:logic.intops pt:expr="($result.rank) % 2" pt:key="remainder" />
<pt:logic.intexpr pt:expr="($remainder) > 0" pt:key="isOdd" />
<pt:logic.if pt:expr="$isOdd">
		<tr height="25" class="listText listItemOneBG">
		<tr height="25" class="listText listItemTwoBG">

Credit to Rick Ptasnik for sharing this code a couple of years ago!

Rest APIs in Oracle WebCenter Interaction

Friday, June 1st, 2012

Here’s something I hadn’t really stumbled across before: Oracle added REST APIs to WebCenter Interaction 10gR3. You can use these APIs to do basic Knowledge Directory manipulation, User management, and Activity Stream updates.

Unfortunately, the documentation is weak, the interfaces aren’t comprehensive, and you’ll get a lot more bang for your development buck by just sticking to the Server APIs, or even the IDK. If you want to hazard a look, though, it seems there’s some Javascript included with the portal in the imageserver that you can check out:

Too little, too late for this I’m afraid. As WCI fades away, it’s clear this mechanism for interacting with portal objects will never reach widespread adoption.

Display an “Unsupported Browser” warning in Confluence 3.4

Wednesday, November 9th, 2011

As we continue to prepare for a Post-WCI world, you’ll see this blog starting to highlight other best-of-breed products and challenges we’ve overcome with them. Today’s post is related to the fact that Atlassian’s Confluence doesn’t support Internet Explorer 9 (in version 3.4), and how we addressed it with our client.

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:


Bug Blog 13: Fix Broken File Downloads in 10gR3 (Part Quatre)

Tuesday, October 25th, 2011

When WebCenter Interaction 10gR3 was released, it was a complete train wreck for documents in the Knowledge Directory – the content headers were wrong, docs wouldn’t download in Internet Explorer due to the comical back-asswards Javascript file open mechanism, and links couldn’t be copied or viewed because the anchor tags were malformed.

In our last post in this painful series, I shared some code that will resolve the ALUI / WCI Knowledge Directory links so that users can right-click and copy the links, and the files open as expected when clicked.

Since then, I’ve found that when an admin is in EDIT mode in the Knowledge Directory, the link calamity continues, and a completely different and incomprehensible linking mechanism is used. So for your reading pleasure today, I’ll update that post to handle edit mode as well as browse mode. Again, just add the following HTML to the footer used in your Knowledge Directory (depending on Experience Definition, there may be more than one):