WebLogic Portal supports interportlet communication (IPC) between producers and consumers. For example, a remote portlet deployed in a producer application can handle a minimize event fired by a local portlet in a consumer. This chapter presents a detailed example explaining how to use interportlet communication with remote portlets.
This chapter includes these sections:
WebLogic Portal provides an extension to the WSRP protocol that allows remote portlets to fire events during the interaction phase of their lifecycle. For detailed information on the WebLogic Portal IPC architecture for federated portlets, see Interportlet Communication with Events.
Communication between portlets deployed in consumer and producer applications is bi-directional. Events fired by local portlets can be handled by portlets deployed in a producer, and vice versa.
The example in this chapter demonstrates one way to implement event handling in a federated portal. In this example, the event handler is added to the portlet on the producer. When a local portlet on the consumer fires an event, the remote portlet on the producer receives the event and handles it (changes the text displayed in the portlet).
Note: | Whenever you implement event handling in a federated environment, remember that you must add event handlers to portlets in the producer application before you create proxy portlets in consumers. If you change a producer portlet’s metadata, such as by adding an event handler, consumers are not notified of that change. The correct procedure is to add the event handler to the portlet on the producer before you create the remote portlet on the consumer. |
For additional information on IPC in WebLogic Portal, see the Portlet Development Guide.
This section presents a detailed example demonstrating how to use event handling in a remote portlet. In this example, a remote portlet on the consumer fires an onMinimize event. The onMinimize event is fired when a portlet is minimized. When the event is fired from a local portlet in a consumer, the event is handled on the producer. The onMinimize event is one of several standard events supported by the WebLogic Portal framework. For a complete list of standard events, see the Portlet Development Guide.
In this example, when the user minimizes the remote portlet on the consumer, the producer handles the event and changes some text in the portlet.
Tip: | Remote portlets can also handle custom events. For detailed information on using custom events with remote portlets, see Data Transfer with Custom Events. |
This example includes these steps:
If you want to try the example discussed in this section, you need to run Workshop for WebLogic and perform the prerequisite tasks and set up the example environment.
To set up the example environment, perform the prerequisite tasks outlined in Table 7-1. If you are not familiar with the specific procedures for these tasks, they are described in detail in the WebLogic Portal tutorial “Setting Up Your Portal Development Environment.”
Figure 7-1 shows the Package Explorer after the prerequisite tasks have been completed.
In this task, you create two JSP files on the producer-side, along with the JSP portlets that surface these files. You also create a backing file that contains the instructions necessary to complete the communication between two portlets 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.
To create the JSP files that the portlets deployed on the producer will surface:
Minimize Me!
, as shown in Figure 7-2. aPortlet.jsp
.aPortlet.jsp
in the Package Explorer and select Generate Portlet....
The Portal Details dialog box appears (Figure 7-3). Note that /aPortlet.jsp
appears in the Content URI field.
The file aPortlet.portlet
appears in the producerWeb/WebContent folder in the Package Explorer.
aPortlet.jsp
, and call the copy bPortlet.jsp
. bPortlet.jsp
in the editor and copy the code from Listing 7-1 into the JSP, replacing everything from <netui:html>
through </netui:html>
. This code simply displays text placed in the request by a backing file, which you will create and attach to the portlet in a subsequent step.<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>
Figure 7-4 shows the completed JSP source file in the editor.
bPortlet.jsp
file. Checkpoint: At this point the you have created the following files in the producerWeb/WebContent folder:
In this example, we use a backing file attached to the portlet in the producer to handle the onMinimize event fired on the consumer.
Tip: | For detailed information on backing files, refer to the Portlet Development Guide. |
Tip: | Alternatively, instead of a folder, you can create a Java package. |
The backing folder appears under producerWeb/src, as shown in Figure 7-5.
Listening
and click Finish. The new Java class appears in the editor. Listening.java
, and copy the code from Listing 7-2 into Listening.java
. Listening.java
. package backing;
import com.bea.netuix.servlets.controls.content.backing.AbstractJspBacking;
import com.bea.netuix.events.Event;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class Listening extends AbstractJspBacking
{
static final long serialVersionUID=1L;
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 7-6.
Now you will attach the backing file created in the previous section to bPortlet.portlet
.
bPortlet.portlet
to open it.Tip: | If the Properties view is not visible in your perspective, select Window > Show View > Properties. If you want to learn more about editing portlet properties, see the Portlet Development Guide. |
backing.Listening
into the Backable Properties > Portlet Backing File field, as shown in Figure 7-8 and press Return. Tip: | You might need to expand the value column to enter text in the Portlet Backing File field. |
You now add the event handler to bPortlet.portlet
. The handler will be configured to listen for an event fired by another portlet and execute an action in response to that event. To add the event handler:
The Portlet Event Handlers dialog box expands to allow entry of more details, as shown in Figure 7-11.
The dialog box closes and aPortlet_1 appears in the Listen to list and the Portlet field, as shown in Figure 7-12. The label aPortlet_1 is the definition label of the portlet to which the event handler will listen.
Tip: | The definition label is a unique identifier for the portlet. A default value is entered automatically, but you can change the value. Each portlet must have a unique value. See the Portlet Development Guide for more information. |
handlePortalEvent
, as shown in Figure 7-14. This method is defined in the backing file that is attached to bPortlet. The source code for the backing file was shown previously in Listing 7-2. The event handler is added. Note that the Value field of the Event Handlers property now indicates 1 Event Handler.
Note: | WebLogic Portal attempts to validate the settings of the Event Handlers dialog. You will receive an error message if any problems are detected. For detailed information on the WebLogic Portal validation framework, see the WebLogic Portal Development Guide. |
Checkpoint: You added a backing file and an event handler to bPortlet. The event handler is configured to invoke the handlePortalEvent() method in the backing file when the portlet receives an onMinimize event fired by aPortlet. In the next task, you test the application to make sure that the portlets function properly in a local environment. Then, you will create a remote portlet in a consumer application to test the interportlet communication in a federated portal environment.
Create a portal in the producer application called ipcLocal.portal
:
and select New > Portal. The New Portal dialog appears.ipcLocal.portal
and click Finish. The portal is created and appears in the editor.aPortlet.portlet
and bPortlet.portlet
from the Package Explorer onto the portal layout, as shown in Figure 7-15.The portal renders in the default browser, as shown in Figure 7-16.
You created a portal containing two local portlets. You configured the portlet called bPortlet to respond to an onMinimize event fired from the portlet called aPortlet. The onMinimize event is a standard event that all WebLogic Portal portlets can fire. When bPortlet receives an onMinimize event, a backing file method is called that modifies the text displayed by the portlet.
In the following steps, you will create a federated portal that uses interportlet communication.
In this section, you create two portlets in the consumer application, one a JSP portlet and the other a remote portlet. The remote portlet consumes the portlet you created previously on the producer, bPortlet.portlet
.
Before you continue with this exercise:
bPrime.portlet
in the File name field, and click Finish.
http://
host
:
port
/producerWeb/producer?wsdl
http://localhost:7001/producerWeb/producer?wsdl
Tip: | WSDL stands for Web Services Description Language and is used to describe the services offered by a producer. For more information, see Federated Portal Architecture. |
After a few seconds, the dialog box refreshes, showing the Producer Details, as shown in Figure 7-18.
The remote portlet appears as bPrime.portlet
in the consumerWeb/WebContent folder in the Package Explorer.
bPrime
. To do this, edit the Title field in the portlet’s Properties view, as shown in Figure 7-20. Tip: | In the Properties view for bPortlet (in the producerWeb/WebContent folder) be sure the Render Cacheable property is set 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 test the consumer application to verify that minimizing aPortlet will change the content of bPrime (the remote portlet). You create a portal and add the two portlets created in Creating the Consumer Portlets. You then build the application and view the portal in a browser.
Create a portal in the consumer application called ipcConsumer.portal
:
and select New > Portal. The New Portal dialog appears. ipcConsumer.portal
and click Finish. The portal is created and appears in the editor. aPortlet.portlet
and bPrime.portlet
from the consumerWeb/WebContent folder onto the portal layout. The result is shown in Figure 7-21. From a user’s perspective, the consumer portal works exactly as if all portlets were local. The user is not aware that bPrime is a remote portlet hosted in a producer application. To test the consumer portlet, minimize aPortlet. The remote portlet, bPrime, responds changing the text it displays.
ipcConsumer.portal
in the Package Explorer and select Run As > Run on Server.
Listing 7-3 shows an excerpt from the XML content of a .portlet
file for the remote portlet described previously in this chapter, bPrime.portlet
. Note that the element dispatchToRemotePortlet
is added as part of the handleEvent
definition. This element indicates that the consumer must dispatch the event to the producer.
...
<netuix:handleEvent event="onMinimize" eventLabel="handlePortalEvent1"
fromSelfInstanceOnly="false" onlyIfDisplayed="true"
sourceDefinitionLabels="aPortlet_1"><netuix:dispatchToRemotePortlet/>
</netuix:handleEvent>
...
Custom events are the recommended method for passing data between portlets deployed in consumer applications and portlets in remote producer applications. This section outlines a possible technique for passing data from a consumer to a producer using custom events.
Tip: | You can use custom events to pass any serializable Java object or an object that extends com.bea.wsrp.ext.holders.XmlPayload between federated portlets. XmlPayload is a WebLogic Portal class that lets you pass XML data between consumers and producers. See Transferring XML Data for more information. Also, for more information on the XmlPayload interface, refer to its Javadoc description. |
Figure 7-24 illustrates the configuration of the example discussed in this section.
This section illustrates how a portlet on the producer can be configured to handle a custom event containing a payload. In this case, the portlet is a Java portlet associated with the class shown in Listing 7-4.
import java.io.IOException;
import javax.portlet.PortletException;
import javax.portlet.GenericPortlet;
import javax.portlet.RenderResponse;
import javax.portlet.RenderRequest;
import javax.portlet.ActionResponse;
import javax.portlet.ActionRequest;
import com.bea.netuix.events.Event;
import com.bea.netuix.events.CustomEvent;
public class JavaPortlet extends GenericPortlet {
public void getMessage(ActionRequest request, ActionResponse response,
Event event) {
CustomEvent customEvent = (CustomEvent) event;
String message = (String) customEvent.getPayload();
response.setRenderParameter("message0", message);
}
public void doView(RenderRequest request, RenderResponse response)
throws PortletException, IOException {
String message = request.getParameter("message0");
if (message == null) message = "";
response.setContentType("text/html");
response.getWriter().write("<p><b>Message From Consumer: </b>" +
message + "</p>");
}
}
The getMessage()
method retrieves a custom event object. This object contains the payload that is sent from the consumer to the producer. In the following steps, you will create an event handler that listens for a custom event and calls the getMessage()
method when this event is received. Note that in this case, the custom event is fired by a portlet deployed to the consumer application.
To configure the event handler in the producer portlet:
Tip: | The Portlet Event Handlers dialog box lets you create and configure event handlers for a portlet. An event handler listens for an event and takes a specified action when the event is receieved. |
messageCustomEvent
. Figure 7-27 shows the completed dialog.
getMessage
, as shown in Figure 7-28, and click OK.
The Java portlet is now configured to handle a custom event called messageCustomEvent
. When this event is received, the handler calls the getMessage()
method in the JavaPortlet class. This event handler provides the mechanism for interportlet communication between this portlet on the producer and other portlets, including portlets on a remote consumer.
A consumer portlet can be configured to fire a custom event, which is then handled on the producer. Listing 7-5 illustrates code that could be used in a local portlet on the consumer to fire a custom event and attach a payload to that event.
PortletBackingContext context =
PortletBackingContext.getPortletBackingContext(getRequest());
context.fireCustomEvent("messageCustomEvent", form.getMessage());
return new Forward("success");
Refer to the
Javadoc for more information on the fireCustomEvent()
method. For more information on portlet development and event handling, see the Portlet Development Guide.