Originally published at developer.com

WSRP stands for Web Services for Remote Portlets, a handy specification from the folks at OASIS that provides a standard for portal applications to share portlets between portals. Put another way, WSRP is the ability to produce an interface to useful functionality which can be consumed throughout your enterprise with little or no changes to existing code. Sound familiar?

Almost all of the latest versions of commercial and open source portal products support WSRP, though your mileage may vary based on the vendor.  The basic mechanism is the same as any old web service. The producer provides a WSDL that instructs the consumer on how to generate a SOAP request. The difference between web services and WSRP is that with a web service the developers of the consumer application next need to figure out how they will use the SOAP response where the WSRP consumer receives a response at the presentation level and all the consumer needs to do is decide where they will display it.  The portal frameworks abstract the heavy lifting and all that is required of developers is to configure the producer and consumer to achieve basic WSRP integration. In theory, this simplicity provides all an enterprise needs to reuse portlets across the enterprise “instamagiclly”. In practice, business requirements rarely let us get off the hook so easy.  In fact, once an enterprise begins to use WSRP, the requirements tend to get more and more complicated, which is why the WebLogic Portal (WLP) has evolved to provide more and more WSRP functionality with increasing ease of development.

When WSRP Makes Sense

WSRP is a technology that provides three benefits. One is reuse; another is performance, (though oftentimes using WSRP will provide only one these two benefits); and the third is the ability to release portlets asynchronously.

WSRP is not the only approach to achieving portlet reuse. Portlets can also be bundled into a WAR file and used as a shared library, or simply copied from one application to another.  Where reuse is the goal, WSRP is the solution of choice when the portlet is used in more than one portal.

Sometimes portlets are resource intensive. If a portal page contains a collection of portlets where system or network resources impact the usability of the portal, WSRP can provide a strategy where the processing is divided across servers to improve performance.

Portals provide the ability to aggregate access to applications. In many enterprises, these applications are owned and maintained by disparate groups where the coordination of release schedules can be difficult (if not impossible). Here, WSRP provides the advantage of allowing a portlet or group of portlets to be released independently of the main portal application.

The Best Way to Consume a Remote Portlet

In the WebLogic Portal, portlets are WSRP enabled by default since version 9.2, as shown below:

In fact, the notation in the .portlet file is only required if you are not offering your portlet as remote, as show by these two snippets:

<netuix:portlet definitionLabel=”simpleProducerA_1″ title=”Simple Producer A”>

<netuix:portlet definitionLabel=”nonRemoteExample_1″ offerRemote=”false” title=”Locals Only”>

In a WSRP implementation, the remote portal is the producer and the portal displaying the remote portlet is the consumer. The consumer gains access to the producer by registering the producer as a remote producer by accessing the producers WSDL. The WSDL is generated automatically by WLP and available as an address from the producers web application in the format of [server_address]/[web_application]/producer?wsdl. The example portal applications referenced in this article are named wsrpConsumer and wsrpProducer, with the portal web applications being named wsrpConsumerWEB and wsrpProducerWEB, which would make the producer’s WSDL address http://localhost:7001/wsrpProducerWEB/producer?wsdl. This WSDL simply defines key details about interacting with the producer, such as security:

<wssp:SecurityToken TokenType=”http://docs.oasis-open.org/wss/2004/01/oasis-2004-01-saml-token-profile-1.0#SAMLAssertionID”>

And where to find various services, such as registration:

<s0:port binding=”s3:WSRP_v1_Registration_Binding_SOAP” name=”WSRPRegistrationService”>

<s4:address location=”https://localhost:7002/wsrpProducerWEB/producer/wsrp-1.0/registration” />

</s0:port>

While the most basic of WSRP producers require 60+ lines of XML to define the WSDL, even the most complicated WLP applications will generate a WSDL for you. The only hand editing you may need to do is with simpler files such as wsrp-producer-config.xml and wsrp-producer-registry.xml.

Remote portlets are consumed in the producer with a proxy portlet, and WLP provides two ways to create a proxy portlet. One method is through the WebLogic Workshop IDE at design time. Defining a proxy portlet at design time requires providing an address to the producer in a .portlet file, which cannot be changed at runtime. Due to this drawback, this approach is not recommended in this article. If you want to see how it works in detail, you can follow the tutorial included in the WLP documentation.

The other method to define a proxy portlet is through the WLP Portal Administration Tool (PAT). To define proxy portlets in the PAT, you must first create a streaming portal. Streaming portals are database-driven rather than file-based (where users access the portal through a .portal file defined in Workshop). There are many considerations outside of WSRP in choosing between a file-based versus a streaming portal and are beyond the scope of this article.

To quickly illustrate the steps of creating a streaming portal and consuming a WSRP portlet we will use the naming conventions from our example applications as well as the existing assets in the example. For simplicity we will have both portal applications deployed to the same domain. With this in mind, here is the process to create a streaming portal and consuming a simple remote portlet:

With portal server running, navigate to http://localhost:7001/wsrpConsumerAdmin for your consumer portal’s administration console (or, with the Portal perspective open in Workshop, select Run\Open Portal Administration Console) and log in with the admin credentials. From the Portal Management page, create a streaming portal and a desktop based on the .portal file you created in Workshop. In the screen shot below, we’ve created a portal named “wsrp” with desktop named “default”.

Next, add your producer portal to your library by expanding Library and Remote Producers, then click on the Add Producer button. In the wizard, enter

http://localhost:7001/wsrpProducerWEB/producer?wsdl and click Search. Click on the Remote Producer in the search results, then follow the self-explanatory prompts to complete registration.

With your remote producer registered, click on the producers’ name, then Selected Portlets to access the Add Portlets button. The Add Portlets button will start a straight-forward wizard to add your remote portlets.

Finally, add the Hello Producer to your Consumer Desktop using the intuitive PAT, which will display as follows once completed:

In WLP 9.2, the process of placing your remote portlets must be repeated manually for each environment (typically, with varying names and number of environments, Test, Staging, and Production). Beginning in WLP 10.0, WSRP portlets can be included in propagation as other portal configurations are in earlier versions of WSRP (see Propagating Weblogic 8.x Portals for an introduction to portal propagation).

If you followed the naming examples in this article you can browse to http://localhost:7001/wsrpConsumerWEB/appmanager/wsrp/default to see the results.

Congratulations, you have achieved portal federation with WSRP!

You’d think this would be a bad file error, but it wasn’t. Turned out the portalDataSource connection pool had gone bad, preventing the desktop from being found or loaded.  Again, you’d think that a restart of the server would fix that, but it didn’t. I had to un-deploy and re-deploy the connection pool before things started working again.

This was on WebLogic Portal 10.3.2. I haven’t seen it before, but that doesn’t necessarily mean it is restricted to that version.

Using the Content Presenter Portlet to add content will be unreliable if server affinity is not configured for the cluster. The portlet will reset itself mid-task. This may not be the case if session replication is turned on, though, as I ran across this in the early stage of the project. Still, something useful to be aware of.

I ran across a thread on LinkedIn that pointed me to an excellent article on IT on Guard dealing with a slow WLS start up issue.

http://humor.fywservices.com/2010/08/milking-technology/

Today’s post on my joke blog should strike home with readers of this blog.

This thread is a must-read if you are a consultant or ever thought of being one. Free LinkedIn membership required.

In Inline Editing with WLP 10.3.2 Content Templates, I concluded that if something else came up I would blog it. Well, it did, so I will.

The shared library part went nice and smooth. To note the (semi-)obvious, the wlp-template-config.xml changes noted in the post must be done in the consuming application, not the shared application, as the consuming application always over-rides.

The part I forgot about was that you must create a role for editing the content or else only Admins will be able to do the inline editing.  I created an enterprise role named “homePageContentAdmin” for my first test, then granted that role update privelages on the content item. Once I did that, it worked properly.

As another sort-of-obvious note, this requires granting view privelages for anonymous or authenticated roles for other users to view the content.

I know it is bad practice to catch java.lang.NoClassDefFoundError.  Today, however, I did need a way to deal with it because I have this annoying habit of wanting everything else to work even when some non-critical piece is broken.

This case was a matter of a third-party security jar that would throw up rather than out when it could not find its properties file. No matter how many catches I had wrapped around the call to the method in the jar, the java.lang.NoClassDefFoundError would bubble up as a big render issue in the JSP.  I am only using this jar to get the user display name, so it isn’t like my application is not secure if I don’t have their name to make them feel special.

After several annoying an pointless approaches, I came up with the following (ugly-but-effective) solution:

try//the Security class relies on this property file but pukes if not found, so we test for it here
{
FileInputStream in = new FileInputStream(“security.properties”);
in.close();
}
catch(Exception e)
{
System.out.println(“security.properties is missing from classpath”);
return personInfo;
}
…go use the third-party class that depends on the file having proven it is there

This allowed the application to continue running and not falling apart at the header just because one file was missing. It is one thing to have a bug that is minor, another when that bug becomes something that users pick up the phone about.

Carrying on from WLP Content Presenter Portlet Simplified, the next goal is to get the in-line editing from the sample application running because most clients think that is a cool feature and don’t understand why it isn’t available by default. Right now I am almost done, and wanted to blog the progress to date, even if the most important part won’t be done until Monday…

There is a really (really, really) brief instruction in the official documentation to do this here.  I’m sure if you have been building content templates for years that document will be enough, just as I’m sure that if that were the case you won’t be reading this (unless to make tsk-tsk noises at my ignorance). The files to import can be taken straight from there, which is:

1. Display Template (Outer Template) – <WLPORTAL_HOME>\samples\applications\portalApp\ contentPresenterSampleWeb\samplePresenterTemplates\ inlineEditExamplePresenterTemplate.jsp
2. CM Display Template (Inner Template) That Displays the Content – <WLPORTAL_HOME>\samples\applications\portalApp\contentPresenterSampleWeb\sampleCMTemplates\inlineEditExampleCMTemplate.jsp
3. JSP File that Performs Other Work – <WLPORTAL_HOME>\samples\applications\portalApp\contentPresenterSampleWeb\sampleCMTemplates\saveNode.jsp

Now, the first time I tried this, I wanted my own paths and renamed everything. It didn’t work. I’m sure I can rename them now, but at this stage the important thing is to get it working, with re-branding to the custom project being secondary.

The next step is to add these to the wlp-template-config.xml. Where the manual tells you to make your own, I find it much easier to simply go to the merged view and copy in the one from the shared install. While this may make a little more work for future WLP upgrading, it is worth it to me to save the time. With the file now in my project, I get the copy from the sample application and added the nodes to my own application that reference the files imported earlier. The relevant parts of the resulting file are below:

Under <content-name-space><name>wlp-content-presenter-single</name>:

<content-resource>
<name>htmlContent</name>
<default-template-uri>/portlets/wlp-content-publisher/templates/wlp-default/cm/wlp-default-resourceDefault.jsp</default-template-uri>
<view>
<name>Show</name>
<description>This is the detailed node view for simple HTML content in the Avitek Financial Intranet sample.</description>
<uri>/sampleCMTemplates/simpleShowView.jsp</uri>
</view>
<view>
<name>ShowEdit</name>
<description>This is the detailed node view with inline
editing for simple HTML content in the Avitek Financial
Intranet sample.
</description>
<uri>/sampleCMTemplates/inlineEditExampleCMTemplate.jsp</uri>
</view>
</content-resource>

Under <template-name-space><name>wlp-content-presenter-single</name>:

<view>
<name>Sample Single Item View with Inline Edit</name>
<description>This is the sample Content Presenter Display Template view for a single item that provides inline HTML editing.</description>
<uri>/samplePresenterTemplates/inlineEditExamplePresenterTemplate.jsp</uri>
</view>

Now, for this to work, you have to create a content type of named “htmlContent”. I created this type with no parent and a primary property named “content” of data type binary.

I’m still testing to find out if the content needs to include “.html” as a suffix to the name.  And, yes, you can by-pass much of this “have to” stuff if you re-write everything, but the goal here is to get it deployed and have business users editing content today

I thought I had it with that, as I could then set the content in an instance of the Content Presenter portlet as a piece of content of the type htmlContent and see the Edit HTML button, but nothing happened on clicking it. Dang! Running it in FireFox (the project was targeted at IE, otherwise I would have started in FireFox), I found the disconcerting message “wlp dojo is not defined”.

Ok, I haven’t used the Dojo tookit yet. I have been building stuff by hand for so long, I just haven’t had the need to use a pre-built JS framework, even one that is as highly praised as Dojo. So I’m not sure if I went about it the best way to get this fixed, but it was the fastest. I searched through the sample directory until I found dojo.js (in Windows, it was located at [WEBLOGIC_HOME]\wlportal_10.3\samples\domains\portal\servers\portalServer\tmp\_WL_user\portalApp\4ycmg9\beaext\dojo-0.4.3-ajax ). I also found that in inlineEditExampleCMTemplate.jsp, the path it was looking for was ${pageContext.request.contextPath}/dojo-0.4.3-ajax/dojo.js. I tried importing it directly to my project from OPOE, but it must be compressed or the path is too long, so I did a copy/paste to a temp directory and imported it from there.

And, viola! It worked.

Now all that is left is to make the web project into a shared library so that I don’t have to turn off validation is my “real” project. If there is anything out of the ordinary with that process I will blog about it here.  Otherwise, go forth and edit.