Figure 26. Reply-to queue name substitution during PUT call
A complete remote queue processing loop using a reply-to queue is shown in Figure 26. This applies in both a distributed-queuing environment and a clustering environment. The details are as shown in Table 6.
The application opens QA at QMB and puts messages on that queue. The messages are given a reply-to queue name of QR, without the queue manager name being specified. Queue manager QMA finds the reply-to queue object QR and extracts from it the alias name of QRR and the queue manager name QMA_class1. These names are put into the reply-to fields of the messages.
Reply messages from applications at QMB are addressed to QRR at QMA_class1. The queue manager alias name definition QMA_class1 is used by the queue manager to flow the messages to itself, and to queue QRR.
This scenario depicts the way you give applications the facility to choose a class of service for reply messages, the class being implemented by the transmission queue QMA_class1 at QMB, together with the queue manager alias definition, QMA_class1 at QMA. In this way, you can change an application's reply-to queue so that the flows are segregated without involving the application. That is, the application always chooses QR for this particular class of service, and you have the opportunity to change the class of service with the reply-to queue definition QR.
You must create:
The complementary administrator at the adjacent system must create:
Your application programs use:
In this way, you may change the class of service as necessary, without involving the application, by changing the reply-to alias 'QR', together with the transmission queue 'QMA_class1' and queue manager alias 'QMA_class1'.
If no reply-to alias object is found when the message is put on the queue, the local queue manager name is inserted in the blank reply-to queue manager name field, and the reply-to queue name remains unchanged.
| Name resolution restriction |
|---|
|
Because the name resolution has been carried out for the reply-to queue at 'QMA' when the original message was put, no further name resolution is allowed at 'QMB', that is, the message is put with the physical name of the reply-to queue by the replying application. |
Note that the applications must be aware of the naming convention that the name they use for the reply-to queue is different from the name of the actual queue where the return messages are to be found.
For example, when two classes of service are provided for the use of applications with reply-to queue alias names of 'C1_alias', and 'C2_alias', the applications use these names as reply-to queue names in the message put calls, but the applications will actually expect messages to appear in queues 'C1' and 'C2', respectively.
However, an application is able to make an inquiry call on the reply-to alias queue to check for itself the name of the real queue it must use to get the reply messages.
This example illustrates the use of a reply-to alias to select a different route (transmission queue) for returned messages. The use of this facility requires the reply-to queue name to be changed in cooperation with the applications.
As shown in Figure 27, the return route must be available for the reply messages, including the transmission queue, channel, and queue manager alias.
Figure 27. Reply-to queue alias example
This example is for requester applications at 'QM1' that send messages to server applications at 'QM2'. The servers' messages are to be returned through an alternative channel using transmission queue 'QM1_relief' (the default return channel would be served with a transmission queue 'QM1').
The reply-to queue alias is a particular use of the remote queue definition named 'Answer_alias'. Applications at QM1 include this name, 'Answer_alias', in the reply-to field of all messages that they put on queue 'Inquiry'.
Reply-to queue definition 'Answer_alias' is defined as 'Answer at QM1_relief'. Applications at QM1 expect their replies to appear in the local queue named 'Answer'.
Server applications at QM2 use the reply-to field of received messages to obtain the queue and queue manager names for the reply messages to the requester at QM1.
The WebSphere MQ system administrator at QM1 must ensure that the reply-to
queue 'Answer' is created along with the other objects. The
name of the queue manager alias, marked with a '*', must
agree with the queue manager name in the reply-to queue alias definition, also
marked with an '*'.
| Object | Definition |
|
|---|---|---|
| Local transmission queue | QM2 |
|
| Remote queue definition | Object name | Inquiry |
|
| Remote queue manager name | QM2 |
|
| Remote queue name | Inquiry |
|
| Transmission queue name | QM2 (DEFAULT) |
| Queue manager alias | Object name | QM1_relief * |
|
| Queue manager name | QM1 |
|
| Queue name | (blank) |
| Reply-to queue alias | Object name | Answer_alias |
|
| Remote queue manager name | QM1_relief * |
|
| Remote queue name | Answer |
The WebSphere MQ system administrator at QM2 must ensure that the local
queue exists for the incoming messages, and that the correctly named
transmission queue is available for the reply messages.
| Object | Definition |
|
|---|---|---|
| Local queue | Inquiry |
|
| Transmission queue | QM1_relief |
|
Applications fill the reply-to fields with the reply-to queue alias name,
and leave the queue manager name field blank.
| Field | Content |
|
|---|---|---|
| Queue name | Inquiry |
|
| Queue manager name | (blank) |
|
| Reply-to queue name | Answer_alias |
|
| Reply-to queue manager | (blank) |
|
Applications at QM2 retrieve the reply-to queue name and queue manager name
from the original message and use them when putting the reply message on the
reply-to queue.
| Field | Content |
|
|---|---|---|
| Queue name | Answer |
|
| Queue manager name | QM1_relief |
|
In this example, requester applications at QM1 always use 'Answer_alias' as their reply-to queue in the relevant field of the put call, and they always retrieve their messages from the queue named 'Answer'.
The reply-to queue alias definitions are available for use by the QM1 system administrator to change the name of the reply-to queue 'Answer', and of the return route 'QM1_relief'.
Changing the queue name 'Answer' is normally not useful because the QM1 applications are expecting their answers in this queue. However, the QM1 system administrator is able to change the return route (class of service), as necessary.
Queue manager QM1 retrieves the definitions from the reply-to queue alias when the reply-to queue name, included in the put call by the application, is the same as the reply-to queue alias, and the queue manager part is blank.
The queue manager replaces the reply-to queue name in the put call with the queue name from the definition. It replaces the blank queue manager name in the put call with the queue manager name from the definition.
These names are carried with the message in the message descriptor.
| Field name | Put call | Transmission header |
|---|---|---|
| Queue name | Answer_alias | Answer |
| Queue manager name | (blank) | QM1_relief |
To complete this example, let us take a walk through the process, from an application putting a message on a remote queue at queue manager 'QM1', through to the same application removing the reply message from the alias reply-to queue.
| Reply-to queue name | Answerable |
| Reply-to queue manager name | (blank) |
| Reply-to queue name | Answer |
| Reply-to queue manager name | QM1_relief |