Data types for elements in the MQ DestinationData subtree
The DestinationData subtree is part of the Destination subtree in the local environment. Local environment trees are created by input nodes when they receive a message and, optionally, by Compute nodes. When created, the trees are empty but you can create data in them by using ESQL statements coded in any of the SQL nodes.
The Destination subtree consists of subtrees for zero or more protocols; for example, WebSphere® MQ and WebSphere MQ Everyplace®, or a subtree for routing destinations (RouterList), or both.
The protocol tree has two children:
- Defaults is the first element; there can be only one.
- DestinationData is the following element, and can be repeated any number of times, to represent each destination to which a message is sent.
Local environment tree structure includes a picture of a typical tree, showing a Destination tree that has both protocol and RouterList subtrees.
The structure of data within the DestinationData folder is the same as that in Defaults for the same protocol, and can be used to override the default values in Defaults. You can therefore set up Defaults to contain values that are common to all destinations, and set only the unique values in each DestinationData subtree. If a value is set neither in DestinationData, nor in Defaults, the value that you have set for the corresponding node property is used.
The fields, data type, and valid values for each element of Defaults and DestinationData subtrees for WebSphere MQ are shown in the following table. MQOutput node describes the corresponding node properties.
Refer to Accessing the local environment tree for information about using DestinationData.
| Data type of the element | Represented as | Corresponding node property | Valid values |
|---|---|---|---|
| queueManagerName | CHARACTER | Queue Manager Name | |
| queueName | CHARACTER | Queue Name | |
| transactionMode | CHARACTER | Transaction Mode | no, yes, automatic |
| persistenceMode | CHARACTER | Persistence Mode | no, yes, automatic, asQdef |
| newMsgId | CHARACTER | New Message ID | no, yes |
| newCorrelId | CHARACTER | New Correlation ID | no, yes |
| segmentationAllowed | CHARACTER | Segmentation Allowed | no, yes |
| alternateUserAuthority | CHARACTER | Alternate User Authority | no, yes |
| replyToQMgr | CHARACTER | Reply-to queue manager | |
| replyToQ | CHARACTER | Reply-to queue |
In addition to the elements listed in the table above, there are a number of elements that you can specify that do not have a corresponding node property. These elements are shown in the following table.
| Data type of the element | Represented as | Valid values | Effect |
|---|---|---|---|
| inMessageGroup | CHARACTER | no, yes | If you specify yes, the MQMD message flag MQMF_MSG_IN_GROUP is set on the message and the MQPMO option MQPMO_LOGICAL_ORDER is used to put the message to the queue. |
| lastInMessageGroup | CHARACTER | no, yes | If you specify yes, the MQMD message flags MQMF_MSG_IN_GROUP and MQMF_LAST_MSG_IN_GROUP are set on the message and the MQPMO option MQPMO_LOGICAL_ORDER is used to put the message to the queue. |
You can use the inMessageGroup and lastInMessageGroup elements to create message groups on a queue and specify that the messages are retrieved in logical order rather than physical order. For information about message groups, see Message groups in the IBM® MQ product documentation. For information about the logical and physical ordering of messages, see Logical and physical ordering in the IBM MQ product documentation.
Case-sensitivity for data types and values
When you create these fields in the DestinationData folder, enter the data type and value exactly as shown in the table. If any variations in spelling or case are used, these fields or values are ignored in the DestinationData records and the next available value is used.
For example, the following ESQL samples could result in unexpected output:
SET OutputLocalEnvironment.Destination.MQ.DestinationData[1].persistenceMode = 'YES';SET OutputLocalEnvironment.Destination.MQ.DestinationData[2].PersistenceMode = 'yes';In each case, the DestinationData folder might not write a persistent message for these destinations. In the first example, the persistenceMode field has been given a value of 'YES', which is not one of the valid values listed in the table, and this value is ignored. In the second example, the field named 'PersistenceMode' is specified incorrectly and is ignored. Either the persistenceMode value of the Defaults folder, or the value of the associated attribute on the MQOutput node are used. If this behavior causes a value of 'no' or 'automatic' to be used, a persistent message is not written.
If a DestinationData folder is producing unexpected output, check that you have used the correct case and spelling in the fields and values.