- The Benefits of Inter-Portlet Communication
- The WebSphere Property Broker
- Creating a Service Provider
- Testing the Service Provider
- Creating a List Portlet
- Creating a Detail Portlet
- Configuring the WebSphere Property Broker
- Alternative Communication Methods
- When to Use Inter-Portlet Communication
- Summary
- Important Points
This chapter is from the book
This chapter is from the book
This chapter is from the book
Alternative Communication Methods
Although the WebSphere Property Broker is a highly flexible and versatile method of inter-portlet communication, there are some situations where other approaches might provide more value. For example, the Property Broker is available only in WebSphere Portal, so if you transfer your portlets to another type of portal server, you need to modify the communication technique used. Second, communicating via the Property Broker requires that a wire must be set up between two portlets before they can communicate; this creates extra configuration steps and leaves more of the configuration process open to human error—although, it can also be regarded as a good thing, because it gives end users more control over the communication process.
There are several alternative options available for setting up inter-portlet communication in WPF, and each has its own strengths and weaknesses. These methods are described next.
Property Broker Action
Property Broker Actions, as opposed to Property Broker Links, let you define your communication as actions rather than as clickable links. The advantage of this approach is that you have more control over how the action is run—whether it be programmatically or from a UI control; however, the disadvantage is that more WPF configuration is required than when using Property Broker Links. The communication on the Property Broker is no different—that is, you still publish properties in the same way.
Property Broker Actions are not really an alternative method of communication to Property Broker Links, because they are really just Property Broker Links that don't produce a link in the UI. However, Property Broker Actions can be quite useful, and because the configuration process is sufficiently different, an example is included.
The following builder is added to the loansList model in this section:
- Link
Modifying the Cooperative Source
To alter the communication in the loans application to use Property Broker Actions, first open the Cooperative Portlet Source builder call in the loansList model. Change the Type input from Property Broker Link to Property Broker Action. This creates an action to publish the loan ID to the Property Broker, but it does not create the corresponding trigger for the action, such as a link. Save the builder call when you are finished.
Adding a Link and Configuring Communication
To trigger the Property Broker Action, add a Link builder call to the loansList model. Name the Link loanIDLink. In the Page Location section of the builder call, fill out the Page input as loansView_ViewPage and the Tag input as LoanID. This replaces the loan ID links created by the View & Form builder call with the new links defined by the Link builder.
Select pbAction_openLoanDetail for the Action input, which triggers the Property Broker Action when a loan ID is clicked. Notice that two arguments with the pbAction_openLoan Detail_Arg prefix are automatically added to the Input Mappings input in the Arguments section of the builder call. You need to replace the values of these arguments. The first argument to any Property Broker Action must be the name of the action (that is, pbAction_openLoanDetail). This argument is used by the portal to associate the Property Broker call with a particular Property Broker action. The argument is added automatically when using Property Broker Links, but needs to be added manually when using Property Broker Actions. Rename the argument to ACTION_NAME, and then type the name of the action (pbAction_openLoanDetail) as the value. Note that the name and value of the argument must be written as specified, or the inter-portlet communication cannot work. Note that the Evaluate Arguments input must be set to 'As the page is rendered'; if it is not, the links cannot be generated correctly.
Because the Cooperative Portlet Source builder call is expecting an argument, you must also change the second argument for each link created by the Link builder call. To do this, change the second argument to point to the currently selected loan, and change the name of the argument to loanID so that it is easier to identify, as shown in Figure 7.16. Note that the value of the argument is the same as the value of the argument specified in the Cooperative Portlet Source builder call. In the next step, you remove the value from the Cooperative Portlet Source builder call so that the value from the Link builder call is used instead. Save the builder call when you are finished.
)
Figure 7.16 Adding an argument to the Link builder call.
Open the Cooperative Portlet Source builder call and delete the Value input for the loanID output. The value for the loanID output is now taken from the Link builder call.
You have now finished configuring the loansList model. No changes are required to the loanDetail model, because the parameter published to the Property Broker is the same as it was before. Note that the ACTION_NAME parameter does not need to be specified in the Cooperative Portlet Source builder call. Rebuild your portlet application by right-clicking on your project and selecting Portal Server WAR, Build Portlet War. You don't need to reset or modify the wire, because the structure of the communication hasn't changed. The only thing that has changed is how you actually trigger the event to send to the Property Broker. To test the new communication method, navigate to the loans portlets in the portal and click on a loan in the Loans List portlet. The corresponding loan should open in the Loan Detail portlet.
You have now successfully configured the loans application to use Property Broker Actions rather than Property Broker Links. Again, note that this change doesn't change the type of communication, but merely how you use it in WPF.
WPF Event Model
When using the WPF event model, communication between portlets occurs by triggering and handling an event. This approach is easy to use and configure: First, you declare an event in a source and target portlet, and then you trigger, or fire, the event in the source portlet. Finally, you handle the event in the target portlet. Events can be fired and targeted to a particular portlet, or they can be fired in such a way that they can be accessed by any other portlet in the same WAR file.
You can trigger events using the WPF event model in two ways: on the server and on the client. Both methods enable you to access and manipulate resources on the server, such as reading and updating data from a service provider, but triggering events on the client also enables you to perform partial page refreshes. Partial page refreshes improve the speed of your application, and users appreciate that they can interact with your portlet without having to constantly reload the entire portal page. Partial page refreshes are covered in more detail in Chapter 13, "Using Ajax and Dojo." Note that you can only pass parameters to events when using server-side events, which is why both types of events are sometimes used together; for example, you might use a server-side event to update data in a Lotus Notes database, and then use a client-side event to partially refresh the page with this data. The example at the end of this section uses only a server-side event.
Be aware that when using the WPF event model approach, all inter-communicating portlets need to be contained in the same WAR file, which also means that they all need to be built with WPF. As a result, the WPF event model is most useful for setting up inter-portlet communication when interoperability with other applications is not a concern.
The following builders are added in this section:
- Event Declaration (x2)
Defining an Event
To alter the communication in the loans application to use the WPF event model, the first step is to define an event, which is triggered every time a user clicks on a loan ID. Add an Event Declaration builder call and change the Event Name input to openLoanDetail. Add an argument called loanId of type String to the Arguments section so that any triggers for the event need to pass in a String value when they trigger the event. This String corresponds to the loan ID of the loan that the user clicks on. The event is triggered any time details for a loan are opened. Save the builder call when you are finished.
Triggering the Event
Now that you have finished configuring the event declaration, you should modify the loansList model to trigger the event. Open the Link builder call in the loansList model and change the Action input to fireopenLoanDetail. You can select this from the Select Action dialog. If the fireopenLoanDetail action does not appear, make sure you have saved your Event Declaration. The fireopenLoanDetail action fires the openLoanDetail event instead of publishing the loan ID to the Property Broker.
Notice that an argument called fireopenLoanDetail_Arg1 has been added underneath the Arguments section of the builder call. This argument has been created by WPF to cater for the loan ID that is supposed to be passed to the event, but you still have two arguments left over from when you configured the Property Broker Action. The loanID argument left over from the Property Broker Action is the argument you want to pass to the event when it is fired, so remove the other two arguments from the Input Mappings input. The Arguments section should now appear, as shown in Figure 7.17.
)
Figure 7.17 Setting arguments for the Link builder call.
You have now finished configuring the Link builder call. Disable the Cooperative Portlet Source builder call as it is not being used, but you might want to use it again later. You can disable builder calls by right-clicking on them and selecting Disable. Save the model when you are finished.
Handling the Event
Now, you need to configure the loanDetail model to handle the openLoanDetail event. To do this, first open the loanDetail model and disable the Cooperative Portlet Target builder call, because you are no longer using the Property Broker (don't save the model yet). Copy the Event Declaration builder call from the loansList and paste it into the loanDetail model. This is done so that both models are using the same event. Because the event name in your Event Declaration is the same as the event name in your Cooperative Portlet Target builder call, no changes are required to the Event Handler builder call; it processes the openLoanDetail event as it is defined by the Event Declaration now that the Cooperative Portlet Target is disabled.
Save the model to complete the configuration of your application to use inter-portlet communication via events. To test the new communication method, rebuild your application and navigate to the loans portlets in the portal. Click on a loan in the Loans List portlet, and the corresponding loan should open in the Loan Detail portlet.
Shared Variables
Shared variables are perhaps the quickest and easiest way to implement inter-portlet communication. Shared variables can be stored in one of four ways: in the HTTP session, in the HTTP request, in the JVM where the current WebApp is running, or using a custom Java class. Variables stored in the JVM are accessed as static variables (the same copy is used across all instances of the portlet). To create or read a shared variable from a model, add a Shared Variable builder and designate a variable to share.
Note that variables stored in the HTTP session increase the amount of memory consumed by the session, and variables stored in the HTTP request have limited scope. Also, variables in the JVM cannot be accessed outside the JVM (for instance, across a cluster), and custom variable storage methods require additional Java development. Provided you keep these concerns in mind, however, shared variables are a powerful and easy-to-configure method of inter-portlet communication.
In the previous section, it was necessary to pass the loanID from the event trigger to the event handler via an argument to the event. In this section, you use a shared variable in place of the loanID argument so that when you change the loanID variable in the loansList portlet, it is read in the loanDetail portlet and used to update the loan information. Note that in this example, an event is still used to access loan details for the loan ID stored in the shared variable. This is because even though the loan ID is shared between both models, the details portlet won't know that it is supposed to refresh the other loan details unless an event is fired that causes this to happen. Because changes to a shared variable do not in themselves trigger any events, shared variables are often used in conjunction with the WPF event model.
The following builders are added in this section:
- Variable (x2)
- Shared Variable (x2)
- Action List
Removing the Event Argument
To alter the communication in the loans application to use the shared variable approach, first remove the argument from the Event Declaration builder call in both the loansList and loanDetail models, because you are now storing the loan ID in a shared variable. The argument is listed in the Arguments input of the Event Declaration. Save both instances of the builder call when you have removed the arguments.
Adding a loanID Variable
Next, add a Variable builder call to the loansList model and call it loanID. Change the Type input to String and save the builder call. This builder call holds the value of the currently selected loan ID and is used in both models, so copy and paste the builder call into the loanDetail model. Save the model when you are finished.
By default, each model uses its own instance of the variable created by the Variable builder call. To share the variable, you need to add a Shared Variable builder call to each model. Add a Shared Variable builder call to the loansList model first, and then name the builder call loanIDShared. Change the Variable input to loanID.
The Scope input enables you to specify where the shared variable will be stored. As discussed earlier, you have four options when setting a shared variables scope: Session, Request, Application, and Custom. Make sure this input is set to Session, which means that the variable value persists even when other links on the page are clicked. Then, change the Unique ID input to loanID and save the builder call. Make a copy of the Shared Variable builder call and paste it into the loanDetail model. Save the model when you are finished.
Creating these Shared Builders shares the loanID variable in the HTTP session using the text loanID as an identifier. The identifier can then be used from other processes and portlets to access the shared variable from the HTTP session. When referring to the variable from WPF, however, you need only to reference the name in the Variable builder call.
Configuring Actions for loansList
The next step is to set up two actions in the loansList model. The first action changes the value of the loanID variable when a loan ID is clicked, and the second action fires the new openLoanDetail event without any arguments.
To add these actions, add an Action List builder call to the loansList model and call it selectLoan. Enter in an argument called loanID of type String in the Arguments input, and then change the Return Type input to void to prevent the Action List from returning a value.
For the first action, select Assignment from under the Special heading in the Select Action dialog. For the Target variable, select the loan ID variable (Variables/loanID), and for the Source variable, select the loanID argument from the Action List (${Arguments/loanID}). The Make Assignment dialog should appear, as shown in Figure 7.18. Press OK when you are finished to accept the action.
)
Figure 7.18 Configuring the Make Assignment dialog.
For the second action, fire the openLoanDetail event by selecting fireopenLoanDetail from the Select Action dialog. Save the builder call when you've finished adding both actions.
Running selectLoan
Open the Link builder call and change the Action input to selectLoan. This runs the selectLoan action list whenever a loan ID is clicked. WPF assumes that you want to set a new argument for the selectLoan action list, so it automatically adds an extra argument to the Input Mappings input. You can delete the extra argument, because the previous loanID argument will suffice. Save the model when you are finished.
Using the Shared Variable in the loanDetail Model
You need to configure the loanDetail model to use the shared variable instead of the argument in the old openLoanDetail event. To do this, open the handleOpenLoanDetail Event Handler builder call and change the first action in the Actions input to use the loanID variable instead of the loanID argument, which no longer exists. The new action should read loansGetLoanDetailWithArgs(${Variables/loanID}).
Save the builder call when you are finished. To test the new communication method, rebuild the application and navigate to the loans portlets in the portal, and then click on a loan in the Loans List portlet. The corresponding loan should open in the Loan Detail portlet.
You have now successfully configured the loans application to use shared variables for its inter-portlet communication.
Click-to-Action (C2A)
Click-to-action (C2A) facilitates inter-portlet communication through the use of portlet menus that the user can configure. The C2A builders have been deprecated as of WPF 6.0, because they rely on the now deprecated WebSphere Portlet API, rather than the JSR-168 standard, so you should avoid using C2A as your inter-portlet communication mechanism.