Function1

Howdy all.  Hope the nice weather is finding happy, healthy, and allergy free. As we were doing spring ALBPM house-keeping with a client the other day, we stumbled upon a bit of a problem with the way that BPM loads some images.  This led us to go digging into how the ALBPM->Portal integration works.  And anytime I get a reason to dig into the guts of software, it usually ends up as a blog post….hope you enjoy.

<context-param>

<param-name>com.bea.opencontrols.IMAGESERVER_URI</param-name>

<param-value>http://your.imageserver.url/bpmContext</param-value>

</context-param>

• You’ll also need to copy the following directory into your bpmContext folder of your imageserver:

$BPM_HOME/enterprise/webapps/workspace/opencontrols/plumtree

• Bounce the BPM workspace after making the changes above and you should see a marked improvement in workspace performance

First, a “Did you Know” on the BPM->Portal integration

• Did you know that the BPM->Portal integration was originally written by Plumtree way back when as a way to bolt Fuego BPM into the Plumtree Portal?  This original codebase is still more or less intact, and is still used for the integration today.
• Did you know that the BPM->Portal integration is built in Java and uses Java Server Faces (JSF)?
• Did you know that the BPM->Portal integration also makes use of the somewhat dated Plumtree  OpenControls libraries?
• Did you know that the code for the standalone BPM web-based client is a lot cleaner than the BPM->Portal integration?
• Did you know that there are servlet filters configured on the BPM Workspace that should do neato stuff like caching and compression auto-magically?  

OK, so the whole “Did you know” thing is a bit of stretch, and really just a vehicle to give you background on the issue we were researching.  So….

The Issue We Were Researching

It turns out that, out of the box, the portlet-based BPM workspace doesn’t handle some images too smartly.  Specifically, on every UI request, there are a bunch of static images that get reloaded all the way from the embedded Tomcat server that runs the BPM workspace.  Now, everybody and their brother knows that it’s just good common sense to cache images, so what gives?  Welp, let’s start at the very beginning and see.  After users reported slow-loading images in the BPM workspace, we used one of the best tools known to mankind to take a look all the HTTP requests being made on page load:

As the lovely highlighting above points out, some images in the workspace are getting loaded from the portal imageserver, and are being appropriately cached in the client browser.  We know they’re being cached by that handy-dandy 304 HTTP status code.  But what’s up with all these requests for images and javascript files with HTTP status code 200 (i.e. going back to the server to successfully load a static file on every page invocation)?  And why do all those URLs end with “WebResource.resource?r=foo”?  Blasphemy!  Time to do some poking around and set things straight.

How we researched the issue

This is the section of the blog post where I take you deep inside the black art of tearing apart a web application and making educated guesses to arrive at a testable hypothesis.  Strap in for a non-stop thrill ride.

Anytime I’m faced with a black box type problem (i.e. there’s something going wrong with a piece of commercial software to which I don’t have the source code), I more or less go through the following checklist:

• Is this something I’ve seen before?
• Is this something that somebody else has seen before?
• Is it going to be more painful to open a support ticket on this than to just figure it out myself?
• What do I know about the inputs and outputs of the black box?
• What do I know about how the application is built?
• How can I tear the application apart to learn something useful?

In this case, we were looking at a problem that we’d never noticed before, nor could we figure out a way to ask the interwebs if anybody else had seen it before.  I was pretty sure that going through the process of working a support ticket was going to be more painful that just fixing the problem (besides, what fun is working with support when you can break into the guts of a system?), so I asked myself, “What do I know about the inputs and outputs of the black box”?

• Input -> HTTP Request to a web page that loads mu
  ltiple static files and some dynamic content
• Desired output -> Cached static content
• Actual output -> Non-cached static content 

Then I thought about what I know about how the application is built:

• Java
• Web application
• JSF

Finally, how can I tear the application apart to learn something useful:

• Look at the inputs (i.e. look at the URLs being requested)
• Look at the web.xml and other configuration files of the application to see how everything is glued together
• Decompile the source to see what the hell is going on

So off we went.  The starting point in our maze was to take a good look at the problem image requests (Warning: I’m going to get all stream of consciousness on you here…welcome to my troubled world)

https://portal.foo.com/gateway_noise/bpm_portlet_server:123/workspace/jsf/menu/WebResource.resource?r=/a/path/to/an/image.gif

bpm_portlet_server:123/workspace/jsf/menu/WebResource?r=/a/path/to/an/image.gif

bpm_portlet_server:123/workspace/jsf/menu/WebResource?r=/a/path/to/an/image.gif

Looks like the name of the web app running on that Tomcat instance is workspace.  Maybe there’s a WAR file or something sitting around that I can play with.  Let me take a look in the Tomcat webapps directory on bpm_portlet_server.  Hmm, nothing here…WTF?  Ah, but I know that this is a special Tomcat server that’s configured all crazy-like because it’s embedded with the ALBPM distro. Let me poke around in the ALBPM directories to see if there’s anything interesting there.  Well how’s about that, there’s a directory at $BPM_HOME/enterprise/webapps named “workspace”.  Seems like this might be useful.  Let’s take a look.  OK, there’s no WAR file here, but I do see a WEB-INF directory, guess they’re just deploying an exploded WAR to the Tomcat server.  Let’s see open up the web.xml and see how this thing is configured:

Well that was pretty useless.   Except…hmm…what’s this:

Looks like there’s a servlet filter configured that should be caching the images.  Let me just decompile that guy real quick and see what he’s doing:

What the hell?  This thing should looks to be setting the cache expiration.  Let me go back to  Firebug and see what the max-age is on the images I’m loading:

Max-age=0

WTF?  I guess the portal gateway is somehow stripping off the cache headers for this image. Why don’t we just hit the web-app directly to see if the portal is screwing with the headers.  Back to browser/Firebug pointed at:

http://bpm_portlet_server:123/workspace/jsf/menu/WebResource?r=/a/path/to/an/image.gif

<Reload a few times>

<Look at FireBug to see cache headers>

Max-age=0

WTF?!?!?!  OK, guess that servlet filter isn’t working right – that’s annoying.

Let’s take a look at that web.xml again…

Yep..still noise.  Time to start randomly looking around in directories in the workspace web application.

<cd $BPM_HOME/webapps/workspace/jsf/>
<Look around at a million different files that aren’t very insteresting>
<Stumble upon …/workspace/jsf/view/viewPresentationNormal.xhtml>

<Open viewTableCell.xhtml> n>

fn:getImage(‘ATTACHMENT_ICON’)

OK, so we’ve finally managed to dive down to the where the app is making calls to get images. <Quick timeout to pat myself on back and IM friends a steady stream of profanities about how ridiculously ALBPM is built>.  Now, that fn: prefix is a tag libarary.  Let’s see what taglib is being used.  Obviously that stupid taglib isn’t included in hasAttachments.xhtml, that would be too simple.  So backtrace through the xhtml files until we get to viewPresentationPanel.xhtml which includes that line:

xmlns:fn=”http://bea.com/bpmWorkspace/functionsLibrary

Now to find where the actual code for this taglib lives…BACK to web.xml

/WEB-INF/facelets/bpmWorkspace.taglib.xml

fuego.workspace.jsfcomponents.FacletsFunctionLibrary

jar -xvf fuego.jsfcomponents.jar

oc:someMethod

So let’s see what the oc: tag library is all about.  ViewPresentationNormal.xhtml was nice enough to include the line:

xmlns:oc=”http://bea.com/opencontrols”

Back to our old friend web.xml.

jar -xvf opencontrols.jar

jar -xvf fuego.workspace.jar

jad workspace/jsfcomponents/WorkspaceTableRender.class

grep -i image WorkspaceTableRender.jad

grep -i img WorskpaceTableRender.jad

String urlBase = “/plumtree/common/private/opencontrols/image/table”;

jad com/bea/opencontrols/XPResourceRequest

<context-param>

<param-name>com.bea.opencontrols.IMAGESERVER_URI</param-name>
<param-value>http://your.imageserver.url/bpmContext</param-value>

</context-param>

You’ll may have noticed that I referred to “we” several times in the text above.  No, I haven’t started referring to myself in the royal third.  I actually had a partner in crime for some of this debugging exercise.  Some of you may know him as Howard, some of you might refer to him as Ross, but I just call him HRoss.  In any case, he’s one of the best portal consultants still working directly for Oracle.  So if you’re still shelling out the big bucks for an Oracle consultant (rather than a more reasonably priced alternative *cough* Function1 *cough*), ask for him by name.