Hints and tips for using WSRP with the portal

Here are some hints and tips for using WSRP with HCL WebSphere Portal.

Consuming remote portlets with the portal

If we use HCL WebSphere Portal to consume remote portlets, we must set the following JVM property for the portal JVMs:

com.ibm.ws.websvcs.useMultipleSetCookie = true

Use this property to enable the WSRP Consumer to process multiple Set-Cookie headers that are contained in a WSRP response.

This property was introduced with IBM WebSphere Application Server APAR PM91361. The APAR is contained in WebSphere Application Server Version 8.5.5.1 and later.

To set this JVM property, use the WebSphere Integrated Solutions Console. After you set this JVM property, restart the Portal server.

Consuming remote portlets from IBM WSRP Producer for WebSphere Application Server

If we use HCL WebSphere Portal v8.5 to consume remote portlets from an IBM WSRP Producer for WebSphere Application Server that you own, use the July 2015 update of that Producer. If your Producer is an earlier version, update the Producer to the July 2015 update. We can obtain the IBM WSRP Producer for WebSphere Application Server from the IBM Collaboration Solutions Catalog.

Consuming remote portlets from an earlier version IBM WSRP Producer for WebSphere Application Server might not work properly under individual environments and scenarios.

Registration

The WSRP Producer for HCL WebSphere Portal does not support the WSRP Registration interface.

Remote portlets on unauthenticated pages

If you add remote portlets to unauthenticated pages that have public sessions turned off, you get the following two consequences:

1. Session data is lost for each request.

2. An extra request to the Producer is submitted to establish a session.

If you add remote portlets to unauthenticated pages, turn on public sessions. This way, we can benefit portal performance and avoid unexpected behavior that results from the lost session data.

Rendering URLs for forms

Submitting data to a portlet through forms is semantically an action request, as this request changes the state of the portlet. WSRP strongly enforces the separation of action and render requests according to the corresponding semantics. It prevents the submission of form data through render requests. As a result, portlets that use render URLs to submit form data do not work remotely.

Portlets cannot use portal internals

With WSRP, we cannot use portal internals in portlets, such as engine objects or engine tags. Portlets that use such internals do not work remotely as WSRP does not supply the infrastructure required for portlets to use portal internals.

Compatibility of portlets with WSRP

The following restrictions apply to the Compatibility of portlets with WSRP:

Some of the portlets that are included with HCL WebSphere Portal cannot be provided as WSRP services.

The reason is that some additional and more advanced HCL WebSphere Portal concepts and features are not reflected by the current WSRP standard yet. This group includes all portal administration portlets, the Portal Search portlets Manage Search and Search Center, and some other portlets that are provided with the portal.

If portlets contain URLs to other resources, the URLs must be encoded according to the Java portlet specification to work with WSRP.

You might have portlets that serve or link to resources such as images, CSS files, JavaScript files, or servlets that are packaged with the portlet. To work in a distributed environment such as WSRP, these portlets must handle the URLs correctly. The HCL WebSphere Portal WSRP Producer runtime hooks into the URL generation code used by the Java Portlet Specification APIs. In such cases, the portal can generate WSRP-compliant URLs to allow resources to be proxied by the WRSP Consumer server. Therefore, URLs in the browser can point to a resource proxy that the WSRP Consumer provides and that routes the request to the appropriate resource that the WSRP Producer host provides. For example, portlets might contain URLs that include CSS or JavaScript files, and we want to provide these portlets by WSRP. In such a case, we must make sure that the URLs point to the correct locations by encoding them in compliance with the Java portlet specification. If we do not encode the URLs using the JSR API calls, the portlets might not work properly.

Note: The HCL WebSphere Portal resource proxy implementation also supports the serving of relative URLs. Example: A URL points to a CSS file and is encoded using the Java Portlet Specification API. The CSS file in turn contains relative links to further resources such as images. In such a case, requests for those images are also routed and served through the WSRP Consumer resource proxy.

WSRP does not support Consumer-side configuration of remote portlets that do not support shared configuration

The configuration of the edit_defaults_compatibility portlet mode is not supported for portlets that are consumed by using WSRP.

The PUMA SPI cannot be used with WSRP

The PUMA SPI does not allow use with remote portlets.

Tag Cloud, Tag Center, and Results List portlets do not support WSRP

The Tag Cloud and Tag Center portlets, including the Result List portlet, do not support WSRP. Therefore, a Producer portal cannot provide these portlets as remote web services, or for a Consumer portal to consume them so that its users can use them.

Parent topic: Reference for using WSRP with the portal