IBM® WebSphere ® products documentation and various developerWorks® articles cover some of the information in this article. However, those documents do not provide all of the critical set up and implementation details for the remote access scenario. Collecting this information in one place and providing simple samples is intended to save the reader time in developing such portlet applications.

Setting up the runtime environment

This article focuses on communication between a portlet running on IBM WebSphere Portal and a business process running on a remote IBM WebSphere Process Server. The samples included with this demo were tested on a runtime environment that was installed as follows:

• For the WebSphere Portal installation:
  1. Install WebSphere Portal V6.0.0.0. Allow the Portal installer to install WebSphere Application Server - Network Deployment. Do not select the option to install WebSphere Process Server. That option is labeled Install business process support and enables a process portal, which is a WebSphere Portal running on a WebSphere Process Server. Be sure to follow the detailed installation steps in the product documentation.
  2. Upgrade WebSphere Application Server to V6.0.2.17. The Portal installer installs Application Server V6.0.2.9, but a higher level is required. Use the Application Server update installer to install the updates.
  3. Upgrade WebSphere Portal to V6.0.1. Obtain the 6.0.1 update from the product support page.
  4. Install WebSphere Process Server Client 6.0.2. In the installer, select the option to use an existing WebSphere Application Server installation and select the Application Server that Portal uses. Select the option Client Installation. The client installation adds a ProcessChoreographer directory under the root directory of Application Server and adds Process Server APIs (including the taskapi.jar file for human tasks) to the lib directory. Later, this article talks about adding stubs for the APIs to the portlet WAR file. If the Process Server Client is not installed, many NoClassDefFoundExceptions occur when you try to run the portlet application.
  5. Install WebSphere Portal 6.0.1 fixes. Download the 6.0.1 critical fixes from the support page.
  6. Run the WPVersioninfo script from the Portal bin directory to verify that the Portal version is V6.0.1.0. Run the versioninfo script from the Application Server bin directory to verify that the Application Server is V6.0.2.17 and WebSphere Process Server Client is V6.0.2.0.
• For the remote WebSphere Process Server, install the following products and upgrades:
  1. On a different WebSphere Application Server on the same system as WebSphere Portal or on a different machine, install WebSphere Process Server V6.0.2.
  2. (Optional) Update WebSphere Process Server to V6.0.2.2. At the time that this article was written V6.0.2.2 is the latest update for V6.0.2. The update is not required for this scenario. The sample portlets work with both versions.
  3. Run the versioninfo script from the Process Server bin directory to verify that the Portal version is V6.0.2.0, or V6.0.2.2 if you applied the optional update. Verify that WebSphere Application Server is V6.0.2.17, or V6.0.2.19 if you applied the optional update.

Developing the business process application

The business process application in the sample BadgeProcessPI.zip was developed in IBM WebSphere Integration Developer V6.0.2.6, using IBM WebSphere Process Server V6.0.2 as the test environment. Figure 1 shows the assembly diagram of the process application. BadgeProcess is a process for requesting an employee badge and consists of two Java™ components and one human task component (CreateSecurityIncident). The human task is invoked when a badge application fails the check to determine if the applicant is a current employee. To simplify the code for the process component VerifyEmployeeStatus, badge applications that contain a serial number that begins with an even number are flagged with a non-employee status and the rejected request is routed for investigation as a potential security incident.

If you are not familiar with developing a business process application, see Resources for a reference to a tutorial in the WebSphere Integration Developer product documentation. The tutorial provides step-by-step instructions for assembling a process and implementing the process components. See Downloads for the BadgeRequestModuleApp.ear file for deploying the business process to WebSphere Process Server and the Project Interchange file (BadgeProcessPI.zip) that you can import into WebSphere Integration Developer for a closer look at the underlying code. See Using the sample applications for detailed instructions.

The portlet application needs a copy the WSDL and schema files from the business process application because the portlet must retrieve the input message for the human task and create an output message when the task is completed. The WSDL and XML schema files contain the definitions of the complex data types used in those messages. When the business process application is completed, package those artifacts from the WebSphere Integration Developer project.

NOTE: If you do not have the project file for your business process application, you can extract the relevant files from the application EAR file. The files will be in a JAR file inside the EAR file. To package the files from the project, follow these steps:

1. In WebSphere Integration Developer, switch to the Web perspective.
2. On the Project Explorer tab, navigate to the folder that contains the WSDL and schemas files for the data types. Figure 2 shows that folder for the BadgeProcess application.
3. If the folder for the schema files includes a subfolder labeled xsd-includes, click a file in the subfolder. Otherwise, click the schema folder. Then click Export on the right-click menu.
4. In the wizard, select JAR file as the export destination, and then click Next.
5. Follow the instructions in the wizard to select all of the WSDL and schema files to export. Keep the JAR file until you are ready to add it to your portlet application. In the sample portlets for this article, the export JAR file is BadgeRequestExports.jar. The file contains ten WSDL and schema files for the four data types: BadgeOrder, EmployeeInput, EmployeeVerification, and SecurityIncident. Except for EmployeeInput, the data types are complex.

Back to top

Developing the portlet application

The samples for this article include basic and cooperative portlets developed in IBM Rational® Application Server V7.0.0.4, using an external WebSphere Portal V6.0.1.0, as the test environment. In Downloads, the project interchange file for the basic portlet is SecurityIncidentPI.zip and the cooperative portlets are in SecurityCoopPI.zip. In both cases, the portlets are JSR 168 portlets and are not Java Server Faces (JSF). Using non-JSF portlets simplified the samples and made it easier to highlight the sections of the code that enable interaction with the remote human task manager.

If you are new to portlet development, there are many resources to help you understand the basics. In addition to those basics, ensure that the application includes the essential elements for remote access described in the subsections that follow.

Add the WSDL and schema files to the portlet project

As discussed in the section Developing the business process application, the portlet needs the WSDL and schema files that define the complex data types for the remote business process. To add a copy of the archive to the portlet project, follow these steps:

1. Copy the JAR file for the schema and WSDL files that you exported from the business process application.
2. In IBM Rational Application Developer, open the portlet project.
3. In the Web perspective, navigate to the folder WebContent/WEB-INF/lib.
4. Paste the JAR file into the lib folder. That action adds the JAR to the build path. In the Project Explorer, the JAR file is listed under Java Resources - Libraries - Web Libraries. When the application WAR file is created, the file is included in the WEB-INF/lib directory.

Add the Task API stubs to the portlet project

The portlet must use classes in the package com.ibm.task.api. For the remote access scenario, stubs for the Task API must be in the portlet WEB-INF/lib directory. To add the stubs, follow these steps:

1. On the system where WebSphere Portal is installed, go to the root directory for the Application Server that Portal is using. Then change to the subdirectory ProcessChoreographer, where the Process Server Client files are installed.
2. Copy the stub archive task137650.jar.
3. In Rational Application Developer, open the portlet project.
4. In the Web perspective, navigate to the folder WebContent/WEB-INF/lib.
5. Paste the task137650.jar into the lib folder. That action adds the JAR to the build path. In the Project Explorer, the JAR file is listed under Java Resources - Libraries - Web Libraries. When the application WAR file is created, the file is included in the WEB-INF/lib directory.

Add an EJB reference to the portlet

The web.xml file for the portlet application must contain an EJB reference that specifies the human task manager home, which is an enterprise Java bean. Use the Deployment Descriptor Editor to add the EJB reference (which the editor codes as an ejb-ref element):

1. Open the project in Rational Application Developer.
2. In the Project Explorer, navigate to the Deployment Descriptor and open it in the Deployment Descriptor Editor.
3. Click the Reference tab, and then click Add in the References section.
4. Follow the instructions in the wizard. Figure 3 and figure 4 show how the wizard was used to add such a reference to the web.xml file for the sample portlet applications.
5. Save the changes.
6. After you add the reference, you must manually add the JNDI name for the binding. If the JNDI name is missing, the portlet fails to access the remote EJB. To manually add the JNDI name, click the newly added EJB reference on the References tab. In the section WebSphere Bindings, type com.ibm.task.api.HumanTaskManagerHome in the JNDI name field. The JNDI name is not added to the web.xml file. Instead, it is added to the ibm-web-bnd.xmi file as an ejbRefBindings element. See listing 1 for an example of the ibm-web-bnd.xmi file. The xmi:id attribute on the ejbRefBindings element and the href attribute on the bindingEjbRef element match the ID attribute on the ejb-ref element in the web.xml file. The system assigns the latter ID during deployment. See listing 2 for an example of the ejb-ref in the web.xml file.

                 
<?xml version="1.0" encoding="UTF-8"?>
<webappbnd:WebAppBinding xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" 
  xmlns:webappbnd="webappbnd.xmi" xmi:id="WebAppBinding_1202149181484" 
  virtualHostName="default_host">
  <webapp href="WEB-INF/web.xml#WebApp_ID"/>
  <ejbRefBindings xmi:id="EjbRefBinding_1202231815765" 
                     jndiName="com.ibm.task.api.HumanTaskManagerHome"> 
                  <bindingEjbRef href="WEB-INF/web.xml#EjbRef_1202231815765"/> 
                  </ejbRefBindings> 
</webappbnd:WebAppBinding>

                
<?xml version="1.0" encoding="UTF-8"?>
<-- Intervening lines not shown -->
</jsp-config> 
<ejb-ref id="EjbRef_1202231815765">
                  <description />
                  <ejb-ref-name>ejb/HumanTaskManagerHome</ejb-ref-name>
                  <ejb-ref-type>Session</ejb-ref-type>
                  <home>com.ibm.task.api.HumanTaskManagerHome</home>
                  <remote>com.ibm.task.api.HumanTaskManager</remote>
                </ejb-ref>
</web-app>

Write code to access the remote human task manager

The WebSphere Process Server APIs for human tasks are packaged in taskapi.jar. Because the business process is running on a remote server, the portlet accesses the interface for the remote session bean (HumanTaskManagerHome) by using the server host name and bootstrap port. Then the portlet looks up the JNDI name for the EJB. Having accessed the human task home, the portlet can access the input message for the task and proceed with implementing the human task: create a security incident report for a rejected badge request. The sample code in listing 3 shows these steps that are taken from SecurityIncidentPortlet.java in the archive for the basic portlet project (SecurityIncident.zip). The portlet provides the user interface for the person who performs the human task (CreateSecurityIncident) in the remote BadgeProcess. Similar steps are in SecurityIncidentCoopAPortlet.java and SecurityReportCoopBPortlet.java in the archive for the cooperative portlet project (SecurityIncidentPI.zip).

                
			
//Get initial JNDI context for the remote human task home
Hashtable hashtable = new Hashtable();
hashtable.put(Context.INITIAL_CONTEXT_FACTORY,
   "com.ibm.websphere.naming.WsnInitialContextFactory");
System.out.println("Stored initial context factory in hashtable");

//To use a hardcoded host name and port. Change example.com to the correct host name.
//hashtable.put(Context.PROVIDER_URL, "corbaloc:iiop:example.com:2809");

//To use portlet preferences from portlet.xml to set the host and port ...
PortletPreferences remoteHostInfo = request.getPreferences();
String host = remoteHostInfo.getValue("host", "localhost");
String port = remoteHostInfo.getValue("port", "2809");
System.out.println("host is: " + host + " and port is: " + port);
hashtable.put(Context.PROVIDER_URL, "corbaloc:iiop:" + host + ":" + port);
System.out.println("Stored provider URL in hashtable");				

//Lookup the remote home for the HumanTaskManager session bean
Context context = new InitialContext(hashtable);
Object obj = context.lookup("com/ibm/task/api/HumanTaskManagerHome");
System.out.println("Looked up remote home interface");

//Convert to correct type
HumanTaskManagerHome taskHome = (HumanTaskManagerHome) 
   javax.rmi.PortableRemoteObject.narrow(obj,HumanTaskManagerHome.class);
System.out.println("Converted type");

//Access the remote interface
HumanTaskManager taskManager = taskHome.create();
System.out.println("Accessed remote interface");

      

To compare remote access with local access, see FileReport.java in the BadgeProcess sample. That servlet and its Java Server Pages (securityList.jsp and incident.jsp) provide the user interface to the security incident human task on the local Process Server.

Write code to perform the actions for the human task

The human task must be claimed, worked on, and completed. The sample portlets perform each of those activities. Depending on your requirements, some of those activities might be implemented in other applications. The WebSphere Process Server documentation provides a detailed description of claiming tasks, retrieving the input message for a task, creating the output message, and completing the task. Listing 4 shows excerpts from SecurityIncidentPortlet (claiming a task) and listing 5 shows excerpts from SecurityReportPortlet (creating a task output message and completing a task). The portlets use a session bean for interportlet communication. Two Java Server Pages (RejectedRequestList.jsp and SecurityReportPortletView.jsp) provide the user interface for the security incident human task.

                
public void processAction(ActionRequest request, ActionResponse response) 
   throws PortletException, java.io.IOException {

//Get the portlet's session bean
SecurityIncidentPortletSessionBean sessionBean = getSessionBean(request);
//Claim the task and display the security incident report form
   try {
      //Set task ID in the session
      sessionBean.setFormTask(request.getParameter(FORM_TASK));
      String taskID = sessionBean.getFormTask();
      System.out.println("TaskID is " + taskID);
      
      //Claim the task using the string representation of the TKIID
      HumanTaskManager taskManager = sessionBean.getTaskMgr();
      Task task = taskManager.getTask(taskID);

      if (task.getState() != Task.STATE_CLAIMED 
         || task.getState() != Task.STATE_RUNNING) {
      taskManager.claim(taskID);
      System.out.println("Claimed task " + taskID);
      }

    }	catch (Exception e1)	{
        e1.printStackTrace();
      }
}

                

public void processAction(ActionRequest request, ActionResponse response) 
   throws PortletException, java.io.IOException {
		
//Get the portlet session bean from application scope
PortletSession session = request.getPortletSession();
SecurityIncidentPortletSessionBean sessionBean = (SecurityIncidentPortletSessionBean)
   session.getAttribute(SESSION_BEAN,PortletSession.APPLICATION_SCOPE);
//When request is to submit a completed security incident form ...
if(sessionBean != null && 
request.getParameter(FORM_SUBMIT).equalsIgnoreCase("submit")) {
// Set the incident data in the session bean and generate human 
task output message	
   try {
     //Get the task manager from session
     HumanTaskManager taskManager = sessionBean.getTaskMgr();
     sessionBean.setFormInvestigator(request.getParameter(FORM_INVESTIGATOR));
     sessionBean.setFormIncident(request.getParameter(FORM_INCIDENT));			
     sessionBean.setFormTask(request.getParameter(FORM_TASK));
     sessionBean.setFormOutcome(request.getParameter(FORM_OUTCOME));
     sessionBean.setFormSubmit(request.getParameter(FORM_SUBMIT));
     //Get the task input message
     String taskID = sessionBean.getFormTask();
     ClientObjectWrapper cow = taskManager.getInputMessage(taskID);
     DataObject inputMsgObject = (DataObject) cow.getObject();
     DataObject inputMsg = (DataObject) inputMsgObject.getDataObject("securityInput");
     //Create the task output message
     ClientObjectWrapper output = taskManager.createOutputMessage(taskID);
     DataObject outputMsgObject = (DataObject)output.getObject();
     DataObject outputMsg =
     (DataObject)outputMsgObject.createDataObject("securityOutput");

     if (outputMsg != null ) {
       outputMsg.createDataObject("EmployeeVerification");
       outputMsg.setDataObject("EmployeeVerification", inputMsg);
       outputMsg.setString("IncidentNumber", sessionBean.getFormIncident());
       outputMsg.setString("Investigator", sessionBean.getFormInvestigator());
       outputMsg.setString("Disposition", sessionBean.getFormOutcome());
       //Print output message
       System.out.println("Output message is: " + outputMsg.toString());
       System.out.println("EmployeeVerification container is: " + 
          outputMsg.getDataObject("EmployeeVerification").toString());
       System.out.println("EmployeeInput container is: " + 
         outputMsg.getDataObject("EmployeeVerification")
         .getDataObject("EmployeeInput").toString());
      //Complete the task using the string representation of the TKIID
      sessionBean.getTaskMgr().complete(taskID, output);
      //Remove task ID from session bean
      sessionBean.setFormTask("");
    }
  }	catch (Exception e) {
      e.printStackTrace();
      }
}//if submit		

}

Back to top

Deploying and testing your portlet application

If you use an Integrated Development Environment (IDE), such as Rational Application Developer, you certainly test your portlet application as you work. To test the portlet outside of the IDE, follow these steps:

1. If the business process application is not already deployed on the remote WebSphere Process Server, deploy the EAR file.
2. Start a process instance. Be sure that the instance creates the condition required to invoke the human task.
3. Install the portlet application.
   • Log in to the portal as an administrator.
   • Click Launch - Administration.
   • Click Portlet Management - Web Modules.
   • Click Install and then click Browse to locate the WAR file for the portlet application.
   • Follow the instructions on the pages to install the application.
4. Add the portlets to a page.
   • In Portal Administration, click Portal User Interface - Manage Pages.
   • Click Content Root - Home to navigate to the level in the page hierarchy to add the new page. Of course, you can also add the page somewhere other than Home.
   • Click New Page. Complete the Title field and then click OK.
   • In the list of pages, click the Edit Page Layout icon for the new page.
   • Click Add portlets to add a portlet to the page.
5. Click Launch - Home.
6. Click the portlet page. If the portlet fails to load or if interactions fail, check the portal log files. See Tips for some hints on potential errors related to access to the remote human task manager.

Back to top

Using the sample applications

Downloads contains links to the sample business process application, the basic portlet sample, and the cooperative portlet sample. Project Interchange files are provided for each application so that you can import the project into your Rational Application Developer or WebSphere Integration Developer. Use the EAR and WAR files to deploy the applications. Those archives also contain the source code. The following sections describe the basic steps for deploying the applications.

Using the basic portlet sample

The basic portlet sample is in SecurityIncidentPortlet.zip. The portlet application provides the user interface for the CreateSecurityIncident task in the BadgeProcess. (See the assembly diagram in figure 1.) In the process, a rejected badge request is handled by having a human review the badge application and file a security incident report.

The basic portlet application contains two portlets that are packaged in the same WAR file for deployment. SecurityIncidentPortlet accesses the remote business process and retrieves a list of ready or otherwise active instances of security incident tasks. The doView method of the portlet displays the list of tasks (RejectedRequestList.jsp). When the user clicks a task link, the processAction method is invoked. That method claims the task and stores the task ID and the HumanTaskManager object in its session bean for later use by its JSP and the second portlet. The two portlets use the APPLICATION_SCOPE session bean for interportlet communication.

The second portlet, SecurityReportPortlet, displays the form for filing the security incident report (SecurityReportPortletView.jsp). If the user has selected a task in the list, the top part of the form displays the information from the task input message (which is the data that was entered on the rejected badge application).

The bottom section of the form contains input fields for the report data. That data is used in the output message for the task. When the user clicks submit, the processAction method is invoked. As shown in listing 5, the portlet uses the HumanTaskManager stored in the session bean to retrieve the input message for the task, construct the output message, and complete the task. The portlet does not have to go through the steps to set up a connection to the interface for the remote HumanTaskManagerHome because it can use the HumanTaskManager that the first portlet stored in the session bean. A sequence of system prints in the portlet shows the content of the output message. Because this is the last component in BadgeProcess, the process instance ends after the output message is sent.

To use the basic portlet application, follow these steps:

1. Deploy the business process application (BadgeRequestModuleApp.ear) to WebSphere Process Server V6.0.2. An alternative is to import the BadgeProcessPI.zip into WebSphere Integration Developer, 6.0.2 and then deploy the application to the Process Server test environment.
2. Create a rejected application request:
   • Ensure that the BadgeRequestModule application is started.
   • In your Web browser, open host:port/BadgeRequestWeb/BadgeRequestServlet, where host is the server host name and port is the default host port. BadgeRequestServlet and its Java Server Page implement the stand-alone reference in the BadgeProcess assembly diagram (figure 1).
   • Complete the form, specifying a serial number that begins with an even number so that the VerifyEmployeeStatus component returns false, which triggers the CreateSecurityIncident component.
   • Submit the form.
   • To create additonal rejected requests, repeat these steps.
   • If you want to run an instance through the BadgeProcess before using the sample portlets, use the human task servlet included as an extra in the project. Open host:port/BadgeRequestWeb/securityList.jsp, and then click a task in the list. The FileReport servlet is invoked and displays the security incident form (incident.jsp). The servlet and JSPs perform the similar functions as the two sample portlet applications, except that the servlet uses local instead of remote access to the human task manager.
3. Install SecurityIncident.war on WebSphere Portal V6.0.1.
4. Configure the portlet preferences for the host name and port of the remote Process Server.
   1. Click Portlet Management - Portlets. Search for the portlet.
   2. Click the Configure portlet icon for the portlet.
   3. Change the parameters host (default value localhost) and port (default value 2809) as needed. See Tips for how to determine the correct value of port.
5. Add the portlets to a page.
6. In the portal, open the portlet page. The results should be similar to figure 5.

Using the cooperative portlet sample

The cooperative portlet sample is in SecurityCoopPI.zip. The portlet application provides the user interface for the CreateSecurityIncident task in BadgeProcess. (See the assembly diagram in figure 1.) In the process, a rejected badge request is handled by having a human review the badge application and file a report.

Like the basic portlet application, the cooperative portlet application consists of two portlets. Although the project interchange file contains both portlets, they are deployed as separate WAR files.

SecurityIncidentCoopA accesses the remote business process and retrieves a list of ready or otherwise active instances of security incident human tasks. The doView method displays the list of tasks (RejectedRequestCoopA.jsp). When the user clicks a task link, the processAction is invoked. That method claims the task and stores the task ID and the HumanTaskManager object in the session bean for later use by its JSP. Unlike in the basic portlet sample, the two portlets do not share a session bean. Instead, interportlet communication is enabled using the property broker. The first portlet is a cooperative source portlet. When the link is clicked, the processAction method of the second portlet (the target portlet) is also triggered. The task ID for the selected task is passed to the target portlet through the property broker.

The target portlet accesses the remote business process and stores the HumanTaskManager object and the current task ID (passed to it) in its session bean. The doView method is invoked and displays the form for filing the security incident report (SecurityReportCoopBPortletView.jsp). The top part of the form displays the information from the task input message (which is the data that was entered on the rejected badge application). The bottom section contains input fields for the report data.

When the user submits the form, the processAction method of the target portlet is invoked. The form data is used in the output message for the task. A sequence of system prints shows the content of the output message. Because this is the last component in the business process, the process instance ends after the output message is sent.

To use the cooperative portlet application, follow these steps:

1. Deploy the business process application (BadgeRequestModuleApp.ear) to WebSphere Process Server V6.0.2. An alternative is to import the BadgeProcessPI.zip into WebSphere Integration Developer, 6.0.2 and deploy the application to the Process Server test environment.
2. Create a rejected application request:
   • Ensure that the BadgeRequestModule application is started.
   • In your Web browser, open host:port/BadgeRequestWeb/BadgeRequestServlet, where host is the server host name and port is the default host port. BadgeRequestServlet and its Java Server Page implement the stand-alone reference in the BadgeProcess assembly diagram (figure 1).
   • Complete the form, specifying a serial number that begins with an even number so that the VerifyEmployeeStatus component returns false, which triggers the CreateSecurityIncident component.
   • Submit the form.
   • To create additonal rejected requests, repeat these steps.
   • If you want to run an instance through the BadgeProcess before using the sample portlets, use the human task servlet included as an extra in the project. Open host:port/BadgeRequestWeb/securityList.jsp, and then click a task in the list. The FileReport servlet is invoked and displays the security incident form (incident.jsp). The servlet and JSPs perform the similar functions as the two sample portlet applications, except the servlet uses local instead of remote access to the human task manager.
3. Install SecurityIncidentCoopA.war and SecurityReportCoopB.war on WebSphere Portal V6.0.1.
4. Configure the portlet preferences for the host name and port of the remote Process Server. Perform this step for each cooperative portlet.
   
   • Click Portlet Management - Portlets. Search for the portlet.
   • Click the Configure portlet icon for the portlet.
   • Change the parameters host (default value localhost) and bootstrap port (default value 2809) as needed. See Tips for how to determine the correct value of port.
5. Add the portlets to a page. After you add the portlets to the page layout, click the Wires tab and wire the portlets as shown in figure 6. Remember to click the plus icon and then to click Done.
6. In the portal, open the portlet page. The results should be similar to figure 7.

Back to top

Conclusion

Remember these key steps for developing a portlet user interface to a human task in a remote business process.

1. Ensure that the environment is installed correctly. The samples provided with this article were tested on WebSphere Portal V6.0.1 with WebSphere Process Server Client V6.0.2 added. For the business process application, WebSphere Process Server V6.0.2 was installed on a separate WebSphere Application Server.
2. Develop or obtain a copy of the business process application, and extract the WSDL and schema files. Add those files to a JAR file for use in the portlet application.
3. Develop the portlet application and be sure to:
   • Add the WSDL and schema JAR file to the portlet WEB-INF/lib path.
   • Add the Task API stubs archive (task137650.jar) to the portlet WEB-INF/lib path.
   • Use the Deployment Descriptor Editor to add the EJB reference to the portlet web.xml file and specify the JNDI name.
   • Write code to access the remote HumanTaskManagerHome interface.
   • Write code to read the input message for the human task, claim the task, read the input message, implement the task, create the output message, and complete the task.
4. Test the application.

Back to top

Downloads

Information about download methods

Resources

• Participate in the discussion forum.
  
  
• "Building a human task-centric business process with WebSphere Process Server, Part 4: Portlet development" (developerWorks, Jul 2007) is a guide to developing human task portlets in an environment that uses the My Tasks portlet for the user interface.
  
  
• The WebSphere Integration Developer 6.0.2 online help includes an easy to follow, step-by-step tutorial on developing a business process application. To access the Help, click Help - Help Contents on the menu bar. In the content navigation tree, click Introduction to WebSphere Integration Developer - Application samples - Loan Application.
  
  
• The WebSphere Portal V6.0.1 Information Center provides instructions for installing the product and developing portlets.
  
  
• The WebSphere Process Server V6.0.2 Information Center provides instructions for installing the product and developing business process applications.
  
  
• Refer to the WebSphere Process Server V6.0.2 Javadoc for details about the Task API.
  
  
• The BPC samples site provides examples and instructions for implementing human tasks.
  
  
• Browse the technology bookstore for books on these and other technical topics.
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Setting up the runtime environment
• Developing the business process application
• Developing the portlet application
• Deploying and testing your portlet application
• Using the sample applications
• Conclusion
• Downloads
• Resources
• About the author
• Comments

Next steps from IBM

• Try: Rational Application Developer for WebSphere Software
• Demo: Build, test and deploy JAX-WS Web services
• Webcast: Webcast: Develop innovative applications efficiently using the right application foundation in today's economy
• Briefing: Software development conference
• Buy: Rational Application Developer for WebSphere Software

My developerWorks community

Dig deeper into WebSphere on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers