ShowTable of Contents
RRP does not work; Can see authoring portlet when editing but no content
This situation usually occurs after an upgrade is performed, or a WCM cumulative iFix is applied, or when the RRP is being set up between servers and while editing in the RRP to access the backend server, you see the authoring portlet and the library but no content.
Typically, these issues mean that there is a code mismatch (.jar files mismatch) between the front-end RRP and the backend authoring server. The Troubleshooting Suggestions section in Document #1265164, “MustGather: Web Content Management Version 6.0 Remote Rendering Portlet,” states the following:
“Are the rendering server and the remote rendering servers at the same level with the same fixes installed? If not, try copying the remote rendering portlet from the rendering server to the remote rendering server, update the portlet using the portal administrative portlets, and retry the configuration."
A usual workaround is to deploy the RRP .war file from the backend server to the front-end server. This would usually resolve the issue. But the key assumption for this resolution is that the RRP code copied from the backend server matches the WCM code of the backend server. If this is not the case, this workaround will fail.
To ensure that this workaround is effective make sure that the following files in the RRP war file being deployed match the following files in the backend WCM authoring server:
<RRP.war>\web-inf\lib\ilwwcm-authoringportlet.jar == <profile>\installedApps\<node>\wcm.ear\ilwwcm.war\WEB-INF\lib\ilwwcm-authoringportlet.jar
<RRP.war>\web-inf\lib\ilwwcm-browserservlet.jar == <profile>\installedApps\<node>\wcm.ear\ilwwcm.war\WEB-INF\lib\\ilwwcm-browserservlet.jar
<RRP.war>\web-inf\lib\ilwwcm-api.jar == wcm\shared\app\ilwwcm-api.jar
<RRP.war>\web-inf\lib\ilwwcm-commons-properties.jar == wcm\shared\app\ilwwcm-commons-properties.jar
<RRP.war>\web-inf\lib\ilwwcm-commons-utils.jar == wcm\shared\app\ilwwcm-commons-utils.jar
<RRP.war>\web-inf\lib\ilwwcm-commons-version.jar == wcm\shared\app\ilwwcm-commons-version.jar
<RRP.war>\web-inf\lib\ilwwcm-commons-xmlpersistency.jar == wcm\shared\app\ilwwcm-commons-xmlpersistency.jar
<RRP.war>\web-inf\lib\ilwwcm-server.jar == wcm\shared\app\ilwwcm-server.jar
The files referred to above are for V6.0.X but the principle still applies even though the locations of the files/names may vary.
Typically the first two jar files mentioned: - ilwwcm-authoringportlet.jar and ilwwcm-browserservlet.jar are critical to the content not displaying. If for some reason any of the jar files do not match, - make sure of the following:
1. Review the Event.History file to ensure that all the fixes were installed correctly.
2. Review the ConfigTrace.log to ensure the config tasks associated with applying a fix such as update-wcm etc have been run.
In spite of all the checks listed above, sometimes the problem still persists. Here are some further troubleshooting steps and tips:
-- If you are working in a V184.108.40.206 environment, check for the following APAR fix: PK66094.
-- Check for the attribute, “WcmAuthoringConfigured = false”, in the Portal config properties file. This can cause the update-wcm task to succeed but not update the authoring portlet.
-- Another possibility is that the WCM servlet is being started on the remote rendering server before the remote rendering portlet starts. This loads classes at the incorrect level, thus resulting in mismatched versions of the classes being used.
-- Check to see if the WCM servlet has started. In the WebSphere Application Server console, navigate to Applications --> Enterprise Applications and find "wcm" in the list of applications. There should be a red "X" icon next to it indicating that it has stopped. If the WCM servlet has not stopped, click in the "wcm" application and then click Target Mappings. Identify each target where there is a green arrow (indicates running) in the displayed list. For each target, click the target, uncheck the "enabled" checkbox and click OK. Save the WebSphere Server configuration after you disable WCM in each target mapping where it was enabled. Restart the Portal server. After the Portal server is restarted, check the list of enterprise applications again in the WebSphere Server console to ensure that the "wcm" servlet has a red "X" icon next to it. Once the WCM servlet stops (assuming it was started in the first place), check the functionality of the remote rendering portlet and see if it is working correctly
RRP is not deployed by default.
Perform the following steps to install a remote rendering portlet:
1. Login to WebSphere Portal as an administrator.
2. Go to the Administration view and then Portlet Management.
3. Select Web Modules.
4. Click Install.
5. Click Browse.
6. Select the file named ilwwcm-remoterendering-portlet.war from the PortalServer_root\wcm\prereq.wcm\installableApps folder in your version 6.X server.
7. Click Open.
8. Click Next.
9. Click Finish.
You must then add the RRP (Remote Web Content Viewer) to a WebSphere Portal page.
Note: Some of the WCM cumulative ifixes may require the RRP to be redeployed after applying the fix. However, if the RRP was never installed on the server, this step is not needed. Since the fix updated the code in the installableApps folder and the .war file was never deployed, the expanded files do not exist in the installedApps directory.
Does the update-wcm task also update the RRP ?
The wpsconfig update-wcm task does not update the RRP. The update must be done manually because it is not included in the update-wcm task. This is by design since the portlet is not always installed, especially on the WCM server
If a WCM Portlet needs to be accessed by anonymous users, then you must configure the Portal server to have anonymous sessions by setting the public.session parameter to True.The following procedures allow sessions to be created for anonymous users. Active anonymous sessions will be managed according to the authentication method of the Web content viewer as described below.
1. Open the WebSphere Application Server administrative console on your remote server.
2. Go to Resources > Resource Environment Providers > WP_NavigatorService > Custom properties
3. Add a new property named "public.session" with a value of True.
Edit mode configuration
WebSphere Portal Administrators can deploy a single instance of the RRP onto a server. The settings for this portlet in configuration mode are then used by default each time the RRP is added to a page. Initially all the portlets will display the same content. The user can then use Edit mode to customize the configuration of each instance. So while all portlets share the same base configuration, each one can be customized as required.
Edit Shared Settings
This mode enables you to specify settings for all users of this instance of the rendering portlet. Changes you make in the Edit Shared Settings mode are not reflected in other instances of the rendering portlet.
This mode enables you to specify settings for all users of all instances of the rendering portlet, regardless of the page on which the portlet instance appears.
Note: Once the shared settings of a portlet have been edited, the default "Configure" mode settings will not be displayed on a page even if you edit them. To restore a portlet to its "Configure" mode, you must delete the portlet from the page and add it back.
Considerations when thinking of using RRP as content delivery option for WCM.
An RRP portlet should be considered when there is less volume of requests for the portlet's contents. RRP requires fewer Web Content Management licences, so for moderate usage contents, we can separate them out and deliver by RRP.
If the Web Content Management server is behind a firewall and you want to deliver content, you should user RRP, which can be configured if redirection is set up and the fully qualified URL is disabled.
RRP is preferred if you want to reduce the CPU load on the Web Content Management rendering server. (LRP can generate high CPU load on the Web Content Management server.)
When you use RRP on a remote server and you need to upgrade, it is not necessary to upgrade the remote WebSphere Portal server. You can upgrade the Web Content Management server only, and content can be delivered by use of RRP.
RRP should not be used to communicate to a local Web Content Management server. The RRP uses a URL connection to communicate with the Web Content Management server, and using it to talk to a local server causes an extra request thread being needed to service the original request. Under heavy loads, if all request threads are being used to serve “incoming” requests to the portlet, then the server will hang because each incoming request to the portlet cannot establish a “backend” request to Web Content Management. The network delay can cause performance issues with the RRP portlet.
Refer to this technote for more details:
Administration and configuration of a RRP is more complex compared to a LRP.
One can use the WCM API with RRP; however, make sure that JSP is on the Web Content Management servers when the request goes in.
Only published content can be displayed with a rendering portlet. Draft content cannot be displayed and cannot be selected when configuring a rendering portlet.
Restriction: Link elements cannot be displayed in remote rendering portlets.
Using the same server for pre-rendering and remote rendering.
This should work but only if the pre-renderer is NOT made the default rendering module. So instead of changing the module in the WCMConfigService.properties ( uncomment connect.businesslogic.module.default.class=com.aptrix.cacher.CacherModule) leave it unchanged to work for the RRP and then address the pre-renderer via a URL that contains the renderer module to use.
As described here in the IC:
Running the pre-renderer manually from the URL is the only way to accomplish the end result.
Support notes for RRP working with specific Portal versions:
1. The v6.1 Remote Rendering Portlet is additionally supported on a Portal 6.0 and 5.1.0.x instance
2. The v6.0 Remote Rendering Portlet is additionally supported on a Portal 5.1.0.x instance
3. This may be important if the delivery servers are running Portal applications which have to be rewritten and tested for a new Portal release
Note : Portal versions earlier than 5.1.0.x are not supported, and moreover will not work due to the difference in requirements for JRE levels
LTPA token setup for RRP
When using LTPA token forwarding in order to make authenticated request to a remote server, single sign-on (SSO) needs to be properly set up between these servers.
Check that the following settings are in place. Most of which can be done using the WebSphere Application Server Administrative Console.
Both servers are configured against the same security backend (e.g. LDAP server).
SSO is enabled on both servers.
The SSO domain name is set to a shared domain suffix on both servers (e.g. intranet.mycompany.com).
The timeout value for forwarded credentials between servers is set to a reasonably high value (e.g. 120 minutes).
The operating system clocks are reasonably in sync on both systems.
The LTPA keys from one server have been exported to a key file. The key file has been imported on the other server.
Quick Check to see if SSO is working:
Log on to the 1st server.
Enter a protected URL pointing to the 2nd server into the address bar of the same Web browser instance used in (a), e.g. http:www.mycompany.com:10040/wps/myportal. Please note that the URL addresses /myportal (protected) rather than /portal (public).
Submit the request to the 2nd server. => If SSO is properly set up, you will be automatically logged on to the 2nd server. If the SSO configuration requires some more tuning, you will have to authenticate manually, e.g. by entering your username and your password into the login form of the login portlet.
Note: For single sign on to be setup you need to have the same registry. This is documented in the WAS InfoCenter here:
Secure Socket Layer (SSL) and RRP
To enable the remote rendering portlet to switch from "http" to "https" when delivering secured content, enter the SSL url in the Web Content Management Server Host SSL field.The logic for the RRP to use http or https when creating URLs to resources is quite simple:
- If the incoming portlet request (to the RRP) is non-secure -> WCM server host setting is used
- If the incoming portlet request (to the RRP) is secure -> WCM server host SSL setting is used
For any SSL handshake error the WebSphere Application Server team needs to be engaged,
Session handling with the standard Web content viewer
When working with standard Web content viewers installed on remote servers, the default Web content session handling works by initiating a new Web content session for each Web content viewer instance on a page. This can cause performance issues if many users access a page containing a large number of remote Web content viewers.If you enable session handling to keep track of valid sessions between Web content viewer instances on a page this performance impact can be avoided.
Note: session handling is required to be enabled ONLY if you are using credential vault method of authentication. If you are using LTPA method of authenication then using session handling is not required as long as you have SSO enabled between the remote rendering server and the content server AND both the servers are pointing to the same LDAP server( you can still enable it if you want to but this would provide no performance gain)
The Portal V6.1 infocenter refers to how to enable the session handling here:
However the IC doesnot distinguish on the fact that if you are on v6.0.1.x CF23 and v6.1.x CF16 or above then you DONOT need to enable the WCM session service. This is more explicitly detailed in Sam Tannous's wiki article here:
Related to session handling the following are some key APARs:
PK85300: The issue of multiple sessions being created for multiple RRP instances on a page even when session handling was enabled was reported to happen only for anonymous users, This APAR covered the code defect where the session handling got disabled for anonymous users by the WCM session service. This APAR is included in v6.0.1.x CF23 and v6.1.x CF16 or above
PK70548: Separate session being used to access WCM by the RRP inspite of using LTPA mechanism This behavior is unexpected and incorrect. This APAR was found in V220.127.116.11 and has been included in V18.104.22.168/V6.0.15 CF 13 and V22.214.171.124 CF7 and V126.96.36.199 CF1. Also note that this APAR led to another issue associated with APAR PK81082. (PK70548 – included in 6014 CF2 and 6015 GA****)
PK81082: After applying PK70548, If an anonymous session exists then the LTPA token is not being added correctly therefore the user will see "You do not have the required access rights to view this content". This APAR was included in V188.8.131.52/V6.0.15 CF 13 and V184.108.40.206 CF7
Another troubleshooting technique to determine if the multiple RRP instances are using the same or different session ID for a user is to do the following:
In Portal go to "Administration -> Portal Analysis -> Enable Tracing" and add in "com.presence.connect.session.*=finest"
Go to the trace.log for that server, and when the RRP's are rendered it would report lines similar to below which show the sessionID for all
the RRPs on the page:
00000104 SessionMapper 3 SessionMapper:: registerSession - SessionId: K7g8fqa8WdB_zp5DwuBB1Ie
0000012d SessionMapper 3 SessionMapper:: registerSession - SessionId: K7g8fqa8WdB_zp5DwuBB1Ie
0000012d SessionMapper 3 SessionMapper:: registerSession - SessionId: K7g8fqa8WdB_zp5DwuBB1Ie
The same sessionIDs indicate that the portlets are using the same session.
Another possibility of the session handling not working inspite of all the correct fixes and configurations is the fact that Parallel Portlet rendering is enabled for the multiple RRPs instances on the page. Here is the Infocenter link that details on how to disable it if already set:
RRP Best practices
Configuring the remote rendering portlet to connect to a clustered Web Content Management URL
You may receive errors when using the remote rendering portlet to connect to a clustered Web Content Management URL. This occurs when the WebSphere Portal Server and the Web Content Management 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 Web Content Management server is accessed by the same host, the Portal Server cookie overwrites the Web Content Management cookie that maintains the session and vice versa. Logout is the result of losing a session.
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 You can use the IP address of the Web Content Management 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 Web Content Management and use one host name for Web Content Management and the other when configuring the portlet. There are two ways of doing this:
* Assign two IP addresses to the Web Content Management 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 WebSphere Application Server administrative console and go to:
-WebSphere Application Server 6.1: Servers > Application Servers > portal_server.
- WebSphere Application Server 7.0: Servers > Server Types > WebSphere application servers > portal_server.
* 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.
Using the Web 2.0 theme with a remote rendering portlet
To use the Web 2.0 theme with a remote rendering portlet you will need to 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. You will need to create a HTTP proxy for AJAX to allow the remote rendering portlet to render content in the Web 2.0 theme. See HTTP proxy for AJAX applications for further information.
Exporting remote rendering portlets
If the create-oids option is set to "true" when exporting portal pages containing remote rendering portlets, you will need to 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.
* 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 Web Content Management application can not be accessed behind a firewall. This is because Web Content Management 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 Web Content Management user so that the logon override does not work for anonymous users.
* If a Web Content Management 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.
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.
RRPs with credential vault authentication
When using remote rendering portlets that are configured to use content from remote WebSphere Portal servers, you must 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.
Useful technotes about RRP
Using a RRP to point to content on the local server instead of the Remote Rendering server
Users logged out using remote content viewer portlet with LTPA token in multi-realm WCM environment
Images do not display
New config Parameters introduced in RRP