Configuring the WSRP Consumer Webpart in SharePoint 2013 and 2010

Tags: SharePoint, Admin, Office 365, SharePoint Online

<UPDATE>

Microsoft just published a KB article stating that the WSRP Viewer Web Part is not supported in Office 365 SharePoint Online (‚Äčhttp://support.microsoft.com/kb/2871282/EN-US). The webpart is still available to add to webpart zones, but it is officially not supported. 
 

</UPDATE>

 

The WSRP Consumer webpart in SharePoint allows organizations to consume published portlets based on the WSRP OASIS standard. WSRP stands for Web Services for Remote Portlets and allows publishers to create reusable pieces of dynamic content or functionality and sites that support WSRP can consume, display, and interact with that published content (more info at Wikipedia: https://en.wikipedia.org/wiki/Web_Services_for_Remote_Portlets). SharePoint has had “support”, in one form or another, for WSRP for quite some time. In fact, in the MOSS 2007 product, there was a WSRP Toolkit that eased the development of WSRP components and was eventually open sourced. In SharePoint 2010, WSRP support was reduced to a Consumer webpart; and that same functionality was carried over to SharePoint 2013. If you do a search for WSRP and SharePoint trying to figure out how SharePoint 2010 and 2013 support the standard, you will undoubtedly find forum and blog posts that state the SharePoint support for WSRP is a “Checkbox” capability. A “Checkbox” capability simply means that, technically, SharePoint does support the WSRP standard, but in a limited fashion. If you are responding to a RFP and a system requirement is WSRP support, check, SharePoint meets that requirement…as long as it’s only consumer side and you can build your solution on a webpart page.

Limited WSRP supportability may not be a bad thing and the WSRP Consumer webpart included in SharePoint 2010 and 2013 may fit most business’ needs just fine. To me, SharePoint doesn’t need to support every standard or surface data from all publishers in their native output or standards-based interface. BCS isn’t a standard, but can be used Out-of-the-Box (OOTB) or in a custom solution to bring external data into SharePoint where users and developers can interact with it through familiar interfaces and common APIs. The point is this, WSRP support in the latest versions SharePoint is not robust and heavy investments in WSRP will probably need custom web service or App Model work on the SharePoint side to fit into the architecture going forward.
 
Now, with the SharePoint WSRP introduction out of the way, how do we configure the environment to consume WSRP Producer web services? A cursory look into the subject will have you adding Xml files to your config folder in the SharePoint Root. However, this will not work. To configure your SharePoint Farm (yes, Farm) to consume WSRP Producers, you need to construct a TrustedWSRPProducers.config file that holds all of the information about your producers and place it in the %programfiles%\Microsoft Office Servers\<Version [14.0 || 15.0]>\Config folder on all SharePoint servers that serve end user traffic (affectionately known as WFEs). Whoa, what? Okay, let me explain that a bit. The .config file is just an Xml file adhering to a schema defined by OASIS that points to your WSRP Producer resources. There is a sample in the SharePoint Installation Config folder that can be used for reference or you can get live demo endpoints that can be used to test the WSRP Consumer webpart from Netunity, SUN, BEA, etc. from the OASIS Wiki: https://wiki.oasis-open.org/wsrp/WSRP_Producers. For a real example, on a SharePoint 2013 front end machine, you can browse to C:\Program Files\Microsoft Office Servers\15.0\Config and find the sample Xml .config file to setup your farm. Just to be totally clear here, you have to have modify access to the file system for each front end in your SharePoint farm and these settings will be used to define the WSRP Producers for all WSRP Consumer webparts in your SharePoint farm.
 
Once you have the TrustedWSRPProducers.config file updated and have configured any proxy requirements, when you edit a WSRP Consumer webpart, you’ll see a list of available WSRP Producers in the webpart toolpart and you’re done.
 

To wrap this up, I want to bring up some oddities with the WSRP Consumer webpart in cloud hosted environments. If you own the entire farm and can define a set of WSRP Producers that will work for the whole farm, great, you won’t have any issues. What if you’re in an environment like Office 365, though? The WSRP Consumer webpart is there; both in the legacy (SharePoint 2010 Interface) and in the new 2013 UI version. Hmmmm….. Will that even work? Unfortunately the answer is “no.” The WSRP Consumer is available and you can drop it on a webpart page, but, since Global or SharePoint Service Administrators don’t have access to the file system, there is no way to configure the TrustedWSRPProducers.config file. This leaves consuming published WSRP interfaces with technologies like BCS or the SharePoint 2013 App Model. With the “Checkbox” capability WSRP has in SharePoint 2010 and 2013, perhaps an alternate development approach should be taken before investing in the WSRP standard.

No Comments

Add a Comment