Web Service for Remote Portlets (WSRP) is a standard for aggregating content within a host system, allowing the content to come from an external system, yet styling to be provided by the host.
SharePoint has 'support' for WSRP since SharePoint 2007, via the WSRP Viewer web part (Enterprise), however while it may technically meet the standard it is all but useless for anything except the most basic of requirements (as at the current version, SharePoint 2013).
How WSRP works is, once configured, the host inserts an iframe into the page (to contain the portlet), with the source of that iframe pointed back to a proxy running on the host server itself. This allows the host server the opportunity to intercept and rewrite the requests and responses, for example style sheets from the host server can be injected, and page resources (such as images) can also be rewritten to point to the proxy.
Limitations with SharePoint:
* The code implementing the WSRP consumer (there is no producer support) appears to have been simply translated from Java, still contains many Java features/conventions, and isn't very responsive.
* It does not work in SharePoint Online. In SPO, the WSRP Viewer web part is available, and can actually be added to a page, but there is no way to configure it to display anything. Configuration requires updating an XML file in 'C:\Program Files\Microsoft Office Servers\15.0\Config', which simply isn't possible in SPO. See http://support.microsoft.com/kb/2871282
That means you need to have an full installation; it is an Enterprise feature, so you require an Enterprise version.
* Resource redirects do not work. Requests for resources from the proxy pages, such as images, fail with a security error unless the target authority (host name + port) is added to a list of allowed redirection servers.
These can be added to the configuration file with the undocumented <RedirectServer> element (repeating for each server), which gets past the security issue, however it still doesn't work because the proxy page never sets the content type, leaving it at "text/html". This means images aren't displayed, scripts won't be run, etc, all because they have the wrong MIME type.
This is probably why the configuration is undocumented. The feature was simply never completed.
* Portlets can't be easily styled. While SharePoint does inject a style sheet into the rewritten content, it is hard coded to "/_layouts/1033/styles/core.css" (varying by language), with no way to configure.
This means it has SharePoint styling, but to style with any kind of site branding you would need to do something like directly edit the CSS file in the LAYOUTS directory, which I strongly advise against due to maintainability issues.
Features:
The few features that the WSRP Viewer part does have in SharePoint include that it can be integrated with the Secure Store for trusted subsystem style authentication. The <SsoApplication> element needs to be configured with the name of the Secure Store application that holds the credentials.
These credentials, if present, are then used as the network credentials for accessing the external (source) system. The WSRP Viewer can either be anonymous, or if configured to use the current user, it will pass through the Name property of the current SharePoint user in the <UserContext> element, userContextKey attribute, in requests to the source system. There is no way to configure this except turn it on or off.
There is also another undocumented configuration option where you can add <RegistrationProperty> elements, with Name and Value attributes, to the producer, which appear to be used as name/value pairs passed through to the RegistrationURL, if used. (I have not tested this, so it may not work.)
Summary:
In a pinch, WSRP could be used to display some plain text in an installed Enterprise environment, but you will very quickly hit limitations with customisation to the point that a plain iframe (Page Viewer web part) would generally do just as well.
I would recommend against changing the core.css style sheet in the LAYOUTS directory, but if your organisation is strongly committed to WSRP and you don't mind a maintenance nightmare with SharePoint, then you could test to see if it works. (I haven't yet).
Bottom line -- WSRP isn't really supported in any practical way.
Thanks. Is it still advisable to proceed with WSRP, as I don’t find any working examples with SharePoint 2013?
If you have any documentation or working examples for consuming WSRP with SP2013, could you share?
WSRP was never implemented correctly in SharePoint, and that is the same in SharePoint 2013.
Technically, you can get some plain text/HTML come through, but can’t style or get any of the normal benefits if WSRP. In fact, the implementation is so poor I would avoid it altogether and not recommend it as a viable solution in most cases.