BPM integration with Webform, Part 2: Human Tasks in Business Space using Lotus Webform Server

Lotus Webform Server has been chosen as one of the standard form user interface technologies. This article will explain how to integrate the Webform Server with the BPM stack.

It will also discuss, and detail how to build the distributed and local Webform Server topologies. It will also guide the creaton of a cluster of Webform Servers and how to perform high availability on the form infrastructure.


Jeff Brent (jeffb@us.ibm.com), Senior Software Engineer, IBM

Jeff Brent is a Senior Engineer with the WebSphere BPM development organization. Since 2005, Jeff has been a member of the WebSphere Process Server SWAT team and is responsible for resolving customer issues and complaints.

23 September 2010

Also available in Japanese Portuguese Spanish

WebSphere BPM and Lotus Webform Server

Overview of HTML and Form interaction

Whenever a human task is included within a long running BPEL, a decision needs to be made regarding the technology to be used in rendering this task. The WebSphere BPM stack gives you a few choices in user interface (UI) technology: JSF, simple HTML and now a tightly coupled integration with Lotus Forms.

Each of these user interfaces can be integrated into, and used from within, Business Space but the inclusion of Lotus Forms requires users to implement a new supporting product infrastructure in order to implement and view these forms.

In previous incarnations of Lotus Forms users needed to install a client application (Lotus Viewer) onto each of the end-users machines. This restricted users to a a finite number of platforms from which to interact with Human Tasks – those supported by the Lotus Viewer – and, most importantly, to a set of machines upon which the viewer was installed.

Lotus Webform Server is a technology designed to remove those restrictions, and allow users to view and interact with Lotus Forms from within a browser.

SalesPromotion Application

In the SalesPromotion application resides a simple business process (BPEL) which contains a single Human Task.

Figure 1. StorePromotions BPEL
StorePromotions BPEL

The 'Approve Request' Human Task has already had a form created for it, and this can be seen by clicking on Human Task name in the details section. This will show you the current settings for this task. In this case, figure 1 a Lotus Forms user interface has been selected.

Figure 2. Human Task settings
Human Task settings

When 'Generate Human Task Interface' is selected from the module context menu, and the form is generated for the 'Approve Request', an 'xfdl' (Extensible Forms Description Language) file will be generated and placed in the module folder. When deployed, the forms file (xfdl) will be stored in the WebContent (or the selected Web project) folder.

Figure 3. NewPromotionForm xfdl file in physical resources
NewPromotionForm xfdl file in physical resources

This file, NewPromotion.xfdl, stores all the requisite forms – in the case of a multi-form application – and these forms will be sent to the Webform Server. The Webform Servers job, at that point, is to convert the 'form' to HTML and return it back to Business Space to display. If you have Lotus Forms Designer installed, opening the NewPromotionForm will allow you to edit and customize the form.

Lotus Webform Server Deployment

Deployment Choices

There are effectively two choices for deploying Lotus Webform Server (WFS) for use with a Business Process Management topology.

Local Deployment installs Webform Server into an existing BPM Cell. In this scenario, due to the install location of the bSpaceWebformEnabler proxy application, it is easiest to install this onto the same physical node as the cluster containing the Business Space application.

Table 1. Reference Cluster Type for Webform Server location
Cluster TypeLocation
Remote Messaging/Remote Support (Gold)Support Cluster Members
Remote Messaging (Silver)Application/Support Cluster
Single Cluster (Bronze)Single Cluster available

Though this is the 'easiest' installation type, as you do not have to relocate the proxy application, it may become inappropriate due to the load created on the nodes. For high performance systems, it may be more prudent to install Webform Server in it's own cell, on separate nodes. This installation type is called the Distributed deployment.

Local Deployment – same Cell

Figure 4. Local Deployment in a Remote Messaging-Remote Support cluster
Local Deployment in a Remote Messaging-Remote Support cluster

Distributed Deployment – remote cell

Figure 5. Distributed Webform Server Cluster with HTTP Server
Distributed Webform Server Cluster with HTTP Server

Clustering Webform Server

In both of the deployment types, a single Webform Server, or a cluster of servers can be created.

With a single server, you are at risk of creating both a bottleneck, and a single point of failure for your applications. Without Webform Server, no Human Task forms will be rendered, and although this would not affect the BPC engine per se, it would effectively stop users from interacting with the processes. Clustering the Webform Servers will effectively reduce the potential bottleneck, and remove the single point of failure.

To create the Webform Server cluster, the Translator Server applications needs to be installed on one machine using the standard installation procedure, either by deploying the application and the supplied Application Server, or by deploying Translator Server application on a deployed Application Server.

The Application Server hosting the Translator Server application should be federated into the Webform Cell.

On the second node, which should be an Application Server node already federated into the Webform Cell, the Webform Server binaries should be installed. The Translator Server application should not be deployed to this Application Server at this time, as seen in Figure 4. This will be accomplished by the creation of the cluster.

Figure 6. Deploying the Translator Server
Deploying the Translator Server

To cluster the server, from the admin console, select the Servers > Clusters > WebSphere Application Server Cluster and create a new cluster, seen in figure 7.

Figure 7. Webform Server cluster creation
Webform Server cluster creation

Enter the name of the cluster, and leave the default settings. On the next screen, figure 8, select the create the member using an existing application server as a template and select the Translator Server that was originally created.

This option will take an existing Application Server as the basis for other nodes in the cluster. Whatever applications and/or other resources configured on the existing Application Server will be created onto the cluster and will therefore be transferred onto new members of cluster when they are added.

Figure 8. Create a cluster form an existing server
Create a cluster form an existing server

On the Add Member screen, figure 9, select the second Application Server, which did not have Translator Server application deployed on it, and click Next. This will create a new cluster member, and will transfer the deployed applications and resources of the existing Application Server to the new member.

Figure 9. Additional Members
Additional Members

You now have a cluster of two Application Servers, each with a deployed TranslatorServer from which forms can be rendered.

BspaceWebformEnabler Servlet

The bSpaceWebFormEnabler servlet is the proxy thru which Business Space will communicate with Lotus WebForm Server. It is a simple application that must be deployed wherever the WebForm Server binaries are installed as it requires access to these libraries.

There are two configuration points to enable Business Space to interact with WFS:

  • Configure the location of the bSpaceWebformEnabler
  • Configure bSpaceWebformEnabler to point to the location of the WebForm Server

The default URL defined for bSpaceWebformEnabler utilizes the 'localhost' host name, so if the WFS is installed local to the cluster member upon which the bSpacewebformEnabler is installed then no change is necessary.

To change the value, select Resource Environment Provider > Mashup EndPoints > Custom Properties, and alter the {com.ibm.bspace}bspaceWebformProxyRootId.url entry, as seen in figure 10.

Figure 10. Amending the Proxy root URL
Amending the Proxy root URL

If the bSpaceWebformEnabler is installed on a different server to the Webform Server, then the bSpaceWebformEnabler servlet parameter, 'translatorLocation', needs to be altered to reflect this, as seen in figure 11. Note, the port should not normally change from the default 8085.

Figure 11. Webform Proxy enabler configuration
Webform Proxy enabler configuration

In the configuration for the translatorLocation, a single URL is configured. This means that, even if a cluster is configured for the TranslatorServer application, the proxy servlet will still only access one of them, meaning we have no real High Availability (HA) functionality in operation.

To improve this situation, an HTTP server, or an IBM Proxy Server, should be configured and placed in front of the cluster. The URL in the 'translatorLocation' should then be configured to point to this server an associated port.

A Proxy Server will be the easiest to configure, as it is built-in to the Application Server. Unlike an HTTP server, the Proxy Server has a dynamic application list that requires no plug-in to be generated and manually distributed


The installation pattern used for WebForm Server depends upon the requirements of the project and the availability of necessary resources.

A distributed environment, whereby Lotus Webform Server is remote, gives the best demarkation of concerns, and allows for separate maintenance schedules.

Local installations, where the WebForm Server is installed locally to the WPS Cluster, can have a detrimental effect on the WPS cluster with additional load being placed on the servers. A local installation would also mean that the WebForm Server would be affected when maintenance is performed on the Application Server.

If High Availability is a requirement, then a cluster of WebForm Servers should be deployed and an HTTP Server or IBM Proxy Server should be configured to allow for load balancing across the cluster members.



Get products and technologies

  • Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.


  • Get involved in the My developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.


developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks

Zone=SOA and web services, WebSphere
ArticleTitle=BPM integration with Webform, Part 2: Human Tasks in Business Space using Lotus Webform Server