Originally published at developer.com
In part 1 of this series you created your first federated portal utilizing WSRP. When the first WSRP spec was released, simply being able to render a portlet from one portal inside another with little or no additional development seemed really exciting. Like all new, cool technologies, once everyone had their gee-whiz moment, they started thinking about what else they wanted. As usual, they wanted a whole lot more, some of which is being addressed by the recently released WSRP 2.0 spec and the next Java portlet spec, JSR-286. Also as usual, neither development groups nor the WebLogic Portal product team waited for the next specification to start delivering the next generation of functionality. The over-arching theme of post-WSRP 1.0 requirements is how to go beyond sharing individual portlets, and begin integrating whole sections of portals together. Starting with version 9.2, the WebLogic Portal (WLP) began including both references on how to leverage existing capabilities as well as new APIs to allow enterprises to fully federate their portal assets. In this installment we’ll examine two of the major features that you can use to meet the expanding requirements you are bound to face once you get that first portlet reused through WSRP.
Federating Pages and Books
As all readers of developer.com are extremely intelligent I am certain that you have already concluded that if you can place one WSRP portlet in your portal, you can also place a whole page full of them in your portal. While this may be adequate for some portals, there are two scenarios that come immediately to mind (though there are bound to be others) where it would be better to have these portlets already grouped in the producer before integrating them into the consumer portal. One scenario is the division of labor provided wholesale importing of pages and books. Some portals are huge, containing hundreds of pages and thousands of portlets. Adding one or more pages to a portal administrator’s duties may simply not be practical. The other scenario is where the owners of the producer portal want to maintain a greater degree of control in how their portlets are combined no matter where they are rendered. Federated pages and books fulfill these needs easily.
WLP has made basic page and book federation extremely simple. So simple that we can just walk through the steps and understand why we are doing what we are doing.
In this walk-through we will use a simple taxonomy, keeping in mind that the more well-planned your taxonomy of portal assets is the easier your portal application will be to maintain. Once you have determined where your first federate page should reside, select the Portal perspective in Workshop, highlight the folder where you want your new page to live, and either select File > New > Other or use the CTRL+N shortcut to start the Workshop Wizard. In the first dialog, expand WebLogic Portal and select Page.
Figure 1: New Page Wizard
The wizard will have your highlighted path pre-selected for you and prompt you for a name for your page. Enter a name and click Finish and you now have a remote-able page where you can add your portlets. While it may seem odd at first to have a page with no book above it in Workshop, it will function the same as pages in the library of your Portal Administration Tool (PAT).
Figure 2: Remote Page Layout
One nice improvement in WLP 9.2 is that the wizards generate the Definition Label of portal assets based on what you named them, rather than the old scheme of portlet_1, portlet_2, etc. While the portlet wizard prompts you for a title, the page wizard does not. With federated portals, some thought should be given to the value to use in the Title field of your remote pages (also for portlets and books). Unlike a Definition Label, the Title does not need to be unique as required by the API. However, consumer portal administrators will have no way of knowing the difference between three pages (or portlets or books) with the same name because they will not have the graphical view of them you do in Workshop or on your desktop. Consumer administrators can, however, change the Title field of a remote portal asset in the consumer portal library. Ah, but didn’t we say that one reason for federating pages was to leave the control with the producer? Like many areas of enterprise design and development, the approach needs to fit the situation. Deciding such trivial matters as portal asset titles in a in the early planning stages of a federated portal architecture will save time during the QA stage.
Adding a remote book to your producer portal starts with almost the exact same steps, the only difference being that you select the Book wizard rather than the Page wizard. Once your remote book is created, you then add pages as you would in a non-remote-able book. While it is somewhat counter-intuitive, remote pages can not be used in remote books laid out in Workshop. Attempting to do so results in the remote page looking wrong in Workshop (the path to the page prints out where you would expect to see a layout). While this invalid configuration will build and deploy, the book with the remote page is not included in the published portal. If you have a remote page that you wish to be in a remote book, you will need to let the administrator of the consumer portal know. As with standard books, pages created in the book will be available in the PAT individually and there the administrator can assemble the way you could not in Workshop.
Note that if a portlet is consumed individually and later included in a remote page (or multiple remote pages are consumed containing the same portlet), a separate instance of the portlet is created on the consumer. If you know in advance that you will consume a portlet both individually and as part of a book or page, it is easiest to maintain your consumer portal by first placing the individual portlet before adding the remote page to your library.
Once the producer has published the remote pages and books, the consumer then needs to add them to the library. This is done in the same fashion as adding a WSRP portlet (as described in The Basics), only you select the Pages or Books section accordingly.
Figure 3: Remote Assets in the Portal Administration Tool
Oddly enough, the sequence of pages in a remote book is not maintained when consumed, so communication must be maintained between the producer developers and consumer portal administrators so that they can be arranged as desired in the consumer once the remote book has been added to the consumer desktop.
Passing Data Between Remote Portlets
Inter-Portlet Communication (IPC) is when an action in one portlet causes a reaction in another portlet. There is an example in the WLP documentation of how to have a receiver react to an Event fired by a sender. In this article we will take IPC one step forward and pass a run-time value from the sender to the receiver.
The important thing to remember when passing data from one remote portlet to another is that the request object is not shared between portlets. While mildly annoying, this makes perfect sense as the collection of remote portlets on a given consumer page may not necessarily be from the same producer. There are multiple solutions to get around this, and in the following example we will use a non-standard approach to illustrate that there are times when requirements remind us that best practices are guidelines rather than rigid rules. I promise to cover the best practices approach in the next installment.
For this example, we are going to assume that our requirement is to maintain the value in session once it has been set. This is mighty convenient for or fictitious development project as we can accomplish this with the least amount of work. First, we will create a Serializable object to hold our value, and use a session singleton pattern just to keep the example simple:
package common.example;
import javax.servlet.http.HttpSession;
public class SharedData implements java.io.Serializable
{
private String ipcValue1;
private static final long serialVersionUID = 1518508811L;
private static final String SESSION_DATA_ID = “sharedSessionData”;
public static SharedData getInstance(HttpSession outerSession)
{
if(outerSession.getAttribute(SESSION_DATA_ID)==null)
{
outerSession.setAttribute(SESSION_DATA_ID, new SharedData());
}
return (SharedData)outerSession.getAttribute(SESSION_DATA_ID);
}
private SharedData (){}
public String getIpcValue1(){return ipcValue1;}
public void setIpcValue1(String ipcValue1) {this.ipcValue1 = ipcValue1;}
}
Now we will create a page flow controller that uses our SharedData object to store a value submitted by a form. While a formbean is potentially redundant for our needs, we’ll cheat and use one anyways as the JSP wizards in Workshop make building a form using the form bean only a moment’s work. As the “Advanced” in the tile of this article assumes you already know how to build basic portlets, we’ll just look at the relevant parts of the code (you can always download the example application to see the full code):
public Forward begin(IpcDemo3FormBean form)
{
HttpServletRequest outerRequest = null;
SharedData sharedData = null;
outerRequest = ScopedServletUtils.getOuterRequest(getRequest());
sharedData = SharedData.getInstance(outerRequest.getSession());
if(form!=null && form.getIpcValue()!=null)
{
sharedData.setIpcValue1(form.getIpcValue());
}
return new Forward(“default”);;
}
The outerRequest reference may be unfamiliar ff you haven’t had to deal with request objects in WLP before. WLP breaks up the request object before providing it to portlets, scoping the request variables down to the portlet level. By using org.apache.beehive.netui.pageflow.scoping.ScopedServletUtils you can gain access to the full request, which is what you need for another portlet to be guaranteed access to your object.
Finally, let’s create the portlet that will get this data and display it (or whatever else you want to do with the data):
public Forward begin(common.formbeans.IpcDemo3FormBean form)
{
HttpServletRequest outerRequest = null;
SharedData sharedData = null;
outerRequest = ScopedServletUtils.getOuterRequest(getRequest());
sharedData = SharedData.getInstance(outerRequest.getSession());
if(sharedData.getIpcValue1()!=null)
{
form.setIpcValue(sharedData.getIpcValue1());
}
return new Forward(“success”);
}
That seemed too easy. Actually, it is too easy. The most frequent cause of bugs in this type of IPC is where the receiver expects there to always be a value. Even if you have a fairly well-orchestrated work flow to get to the portlet with a value it can use, our users are frequently adept at finding ways around such good intentions and then getting mad at us for not anticipating it. In this particular example, we will handle the missing value in the JSP like this:
<netui:label defaultValue=”No IPC Value Set” value=”${actionForm.ipcValue}” />
Of course, this works only because all we are doing with the value is displaying it. Your mileage may vary, and so long as you remember that the value may be null, you will still not crash.
So, we place our page flows into portlets, build, deploy, go to the consumer PAT, add the new portlets (or a remote page containing both already) from the remote producer to the library, place it on our desktop and present users first with:
Then show them what they want:
In conclusion, once you have federated your first portlet, you will probably be asked to federate more portlets, then pages of portlets, and possibly books of portlets. Once you start consuming pages and books, you have essentially created a portal within a portal, and someone will want it to act that way, such as sharing data between remote portlets. Now you can.
Shortly after you demonstrate your ability to all of the above, they will probably want you to have even more inter-portlet communication with more data, get some of that data you are putting into session out of the session once it has been passed, pass some of the data through hyperlinks instead of forms, and then navigate from one remote page to another by choosing an action in a portlet. That’s ok, though. We’ll cover that in part three.
