Posts Tagged ‘IDK’

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.

Bug Blog 8: WebCenter Friendly URLs break Plumtree Excel Portlets

Monday, September 20th, 2010

I’ve been a pretty big fan of Friendly URLs in WebCenter Interaction ever since it was AquaLogic User Interaction 6.5.  But the Law of Unintended Consequences has a way of striking in unique ways.  In today’s post, the bug is that Friendly URLs cause problems with the old Plumtree Excel Portlets.  Basically, if you have an Excel portlet on any page other than the home page in a community, pagination breaks because the browser bounces back to the home page in the community when you click any links.

This seems to have to do with the way the return URI is sent to the remote tier, and how the GDK interprets the URL, interacting with the fact that there are no longer query strings in the source URL (that’s right – this ancient Plumtree code uses ASP / VB and the long-dead Gadget Development Kit).  I won’t bore you with all the analysis that went into this, but the code fix is pretty straightforward.

If you’re still using Excel portlets in WCI 10gR3, you need to make the following fix in C:\ Program Files\ plumtree\ Excel Portlet Framework\ gadget\ setGadgetDisplay.asp.  Change:

Call Response.Redirect(strReturnURI & "#" & strID)

…to this:

'11/3/2009 mchiste: because the 10gR3/gdk/friendly urls screw up the strReturnURI, we use this URL instead to go back to the page we were just on
Dim strReturnURI2
strReturnURI2 = Request.ServerVariables("HTTP_REFERER")
If (strReturnURI2 = Null) Then
Call Response.Redirect(strReturnURI & "#" & strID)
If InStr(1,strReturnURI2, "#") <> 0 Then
strReturnURI2 = Mid(strReturnURI2,1,InStr(1,strReturnURI2, "#")-1)
End If
Call Response.Redirect(strReturnURI2 & "#" & strID)
End If

The code change basically tells the browser to return to the page it came from, rather than “trusting” the portal/gdk.

RTFM: Microsoft.Web.WebServices2 in ALUI IDK

Wednesday, March 31st, 2010

Psst.  You.  Yeah, you.  I’ve got a tip for you: Read the friggin’ manual

OK, maybe that should read: “Psst.  Me.  Yeah, Me.  Read the friggin’ manual”.  Because I’m terrible with this: I’ve probably installed or upgraded Plumtree Foundation, Aqualogic User Interaction, and WebCenter Interaction (and the ancillary apps) hundreds of times: I don’t need no steenkin’ manual.  But every now and then, I miss yet another step.

Take this example I ran into recently:  I was installing LockDown on a client server, and was getting this message:

Could not load file or assembly ‘Microsoft.Web.Services2, Version=, Culture=neutral,PublickKeyToken=31bf3856ad364e35’ or one of its dependencies.  The system cannot find the file specified.

At first, I was really miffed the stupid WebCenter Interaction IDK once again failed me, but if I had just read the friggin’ manual (well, release notes), I’d have found the simple solution and felt a little less foolish when I came across the solution:

General .NET

  • The IDK requires WSE 2.0 SP3. Building against the .NET IDK causes the warning “dependency could not be found,” for the assembly: Microsoft.Web.Services2. As the requirements indicate, this assembly from Microsoft Web Services Enhancements is only needed by PRC Collaboration for Document Upload and the warning can be ignored if this part of the IDK API is unused. (Issue #37773)

Moral of the story:  sometimes it IS actually user error.  So read the manual before whining like myself about something not working out of the box, and install the prerequisites already!

OK, I’d be remiss if I didn’t mention that contrary to the release notes, this component IS required by more than just the “PRC Collaboration for Document Upload”; the above error was thrown when trying to load Publisher Objects.  So, uh, I guess it can’t hurt to always install this tiny, easily installed support app from Microsoft … just in case.