MQSeriesIn

 

Configuration and Testing. PAGEREF _Toc225250826 \h 2

Creating queues on IBM WebSphere MQ using  WebSphere MQ explorer PAGEREF _Toc225250827 \h 2

Managed Connection Factory. PAGEREF _Toc225250828 \h 7

Attributes. PAGEREF _Toc225250829 \h 7

Interaction Configuration. PAGEREF _Toc225250830 \h 9

Attributes. PAGEREF _Toc225250831 \h 10

Input and Output PAGEREF _Toc225250832 \h 19

Input PAGEREF _Toc225250833 \h 19

Output PAGEREF _Toc225250834 \h 24

Functional Demonstration. PAGEREF _Toc225250835 \h 25

Scenario 1. PAGEREF _Toc225250836 \h 25

Scenario 2. PAGEREF _Toc225250837 \h 26

Useful Tips. PAGEREF _Toc225250838 \h 28

 

The MQSeriesIn component provides an interface to queues on IBM WebSphere MQ 5.3 and above using MQSeries client for Java. The component sends messages that are received to queues on the MQSeries Server. The input message contains details of the message to be sent to the queue.

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 skipped if the queue to which messages are sent is already created.

Steps for creating a queue on IBM Websphere MQ:

1.      Start WebSphereMQ Explorer.

2.      In the WebSphereMQ Explorer – Navigator pane, expand the IBM WebSphere MQ and right-click Queue Managers node.

3.      From the pop-up menu, select New and click Queue Manager... (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) wizard page.

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 Finish. A new Queue Manager with given name is created and shown in WebSphereMQ Explorer – Navigator.

                Figure 4: New Queue Manager Sample QM

8.      In the WebSphereMQ Explorer – Navigator, expand IBM WebSphere MQ > Queue Managers > SampleQM > Advanced and right-click Channels node as shown in Figure 5.

9.      From the pop-up menu, select New and click Server-connection Channel to add a server-connection channel as shown in Figure 5.

                Figure 5: Adding a server-connection channel

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

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

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

13.  In the WebSphereMQ Explorer – Navigator, expand IBM WebSphere MQ > Queue Managers > SampleQM and right-click Queues node as shown in Figure 8.

14.  From the pop-up menu, select 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

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

TOP

Managed Connection Factory

The connection details are configured in the first panel, Managed Connection Factory (MCF). Figure 12 illustrates the panel with expert properties  view enabled.

Figure 12: Connection configuration details in MCF panel

TOP

Attributes

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 IBM WebSphere MQ > Queue Managers > SampleQM > Advanced > Listeners in WebSphereMQ Explorer – Navigator as shown in Figure 13.

Figure 13: Port number of Queue Manager Sample QM

Server Channel Name

The name of the channel to be used for communicating with the Queue Manager. Note: The channel name is case-sensitive.

Queue Manager Name

The name of the Queue Manager in which destination queue is present.

Is Authentication required

Use authentication when connecting to the MQSeries Server. When this value is selected, values for properties Username and Password are used for authentication.

Do not use authentication when connecting to the MQSeries Server. When this value is selected, values for properties Username and Password (if provided) are ignored while connecting to Queue Manager.

User name

The user name to connect to the MQSeries Queue Manager.

Password

The user password to connect to the MQSeries Queue Manager.

SendExitClass

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

ReceiveExitclass

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.

SecurityExitClass

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      

TOP

Interaction Configuration

Business logic configuration details are configured in the second panel, Interaction Configurations. Figure 14 illustrates the panel with expert properties  view enabled.

Figure 14: Business logic configuration in Interaction Configurations panel

TOP

Attributes

DestinationQueue

This property defines the queue on IBM WebSphere MQ to which messages are sent, format of message, and message sending options.

Click the ellipsis button  to launch an editor for providing these configurations.

Figure 15: Launching editor for configuring queue and message sending options

Name of the queue on IBM WebSphere MQ to which messages are sent.

A 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 MQSeriesIn component takes in an input message in text format (either XML or raw), builds a MQ message internally from the message in text format based on message details configured in CPS and sends the message to the configured queue.

There are two formats for defining the input message:

This option defines a XML structure with headers and fields of message body defined in CPS. The input XML contains values for headers and message body fields, which are parsed and respective values, are set on MQ message. The MQ message will then be sent to MQ queue.

This option should be used in any of the following cases:

- When the message body contains data for multiple fields. Example: Name and age of a person MQMD or RFH2 headers and/or  their values vary with each input message.

- When this option is selected, both Structure and Headers buttons are enabled.

This option does not define any structure for input message. The input message is set on the message body as a single string field. Headers (MQMD and RFH2) with values defined in CPS are sent on every message. Only one RFH2Header is added to the message.

This option should be used when the all of the followings conditions are met:

- When the message body contains only a single text field and complex transformation and XML parsing can be avoided. A typical  case, when a message is pulled from one system and passed on without any modifications to IBM WebSphere MQ series. MQMD or RFH2 headers and their values are constant for all messages.

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.

The structure button is enabled only when Text Type is XML Text. Click this button to launch editor to define the fields of the message. Refer Figure 16.

                Figure 16: Editor to define fields in message

The editor contains a table with Tag Name and Data Type 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 Figure 16 shows the definition of structure to build a MQ message with data for a ID, name and age of a person.

The order of the fields is important and the order of the rows in this table defines the order of fields in the MQ message. The Move Up and Move Down buttons are used to reorder the fields. The Add and Delete buttons are used to add or remove the fields.

The schema for input 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.

Note:

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, refer to Figure 17, that defines MQ message descriptor (MQMD) fields and RFH2 Headers to be used. This property depends on Text Type.

Defining headers when Text Type is XML Text

When Text Type is set to XML Text the editor defines the following:

                Figure 17: Headers editor when Text Type is XML Text

Defining MQMD headers

Available Headers: Contains MQMD headers that can be defined on MQ message and whose values are not taken from input message. Headers in this list are set with default values on MQ message.

Included Headers: Contains MQMD headers that can be defined on MQ message and whose values are taken from input message.

Headers in Available Headers and Included Headers together contain all MQMD headers.

MQMD headers can be selected or unselected as

The default values are used for MQMD headers which are in Available Headers list or which are in Included Headers, but corresponding elements are not present in input XML.

Refer to section MQMD headers for default values

Defining RFH2 headers

Select the Include RFH2 headers check box to set RFH2 headers on MQ Message, refer to Figure 17. If the check box Include RFH2 headers is unchecked the input schema created will not contain elements related to RFH2 headers.

Multiple RFH2 headers can be set in the input message. Each RFH2 header should contain all the fields shown in Figure 17. If any RFH2 header in input XML does not contain the particular field then corresponding value from the Default Value column is used. The Variable data is also a field of RFH2 header and is treated similar to other RFH2 fields in the table.

Refer to section RFH2 header fields for default values.

Defining headers when Text Type is Raw Text

When Text Type is set to Raw Text the editor defines the following:

           Figure 18: Selection of MQBD headers that has to be set on the input message

Defining MQMD headers

Select the check box in Select column if a particular MQMD header value in Name column has to be set on the input message with value specified in Constant Value column, refer to Figure 18. If the check box in Select column is not checked, then the default value for corresponding MQMD header is used. The values provided in Constant Value column are not validated against the data type of the corresponding MQMD header and hence, should be carefully defined.

Note: MQMD headers are set with same values on all messages.

Refer to section MQMD headers for default values and data types.

Defining RFH2 headers

Select the Include RFH2 headers check box to set RFH2 header on MQ Message, refer to Figure 18. If the check box Include RFH2 headers is unchecked RFH2 header is not set on the message.

Only one RFH2 header can be set on message. Values for each field of RFH2 header can be provided in Constant Value column against corresponding field as shown in Figure 18. The Variable data is also a field of RFH2 header and is treated similar to other RFH2 fields in the table. By default, when this editor is opened for the first time default values for all fields are loaded.

Refer to section RFH2 header fields for additional information.

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.

Note: Values in Default value column of Table 1 are the defaults defined in the component and may vary from the actual default values of IBM WebSphere MQ.

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

RFH2 Header fields

Refer to Table 2 for a short description and default value used for each RFH2. Refer to link  http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.csqzak.doc/csqzak10172.htm  for detailed information on RFH2 header fields.

Note: Values in Default value column of Table 2 are the defaults defined in the component and may vary from the actual default values of IBM WebSphere MQ.

Table 2 Short descriptions, default values and data types of RFH2 header fields used in the component

 

RFH2 Header field

Description

Default value

Data type

StructId

Structure identifier. This field should strictly contain 4 characters. If there are more than 4 characters content after 8th character is pruned by the component. If there are less than 8 characters required additional blank spaces are padded at the end by the component.

RFH (MQRFH_STRUC_ID)

String of length 4 characters

Version

Structure version number

2 (MQRFH_VERSION_2)

Integer

Encoding

The numeric encoding of the data that follows the last NameValueData field; it does not apply to numeric data in the MQRFH2 structure itself

273 (MQENC_NATIVE)

Integer

CodedCharSetId

The character set identifier of the data that follows the last NameValueData field; it does not apply to character data in the MQRFH2 structure itself.

1208

Integer

Format

The format name of the data that follows the last NameValueData field. This field should strictly contain 8 characters. If there are more than 8 characters content after 8th character is pruned by the component. If there are less than 8 characters required additional blank spaces are padded at the end by the component.

MQSTR   (MQFMT_STRING)

String of length 8 characters

Flags

This value should be set to MQRFH_NONE

0 (MQRFH_NO_FLAGS)

Integer

NameValueCCSID

The coded character set identifier of the data in the NameValueData field.

1208

Integer

Variable Data

A variable-length character string containing data encoded using an XML-like syntax. Refer to link http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.csqzak.doc/js07180.htm for additional details about this field

null

String

The IBM WebSphere MQ series support transactions similar to JMS transaction. Select the check box if the messages sent to MQ queue have to be committed after sending a batch of messages. The messages are not visible or available for consumption on queue until a commit is performed. If the check box is unchecked, any messages sent are immediately available for consumption on the queue.

The Batch Size is taken into account only if this check box is checked.

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

CCSID

The Coded Character Set Identification should be an integer or null, in case of null, 819 (ISO 8859-1 ASCII) is used as CCSID. This character set is set on the MQMessage. This overrides the MQCharacterSet header property set in MQMD headers.

TOP

Input and Output

Input

The input schema for the component is defined based on the configuration selected.

                Figure 19: Fields defined for message body

The input schema is defined as shown in Figure 20 and a sample input is shown in Figure 21.

Figure 20: Schema when only fields of message body are defined

Figure 21: Sample input XML for schema in Figure 20

All the fields defined are added as child elements under MessageBody in the same order in which these fields are defined in CPS. The Input XML should have all the fields and should strictly follow the order. MQMD headers are not explicitly set by the component.

                Figure 22: Selecting MQMD headers whose values have to be taken from input XML

The input schema is defined as shown in Figure 23 and a sample input is shown in Figure 24.

Figure 23: Input schema when fields of message body and some MQMD headers are defined

Figure 24: 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.

If Message Header element is not present MQMD headers are not explicitly set by the component and it behaves exactly like the case where only the fields of message body are defined.

If Message Header element is present, then for the MQMD fields that are present under the Message Header element in input XML, values are taken from input XML. For the MQMD fields that are not present under the Message Header element, default values as described in section MQMD Headers are used irrespective of whether the header is selected or not in CPS as shown in Figure 22.

Figure 25: Selecting some MQMD headers and enable RFH2 header

The input schema is defined as shown in Figure 26 and a sample input is shown in Figure 27.

Figure 26: Schema when RFH2 headers are selected as well

Figure 27: Sample input XML for schema defined in Figure 26

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. The RFH2 headers are added as well under Message Header element as RFH2Headers element, and the RFH2Headers element can contain multiple RFH2Header elements.

If Message Header element is not present, MQMD headers and RFH2 header are not explicitly set by the component and it behaves exactly like the case where only the fields of message body are defined.

If Message Header element is present, then for the MQMD fields that are present under the Message Header  element in input XML, values are taken from input XML. For the MQMD fields that are not present under the Message Header element, default values as described in section MQMD Headers are used irrespective of whether the header is selected or not in CPS as shown in Figure 25. If RFH2Headers element is not present or if  RFH2Headers element is present but does not have any child RFH2Header elements then RFH2 headers are not set. If there is a RFH2Headers element which contains one or more RFH2Header elements as children, then one RFH2 header is added for each of the RFH2Header elements present in the same order. A RFH2 header is populated with field values from the values present at elements with corresponding field names. If a particular field element is not present, as a child to RFH2 header then the default value defined in the CPS for that field is taken.

If the input message contains a property with name TargetQueueName and the value of property is not null message, the message is sent to the queue with name specified by the property. If the property is not defined or a value is not set for the property the message is sent to queue with name configured in CPS.

TOP

Output

The output schema for the component is fixed. The schema is shown in Figure 28.

Figure 28: Schema for output message

The output message contains only two elements:

The queue name to which the message is sent is also set as message property with name TargetQueueName.

TOP

Functional Demonstration

Scenario 1

Configure the component for Text type mode as Raw Text and configure Headers as shown in Figure 29.

Figure 29: Configuration of headers for scenario 1

Input Message

testMessage

Output Message

<?xml version="1.0" encoding="UTF-8"?>

<MessagePublishReport xmlns="http://www.fiorano.com/fesb/activity/MQSeriesIn1In/Out">

   <QueueName>TestQueue</QueueName>

   <status>success</status>

</MessagePublishReport>

Note: MQMD headers that are selected in Figure 19 are set on MQMessage with values provided in Constant Value column. For the MQMD headers which are not selected in CPS, default values are set on MQ Message.

TOP

Scenario 2

Configure the component for XML type message.

Add two fields Name1 and Name2 with type String in Structure editor as shown in Figure 30.

Figure 30: Fields in message body for scenario 2

Select MQMD headers MQCharacterSet and MQApplicationName and check RFH2 Headers as shown in Figure 31

Figure 31: Headers defined for scenario 2

InputMessage:

<ns1:MQMessage xmlns:ns1="http://www.fiorano.com/fesb/activity/MQSeriesIn1In/In">

   <ns1:MessageHeader>

      <ns1:MQCharacterSet>1208</ns1:MQCharacterSet>

      <ns1:RFH2Headers>

         <ns1:RFH2Header>

            <ns1:StructId>RFH</ns1:StructId>

            <ns1:Version>2</ns1:Version>

            <ns1:Encoding>273</ns1:Encoding>

            <ns1:CodedCharSetId>1208</ns1:CodedCharSetId>

            <ns1:Format>MQSTR</ns1:Format>

            <ns1:Flags>0</ns1:Flags>

            <ns1:NameValueCCSID>1208</ns1:NameValueCCSID>

            <ns1:VariableData><![CDATA[<mcd>jms_text</mcd>]]></ns1:VariableData>

         </ns1:RFH2Header>

      </ns1:RFH2Headers>

   </ns1:MessageHeader>

   <ns1:MessageBody>

      <ns1:Name1>Name1value</ns1:Name1>

      <ns1:Name2>Name2value</ns1:Name2>

   </ns1:MessageBody>

</ns1:MQMessage>

OutputMessage:

<?xml version="1.0" encoding="UTF-8"?>

<MessagePublishReport xmlns="http://www.fiorano.com/fesb/activity/MQSeriesIn1In/Out">

   <QueueName>TestQueue</QueueName>

   <status>success</status>

</MessagePublishReport>

Note: In the above sample, input message only not all MQMD headers which are selected in CPS are provided. For those MQMD headers which are not provided in input message, default values are set. And for RFH2 headers, default values are taken from the CPS if they are not provided in input message.

TOP

Useful Tips

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

 

TOP

Copyright © 1999-2008, Fiorano Software Technologies Pvt. Ltd. All rights reserved.

Copyright © 2008-2009, Fiorano Software Pty. Ltd. All rights reserved.

This software is the confidential and proprietary information of Fiorano Software ("Confidential Information"). You shall not disclose such Confidential Information and shall use it only in accordance with the terms of the license agreement enclosed with this product or entered into with Fiorano.