The Bookmark Portlet Locator
By Nino Guarnacci on Dec 05, 2008
Basically we needed a solution to address the recurring problem of plumbing into content html properties some content portal hyperlinks,
We than implemented a portal url pattern based on generic portlet instances’ bookmarks, instead of on pageLabels: any portlet instance (besides of its parent netuix control) can be administratively labelled via a specific portlet preference, and from that moment on, reachable via a simplified, shortened http url:
Secondly, more project-scoped, we had also to get an easy way to profile 3.rd party CMS items, when no VCR ‘s SPI were at disposal (in our case we dealt with Interwoven’s TeamSite, still lacking of a fully fledged VCR connector implementation: the only choice was bulk loading), using entities acknowledged by wlp’s UserInteraction API and Tools: those values had to be exposed from portal, retrieved and included in IW forms and then resubmitted to portal, as content item’s metadata.
This solution has not been –yet- tested in a production environment.
We did some internal performance tests using jrockit ‘s MC tools (basically to get an idea of latency gain in custom cache usage) that showed reassuring results (the overhead of url computing / decoding is in terms of milliseconds…….)
We lend to consider the solution – at this stage –more likely to be wlp code hacking than a real world solution, but yet hope that the underlying idea can be leveraged to develop a similar feature in future wlp releases (we do need it…..)
Following, see comparative results among tests with disabled / enabled url resolution caches
In our solution, those urls should also can carry / support a (unpredictable) number of further additional parameters (as querystring params), eventually parsed by the portlet instance’s jsp, to further parameterize –on user request basis - the behaviour of the target jsp portlet’s algorithms (more on this hint on next sections): in our case we needed to customize cm query logic with some external CMS item’s properties.
Another requisite we had to address (which is somehow out of scope for the Locator itself, but still useful set of methods) was also to define and expose (towards 3.rd party CMS), some WLP personalization entities used by WLP Framework and/or WLP UserInteraction personalization engines (i.e. we decided respectively to use streaming Portals / Desktops name-paths, or UserSegments’ rulesets names), so that personalization reasoning logic externally defined could work inside WLP User Interaction engines, even in absence of any VCR SPI implementation.
As said, we than ought to design –on Locator- some logic to
Last but not least, the solution should grant
 The frendlyUrl-to-pageUrl resolution must be dynamic and based on a indirection entity (bookmark) not on portlet instance id, because portlet instance could reasonably get moved among different pages/desktops/portals in the interval the information is exposed and the item is bulkloaded back to portal…..
As said, the Locator consists in a WebLogic JEE Shared Library (PortletLocator.war)
As you link this library, you will find basically three kinds of components:
The interfaces that export wlp-related information towards external clients
All the further supporting / helper / cache logic is packaged in a .jar in the WEB-INF/lib
Just proceed as a normal shared lib:
1) install the web library in your wlp server / cluster
1) then, add the standard library reference tags in weblogic.xml of your portal web app:
3) Congratulations! You’re done.
Of course, in a DEV environment, you can include it in the WLS JEE Library list:
The library has a complete default configuration: if you don’t have special requirements, it’s all there. You can skip to Usage section.
If you really have to, you can still configure a bunch of parameters (read Usage section to understand the underlying semantics in there; for now just pick up the list):
We didn’t use any new, nth xml configuration file: to override the default configuration you just work on
Defaults, the PortletLocator creates 2 new portal caches with 1h TTL:
Let’s distinguish Locator’s usage into 2 different context / use cases:
(WLP Portal side; role: PortalAdministrator; tool: PortalAdminTool)
 By now no control is made on bookmark’s preference value uniqueness: we didn’t find an efficient solution to automate this control on portal lifecycle stages (i.e. web app deployment time, new preference insertion, etc)
From this moment on, with PortletLocator deployed and configured, you can reach this portlet instance by composing this url on a browser:
When you hit a non existing bookmark, the filter send back a Http Error Code 436 (to let you customize error handling with a friendly page / error handler)
Navigate to Web Service ‘s PortalStructureService WSDL and test operation availablePortletsBookmark: an invocation returns the full map of bookmarked portlets: a list of following key/values
following an example of returned values:
This key/value list can then be easily embedded in external CM contribution tool (in our case, into TeamSite’s forms) in the form of a combo box: the options key being the bookmark value, while the options value being the portlet instance description.
The redactor, when he needs to plumb an hyperlink on an html body of a cm item, can than select a bookmark’s value by selecting his description.
Note that any duplicated entry of bookmark_value / portlet instance description has to be handled manually with a fix in wlp’s portal admin tool.
Just store this picked value (the bookmark’s preference value) in a cm specific item property / metadata (i.e. WLP_BOOKMARK)
(CM side; role: CM developer)
At export time (i.e when preparing content item for wlp’s bulkloading) in our solution, Interwoven developers just parsed html content for any CM proprietary hyperlinks;
If present, they queried the target’s item WLP_BOOKMARK property with that value, they invoked again Locator’s PortalStructureService , just a different operation: getContextUrlFromBookmark:
In this way the bookmark definition itself is decoupled from current portalweb-scoped configuration, that can differ among different environments, deployments, evolutions, etc), use the result to compose href attribute of resulting anchor tag inside cm item html property.
At this stage the CM developer can choose to add further querystring parameters(as the result of additional target cm metadata enquiry, i.e. ITEM_ID, Locale, WLP_PortalPath, WLP_UserSegments, more on that following)
The resulting url could be:
 In next release the bookmark-to-webcontext url resolution could be moved inside the portal itself, using some Ajax feature at click time
After bulkloaded the item(s), and CM display temaplates / jsp implemented and deployed, any /portletlocator links get intercepted by PortletLocator’s ServletFilter;
This filter picks up the bookmark value in servletpath and compute the actual and current pageUrl on which target portlet instance is – currently – instantiated in.
The user is redirected or forwarded (based on exposure-redirect-request-enabled configuration parameter) to portal’s page url .
Should any additional querystring parameters be present in url, the filter copies them in (Outer)Request scope (or Sessione scope, if configured), so that target portlet can take advantage of them to further customize the default behaviour of i.e. content display logic: for instance you can use item_id request parameter to select a specific content item (given you provided a corresponding cm property / metadata and that this id is really unique across the CM Repository).
First you had to identify which portal entities you will use to as personalization discriminating data useful to profile your cm item: you can decide to “tag” target user segments using both
Locator expose those two list in two different web services:
You can follow same guidelines to include to external CM tool those lists: the redactor would than just pickup the current usersegment / current portal that specific item is targeted to, and store it this value in a specific cm item property / metadata (i.e. WLP_USERSEGMENTS, or WLP_PORTAL_PATH).
On wlp side, when implementing cm display templates or jsps, you can select the cm item to show by comparing:
The latter being a portlet instance’s preference while the former the result of a dynamic evaluation leveraging Locator’s custom control API:
String segmentOfUserFromRequest(HttpServletRequest request)
|Furthermore there are many specific features that can be used, we suggest to consult this pdf documentation.|
Nino Guarnacci & Gabriele Folchi