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.
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.
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.
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.
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.
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.