Moving Domino Data and Applications to the WebSphere Portal

     

One key to creating a successful, highly utilized portal is to provide end users with custom views into the applications and data they need to do their jobs effectively. However, creating these custom views, or portlets, can be time-consuming , requiring developers to write Java code that connects the various data sources, business processes, and existing systems with the portal vendor's specialized interfaces.

This problem is especially pronounced when it comes to leveraging Domino applications within a portal framework. Companies can have hundreds of custom Domino applications containing highly valuable data and logic but not have the Java or J2EE expertise to write the code needed to present these applications in a portal.

For example, suppose a company wants to utilize an existing Domino expense report management application from within their portal and enable portal end users to view, create, edit, and delete expense documents. Suppose this company also wants to be able to reuse, rather than rewrite, the existing agents within the Domino application.

For even the most seasoned J2EE developer, creating a portlet to meet these requirements would be time-consuming and code- intensive . The developer would first need to learn the Domino and Portal APIs and then write the following code (at a bare minimum):

• Java class to handle events

• Bean(s) to handle passing of data from the portlet to the JSP for rendering

• Java code for retrieving Domino Views and Documents, updating the Domino Documents, and remotely invoking the agents

• Java code for obtaining, releasing, and pooling of Domino Session objects

• Java code to handle authentication

• JSP for the portlet's user interface

• Deployment descriptors (web.xml and portlet.xml)

This doesn't include enabling portal administrators or end users to customize or personalize this portlet. That would require the J2EE developer to write additional JSPs, create encoded URIs, and develop the code that listens for and handles the various portlet modes (e.g., view, edit, or configure).

To reduce the effort and time needed to create and customize Domino portlets, developers can use different third-party graphical tools that shield them from needing to learn or implement the required APIs. Some of these tools also automate the creation of the Java code by abstracting development with wizard-like UIs. An example tool is the Bowstreet Portlet Factory for WebSphere. This type of tool can simplify the portlet development process, making it easy for even novice developers to rapidly create, customize, deploy, and maintain Domino portlets. By leveraging a tool such as the Portlet Factory, Domino developers can rapidly create standard, J2EE-compliant portlets that that display Domino Views and let end users view, create, edit, and delete Domino Documents. And because tools such as Portlet Factory offers a graphical environment, Domino developers can quickly learn to build robust J2EE portlets within a very short amount of time. The next section provides an overview of the Portlet Factory tool and describes how to use this product to create and customize the expenses portlet described here. The idea is to describe how tools such as Portlet Factory can be used to simplify the building of WebSphere portlets based on your existing Domino data and Domino applications.

Architecture and Concepts

Bowstreet Portlet Factory for WebSphere is a tool and framework for rapidly creating custom portlets for the WebSphere Portal (WP) environment. With Portlet Factory, developers build portlets by snapping together a sequence of highly adaptive software components called Builders. Builders generate the code (including Java, JSP, and XML) for specific application functionality. Portlet Factory includes a set of Builders that automate the creation of code for page controls, such as buttons and links. Portlet Factory also includes Builders for orchestrating page and process flows and for integrating with common back-end systems, such as Domino, SAP, or any JDBC-compliant database.

To create portlets using Bowstreet Portlet Factory, developers specify inputs to the wizard-like Builder interfaces, rather than entering code. Once a Builder is populated and saved, the Portlet Factory regeneration engine dynamically generates the appropriate J2EE code, which the application server can then execute. In this way, developers can capture and automate the process of building dynamic portlets instead of explicitly coding each portlet. Also developers can easily iterate during development by simply going back into a Builder and changing the input values.

The Bowstreet Portlet Factory snaps into the WebSphere Environment:

• IDE . The Portlet Factory developer tool, called the Designer, plugs right into the WebSphere Studio family of products as well as the open -source Eclipse platform.

• Application Server . The Portlet Factory regeneration engine is installed as an enterprise application (EAR file) on WebSphere Application Server.

• Portal Server . Applications created using the Bowstreet Designer integrate with WebSphere Portal via the Bowstreet Portlet Adapter Web Archive File (WAR). This is a standard WAR that includes the Portlet Factory classes (JAR files).

Creating a Portlet That Enables Viewing and Editing

To build the expenses portlet described in the preceding section, this section describes the use of the Domino View & Form Builder. To create the Domino portlet, follow these steps:

1. Create a new model from the Designer (a model is the Portlet Factory name for the container that holds all the Builders), by selecting File>New>Bowstreet Model in the Bowstreet Perspective within WebSphere Studio.
   
   
2. Select the Domino View & Form Builder from the Builder Palette.
   
   
3. Supply the Builder with the proper inputs, such as Domino Host Server, Database name (*.nsf file), View name, Form name, and so forth, and save it.
   
   

It's a relatively straightforward task to populate the Builders' inputs because they have numerous pickers and check boxes that help simplify development. For example:

• Once a developer enters a Domino host server, the Builder retains this value in the drop-down.

• Developers can select from pickers the appropriate Domino database and elements, including Views, Agents, and Forms.

• Using the run-time credentials select list, developers can specify the mechanism used to capture and utilize end user credentials (i.e., user name and password). As such, developers can quickly enable single sign-on by leveraging LTPA tokens or the WebSphere Credential Vault. Alternatively, developers can have the Builder generate the code that prompts end users for their login information and then authenticates the users to Domino.

• Developers can add paging to the portlet by checking the "Paged Data Display" box and specifying the rows to display per page. This feature is useful for Domino views that contain a large number of documents. Thus, rather than displaying all documents on the first page of the portlet, the portlet will display only the specified number of rows per page. The portlet will also include paging buttons that help end users traverse through the documents.

• To create a portlet that enables users to filter their views by category, developers simply need to check the "Show category selector" box. This automatically adds a select list to the portlet that contains the categories associated with the selected Domino View.

• Developers can build portlets that enable end users to view, create, edit, and delete documents by simply checking the appropriate box in the Builder (e.g., "Enable document create").

• Developers can also browse for HTML files and stylesheets.

After populating the desired inputs, you can save the Builder and examine the code that it created. The Builder generates a schema (view_schema) that represents the structure of the selected Domino view. It also generates a schema to describe the Document (view_documentSchema), as well as the JSP and supporting code for the retrieving and formatting of the View and Document data.

This Builder creates all of the code needed to support full-text search, paging through views, single sign-on, handling of Domino Session objects, caching of the View data results, invoking of agents, and creating, editing, and deleting of Domino documents. Furthermore, much of this code is also wrapped within helper methods (e.g., getViewData, sendDocument, updateDocument, createDocument, runAgent, and setComputeWithFormEnabled). Developers can call (pick) these methods from any Builder.

Developers can then run and test the model right from the Designer window. Also without requiring any additional modifications, developers can run the model as a portlet within WebSphere Portal. Developers simply need to make a copy of the Bowstreet Portlet Adapter and point it at the appropriate model. As mentioned earlier, the Bowstreet Portlet Adapter is nothing more than a WAR file that gets uploaded to the WebSphere Portal server once during the installation of the Portlet Factory.

Changing Portlet Functionality

It's important to note that Builders aren't simply "one-time use" wizards. At any time, developers can go back into any Builder and make a change and the code automatically updates. For example, suppose that after filling out and saving the Domino View & Form Builder, the developer wants to use a different view and also add category searching. The developer would simply need to open up the Builder, pick a different view, check off the "show category selector" box and click OK. The Builder then automatically regenerates the proper code.

Furthermore, if the developer wants to add additional functionality to the portlet, all that's needed is to add new Builders to the model. For example, using a single Builder can add sorting to any column. Adding another Builder can modify the naming and order of columns . In fact, any aspect of the portlet behavior can be modified or enhanced by adding additional Builders to the model, including portlet-to-portlet communication, look and feel, and application flow. In short, you don't have to settle for choices someone else has made for you.

Serving Multiple Constituencies

There is usually quite a bit of extra work required to create customized portlets (i.e., portlets that can be configured by portal administrators or personalized by end users). By using a tool such as Portlet Factory, developers can repurpose a single code base to serve multiple constituencies without requiring additional code changes or redeployment of files. In other words, developers don't need to write any additional code to handle new variations; they get the variations for free.

Bowstreet's profiling functionality makes this possible. Profiling makes it easy to pass different inputs into the Builders to generate new versions of a portlet. Essentially, a profile is a level of abstraction above Builders. The inputs to the Builders in a model can be captured within profiles. When a developer applies a profile to a model, Bowstreet dynamically generates a new version of the portlet application. This helps developers generate different behaviors from a single portlet ”for example to enable application customization, user entitlement, or personalization ”by simply creating a new profile for a portlet application.

We could create a Manager profile for our expenses model that would run the "approve" agent when a manager edits and saves an expense report. We would simply need to profile the "Agent to run on Save" Builder input, passing the name of the approve agent when the profile is Manager and leaving the input null when the profile is default. Similarly, we could profile the delete functionality, enabling delete when the profile is Manager and disabling delete when the profile is default.

Developers can expose profiles to a portal in several different ways. For example, applications can automatically select profiles based on portal user login information. So if someone belonging to the Manager group logs in, the application can use the Manager profile to apply to the expenses portlet. Profiles can also be exposed in a portlet's Edit or Configure modes.

With tools such as the Portlet Factory, the process of reusing and repurposing the same model for different constituencies without having to write new code can be significantly simplified. As a result, developers no longer have to deal with the maintenance of keeping up multiple versions of a portlet or the problem of maintaining complex patterns of conditional logic.