Remote Rendering Portlet best practice

Remote Rendering Portlet best practice

+
Search Tips | Advanced Search

For remote rendering portlets...

To display content from multiple servers, enable single sign-on between servers.
WCM security is enforced using Portal logon or credential vault slot.
WCM content or components displayed within a WebSphere Portal page should be self-contained and not rely on other WCM content or components.
When creating presentation templates or page styles, reference just the content to display. Components, such as menus and navigators, should be displayed in separate portlets and linked to the Content Portlet as required.
JavaScript URLs will not work.
When a web page is rendered via the WCM application, some tags may be rewritten. The WCM application uses double quotes for attributes in HTML tags. If you use JavaScript to produce HTML tags, the WCM application will not recognize them if you use single quotes.

Path component tags

The URLs generated by the path component will be fully qualified when viewed through a portal. To generate URLs with no prefix, use the following "Type" parameters instead of the standard parameters:

Type="noprefixbase" instead of Type="base"
Type="noprefixservlet" instead of Type="servlet"
Type="Prefix". When viewed through portal the, prefix value will be printed. If no prefix exists then empty string is returned.

Use remote rendering portlets with credential vault authentication

When using remote rendering portlets that are configured to use content from remote WebSphere Portal servers, either:

Disable LTPA.
This is because with LTPA enabled without single sign-on you will be logged out each time you access a different server. If single sign-on is enabled with LTPA, the user will be granted the same access rights of the credential vault user.
Use a different domain name for the server hosting the remote rendering portlet.
Enter an IP address instead of a domain name when configuring the remote rendering portlet.

Configure the remote rendering portlet to connect to a clustered WCM URL

You may receive errors when using the remote rendering portlet to connect to a clustered WCM URL. This occurs when the WebSphere Portal Server and the WCM server are accessed by the same host. This is because they are both trying to use the same cookie.
By default, an Application Server uses a cookie with the name of JSESSIONID as the key to maintain session for that host. Since the WCM server is accessed by the same host, the Portal Server cookie overwrites the WCM cookie that maintains the session and vice versa. Logout is the result of losing a session.
There are four possible solutions:
Use local rendering portlets Local rendering portlets can be used to access the same content on different servers in a clustered environment.
Use the IP address Use the IP address of the WCM server instead of the HOST name when configuring the portlet.
Assign two host names You can assign two host names to the server running both WebSphere Portal Server and WCM and use one host.name for WCM and the other when configuring the portlet. There are two ways of doing this:

Assign two IP addresses to the WCM server and assign a different host.name to each IP.
Assign two Host names to the same IP in a DNS.

Change the default cookie name You could also change the default cookie name used by one of the servers:

Log in to the WAS administrative console.
Select Servers -> Application Servers -> WebSphere_Portal
Select Web Container Settings -> Session management.
Click on the "Enable Cookies" link. (Leave it checked.)
Change the cookie name from JSESSIONID to JSESSIONID2.
Click Apply and then Save the changes
Restart WebSphere Portal.

Use the Web 2.0 theme with a remote rendering portlet

To use the Web 2.0 theme with a remote rendering portlet create a HTTP proxy for AJAX. This is because when the Web 2.0 theme is used, content is being delivered from different domains. By default, the AJAX proxy is set to not allow any cross domain requests for security reasons. Create a HTTP proxy for AJAX to allow the remote rendering portlet to render content in the Web 2.0 theme.

Use the Web 2.0 theme with a local rendering portlet

By default, the local rendering portlet is on the Web 2.0 theme's portlet blacklist because of a known issue where the browser applet used to edit content with Rich Text fields does not load correctly in Internet Explorer when using authoring tool components. If this is not a valid use case in your environment, you can choose to remove the portlet from the blacklist at your own discretion. IBM recommends that you test the local rendering portlet in the Web 2.0 theme before putting it into production.
To use the Web 2.0 theme with a local rendering portlet remove the local rendering portlet from the blacklist by either removing or commenting out the following line from the portlet blacklist, or setting the value to "false".
"wcm.contentviewer.1001":false
The blacklist is stored in a Javascript file in the Web 2.0 theme: /js/portletsForServerSideOnly.js.
Any cached copies of the javascript file will need to be cleared from browser and proxy caches before the change will take effect in a client browser. See

Exporting remote rendering portlets

If the create-oids option is set to "true" when exporting portal pages containing remote rendering portlets, edit the configuration of the remote rendering portlet on the server the portal page has been exported to and re-select the page to broadcast to if using the "another page" broadcast link option.

Other limitations

The results of a POST in a form are only displayed within the portlet that sent the POST. You cannot send the result of a POST to another portlet.
The WCM application can not be accessed behind a firewall. This is because WCM will still need to be accessed directly for images and other resources.
An anonymous WebSphere Portal Server user will also be classed as an anonymous WCM user so that the logon override does not work for anonymous users.
If a WCM proxy server is being used with Rendering Portlets, all URLs rewritten by the proxy will not be fully-qualified, but server-relative instead. To address this issue, redirect mappings can be created in the HTTP Server configuration that will pass the URLs to the proxy server.
WCM caching features and category selection trees cannot be used with the Local Rendering Portlet .
If you use a local rendering portlet with CSA (Client-Side Aggregation) you may recieve a "wcmHideCurrentContextMenu is not defined" error when switching from the inline authoring user interface back to the normal view. If this error occurs, refresh the page the page should render correctly.
When you configure a local rendering portlet or remote rendering portlet with CSA, you may need to use two clicks to close the configure pane when you click Cancel or OK.

Parent topic
Configure the local rendering portlet

Parent topic
Configure the remote rendering portlet

Use local rendering portlets	Local rendering portlets can be used to access the same content on different servers in a clustered environment.
Use the IP address	Use the IP address of the WCM server instead of the HOST name when configuring the portlet.
Assign two host names	You can assign two host names to the server running both WebSphere Portal Server and WCM and use one host.name for WCM and the other when configuring the portlet. There are two ways of doing this: Assign two IP addresses to the WCM server and assign a different host.name to each IP. Assign two Host names to the same IP in a DNS.
Change the default cookie name	You could also change the default cookie name used by one of the servers: Log in to the WAS administrative console. Select Servers -> Application Servers -> WebSphere_Portal Select Web Container Settings -> Session management. Click on the "Enable Cookies" link. (Leave it checked.) Change the cookie name from JSESSIONID to JSESSIONID2. Click Apply and then Save the changes Restart WebSphere Portal.