Level: Introductory Dr. Wilfred Jamison (wjamison@us.ibm.com), Senior Software Engineer, IBM
Andreas Nauerz (andreas.nauerz@de.ibm.com), Software Engineer, IBM
21 Feb 2006 In Part 15 of this series, you were introduced to IBM WebSphere® Integration Developer (Integration Developer) V6.0 as part of an insurance claim scenario. In this installment, you add human tasks, the steps in a workflow that require user action. You also find out how to include human tasks within your Business Process Execution Language (BPEL) process. And you also exploit WebSphere Portal V5.1.0.3 business process integration capabilities.
Introduction
In Part 15 of this series, a subset of an insurance claim scenario was used to demonstrate the basic concepts and methodology of IBM WebSphere Integration Developer (Integration Developer) tool. In this article, you review the complete insurance claim scenario and learn how:
- Human tasks can be added to a BPEL process using Integration Developer's BPEL editor.
- Business process integration, introduced in Part 9 as process portal, can be exploited to process human tasks.
- Security is configured as a requirement for human tasks.
Snapshots of the insurance claim application on WebSphere Process Server V6.0.1 (Process Server) and WebSphere Portal V5.1.0.3 (WebSphere Portal) are also included.
Understanding human tasks
Human tasks are manual activities that involve user intervention in a business workflow process. A human task can involve an IT operation, such as filling out a form on the computer or it can be purely manual, such as signing a document for approval. Establishing business processes within an enterprise is important because efficiency is increased, and thus, it helps achieve a competitive advantage. But processes must also be surfaced to the user responsible for executing single tasks as part of the workflow. Therefore, a usable, consistent, and powerful GUI should be available to provide the interface. The time to complete a manual step is indeterminate and cannot be guaranteed. For this reason, BPEL processes with human tasks are also called long-running processes.
Security is also a concern when human tasks are introduced. Since users are involved in the execution of human tasks, a real production system takes into account who is authorized to execute a particular manual step in the organization. For example, you would not want a customer service representative to be able to approve or disapprove a claim application.
The insurance claim scenario
The simple scenario in Part 15 deals only with the creation of insurance claim records. In this article, the project is extended using an end-to-end scenario for claim processing. Figure 1 shows the assembly diagram of the entire insurance claim scenario. Part 17 introduced the concepts of high-touch and express (or low-touch) claim. In this article, the focus is on the low-touch claims subpart of the process, as shown by the dashed box in Figure 1.
Some of the component labels you saw in Part 15 in the Create Process process have been modified, including AssignAdjuster and EmailCustomer (originally labeled Send Explanation) in the doLowTouch process.
Figure 1. Complete assembly diagram for insurance claim
Note: The WebSphere Integration Developer project interchange for the entire insurance claim scenario is available for you to download, including all other artifacts you need to install and run the application in your own environment. (Simply click the Sample code icon.) You can find all of the succeeding examples in the project interchange.
The doLowTouch process
The doLowTouch process handles all express claim records. Figure 2 shows the doLowTouch
BPEL process. The process receives a claimData business object, and checks whether the claim has enough or valid coverage by calling a Web service. If the check fails, the claim is rejected and an e-mail notification is sent to the applicant. Otherwise, further processing is
performed by assigning an insurance adjuster using the business rules created in Part 15.
Figure 2. doLowTouch BPEL process
The succeeding invocations of four BPEL processes all involve human tasks.
- contact
- Requires an
insurance adjuster to set appointments with the applicant and to inform both the field adjuster and the applicant regarding
these appointments
- process
- Involves estimating costs to fix the damage both by the
field adjuster and some potential vendors (This information is relayed to the insurance company and entered into the system.)
- settle
- Informs applicant of the approved amount by the insurance company (The applicant
indicates whether to accept this amount or not.)
- close
- Closes the claim, regardless of
the applicant's settlement decision (If applicant agrees with the amount, the claim is closed as soon as payment is received.)
The three Web services applications used in Part 15 are also used in this scenario, which are:
- CRM Web services (provides services related to customer information)
- Policy Web services (provides services related to insurance policies)
- Claim Web services (provides services related to the processing of a claim record)
Creating your human task
Only the contact process is used to illustrate the creation and configuration of a human task, since these steps are basically the same for all of the other human tasks. Figure 3 shows the BPEL implementation of the contact process, with annotations for the first few steps to initially create a human task.
Figure 3. Creating a human task with the BPEL editor
Each human task must have a corresponding interface. By clicking New indicated in the preceding step 4, a window appears with a list of interfaces to choose from. Thus, you should have created earlier an interface for the human task that you are currently creating. In the example, we created the ContactTaskInterface shown in Figure 4.
Figure 4. Interface used for Contact Customer task
There is only one operation in this interface. The business object ClaimData has already been created. Once the interface is chosen, the human task definition is created, as shown in Figure 5.
The name created by Integration Developer for this task is ContactTask1. Click the ContactTask1 button and the properties display in the lower half of the figure. In the simplest case, these definitions are sufficient and you can simply save this configuration.
Figure 5. Human task configuration editor for Contact Customer
In Figure 6, ContactTask1 now appears as the chosen configuration for the Contact Customer human task after assigning the ContactTaskInterface. The next step is to create and map variables for each input and output parameter defined by the interface.
Figure 6. Assigning variables for Contact Customer task
When a human task is created in your BPEL process, you should set it as a long-running one. You can do this on the Details panel under the Properties tab of the BPEL process, as shown in Figure 7.
Figure 7. Assigning variables for the Contact Customer task
At this point, you've created a human task for the contact process labeled Contact Customer. When this human task is reached during the execution of this process, it suspends itself and waits until the task is completed. In the next section, you will create a portal front end for completing human tasks.
Using WebSphere Portal to process your human tasks
The Business Process Engine (BPE) is a component of WebSphere Process Server that is designed to execute BPEL processes. The Web client that comes with BPE
can be used to process and complete human tasks. However, the tool's primitive and inflexible user interface does not lend itself to production systems, but more for testing purposes only.
Business process integration
WebSphere Portal V5.1.0.3 and the BPE of WebSphere Process Server V6.0.1 developed a mechanism where they can interact with each other and allow a portal server to process human tasks through portlets. This allows for a variety of workflow types to be handled: productive workflows, where human tasks are used for exception handling, or collaborative workflows, where human tasks are the essential key components of the flow.
WebSphere Portal first eases the setup of the process container and ensures both products work together. It comes with a generic My Tasks
portlet for a user to see, claim, and process tasks assigned to him. Alert mechanisms notify users
as soon as new tasks become available, and redirect them to the panel containing the My Tasks portlet.
As part of the development process and specific to every workflow, you generally have to develop a:
- Process initiating portlet, to create and kick-off an instance of a process template
- Task processing portlet, that is associated with a task
with which a user can enter information and trigger the completion of that task, and relay the information back to the BPE
Figure 8 shows a simple, high-level diagram of the runtime flow of business process integration.
A BPEL process runs in the BPE.
Figure 8. High-level business process integration
The My Tasks portlet is used in the portal server, which lists all to do tasks (tasks that need
to be worked on and completed). When a human task is reached in the BPEL process execution, a to do task is added in the My Tasks portlet. You can claim a task, such as Task 1, to work on it and then click it to be redirected to a task panel to process it. Processing can involve manual steps, such as submitting a form for approval or sending a fax copy of a document to another office. Eventually, you have to go back to this claimed task and execute its task-processing portlet. That portlet may be as simple as clicking a button to indicate that the task is completed, or it may include filling out more information in a form. Once this is done, a completed task object is passed back to the owning BPEL process.
Task pages are dynamic pages introduced in WebSphere Portal 5.1.0.1. Task pages of the same page type can have multiple instances that can be launched on demand. This is a powerful feature because it allows for interruptible processing of a form; another instance of the page can be processed without losing the state of the previous instance. When the interrupting page is done, you can proceed with
the processing of the previous page from where the user left off.
For business process integration to work, both WebSphere Process Server and WebSphere Portal should be configured so they can properly communicate with each other.
The BPE has provided APIs -- most important, the Human Task Manager API. For example, the portal server needs to have the client code to
call the BPE APIs, and the hostname and listening port, of the Process Server.
Our configuration uses a single instance of Process Server to host both the insurance claim application and the portal server, shown in Figure 9. For instructions on how to set up business process integration, see the WebSphere Portal Information Center.
Figure 9. Software stack for insurance claim scenario
After the configuration is in place, you'll need to do a few more steps to complete the setup. You need to write a processing
portlet for the human task, install the portlet on a page in the portal server, and associate the human task with that page
using a unique name.
Task-processing portlets using JSF
JavaServer Faces (JSF) portlets was used to develop the task-processing portlets using Integration Developer's Web Perspective. Make sure that the portal toolkit is installed. The capabilities of IBM Rational® Application Developer 6.0.1.1 tooling were exploited to create process initiation
and task processing portlets automatically.
 | | Creating JSF portlets is beyond the scope of this article. A more detailed discussion, as it relates to business process integration, is planned for a forthcoming article. |
|
The following is an overview of the code required to complete our
task processing portlet for the ContactTask1 task. This code is generated automatically by Rational Application Developer. All you need to do is to supply the portions specific to the business logic.
Listing 1 shows the init
method of the class ContactPortlet, which extends the class FacesGenericPortlet.
This method is called whenever the portlet is created. It essentially gets a reference to the
HumanTaskManager that resides in the Process Server where the insurance claim is running.
Listing 1. init method of ContactPortlet
public void init(PortletConfig portletConfig) throws PortletException {
try {
String url = "iiop://localhost:2809";
Hashtable env = new Hashtable();
env.put(Context.PROVIDER_URL, url);
Context ctx = new InitialContext(env);
HumanTaskManagerHome humanTaskManagerHome = (HumanTaskManagerHome)
ctx.lookup ("com/ibm/task/api/HumanTaskManagerHome");
if (humanTaskManagerHome != null)
this.humanTaskManager = humanTaskManagerHome.create();
} catch (Exception e) {
e.printStackTrace(System.out);
}
super.init(portletConfig);
}
|
Listing 2 shows the processAction that is called when the
Contact Customer task is executed. This is the point of communication when a to do task object gets passed to
the portal server from the BPE. The first half of the method keeps the page contexts into the portlet session and the
internal task ID assigned for this task. The second half retrieves the input parameter of the Contact Customer task,
which in this case is called claimRequest (as defined in the contactTaskInterface). It is then placed into the
portlet session for access by the JSF portlet.
Listing 2. processAction method of the ContactPortlet
public void processAction(ActionRequest request, ActionResponse response) throws
PortletException {
PortletSession portletSession = request.getPortletSession();
String specialAction = request.getParameter("com.ibm.portal.action");
if (specialAction != null) {
if (specialAction.equals("com.ibm.portal.pagecontext.receive")) {
java.util.Map contextMap =
(java.util.Map) request.getAttribute("com.ibm.portal.pagecontext.context");
DynamicPageHandle taskUIHandle =
(DynamicPageHandle) contextMap.get("TaskUIHandle");
String dynamicUIConfig = (String) contextMap.get("DynamicUIConfig");
ObjectID returnPageID = (ObjectID) contextMap.get("ReturnPageID");
ObjectID taskPageID = (ObjectID) contextMap.get("TaskPageID");
String taskID = (String) contextMap.get("TaskID");
portletSession.setAttribute("TaskUIHandle", taskUIHandle);
portletSession.setAttribute("ReturnPageID", returnPageID);
portletSession.setAttribute("TaskID", taskID);
portletSession.setAttribute("DynamicUIConfig", dynamicUIConfig);
portletSession.setAttribute("TaskPageID", taskPageID);
if (this.humanTaskManager != null) {
try {
Object obj = ((ClientObjectWrapper)
this.humanTaskManager.getInputMessage(taskID)).getObject();
if (obj instanceof DataObject)
DataObject claimRequest = ((DataObject) obj).getDataObject
("claimRequest");
if (claimRequest != null)
portletSession.setAttribute("claimRequest", claimRequest);
} catch (Exception e) {
e.printStackTrace(System.out);
}
} else {
System.out.println("failed to initialize");
}
}
super.processAction(request, response);
}
|
Figure 10 shows the JSF portlet design for the Contact Customer task. Some of the values in the fields
are taken from the claimRequest object of the current portlet session.
Figure 10. Portlet design for Contact Customer
Listing 3 shows the code that
gets executed when Submit is selected.
First, it creates a reference to the HumanTaskManager where the insurance claim runs. Using the task ID assigned
for this task, the object response is retrieved (which is called claimResponse, based on contactTaskInterface).
Once retrieved, the object is populated with the responses gathered from the JSP form. The completed object is then passed
back to the BPE through the HumanTaskManager APIs. Note that the task is marked completed in the end.
Listing 3. Action code for Submit in the JSF portlet for Contact Customer
public String doButton1Action() {
// code that runs when Submit button is clicked
try {
String url = "iiop://localhost:2809";
Hashtable env = new Hashtable();
env.put(Context.PROVIDER_URL, url);
Context ctx = new InitialContext(env);
HumanTaskManagerHome humanTaskManagerHome = (HumanTaskManagerHome)
ctx.lookup("com/ibm/task/api/HumanTaskManagerHome");
if (humanTaskManagerHome != null) {
HumanTaskManager humanTaskManager = humanTaskManagerHome.create();
String taskID = (String) sessionScope.get("TaskID");
ClientObjectWrapper outputMessage = humanTaskManager.
createOutputMessage(taskID);
DataObject outMessage = (DataObject) outputMessage.getObject();
if (outMessage != null) {
DataObject outData = outMessage.getDataObject("claimResponse");
if (outData == null )
outData = getClaimData();
outData.setString("AgentNotificationDate", getAgentNotificationDate());
outData.setString("AdjusterNotificationDate",
getAdjusterNotificationDate());
outData.setString("InsuredNotificationDate", getInsuredNotificationDate());
outData.setString("AppointmentDate", getAppointmentDate());
outMessage.setDataObject("claimResponse", outData);
} else System.out.println("failed to get outMessage");
ClientObjectWrapper cow = new ClientObjectWrapper(outMessage);
humanTaskManager.setOutputMessage(taskID, cow);
humanTaskManager.complete(taskID);
}
else System.out.println("failed to locate the ejb");
facesContext.getExternalContext().getResponse());
} catch (Exception e) {
e.printStackTrace(System.out);
}
return "Submit";
}
|
Portlet installation on a task page
After creating the portlet, it needs to be installed in the portal server. In the Administration section of WebSphere Portal, you see how to install the Web module that contains the JSF portlets written earlier. Then you create a page called Contact Customer that contains the Contact Customer portlet. Finally, create a new page definition
and assign a Unique name for this page definition. The page should be placed under Context Root > Task page definitions so
that page definitions cannot be seen as part of the normal navigation.
Assign a unique name by going through
Portal Settings > Custom Unique Names > Pages. Search for the Contact Customer page. On the right side, select the Edit Unique Name for Page icon. Figure 11 shows the unique name we assigned for the
Contact Customer page definition.
Figure 11. Assigning a unique name
Associating a human task with a task page
The last step is to associate the ContactTask1 human task to the page just created. Figure 12
brings you back to the ContactTask1 definition page. The annotations in Figure 12 highlight the key points to remember.
Figure 12. Associating ContactTask1 with the Contact Customer Page
Perform these steps on the remaining human tasks. Using Integration Developer you can build, deploy, and export a J2EE enterprise application for installing on
WebSphere Process Server.
Finally, you will go back to the Properties tab of the Contact Customer human task, as shown in Figure 13.
Under the Description page, just remember that whatever you write in the Display Name field for
this task appears as the task name when shown in the My Tasks portlet. Similarly, the description you enter will also
appear in that portlet.
Figure 13. Display Name and Description for the Contact Customer task
Securing your WebSphere Process and Portal Servers
Security is important when executing long-running BPEL processes. A business organization must ensure that manual steps are executed only by a user with proper permission. When installing a BPEL application that contains human tasks, you need to enable global security in the target process server.
Figure 14 shows the global security settings. LTPA is required as the authentication mechanism.
Click the Authentication mechanisms on the right side, select LTPA, then create
the Lightweight Third Party Authentication (LTPA) token by providing a password.
Figure 14. Process server global security settings
We've used LDAP as the user registry. This is necessary because WebSphere Portal is running on this process server. Make sure that you have a running LDAP server. Click LDAP to configure your LDAP settings.
As an example, the LDAP settings are shown in Figure 15.
Figure 15. LDAP settings
J2C authentication data
It is very important to set your Java™ Authentication and Authorization Service (JAAS) configuration correctly. From the Global security panel, click to go to the J2EE Connector (J2C) authentication aliases. You must map all aliases to existing users in your user registry. Figure 16
shows a portion of J2C aliases table.
Figure 16. J2C authentication aliases
SCA_Auth_Alias is especially important because it is initially bound to something that does not exist.
Make sure to change the value. Otherwise, you will get many errors when process server tries to authenticate with the service integration bus.
Console users and groups
A possible source of security problems are the console users and console groups. Make sure you provide
values in these two entries. Figure 17 shows the console users that were created.
Notice that wpsbind is the one that is currently active; the user is logged on as wpsbind).
Figure 17. Console users
Figure 18 shows the console groups, where the predefined group, EVERYONE, is given the administrator role.
Figure 18. Console groups
Map RunAs and security roles
Finally, you need to map the RunAs and security roles for both the BPE and task containers. Go to
Enterprise Applications and click the BPEContainer application. In the Additional Properties column, click Map RunAs roles to users. You will see an entry for JMSAPIUser, as shown in Figure 19.
Make sure that the user name that is mapped to it is a valid user in your user registry.
Figure 19. Mapping RunAs roles to users for the BPEContainer
Go to the Additional Properties column, click Map security roles to users/groups.
Select BPESystemAdministrator for this BPEContainer application, as shown in Figure 20.
You can choose to map this role to: Everyone, All Authenticated, or Mapped Users/Group.
Figure 20. Mapping security roles to Users and Groups
Figure 21 shows how to map users to the selected role (in this case, BPESystemAdministrator).
All available users are presented on the left side. Click the user name and move it to the right side using the arrow.
You can also do the reverse direction. The interface is similar for mapping groups; a list of groups instead of users will display on the left side.
Figure 21. Selecting users for mapping to security role
The steps are similar for the TaskContainer application. The RunAs role, EscalationUser, must be mapped to a valid user name, as shown in Figure 22.
Figure 22. Mapping RunAs roles to Users for the TaskContainer
As for the security role, you should map users or groups to the security role, TaskSystemAdministrator, shown in Figure 23.
Figure 23. Mapping the TaskSystemAdministrator
Security must be enabled for the WebSphere Portal as well. The WebSphere Portal Information Center provides "how to" information. Basically, you'll have to edit the wpconfig.properties and then execute at least two commands
under $(PORTAL_HOME)/config directory:
-
WPSConfig validate-ldap
-
WPSConfig enable-security-ldap
Running the insurance claim scenario
To summarize this discussion, the following snapshots show the running application. A basic portlet was written, shown in Figure 24, that allows a user to enter information about a claim.
Figure 24. Portlet for submitting a claim
You can submit a claim by selecting Submit. Consequently, a BPEL process instance of the InsuranceClaim process template
is created and starts executing. This instance was implemented using the BPE APIs. And the doLowTouch process will be executed by checking the Express Claim field in the portlet.
Next, the My Tasks portlet is installed in the portal server as part of the business
process integration configuration. Figure 25 shows the My Tasks portlet and the list of outstanding tasks.
Figure 25. My Tasks portlet
When the claim was submitted previously, a claim record was created and eventually it reached the Contact Customer human task.
So now you can see the Contact Customer task in the first line. To be able to work on this task, you need to claim it first by
clicking the box to its left and selecting Claim. Figure 26 shows the state of the My Tasks
portlet after claiming the task.
Figure 26. After claiming a task
Notice that when a task has been claimed, it becomes a link that goes to the task processing portlet for that given task.
For example, if you click the first Contact Customer task, the panel shown in Figure 27 displays.
Figure 27. Task processing portlet for Contact Customer
This is the task processing portlet for Contact Customer discussed previously.
A user can enter information in the editable fields just shown. Select Submit when done, and the page in Figure 28 appears.
Figure 28. Message after executing task processing portlet
Go back to the My Tasks portlet by clicking the tab to refresh it. You can see that the Contact Customer
task has disappeared, but a new task appears. Remember in Figure 2 that following the contact
process is the process process, which itself has a human task called Process Claim. Figure 29
indicates that the BPEL process that was originally in the Contact Customer task has now proceeded and reached
another human task called Process Claim. Again, this process needs to be claimed before its task processing portlet can
be executed.
Figure 29. My Tasks after completing a task
The processing of one claim application proceeds from the contact process to the close process. After the task processing
portlet for the Close Claim task is executed, the claim application is completed and should no longer appear in the My Tasks
portlet.
Summary
In this article you got a detailed overview about how human tasks can be created and added to a BPEL process using WebSphere Integration Developer's BPEL editor. You also learned how WebSphere Portal can be used as a GUI client to the Business Process Engine of the WebSphere Process Server for handling and processing human tasks. We also showed the required security configuration in the Process Server run time when
installing a BPEL application with human tasks. Finally, you were guided through a sample execution of the insurance
claim scenario.
Stay tuned for future articles where you'll create task processing portlets using Rational Application Developer V6.0.1.1.
Download | Description | Name | Size | Download method |
|---|
| Project installables for Insurance Claim App | i-odoebp18code.zip | 683KB | HTTP |
|---|
Resources Learn
-
Series overview: Link to previous articles and read about this series, which demonstrates to business analysts, solution designers, and architects how to design and implement on demand solutions using the thirteen capabilities of the IBM On Demand Operating Environment.
-
Part 15 of this series: Read this article to learn the basics of WebSphere Integration Developer.
-
Part 9 of this series introduces the process portal.
-
WebSphere Process Server: Provides an overview, features, benefits, system requirements, and more.
-
WebSphere Integration Developer: Learn about WebSphere Integration Developer and related software.
-
IBM WebSphere Portal InfoCenter: Provides extensive information need about WebSphere Process Server and WebSphere Integration Developer.
-
Dynamic UIs: Learn more from the WebSphere Portal Info Center.
-
"Developing business process portal applications using WebSphere tooling" (developerWorks, May 2005): Provide your end users with a way to more efficiently process tasks.
-
"WebSphere Process Server: IBM's new foundation for SOA" (developerWorks, Sep 2005): Read about the major WebSphere Process Server capabilities, features, and solutions, and references to other resources for you to learn more.
-
Business Process Execution Language for Web Services Version 1.1: Get the specification. BPEL4WS provides a language for the formal specification of business processes and business interaction protocols.
-
New to SOA and Web services: Visit this content area if you are new to Service-Oriented Architecture and Web services.
-
"Building SOA solutions with the Service Component Architecture, Part 1" (developerWorks, Oct 2005): Read this related article.
-
"Introduction to Service Data Objects: Next-generation data programming in the Java environment" (developerWorks, Sep 2004): A good starting point to learn about Service Data Objects.
Get products and technologies
Discuss
About the authors | 
| | Dr. Wilfred Jamison currently works with the IBM On Demand Software Development team and is heavily involved with many projects pertaining to business innovation, optimization, and service-oriented architecture (SOA). His expertise also includes distributed systems, performance analysis, Web services, software agents, and others. He is heavily involved in the Tonawanda project and is currently looking into DataPower to extend the capabilities of this project. Contact Dr. Jamison at wjamison@us.ibm.com. |
| 
| | Andreas Nauerz works as Software Engineer for the IBM Laboratories at Boeblingen, Germany. His current work areas include Business Process Integration and Dynamic UI Management. He studied Computer Science at the University of Cooperative Education of Mannheim, the University of Staffordshire, the University of Saarbrücken, and the University of Hagen. Contact Andreas at andreas.nauerz@de.ibm.com. |
Rate this page
| 
