Activity execution with the Web Client

There is a major difference between the Standard Client of MQSeries Workflow and the Web Client setup. In contrast to the Standard Runtime Client, the Web Client does not have the MQSeries Workflow API installed on the client machine. This means there is usually neither MQSeries nor a Program Execution Agent available on the client machine. In the following sections, we look at different alternatives to execute activities when using the Web Client.

Automatic activities

Automatic activities are not meant to be displayed on worklists. When they are scheduled, the Execution Server tries to find (depending on the process model): If, in the first case, the user is actually working with the Web Client, you have to manually start the Program Execution Agent for the user ID (see the fmcxspea program) on an appropriate machine so that the activity can be executed. However, this setup is only useful for non-interactive programs, that is, programs that do not require human interaction.

Manual activities

Manual activities are shown as work items on worklists from which they can be started. If the Web Client was using the WorkItem.start() API for work items invoked from the worklist, the same considerations as mentioned in the previous section would apply. However, because manual activities are usually interactive, a different approach is needed for the standard worklist of the Web Client: Instead of starting the work item, it is checked out. Only if a work item cannot be checked out (see the 'Program activities can be checked out' flag on the 'Activity' and 'Control' pages in Buildtime) the Web Client will try to start the work item, depending on the startAllowed request parameter of the checkOutWorkItem command. That is, if you want to start a non-interactive program manually from the Web Client, you must either disable the 'can be checked out' flag in Buildtime or write your own worklist without the startAllowed parameter for the checkOutWorkItem command. Alternativley, you can use the startWorkItem command instead of the checkOutWorkItem command. If, however, the checkout was successful, the servlet sends a form to the client, which contains the input container data. This form depends on the Viewer setting and usually contains a 'Submit' button invoking the servlet's checkInWorkItem command. The checkInWorkItem command then reads the data to be set in the output container from the HTML form that was submitted. For more details, refer to the source code of DefaultViewer and JSPViewer that is part of the Web Client. Refer to the checkOutWorkItemResponse() method.

Invoking Java Server Pages (JSPs)

This is the recommended implementation for manual activities using the Web Client. The JSPViewer class already supports this by mapping the name of the program assigned to an activity to a JSP. If, for example, activity A has program DoSomething assigned and the checkOutWorkItem command is invoked on a work item of activity A, the JSPViewer first checks out the work item and then forwards the request to the <MQWFDir>/WebClient/webpages/programs/DoSomething.jsp JSP. This JSP can then access the work item and container data by including the following code:
    <%@ page language="java" info="JSP activity implementation" %>
    <%@ page import="com.ibm.workflow.api.*" %>
    <%@ page import="com.ibm.workflow.servlet.client.*" %>
    <jsp:useBean id="context" scope="request"
                 type="com.ibm.workflow.servlet.client.RequestContext"/>
    <html>
    <body>
    <% ReadOnlyContainer inData = context.getContainer();
       WorkItem workItem = context.getWorkItem(); %>
    :
    <%=context.openForm("checkInWorkItem", workItem.persistentOid())%>
    :
      <input type="submit" name="submitData" value="Complete work item">
      <input type="button" name="cancel" value="Cancel"
             onClick="javascript:{location='<%=context.getCommand("cancelWorkItem", workItem.persistentOid())%>';}">
    </form>
    :
    </body></html>
For a simple example, see the NCollectCreditData.jsp file and the checkOutWorkItem command.

Invoking Applets

Running applets in the client's browser is very easy, simply create a JSP (see above) for the activity that contains the appropriate <applet> tags.

Invoking Enterprise Java Beans (EJBs)

EJBs are not supported 'out of the box' by MQSeries Workflow. That is, you cannot model your processes in Buildtime to invoke EJBs. But since JSPs can access everything in Java it is possible to write an activity implementation JSP (see above) that acts as an EJB client. Just import the required packages, look up the EJB through its home interface, and invoke any methods on it you need. Data retrieved this way can then be included in the form that is sent to the browser as well as data from a submitted form can be used to update an EJB when the work item is checked in.

Invoking Servlets

Note that while a servlet is a piece of code running on the server doing interesting things one wants to integrate it is primarily a piece of code retrieving a request -- usually from a browser using the HTTP protocol -- and generating a dynamic response, usually in the HTML format. That is, it does not fit well as an activity implementation.

If the servlet in question is yet-to-be-written, it is strongly recommended that a JSP is written instead (which the JSP-compiler will turn into a servlet anyway). This is fully supported by the Web Client and allows to easily pass workflow-context, (that is, container data) in and out of the activity implementation. For interactive activity implementations this is the way to go.

There is no easy way to integrate an existing servlet for an interactive activity without changing the servlet. While it is quite easy to write a 'router JSP' that forwards a start work item request to an existing servlet through either the HttpServlet.sendRedirect(...) Java API or the <jsp:forward ...> JSP statement, there is no easy way to get the invoked servlet's response back into the workflow. Both sendRedirect and jsp:forward will forward the request, that is, the servlet's response will be sent to the browser. The challenge now is to get WorkItem.checkIn() called with the appropriate data so that the workflow process can continue. But since the existing servlet does not know about workflow, it will not include the necessary fields in the reponse page it sends.


© Copyright IBM Corporation 1999, 2001. All Rights Reserved.