Using WSRP with WebLogic Portal
WebLogic Portal 8.1 with service pack 4 supports interportlet communication (IPC) between Producers and Consumers. In other words, local portlets on a Consumer can react to events on a federated portlet from a Producer and vice versa; for example, minimizing a local portlet would change the contents of a remote portlet that was listening for a minimize event.
This document describes the IPC model used by WebLogic Portal and shows how to apply it to WSRP-compliant portlets. It includes information on the following subjects:
Note: For a list of supported portlets, please refer to WSRP Portlet Type Support in Introduction to WSRP.
Earlier versions of WebLogic Portal allowed you to establish interportlet communications by using such techniques are adding listenTo()
methods or backing files on page flow portlets. WebLogic Portal 8.1 with service pack 4 introduces a new IPC model based upon event handlers, Java objects that listen for predefined events on other portlets in the portal and fire actions when that event occurs.
Event handlers "listen" for events raised on subscribed portlets and fire an action when a specific event is detected. Event handlers can listen and react to the following types of events:
Event actions depend upon the type of event being raised. Except for portal events, all other events can be identified in the Events field on the Event Handler tool. Events available with the portal event handler are listed in Table 3-1.
Returns to its normal state from either a maximized or minimized state |
|
Event handlers fire an action on the host portlet when that handler detects an event from another portlet in the application; for example, when the user minimizes the appropriate portlet a portal event called onMinimize might cause the handler listening for it to fire an action that invokes a backing file attached to it.
Table 3-2 lists the event actions available.
Changes the window's mode from its current mode to a user-specified mode; for example, from help mode to edit mode. |
|
Changes the window's state from its current state to a user-specified state; for example, from maximized to delete state. |
|
Fires a user-defined custom event. This event needs to be included in the portlet file. |
|
Runs the backing file attached to the portlet. Backing files allow you to programatically add functionality to a portlet to enable preprocessing (for example, authentication) prior to rendering the portal controls. For more information, please refer to Special Considerations for Remote Portlets. |
The IPC Tool included in WebLogic Workshop makes implementing event handlers relatively easy. To launch the tool, do the following:
The tool will appear, as shown in Figure 3-1
The dialog box will expand, opening up additional fields you can use to set up the handler (Figure 3-2).
Figure 3-2 Expanded Event Handler Tool
The entire process of setting up an event handler can all be handled by using this tool. What you need to do is:
This section describes the process of setting up interportlet communications between a Consumer and a Producer by using the Event handler tool in BEA WebLogic Workshop. This is a simple example in which minimizing the local portlet on the Consumer will change the text string in the portlet federated from the Producer.
Note: Currently when a change is made to a producer's metadata, consumers are not notified of the change. For example, if you add an event handler to a portlet on the producer after you create a remote proxy to that portlet, the remote portlet is not made aware of the change: it will not fire the event. The correct procedure is to add the event handler to the portlet on the producer before you create the remote portlet on the consumer. This is a basic limitation of Web Services in general.
This exercise is comprised of four main steps:
In this step, you will create a domain, an enterprise application, and two web applications (web projects) under the enterprise application.
Note: In this exercise, the root directory for your domain should be BEA_HOME\user_projects\domains
; for the applications and all of their components, it's BEA_HOME\user_projects\applications
. These are default directories that are created when you install BEA WebLogic Platform.
To create a domain, do the following:
To create a portal applications, do the following:
config.xml
.When the application is successfully created, it will appear in the application panel, as shown in Figure 3-3.
Figure 3-3 Producer Portal Application Created
Create Producer and Consumer portal web applications (Projects) under the ipcWsrpTest portal application by doing the following:
producerWeb will now appear under the ipcWsrpTest application in the application tree (Figure 3-4).
Figure 3-4 Portal Web Application (Project) Added to the Producer
When the web applications are successfully created, they will appear under ipcWsrpTest in the Application panel, as shown in Figure 3-5.
Figure 3-5 Portal Web Applications (Projects) Added to the Portal Application
With the completion of Step 1: Set Up Your Environment, you have created a domain, a portal applications, and two portal web applications, producerWeb (the Producer) and consumerWeb (the Consumer). You can verify that these components exist by looking in your file system at BEA_HOME\user_projects\
, as shown in Figure 3-6.
Figure 3-6 File System Showing New Domain and Applications
In this step, you will create two JSP files on the Producer-side, along with the JSP portlets that will surface these files. You will also create a backing file that will contain the instructions necessary to complete the communication between two portlets (for more information on backing files, please refer to Understanding Backing Files) and add an event handler to one of the portlets. Once you have created the portlets and attached the backing file, you will test the application in your browser.
Note: Before continuing with this procedure, ensure that WebLogic Workshop is running and the producerWeb Web application node is expanded.
To create the JSP files the Producer portlets will surface, do the following:
The JSP file opens in Design View (Figure 3-7).
Figure 3-7 index.jsp in Design View
A box will appear around the text and an inner text field will appear in the Property Editor, under General (Figure 3-8).
Figure 3-8 Properties Menu inner Text Field
The dialog box closes and Minimize Me!!! appears in the inner text field and in the Design View, as shown in Figure 3-9.
Figure 3-9 New Text Added to the JSP File
aPortlet.jsp
in the Application tree and select Generate Portlet... from the context menu (Figure 3-10).Figure 3-10 Generating a Portlet from index.jsp
The Portal Details dialog box appears (Figure 3-11). Note that /aPortlet.jsp
appears in the Content URI field.
Figure 3-11 Portal Details Dialog Box for aPortlet
aPortlet.jsp
should still be open. If it isn't, double-click it in the application tree to reopen it.The JSP code appears (Figure 3-12).
Figure 3-12 JSP File Source View
<netui:html>
through </netui:html>
. This code displays event handling from the backing file that you will create and attach in a subsequent step.Listing 3-1 New JSP Code for bPortlet.jsp
<netui:html>
<% String event = (String)request.getAttribute("minimizeEvent");%>
<head>
<title>
Web Application Page
</title>
</head>
<body>
<p>
Listening for portlet A minimize event:<%=event%>
</p>
</body>
</netui:html>
The source should look like example in Figure 3-13.
Figure 3-13 Updated JSP Source
To create the backing file, do the following:
The folder backing
will appear under WEB-INF/src
, as shown in Figure 3-14.
Figure 3-14 backing Folder Under WEB-INF/src
The Source View of the new Java class appears (Figure 3-15).
Figure 3-15 Listening.java Source File
Listening.java
. Listing 3-2 Backing File Code for listening.java
package backing;
import com.bea.netuix.servlets.controls.content.backing.AbstractJspBacking;
import com.bea.netuix.events.Event;
import com.bea.netuix.events.GenericEvent;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class Listening extends AbstractJspBacking
{
private static boolean minimizeEventHandled = false;
public void handlePortalEvent(HttpServletRequest request,
HttpServletResponse response, Event event)
{
minimizeEventHandled = true;
}
public boolean preRender(HttpServletRequest request, HttpServletResponse
response)
{
if (minimizeEventHandled){
request.setAttribute("minimizeEvent","minimize event handled");
}else{
request.setAttribute("minimizeEvent",null);
}
// reset
minimizeEventHandled = false;
return true;
}
}
The source should now look like that shown in Figure 3-16.
Figure 3-16 Listening.java with Updated Backing File Code
Now you will attach the backing file created in Create the Backing File to bPortlet. Do the following:
backing.Listening
into the Backing File field, as shown in Figure 3-17 and press Tab.Figure 3-17 Attaching the Backing File in the Property Editor
You now add the event handler to bPortlet. This handler will be set up so that it will listen for an event on a specific portlet and fire an action in response to that event. To add the event handler, do the following:
Note: bPortlet.portlet
should be displayed in WebLogic Workshop. If it isn't, locate it under producerWeb in the application panel and double-click it.
The Event Handler dialog box appears (Figure 3-18).
Figure 3-18 Event Handler Dialog Box
The Event Handler dialog box expands to allow entry of more details (Figure 3-19).
Figure 3-19 Event Handler Dialog Box Expanded
The Open dialog box closes and Portal_1 appears in the Listen to: list and the Portlet field (Figure 3-20). Portal_1 is the definition label of the portlet to which the event handler will listen.
Figure 3-21 Event Drop-down List
Figure 3-22 Add Action Drop-down List
Invoke BackingFile Method appears on the Events list as a child to Handle Portal Event, as shown in Figure 3-23.
Figure 3-23 Event List with Action Added
handlePortalEvent
(Figure 3-24).Figure 3-24 Adding the Backing File Method
To test the application, do the following:
Note: Before you begin, ensure that all files are saved.
Figure 3-25 Portal Layout with Portlets Added
The portal will render in your browser (Figure 3-26).
Figure 3-26 ipcLocal Portal in Browser
In this step, you added to the portal application components created in Step 1: Set Up Your Environment two JSP portlets built on the Producer. One portlet, aPortlet, was fairly simple, while the second portlet, bPortlet, surfaced a more complex JSP file, leveraged a backing file, and contained a portal event handler. When you tested the Producer application, you observed how the two portlets communicated when an event occurred on aPortlet. This is called local interportlet communications.
In this step, you will create two portlets on the Consumer, one a JSP portlet and the other a remote portlet. As in Step 2: Create the Producer Portlets, the JSP portlet will surface the aPortlet.jsp
file while the remote portlet will consume bPortlet you created in Create the JSP Files and Portlets.
Before you continue with this exercise, do the following:
aPortlet.jsp
from:BEA_HOME \user_projects\applications\ipcWsrpTest\producerWeb
BEA_HOME
\user_projects\applications\ipcWsrpTest\consumerWeb
.
Note: This step is necessary to streamline this exercise and because WebLogic Workshop does not allow you to copy files between folders. If you don't want to copy aPortlet.jsp
from producerWeb to consumer Web, you can create it from scratch, as described in Create the JSP Files and Portlets.
To create a the JSP portlet, do the following:
The Portlet Details dialog box appears, with /aPortlet.jsp
already in the Content URI field (Figure 3-28).
Figure 3-28 Portlet Details Dialog Box
WebLogic Workshop refreshes and the new portlet layout appears, as shown in Figure 3-29.
To create the remote portlet, do the following:
The Portlet Wizard is launched, showing the Select Portlet Type dialog box (Figure 3-28).
Figure 3-30 Select Portlet Type Dialog Box
The Find Producer/Select Producer dialog box appears (Figure 3-31).
Figure 3-31 Find Producer/Select Producer Dialog Box
http://localhost:7001/producerWeb/producer?WSDL
The Register dialog box appears (Figure 3-32).
Figure 3-32 Register Dialog Box
The Select Portlet From List dialog box appears (Figure 3-33
Figure 3-33 Select Portlet From List Dialog Box
The remote portlet will be created and will appear as bprime.portlet
under consumerWeb in the Application panel.
Figure 3-34 Setting Render Cachable Property to False
With the completion of the two Consumer portlets, you have now created all of the necessary components to demonstrate interportlet communications between a remote and a local portlet. In the next step, you will add the Consumer portlets to a Consumer portal and raise an event on one portlet that will cause a reaction on the other.
In this step, you will test the Consumer application to verify that minimizing aPortlet will change the content of bPrime. You will create a portal and add the two portlets created in Step 3: Create the Consumer Portlets. You will then build the application and view the portal in a browser.
To create a portal for testing the application, do the following:
Note: Ensure all files are saved.
Figure 3-35 ipcConsumer Portal Layout
When the build completes, verify that an event on aPortlet can affect the content of bportlet by doing the following:
A browser opens displaying the ipcConsumer portal (Figure 3-36).
Figure 3-36 ipcConsumer Portal in a Browser
aPortlet minimizes and the contents of bPortlet changes, as shown in Figure 3-37.
Figure 3-37 ipsConsumer Portal in Browser After Minimize Event
If an event has one or more events that must be handled by the Producer (for example., netuix:invokePageFlowAction
, netuix:invokeStrutsAction
, netuix:invokeJavaPortletMethod
, and netuix:invokeBackingFileMethod
), the Producers adds a dispatchToRemotePortlet()
method. This element indicates that the Consumer must dispatch the event to the Producer.
The portal you created in Implementing IPC with WSRP: Example uses backing files to achieve communication between two portlets. Backing files allow you to programatically add functionality to a portlet by implementing (or extending) a Java class, which enables preprocessing (for example, authentication) prior to rendering the portal controls.
Backing files are simple Java classes that implement the com.bea.netuix.servlets.controls.content.backing.JspBacking interface or extend the com.bea.netuix.servlets.controls.content.backing.AbstractJspBacking interface
abstract class. The methods on the interface mimic the controls lifecycle methods (see How Backing Files are Executed) and are invoked at the same time the controls lifecycle methods are invoked.
At this time, the following controls support backing files:
All backing files are executed before and after the JSP is called. In its lifecycle, each backing file calls these methods:
On every request, the following occurs:
init()
methods are called on all backing files on an "in order" basis (that is, in the order they appear in the tree). This method gets called whether or not the control (that is, portal, page, book, or desktop) is on an active page. handlePostbackData()
methods are called. In other words if a portlet is on a page but its parent page is not active, then this method will not get called.A new instance of a backing file is created per request, so you don't have to worry about thread safety issues. New Java VMs are specially tuned for short-lived objects, so this is not the performance issues it once was in the past. Also, JspContent
controls support a special type of backing file that allows you to specify whether or not the backing file is thread safe. If this value is set to true
, only one instance of the backing file is created and shared across all requests.