Web Services for Remote Portlets, also known as WSRP, is a standard defined by an OASIS committee which describes how to use SOAP requests to receive fragments of HTML from a remote service.   The overview on the OASIS site states:

WSRP defines a set of interfaces and related semantics which standardize interactions with components providing user-facing markup, including the processing of user interactions with that markup. This allows applications to consume such components as providing a portion of the overall user application without having to write unique code for interacting with each component.

So what does WSRP really do?  It can allow an organization that has multiple WSRP compatible portal products to reuse portlets across the different platforms.  Portal products such as SharePoint, PeopleSoft and WebSphere provide support for WSRP.  Even products such as Adobe LiveCycle Data Services ES2 provides support for displaying Flex client applications as a portlet.   This could reduce or eliminate the need to create a custom solution to display information across multiple platforms.   WSRP can also be used in an organization with a very heavy focus on SOA where you may already have web services and adding a WSRP producer in front of them would allow multiple portal technologies to render the portlets in the same fashion.

In February 2006 Mike Fitzmaurice from Microsoft wrote an excellent blog post discussing WSRP. In his post he describes the reasons for using WSRP but also cautions that it isn’t “magic” and it shouldn’t be used as a shortcut for good application design.   Although the post is several years old the information is still relevant today; I highly recommend you read it before proceeding with a WSRP implementation.

SharePoint 2010 provides a WSRP 1.1 viewer web part (also known as a WSRP consumer).   This web part allows a user to connect to a trusted WSRP producer and render the portlet within a SharePoint site.   Below I will walk through the process on how to use the WSRP viewer web part.

SharePoint only allows a user to connect a WSRP viewer web part to a trusted producer.  A trusted producer is any producer that has been configured for use in the farm by the SharePoint administrator.  An end user cannot add trusted producers and they cannot override the settings by the SharePoint administrator and connect to untrusted producers.  This restriction was put in place to protect the SharePoint environment and the end user from damages that could be caused by a malicious remote portlet.

To add a trusted producer the SharePoint administrator needs to create a TrustedWSRPProducers.config file in the “program filesMicrosoft Office Server14.0Config” folder on the SharePoint web front ends.   A sample configuration file called TrustedWSRPProducers.xml.sample is available in the config folder and can be used as a guide.   Note that the path is not in the traditional SharePoint “hive”.

Sample contents of a TrustedWSRPProducers.config file:

<Configuration >
  <Producer Name="NetUnity" AllowScripts="true">
     <ServiceDescriptionURL>http://wsrp.netunitysoftware.com:80/WSRPTestService/WSRPTestService.asmx</ServiceDescriptionURL>
     <RegistrationURL>http://wsrp.netunitysoftware.com:80/WSRPTestService/WSRPTestService.asmx</RegistrationURL>
     <MarkupURL>http://wsrp.netunitysoftware.com:80/WSRPTestService/WSRPTestService.asmx</MarkupURL>
     <PortletManagementURL>http://wsrp.netunitysoftware.com:80/WSRPTestService/WSRPTestService.asmx</PortletManagementURL>
    <!-- <SsoApplication Name="NetunityWSRP"/>
 SsoApplication Element is optional. It specifies the SSO application to use when authenticating to the WSRP Producer. -->
 </Producer>
</Configuration>

 

After the TrustedWSRPProducers.config file has been created and placed in the “program filesMicrosoft Office Server14.0Config” folder on the SharePoint web front ends a user can configure the WSRP Viewer web part.

Once a WSRP viewer web part has been added to a site the site designer or administrator will need to open up the web parts configuration panel and modify a few settings.   The first setting that needs to be modified is the producer.   This drop down selector will list out each of the producers that have been made available in the TrustedWSRPProducers.config file.   After the producer is selected the portlet drop down selector will populate with the available portlets for the selected producer.    Select the desired portlet, make any additional configuration modifications to the web part and then click the OK button to save these settings.

image

Some WSRP portlets may include additional configuration settings that are made directly in the portlet and not through the WSRP viewer web part tool pane.  To access these settings the SharePoint site must be switched to edit mode and then the Edit Web Part option needs to be selected from the WSRP viewer web part drop down menu.

image

This will switch the web part to edit mode which will display the web parts configuration tool pane along with displaying additional portlet configuration information in the location of the web part on the SharePoint site.

image

WSRP is just one option of many for interoperability between different line of business systems and portals when working with SharePoint 2010.   Before fully committing to using WSRP I would also recommend that you look at SharePoint’s business connectivity services and creating custom data view web parts from webservices  using SharePoint Designer.   As Mike Fitzmaurice said in his blog post “It’s up to you to decide, but please, please,please make that decision an informed one.”