MQInput node

Use the MQInput node to receive messages from clients that connect to the integration node by using the WebSphere® MQ Enterprise Transport.

The MQInput node is available in the following operation modes:

Developer
Application Integration Suite
Standard
Advanced
Express
Scale
Adapter

For more information, see Operation modes.

WebSphere MQ is available as a separate installation package, and your IBM® Integration Bus license entitles you to install and use WebSphere MQ with IBM Integration Bus. For more information, see Enhanced flexibility in interactions with WebSphere MQ and Installing WebSphere MQ.

This topic contains the following sections:

Purpose

The MQInput node receives messages from a specified queue through a local or client connection to a queue manager.

On distributed systems, you can configure the MQInput node to get messages from a WebSphere MQ queue on any local or remote queue manager, by either setting the MQ Connection properties, or specifying an MQEndpoint policy on the Policy tab.

If the integration node has a queue manager associated with it, then the MQ message flow node by default connects to that queue manager with server bindings. If you configure properties on the MQ Connection tab, then these properties will be used to connect to the specified queue manager. If you specify a MQEndpoint policy, then the values in the policy will be used instead of the values defined in the MQ Connection tab.

On z/OS®, only local connections to queue managers are supported. You must have a queue manager specified for the integration node, but you can also connect to other local queue managers on an MQInput node by using server bindings for the connection.

You can connect to a secured local or remote queue manager by using the Security identity property on the MQInput node to pass a user name and password to the queue manager. The identity is defined using the mqsisetdbparms command. You can use the Security identity property to provide the security credentials on local and client connections, but it is not available for client connections that use a client channel definition table (CCDT). You can also choose whether to use the SSL protocol when a client connection is made to a remote queue manager. Select the Use SSL property on the MQInput node to provide confidentiality on the client connection by using SSL. You can also set these properties through an MQEndpoint policy. For more information about using security identities and SSL, see Connecting to a secured WebSphere MQ queue manager.

Message flows that handle messages that are received across WebSphere MQ connections must always start with an MQInput node. You can set the properties of the node to control the way in which messages are received; for example, you can request that a message is to be processed under transaction control. You can also request that data conversion is performed on receipt of every input message.

For information about how to configure the MQInput node for transactions, see Configuring MQ nodes for transactions.

You can define the input queue as a WebSphere MQ clustered queue or shared queue.

The MQInput node handles messages in the following message domains:

DFDL
XMLNSC
DataObject
JSON
BLOB
MIME
MRM
JMSMap
JMSStream
XMLNS

If you include an output node in a message flow that starts with an MQInput node, the output node can be any one of the supported output nodes, including user-defined output nodes; you do not have to include an MQOutput node. You can create a message flow that receives messages from WebSphere MQ clients and generates messages for clients that use any of the supported transports to connect to the integration node, because you can configure the message flow to request that the integration node provides any conversion that is necessary.

The MQInput 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 MQInput node in a message flow

For an example of how to use this node, assume that you have written a publishing application that publishes stock updates on a regular basis. The application sends the messages to the integration node on an MQInput node, and the message flow makes the publications available to multiple subscribers through a Publication node. You configure a Compute node to create a new output message whenever one particular stock is changed, and connect this node to an MQOutput node to record each price change for this stock.

Connecting the terminals

The MQInput node routes each message that it retrieves successfully to the Out terminal. If the message is not retrieved successfully, the message is tried again until it succeeds or until the backout threshold is reached. If the backout count is exceeded (as defined by the BackoutThreshold attribute of the input queue), the message is routed to the Failure terminal; you can connect nodes to this terminal to handle this condition. If you have not connected the Failure terminal, the message is written to the backout queue, if it has been defined, and if no backout queue has been defined, the message is written to the dead-letter queue (DLQ). If neither a backout queue nor DLQ has been defined, the message continues to loop through the node until the problem has been resolved, so it is good practice to ensure that at least one of these queues has been defined. The most likely cause of this type of failure is that the incoming message has an incorrect format and validation is enabled.

If the message is caught by this node after an exception has been thrown further on in the message flow, the message is routed to the Catch terminal, if it has been defined. If the Catch terminal has not been defined and the flow is transactional, the message is rolled back to the input queue and the message processing is retried until it succeeds or until the backout threshold is reached. If the backout count is exceeded, the message is routed to the Failure terminal. If the Failure terminal has not been connected, the message is written to the backout queue, and if no backout queue has been defined, the message is written to the dead-letter queue (DLQ). If neither a backout queue nor DLQ has been defined, the message continues to loop through the node until the problem has been resolved. If the Catch terminal has not been defined and the flow is not transactional, the message is discarded.

To learn more about specific error-handling logic for the MQInput node, see Handling MQInput node errors.

MQGET buffer size

The MQGET buffer size is implemented internally by the integration node and you cannot change it. The following description is provided for information only. You must not rely on it when you develop your message flows, because the internal implementation might change.

When the MQInput node initializes, it sets the size of the default buffer for the first MQGET to 4 KB. The MQInput node monitors the size of messages and increases or reduces the size of the buffer:

If an MQGET fails because the message is larger than the size of the buffer, the node immediately increases the size of the buffer to accommodate the message, issues the MQGET again, and zeros a message count.
When 10 messages have been counted since the increase in the size of the buffer, the node compares the size of the largest of the 10 messages with the size of the buffer. If the size of the largest message is less than 75% of the size of the buffer, the buffer is reduced to the size of the largest of the 10 messages. If an MQGET fails during the 10 messages because the message is larger than the size of the buffer, the node takes action 1.

For example, if the first message that the node receives is 20 MB, and the next 10 messages are each 14 MB, the size of the buffer is increased from 4 KB to 20 MB and remains at 20 MB for 10 messages. However, after the 10th message the size of the buffer is reduced to 14 MB.

Terminals and properties

When you add an MQInput node to a message flow, you can use the Properties view in the Message Flow editor to configure it. To display field help, click within a field, and then click the information icon that is displayed at the beginning of the field. All mandatory properties that do not have a default value defined are marked with an asterisk. For general configuration information see Configuring a message flow node. You can also use an MQ Service to configure the MQInput node, but this is supported only if a queue manager has been specified on the integration node. See Configuring an MQ node by using an MQ Service.

You can create and attach operational policies to control particular connection properties for this type of node at run time. For more information about policy, see Operational policy properties.

The following tables describe the node terminals and the node properties that you can set on a specified tab in the Properties view in the Message Flow editor. The column headed M indicates whether the property is mandatory (marked with an asterisk if you must enter a value when no default is defined).

Table of node terminals

Table 1. The terminals of the MQInput node
Terminal	Description
Failure	The output terminal to which the message is routed if an error occurs. Even if the Validation property is set, messages propagated to this terminal are not validated. Received messages are also routed to this terminal if they have previously been backed out a number of times that exceeds the defined backout threshold.
Out	The output terminal to which the message is routed if it is successfully retrieved from the WebSphere MQ queue.
Catch	The output terminal to which the message is routed if an exception is thrown downstream and caught by this node.

Tables of node properties

Table 2. The Description properties of the node
Property	M	Default	Description
Node name	No	The node type, MQInput	The name of the node.
Short description	No		A brief description of the node.
Long description	No		Text that describes the purpose of the node in the message flow.

Table 3. The Basic properties of the node
Property	M	Default	Description
Queue name	Yes		The name of the WebSphere MQ input queue from which this node retrieves messages (using MQGET) for processing by this message flow. You must predefine this WebSphere MQ queue to the queue manager that hosts the integration node to which the message flow is deployed.

Table 4. The MQ Connection properties of the node
Property	M	Default	Description
Connection	No	Local queue manager	This property specifies how a connection is made to WebSphere MQ: Select Local queue manager to make a local connection to a specified queue manager. If this option is selected, specify a queue manager in the Destination queue manager name property. If this property is set without a Destination queue manager name value, and no MQEndpoint policy is specified on the Policy tab, the MQ node uses the connection details of the queue manager specified for the integration node at run time. If no queue manager was specified for the integration node, then the message flow will not deploy. Select MQ client connection properties to make a client connection to a remote queue manager by specifying the client connection details. If this option is selected, the following properties must also be specified: Queue manager host name Listener port number Channel name Destination queue manager name Select Client channel definition table (CCDT) file to use client connection details that are specified in a client channel definition table (CCDT) file. If this option is selected, you must also specify the queue manager name. Specify the location of the CCDT file by running the mqsichangeproperties command, using the integration node registry object property mqCCDT. For example, enter the following command on one line: `mqsichangeproperties IBNODE -o BrokerRegistry -n mqCCDT -v "C:\Program Files (x86)\IBM\WebSphere MQ\Qmgrs\QM1\@ipcc\AMQCLCHL.TAB"` For more information, see Integration node registry object parameter values. If you select Connect with CCDT and mqCCDT is not set, then a run time error occurs when IBM Integration Bus attempts to connect to the specified queue manager. The mqCCDT property applies to a specific integration node, so if you want to connect to different queue managers using CCDT, then you must define separate client connection channels in the CCDT file for each queue manager. Valid values for mqsiapplybaroverride are SERVER, CLIENT, and CCDT.
Destination queue manager name	No		This property specifies the name of the queue manager on which the message queues are defined.
Queue manager host name	No		This property specifies the host name of the queue manager. To achieve high availability, you can specify more than one host name by separating each host name with a comma. The first host name in the list is used as the primary host name. If the connection to the host name becomes unavailable, the next host name is used, and so on. For more information about high availability in WebSphere MQ, see the WebSphere MQ Version 7.5 product documentation online.
Listener port number	No		This property specifies the port on which the queue manager is listening.
Channel name	No		This property specifies the name of the channel used by the queue manager to send messages.
Security identity	No		This property specifies an identity that is used to provide user name and password credentials for connections to a secured local or remote queue manager. It can be used to provide credentials on local and client connections, but it is not available for client connections that are configured using a client channel definition table (CCDT). The identity is defined using the mqsisetdbparms command. When you set the security identity by using this command, ensure that it is prefixed by `mq::`. Do not include the prefix when setting the security identity on the node or in the MQEndpoint policy. For more information, see Connecting to a secured WebSphere MQ queue manager.
Use SSL	No	No	This property controls whether the SSL protocol is used when a client connection is made to a remote queue manager. Select this property to provide confidentiality on the client connection by using SSL. You can also set this property through an MQEndpoint policy. You can use SSL for client connections that are configured using either the MQ client connection properties or a client channel definition table (CCDT). If you select Use SSL and specify the connection details through MQ client connection properties, you can also set the following properties: SSL peer name SSL cipher specification The SSL peer name and SSL cipher specification properties are not used for client connections that use a client channel definition table (CCDT); you can specify this information in the CCDT. If you select the Use SSL property, you must also specify the location of the SSL key repository. The SSL key repository is created using the WebSphere MQ GSkit, and it holds the required private and public certificates appropriate to the chosen certificate policy for the queue manager. You specify the key repository location by using the mqsichangeproperties command; it is specified as the SSL key repository full file path minus the .kdb file extension. For example, if the SSL key repository is located in C:\SSL\key.kdb, you set it by using the following command : `mqsichangeproperties IB10NODE -o BrokerRegistry -n mqKeyRepository -v C:\SSL\key` The SSL key repository password stash file `key repository file name`.sth must be located in same folder location as the key repository. The stash file is created using WebSphere MQ GSKit. Use the MQSC REFRESH SECURITY command to pick up the changes to the SSL key repository. For more information, see Connecting to a secured WebSphere MQ queue manager.
SSL peer name	No		This property specifies the name that is passed to the remote queue manager when making the client connection. The value specified by this property must match the value specified in the SSLCIPH property in the remote channel definition. You can specify this property if the Use SSL property is selected and the client connection details are specified through MQ client connection properties. It is not used for client connections that use a client channel definition table (CCDT); you can specify this information in the CCDT.
SSL cipher specification	No		This property specifies the name of the symmetric key cryptography algorithm through which the remote queue manager is secured. You can specify this property if the Use SSL property is selected and the client connection details are specified through MQ client connection properties. It is not used for client connections that use a client channel definition table (CCDT); you can specify this information in the CCDT.

Configure the connection details to enable a message to be retrieved from a queue on a local or remote queue manager. Values that are set on the MQ Connection tab are used at run time, unless overridden by a value in an MQEndpoint policy that is specified on the Policy tab.

Table 5. The Input Message Parsing properties of the node
Property	M	Default	Description
Message domain	No	BLOB	The domain that is used to parse the message. If the field is blank then the default is BLOB.
Message model	No	Cleared	The name or location of the message model schema file in which the message is defined. When you click Browse, you see a list of available message model schema files for the selected Message domain.
Message	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	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.

If the incoming message has an MQRFH2 header, you do not have to set values for the Input Message Parsing properties because the values are 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 the values in the MQRFH2 header, and the <Msd> element is a valid domain, the values in the MQRFH2 header take precedence.

Table 6. The Parser Options properties of the node
Property	M	Default	Description
Parse timing	No	On Demand	This property controls when an input message is parsed. Valid values are On Demand, Immediate, and Complete. Parse timing is, by default, 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	Cleared	This property controls whether the MQRFH2C compact parser, instead of the MQRFH2 parser, is used for MQRFH2 headers.
Build tree using XML schema data types	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.
Use XMLNSC compact parser for XMLNS domain	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 the Input Message Parsing property Message domain is XMLNS. For more information, see Manipulating messages in the XMLNSC domain.
Retain mixed content	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	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	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.
Opaque elements	No	Blank	This property is used to specify a list of elements in the input 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.

Table 7. The Advanced properties of the node
Property	M	Default	Description
Transaction mode	Yes	Yes	This property controls whether the incoming message is received under sync point. Valid values are Automatic, Yes, and No. If you select Automatic, the incoming message is received under sync point if it is marked persistent, otherwise it is not received under sync point. The transactionality of any derived messages that are sent later by an output node is determined by the incoming persistence property, unless the output node has overridden transactionality explicitly. If you select Yes, the incoming message is received under sync point. Any derived messages that are sent later by an output node in the same instance of the message flow are sent transactionally, unless the output node has overridden transactionality explicitly. If you select No, the incoming message is not received under sync point. Any derived messages that are sent later by an output node in the message flow are sent non-transactionally, unless the output node has specified that the messages must be put under sync point. For more information, see Configuring MQ nodes for transactions.
Order mode	Yes	Default	The order in which messages are retrieved from the input queue and processed. Messages arriving can be processed in order, or any thread can process any message when it is ready. When ordering is imposed, a thread processes a message only if it is the first unprocessed message available with a unique ordering value. Valid values are Default, By User ID, By Queue Order, and User Defined. This property has an effect only if the message flow property Additional instances on the Instances tab, is set to greater than zero; that is, if multiple threads read the input queue. Valid values are: Default. Messages are retrieved in the order that is defined by the queue attributes, but this order is not guaranteed because the messages are processed by the message flow. By User ID. Messages that have the same UserIdentifier value in the MQMD are retrieved and processed in the order that is defined by the queue attributes; this order is guaranteed to be preserved when the messages are processed. A message that is associated with a particular user identifier that is being processed by one thread, is completely processed before the same thread, or another thread, can start to process another message with the same user identifier. Ensure that each message has a unique message ID in the MQMD of the incoming message. No other ordering is guaranteed to be preserved. By Queue Order. Messages are retrieved and processed by this node in the order that is defined by the queue attributes; this order is guaranteed to be preserved when the messages are processed. This behavior is identical to the behavior that is exhibited if the message flow property Additional instances is set to zero. However, if you set Order mode to By Queue Order then redeploy the message flow, additional instances that are already running are not released. Therefore, when you set Order mode to By Queue Order, either stop and restart the message flow, or run the mqsireload command for the integration server after you redeploy the flow. User Defined. You can specify a message element using the Order field location property. For more details about using this option, see Optimizing message flow throughput and Receiving messages in a WebSphere MQ message group.
Order field location	N	""	An XPath or ESQL expression property to control which part of the message is used to impose ordering on incoming messages when Order mode is User Defined. If the field is missing, an exception is raised, and the message is rolled back. NULL and empty values are processed separately, in parallel.
Logical order	Yes	Selected	If you select this check box, messages are received in logical order, as defined by WebSphere MQ. This option maps to the MQGMO_LOGICAL_ORDER option of the MQGMO of the MQI. If you clear the check box, messages that are sent as part of a group are not received in a predetermined order. If an integration node expects to receive messages in groups, and you have not selected this check box, either the order of the input messages is not significant, or you must design the message flow to process them appropriately. You must also select Commit by message group if you want message processing to be committed only after the final message of a group has been received and processed. More information about the options to which this property maps is available in the Application Programming Reference section of the WebSphere MQ Version 7.5 product documentation online. For more details about using this option, see Receiving messages in a WebSphere MQ message group.
All messages available	Yes	Cleared	Select All messages available if you want message retrieval and processing to be done only when all messages in a single group are available. This property maps to the MQGMO_ALL_MSGS_AVAILABLE option of the MQGMO of the MQI. Clear this check box if message retrieval does not depend on all of the messages in a group being available before processing starts. More information about the options to which this property maps is available in the Application Programming Reference section of the WebSphere MQ Version 7.5 product documentation online.
Match message ID	No		A message ID that must match the message ID in the MQMD of the incoming message. Enter a message identifier if you want the input node to receive only messages that contain a matching message identifier value in the MsgId field of the MQMD. Enter an even number of hexadecimal digits (characters `0 to 9`, `A to F`, and `a to f` are valid) up to a maximum of 48 digits. If the matching message identifier that you enter is shorter than the size of the MsgId field, Match message ID is padded on the right with `X'00'` characters. This property maps to the MQMO_MATCH_MSG_ID option of the MQGMO of the MQI. Leave this property blank if you do not want the input node to check that the message ID matches. More information about the options to which this property maps is available in the Application Programming Reference section of the WebSphere MQ Version 7.5 product documentation online.
Match correlation ID	No		A correlation ID that must match the correlation ID in the MQMD of the incoming message. Enter a message identifier if you want the input node to receive only messages that contain a matching correlation identifier value in the CorrelId field of the MQMD. Enter an even number of hexadecimal digits (characters `0 to 9`, `A to F`, and `a to f` are valid) up to a maximum of 48 digits. If the ID that you enter is shorter than the size of the CorrelId field, it is padded on the right with `X'00'` characters. This property maps to the MQMO_MATCH_CORREL_ID option of the MQGMO of the MQI. Leave this property blank if you do not want the input node to check that the CorrelID matches. More information about the options to which this property maps is available in the Application Programming Reference section of the WebSphere MQ Version 7.5 product documentation online.
Convert	Yes	Cleared	If you select this check box, WebSphere MQ converts data in the message to be received, in conformance with the CodedCharSetId and Encoding values set in the MQMD. Select Convert if you want WebSphere MQ to perform data conversion on the message when it is retrieved from the queue. This option is useful if you are handling messages in the BLOB domain, or are using a user-defined parser. Do not select this option if you are parsing messages with the XML or MRM domains, because the parser does the conversion. WebSphere MQ converts the incoming message to the encoding and coded character set that is specified in the MQMD that the input node supplies on the MQGET call to retrieve the message from the input queue. The integration node uses the MQGMO_CONVERT option on the MQGET call; typical rules for WebSphere MQ conversion apply. The values that you specify in the Convert encoding and Convert coded character set ID options are used in the MsgDesc Encoding and CCSID fields in the MQGET call. WebSphere MQ can convert the incoming message only if the MQMD Format field is a built-in WebSphere MQ value that identifies character data, or if a data conversion exit exists in WebSphere MQ. This property maps to the MQGMO_CONVERT option of the MQGMO of the MQI. Clear the check box if you do not want WebSphere MQ to convert the message. If you select this check box, you can also specify values for the Convert encoding and Convert coded character set ID properties. For more information about WebSphere MQ data conversion, and why you might choose to use this option, see the Application Programming Guide section of the WebSphere MQ Version 7.5 product documentation online.
Convert encoding	No		The representation used for numeric values in the message data, expressed as an integer value. This property is valid only if you have selected Convert. Enter the number that represents the encoding to which you want to convert numeric data in the message body. Valid values include: 546 for DOS, all Windows systems, and Linux® on x86 273 for Linux on Linux on POWER®, Linux on Z, and all UNIX systems 785 for z/OS messages that use Binary Packed Decimals, and 273 for messages that use IEEE floating point numbers The encoding is used only in the following circumstances: If a user-defined WebSphere MQ data conversion exit uses the encoding. If the built-in WebSphere MQ conversion exit uses the encoding to convert messages in any of the predefined WebSphere MQ formats. If you specify an incorrect value, no conversion is done. For further information about the values that you can specify for Convert encoding, see Data conversion and the Application Programming Reference section of the WebSphere MQ Version 7.5 product documentation online.
Convert coded character set ID	No		The coded character set identifier of character data in the message data, expressed as an integer value. This property is valid only if you have selected Convert. Enter the value that represents the character set identifier to which you want to convert character data in the message body. If you specify an incorrect value, no conversion is done. For further information about the values that you can specify for Convert coded character set ID, see the Application Programming Reference section of the WebSphere MQ Version 7.5 product documentation online.
Commit by message group	Yes	Cleared	This property controls when a transaction is committed when processing messages that are part of a message group. If you select the check box, the transaction is committed when the message group has been processed. If you leave this check box cleared, a commit is performed after each message has been propagated completely through the message flow. This property is relevant only if you have selected Logical order. Set the Order mode property to By Queue Order if the messages in a group must be retrieved and processed in the order in which they are displayed on the queue.
z/OS serialization token	No		On z/OS only: A user-defined token for serialized application support. The value that is specified must conform to the rules for a valid ConnTag in the WebSphere MQ MQCNO structure. Enter a serialization token if you want to use the serialized access to shared resources that is provided by WebSphere MQ. The value that you provide for the serialization token must conform to the rules described in the Application Programming Reference section of the WebSphere MQ Version 7.5 product documentation online. For more information about serialization and queue sharing on z/OS, see the Concepts and Planning Guide section of the WebSphere MQ Version 7.5 product documentation online.
Topic	No		The default topic for the input message. You can associate a message with a publish/subscribe topic by using this property. You can enter any characters as the topic name. When messages pass through the MQInput node, they take on whatever topic name you have entered. (If you are using publish/subscribe, you can subscribe to a topic and see any messages that passed through the MQInput node and were published under that topic name.) If the incoming message has an MQRFH2 header, you do not have to set a value for the Topic property because the value can be obtained from the `<psc>` folder in the MQRFH2 header; for example: `<psc><Topic>stockquote</Topic></psc>` If you set a Topic property value, and that value differs from the <Topic> value in the MQRFH2 header, the value in the MQRFH2 header takes precedence.
Browse Only	No	Cleared	This property controls whether a message is removed from the queue when it is read. If you select this check box, the message is not removed from the queue when it is read. If you select this option, OutputLocalEnvironment.MQ.GET.Browsed is set to true when a message is propagated to the output terminal of the MQInput node.
Reset browse timeout (ms)	Yes	-1	The time, in milliseconds, between the last eligible message being browsed on the input queue and the browse being reset to the beginning of the queue. The default value of -1 indicates that the browse is not reset.

Set the Advanced node properties to determine how the message is processed, such as its transactional characteristics. Many of these properties map to options on the MQGET call.

Table 8. The Validation properties of the node
Property	M	Default	Description
Validate	No	None	This property controls whether validation takes place. Valid values are None, Content, and Content and Value.
Failure action	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.

Set these properties if you want the parser to validate the body of messages against the Message set. (If a message is propagated to the Failure terminal of the node, it is not validated.) For more details, see Validating messages and Validation properties.

Table 9. The Security properties of the node
Property	M	Default	Description
Identity token type	No	None	This property specifies the type of identity token present in the incoming message. Valid values are: Transport Default Username Username + Password SAML Assertion X.509 Certificate If this property is not specified, the identity is retrieved from the transport headers and the type is set to Username.
Identity token location	No	None	This property specifies where, in the message, the identity can be found. The location is specified as an ESQL field reference, an XPath expression, or a string literal. If you use a string literal, it must be enclosed in single quotation marks and must not contain a period (.), If this property is not specified, the identity is retrieved from the MQMD.UserIdentifier transport header.
Identity password location	No	None	This property specifies where, in the message, the password can be found. The location is specified as an ESQL field reference, an XPath expression, or a string literal. If you use a string literal, it must be enclosed in single quotation marks and must not contain a period (.), If it is not specified, the password is not set. This property can be set only if Identity token type is set to Username + Password.
Identity IssuedBy location	No	None	This property specifies a string or path expression that describes the issuer of the identity. The location is specified as an ESQL field reference, an XPath expression, or a string literal. If you use a string literal, it must be enclosed in single quotation marks and must not contain a period (.), The value specifies the Issuer that is passed to a WS-Trust v1.3 STS provider. If this property is not specified, the MQMD.PutApplName value is used. If you leave the Identity issuedBy location field blank and the MQMD.PutApplName is also blank, the string `MQ` is used.
Treat security exceptions as normal exceptions	No	False	This property specifies whether to treat security exceptions (such as "Access Denied") as normal exceptions, and propagate them to the Failure terminal (if wired). This property is turned off by default, which ensures that security exceptions cause the message to be backed out even if the Failure terminal is wired.

Set values for the Security properties to control the extraction of an identity from a message (when a security profile is associated with the node). For more information about these properties, see Identity, Configuring the extraction of an identity or security token, Message flow security overview, and Setting up message flow security.

Table 10. The Instances properties of the node
Property	M	Default	Description
Additional instances pool	No	Use Pool Associated with Message Flow	The pool from which additional instances are obtained. If you select Use Pool Associated with Message Flow, additional instances are obtained from the message flow value. If you select Use Pool Associated with Node, additional instances are allocated from the additional instances of the node, based on the number specified in the Additional instances property.
Additional instances	No	0	The number of additional instances that the node can start if the Additional instances pool property is set to Use Pool Associated with Node. By default, no additional instances are given to the node.

Set values for the Instances properties to control the additional instances that are available for a node. For a full description of these properties, see Configurable properties in a BAR file.

Table 11. The Policy properties of the node
Property	M	Default	Description
Policy URL	No		Set the value of this field to the location of an MQEndpoint policy to use the connection details defined in that policy for this MQ node. If an MQEndpoint policy is specified, the property values that are set in the policy are used at run time. The properties that are set in the policy override the corresponding properties that are set on the MQ Connection tab. If an MQEndpoint policy is not specified, then property values that are set on the MQ Connection tab are used. If no MQEndpoint policy is specified, and the Connection property on the MQ Connection tab is set to Local queue manager with no queue manager specified (the default state), then the MQ node uses the connection details for the queue manager that was specified for the integration node. If no queue manager was specified for the integration node, then the message flow will not deploy.

If an MQEndpoint policy is specified, then any equivalent properties that are set on the MQ Connection tab are ignored at run time. For more information about operational policies that can be applied to MQ nodes, see MQEndpoint policy.

Table 12. The Monitoring properties of the node
Property	M	Default	Description
Events	No		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 by using monitoring properties for details. You can enable and disable events that are shown here by selecting or clearing the Enabled check box.

Configurable properties

The following table describes the node properties that are configurable (you can change the property value when you add the message flow to the BAR file for deployment by using the mqsiapplybaroverride command). The table maps the message flow node properties to the corresponding properties of the mqsiapplybaroverride command.

For more information about configurable properties, see Configurable properties in a BAR file.

Table of configurable properties

Table 13. List of node properties that can be configured using the mqsiapplybaroverride command
Property	mqsiapplybaroverride command property
Queue name	queueName
Connection	connection
Destination queue manager name	destinationQueueManagerName
Queue manager host name	queueManagerHostname
Listener port number	listenerPortNumber
Channel name	channelName
Security identity	securityIdentity
Use SSL	useSSL
SSL peer name	SSLPeerName
SSL cipher specification	SSLCipherSpec
Serialization token	serializationToken
Topic property	topicProperty
Validate	validateMaster
Component level	componentLevel
Additional instances	additionalInstances
Policy URL	policyUrl

Operational policy properties

You can create and attach MQEndpoint policies to MQ nodes to control the behavior of the node at run time. The following table maps the operational properties of the message flow node to the corresponding properties of the node policy document. Operational properties are properties that you can control the value of at run time by using an operational policy.

If you set the ccdt property in the policy document to use a CCDT file, you must also run mqsichangeproperties to specify the CCDT file path. Use the following form, where file_path represents the path to the CCDT file:

mqsichangeproperties IBNODE -o BrokerRegistry -n mqCCDT -v file_path

For more information about operational policy and how to use a policy in a message flow, see Operational policy and MQEndpoint policy.

Table of operational properties

Table 14. List of node properties that can be controlled at run time by using an MQEndpoint policy
Property	Policy document property
Connection type	connection
Destination queue manager name	destinationQueueManagerName
Queue manager host name	queueManagerHostname
Listener port number	listenerPortNumber
Channel name	channelName
Security identity	securityIdentity
Use SSL	useSSL
SSL peer name	SSLPeerName
SSL cipher specification	SSLCipherSpec