Note: Since there is no concept of a store and forward
queue in C all of the following information relates to the Java code base. The
store and forward queue is managed by class MQeStoreAndForwardQueueAdminMsg which
inherits from MQeQueueAdminMsg.
A store and forward queue is normally defined on a server and can be configured
in the following ways:
- Forward messages either to the target queue manager, or to another queue
manager between the sending and the target queue managers. In this case the
store-and-forward queue pushes messages either to the next hop or to the target
queue manager
- Hold messages until the target queue manager can collect the messages
from the store-and-forward queue. This can be accomplished using a home-server queue,
as described in Configuring home server
queues - Introduction. Using this approach messages are pulled from
the store-and-forward queue.
Store-and-forward queues are implemented by the MQeStoreAndForwardQueue class.
They are managed with the MQeStoreAndForwardQueueAdminMsg class,
which is a subclass of MQeRemoteQueueAdminMsg. The main
addition in the subclass is the ability to add and remove the names of queue
managers for which the store-and-forward queue can hold messages.
Apart from the characteristics shared by all remote queues, a store-and-forward
queue object also has a property identifying its set of target queue managers.
The string field Queue_QMgrNameList, with the value "qqmnl",
identifies the field in an administration message representing the set of
target queue managers. The value of this field is set or retrieved using putAsciiArray() and getAsciiArray() methods.
Each store-and-forward queue has to be configured to handle messages for
any queue managers for which it can hold messages. Use the Action_AddQueueManager action,
described earlier in this section, to add the queue manager information to
each queue:
- If you want the store-and-forward queue to push messages to the next queue
manager, the queue manager name attribute of the store-and-forward queue must
be the name of the next queue manager. A connection with the same name as
the next queue manager must also be configured. The store-and-forward queue
uses this connection as the transport mechanism for pushing messages to the
next hop.
- If you want the store-and-forward queue to wait for messages to be collected
or pulled, the queue manager name attribute of the store-and-forward queue
has no meaning , but it must still be configured. The only restriction
on the queue manager attribute of the queue name is that there must not be
a connection with the same name. If there is such a connection, the queue
tries use the connection to forward messages.
Figure 1. Store-and-forward queue
The diagram shows an example of two store and forward queues on different
queue managers, one setup to push messages to the next queue manager, the
other setup to wait for messages to be collected:
- Queue manager qm2 has a connection configured to queue
manager qm3
- Queue manager qm2 has a store-and-forward queue configuration
that pushes messages using connection qm3, to queue manager qm3.
Note that the queue manager name portion of the store-and-forward queue is qm3 which
matches the connection name. Store-and-forward queue qm3.SFQ on qm2 temporarily
holds messages on behalf of qma, qmb and qmc,
(but not qm3).
- Queue manager qm3 has a store-and-forward queue qm3.SFQ.
The queue manager name portion of the queue name qm3 does
not have a corresponding connection called qm3, so all messages
are stored on the queue until they are collected.
- Store-and-forward queue qm3.SFQ on qm3 holds messages
on behalf of queue managers qma, qmb and qmc.
Messages are stored until they are collected or they expire.
If a queue manager wants to send a message to another queue manager using
a store-and-forward queue on an intermediate queue manager, the initiating
queue manager must have:
- A connection configured to the intermediate queue manager
- A connection configured to the target queue manager routed through the
intermediate queue manager
- A remote queue definition for the target queue
When these conditions are fulfilled, an application can put a message to
the target queue on the target queue manager without having any knowledge
of the layout of the queue manager network. This means that changes to the
underlying queue manager network do not affect application programs.
In the diagram, queue manager
qm1 has been configured
to allow messages to be put to queue
invQ on queue manager
qma.
The configuration consists of:
- A connection to the intermediate queue manager qm2
- A connection to the target queue manager qma
- A remote asynchronous queue invQ on qma
If an application program uses queue manager
qm1 to put
a message to queue
invQ on queue manager
qma the
message flows as follows:
- The application puts the message to asynchronous queue qma.invQ.
The message is stored locally on qm1 it is transmitted.
- When transmission rules allow, the message is moved. Based on the connection
definition for qma, the message is routed to queue manager qm2
- The only queue configured to handle messages for queue invQ on
queue manager qma is store-and-forward queue qm3.SFQ on qm2.
The message is temporarily stored in this queue
- The stored and forward queue has a connection that allows it to push messages
to its next hop which is queue manager qm3
- Queue manager qm3 has a store-and-forward queue qm3.SFQ that
can hold messages destined for queue manager qma so the message
is stored on that queue
- Messages for qma remain on the store-and-forward queue
until they are collected by queue manager qma. See Configuring home server queues - Introduction for
how to set this up.