Resolution rules always start with a message being presented to a queue manager, with a specified destination queue manager name and a specified destination queue name. This is equivalent to the API call putMessage(queueManagerName, queueName, msg,....). The destinationQueueManagerName and destinationQueueName should identify a local queue onto which the message should eventually be placed.
If the queue manager has an alias mapping destinationQueueManagerName to another name, for example, realQueueManagerName then this substitution is made first, and the call:
putMessage(destinationQueueManagerName, destinationQueueName
is effectively transformed to
putMessage(realQueueManagerName, destinationQueueName.
From this point on destinationQueueManagerName is completely forgotten, and realQueueManagerName is used.
The queue manager now looks for a queue to place the message on. The queue manager looks for a queue with the best match, following the these rules:
Local queue or remote queue definition where the queue name matches the destinationQueueName and the queues queue manager name matches the destinationQueueManagerName.
The term 'queues queue manager name needs some explaining. For a local queue this is the same as the name of the queue manager where the queue resides. For a local queue localQ@localQM, localQM is the queues queue manager name.
For a remote queue definition remoteQ@remoteQM residing on localQM, the queues queue manager name is remoteQM.
If a queue (remote definition or local) has a matching queue manager name and an alias and this alias matches destinationQueueName then this queue will considered a match. Effectively the put message call :
putMessage(destinationQueueManagerName, queueAliasName
is transformed to
putMessage(destinationQueueManagerName, realQueueName.
at this point. The original name of the queue used in the put call is entirely forgotten from this point on in the resolution.
If there is no exact match the queue manager searches for an inexact match. An inexact math is a Store and Forward queue that will accept messages for the given queue manager name. The search for a store and forward queue ignores the destinationQueueName. If an appropriate Store And Forward queue is found, then the message is put to it, using the destinationQueueManagerName and destinationQueueName, and the StoreAndForward queue stores the destination with the message.
If no queue has been found that will accept the message the and the message is not for a local queue, then the queue manager tries to find the remote destination queue and queue and create a remote queue definition for it automatically. This is called queue discovery. The queue manager can only perform discovery if:
If discovery is successful the newly created remote queue definition is used. This then behaves as if an exact match on a remote queue definition had been found in the first place.
The remote queue definition created by discovery is always synchronous, even if the queue to which it resolves is asynchronous, or even a Store and forward queue.
If no queue has been found by the above steps then the message put is deemed to have failed.
A message placed upon a remote queue is pushed across the network. The queue first locates a connection definition with the correct name, and then puts the message to the remote queue manager using the connection definition as the entry to the communications link.
The queue seeks a connection definition whose name is the same as the queues queue manager name. The connection may be a normal connection, or a via connection.
A normal connection points to a listener upon the destination queue manager. The put message command is routed directly to the destination queue manager. The putMessage call is then resolved just as if it had been placed on the queue manager via the API.
A via connection points at another connection called the 'real' connection. All commands performed on the via connection will be delegated to the real connection. Via connections can be chained, and so the command may travel 'via' several indirections before reach a real connection. The names of the put message destination are not changed by the use of a via connection.
Eventually the command will be routed to a 'normal' connection definition, then across the network to a queue manager, where the message put will be resolved.
Home server queues pull messages from Store and forward queues. The route of the pull only spans a single network hop. Only messages for the queue manager hosting the home server queue will be pulled down. Messages pulled from the store and forward queue are presented to the queue manager using a normal put method call, and are then resolved as normal. The messages pulled down this way should all be destined for local queues.