- Configuration and Testing
- Creating Queues on IBM WebSphere MQ using WebSphere MQ Explorer
- Managed Connection Factory
- Interaction Configuration
- Input and output
- Functional Demonstration
The MQSeriesOut component provides an interface to queues on IBM WebSphere MQ 5.3 and above, using MQSeries client for Java. The MQSeriesOut component receives messages from queues on MQSeries Queue Manager.
Configuration and Testing
Creating Queues on IBM WebSphere MQ using WebSphere MQ Explorer
Required queue should be created on IBM WebSphere MQ prior to configuring the component. This section can be ignored if the queue from which messages are received is already created.
Steps for creating a queue on IBM Websphere MQ
- Start WebSphereMQ Explorer.
- In the WebSphereMQExplorer – Navigator, expand IBMWebSphereMQ, right-click QueueManagers node.
- From the pop-up menu point to New and click QueueManager... (shown in Figure 1)
Figure 1: Adding new queue manager
- Enter the Queue manager name with required name in Enter basic values (step 1).
Figure 2: Providing a name for queue manager
- Proceed to Enter listener options (Step 4) of the wizard.
- Provide a port number which is not used by any other application or any other Queue Manager in IBM WebSphere MQ as shown in Figure 3.
Figure 3: Providing port number
- Click the Finish button.
- A new Queue Manager with given name is created and shown in WebSphereMQ Explorer – Navigator.
Figure 4: New Queue Manager Sample QM
- In the WebSphereMQ Explorer – Navigator, expand IBM WebSphere MQ > Queue Managers > SampleQM > Advanced and right-click Channels node as shown in Figure 5.
- From the pop-up menu, point to New and click Server-connection Channel to add a server-connection channel as shown in Figure 5.
Figure 5: Adding a server-connection channel
- Enter the Name in Create a Server-connection Channel step, as shown in Figure 6, and click Finish.
Figure 6: Configuring Server-connection Channel with required name
- On successful completion, newly added server-connection channel is shown when IBM WebSphere MQ > Queue Managers > SampleQM > Advanced > Channels node is expanded as shown in Figure 7.
Figure 7: Newly added server connection channel
- Right-click the newly added Server-connection Channel and click Start option from the pop-up menu as shown in Figure 8.
Figure 8: Starting Server-connection Channel
- In the WebSphereMQ Explorer – Navigator, expand IBM WebSphere MQ > Queue Managers > SampleQM and right-click Queues node as shown in Figure 8.
From the pop-up menu, point to New and click Local queue to add a local queue as shown in Figure 9.
Figure 9: Adding a new local queue
- Enter the Name in Create a Local Queue step, as shown in Figure 10, and click Finish.
Figure 10: Name for local queue
- On successful completion, newly added Local Queue is shown when IBM WebSphere MQ > Queue Managers > SampleQM > Queues node is expanded as shown in Figure 11.
Figure 11: Newly added Local Queue
Managed Connection Factory
The Connection details are configured in the first panel, Managed Connection Factory (MCF). The Figure 12 illustrates the panel with expert properties view enabled.
Figure 12: Connection configuration details in MCF panel
The hostname or IP address of the machine on which IBM WebSphereMQ Server is running. If connecting to IBM WebSphereMQ on the same machine on which the component is running, use localhost.
Port for MQSeries server
The port number on which IBM WebSphere MQ listens for connection requests to connect to configured Queue Manager. To view the port number for required Queue Manager (value for property Queue Manager Name, expand the node IBM WebSphere MQ > Queue Managers > SampleQM > Advanced > Listeners as shown in Figure 13. The value in Port column is the required port number.
Figure 14: Port number of Queue Manager Sample QM
Server channel Name
The case-sensitive name of the channel to be used for communicating with the Queue Manager.
Queue Manager Name
The name of the Queue Manager in which destination queue is present.
Figure 13: Authentication configuration details in MCF panel
Select Authentication Required check box if authentication is required while connecting to the MQSeries Server. When this value is selected, values for properties Username and Password are used for authentication.
The user name to be used to connect to the MQSeries Queue Manager. The ID is used to identify the WebSphere® MQ client. It overrides the value of WebSphere MQ environment variable MQ_USER_ID.
If no security exit is defined for this client, the value of userID is transmitted to the server and is available for use by the server security exit.
The default value is "" (empty string).
The password to be used to connect to the MQSeries Queue Manager. The password is used to verify the identity of the WebSphere® MQ Client. It overrides the value of MQEnvironment variable MQ_PASSWORD .
If a security exit is not defined for this client, the value of password is transmitted to the server and is available to the server security exit when it is invoked.
The default value is "" (empty string).
Using Named Configurations
Refer Named Configurations section under Common Configurations page to know how to used Named Configurations.
Send Exit Class
The class that implements the MQsendExit interface. This class allows you to examine and possibly alter the data sent to the queue manager by the MQSeries client. At runtime new instance of this class is created and assigned to the variable MQEnvironment.sendExit (class in IBM MQSeries API).
Receive Exit class
The class that implements the MQReceiveExit interface. This class allows you to examine and possibly alter the data received from the queue manager by the MQSeries client. At runtime new instance of this class is created and assigned to the variable MQEnvironment.receiveExit.
The class that implements the MQSecurityExit interface. This class allows you to customize the security flows that occur when an attempt is made to connect to a queue manager. At runtime, new instance of this class is created and assigned to the variable MQEnvironment.securityExit.
A WebSphere MQ JMS application can use channel security, send, and receive exits on the MQI channel that starts when the application connects to a queue manager. An application connects to a queue manager by setting channel related fields or environment properties in the MQEnvironment class. Further information can be found at http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.csqzaw.doc/uj21370_.htm
Business logic configuration details are configured in the second panel, Interaction Configurations. The Figure 14 illustrates the panel with expert properties view enabled.
Figure 15: Business logic configuration in Interaction Configurations panel
This property defines the queue on IBM WebSphere MQ from which messages are received, format of message, and message selection options.
Click the ellipsis button to launch an editor for providing these configurations.
Figure 16: Launching editor for configuring queue and message selection options
- Queue Name
Name of the queue on IBM WebSphere MQ from which messages are received.
- Text Type
An MQ message contains message descriptor (a set of headers that define the message) and data. The data is stored in binary format. Multiple fields are written in a sequence using a type specific API. The data in the message is read by the consuming application exactly in the same order as the data is written.
The MQSeriesOut component parses messages read from a MQ queue based on Structure and Headers configurations in the CPS. It builds output message based on Text Type, Output Mode, Structure and Headers configurations in the CPS.
- Parse Message
This option is used when the MQ message contains multiple fields in the message body. When this option is selected, both Structure button and Headers button are enabled. Fields in the MQ message are defined in Structure editor.
The MQ message is parsed based on the fields defined and a XML message containing fields and headers with their respective values is generated. The output message is always a XML message.
- Raw Text
This option is used if MQ message contains only a single string field. MQ message is read from the queue and the data from the message is set in text format on output message. Any headers that have to be read from the MQ message are defined in Headers editor. The output message can either be in raw text or in XML format based on the value for property Output Mode.
When this option is selected, Structure button is disabled and Headers button is enabled.
Refer to section Input and Output for details about the effects of these configurations on input and output structures.
- Output Mode
When Text Type is Raw Text, format of the message to be sent on output port can be set either as XML or Raw Text.
There are two formats for defining the output message:
- Raw Text
This option is used when the user wants the output message to be set as raw text. Headers defined in CPS are set as message properties on output message.
- Raw Text
This option is used when the user wants the output message in XML format. Output XML contains values for header fields defined in CPS and message body which contains the text read from MQ message.
This button is enabled only when Text Type is Parse Message. Click Structure button to launch editor to define the fields of the message, as shown in Figure 16.
Figure 17: Editor to define fields in message
The editor contains a table with Tag Name, Data Type and Length columns. Each row corresponds to a field in the MQ message. The value in Tag Name column is the element name for the element in XML structure which holds data for the field. The value in Data Type column is the type of the data that is held in the field. It can only contain following values (case-sensitive) - Char, Double, Float, Integer, Long Integer, Short Integer, UTF, String, Boolean, Byte Array. The value in Length column is the length of the field that has to be read from MQ message. This value is applicable for only String and Byte Array data types and the value is ignored for other data types. For String data type, default value is -1 which means whole message is read from MQ message and is set on the output message. Figure 16 shows the definition of structure to build the output message from MQ message with data for an ID, name and age of a person.
Order of the fields is important and the order of the rows in this table defines the order of fields in the MQ message. Move Up and Move Down buttons are used to reorder the fields. Add and Delete buttons are used to add or remove the fields.
Schema for output XML is built based on the fields defined here. However, the types for elements in schema do not use the types defined here. All the elements are defined as string type and hence, the schema does not validate content of element with appropriate data type.
Refer to section Input and Output for details about the effects of these configurations on input and output structures.
Click Headers button to launch an editor, Figure 17 defines MQ message descriptor(MQMD) fields that have to be read from the MQ message and set on output message.
Figure 18: Headers editor
Defining MQMD headers
Available Headers - Contains MQMD headers that are defined on MQ message.
Included Headers - Contains MQMD headers that can be defined on output message and whose values are taken from MQ message received from the queue.
Selected headers are set in Output XML when
- Text type is parse message or
- Text type is Raw Text and Output mode is XML
When output message is raw text, selected headers are set as message properties on the output message.
Headers in Available Headers and Included Headers together contain all MQMD headers.
MQMD headers can be selected or unselected as
- To read values of MQMD headers from MQ message and set them on output message, select required headers from Available Headers list and click .
- To read values of all MQMD headers from MQ message and set them on output message, click .
- To remove any of selected headers, select required headers from Included Headers and click .
- To remove all selected headers, click .
Refer to section MQMD headers for default values.
Include RFH2 Headers- Select this option to parse MQRFH2 headers present in MQ message and set them on output message.If this option is not selected,then MQRFH2 headers are discarded and the output message contains only message data present in MQ message.
RFHFolder format - This property is used to specify the way in which the variable portion of the RFHHeaders has to be sent in output XML. The variable portion of a RFH Header contains variable number of MQHRF2 folders. Refer to link http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.csqzak.doc/js07180.htm for additional details. It can be chosen as explained below
When this option is chosen the RFHFolders in the header is output as CDATA. For example a sample jms Folder<jms><Dst>queue:///Test</Dst><Dlv>4</Dlv><Tms>3543534</Tms></jms> present in the retrieved message is output as<![CDATA[<jms><Dst>queue:///Test</Dst><Dlv>4</Dlv><Tms>3543534</Tms></jms>]]>
- CUSTOM XMLWhen this opton is chosen the RFHFolders in the header is output as elements confirming to a schema. For example a sample jms Folder<jms><Dst>queue:///Test</Dst><Dlv>4</Dlv><Tms>3543534</Tms></jms> present in the retrieved message is output as <ns1:Folder type="jms"><ns1:Property name="Dst">queue:///Test</ns1:Property><ns1:Property name="Dlv">4</ns1:Property><ns1:Property name="Tms">3543534</ns1:Property></ns1:Folder>
Refer to section Input and Output for details about the effects of these configurations on input and output structures
Only some of most commonly used MQMD headers are provided in the CPS of the component. Refer to Table 1 for a short description and default value used for each MQMD header. Refer to link http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.csqzak.doc/mqmd.htm for detailed information on MQMD headers.
Table 1 Short descriptions, default values and data types of MQMD headers used in the component
MQMD header name
Name of application that put the message.
Empty string ("")
Type of application that put the message
Character set identifier of character data in the message
A byte string that the application can use to relate one message to another, or to relate the message to other work that the application is performing
byte array as a hex string
A byte string that is used to distinguish one message from another. The message identifier is a permanent property of the message, and persists across restarts of the queue manager.
byte array as a hex string
Delivery mode indicating whether the message survives system failures and restarts of the queue manager.
A period of time expressed in tenths of a second, set by the application that puts the message. The message becomes eligible to be discarded if it has not been removed from the destination queue before this period of time elapses.
Subfield of encoding header that specifies encoding for binary integers
Subfield of encoding header that specifies encoding for packed-decimal integers
Subfield of encoding header that specifies encoding for floating-point integers
Priority of the Message
Name of the message queue to which the application that issued the get request for the message sends MQMT_REPLY and MQMT_REPORT messages
Empty string ("")
Type of message
User identifier of the application that originated the message. The queue manager treats this information as character data, but does not define the format of it.
Empty string ("")
A name that the sender of the message uses to indicate to the receiver the nature of the data in the message
Sync Point Control Option
- Sync Point Control
The IBM WebSphere MQ series support transactions similar to JMS transaction. Select the check box if the transaction has to be committed after receiving a batch of messages. On selecting this option, the component assigns the message with sync point control. The message is not visible outside the unit of work (in this case, the sync point batch size) until the unit of work is committed. If the unit of work is rolled back from the server, the message is deleted.
The Batch Size is taken into account only if this check box is checked.
- Batch Size
The number of messages after which a commit should be performed if the check box Sync Point Control is checked. The Batch size is counted based on the number of messages that are successfully received from MQ Queue. If any message could not be sent to MQ Queue due to an error that message is not counted but the count continues.
Message Selection Properties
- Message SelectionThis option is used to receive specific messages from the MQ queue. Selection is based on the MQMD headers Message ID, Correlation ID and Message Sequence Number.
- Message Sequence Number
This is the sequence number of a logical message within a group.
- Message ID
This is a byte string that is used to distinguish one message from another.
- Correlation ID
This is a byte string that the application can use to relate one message to another, or to relate the message to other work that the application is performing
- Message Count
The number of messages to be received from the Queue. If the message count is specified as 'n', then the component aggregates and sends all the messages at a time after receiving 'n' messages. If Sync Point Control is checked this property is disabled and batch size is used to aggregate. Default value is 1. If this value is 0, all messages are fetched till the time out occurs as specified by Wait Interval and the aggregated message is sent to output port.
- Wait Interval
Maximum time in milliseconds the component should wait for a message on the MQ queue. When a request is sent to get message from queue, a message is received if it is present on the queue. If there are no messages on the queue, it waits for the specified interval of time for the message. Default value is -1 which specifies infinite wait time that is, waits until a message is received. Any value which is less than 0 (zero) specifies infinite time.
This property works in conjunction with Message Count property.
Example: If the MessageCount is set to 10000 and WaitInterval is set to 10 seconds. The component tries to fetch 10 messages from MQ queue. For each request to fetch message, if an unconsumed message is present on the MQ queue it is immediately fetched. If there are no messages on the MQ queue, then the component waits for utmost 10 seconds. If a message is not available on the queue during this wait time, the component builds output XML based on messages received so far for this request and sends it on the output port. If there are no messages received an empty output is sent on the output port.
If there are no messages on the queue till the time out occurs, then an empty message is sent to output port. Please refer to Scenario 4 in Functional demonstration section for the affects of this property on output message.
Coded Character Set Identification (should be an integer or null), in case of null, 819 (ISO 8859-1 ASCII) is used as CCSID. Data in MQ message is always present in the form of bytes. This field is used while converting this data bytes (decodes bytes into string using the specified Charset) and this conversion depends on the type of output message.
- When text type is Raw Text and Output mode is Raw Text, the data bytes in MQ message is converted to string data using the CCSID value and set as output message.
- When text type is Raw Text and Output mode is XML, the data bytes in MQ message is converted to string data using the CCSID value and set as message body in output message.
- When text type is parse message, the data bytes in MQ message are read based on the structure fields. Whenever there is a String data field, CCSID value is used for conversion of the data bytes.
- The behavior is unspecified if the data bytes present in message are not valid in specified Charset. There can be error while building the output message or they can be junk data in output message.
Action when message is not available?
This property specifies the action to be taken when there are no messages on the queue within the timeout specified.This property is disabled when the wait interval(timeout) is -1 (infinite).
- Send Empty Message
This value is set by default.An empty message is sent to output port when 'Text type' is set to 'Raw Text'. When Texttype is set to 'Parse message', a default xml message with empty 'MQMessages' element is sent to output port.
- Treat as Exception
An exception message is sent to error port and no message is sent to output port.
- No Action
No message is sent to either output port or error port.
Input and output
The input schema for the component is fixed. The schema is shown in Figure 18.
Figure 23: Schema for input message
All the elements present in the Input message are optional. If a particular element is present, its value is used while receiving the message; else default value specified in CPS is used.
Figure 24: Input message with no elements specified
Data in the fields EBCDIC_TO_ASCII_CONVERSION, IsSelectionRequired, IsSyncPointControl should be of boolean type and for data in SyncSize should be of Integer type, if data is not present in proper data types, error occurs while creating the output message.
The output schema for the component is based on the configuration selected.
When the Text Type is set to Raw Text and Output Mode is set to XML Text, then there is no schema defined for the output. The output message text contains a single String field.
Selected MQMD headers in CPS with values present of MQ message are set on output message.
When the Text Type is set to Parse Message the output schema varies based on the configuration of structure and headers.
- When only fields of message body are defined in Structure dialog as shown in Figure 20.
Figure 25: Fields defined for message body
The output schema is defined as shown in Figure 21 and a sample output message is shown in Figure 22.
Figure 26: Schema when only fields of message body are defined
All the fields defined are added as child elements under MessageBody in the same order in which these fields are defined in CPS. MQMD headers are not explicitly set by the component.
- When fields of message body are defined in Structure dialog as shown in Figure 20 and MQMD headers are defined in Headers dialog as shown in Figure 23
Figure 27: MQMD headers are defined in Headers
Figure 28: Selecting MQMD headers whose values have to be taken from input XML
The output schema is defined as shown in Figure 24 and a sample output is shown in Figure 25.
Figure 29: output schema
Figure 30: Sample input XML for schema defined in Figure 23
All the fields defined are added as child elements under MessageBody in the same order in which these fields are defined in CPS and all the MQMD headers selected are added as child elements under Message Header in the same order in which these headers are defined in CPS.
When the Text Type is set to Raw Text and Output Mode is set to XML Text, the output schema varies based on the configuration headers.
- When there are no selected headers in CPS, then the output Schema is set as shown in Figure 26 and a sample output is shown in Figure 27.
Figure 31: Schema when there are no selected headers
Figure 32: Ouput XML when there are no selected headers
- When MQMD headers are defined in Headers dialog as shown in Figure 23, then the output Schema is set as shown in Figure 28 and a sample output is shown in Figure 29.
Figure 33: Schema when there are selected headers
Figure 34: Ouput XML when there are selected headers
When Include RFH2 Headers option is selected in Headers as shown in Figure 30 and Text Type is set to Raw Text, then output schema is set as shown in Figure 31 and a sample output is shown in the Figure 32.
Figure 35: Option to include RFH2 headers
Figure 36: Output Schema when Include RFH2 Headers is selected.
Figure 37: Sample output XML when Include RFH2 Headers is selected.
For all the messages that are sent to output port, a message property QueueName is set with the value of queue name from which message has been received.
Configure the component for Text type mode as Raw Text, Output Mode as Raw Text and configure Headers as shown in Figure 33.
Figure 38: Configuration of headers for Scenario 1
Figure 39: Message properties of output message
Configure the component for Text type mode as Raw Text, Output Mode as XML and configure Headers as shown in Figure 33.
Configure the component for Text type mode as Parse Message and configure Headers as shown in Figure 33.
This scenario describes the aggregation of messages using the property Message Count and Wait Interval. Configure the component as described in any of the above 3 scenarios.
When time out occurs and no message is available on the queue, sample message sent to output port is shown below.
This scenario describes to include RFH2 headers in output message .Configure the component for Text Type to Raw Text and headers as shown in Figure 30.
This scenario describes the property 'Action when message is not available' property. Set 'Wait Interval' to a finite value(say 1000 msec) and TextType to 'Parse Message'.
Set 'Action when message is not available' to 'Send Empty Message'.
The correct CCSID should be set for message encoding when transferring messages from AS 400 systems to other platforms and vice versa.