February 26, 2021
Hot Topics:

Portal Federation with WebLogic Portal WRSP: Advanced IPC Techniques

  • By Scott Nelson
  • Send Email »
  • More Articles »

Managing Session Size

In Part 2 of this series, you created a session object to share data between your remote portlets running on the WebLogic Portal (WLP). Objects in the session are useful when you will need them for an extended period of time; otherwise, you would have to annoy the user repeatedly for the same information. As portals (or any web-based application) grow in size and complexity, it quickly becomes an effort to achieve acceptable performance. One way to improve performance is by keeping the session small, with only the objects that are necessary stored there. This is the time to check your session objects and ask yourself "do I really need this in the session?" Portals that use WSRP can fill the session quickly when objects are placed in session just to share them when they are only used on a request level. Because of your need for speed, take a look at how to orchestrate the way you share your objects using the session just long enough to achieve communication.

The WebLogic Portal includes an Event framework that is ideal for inter-portlet communication (IPC) because it provides APIs to handle such communications in a loosely coupled fashion. For example, say that a user enters a value in portlet A and, on submission, portlet B needs to get that value for the purpose of a single update. Although in the example from Part 2, you used a session object to store the value, this time you will follow the WebLogic best practice of utilizing the Event framework for IPC. Start by firing a custom event in portlet A and then attaching your value to the Event:

public Forward ipcDemoCall1(IpcDemo1FormBean form)
   Forward                   forward          = null;
   PortletBackingContext     context          = null;
   HttpServletRequest        outerRequest     = null;

   forward          = new Forward("success");
   outerRequest     = ScopedServletUtils.getOuterRequest
   context          = PortletBackingContext.

   context.fireCustomEvent("loadIpcPortletB", form);
   return forward;

Next, you will have portlet B listen for your custom event:

<netuix:handleEvent event="loadIpcPortletB"
   fromSelfInstanceOnly="false" onlyIfDisplayed="false"

The values above represent the custom event fired from portlet A, an event label that must be unique to avoid headaches. The two "false" values allow you to listen for the event from other portlets no matter where the listening portlet is displayed, and to listen for this event from any portlet (more on the usefulness of this later).

.portlet files are far easier to configure reliably using the portal IDE (Workshop or Workspace Studio, depending on the WLP version) and the portlet property editor in the Portal perspective. In this article, you have looked at the actual XML both to improve understanding and because it would take way too many screen shots to illustrate the full flow. The values in the XML example above combined with the intuitive Workshop/WorkSpace portal development interface should get you through doing this the easy way.

Were you not using WSRP, the payload parameter of fireCustomEvent (getRequest().getParameter(IPC_VALUE));) would be readily available to the listening portlet. In a WSRP scenario, the firing portlet (A) does not share the same request object as the listening portlet (B), so you need to add a backing file to portlet B that has access to both the Event and the session:

package article.examples.portal.util.wsrp.backing;

import com.bea.netuix.servlets.controls.content.backing.
import com.bea.netuix.servlets.controls.portlet.backing.
import org.apache.beehive.netui.pageflow.scoping.
import com.bea.netuix.events.Event;
import com.bea.netuix.events.CustomEvent;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;

public class IpcEventHandler extends AbstractJspBacking
   static final long serialVersionUID=1L;
   public static final String IPC_DATA = ".data";
   public void handlePayloadEvent(HttpServletRequest request,
      HttpServletResponse response, Event event)
      CustomEvent customEvent                = null;
      HttpServletRequest        outerRequest = null;
      HttpSession               outerSession = null;
      Object                    payLoad      = null;
      PortletBackingContext     pbc          = null;
      String                    payLoadId    = null;

      customEvent      = (CustomEvent)event;
      outerRequest     = ScopedServletUtils.getOuterRequest
      outerSession     = outerRequest.getSession();
      pbc              = PortletBackingContext.

         payLoad       = customEvent.getPayload();
         payLoadId     = pbc.getInstanceId()+IPC_DATA;
         outerSession.setAttribute(payLoadId, payLoad);

This works because the event framework has access to requests from portlet A even though portlet B does not. To help out the portlet, your backing file takes the event payload and places it in the session. This is done using the portlet ID as part of the session key so that this backing file can be reused in any portlet, even by multiple instances of the same portlet.

Admittedly, portlet A could simply have put the value into the session, although doing so would create a tighter coupling between the two portlets. Also, portlet A would put the value in the session regardless of whether there were a portlet that needed it, which would defeat your goal of managing the session.

Once portlet B accesses the data from the session, it can store it in its local scope and safely remove it from the session by calling removeAttribute() on the session.

Page 1 of 3

This article was originally published on May 28, 2008

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date