This topic contains sections marked as revised for this release

WebSphere Message Brokers
File: ac20806_
Writer: Terry Cowling

Reference topic

This build: July 31, 2007 21:19:30

MQGet node

Use the MQGet node to receive messages from clients that connect to the broker using the WebSphere MQ Enterprise Transport, and that use 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's 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 within 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:
  • MRM
  • XML
  • XMLNS
  • XMLNSC
  • JMSMap
  • JMSStream
  • MIME
  • BLOB
  • IDOC

The MQGet node is represented in the workbench by the following icon:

MQGet node icon

Using the MQGet node in a message flow

Look at the following topics to see how to use the MQGet node in a message flow:

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. To display its properties, either double-click the node, or right-click the node and click Properties.

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

Configure the MQGet node.

  1. Optional: On the Description tab, enter a short description, a long description, or both. You can also rename the node on this tab.
  2. On the Basic tab, enter in Queue Name the name of the queue from which the message is to be obtained. You must predefine this WebSphere MQ 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.
  3. On the Input Message Parsing tab, set values for the properties that describe the message domain, message set, message type, and message format that the node uses to determine how to parse the queue message, and the default topic that is associated with the message.
    • If the queue message has an MQRFH2 header, you do not need 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 those values differ from those in the MQRFH2 header, the values in the MQRFH2 header take precedence.

    • In Message Domain, select the name of the parser that you are using from the drop-down list. You can choose from the following names:
      • MRM
      • XML
      • XMLNS
      • XMLNSC
      • JMSMap
      • JMSStream
      • MIME
      • BLOB
      • IDOC
    • If you are using the MRM or IDOC parser, select the correct message set from the drop-down list in Message Set.

      Leave Message Set blank for XML, XMLNS, XMLNSC, JMS, MIME, and BLOB parsers.

    • If you are using the MRM parser, select the correct message from the drop-down list in Message Type. This list is populated with messages that are defined in the message set that you have selected.

      Leave Message Type blank for XML, XMLNS, XMLNSC, JMS, IDOC, MIME, and BLOB parsers.

    • If you are using the MRM or IDOC parser, select the format of the message from the drop-down list in Message Format. This list includes all the physical formats that you have defined for this message set.

      Leave Message Format blank for XML, XMLNS, XMLNSC, JMS, MIME, and BLOB parsers.

  4. On the Parser Options tab:
    1. Parse Timing is, by default, set to On Demand, which causes validation to be delayed until the message is parsed by partial parsing.

      If you change this value to Immediate, partial parsing is overridden and everything in the message is parsed and validated, except those complex types with a composition of Choice or Message that cannot be resolved at the time. If you change this value to Complete, partial parsing is overridden and everything in the message is parsed and validated; complex types with a composition of Choice or Message that cannot be resolved at the time cause a validation failure.

      For more details, refer to Validation properties.

    2. Select Use MQRFH2C Compact Parser 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.
    3. Set values for the properties that determine how the request parameters are constructed. For more information, refer to Manipulating messages using the XMLNSC parser.
  5. On the Advanced tab, set values for the advanced properties.
    • Select a value for Transaction Mode from the drop-down list to define the transactional characteristics of how this message is handled:
      • If you select Automatic, the queue message is received under syncpoint if it is marked as persistent. If the message is not marked as persistent, it is not received under syncpoint. The persistence or non-persistence of the input message determines the transactionality of any derived messages that are subsequently 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 syncpoint. Any derived messages that are subsequently 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 syncpoint. Any derived messages that are subsequently 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 syncpoint.
    • Select a value for Generate Mode from the drop-down list to define which components of the output message are generated within the MQGet node, and which components are taken from the input message.
      • If you select None, all 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 LocalEnvironment, Environment, and ExceptionList components from the input tree are propagated unchanged.
      • If you select LocalEnvironment, a new LocalEnvironment component is created by the node, but the Message, Environment, and ExceptionList components from the input tree are propagated unchanged.
      • If you select Message and LocalEnvironment, new Message and LocalEnvironment components are created by the node, but the Environment and ExceptionList components from the input tree are propagated unchanged.
    • If you have chosen Generate Mode to be either Message or Message and LocalEnvironment, select a value for Copy Message from the drop-down list to define which parts of the message are generated within 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.
    • If you have chosen Generate Mode to be either LocalEnvironment or Message and LocalEnvironment, select a value for Copy Local Environment from the drop-down list to define which parts of the local environment are generated within the MQGet node, and which parts are taken from the input message.
      • If you select None, no part of the local environment is copied to the output message.
      • If you select Copy Entire LocalEnvironment (the default), the entire local environment that is defined in the input message is copied to the output message.
    • Provide a value for the Wait interval property to specify how many milliseconds to wait for a message to be received from the MQGET call. If you do not provide a value, the default value of 1000 milliseconds is used.
    • Provide a value for the Minimum message buffer size property to specify the size, in KB, of the initial buffer for the MQGET call. The buffer expands automatically to accept a message of any size, but if it is expected that messages will all be large, specify a suitable value to reduce the frequency of the buffer being re-sized. If you do not provide a value, the size of the buffer is 4 KB.
  6. On the Request tab, set values for the properties that determine how the request parameters are constructed.
    • If the MQMD that is to be used for the MQGET call is not the default location InputRoot.MQMD, specify in Input MQMD Location the location of the MQMD.
    • If the location of the parameters for the MQGET call (for example, MQGMO overrides), is not the default location InputLocalEnvironment.MQ.GET, specify the location in Input MQ Parameters Location.
    • 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.
    • 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.
    • If you select Use complete input MQMD, the entire MQMD of the message to be retrieved must match the value of the Input MQMD Location on a bit-for-bit basis. By default, this check box is cleared.
    • Start of changeSelect Browse Only to specify that the message should be retained on the queue when it is read.End of change
  7. On the Result tab, set values for the properties that determine how the results of the MQGET call are handled.
    • In Output Data Location, enter the start location within the output message tree at which the parsed elements from the bit string of the queue message are stored; the default value is OutputRoot. 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 new node within 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. See A request-response scenario using an MQGet node for more detailed information.

      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.

    • Set a value in Result Data Location to control which subtree of the queue message is placed in the output message. The default value is ResultRoot, which means that the whole 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.
    • Set a value in Output MQ Parameters Location to control where the CC (completion code), the RC (return code), and any other MQ parameters (for example the MQMD used by the MQGET call) are placed in the output tree. The default value is OutputLocalEnvironment.MQ.GET.
    • Set a value in Warning Data Location to control where the queue message is placed when the MQGET call returns a warning code. The default value is OutputRoot.

      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.

    • Start of changeClear the Include Message Contents in Output Message Assembly check box 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.

      If you select Include Message Contents in Output Message Assembly, it does not guarantee that the message contents are included in the output tree because the property depends on other node properties, such as the Generate Mode property.

      End of change
  8. On the Validation tab, set the validation properties if you want the MRM parser to validate the body of each queue message against the dictionary that is generated from the message set. (If a message is propagated to the Failure terminal of the node, it is not validated.)

    For more details, refer to Validating messages and Validation properties.

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

See Connecting failure terminals for more information.

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 syncpoint.
  • If you set the property to Yes (the default), the queue message is received under syncpoint (that is, within a WebSphere MQ unit of work). Any messages that an output node in the same instance of the message flow sends subsequently are put under syncpoint, 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 syncpoint if the incoming message is marked as persistent. Otherwise, it is not. Any message that is sent subsequently by an output node is put under syncpoint, 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 syncpoint. Any messages that are sent subsequently by an output node in the message flow are not put under syncpoint, unless an individual output node, or any other subsequent node, specifies that the message must be put under syncpoint.

Start of changeIf 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 syncpoint. However, any derived messages that are propagated subsequently by an output node in the same instance of the message flow follow the behavior that is described above in accordance with the specified Transaction Mode value.End of change

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 within 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 within 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
Queue Name Yes Yes None The name of the WebSphere MQ message queue from which this node retrieves messages.

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

Property M C Default Description
Message Domain No No None The domain that is used to parse the queue message.
Message Set No No None The name or identifier of the message set in which the queue message is defined.
Message Type No No None The name of the queue message.
Message Format No No None The name of the physical format of the queue message.

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

Property M C Default Description
Parse Timing No No On Demand This property controls when an input message is parsed. Valid values are On Demand, Immediate, and Complete.

For a full description of this property, refer to 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.
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 appears under XMLNSC in nodes that are connected to the output terminal when the input RFH2 header or Input Message Parsing properties 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 an input 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 an input 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 an input 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.

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 syncpoint. Valid values are Automatic, Yes, and No.
Generate Mode No No Message This property controls which parts of the message from the input tree are copied. Valid values are Message, LocalEnvironment, Message And LocalEnvironment, and None.
Copy Message No No None This property controls which parts of the message from the input tree are copied. Valid values are None, Copy Headers, and Copy Entire Message.
Copy Local Environment No No   This property controls which parts of the local environment are copied to the output message. Valid values are None, and Copy Entire LocalEnvironment. The default value is Copy Entire LocalEnvironment.
Wait interval (ms) Yes No 1000 The maximum time, in milliseconds, to wait for the queue message to be obtained from the message queue.
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 KB.

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

Property M C Default Description
Input MQMD Location No No   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   The location in the input message assembly where the 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.
Get by Message ID No No Cleared If you select this check box, only messages that have the specified message ID are retrieved.
Use complete input MQMD No No Cleared If you select this check box, the complete MQMD is used; otherwise, only the message ID and correlation ID are used.
Start of changeBrowse OnlyEnd of change Start of changeNoEnd of change Start of changeNoEnd of change Start of changeClearedEnd of change Start of changeThis 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.End of change

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

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.
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.
Output MQ Parameters Location No No   This property specifies where the output 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.
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.
Start of changeInclude Message Contents in Output Message AssemblyEnd of change Start of changeNoEnd of change Start of changeNoEnd of change Start of changeSelectedEnd of change Start of changeThis 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 the Include Message Contents in Output Message Assembly check box, it does not guarantee that the message contents are included in the output tree because the property depends on other node properties, such as the Generate Mode property.

End of change

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

Refer to Validation properties for a full description of these properties.
Property M C Default Description
Validate No Yes None This property controls whether validation takes place. Valid values are None, Content, Content and Value, and Inherit.
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.
Include All Value Constraints No No True You cannot edit this property. Basic value constraint checks are included in Content and Value validation.
Fix No No None You cannot edit this property.
Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2007Copyright IBM Corporation 1999, 2007. All Rights Reserved.
This build: July 31, 2007 21:19:30

ac20806_ This topic's URL is: