Federated Portals Guide

WSRP Interoperability With WebCenter Framework

This chapter discusses techniques and best practices for achieving WSRP interoperability between WebLogic Portal and WebCenter Framework.

This chapter includes the following sections:

Installing the Patch Set

Several enhancements have been made to WebLogic Portal 10gR3 and WebLogic Server 10gR3 to support WSRP interoperability with WebCenter Framework. These enhancements include:

To use these new interoperability features in WLP 10.3, you must install the patch sets listed in Table 14-1.

For detailed information on obtaining and installing these patches, see Downloading and Applying Patches in Oracle Smart Update Installing Patches and Maintenance Packs.

Consuming WLP Portlets in WebCenter Framework and Oracle Portal Applications

This section includes these topics:

Introduction

The following sections describe the recommended technique for consuming WLP portlets in WebCenter Framework and Oracle Portal applications. In the scenario addressed in these sections, WebLogic Portal is the producer and WebCenter Framework/Oracle Portal is the consumer, as illustrated in Figure 14-1.

Because of an incompatibility between the way WLP and WebCenter Framework/Oracle Portal implement certain WSRP operations, user authentication errors can occur. The following sections describe the nature of this incompatibility and the procedure for avoiding these errors.

Understanding the Cause of User Authentication Errors

An incompatibility exists between the way WebLogic Portal and WebCenter Framework/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 WebCenter Framework or Oracle Portal applications.

Specifically, JDeveloper makes unauthenticated operation calls at various points in the development lifecycle:

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 Framework/Oracle Portal producer does not require user authentication for these methods.

Preventing User Authentication Errors

To prevent user authentication errors when consuming WebLogic Portal portlets in a WebCenter Framework or Oracle Portal application, do the following:

With this configuration, the WebLogic Portal producer server automatically authenticates the specified user when unauthenticated operation calls to the four WSRP operations clonePortlet, destroyPortlets, importPortlets, or exportPortlets are received. This automatic authentication only occurs for these four operations.

Consuming WebCenter Framework Portlets in WebLogic Portal

This section discusses techniques and best practices for consuming WebCenter Framework portlets in a WebLogic Portal application. In this scenario, WebLogic Portal is the consumer and WebCenter Framework is the producer, as illustrated in Figure 14-2. Topics in this section include:

Avoiding Cookie Collisions

A WebCenter Framework 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, which results in the loss of session state:

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 Configuring Session Cookies.

Configuring Portlets That Use ADF Faces Rich Client Components

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 tasks, described in this section, include:

For information on Oracle ADF Faces Rich Client Components, see http://www.oracle.com/technology/products/adf/adffaces/index.html.

Use iframe_unwrapped

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, in WLP set the portlet property Async Content Rendering 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 Content 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.

Disable html-amp-entity in WEB-INF/wlp-framework-common-config.xml

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 standard 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.

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 Framework, this default setting should be changed. To do so:

Use CSS Styling (Optional)

The WebCenter Framework WSRP consumer sends a custom WSRP extension to the WebCenter Framework producer, which tells the producer which ADF Faces skin is currently applied on the consumer. The WebCenter Framework 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 Framework WSRP extension, and so every portlet returned from a WebCenter Framework producer will be styled with the "portlet" version of the default skin (for example, blafplus-rich.portlet). If you want to style a portlet consumed in WebLogic Portal based on a specific ADF Faces skin, follow these steps:

Set a Fixed Height on the Portlet's Contents (Optional)

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:

Configuring Security

For information on configuring security between WebLogic Portal and WebCenter Framework, see Configuring WSRP Security Between WLP and WebCenter Framework. That chapter describes one technique for establishing a secure communications channel for WSRP transactions between WLP and WebCenter Framework. For more information on security configurations, see the WebLogic Server document “Securing WebLogic Server Services.”

Interportlet Communication Considerations

WebCenter Framework 11gR1 does not currently support WSRP event distribution. Additionally, portlets using WebLogic Portal’s IFRAME feature are unable to respond to public NavigationalContext changes (see also Use iframe_unwrapped). Therefore, if you want to share data between portlets across WebCenter Framework 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.

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 Listing 14-1, the responses from POST requests to a WebCenter Framework producer are being changed to force the browser's outermost window to reload itself. See also The Interceptor Framework.

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;
    }
}

Consuming Oracle ADF Faces Rich Client Component Portlets

If you want to consme 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.