Archive for the ‘IDK’ Category

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)
Else
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.

Deploying WCI API applications without the portal installed

Monday, July 5th, 2010

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!

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=2.0.3.0, 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.