| Oracle® Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal 10g Release 3 (10.3.6) E14235-07 |
|
|
View PDF |
| Oracle® Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal 10g Release 3 (10.3.6) E14235-07 |
|
|
View PDF |
This chapter discusses techniques and best practices for achieving WSRP interoperability between WebLogic Portal and Oracle WebCenter Portal and Oracle Portal.
This chapter includes the following sections:
This section describes the recommended technique for consuming WLP portlets in WebCenter Portal applications and Oracle Portal applications. In this scenario, WebLogic Portal is the producer and WebCenter Portal/Oracle Portal is the consumer, as illustrated in Figure 13-1.
Because of an incompatibility between the way WLP and WebCenter Portal/Oracle Portal implement certain WSRP operations, user authentication errors can occur. This section describes the nature of this incompatibility and the procedure for avoiding these errors.
This section includes these topics:
Figure 13-1 Consuming WLP Portlets in WebCenter Portal: Framework Applications
Note:
When consuming JSF portlets, ensure that JSP encoding is set to UTF-8.
An incompatibility exists between the way WebLogic Portal and WebCenter Portal/Oracle Portal implement the WSRP operations clonePortlet, destroyPortlets, importPortlets, and exportPortlets. Because of this incompatibility, you might encounter user authentication errors when trying to consume portlets from a WebLogic Portal producer in Framework applications or Oracle Portal applications.
Note:
For detailed information on the clonePortlet, destroyPortlets, importPortlets, and exportPortlets operations, refer to the Oasis Standard document Web Services for Remote Portlets Specification v2.0 at http://docs.oasis-open.org/wsrp/v2/wsrp-2.0-spec-os-01.html.
Specifically, JDeveloper makes unauthenticated operation calls at various points in the development lifecycle:
clonePortlet is called when dragging a portlet from a registered WebLogic Portal producer onto a JSF page or ADF task flow.
destroyPortlets is called when deleting a portlet from a JSF page or ADF task flow.
exportPortlets is called when exporting an application containing a WebLogic Portal remote portlet to an EAR, for deployment onto a production server.
importPortlets is called when deploying a previously-exported EAR onto a production server.
The compatibility problem arises because the WebLogic Portal producer requires that a user be authenticated when the clonePortlet, destroyPortlets, importPortlets, or exportPortlets operations are invoked, while the WebCenter Portal/Oracle Portal producer does not require user authentication for these methods.
To prevent user authentication errors when consuming WebLogic Portal portlets in a Framework application or Oracle Portal application, do the following:
In the WebLogic Portal producer application, create a new user to function as a surrogate for the WSRP operations listed in the previous section. This user should be in the Portal System Administrators group.
Copy the file WEB-INF/wsrp-producer-config.xml to your workspace and open it for editing. The procedure for copying files to your workspace is described in "Copying J2EE Library Files Into a Project" in the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.
Add the following security element attribute to the wsrp-producer-config.xml file. This element must be the last element in the <wsrp-producer-config> element (place it just above the closing </wsrp-producer-config> line):
<security anonymousCloneDestroyUser="username"/>
where username is the name of the user that you created.
Save your changes, and republish your web project.
With this configuration, the WebLogic Portal producer server automatically authenticates the specified user when unauthenticated operation calls to the four WSRP operations (described in the previous section) are received. This automatic authentication only occurs for these four operations. Also, this automatic authentication works only for complex producers.
This section discusses techniques and best practices for consuming WebCenter Portal portlets in a WebLogic Portal application. In this scenario, WebLogic Portal is the consumer and WebCenter Portal/Oracle Portal is the producer, as illustrated in Figure 13-2. Topics in this section include:
Section 13.2.2, "Configuring for Partial Page Refresh Over WSRP"
Section 13.2.3, "Configuring Portlets That Use ADF Faces Rich Client Components"
Section 13.2.4, "Consuming WebCenter Portal Service Portlets"
Figure 13-2 Consuming WLP Portlets in WebCenter Portal Applications
A WebCenter Portal producer and a WebLogic Portal consumer have the same cookie-name and path information configured by default. Some resource requests from the consumer to the producer will cause the producer's cookie name and value to be set on the client (the browser). When this occurs, it has the effect of overriding the value set by the consumer. This situation puts the client-consumer-producer interactions into this cycle:
Consumer server sets the cookie value on the client (browser).
Client (browser) sends the consumer's cookie value to the producer.
The producer doesn't recognize the value, and sends the client a new cookie value.
The client sends the producer's cookie value to the consumer.
The consumer doesn't recognize the value, and sends the client a new cookie value and so on.
Because session state is usually persisted based on the cookie value, this constant change in cookie values causes session state to be lost on both the producer and consumer.
Fortunately, there are several easy ways to correct this situation. These techniques include using different cookie names, using a system property, and blocking cookies. For details, see Section 14.15, "Configuring Session Cookies" in Chapter 14, "Other Topics and Best Practices."
Certain ADF Faces Rich Client components make use of "Partial Page Refresh" JavaScript to update the page without reloading it completely. In some circumstances this does not work properly over WSRP due to improperly encoded ampersand characters. To fix this, add the following line to the consumer's WEB-INF/wlp-framework-common-config.xml file, just before the </wlp-framework-common-config> tag:
<ignore-wsrp-ampersand-encoding-extension default="true"/>
Tip:
The easiest way to edit this file is to copy it to your Eclipse workspace. To do this, locate the file in the Merged Projects view. Right-click the file and select Copy to Workspace.
To consume portlets that use Oracle ADF Faces Rich Client Components in a WLP consumer, you must perform the following configuration tasks on the WLP consumer. The steps include:
Section 13.2.3.2, "Disabling html-amp-entity in WEB-INF/wlp-framework-common-config.xml"
Section 13.2.3.4, "Setting a Fixed Height on the Portlet's Contents (Optional)"
For information on Oracle ADF Faces Rich Client Components, see http://www.oracle.com/technology/products/adf/adffaces/index.html.
ADF Faces Rich Client portlets contain base-level HTML tags (like HTML, HEAD, BODY, and BASE) that WebLogic Portal already provides in a rendered portal page. Having such tags appear multiple times in HTML can result in the misbehavior of JavaScript on the page, among other things. To avoid these problems, render the contents of these portlets inside an IFRAME element.
To render an ADF Faces Rich Client portlet in an IFRAME, the portlet property Async Content Rendering must be set to iframe_unwrapped. The iframe_unwrapped setting renders the body of the remote portlet, "unwrapped" from any HTML artifacts that the WebLogic Portal framework would provide (for instance, skeleton artifacts such as HTML, HEAD, BODY, and other tags). For more information on the Async Content Rendering property, see "Asynchronous Portlet Rendering" in the Oracle Fusion Middleware Portlet Development Guide for Oracle WebLogic Portal. For information on skeletons, see "What is a Skeleton" in the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.
Certain ADF Faces Rich Client components make use of JavaScript to handle the display of images, such as changing a button image when it is rolled-over. An example of such a case might look like this, as served by the producer:
<script type="text/javascript">
...
var hoverIcon = 'wsrp_rewrite?wsrp-urlType=resource&wsrp-url=http%3A%2F%2Fhost.com%3A8899%2Fproducer%2Fadf%2Fwebcenter%2Fattributegroup_ovr.png&wsrp-requiresRewrite=false&wsrp-extensions=oracle%3Astateless-resource%3Dtrue/wsrp_rewrite';
...
</script>
The WebLogic Portal consumer is responsible for converting the information between the wsrp_rewrite? and /wsrp_rewrite tokens into a valid URL for that resource. When a URL like this one is a value for markup attributes, any ampersand characters within it should be encoded as &, according to markup validation rules. However, when the URL is to be used inside of non-markup content, such as JavaScript and CSS, it should explicitly not be encoded as &. Doing so causes the request to the server to send parameter names like amp;_nfpb instead of _nfpb, which typically results in an unintended or unexpected response from the server. For information on markup validation rules, see http://www.htmlhelp.com/tools/validator/problems.html#amp.
The WebLogic Portal URL framework performs ampersand entity encoding on all URLs in the text/* markup type by default. For interoperability with ADF Faces Rich Client portlets produced by the WebCenter Portal, this default setting should be changed. To do so:
Copy WEB-INF/wlp-framework-common-config.xml into your project, and open it for editing.
Change the value of the html-amp-entity element to false.
Save your changes, and republish your web project.
The Oracle WSRP Consumer sends a custom WSRP extension to the WebCenter Portal producer, which tells the producer what ADF Faces skin is currently applied on the consumer. The WebCenter Portal producer uses this information to return a matching CSS stylesheet for the portlet being requested. The WebLogic Portal consumer does not currently support this custom WebCenter Portal WSRP extension, and so every portlet returned from a WebCenter Portal producer will be styled with the "portlet" version of the default skin (for example, blafplus-rich.portlet). If you would like to style a portlet consumed in WebLogic Portal based on a specific ADF Faces skin, follow these steps:
On the WebCenter Portal producer, open the WEB-INF/portlet.xml file for editing.
Find the <portlet> element for the portlet to which to apply the skin.
Add the following <init-param> element, underneath the <portlet-class> element:
<init-param>
<name>org.apache.myfaces.trinidad.skin.id</name>
<value>blafplus-rich.desktop</value>
</init-param>
where blafplus-rich.desktop is the ID of the specific skin to be applied to this portlet, when a consumer does not use the Oracle-specific WSRP extension to specify a skin.
Redeploy your portlet producer application.
The WebLogic Portal framework attempts to resize a portlet's IFRAME to match the height of the rendered contents within it. However, certain ADF Faces Rich Client components also attempt to resize themselves according to the size of the surrounding window or frame. This leads to a scenario where the initial size of the contents of the IFRAME are based on the initial size of the IFRAME itself, before any client-side dynamic resizing has occurred.
In these cases, you may prefer to set a fixed height for the contents of your portlet. To do so:
In WebLogic Workshop, right-click your .portlet file and select Open With > XML Editor.
On the <netuix:proxyPortletContent> element, add the presentationStyle attribute, with a value similar to min-height: nnnpx;, where nnn is the desired pixel height of your portlet's body. For example:
<netuix:proxyPortletContent presentationStyle="min-height: 600px;"/>
Save your changes, and republish your web project.
For service portlets, the WebCenter Portal producer sends a WSRP URL extension parameter, which is used for URL rewriting, to the WSRP consumer. If you encounter the problem that popups are not appearing in service portlets, configure wlp-framework-common-config.xml to ignore the WSRP URL extension parameter, oracle:escape-xml. To do so:
Open WEB-INF/wlp-framework-common-config.xml.
Add the following entry:
<ignore-wsrp-ampersand-encoding-extension default="true"/>
This entry must be added as the last entry before the closing </wlp-framework-common-config> element in the configuration file.
Save your changes, and republish your web project.
For information on configuring security between WebLogic Portal and WebCenter Portal, see Chapter 17, "Configuring WSRP Security Between WLP and a WebCenter Portal: Framework Application." That chapter describes one technique for establishing a secure communications channel for WSRP transactions between WLP and WebCenter Portal.
This section shows by example how to configure interoperability of navigational parameters through WSRP.
The sample tasks described in this section are:
WLP and WebCenter Portal Java portlets are able to share parameters over WSRP. WebCenter Portal calls these shared parameters "public render parameters", while WLP calls them "shared parameters", and the JSR286 specification calls them "public parameters". As long as the configured QNames for these parameters match, they will automatically be shared between portlets consumed over WSRP.
For detailed information, see "Using Shared Parameters" in Oracle Fusion Middleware Portlet Development Guide for Oracle WebLogic Portal, and "How to Use Public Render Parameters" in Oracle Fusion Middleware Developer's Guide for Oracle WebCenter.
In Workshop for WebLogic, register a WebCenter Portal producer application.
In Workshop, create a remote portlet consuming a portlet in the WebCenter Portal producer.
Create a backing file for the portlet with an onInit method. In this method, set param to the shared parameter name and default_param_value to the initial value you would like to set.
Open the .portlet file with the XML editor and add the following as the last attribute of netuix:proxyPortlet.
backingFile="com.bea.wsrp.qa.SetSharedParamsBacking"
Add this element after the netuix:proxyPortlet element, where shared_param_name is the name of the shared navigational parameter that the WebCenter Portal portlet requires.
Example 13-1 Backing File onInit() Method
public void onInit(HttpServletRequest request, HttpServletResponse response, Event event) {
PortletBackingContext portletBackingContext =
PortletBackingContext.getPortletBackingContext(request);
String foo = portletBackingContext.getSharedParameterValue("param");
if (foo == null || foo.length() == 0) {
portletBackingContext.setSharedParameterValue("param", "default_param_value");
}
}
Example 13-2 Element Added to .portlet File
<netuix:handlePortalEvent event="onInit" eventLabel="handlePortalEvent1"
fromSelfInstanceOnly="false" onlyIfDisplayed="true">
<netuix:invokeBackingFileMethod method="onInit"/>
</netuix:handlePortalEvent>
<netuix:sharedParameter paramId="shared_param_name" qname="shared_param_name"/>
This section describes additional issues to consider with respect to WLP and WebCenter Portal interoperability.
Portlets using WebLogic Portal's IFRAME feature are unable to respond to public NavigationalContext changes. Therefore, if you want to share data between portlets across WebCenter Portal and WebLogic Portal containers, consider setting attributes in the HttpSession. For further information on this topic, see the WebLogic Server Session topic "Using Sessions and Session Persistence" in Oracle Fusion Middleware Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server. For information on event distribution and the NavigationalContext type, refer to the Oasis Standard document Web Services for Remote Portlets Specification v2.0 at http://docs.oasis-open.org/wsrp/v2/wsrp-2.0-spec-os-01.html.
Note:
Be aware that when you use HttpSession to share data, you create a dependency between portlets, which is not generally considered to be a best practice. See Section 14.2, "Avoid Interportlet Dependencies."
Even when using HttpSession attributes to share data across portlets, those inside of IFRAMEs will be isolated from the notification of the change. A reload of the entire portal page is required, so that all of the portlets residing in IFRAMEs can update their contents with the new HttpSession attribute information. To facilitate this programatically, consider using a WSRP interceptor. In the interceptor shown in Example 13-3, the responses from POST requests to a WebCenter Portal producer are being changed to force the browser's outermost window to reload itself. See also Chapter 9, "The Interceptor Framework."
Example 13-3 Interceptor to Force Reload of a Parent Frame
package com.oracle.wlp.wsrp;
import java.io.ByteArrayInputStream;
import java.io.UnsupportedEncodingException;
import com.bea.wsrp.consumer.interceptor.IGetMarkupInterceptor;
import com.bea.wsrp.consumer.interceptor.Status;
import com.bea.wsrp.consumer.interceptor.Status.OnFault;
import com.bea.wsrp.consumer.interceptor.Status.OnIOFailure;
import com.bea.wsrp.consumer.interceptor.Status.PostInvoke;
import com.bea.wsrp.consumer.interceptor.Status.PreInvoke;
import com.bea.wsrp.model.markup.IGetMarkupRequestContext;
import com.bea.wsrp.model.markup.IGetMarkupResponseContext;
public class ReloadInterceptor implements IGetMarkupInterceptor {
// A very simple piece of HTML markup that, via JavaScript, will cause
// the parent frame to reload. Tested in IE7 and FF3.
private static final String RELOAD_MARKUP =
"<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\" \"http://www.w3.org/TR/html4/loose.dtd\"><html><head><script type=\"text/javascript\">window.parent.location.reload(true);</script></head><body></body></html>";
@Override
public PostInvoke postInvoke(IGetMarkupRequestContext request, IGetMarkupResponseContext response) {
// Do something here to determine if you'd like to reload the parent frame.
// In this example, we're forcing a reload of the parent frame if this request
// was of type "POST".
if (request.getRequestVerb().equalsIgnoreCase("POST")) {
try {
// Completely replace the response markup with our simple "reload" HTML markup.
response.setMarkupData(new ByteArrayInputStream(RELOAD_MARKUP.getBytes("UTF-8")));
// Abort the interceptor chain, as we don't want any other interceptors
// to undo what we've just done. This is ok, as a subsequent GET request
// will soon follow, as the parent frame is reloaded.
return Status.PostInvoke.ABORT_CHAIN;
} catch (UnsupportedEncodingException e) {
// Ignore, as in this case the encoding will always be valid.
}
}
return Status.PostInvoke.CONTINUE_CHAIN;
}
@Override
public PreInvoke preInvoke(IGetMarkupRequestContext request) {
return Status.PreInvoke.CONTINUE_CHAIN;
}
@Override
public OnFault onFault(IGetMarkupRequestContext request, IGetMarkupResponseContext response, Throwable t) {
return Status.OnFault.CONTINUE_CHAIN;
}
@Override
public OnIOFailure onIOFailure(IGetMarkupRequestContext request, IGetMarkupResponseContext response, Throwable t) {
return Status.OnIOFailure.CONTINUE_CHAIN;
}
}
If you want to consume Oracle ADF Faces Rich Client Component Portlets in WLP, you must use WebLogic Workshop. The WebLogic Portal Administration Console does not currently support the portlet configuration required for consuming Oracle ADF Faces Rich Client Component portlets.
For information on Oracle ADF Faces Rich Client Components, see http://www.oracle.com/technology/products/adf/adffaces/index.html. For information on using the WLP Administration Console, see the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.
|
 Copyright © 2010, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|