This page is an introduction to the use of an MQGet node in a request-response flow, and describes how the node processes the input messages (according to the LocalEnvironment and input parameters you set) to construct the output messages.
A request-response flow between two applications allows one of the applications to request messages from the other. This type of flow is illustrated in the following diagram:
In the diagram, the Requesting Application places a message into the "Request" input queue of the Replying Application. The Replying Application then processes the message and sends a reply to the "Reply" queue specified in the original message from the Requesting Application.
If one of these applications is to be replaced or enhanced without making changes to the other, then messages will need to be transformed between the two applications. To achieve this, the Broker can be inserted between them, as shown in the following diagram:
Now a queue alias, or a similar device, is configured so that the Requesting Application places its request message into the input queue of the "Coordinated Request Reply" Broker message flow. In the previous example this message was placed directly into the input queue of the Replying Application. The "Coordinated Request Reply" flow transforms the message to a format suitable for the Replying Application, and passes it on to its input queue. It also saves the original Requesting Application's reply-to queue details, and restores these to the reply message it receives from the Replying Application so it can be posted back correctly to the Requesting Application.
An MQGet node can be placed anywhere in a flow and receives on its input terminal an input tree propagated from the preceding node. It then uses the message retrieved from the configured WebSphere MQ queue to build a result tree. Finally, it uses the input tree and the result tree to build an output tree that is then propagated to its output, warning or failure terminal depending on the configuration of the node and the result of the Get operation.
For more details on constructing a flow, see the sample: Coordinated Request Reply sample.
The LocalEnvironment propagated from the preceding node is read and updated by the MQGet node.
${inputMQParmsLocation} is the value set in the MQGet Node Property Input MQ Parameters Location on the Request Properties tab.
${outputMQParmsLocation} is the value set in the MQGet Node Property Output MQ Parameters Location on the Result Properties tab.
For details of these properties, see MQGet node.
The following diagram shows in a little more detail how the MQGet node constructs the MQMD to be used on the call to WebSphere MQ:
The following diagram outlines how the output message tree is constructed by combining the input tree from the previous node with the result tree from the MQGet call:
Here are some examples of how message trees are constructed according to the rules outlined above.
With a message assembly like this: | The message that MQGet returns is: |
---|---|
|
![]()
![]() |
With the following settings: | The resulting output message assembly is: |
---|---|
|
|
|
This tree is effectively the result of doing an assignment from ${resultDataLocation} to ${outputDataLocation}. The value of the source element is copied, as are all children including attributes. |
|
This tree has the MQMD used for the get in the OutputLocalEnvironment because the input MQ parameters location had an MQMD element under it. Even though the input tree is not copied, the presence of the MQMD element causes the MQMD used for the get to be placed in the output tree. |
|
The setting of copyMessage in this case makes no difference to the eventual output tree. |
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ac34680_ |