IBM Integration Bus, Version 9.0.0.8 Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

See information about the latest product version

MQGet node

Use the MQGet node to receive messages from clients that connect to the broker by using the WebSphere® MQ Enterprise Transport, and the MQI and AMI application programming interfaces.

You can also use the MQGet node to retrieve messages that were previously placed in a WebSphere MQ message queue that is defined to the broker queue manager.

This topic contains the following sections:

The topic uses the following terms:

input message: A message that enters the In terminal of the MQGet node.
queue message: A message that the MQGet node reads from the queue.

Purpose

The MQGet node reads a message from a specified queue, and establishes the processing environment for the message. If appropriate, you can define the input queue as a WebSphere MQ clustered queue or shared queue.

You can use an MQGet node anywhere in a message flow, unlike an MQInput node, which you can use only as the first node in a message flow. The output message tree from an MQGet node is constructed by combining the input tree with the result tree from the MQGET call. You can set the properties of the MQGet node to control the way in which messages are received; for example, you can indicate that a message is to be processed under transaction control, or you can request that, when the result tree is being created, data conversion is performed on receipt of every input message.

The MQGet node handles messages in the following message domains:

DFDL
XMLNSC
DataObject
JSON
BLOB
MIME
MRM
JMSMap
JMSStream
XMLNS

The MQGet node is contained in the WebSphere MQ drawer of the palette, and is represented in the IBM® Integration Toolkit by the following icon:

Using the MQGet node in a message flow

For information about how to use the MQGet node in a message flow, see A request-response scenario that uses an MQGet node.

Look at the following sample to see how to browse messages with the MQGet node:

Browsing WebSphere MQ Queues

You can view information about samples only when you use the product documentation that is integrated with the IBM Integration Toolkit or the online product documentation. You can run samples only when you use the product documentation that is integrated with the IBM Integration Toolkit.

Configuring the MQGet node

When you have put an instance of the MQGet node into a message flow, you can configure it; for more information, see Configuring a message flow node. The properties of the node are displayed in the Properties view.

All mandatory properties for which you must enter a value (those properties that do not have a default value defined) are marked with an asterisk.

Configuring for coordinated transactions

When you include an MQGet node in a message flow, the value that you set for Transaction mode defines whether messages are received under sync point.

If you set the property to Yes (the default), the queue message is received under sync point (that is, in a WebSphere MQ unit of work). Any messages that an output node in the same instance of the message flow sends later are put under sync point, unless the output node, or any other subsequent node, overrides this setting explicitly.
If you set the property to Automatic, the queue message is received under sync point if the incoming message is marked as persistent. Otherwise, it is not received under sync point. Any message that is sent later by an output node is put under sync point, as determined by the incoming persistence property, unless the output node, or any other subsequent node, overrides this setting explicitly.
If you set the property to No, the queue message is not received under sync point. Any messages that are sent later by an output node in the message flow are not put under sync point, unless an individual output node, or any other subsequent node, specifies that the message must be put under sync point.

If you set the Browse only property, the value that you set for the Transaction mode property is ignored because a message cannot be browsed under sync point. However, any derived messages that are propagated later by an output node in the same instance of the message flow follow the behavior that is described previously in accordance with the specified Transaction mode value.

Overriding node properties during message processing

When you include and configure an MQGet node in a message flow, you might want to override its properties under some conditions. For example, you might want to read from a queue that is identified in another part of the message, or that is retrieved from a database record.

To override the values that you set for the MQGet node properties to achieve a more dynamic way to process messages, include a Compute or JavaCompute node in your message flow before the MQGet node. Configure this node to create an output message, and add fields to the local environment tree to define new values for the properties that you want to change.

For example, add a Compute node into the flow and define a new queue name for the MQGet node to read for messages, by including the following ESQL statement:

SET LocalEnvironment.MQ.GET.QueueName = 'new_queue';

Use LocalEnvironment.MQ.GET. as the correlation name for all fields that relate to the MQGet node.

You can set the following properties under the InputLocalEnvironment.MQ.GET tree. If you have set a value for the Input MQ parameters location property on the MQGet node, that tree location is checked instead.

Setting Description

QueueName

Setting	Description
QueueName	This setting overrides the MQGet node Queue name property; for example: `SET InputLocalEnvironment.MQ.GET.QueueName = 'myQueue';`
InitialBufferSize	This setting overrides the MQGet node Minimum message buffer size property; for example: `SET InputLocalEnvironment.MQ.GET.InitialBufferSize = 1024;`
MQGMO.*	This setting overrides the MQGET message options used by the MQGet node; for example: `SET InputLocalEnvironment.MQ.GET.MQGMO.Options = MQGMO_ACCEPT_TRUNCATED_MSG; SET InputLocalEnvironment.MQ.GET.MQGMO.WaitInterval = 10000;` This override is provided for flexibility, but should be used with caution because the MQGMO is used exactly as specified. Node properties and other local environment overrides are not considered. For more information about the MQGMO structure, see the WebSphere MQ Version 7 product documentation online.

This setting overrides the MQGet node Queue name property; for example:

SET InputLocalEnvironment.MQ.GET.QueueName = 'myQueue';

InitialBufferSize

This setting overrides the MQGet node Minimum message buffer size property; for example:

SET InputLocalEnvironment.MQ.GET.InitialBufferSize = 1024;

MQGMO.*

This setting overrides the MQGET message options used by the MQGet node; for example:

SET InputLocalEnvironment.MQ.GET.MQGMO.Options = MQGMO_ACCEPT_TRUNCATED_MSG;
SET InputLocalEnvironment.MQ.GET.MQGMO.WaitInterval = 10000;

This override is provided for flexibility, but should be used with caution because the MQGMO is used exactly as specified. Node properties and other local environment overrides are not considered.

For more information about the MQGMO structure, see the WebSphere MQ Version 7 product documentation online.

Connecting the terminals

Connect the Out, Warning, Failure, and No Message output terminals of this node to another node in the message flow to process the message further, process errors, or send the message to an additional destination.

The completion code (CC) that is generated by the MQGET call controls what is propagated to each of the output terminals.

If the MQGET call is successful, the MQGet node routes each parsed output message to the Out terminal.
If the MQGET call fails, but with a CC that indicates a warning, an unparsed output message is propagated to the Warning terminal.
If the MQGET call fails with a CC more severe than a warning, the input message is propagated to the Failure terminal.
If the MQGET call fails with a reason code of MQRC_NO_MSG_AVAILABLE, the output message is propagated (without a result body) to the No Message terminal. The output message that is propagated to the No Message terminal is constructed from the input message only, according to the values of the Generate mode, Copy message, and Copy local environment properties.
If you do not connect the Out, Warning, or No Message terminals to another node in the message flow, any message that is propagated to those terminals is discarded.
If you do not connect the Failure terminal to another node in the message flow, the broker generates an exception when a message is propagated to that terminal.

For more information, see Connecting failure terminals.

Terminals and properties

The terminals of the MQGet node are described in the following table.

Terminal	Description
In	The input terminal that accepts the message that is being processed by the message flow.
Warning	The output terminal to which the output tree is propagated if an error (with a CC that indicates a warning) occurs in the node while trying to get a message from the queue. The MQMD part of the message is parsed, but the rest of the message is an unparsed BLOB element. The warning is discarded if the terminal is not connected, and there is no output propagation from the node at all.
Failure	The output terminal to which the input message is routed if an error (with a CC that indicates an error that is more severe than a warning) occurs in the node while trying to get a message from the queue.
Out	The output terminal to which the message is routed if it is retrieved successfully from the WebSphere MQ queue.
No Message	The output terminal to which the input message is routed if no message is available on the queue. The output message that is propagated to the No Message terminal is constructed from the input message only, according to the values of the Generate mode, Copy message, and Copy local environment properties.

The following tables describe the node properties. The column headed M indicates whether the property is mandatory (marked with an asterisk if you must enter a value); the column headed C indicates whether the property is configurable (you can change the value when you add the message flow to the BAR file to deploy it).

The Description properties of the MQGet node are described in the following table.

Property	M	C	Default	Description
Node name	No	No	The node type, MQGet	The name of the node.
Short description	No	No	Blank	A brief description of the node.
Long description	No	No	Blank	Text that describes the purpose of the node in the message flow.

The Basic properties of the MQGet node are described in the following table.

Property	M	C	Default	Description	mqsiapplybaroverride command property
Queue name	Yes	Yes	None	The name of the WebSphere MQ message queue from which this node retrieves messages. You must predefine this queue to the queue manager that hosts the broker on which the message flow is deployed. If this queue is not a valid queue, the node generates an exception, and the input message is propagated to the Failure terminal.	queueName

The MQGet node Input Message Parsing properties are described in the following table.

If the queue message has an MQRFH2 header, you do not have to set values for the Input Message Parsing properties, because the values can be derived from the <mcd> folder in the MQRFH2 header; for example:

<mcd><Msd>MRM</Msd><Set>DHM4UO906S001</Set><Type>receiptmsg1</Type>
<Fmt>XML</Fmt></mcd>

If you set values, and the values differ from those values in the MQRFH2 header, the values in the MQRFH2 header take precedence.

Property	M	C	Default	Description
Message domain	No	No	BLOB	The domain that is used to parse the message. If the field is blank then the default is BLOB.
Message model	No	No	Cleared	The name or location of the message model schema file in which the message is defined. This list is populated with all available message model schema files for the Message domain that you have selected.
Message	No	No	Cleared	The name or location of the message root within your message model schema file. This list is populated with all available messages that are defined in the Message model that you have selected.
Physical format	No	No	Cleared	The name of the physical format of the message. If you are using the MRM or IDOC parser, select the physical format of the incoming message from the list. This list includes all the physical formats that you have defined for the selected message model. If you set the Message domain property to DataObject, you can set this property to XML or SAP ALE IDoc. Set this property to SAP ALE IDoc when you have to parse a bit stream from an external source and generate a message tree.

The Parser Options properties of the MQGet node are described in the following table.

Property	M	C	Default	Description
Parse timing	No	No	On Demand	This property controls when the queue message is parsed. Valid values are On Demand, Immediate, and Complete. By default, this property is set to On Demand, which causes parsing of the message to be delayed. To cause the message to be parsed immediately, see Parsing on demand.
Use MQRFH2C compact parser for MQRFH2 header	No	No	Cleared	This property controls whether the MQRFH2C compact parser, instead of the MQRFH2 parser, is used for MQRFH2 headers. Select Use MQRFH2C compact parser for MQRFH2 header if you want the MQRFH2C parser to be used. By default, this check box is cleared, which means that the compact parser is not used.
Build tree using XML schema data types	No	No	Cleared	This property controls whether the XMLNSC parser creates syntax elements in the message tree with data types taken from the XML schema. You can select this property only if you set the Validate property on the Validation tab to Content or Content and Value. For more information about XMLNSC, see Manipulating messages in the XMLNSC domain.
Use XMLNSC compact parser for XMLNS domain	No	No	Cleared	This property controls whether the XMLNSC Compact Parser is used for messages in the XMLNS Domain. If you set this property, the message data is displayed under XMLNSC in nodes that are connected to the output terminal when the input MQRFH2 header or Input Message Parsing properties Message domain is XMLNS.
Retain mixed content	No	No	Cleared	This property controls whether the XMLNSC parser creates elements in the message tree when it encounters mixed text in the queue message message. If you select the check box, elements are created for mixed text. If you clear the check box, mixed text is ignored and no elements are created.
Retain comments	No	No	Cleared	This property controls whether the XMLNSC parser creates elements in the message tree when it encounters comments in the queue message message. If you select the check box, elements are created for comments. If you clear the check box, comments are ignored and no elements are created.
Retain processing instructions	No	No	Cleared	This property controls whether the XMLNSC parser creates elements in the message tree when it encounters processing instructions in the queue message. If you select the check box, elements are created for processing instructions. If you clear the check box, processing instructions are ignored and no elements are created.
Opaque elements	No	No	Blank	This property is used to specify a list of elements in the queue message that are to be opaquely parsed by the XMLNSC parser. Opaque parsing is performed only if validation is not enabled (that is, if Validate is None); entries that are specified in Opaque Elements are ignored if validation is enabled.

The Advanced properties of the MQGet node are described in the following table.

Property	M	C	Default	Description
Transaction mode	No	No	Yes	This property controls whether the incoming message is received under sync point. Select a value for Transaction mode from the list to define the transactional characteristics of how this message is handled: If you select Automatic, the queue message is received under sync point if it is marked as persistent. If the message is not marked as persistent, it is not received under sync point. The persistence or non-persistence of the input message determines the transactionality of any derived messages that are later propagated by an output node, unless the output node, or any other subsequent node in the message flow, overrides the transactionality explicitly. If you select Yes, the queue message is received under sync point. Any derived messages that are later propagated by an output node in the same instance of the message flow are sent transactionally, unless the output node, or any other subsequent node in the message flow, overrides the transactionality explicitly. If you select No, the queue message is not received under sync point. Any derived messages that are later propagated by an output node in the same instance of the message flow are sent non-transactionally, unless the output node, or any other subsequent node in the message flow, has specified that the messages must be put under sync point.
Generate mode	No	No	Message	This property controls which parts of the message from the input tree are copied. Select a value for Generate mode from the list to define which components of the output message are generated in the MQGet node, and which components are taken from the input message. If you select None, all the components of the message from the input tree are propagated unchanged. If you select Message (the default), a new Message component is created by the node, but the local environment, environment, and exception list components from the input tree are propagated unchanged. If you select LocalEnvironment, a new local environment component is created by the node, but the message, environment, and exception list components from the input tree are propagated unchanged. If you select Message and LocalEnvironment, new message and local environment components are created by the node, but the environment and exception list components from the input tree are propagated unchanged.
Copy message	No	No	None	This property controls which parts of the message from the input tree are copied. If you have set Generate mode to either Message or Message And LocalEnvironment, select a value for Copy message from the list to define which parts of the message are generated in the MQGet node, and which parts are taken from the input message. If you select None (the default), no part of the input message from the input tree is propagated. If you select Copy Headers, the headers from the input message in the input tree are copied to the output message. If you select Copy Entire Message, the entire input message from the input tree is copied to the output message.
Copy local environment	No	No	Copy Entire LocalEnvironment	This property controls how the local environment is copied to the output message. If you have set Generate mode to either LocalEnvironment or Message And LocalEnvironment, select a value for Copy Local Environment from the list to define which parts of the local environment are generated in the MQGet node, and which parts are taken from the input message. If you select Copy Entire LocalEnvironment (the default), at each node in the message flow, a new copy of the local environment is created in the tree, and it is populated with the contents of the local environment from the preceding node. Therefore, if a node changes the local environment, the upstream nodes do not see those changes because they have their own copies. This behavior might be an issue if you are using a FlowOrder node, or if you use the propagate command on a Compute node. The entire local environment that is defined in the input message is copied to the output message. If you select None, each node does not generate its own copy of the local environment, but it uses the local environment that is passed to it by the previous node. Therefore, if a node changes the local environment, those changes are seen by the upstream nodes.
Wait interval (ms)	Yes	No	1000	The maximum time, in milliseconds, to wait for the queue message to be obtained from the message queue. Provide a value for the Wait interval (ms) property to specify how many milliseconds to wait for a message to be received from the MQGET call. If you select 0, the wait interval is disabled and there is no wait time for messages. The Wait interval (ms) value cannot be negative. If you do not provide a value, the default value of 1000 milliseconds is used.
Minimum message buffer size (KB)	Yes	No	4	The minimum size, in KB, of the get buffer. The minimum value of this property is 1. Provide a value for this property to specify the size of the initial buffer for the MQGET call. The buffer expands automatically to accept a message of any size, but if messages are likely to be large, specify a suitable value to reduce the frequency of the buffer being resized. If you do not provide a value, the size of the buffer is 4 KB.

The Request properties of the MQGet node are described in the following table.

Property	M	C	Default	Description
Input MQMD location	No	No	InputRoot.MQMD	The location in the input message assembly where the MQMD that is to be used for the MQGET can be found. The default location is InputRoot.MQMD.
Input MQ parameters location	No	No	InputLocalEnvironment.MQ.GET	The location in the input message assembly where the WebSphere MQ parameters (for example, the initial buffer size and the MQGMO overrides) can be found. The default location is InputLocalEnvironment.MQ.GET.
Get by correlation ID	No	No	Cleared	If you select this check box, only messages that have the specified correlation ID are retrieved. If you select Get by correlation ID, the `CorrelId` field of the message to be retrieved must match the `CorrelId` field in the Input MQMD location. By default, this check box is cleared. Setting the `CorrelId` field to MQCI_NONE has the same effect as not selecting Get by correlation ID.
Get by message ID	No	No	Cleared	If you select this check box, only messages that have the specified message ID are retrieved. If you select Get by message ID, the `MsgId` field of the message to be retrieved must match the `MsgId` field in the Input MQMD location. By default, this check box is cleared.
Use all input MQMD fields	No	No	Cleared	If you select Use all input MQMD fields, all MQMD fields at the Input MQMD location are used to retrieve the message. If an MQMD bit stream is present at the Input MQMD location, all fields in the bit stream are used. Make sure that the MQMD of the message to be retrieved matches these fields. By default, this check box is cleared. If you do not supply an input MQMD, the default MQMD is used. If you do supply an input MQMD, the default MQMD is used after the following modifications: If you set the property Use all input MQMD fields, all MQMD fields supplied are copied into the default MQMD from the input MQMD. If you do not set the property Use all input MQMD fields, and the properties Get by Message ID or Get by Correlation ID are selected, the respective IDs are copied into the default MQMD from the input MQMD. For more information about how the MQMD for the MQGET call is constructed, see A request-response scenario that uses an MQGet node.
Browse only	No	No	Cleared	This property controls whether a message is removed from the queue when it is read. If this check box is selected, the message is not removed from the queue when it is read. Select Browse only to specify that the message must be retained on the queue when it is read.
Reset browse cursor	No	No	Cleared	You can set this property only if you have selected Browse only. When you select Reset browse cursor, the node browses from the start of the MQ queue (that is, the MQGMO_BROWSE_FIRST MQ get option is specified). If you do not select this property, the node browses from the current cursor position in the MQ queue (that is, the MQGMO_BROWSE_NEXT MQ get option is specified).

The Result properties of the MQGet node are described in the following table. Set these properties to determine how the results of the MQGET call are handled.

Property	M	C	Default	Description
Output data location	No	No	OutputRoot	This property specifies where the output data is placed. If you leave the field blank, OutputRoot is used as a default. Enter the start location in the output message tree at which the parsed elements from the bit string of the queue message are stored. All elements at this location are deleted, and the default behavior is to replace the input tree message with the queue message. You can enter any valid ESQL field reference (this reference can include expressions), including new field references to create a node in the message tree for inserting the response into the message that is propagated from the input tree. For example, `OutputRoot.XMLNS.ABC.DEF` and `Environment.GotReply` are valid field references. For more detailed information, see A request-response scenario that uses an MQGet node. When the queue message bit string is parsed to create the contents of the message tree, the message properties that you have specified as the Input Message Parsing properties of the node are used.
Result data location	No	No	ResultRoot	This property specifies which subtree (of the queue message) to use. If you leave this field blank, ResultRoot is used as a default, and the whole queue message is used. If, for example, ResultRoot.MQMD.ReplyToQ is specified, only that subtree is used. Set this property to control which subtree of the queue message is placed in the output message. If, for example, you want only the MQMD from the queue message, use `ResultRoot.MQMD`; this subtree is then placed at the location specified by Output data location.
Output MQ parameters location	No	No	OutputLocalEnvironment.MQ.GET	This property specifies where the output WebSphere MQ parameters are located. If you leave this field blank, OutputLocalEnvironment.MQ.GET is used as a default. Set Generate mode to include LocalEnvironment to ensure that the updated values are visible in downstream nodes. The default location is OutputLocalEnvironment.MQ.GET. Set this property to control where the CC (completion code), the RC (reason code), the Browsed indicator, and any other WebSphere MQ parameters (for example, the MQMD that is used by the MQGET call) are placed in the output tree.
Warning data location	No	No	OutputRoot	This property specifies where the output data is placed if MQGET returns a warning code. If you leave this field blank, OutputRoot is used as a default. Set this property to control where the queue message is placed when the MQGET call returns a warning code. You can enter any valid ESQL field reference (see the description of the Output data location property). The data that is placed at this location is always the complete result tree, with the body as a BLOB element. Result data location is not used for warning data.
Include message contents in output message assembly	No	No	Selected	This property specifies that no result or warning data is required for the output message assembly. If you select this check box, the node gets or browses the message on the queue without completely reading or parsing its contents. If you select Include message contents in output message assembly, the message contents are not guaranteed to be included in the output tree because this inclusion depends on other node properties, such as the Generate mode property. Clear Include message contents in output message assembly to specify that no result or warning data is required for the output message assembly. This action gets or browses the message on the queue without reading or parsing its contents.

The Validation properties of the MQGet node are described in the following table. For a full description of these properties, see Validation properties.

Property	M	C	Default	Description	mqsiapplybaroverride command property
Validate	No	Yes	None	This property controls whether validation takes place. Valid values are None, Content, Content and Value, and Inherit.	validateMaster
Failure action	No	No	Exception	This property controls what happens if validation fails. You can set this property only if you set Validate to Content or Content and Value. Valid values are User Trace, Local Error Log, Exception, and Exception List.

The Monitoring properties of the node are described in the following table.

Property	M	C	Default	Description
Events	No	No	None	Events that you have defined for the node are displayed on this tab. By default, no monitoring events are defined on any node in a message flow. Use Add, Edit, and Delete to create, change or delete monitoring events for the node; see Configuring monitoring event sources using monitoring properties for details. You can enable and disable events that are shown here by selecting or clearing the Enabled check box.

ac20806_.htm |

Last updated Friday, 21 July 2017