Introduction

WebSphere Portal aggregates and integrates disparate enterprise applications and content in order to present a single, unified application experience for end users. Vendors have developed packaged portlets to surface common applications using WebSphere Portal including ERP, CRM, host, and client/server applications.

Prior to the advent of portals, new enterprise applications were developed as client/server applications in which separate window instances provided users a means to multi-task or reference information in different systems. Each window preserved the user session and information entered. In the portal realm, these various windows would correlate to different portlets with each portlet often residing on multiple portal pages. Therefore, as a user moves between applications in an effort to multi-task or reference information, the user’s application-specific information would be lost.

Back to top

Introducing the business scenario

The business scenario used in this article is based on a call center application. In a call center, customer service representatives (that is, portal users) need the ability to move between portal pages to reference information and to enter data, while maintaining application-specific context and data.

For example, the portal user accesses the portal to:

1. Enter customer information on one page.
2. Navigate to other portal pages (containing, portlets to web, host and client/server applications).
3. Return to the initial screen.

Our challenge is to transparently store the data entered into the original portlets (from step 1), and to maintain the data while the user navigates to and from other portal pages.

To demonstrate the scenario, we use a web clipping portlet on the main page, Call Center App, to clip the legacy struts web application. Other standard installed pages are used to simulate page navigation.

Back to top

Developing the example scenario

The most popular way to to store and retrieve data (persist) data has been to use cookies and JavaScript. This option does not require the browser to do a form submit because the execution processes on the client side.

The method that we have selected leverages simple JavaScript techniques that force the form submit so that the back-end application can take care of persisting the form data into a session object. In order to transparently submit the form, we chose to use the BODY tag unload() event. However, because there are no HTML or BODY tags in any of the portlet views as part of the portlet standard, we needed to add the unload() event to the theme's Default.jsp.

In the unload event we force the form submit so that the back-end application can read the form elements to persist the form data.

For your reference, the sample legacy application WAR file and Default.jsp code are provided in a download.

To develop the sample business scenario:

1. Set up the back-end application.

   Download and deploy the sample code,Inci2.war, into a local WebSphere Application Server 6.0. This application is a simple action class which returns control to the page. We have used a Struts application with a form bean set to session in struts-config.xml so that form data persistence is taken care by the Apache Struts framework.

   Listing 1. Back-end application’s struts-config.xml file and java source file

   <action path="/customerRequestAction" type="inci.resources.customerRequestAction" name="customerRequestBean" validate="false" input="/customerRequest.jsp" scope="session"> <forward name="create" path="customerRequest.jsp" contextRelative="true" redirect="false" /> </action> Action class of the web app simply returns control back. package inci.resources; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import org.apache.struts.action.Action; import org.apache.struts.action.ActionForm; import org.apache.struts.action.ActionForward; import org.apache.struts.action.ActionMapping; public class customerRequestAction extends Action { public ActionForward execute (ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception { customerRequestForm loginForm = (customerRequestForm) form; System.out.println("Loginaction"); return (mapping.findForward("create")); } }

   
   
2. Validate that you are able to access the back-end application using the following url:

   http://localhost:9080/Inci/customerRequest.jsp

   
   
3. From the WebSphere Portal admin console, clip the back-end Web application as shown in Figure 1.

   Web clipping is out-of-the-box function in WebSphere Portal 5.x. You can clip an entire Web page or part of it using the Web Clipping Editor. After clipping the page or portion, the editor creates a portlet which you can be place on any portal page. Figure 1 illustrates the Web clipping portlet.

   
   Figure 1. Clip the back-end Web application
   
   
4. Create a portal page and attach the Web clipping portlet created in the previous step.
5. Create additional portal pages and attach any portlets. These pages will be used by the user to navigate away from the page with the Web clipping portlet.

   You could either use out-of-the-box sample pages or create new pages from the WebSphere Portal Administration console. For example, you could create a new page called Switch under My Portal.

6. Implement a form submit by adding the following JavaScript function to the Default.jsp of the theme that you are using.

   Listing 2. JavaScript function to be added in the Default.jsp of your theme

   function formSave(formName, act){ if(window.document.activeElement != "[object]" && window.document.activeElement != null){ // window.document.activeElement returns the name of the object clicked, // we will be using this to capture the link/page user clicked to // navigate after submitting the form. if (!stopSubmits) { stopSubmits = true; // We are using stopSubmits as a Boolean variable to stop the form // submission if user is intentionally performing other actions in the form. var form = document.forms[formName]; form.all.tags("input").item("hiddenOperation").value = act; //hiddenOperation is a hidden field used to differentiate different actions // at the server side just in case needed. form.elements["url"].value = window.document.activeElement; form.submit(); window.location.href = form.elements["url"].value; // above statement redirects to url clicked after form submit. } } }

   
   

   Because the portal theme is common across all of the portal pages, you need to make sure that the form submission happens only on the page that contains the portlet. Therefore, include the conditional statement:

   if document.forms['wpsFormtoSave'] != null

   
   

   If you have a situation in which you need to save data from multiple portlets, you can do so by looping through the forms.

   To make sure that this script is not triggered when the user is trying to save the form intentionally by clicking on a submit button, check the if (!stopSubmits) button action.

   You can submit the Web page transparently by re-directing the user's action by clicking on any page, but the user would expect to go to the page clicked. This is achieved by reading the page clicked using the window.document.activeElement JavaScript method, and storing it into a form variable called url, which is read after the page submission is complete.

   We tried another technique for redirecting the url on the server side using response.sendRedirect("<url>" ), but this resulted in opening the entire portal page in the portlet window. Therefore, we opted to redirect the url on the client side.

   Alternative scenario:

   In some instances you may not be clipping a back-end application but rather working with a custom developed portlet application. In this case, the data can be submitted to the portlet application by leveraging the actionPerfomed event. If this is the case, you do not need to implement the default theme code above; instead, you could leverage the following portlet application receive action:

   Listing 3. JavaScript function to be added in the Default.jsp of your theme

   <body marginwidth="0" marginheight="0" <%=bidiDirAttr%> onUnload="if (document.forms['<portletAPI:encodeNamespace value="wpsFormtoSave"/>'] != null ) formSave(['<portletAPI:encodeNamespace value="wpsFormtoSave"/>');"> function formSave(formName, act){ if(window.document.activeElement != "[object]" && window.document.activeElement != null){ if (!stopSubmits) { stopSubmits = true; var form = document.forms[formName]; form.all.tags("input").item("operation").value = act; form.elements["url"].value = window.document.activeElement; document.<portletAPI:encodeNamespace value="wpsFormtoSave"/>.action = "<portletAPI:createURI> <portletAPI:URIAction name='formSaveAction'/> </portletAPI:createURL>"; //encoding namespace and creating an action to trigger // actionPerformed() event is required if you use custom portlets // instead of clipped applications. form.submit(); window.location.href = form.elements["url"].value; } } }

   
   
7. Add the unload Javascript event to the BODY tag of Default.jsp.

   <body marginwidth="0" marginheight="0" <%=bidiDirAttr%> onUnload="if (document.forms['wpsFormtoSave'] != null ) formSave('wpsFormtoSave');">

   
   
8. Load the portal page so you can prepare to test the scenario. You see the following portlet:
   Figure 2. The completed portlet
   
   

   Now that you have implemented the scenario, you can run through the usage scenario and verify that the data entered is persisted throughout the user's navigation.

Back to top

Testing the scenario

Now, to test the scenario, you would follow the user steps described earlier in the business scenario introduction:

1. Enter information on one page.
2. Navigate to another portal page.
3. Return to the initial page, where the data entered early should be preserved.

To illustrate this sequence, the screen shots below show the user starting to enter data into a form; then, half way through the data entry, the user navigates to another page. When the user returns, the user finds all the data that was previously entered is still intact.

Back to top

Conclusion

In this article, we demonstrated a technique to transparently submit a form to a legacy back-end application in a manner that persisted the data as the user navigated between portal pages. In addition, we showed how a similar technique can be used in a situation where a portlet application rather than a clipped legacy application is used.

Back to top

Download

Description	Name	Size	Download method
Code samples	samples-persisting.zip	6.6 MB	FTP|HTTP

Information about download methods

Resources

Learn

• developerWorks WebSphere Portal zone: Provides a wide variety of technical resources to help you develop portals and portlets.
  
  
• Page-to-page communication between legacy Web pages and portlets: Shows how to pass information between legacy Web (non-portal ) pages and either JSR 168 portlets or IBM API portlets.
  
  
• Page-to-page communication between JSR 168 portlets in WebSphere Portal V5.1.0.1: Enable a JSR 168 portlet on one page to pass information to a JSR 168 portlet on another page, using cross-page wiring.
  
  
• Page-to-page communication between portlets: Provides two techniques--for enabling static links with pre-defined data and for linking with user input carried along to the receiving portlet--in either WebSphere Portal V4.2.1 and V5.0.2.
  
  
• IBM Redbook: IBM Rational Application Developer V6 Portlet Application Development and Portlet tools: Basic information for creating portlets using the Rational Application Developer environment and built-in portal tools .
  
  
• Portlet development guide: Helps you get started developing portlets in WebSphere Portal V5.x.
  
  
• WebSphere Portal production documentation: Provides access to all current product documentation including InfoCenters, release notes, and readmes for all releases of WebSphere Portal.
  
  

Get products and technologies

• Rational Application Developer V6: Download trial software from developerWorks. Includes the portal tools and a test runtime copy of portal that you can use to develop a prototype.
  
  

About the author

Kris Vishwanathan is an IT Architect who has been with IBM since 2003. He worked as a senior developer and architect for IBM Systems and Technology Group before joining IBM Software Services for Lotus at the end of 2004. He has been part of the delivery team implementing WebSphere Portal and Web Content Management (WCM) solutions. In addition to architecting solutions for clients, he also sets up portal production environments involving portal clustering, Tivoli Access Manager, LDAP, user registry configurations, and portlet development using JSR168, JSF, IBM API, and WCM API. He is an IBM Certified WebSphere Portal System Administrator and Solution Developer.

Rate this article

Comments

Back to top

Table of contents

• Introduction
• Introducing the business scenario
• Developing the example scenario
• Testing the scenario
• Conclusion
• Download
• Resources
• About the author
• Comments

Next steps from IBM

• Try: Rational Application Developer for WebSphere Software
• Buy: Rational Application Developer for WebSphere Software

Dig deeper into WebSphere on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers