| Oracle® Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal 10g Release 3 (10.3.4) Part Number E14235-05 |
|
|
View PDF |
| Oracle® Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal 10g Release 3 (10.3.4) Part Number E14235-05 |
|
|
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
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.
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:
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."
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.2.2, "Disabling html-amp-entity in WEB-INF/wlp-framework-common-config.xml"
Section 13.2.2.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:proxyPortlet> 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 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.
The WebCenter JSR 168 implementation provides the user the ability to specify navigational parameters for JSR 168 portlets in the oracle-portlet.xml file. The WebLogic Portal JSR 286 implementation also supports navigational parameters. This section shows by example how to configure interoperability of navigational parameters through WSRP.
The sample tasks described in this section are:
Assume that you have a WLP web application containing JSR 286 portlets. To configure the application to use navigational parameters with WebCenter JSR 186 portlets, you need to add an oracle-portlet.xml file to your web application's WEB-INF folder. Example 13-1 shows a sample oracle-portlet.xml file. Note that the file refers to two portlets, ParameterForm and ReadOnlyParameterForm. It is assumed that these to portlets are Java portlets that were created previously in the web application. The <navigation-parameters> elements configure the parameters that will be shared.
Example 13-1 Example oracle-portlet.xml File
<?xml version="1.0" encoding="ISO-8859-1"?>
<portlet-app-extension
xmlns="http://xmlns.oracle.com/portlet/oracle-portlet-app"
version="1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<portlet-extension>
<portlet-name>ParameterForm</portlet-name>
<navigation-parameters>
<name>parameter1</name>
<type>xsd:string</type>
<label xml:lang="en">First parameter</label>
<hint xml:lang="en">First parameter set by portlet</hint>
</navigation-parameters>
<navigation-parameters>
<name>parameter2</name>
<type>xsd:string</type>
<label xml:lang="en">Second parameter</label>
<hint xml:lang="en">Second parameter set by portlet</hint>
</navigation-parameters>
<navigation-parameters>
<name>parameter3</name>
<type>xsd:string</type>
<label xml:lang="en">Third parameter</label>
<hint xml:lang="en">Third parameter set by portlet</hint>
</navigation-parameters>
<portlet-id>1</portlet-id>
<allow-export>true</allow-export>
<allow-import>true</allow-import>
<minimum-wsrp-version>2</minimum-wsrp-version>
</portlet-extension>
<portlet-extension>
<portlet-name>ReadOnlyParameterForm</portlet-name>
<navigation-parameters>
<name>parameter1</name>
<type>xsd:string</type>
<label xml:lang="en">First parameter</label>
<hint xml:lang="en">First parameter set by portlet</hint>
</navigation-parameters>
<navigation-parameters>
<name>parameter2</name>
<type>xsd:string</type>
<label xml:lang="en">Second parameter</label>
<hint xml:lang="en">Second parameter set by portlet</hint>
</navigation-parameters>
<navigation-parameters>
<name>parameter3</name>
<type>xsd:string</type>
<label xml:lang="en">Third parameter</label>
<hint xml:lang="en">Third parameter set by portlet</hint>
</navigation-parameters>
<portlet-id>2</portlet-id>
<allow-export>true</allow-export>
<allow-import>true</allow-import>
<minimum-wsrp-version>2</minimum-wsrp-version>
</portlet-extension>
</portlet-app-extension>
To configure a Framework application to use the navigational parameters configured in the WLP application through WSRP, follow these basic steps:
Create a Portlet Producer Application in JDev.
Create Java portlets in the web application.
Add the same oracle-portlet.xml file that you added to the WLP application to the application's WEB-INF folder.
Start the WebCenter Portal producer web application.
This section explains how to consume the Java portlets offered by both the WLP and WebCenter Portal producers configured in the previous two sections. The key point about this example is that WLP and WebCenter Portal Java portlets are able to share navigational parameters over WSRP.
Create a new Framework application in JDev. This application is the consumer.
Create a new JSF .jspx page in the Web Content folder.
Create a new WSRP Producer under Application Resources/Connections.
Register the WebCenter Portal Producer created in the previous section, Section 13.4.2, "Configuring the WebCenter Portal Producer."
Create another new WSRP Producer.
Register the WLP Producer created in the previous section, Section 13.4.1, "Configuring the WLP Producer."
Add the ParameterForm portlet from the WebCenter Portal Producer to the .jspx page. (What does this mean, consume it over WSRP?)
Add the ReadOnlyParameterForm portlet from the WLP producer to the .jspx page.
Right-click the .jspx page and click on Go to Page Definition.
Open the Source tab of PageDef.xml.
Copy the values of the parameter pageVariable from the ParameterForm portlet entry to the values of the parameter pageVariables for the ReadOnlyParameterForm portlet (make sure to match param 1 to param 1, param 2 to param2 and param3 to param3).
Make note of the name of the ParameterForm portlet.
In the .jspx page in the JDev editor, click the ReadOnlyParameterForm portlet.
In the Property Inspector for the portlet, enter the name of the ParameterForm portlet that you noted previously in the Partial Triggers field.
Run the .jspx page.
Enter values in the parameter fields of the ParameterForm portlet and click OK. The values are reflected in the ReadOnlyParameterForm portlet.
This example illustrated how to configure Java portlets in a Framework application and WLP to communicate through navigational parameters across WSRP. Other possible scenarios include consuming both portlets from the WebCenter Portal producer, consuming both portlets from the WLP producer, or consuming the ParameterForm portlet from WLP and the ReadOnlyParameterForm portlet from the Framework application.
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-2 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-3 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.
WebCenter Portal 11gR1 does not currently support WSRP event distribution. Additionally, 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-4, 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-4 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, 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|