Overview

IBM® WebSphere® Process Server Version 6.1 enables flexible, dynamic business processes based on the WS-BPEL 2.0 standard. Processes can contain a mix of automatic and manual steps. For a manual step, work is assigned to a person. After the person performs the work, control is returned to the process, which decides which step to perform next. Work can be assigned to individual users, or to groups of users, such as job roles, department members, or group members.

Users who interact with the process are presented with a "work list", showing them a list of all items of work they are authorized to perform. The user can select one of these work items, and decide if they want to claim the work as their own to perform. If they claim the work item, its status moves from Ready to Claimed, locking other users out from being able to claim it. Most of the time, a work list is configured to only show work items in the Ready state.

When a user claims a work item, the data from the process needs to be presented to them in a user-friendly manner, along with work instructions, and buttons to press to select different options such as approving or rejecting a request. When all the work has been completed, the user presses a button to indicate they are done with the work item.

In older versions of WebSphere Process Server and its predecessors, WebSphere MQ Workflow and WBI Server Foundation, a Web client was available for users. Wizards could be used to generate JSPs for the user interactions, or one could be created by hand. WebSphere Process Server comes as a part of WebSphere Portal Extend (or higher), in which case the MyTasks portlet is used, along with a custom portlet for each task.

This article focuses on integration with IBM Lotus® Forms, a new option in WebSphere Process Server V6.1. Lotus Forms provides a security-rich, dynamic, easy-to-use front-end for business processes. You can create a pixel-perfect representation of an existing form for users to fill in, print, save, or to use as a part of a business process. Lotus Forms are based on open standards such as XForms.

This article explains how you can use Lotus Forms as part of a process with WebSphere Process Server. You will enhance a simple process by adding Lotus Forms at the front end, as well as a way to present the data for human task steps in the process.

Back to top

Business process overview

A simple approval process will be used to demonstrate the capabilities of WebSphere Process Server and Lotus Forms. Let's begin by examining the parts that make up the business process. You can import the file: 0803_fasbinder-InitialProcess_PI.zip (see the Downloads section) to examine the initial process, or the file: 0803_fasbinder-FinalProcess_PI.zip (see the Downloads section) to examine the completed process with forms.

Before you begin, make sure you have installed all of the following:

• WebSphere Integration Developer V6.1 or higher
• A WebSphere Process Server V6.1 or higher test server
• Lotus Forms Server API
• Lotus Forms Designer
• Lotus Forms Viewer

All of the required software is included in the packaging for WebSphere Integration Developer V6.1. If you do not install Lotus Forms Designer, you will not be able to edit your forms. If you do not install the Forms Server API or Forms Viewer, you will not be able to run and test your forms. Lotus Forms Viewer is an application which can also be a plug-in for your Web browser. If you use the Lotus WebForm Server instead, you will not need the Lotus Forms Viewer.

Processes, like other components in WebSphere Process Server, require interfaces. An interface specifies an operation. One-way requests have input messages, while two-way requests have an input and an output. An exception message could also be optionally specified. These messages are based on data types, called business objects, based on the SDO standard. Figure 1 shows the simple data that makes up the request for the process.

Each component in a module can have its own interface, or the same interface could be reused. For this simple example, all components will share the same interface. The interface is made up of a two-way operation called start, with an input and output using the type Request, as Figure 2 shows.

The business process itself is very basic, with just three major steps, as shown in figure 3. WS-BPEL processes always start off with a Receive. The input message of the interface is stored in a variable, and the process flow begins.

A human task Approve Step enables a person to approve or reject the request. It reads from the WS-BPEL variable input1, and writes its output to the variable output1. Initially, the task is set to the default, assigning work to all users, by using the people assignment criteria "Everybody". A WS-BPEL choice activity is then used to direct the process to one of two Java™ snippets: Yes or No. These snippets simply write a message to the console to indicate if the request was approved or rejected. Listing 1 shows the Java snippet for the Yes activity.

Listing 1. Java snippet

System.out.println("It was approved!");

The logic for the choice is specified by clicking Approved, then the details tab. You can specify logic as Java, XPath, simple, or through a graphic snippet, as figure 4 shows. This snippet returns the results of the boolean expression, comparing the requestStatus field of output1 to the string "Approved". No logic is needed for the Otherwise case; it is used if none of the other cases evaluate to true.

Since the interface was two-way, a reply message needs to be sent back at the end. The WS-BPEL Reply activity sends back the response message.

You can test the initial process to make sure it works, by using the BPC Explorer.

1. In your WebSphere Integration Developer, start the server and deploy ApprovalModule. After the module has started, right-click your server, and select Launch => Business Process Choreographer Explorer.
   
   Figure 5. Launching BPC Explorer
   
   
   
2. The BPC Explorer window opens up. If you are prompted about a certificate, click Yes. Log on with the user admin and password admin. This is the default administrative user in the WebSphere Process Server profile which is configured with WebSphere Integration Developer.
3. Click My Process Templates to see a list of processes you can start. You should see RequestProcess in the list. Check the box next to RequestProcess, then click Start Instance.
4. Enter the data for input1, as shown in Figure 6. Optionally, you can enter a process name for the instance. If you do not enter a name, one will be generated for you. When you are done with your input, click Submit to begin the process.
   
   Figure 6. Starting the process
   
   
   
5. The process starts with the human task. Click My To-dos to see the work item created. The task is initially in the Ready state. Select the checkbox for the step, then click Work on. The task is now in the Claimed state.
   
   Figure 7. My To-dos
   
   
   
6. In this step, the user needs to record whether they approve or reject the request. Since you have not created a JSP or a form yet, only the raw data is displayed at this point. Copy the name and amount from the input to the output, and enter a requestStatus of Approved. Click Complete when you are done.
   
   Figure 8. Working on the task
   
   
   
7. The human task is now complete. Based on your input, the process will flow to the Yes step, and a message will appear in the console to show it was approved.
8. Repeat steps 3-7 again, but this time use a value of Rejected for the approval status. You will see a message in the console showing that the request was rejected.
9. Remove the project from the server.

You have now run this very simple process from end-to-end, down both paths. Now that you understand how the process works, you can begin to add additional features. You will modify the process, so before proceeding, remove it from your server.

Back to top

Adding forms capabilities to the process

When testing the request process, you saw two places where a form could be used to improve the user experience: starting the process, when you entered the initial data, and the human task, where the user needed to mark the request as approved or rejected.

Adding a task to start the process

In WebSphere Process Server, there are a number of ways you can start a process. Requests could flow in using JMS, HTTP or WebSphere MQ messaging. Web Services requests could also be used to start a process. APIs can be used, as was done behind the scenes when you tested with the BPC Explorer. There is one additional interface which can be used: tasks. The task interface to a process enables you to create a human task, and use it to start the process. This human task can use a Web front end, as well as portlets and forms. To create the task for starting the process, perform the following steps.

1. In WebSphere Integration Developer, double-click on RequestProcess to edit it. Click on the whitespace in the background, so that the process settings can be viewed. Click the Administration tab. As a default, there are no human tasks defined for the administrative settings. Create a new one by clicking New.
   
   Figure 9. Administrative settings
   
   
   
2. The human task editor opens. As a default, the people assignment criteria for the administrators group is set to Everybody. In a production system, you would need to update this setting. For this simple test, you can leave it at the default. Close the human task editor. The process now has an administrative task. This setting is required before you can create a task to start the process.
3. In the process editor, click the Receive activity which begins the process. In the properties, click the Authorizations tab. Click New to create a human task for starting the process.
   
   Figure 10. Receive authorizations tab
   
   
   
4. The human task editor opens. Potential Starters is set to Everybody as a default. If you wanted to restrict who can start a process, you could update this to an alternative setting. In this case, leave the default value.
5. Configure the task to use a Lotus Forms client. Click the + for user interface, then select IBM Lotus Forms client, as figure 11 shows.
   
   Figure 11. Invocation Task settings
   
   
   
6. The properties will now show a tab for client settings. As a default, there is no form selected. If you have already designed a form, you could browse for it and select it. In this case, there is not an existing form. Click New to generate one. When prompted for the location, keep the default and click OK.
   
   Figure 12. Client settings
   
   
   
7. The client settings are now updated showing that the task is now configured to use the form.
   
   Figure 13. Updated client settings
   
   
   
8. Click on the form name to edit the form. A progress indicator dialog will appear briefly, then the forms editor will be displayed. If you are not able to open the forms editor, you did not install it with WebSphere Application Developer. You will need to go back and install Lotus Forms Designer before you can proceed.
   
   Figure 14. Default generated form
   
   
   
9. The generated form is very basic. It shows the name of the business object, its data fields, and provides an area for input, for each of them. You can now use the functionality of the Lotus Forms Designer to improve the form, and make it look nicer for the user. To enable all of the editing functions, you need to switch perspectives. Click the icon to open a perspective as shown in Figure 15, and select Other, or alternatively select Window => Open Perspective => Other. Select IBM Lotus Forms Designer. The Eclipse perspective will switch to the Forms Designer.
   
   Figure 15. Opening a new perspective
   
   
   
10. When the Forms Designer first opens, by default, not all of its capabilities are available. In the properties tab, click the menu icon, as shown in Figure 16. Select advanced options, so that all the properties are visible.
    
    Figure 16. Accessing menu options
    
    
    
11. It is beyond the scope of this article to go into depth on how to use the Forms Designer. Only a few changes will be made to the generated form. To begin with the requestStatus field is not needed at the beginning. Right-click the input area for requestStatus, and select Delete. Do the same for the requestStatus label.
12. Click the text Request at the top until it is selected. Replace it with something more meaningful, such as "Enter information for your new request".
13. With the text selected, click in the properties on labelfontinfo in the Appearance section. If you do not see this line, make sure you have performed step 10. Click on the value column for labelfontinfo. A button appears with a T. Click the button to open the font editor. Select a different font, such as Impact. Select a larger size, such as 12. Click OK when done. Your form should now look something like the example in Figure 17.
    
    Figure 17. Updated form
    
    
    
14. Save and close the form.
15. Return to the Business Integration perspective.

You have now created a form that will be used to start a process instance.

Adding people assignment criteria

When you initially tested the process, the human task used the people assignment criteria of "Everyone", meaning that all users could perform the work. In a real system, only a subset of users would be authorized for a given task. You will now update the process to use a different criteria for assigning people, assigning work by group.

In order to understand what default groups are available to use the WebSphere Integration Developer V6.1, begin by opening the administrative console.

1. In the server view of WebSphere Integration Developer 6.1, right-click the server. Select Run administrative console. A browser window will open. Logon with the default user admin, with a password of admin.
2. Click the + to expand Users and Groups, then click Manage groups. Click Search to search on group name. A list of groups will appear, as shown in Figure 18.
   
   Figure 18. Groups
   
   
   
3. As a default, there are three groups defined to the Virtual Member Manager: d1, d2 and managers. For this example, you will assign work to managers. The important part to remember is the unique name for the group, in the column on the right. Select the text for unique name, "cn=managers,o=defaultWIMFileBasedRealm" with the mouse, then Ctrl-c to copy the text to the clipboard.
4. Select managers to see details of the group. Choose the members tab. You will see a list of default users in that group. Make a note of one of these IDs, such as dcampbell. All of the default users have a password of "wid".
5. Select Manage Groups to see the list of groups again. Select d1 to find a list of users in group d1. Make a note of one of them, such as jjames.
6. Open RequestProcess to edit it. Select Approval Step, then go to the Properties, and the details tab. You will see how the task is configured to read from the variable input1, and write its output to the variable output1. You will also see the human task being used, RequestProcessTask1. Select the task name, or click the Open button to the right. The human task editor opens.
   
   Figure 19. Approval Step properties details
   
   
   
7. In the properties view, choose the details tab. By default, the people directory JNDI name is set to bpe/staff/userregistryconfiguration. Choose the pulldown menu, and select the sample VMM configuration, bpe/staff/samplevmmconfiguration . This tells the task which plug-in is being used to perform the directory search.
8. By default, potential owners are set to Everybody. You will now update the people assignment criteria to use a group instead. In the top right pane, click Potential Owners. The properties view will show the details in the Assign People tab.
9. Choose the pulldown menu, and select Group Members. The details view will update with the parameters for that particular selection criteria. The GroupName parameter is required. Paste in the value you copied to the clipboard in step 3.
10. Select the value line for IncludeSubgroups. Choose the pulldown menu, and select false. Your settings should look like the ones in Figure 20. Ctrl-S to save the changes.
    
    Figure 20. Setting potential owners to group members
    
    
    
11. If you made any mistakes, it would be difficult if you had to deploy the process to test out who the work gets assigned to. WebSphere Integration Developer solves this dilemma by enabling you to test your people assignment, right in the editor. Click Test to test your people assignment criteria. When prompted for which server to use, ensure that WebSphere Process Server V6.1 is selected, then click Submit. You should see three users found, including dcampbell. If nobody was found, you either did not perform step 7, or the text for the unique name is incorrect.
12. Click OK to exit the test. You now know who the work for the task will be assigned to when the process runs. Do not close the task yet; you will make further updates in the next section.

Creating a form for the human task

As with the human task for starting the process, you can select an existing form to use with task in the process, or you can have one generated for you. To create the form for the task:

1. RequestProcessTask1 should still be open in the task editor. If not, reopen it as you did in the previous section. In the User Interface section, click +, then IBM Lotus Forms Client.
2. No form exists, so click New to generate one. Click OK to accept the default location. The name of the form will be displayed now. Click on the name to edit the form. The form editor will open, as Figure 21 shows.
3. As before, you need to change perspectives to IBM Lotus Forms Designer. You may see the perspective already available, as Figure 21 shows. If not, you can click the icon to open a perspective Other, then select it from the list.
   
   Figure 21. Generated form
   
   
   
4. As you did before, change the heading to something more useful, such as "Enter approval status for the following request". Change the font to something larger, and in bold. Update the text for the labels to something more descriptive as well. The form should now look similar to Figure 22.
   
   Figure 22. Updated form
   
   
   
5. The request approver should not be allowed to alter the data values. For this reason, the name and amount fields should be set to read only. Click on the data entry field labeled requestor. In the properties, in the General section, select readonly. The current value is off. Select off, and an icon for a pulldown menu appears. Click the icon, and select on. The field is now read-only. Repeat for the request amount field.
6. It would be cumbersome for the user to need to type in "Approved" or "Rejected". This also leaves too much room for error, if they were to spell it incorrectly. A better solution is to give the user a pushbutton or radio button to select a choice. From the pallet on the left, click RadioGroup (Select 1), then click on the whitespace below the last line. Drag the corner of the new radio group to resize it larger.
7. In the properties, expand the XForms (select 1) section, and click on ref, as shown in Figure 23. This property is used to tie the radio group to the data used in the form.
   
   Figure 23. Radio group properties
   
   
   
8. Choose on the Instance tab, expand the instance, expand output, then right-click requestStatus. Select Copy Reference, then return to the radio group. Select the value column for ref. You can now paste in the reference. Alternatively, you could click the icon in the value column, and the text editor opens. Enter instance('output1')/requestStatus, then click OK. If you know the right syntax, typing in might be faster and easier for you. Using the copy reference & paste method has the advantage of reducing the possibility for errors.
   
   Figure 24. Forms pallet
   
   
   
9. On the pallet, choose Choice (Item) as Figure 24 shows, then click inside the radio group in the form. In the properties, expand XForms (item) and label. Choose on Text, then click in the value column, and enter Approved. Expand value, choose Text, and enter Approved. This feature enables you to show one label, but set the field to a different value. The choice (item) should now look like Figure 25.
   
   Figure 25. Item properties
   
   
   
10. Repeat step 9 to add a second choice (item), with a label and value of Rejected.
11. Delete the input field for status. Arrange the radio group so that both options are on a line together. Move the radio group to the location where the field was you just deleted. Your form should now look like Figure 26.
    
    Figure 26. Completed form
    
    
    
12. To see how the form will look at runtime, click the Viewer tab. After a few moments, you will see the runtime view of the form. Verify that the requestor and request amount fields are read-only. Click on the button for each status option. When you are done, return to the design tab, and save your changes.
13. Close the form. You are now back at the human task. Save the task, then close it. Perform a Save-all, in case you forgot any other updates, by typing Ctrl-Shift-S.

You have now completed the process and the form.

Generating the user interface application

There is one final step required before deploying and testing the solution. As you have seen previously, the BPC Explorer can be used to test a process. However, it is not a tool designed for end-users. Instead, a custom client application can be used. WebSphere Integration Developer has the ability to generate the client for you, without programming.

1. Make sure you are in the Business Integration perspective. Eclipse wizards are context sensitive. If you are in a different perspective, you will see different options when you right-click an object.
2. Right-click ApprovalModule, and select Generate User Interfaces A wizard will appear. For the generator type, select IBM Lotus Forms client, as shown in Figure 27. Ensure that both ApprovalStep and Receive are checked, then click Next.
   
   Figure 27. Selecting generator type
   
   
   
3. Enter Approval_UI for name of the web project to be generated. Optionally, click Browse to point to an image of your company logo, and/or select one of the styles for the generated project. Click Next.
4. You will see a list of which tasks will be based on forms, and which will be based on JSPs, as show in Figure 28. If you do not see this screen, you did not select the proper generator type. You can click Back and redo the previous steps if you made a mistake.
   
   Figure 28. IBM Lotus Forms client configuration
   
   
   
5. Click Finish to complete the process. This will take a little time, depending on the speed of your machine. When you see the success message, click OK.

WebSphere Integration Developer has now generated a custom client for your application. In the upper right pane, in the Business Integration view, you will see that two projects have been created: Approval_UI and Approval_UIEAR.

Deploying the solution

You are now ready to deploy the updated process and the generated client to your test server. Ensure the server is running, then add the projects to the server.

1. In the server view, right-click your server and select Add and remove projects. Click Approval_UIEAR, then Add. Repeat for ApprovalModuleApp, then click Finish. The projects will publish to the server.
2. When you see messages in the console that both applications have started, you can proceed to testing.

Testing

You are now ready to test your final application. Since you previously tested the process, you know it works correctly. Now you can concentrate on testing. First, test the people assignment criteria.

1. As you did before, right-click the test server, and select Launch  Business Process Choreographer Explorer. Logon with user ID admin and password admin.
2. Click My Process Templates, select the checkbox for RequestProcess, then click Start Instance. Enter a name and an amount, then click Submit. The process is now started.
3. Click logout. Log back in with user ID jjames, and password wid. As you saw previously, jjames is not in the managers group. My To-dos will be empty, since jjames is not in the group.
4. Click logout. Log back in with user ID dcampbell, and password wid. In My To-dos, you will now see Approval Step. You have verified that work is being assigned just to users of the group.
5. Select the checkbox for Approval Step, then click Work On. As you did before, enter Approved or Rejected for the requestStatus, then click Complete.

Now it is time to test out the generated client.

1. Open a Web browser, and enter the URL http://localhost:9081/Approval_UI .
2. At the Log on to business user client screen, use the user ID admin, with the password of admin.
3. Under the Business Case heading, click New. This will show you a list of all the processes you can start. There is only one, named Receive. The name comes from the first task of your process, with the human task you previously created. In a production system, you would of course select a more meaningful name.
4. Click Receive to start the new business case. The form will load, as shown in Figure 30. The initial load of a form will take a while, since nothing is cached. Subsequent loads will occur much faster.
   
   Figure 30. New business case
   
   
   
5. Enter your name, and a number, then click Create. An instance of the process is started.
6. Under the My ToDo's heading, click Open. You will see just one task on your list. Click on the task name to select it. Since you started the process as admin, you are authorized to perform the tasks. Alternatively, you could log out and log back in as dcampbell as you did in the previous test.
   
   Figure 31. Viewing the task data
   
   
   
7. When you first click on a task, you are only viewing it. If you have a large number of tasks, you might want to be able to look through them to find "the right one" you want to work on. You do no actually start working on the item until you claim it. Since you are just looking at the data, you will find that all of the fields and radio buttons are read-only. To claim the task now, click Claim.
8. The task is now claimed. You can click the button for Approved or Rejected. If you hover over the buttons on the top, you will see that you can perform actions like saving the form, printing the form, emailing the form, and so on. There are three buttons from the generated client. Release would "unclaim" the work item, and set it back to the ready state. Save would save the work so you could resume later, including any updates you’ve made to the data. Complete means you are done with the work. Select a status for approval, then click Complete.
9. Check the console to verify the message for the subsequent task.

You have now tested the entire process and user interface.

Back to top

Conclusion

In this article, you learned how Lotus Forms can work with WebSphere Process Server to:

• Generate a form for a human task in a business process.
• Assign work to a group, using the Virtual Member Manager.
• Make updates to the form using the Lotus Forms Designer.
• Generate a custom client application using the forms.
• Deploy and test the process and the generate the client.

Hopefully, this article has provided the information you need to build business processes with human tasks using Lotus Forms and WebSphere Process Server.

Trademarks

• IBM, and WebSphere are trademarks or registered trademarks of IBM Corporation in the United States, other countries, or both.
• Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

Back to top

Downloads

Information about download methods

Resources

• WebSphere Process Server
  Get the details you need to get started with WebSphere Process Server.
  
  
• WebSphere Business Integration zone
  Provides application connectivity and business process management technical resources.
  
  
• IBM developerWorks WebSphere Process Server and WebSphere Integration Developer resource page
  Provides technical articles and tutorials for WebSphere Process Server and WebSphere Integration Developer.
  
  
• Lotus Forms product page
  Find the resources you need to get started on the Lotus Forms product page.
  
  

About the author

Marc Fasbinder is an I/T Specialist at IBM with the WebSphere Technical Sales team in Southfield, Michigan. You can reach him at mfasbind@us.ibm.com.

Comments

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Overview
• Business process overview
• Adding forms capabilities to the process
• Conclusion
• Downloads
• Resources
• About the author
• Comments

Next steps from IBM

• Try: Lotus Forms
• Demo: Create an electronic form solution with DB2 pureXML and Lotus Forms
• Briefing: Smarter collaboration with IBM Lotus solutions
• Buy: Lotus Forms

My developerWorks community

Dig deeper into WebSphere on developerWorks

Cloud computing for developers

Virtual workshop: Learn how to build a cloud infrastructure and develop/deploy cloud-based applications. (6-8 Apr 2010)

Special offers