MQSeries Workflow - Event Server sample using MQSeries Integrator

IBM MQSeries Workflow Version 3.3 provides an Event Server sample using MQSeries Integrator and its Publish/Subscribe function. This SupportPac demonstrates how you can use MQSeries Integrator as an Event Server that handles incoming external events and sends them to the MQSeries Workflow activity that is waiting for the event.

In this documentation it is assumed that you are familiar with the MQSeries family of products. It describes how to install and run the delivered sample scenario.

IBM

Contents

Introduction
Overview of sample scenario
Installation
Running the sample
Handling problems and errors

More information

For more information on related topics, visit the following Web pages:
IBM MQSeries Workflow http://www.software.ibm.com/ts/mqseries/workflow
IBM MQSeries Integrator http://www.software.ibm.com/ts/mqseries/integrator
IBM DB2 Universal Database http://www.ibm.com/software/data/db2
IBM MQSeries Family publications http://www.software.ibm.com/ts/mqseries/library
IBM MQSeries Workflow Support Pacs http://www.software.ibm.com/ts/mqseries/txppacs/txpm1.html
IBM MQSeries Family Whitepapers http://www.software.ibm.com/ts/mqseries/library

If you have any comments or suggestions, please contact our MQSeries Workflow Competence Center.

Introduction

IBM MQSeries Workflow offers XML support in addition to the standard API interfaces. With this message-based interface, you can connect an MQSeries Workflow system to any other system, even outside of MQSeries Workflow systems. In addition, you can use applications based on MQSeries to start or execute MQSeries Workflow processes. You can also integrate existing MQSeries applications into an MQSeries Workflow process without having to change the applications.

This SupportPac contains a sample scenario that shows how you can handle external events by using MQSeries Integrator Version 2, for example, for sending an external event from an existing MQSeries application to an MQSeries Workflow activity.

This sample implementation was developed and tested for Windows NT and Windows 2000. It requires an MQSeries Integrator installation as well as an MQSeries Workflow environment.

The MQSeries Workflow postcard sample application, MQSeries Integrator message sets and message flows and the MQSeries Workflow process are included in this SupportPac. You can run the sample on a system that fulfills the requirements that are listed in the section Installation. For details on how to get the sample running, refer to the section Setting up the sample.

Overview of the sample scenario

This section gives you an overview of the scenario on which this SupportPac is based.

The scenario describes the final step in a complex travel booking process. In this step, a travel survey is sent to a customer that is intended to give general feedback on this customer's travel. The process contains the following activities:

SendQuestionnaireToCustomer
This activity represents an activity that sends a questionnaire to the customer.
WaitForCustomerResponse
This activity waits for the external event (the response from the customer), which in this sample is represented by the MQSeries Workflow postcard sample application. As soon as the response is available, the contents of the questionnaire are provided as output container of the activity.
ProcessQuestionnaireResult
If the customer answers the questionnaire, that is, the external event occurs, this activity represents the activity that automatically processes the result of the travel survey.
NoResponseFollowup
If the customer does not answer the questionnaire within a specified time frame, that is, the external event does not occur, the WaitForCustomerResponse activity expires. The NoResponseFollowup activity then sends a message to the travel agent that tells him, for example, to contact the customer again.
MQSeries Integrator provides a Publish/Subscribe function that processes the incoming events. In this sample, MQSeries Integrator Version 2 is used for the implementation of the user-defined Program Execution Server (UPES). The user-defined Program Execution Server handles the external event that is represented by the sample postcard application and processed by the WaitForCustomerResponse activity. An MQSeries Workflow postcard sample application is used to send the customer response message to the MQSeries Integrator, which then sends the response message back to MQSeries Workflow.

If the external event does not occur, that is, the customer does not respond to the travel survey, the corresponding activity expires, and MQSeries Workflow sends an ActivityExpired message to the UPES. If the workflow process is terminated, a TerminateProgram message is sent instead.

The following section provides a detailed description of the scenario and the deliverables that are part of this SupportPac:

Sample scenario

The sample scenario describes the final step of a complex travel booking process. The process for this final step contains several activities. This section explains how these activities are implemented and handled by the system. The following figure shows how the activities are handled by MQSeries Workflow and MQSeries Integrator:

external event scenario

MQSeries Workflow sends an ActivityImplInvoke message in XML format to the UPES that is specified for this activity (1). In the sample, the message is sent to an MQSeries Integrator message flow that transforms the message into a RegisterSubscriber message. The RegisterSubscriber message is sent to the control queue of the Publish/Subscribe function of MQSeries Integrator (3), and correlation data is inserted in the MQSeries Workflow database (default name: FMCDB) (2). This correlation data is necessary for generating the reply message to MQSeries Workflow in a later step (9). The subscription to the Publish/Subscribe function is content-based. This means that the unique customer identification is used to specify the filter of the subscription. The customer identification is an input container member of the WaitForCustomerResponse activity.

An MQSeries Workflow postcard sample application represents the external event. It sends an XML message to an MQSeries Integrator message flow (4) that transforms the message into a publication message. The publication message is passed to a publication node which sends it to the Publish/Subscribe function of the broker. If the customer identification of the postcard matches with the filter criteria of one of the current subscriptions, the publication message is made available for another TransformPublication message flow (6). This message flow then transforms the publication message for the subscriber into an ActivityImplInvokeResponse message (9).

The content of the postcard message is mapped to the output container of the WaitForCustomerResponse activity, and the correlation data for the response message is retrieved from the MQSeries Workflow database (7). After retrieving the correlation data from the database, the generated XML response message ActivityImplInvokeResponse is sent to the input queue of MQSeries Workflow (9). This message flow also includes the generation of a DeregisterSubscriber message that is sent to the Publish/Subscribe function to revoke the previous subscription (8).

If the external event does not occur, that is, the customer does not respond to the travel survey, the activity WaitForCustomerResponse expires after a specified amount of time. In this case, the following steps are performed:

  1. MQSeries Workflow sends the XML message ActivityExpired to the UPES. In the sample, this is the MQSeries Integrator message flow RegisterSubscriber (10).
  2. The RegisterSubscriber message flow deletes the correlation data from the MQSeries Workflow database (11).
  3. The RegisterSubscriber message flow generates a DeregisterSubscriber message which is sent to the Publish/Subscribe function to revoke the previous subscription (12).
If the workflow process is terminated, MQSeries Workflow sends the XML message TerminateProgram to the UPES (10). The MQSeries Integrator message flow deletes the correlation data from the MQSeries Workflow database (11), and generates a DeregisterSubscriber message. This message is sent to the Publish/Subscribe function to revoke the previous subscription (12).

MQSeries Workflow TravelSurvey process

The MQSeries Workflow sample process TravelSurvey is designed to show within the delivered scenario how an MQSeries Workflow process sends a request and waits for a reply of an external event that influences the further processing of the process. The TravelSurvey process is not complex. It covers a few process steps for demonstration purposes only.

The TravelSurvey process is modeled with four major activities. When the process in the sample scenario is started, a window for the input container is displayed in which you can enter the name and address of the customer.

SendQuestionnaireToCustomer is the first activity in the process and is started manually. This activity simulates the sending of a travel survey to the customer. The second activity in the process is an automatic program activity, called WaitForCustomerResponse. It waits for the response from a customer. This program activity is started automatically and is executed by the UPES, which is defined in the FDL and is called MQSIPES. As soon as the response is available, the contents of the survey are provided as output container of the external event. The final activity depends on the result of the external event. If the external event occurs, the activity ProcessQuestionnaireResult automatically processes the results of survey. If the customer does not respond to the survey within a certain time frame, that is, the activity WaitForCustomerResponse expires, the activity NoResponseFollowup is processed. This activity informs the travel agent to contact the customer again.

The first and the final activities are implemented as MQSeries Workflow application 'fmcnshow' to show the content of the input and output containers of these activities. The activity that is waiting for the external event, the WaitForCustomerResponse activity, is implemented by the MQSeries Integrator message flows.

The external event is implemented by the MQSeries-based sample postcard application that sends an XML message to MQSeries Integrator. When the provided MQSeries Integrator message flows receive this XML message, they generate the response message from the UPES and send it back to the running activity WaitForCustomerResponse.

The sample process was chosen to illustrate how you can use MQSeries Integrator as an Event Server that handles incoming external events and sends them to an MQSeries Workflow activity that is waiting for the event. The activities that must be performed manually, are represented as work items in a worklist. Because the first and the last activities in the process are modeled to be started manually, the MQSeries Workflow TravelSurvey process can be monitored while running the sample. This helps to demonstrate all activity invocations, for example, how the second activity changes from a running state (while the MQSeries Integrator processes the incoming events)to a finished state (after the external event has been published to all subscribers), and how the process flow continues.

The following figure shows the sample MQSeries Workflow process, called TravelSurvey.

TravelSurvey process

MQSeries-based postcard sample application

As described in section Sample Scenario, this SupportPac is shipped with the following sample application based on MQSeries: In the following section, the scope and the contents of this sample application are described. In this sample scenario, it is used to simulate an external event. The MQSeries Workflow postcard sample application simulates an application that acts as an event producer. In a real scenario, any MQ application could take up this role. The message flows of MQSeries Integrator must transform the format of the external event message into the format that is expected by MQSeries Workflow. The sample application is implemented as Java application, which is based on MQSeries.

The following example shows the format of the provided MQSeries Workflow postcard XML message:

<PostcardMessage>
<Location>London</Location>
<Country></Country>
<MessageText>Hi, I'm really happy with your travel agency</MessageText>
<Recipient>Friendly Travel Agency</Recipient>
<Sender>Peter</Sender>
<Weather>Wet</Weather>
<Duration>7</Duration>
<GoodTime>TRUE</GoodTime>
</PostcardMessage>

Instead of using the MQSeries Workflow postcard sample application, you can also write an own MQSeries application that either generates an XML message or a message in any other format and sends it directly to MQSeries Integrator. For a description on how to use other message formats, refer to the WA02 SupportPac "MQSeries Integrator Interoperability Sample".

MQSeries Integrator sample message sets and flows

An MQSeries Integrator message set defines the structure of a message. An MQSeries Integrator message flow defines which messages are to be handled from which queue, which operations are to be executed, for example, data transformation, and it also defines where to put existing output messages.

This SupportPac contains the following MQSeries Integrator message set:

  1. MQSWFXML (MQSeries Workflow Message Set)
as well as the following MQSeries Integrator message flows:
  1. RegisterSubscriber
  2. Publish
  3. TransformPublication

MQSWFXML (MQSeries Workflow Message Set)

A dedicated message set is used to describe the MQSeries Workflow XML messages. Because a complete MQSeries Workflow XML message set contains the input and output data of the MQSeries Workflow processes and activities, they depend on the processes and activities defined in the MQSeries Workflow Buildtime. Therefore, this SupportPac contains an 'MQSWFXML (MQSeries Workflow XML message set)' where the MQSeries Workflow DTD is described as base MQSeries Integrator message set. This MQSeries Integrator message set can be used for any new message set. You can derive application-specific message sets from this message set so that you can extend it by the defining own (user-defined) data structures that are used as input or output of an MQSeries Workflow process or activity. This means that all definitions from the MQSWFXML message set are available in any deviated message set plus the new definitions for the customized input and output data that must be added. The MQSeries Workflow DTD is described in the MQSeries Workflow Programming Guide.

Note: Refer to the MQSeries Workflow DTD when defining your own message flows.

Not all syntactical specifications of the MQSeries Workflow XML messages are defined in the MQSeries Integrator message set. For example, the WfMessage must contain at least one element from the list of possible values. MQSeries Integrator does not support these definitions so that all of these elements are defined as optional. Make sure that you have at least one of these elements assigned.

Note:
This message set is a level 2 message set, based on the message set that was provided with the previous version of the WA02 SupportPac "MQSeries Integrator Interoperability Sample Version 1.0.1". If you have already installed the message set from the new version (Version1.1) of the WA02 SupportPac, you need not install it again for this SupportPac. If the message set already exists on your system, the following message is displayed:

"Duplicate message set identifier. The message set to be imported already exists in this repository."

Message Flow RegisterSubscriber

The MQSeries Integrator message flow RegisterSubscriber is used to transform the incoming ActivityImplInvoke message into a message that is required to subscribe to the broker. Additionally it is used to store the correlation data that is needed for the response to the MQSeries Workflow system.

The first filter node checks if the incoming message is an 'ActivityImplInvoke' message. If this filter evaluates to true, the necessary correlation data is inserted into the database FMCDB in a DataInsert node. A Compute Node follows, which creates the RegSub command and inserts the filter critera that is used in the subscription. The filter criteria is the user nickname from the data container of the incoming ActivityImplInvoke message. Additionally, the Compute Node inserts registration options. Then, the output node sends the RegSub command to the SYSTEM.BROKER.CONTROL.QUEUE.

If the first filter node evaluates to false, the next filter checks if an 'ActivityExpired' or a 'TerminateProgram' message has arrived. In this case, a database node deletes the correlation data for this activity from the database. Then, a compute node generates the DeregSub command to delete the subscription for this activity from the broker. The output node also sends this command to the SYSTEM.BROKER.CONTROL.QUEUE.

All unknown or failure messages are sent to the WA06_Backout queue.

Customization:
If you want to customize this sample for your own workflow process with other container structures for the program activities, or with another external event message than the MQSeries Workflow PostcardMessage, you must adapt the filter in the ESQL of the node 'Generate RegisterSubscriber command' to your container structure and to the format of your external event message. In the ESQL, the note 'Can be customized' indicates which lines you have to customize for this purpose:

ESQL of node 'Generate RegisterSubscriber command':

SET OutputRoot.MQMD.MsgType = MQMT_DATAGRAM;
-- Note: If you want to get response messages from the broker, you can set the Report option  
-- to MQRO_PAN (success response) or to MQRO_NAN (error response) or to both 
-- (MQRO_PAN + MQRO_NAN)
SET OutputRoot.MQMD.Report = MQRO_NAN + MQRO_PASS_CORREL_ID;
SET OutputRoot.MQMD.Expiry = MQEI_UNLIMITED;
SET OutputRoot.MQMD.Format = MQFMT_RF_HEADER_2;
SET OutputRoot.MQMD.MsgId = MQMI_NONE;
SET OutputRoot.MQMD.CorrelId = InputRoot.MQMD.MsgId;
SET OutputRoot.MQMD.ReplyToQ = 'WA06_TransformPublicationInput';
SET OutputRoot.MQRFH2.psc.Command='RegSub';
SET OutputRoot.MQRFH2.psc.Topic='MQWF/Event';
-- NOTE: Can be customized:
-- If you use your own Workflow process with own containers for the program activities
-- or another external event message than PostcardMessage you have to adapt the 
-- 'Filter' for the subscription accordingly.
SET OutputRoot.MQRFH2.psc.Filter='Body.PostcardMessage.Sender=''' ||

 InputBody.WfMessage.ActivityImplInvoke.ProgramInputData.Customer.Nickname || '''';
-- Note: When you edit this ESQL and get an ESQL Syntax error in above Filter 
-- statement in the four apostrophs at the end, you can ignore it. The syntax 
-- is correct.
SET OutputRoot.MQRFH2.psc.RegOpt[1]='CorrelAsId';
SET OutputRoot.MQRFH2.psc.RegOpt[2]='Pers';
-- Note: If the broker sends retained publications (which can be specified in node 
-- 'GeneratePublishCommand' in the 'Publish' message flow), the subscribers will 
-- also receive publications, that have occurred before the subscription was 
-- registered.
-- If the subscriber does NOT want to receive retained publications, the following 
-- option can be set:
-- SET OutputRoot.MQRFH2.psc.RegOpt[3]='NewPubsOnly';
-- By setting following option, the broker will inform the subscriber in the 
-- 'Publish' message if a publication is retained.
-- SET OutputRoot.MQRFH2.psc.RegOpt[4]='InformIfRet';

Note:
If you want get error and warning messages from the Broker in case of any subscription problems, specify the MQRO_NAN report option in the MQMD (as seen above in the ESQL). In this sample you will find eventual subscription error messages in queue WA06_SubscriptionErrorInput.

Message Flow Publish

The MQSeries Integrator message flow Publish is used to convert the incoming XML message of the MQSeries Workflow postcard sample application into the expected 'Publish' command for the MQSeries Integrator broker (Publish/Subscribe function). This is done in a compute node and the command is sent to the SYSTEM.BROKER.CONTROL.QUEUE by a publication node.

All unknown or failure messages are sent to the WA06_Backout queue.

Message flow TransformPublication

The MQSeries Integrator message flow TransformPublication is used to transform the incoming publication message from the broker to the subscriber into an ActivityImplInvokeResponse message, that is sent back to the MQSeries Workflow system. Because eventual subscription error messages are also sent to the input queue, a first filter node checks if the incoming message is a RegSub error message.

If this filter evaluates to true, the message is sent to queue WA06_SubscriptionError. If this filter evaluates to false, the message is sent to two compute nodes. One compute node generates the DeregSub command to deregister the previous subscription for this Workflow activity and sends it to the  SYSTEM.BROKER.CONTROL.QUEUE via an output node. The other compute node retrieves the correlation data from the database and transforms the message into an ActivityImplInvokeResponse message, that is sent back to the Workflow system via an output node. A database node deletes the correlation data from the database.

All unknown or failure messages are sent to the WA06_Backout.

Customization:
If you want to customize this sample for your own workflow process with other container structures for the program activities or with another external event message than the MQWF PostcardMessage, then you have to adapt the filter in the ESQL of node 'Retrieve correlation data from DB and transform message' to your container structure and to the format of your external event message. In the ESQL, the note 'Can be customized' indicates which lines you have to customize for this purpose:

ESQL of node 'Retrieve correlation data from DB and transform message':

SET OutputRoot.MQMD=InputRoot.MQMD;
SET OutputRoot.MQMD.Format='MQSTR';
-- Set ReplyToQ for possible error messages from the MQWorkflow system
SET "OutputRoot"."MQMD"."ReplyToQ" = 'WA06_RegisterSubscriberInput';
-- Set destination list for the output node
SET OutputDestinationList.Destination.MQDestinationList.DestinationData[1].queueName[]

 = (SELECT ITEM T.ReplyToQ FROM Database.WA06.Correl_Data AS T where T.MessageID=InputRoot.MQMD.CorrelId);
SET OutputDestinationList.Destination.MQDestinationList.DestinationData[1].queueManagerName[]
 = (SELECT ITEM T.ReplyToQMgr FROM Database.WA06.Correl_Data AS T where T.MessageID=InputRoot.MQMD.CorrelId);
SET OutputRoot.Properties.MessageDomain='XML';
SET OutputRoot.Properties.MessageSet=NULL;
SET OutputRoot.Properties.MessageType=NULL;
SET OutputRoot.Properties.MessageFormat=NULL;
-- Convert output message to UTF-8
SET OutputRoot.Properties.CodedCharSetId=1208;
SET OutputRoot.Properties.Encoding=MQENC_NATIVE;
SET OutputRoot.XML.(XML.XmlDecl)='';
SET OutputRoot.XML.(XML.XmlDecl).(XML.Version)='1.0';
SET OutputRoot.XML.(XML.XmlDecl).(XML.Encoding)='UTF-8';
SET OutputRoot.XML.(XML.XmlDecl).(XML.Standalone)='yes';
SET "OutputRoot"."XML"."WfMessage"."WfMessageHeader"."ResponseRequired"='No';
SET "OutputRoot"."XML"."WfMessage"."ActivityImplInvokeResponse"."ActImplCorrelID"[]
 = (SELECT ITEM T.ActImplCorrelID FROM Database.WA06.Correl_Data AS T where T.MessageID=InputRoot.MQMD.CorrelId);
SET "OutputRoot"."XML"."WfMessage"."ActivityImplInvokeResponse"."ActImplCorrelID" =
TRIM("OutputRoot"."XML"."WfMessage"."ActivityImplInvokeResponse"."ActImplCorrelID");
SET "OutputRoot"."XML"."WfMessage"."ActivityImplInvokeResponse"."ProgramRC" = '0';
-- NOTE: Can be customized:
-- If you use your own Workflow process with own containers for the program 
-- activities or another external event message than the PostcardMessage,
-- you have to adapt the following statements accordingly.
SET "OutputRoot"."XML"."WfMessage"."ActivityImplInvokeResponse"."ProgramOutputData".
"QuestionnaireResult"."Sender" = InputBody.PostcardMessage.Sender;
SET "OutputRoot"."XML"."WfMessage"."ActivityImplInvokeResponse"."ProgramOutputData".
"QuestionnaireResult"."MessageText" = InputBody.PostcardMessage.MessageText;

Installation

Prerequisites

Note: The samples in this SupportPac currently have been tested on Windows NT and Windows 2000 only.

For information on how to install these products, see the related documentation.

Installation of this support pack

This SupportPac is packaged as zipped file WA06.zip. Copy the zip file into the MQSeries Workflow installation directory, for example, d:\fmcwinnt. From this directory, start a tool to unzip and extract the files. To get the sample running, refer to the section Setting up the sample. The following files are available in the following directory structure:

d:\fmcwinnt\SMP\Events\readme.html                \\ This documentation
d:\fmcwinnt\SMP\Events\process.gif                \\ Graphic 
d:\fmcwinnt\SMP\Events\scenario.gif               \\ Graphic
d:\fmcwinnt\SMP\Events\mf_regsub.gif              \\ Graphic
d:\fmcwinnt\SMP\Events\mf_publish.gif             \\ Graphic
d:\fmcwinnt\SMP\Events\mf_transfpub.gif           \\ Graphic
d:\fmcwinnt\SMP\Events\EventMsgFlows.exp          \\ MQSeries Integrator message flows
d:\fmcwinnt\SMP\Events\MQWFXML2.mrp               \\ MQSeries Integrator MQSWFXML message set
d:\fmcwinnt\SMP\Events\Events.mqs                 \\ Script to generate sample queues in the queue manager of                                                    
                                                  \\ the MQSeries Integrator broker
d:\fmcwinnt\SMP\Events\EventSample.fdl            \\ MQSeries Workflow TravelSurvey process
d:\fmcwinnt\SMP\Events\fmctwa6j.jar               \\ MQSeries Workflow postcard sample classes
d:\fmcwinnt\SMP\Events\WA06PostcardNative.dll     \\ MQSeries Workflow postcard sample dll for Windows
d:\fmcwinnt\SMP\Events\Postcard.bat               \\ Batch file to start the MQSeries Workflow postcard sample 
                                                  \\ application for Windows

Setting up the sample

This SupportPac is designed for an environment with predefined names of the queues and the queue manager. In addition, it is assumed that you run everything using a user ID, with all available authorization rights for MQSeries Workflow and the MQSeries Integrator.

A distributed environment or other user/authorization concepts are also feasible, but this is not described in this paper. You can set up the system as described in the following section.

It is assumed that you are familiar with the required products.

Setting up MQSeries Workflow

To run the sample, MQSeries Workflow must be installed on your system with a minimum of the following components:

The SupportPac sample is based on using a default configuration with the default queue manager name 'FMCQM', default system 'FMCSYS', and default system group 'FMCGRP'. For details on how to set up the default configuration, refer to the MQSeries Workflow Installation Guide. If you do not use the default names, you must change them accordingly in the MQSeries Integrator message flows and in the provided FDL, which is described later.

The sample process is modeled so that all activities run in the scope of the starter of the process. The user ID of the process starter is contained in the MQMD user identifier field of the XML message ActivityImplInvoke that arrives at the MQSeries Integrator. In the sample, this field contains the user ID of the user who started the TravelSurvey sample application.

Make sure that this user ID, which is defined in MQSeries Workflow, also is defined in your Windows system and that it has the necessary MQSeries authorization to issue PUT for the required message and the necessary authorization to issue Publish/Subscribe commands.

The sample is designed so that the MQSeries Workflow XML message that is sent to the UPES is put into the WA06_RegisterSubscriberInput queue of the MQSeries Workflow queue manager (FMCQM). The MQSeries Workflow queue manager name FMCQM is also used for the queue manager name of the MQSeries Integrator broker. If you change the MQSeries Workflow queue manager name, you must change it accordingly for the MQSeries Integrator broker.

Import the provided FDL file, called EventSample.fdl, into MQSeries Workflow Runtime as described in the Getting Started with Buildtime book. From a command prompt, enter the following command:

fmcibie -uADMIN -ppassword -yFMC -iEventSample.fdl -t -o
where 'ADMIN' and 'password' are the initial values of the default user ID after having installed MQSeries Workflow, and 'FMC' is the configuration identifier.

MQSeries Workflow is now ready to run.

You can verify your MQSeries Workflow setup by starting the MQSeries Workflow client (Start -> Programs -> MQSeries Workflow -> MQSeries Workflow client - FMC). If you start the MQSeries Workflow Client for the first time using your Windows NT user ID and password, one window displays showing a tree view. Then, create a process template list, an instance list, and a worklist. To do this, select any one of these in the tree view and right-click to open the context menu. Click Create New ... . Enter a name for the list, for example, TemplateList and click OK. Repeat these steps for the two remaining lists. A separate window is displayed for every list. In the template list, there is the process template TravelSurvey which represents the translated process model from Buildtime, called TravelSurvey. In the instance list, you can see an entry for every running TravelSurvey process as soon as this process is started.

Setting up MQSeries

For the sample, it is assumed that the queue manager name for MQSeries Workflow is FMCQM and this is also the queue manager name for MQSeries Integrator broker. In the configuration of this sample, MQSeries Workflow and the MQSeries Integrator broker share one queue manager. MQSeries Workflow creates the queue manager FMCQM during configuration. The broker is created during the configuration of MQSeries Integrator.

In addition to the queue manager, additional queues must be created for MQSeries Integrator and the postcard sample application. This SupportPac contains the following script file for MQSeries to create the required resources:

Setting up MQSeries Integrator

To run the sample, MQSeries Integrator must be installed and configured as described in the MQSeries Integrator documentation, for example, the MQSeries Integrator Installation book. The definition for queue manager name of the MQSeries Integrator broker is FMCQM, as described in the section Setting up MQSeries Workflow.

In this sample, it is assumed that you create a broker on the same queue manager (FMCQM) that is running on the MQSeries Workflow system. If you choose a different name, you must change the queue manager name in the MQSeries Workflow UPES 'MQSIPES' definition.

You must import the message set into the MQSeries Integrator message repository. Use the MQSeries Integrator command 'mqsimrmimpexp' and import the file MQWFXML2.mrp.

Example:

mqsimrmimpexp -i MQSIMRDB Userid password MQWFXML2.mrp
In this example, MQSIMRDB is your message repository database, which is created during the MQSeries Integrator setup, and Userid/password is the user ID and password you use to access the message repository database.

The imported message sets are now stored in the MQSeries message repository. Start the MQSeries Integrator Control Center. Click the Control Center page, called Message Sets, then select Message Set on the left pane. Open the context menu and click Add to Workspace. A list of message sets contained in the database is displayed. Select the newly imported message set, called 'MQSWFXML (MQSeries Workflow XML Message Set)'.

To display the MQSeries Integrator objects as, for example, messages and types, select the objects and open the context menu. Click 'Add to Workspace'. Then save the MQSeries Integrator workspace (File -> Save Workspace As...).

Note:
If the newly imported message sets are not displayed, stop all MQSeries Integrator services and start them again. Retry the preceding step to display the imported message sets.

Next, select the Control Center Import (File -> Import) to import the message flows. They are part of the distributed file EventMsgFlows.exp. This file was installed during installation (see Installation. Select the message flows page where you see the newly imported message flows, such as RegisterSubscriber, Publish, and TransformPublication. A blue square indicates that the message flows are new and available only on your local workspace.

To deploy the new message flows, they must be checked in to MQSeries Integrator. To do this, select every message flow. Open the context menu, then click 'Check In' or alternatively, in the tool bar, select File -> Local -> Save to Share, which checks in all objects from your workspace to MQSeries Integrator.

Create and set up an MQSeries Integrator broker FMCQM on queue manager FMCQM. To deploy the sample message flows to the MQSeries Integrator broker, select the Control Center Topology page, check out Topology, and click Topology -> Create -> Broker.

Note:
The broker itself should have already been created as described in the MQSeries Integrator installation and configuration. The step described here only creates a reference to the existing broker.

Add the name of the broker and the name of its queue manager. You can use the same name for both (default: FMCQM). Then, check in the newly created broker link and topology or use File -> Local -> Save to shared.

Next, you must deploy the message flows to the broker. To do this, select the Assignment page of the MQSeries Integrator control center. Three windows are displayed. The window on the left displays the Domain Hierarchy, the window in the middle displays the deployable message types, and on the right the domain topology window is displayed. Check out the newly created broker. The broker should already contain an Execution Group with a name 'default', which you must check out. The window in the middle displays the message sets and message flows and on the right, the broker name and the default execution group are displayed. Use the mouse to drag and drop the three sample message flows into the Execution Group default area. Alternatively, use 'Add' in the context menu for the default in the window on the left. Do not add the message set to the broker. Check in all the changes.

Next, select the broker displayed in the window and right-click the context menu, click Deploy -> Complete Assignment Configuration. This starts to publish the information to the MQSeries Integrator broker. A message box appears to inform you that the deployment has started. In the control center, select File -> Log ... from the toolbar, then click Refresh. When the deployment message tells you that the step was successful, the newly created information is available to the broker. The Control Center page 'Operation' displays the broker and the message flows with a green traffic light next to them. This means that MQSeries Integrator is ready to wait for messages in the input queues to convert them as needed.

Setting up DB2

MQSeries Workflow generates an 'Activity Implementation Correlation Identifier' within an XML message. This is a unique ID that is used by MQSeries Workflow to relate the XML reply to the XML request. This value and the values for the ReplyToQ, ReplyToQMgr and the messageID of the incoming ActivityImplInvoke message are stored in the MQSeries Workflow database FMCDB during the RegisterSubscriber message flow. In the TransformPublication message flow, these values are used and then deleted.

To use the sample, create a new table space, called CORRELDATA, and a new database table, called CORREL_DATA, in the MQSeries Workflow database FMCDB with the following settings:

CONNECT TO FMCDB;

------------------------------------
-- DDL Statements for TABLESPACES --
------------------------------------

CREATE REGULAR TABLESPACE "CORRELDATA" IN NODEGROUP IBMDEFAULTGROUP
    PAGESIZE 4096
    MANAGED BY SYSTEM USING ('container-string')
    EXTENTSIZE 32
    PREFETCHSIZE 16
    BUFFERPOOL IBMDEFAULTBP;

----------------------------------------------------
-- DDL Statements for table "WA06"."CORREL_DATA"
----------------------------------------------------

CREATE TABLE "WA06"."CORREL_DATA"
    (
     "REPLYTOQ" CHAR(48)                        ,
     "REPLYTOQMGR" CHAR(48)                     ,
     "MESSAGEID" CHAR(24) FOR BIT DATA  NOT NULL,
     "ACTIMPLCORRELID" CHAR(80)         NOT NULL
    )
IN "CORRELDATA";

-- DDL Statements for primary key on Table "WA06"."CORREL_DATA"

ALTER TABLE "WA06"."CORREL_DATA"
    ADD PRIMARY KEY
    (
     "MESSAGEID",
     "ACTIMPLCORRELID"
    );


COMMIT WORK ;

CONNECT RESET ;

TERMINATE ;
Because this sample needs all components running on one system and DB2 is already used for MQSeries Workflow and MQSeries Integrator, the following short description assumes that you have the rights to perform these tasks. If you have problems, contact your DB2 administrator or use the DB2 documentation.

Perform the following steps to create the database table CORREL_DATA:

The DB2 database table CORREL_DATA now is created.

To use this database for MQSeries Integrator, you must create a new ODBC data source for this database in ODBC. To do this, select Start -> Settings -> Control Panel -> Administrative Tools -> Data Sources (ODBC ). Switch to the System DSN page and click Add. Select the IBM DB2 ODBC DRIVER and click Finish. Select the database FMCDB in the database alias entry field and click OK.

If you want to use an own queue manager for MQSeries Integrator other than the MQSeries Workflow queue manager FMCQM, you have to use an own database for the broker to store the correlation data. If you want to use the two-phase commit protocol for this database, you have to enable it as follows:

Add an XAResourceManager stanza for the database manager that your queue manager is going to coordinate. For more information about how to do this, refer to the MQSeries System Administration Guide.

Running the sample

Usage:
Prerequisites: Normal processing:

When the steps to set up the system have been finished, you can run the sample. The following section describes the steps to run the sample.

  1. Use the Standard Client to create and start the process template 'TravelSurvey'. When the process is started, you are prompted to enter a customer name, which will be part of the input container. When the first process activity (SendQuestionnaireToCustomer)is finished, the next activity (WaitForCustomerResponse) is started automatically.
  2. The WaitForCustomerResponse activity is an unattended, that is, staffless activity which means that no work item is created for it. To verify that a subscribtion has been created for this staffless activity, check the entries on the Subscription page of the MQSeries Integrator control center. Then, start the MQSeries-based MQSeries Workflow postcard application using the customer name you have specified in step 1.
  3. Open a command prompt to start the MQSeries Workflow postcard application and change to the subdirectory where you have installed the Event sample (for example, cd  d:\fmcwinnt\smp\events). From this command prompt, invoke the MQSeries Workflow postcard application using the following command:
  4. Postcard.bat
    In the Postcard sign-on window, enter the customer name you have specified in step 1 and the name of the broker (FMCQM). When the postcard is displayed, enter a message text in the 'Message' input field and any receiver name in the 'To' input field, then click 'Send' to send the message. During this time, the next activity ProcessQuestionnaireResults is made ready for execution and the previous subscription is deleted. To verify that the subscription is deleted, check the entries on the Subscription page of the MQSeries Integrator control center.
  5. When you start the activity ProcessQuestionnaireResults, its input container should contain the message text you have entered in the previous step.
Special cases:
  1. Activity WaitForCustomerResponse expires

  2. If the customer does not respond to the survey, the activity expires after a specified amount of time (the default value in the delivered FDL is 7 days).

    Note:
    For the expiration of an activity it is required that the MQSeries Workflow Scheduling Server is running.

    If the expiration time has passed, an XML message ActivityExpired is sent to the UPES, that is, to the input queue WA06_RegisterSubscriberInput. Then, the activity NoResponseFollowup is started. The UPES, that is, the MQSeries Integrator message flow RegisterSubscriber deletes the correlation data from the MQSeries Workflow database, and deregisters the subscription in the Publish/Subscribe function (broker).

  3. Process TravelSurvey is terminated

  4. If the process is terminated, an XML message TerminateProgram is sent to the UPES. The UPES deletes the correlation data from the MQSeries Workflow database, and deregisters the subscription.

Handling problems and errors

Following are hints and tips to help you in case of problems with the sample or your scenario.