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.