Portal Federation with WebLogic Portal WRSP: Advanced Techniques

May 14, 2008

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, you'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

Because 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. Although 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. In fact, it's so simple that you can just walk through the steps and understand why you are doing what you are doing.

In this walkthrough, you 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.

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; you now have a remote-able page where you can add your portlets. Even though 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).

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, and so forth. Even though 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 I 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. Although it is somewhat counter-intuitive, remote pages cannot 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). Even though 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 want 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: 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.

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. Although mildly annoying, this makes perfect sense because 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 the following example will use a non-standard approach to illustrate that there are times when requirements remind you that best practices are guidelines rather than rigid rules. I promise to cover the best practices approach in the next installment.

For this example, you are going to assume that your requirement is to maintain the value in session once it has been set. This is mighty convenient for your fictitious development project because you can accomplish this with the least amount of work. First, you will create a Serializable object to hold your value, and use a session singleton pattern just to keep the example simple:

Now, you will create a page flow controller that uses your SharedData object to store a value submitted by a form. Even though a formbean is potentially redundant for your needs, you'll cheat and use one anyways because 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; you'll just look at the relevant parts of the code (you can always download the example application to see the full code):

The outerRequest reference may be unfamiliar if 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, you can create the portlet that will get this data and display it (or whatever else you want to do with the data):

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, your users are frequently adept at finding ways around such good intentions and then getting mad at you for not anticipating it. In this particular example, you will handle the missing value in the JSP like this:

Of course, this works only because all you 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, you place your 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 your desktop and present users first with:

Conclusion

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.

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 okay, though. I'll cover that in Part 3.