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

  1. Start WebSphereMQ Explorer.
  2. In the WebSphereMQExplorer – Navigator, expand IBMWebSphereMQ, right-click QueueManagers node.
  3. From the pop-up menu point to New and click QueueManager... (shown in Figure 1)


    Figure 1: Adding new queue manager
     
  4. Enter the Queue manager name with required name in Enter basic values (step 1).


    Figure 2: Providing a name for queue manager
     
  5. Proceed to Enter listener options (Step 4) of the wizard.
  6. 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
     
  7. Click the Finish button.
  8. A new Queue Manager with given name is created and shown in WebSphereMQ Explorer – Navigator.


    Figure 4: New Queue Manager Sample QM
     
  9. In the WebSphereMQ Explorer – Navigator, expand IBM WebSphere MQ > Queue Managers > SampleQM > Advanced and right-click Channels node as shown in Figure 5.
  10. 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
     
  11. 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

  12. 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
     
  13. 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
     
  14. 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
     
  15. Enter the Name in Create a Local Queue step, as shown in Figure 10, and click Finish.


    Figure 10: Name for local queue
     
  16. 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
Icon

To put a test message in the Queue from the wizard, expand SampleQM -> Queues, right-click on SampleQueue and select Put Test Message and then enter some message in the 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.

Attributes

Connection Configuration


Figure 12: Connection configuration details in MCF panel

Host Address

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.

Authentication Configuration


Figure 13: Authentication configuration details in MCF panel

Authentication required

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.

Username

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

Password

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.

SecurityExit Class

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

Interaction Configuration

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

Attributes

MonitoredQueue

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

      Icon

      When the Include RFH2 Headers is selected in Headers option, the Output Mode gets disabled and output message is always set to xml format.

Structures

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.

Icon
  • Data in output XML for Boolean type fields contains true or false.
  • Data in output XML for Byte Array type fields contains Base64 encoded string. The Base64-Decode function under Advanced Functions in Fiorano Mapper can be used to convert Base64 encoded string into byte array.
  • If the order of elements defined in Structure editor differs from order of fields in MQ message or if there are additional fields defined in Structure editor or if some of the fields present in the MQ message are not defined in the Structure editor, one of the following happens:
    • error when building output message from MQ message.
    • mixed up values between fields.
    • junk data is set on output message.

Refer to section Input and Output for details about the effects of these configurations on input and output structures.

Headers

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

  • TEXT
    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>
Icon
  • When the Include RFH2 Headers is selected, the output message is always in XML format and Output Mode is disabled.
  • The component is able to parse MQRFH2 headers present in MQ message. Any other headers except MQMD and MQRFH2 headers (if present) are not parsed and are set in message body of the output message.

Refer to section Input and Output for details about the effects of these configurations on input and output structures

MQMD Headers

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

Description

Default value

Data type

MQApplicationName

Name of application that put the message.

Empty string ("")

String

MQApplicationType

Type of application that put the message

0 (MQAT_NO_CONTEXT)

Integer

MQCharacterSet

Character set identifier of character data in the message

0 (MQCCSI_Q_MGR)

Integer

MQCorrelationID

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

null (MQCI_NONE)

byte array as a hex string

MQMessageID

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.

null (MQMI_NONE)

byte array as a hex string

MQDeliveryMode

Delivery mode indicating whether the message survives system failures and restarts of the queue manager.

0 (MQPER_NOT_PERSISTENT)

Integer

MQExpirationTime

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.

-1 (MQEI_UNLIMITED)

Integer

MQEncodingBinaryIntegers

Subfield of encoding header that specifies encoding for binary integers

1 (MQENC_INTEGER_NORMAL)

Integer

MQEncodingPackedDecimal

Subfield of encoding header that specifies encoding for packed-decimal integers

16 (MQENC_DECIMAL_NORMAL)

Integer

MQEncodingFloatPointNumbers

Subfield of encoding header that specifies encoding for floating-point integers

256 (MQENC_FLOAT_IEEE_NORMAL)

Integer

MQPriorityTag

Priority of the Message

-1 (MQPRI_PRIORITY_AS_Q_DEF)

Integer

MQReplyToQueueName

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 ("")

String

MQMessageType

Type of message

8 (MQMT_DATAGRAM)

Integer

MQUserId

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 ("")

String

MQMessageFormat

A name that the sender of the message uses to indicate to the receiver the nature of the data in the message

null

String

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

If the batch size is 'n', then all the n messages are sent out as a single aggregated message.

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.

Icon

When Message Count is 0 (zero) and Wait Interval is -1, the component receives messages from the queue and processes them for aggregation but no message is sent to output port. This combination of Message Count and Wait Interval should not be used.

 

CCSID

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

Input

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

Icon

The component also accepts null message as an input. When null/empty message is sent as an input, then the value specified in CPS is used.


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.

Output

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.

Icon

When the Include RFH2 headers option is selected, the headers are set in output message in xml format.

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.

Functional Demonstration

Scenario 1

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

Input Message

Output Message

TestMessage


Figure 39: Message properties of output message

Scenario 2

Configure the component for Text type mode as Raw Text, Output Mode as XML and configure Headers as shown in Figure 33.

InputMessage

OutputMessage

Scenario 3

Configure the component for Text type mode as Parse Message and configure Headers as shown in Figure 33.

InputMessage

OutputMessage

Scenario 4

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.

InputMessage

Icon

When there are two messages available on the MQ queue, then both of them are fetched as shown in the OutputMessage.

OutputMessage

When time out occurs and no message is available on the queue, sample message sent to output port is shown below.

OutputMessage

Scenario 5

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.

InputMessage

OutputMessage

Scenario 6

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

InputMessage

OutputMessage

Icon

For the same scenario,but when TextType is set to 'RawText', a message with empty content is sent to output port

Useful Tips

The correct CCSID should be set for message encoding when transferring messages from AS 400 systems to other platforms and vice versa.

Adaptavist ThemeBuilder EngineAtlassian Confluence