Inter-portlet Communication with OmniPortlet

OmniPortlet was originally built for Oracle Portal, allowing page designers to visualize various types of data sources in a declarative manner in the browser, without using an IDE. The two simple steps of defining an OmniPortlet in-place are: selecting and specifying your data source (XML, SQL, CSV, Web service, etc.), and applying the visualization/view on top (table, bullet, scrolling news, or even custom HTML).

While OmniPortlet doesn’t support ADF eventing, if all you need is driving a detail OmniPortlet from a master one, here is how you can achieve it. In this example I’m using WebCenter Spaces, but the same applies to any custom WebCenter portal application that leverages Oracle Composer.

Edit your page, and drop two instances of OmniPortlet onto the page. At this point they will be undefined.

From the View Actions Menu of the first one, select the Customize menu.

For our simple demo, select CSV as the data source, and leave the default settings for the CSV URL. The only thing we’ll change in this portlet is the Layout Style: HTML.

For the non-repeating heading section, specify the hyperlink for your master portlet. What you need to know for this step, is the URL of your page, containing your portlet. If you’re using WebCenter Spaces, an easy way to find this out is through the About menu of your page. In my case, the page is called OmniPage, and it’s in the group space, called MyGroupSpace. Notice the URL parameter appended to the linked page, PageParam1 (you can choose your own name, of course), and the values assigned to it: Hello in the first line, and World in the second.

<a href="">Hello</a>
<a href="">World</a>

Note: The above code snippet appears to be incomplete, but if you select it and paste it into a text editor, you will have it all.

Customize the second OmniPortlet, choose HTML for the Layout Style. All you need to do, is reference the parameter passed to this OmniPortlet, by using the OmniPortlet syntax: ##Param1##.

The last step is specifying that the request parameter specified in the first OmniPortlet, PageParam1, should e passed to the first parameter of OmniPortlet, Param1. To do this, make sure the page is in edit mode. Click the Edit (pencil) link of the Detail (consumer) OmniPortlet, and specify the following value for Param1: #{param.PageParam1}. This is the EL syntax for “request parameter, called PageParam1”.

Save your changes, and close the edit mode of your page. What you should see is similar to this when clicking on Hello:

And here is what you get when clicking on World:

One important caveat: this is more of a trick or workaround for OmniPortlet’s (and PDK-Java as a portlet technology’s) shortcoming, the lack of support for ADF model events. This solution will perform a full page refresh, and it also resets/looses your JSF session. If you’re designing components/portlets that should support inter-component communication, your first choice should always be ADF task flows or WSRP 2.0 portlets.

2 Easy Steps to Implement Inter-Portlet Communication with WSRP 2.0

One of the most mysterious topics of the portal world is inter-portlet communication. Some of you expressed interest in portlet technologies in an earlier poll, so here we go…

Before the 2.0 versions of the portlet standards were ratified (WSRP 2.0, JSR 286), inter-portlet communication could only be achieved with some sort of a hack. Typical implementations included vendor-specific extensions on top of the portlet standards (breaking inter-operability), or portlets using a shared store to exchange information, such as the session context or a database. All of these workarounds required a hacker attitude.

The easiest way to try out the concept is by using two of the sample portlets from the WSRP Sample Portlet Producer: the Parameter Form and Parameter Display portlets. Here are the introductory steps you need to take, that are not related to inter-portlet communication, and you may well be familiar with:

  1. Start up the preconfigured OC4J. First, point your browser to http://localhost:6688. Then click on the Sample Portlets link (http://localhost:6688/portletapp/info).
  2. Copy the WSRP 2.0 WSDL end point URL (you find it on the bottom of the page) to your clipboard: http://localhost:6688/portletapp/portlets/wsrp2?WSDL.
  3. Create an application in JDeveloper, based on the WebCenter Application Template.
  4. Register the WSRP Sample Producer with your application.

  5. Create a new jspx page, and drop the Parameter Form and Parameter Display portlets onto the page.

It takes only two steps to set up inter-portlet communication – and this is the actual meat of this post.

  1. Wire the two portlets, so the parameters entered in the parameter form portlet are passed to the parameter display portlet.
    1. Switch to the page definition of the page (invoke the context menu in the middle of the page, and select Go to Page Definition. If the page definition doesn’t exist yet, let JDeveloper create it for you.
    2. Locate the two portlets in the Structure Pane, and expand the Parameters section to see the three WSRP 2.0 navigational parameters that these portlets provide. Notice that the portlet parameters are mapped to page variables. All you need to do is make sure that the portlet parameters of the Parameter Form Portlet are mapped to the same page variables as the parameter of the Parameter Display Portlet.
    3. Confirm your changes by taking a look a the source of the page definition.
  2. Configure partial page refresh, so the parameter form display portlet refreshes when a new parameter is submitted in the parameter form portlet.
    1. On your jspx page select the Parameter Display portlet and locate Partial Triggers attribute. Point to the id of the Parameter Form portlet, for example portlet1.

That’s it!

Now run the application and enter some values into the Parameter Form portlet.

Click the OK button. The Parameter Display portlet should refresh with partial page refresh (PPR).

“And the crowd goes wild…” [B.H.]