Portal Federation with WebLogic Portal WRSP: Advanced Techniques

Finally, you can 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, 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:

<netui:label defaultValue="No IPC Value Set" value=
   "${actionForm.ipcValue}" />

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:

Click here for a larger image.

Figure 4: Null Values Should Be Expected

Then, show them what they want:

Click here for a larger image.

Figure 5: Portlets Sharing Runtime Data

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.

Download the Code

You can download the example application here.

About the Author

Scott Nelson is a Principal Portal Consultant who likes clients who want more sophisticated portals, creating a satisfying experience for users, and going home early during the QA phase.