Administering Queues

A transactional queue is one that only contains transactional messages, which are messages sent within a transaction. The requirements for sending and receiving messages are based on the type of queue used (transactional or nontransactional) and the queue's location (local or remote).

Subqueues allow applications to group messages. Subqueues are useful in the following scenarios:

• Work order processing. If an application processes messages that contain items from different work orders, it can use the subqueues to group the line items by work order for more efficient processing.
  
  
• Poison message handling. If an application receives a message that it cannot process at that time, it can move the message to a fault subqueue to be processed later.
  
  

Subqueues are implicitly created when they are opened. In other words, when a message is moved to a subqueue, this action essentially creates a subqueue if one does not already exist. Subqueues are deleted when empty, and they have no open handles. Applications cannot send messages directly to subqueues. They can only move messages to a subqueue. They can receive messages from subqueues, move them between a main queue and its subqueue, or move them between subqueues of the same main queue. They cannot move them from the subqueue of a main queue to the subqueue of a different main queue.

For example, in the following figure, messages can be moved back and forth between subqueue1 (or subqueue2) and the Queue messages folder of queuea. Messages can also be moved between subqueue1 and subqueue2. Similarly, messages can be moved back and forth between queuez and its subqueues, subqueue3 and subqueue4.

However, messages cannot be moved in either direction between queuea and subqueue3 or subqueue4, or between queuez and subqueue1 or subqueue2. Similarly, messages cannot be moved back and forth between the subqueues of queuea (subqueue1 or subqueue2) and the subqueues of queuez (subqueue3 or subqueue4).

Subqueues do not have their own properties or state. They share the properties of the main queue. For example, a subqueue does not have its own:

• Quota
  
  
• Access control list (ACL)
  
  
• Transactional type
  
  

Subqueues share the quota of the main queue, and messages in the subqueue are factored into that quota.

Subqueues cannot be created under journal or other system queues, or other subqueues.

Administration queues are application-generated queues. They are used to store system-generated negative and positive acknowledgment messages that Message Queuing or connector applications create. They are specified programmatically in the original messages by the sending application. Any available nontransactional queue can be specified as an administration queue. Administration queues do not contain administrative messages, which are stored in internal private queues.

The system-generated acknowledgment messages returned to these queues can indicate whether a message arrived at its destination queue, whether it was retrieved from the destination queue, or both. Each acknowledgment message contains information that describes what triggered the acknowledgment and to which message the acknowledgment refers. When requesting acknowledgment messages, the sending application must specify the queue to be used as the administration queue and the acknowledgment level of the message. Typically, an administration queue is a local queue, so that the sending application can read the acknowledgment messages locally.

Like administration queues, response queues are application-generated. They are used to store application-generated response messages that are typically returned by an application that is reading messages from a queue. Response queues are specified programmatically by the sending application when a message is sent. Any available queue can be specified as a response queue. Response messages are not the same as administrative response messages, which are stored in an internal private queue.

The response messages returned to these queues must be understood by the application returning the response messages and the application reading the response messages. Message Queuing has no control over what information is sent in response messages. When requesting response messages, the sending application must specify the queues that it wants to use as response queues. Typically, response queues are local queues, so that the sending application can read the response messages locally.

When a response queue and an administration queue are both needed, their functionality can be combined into a single queue. However, because all administration queues must be nontransactional, this queue will accept only nontransactional messages.

Report queues are application-generated queues used to store report messages that Message Queuing or connector applications generate when the sending application requests tracing. The report messages indicate the route that a message took to its destination on a remote computer or the route that a test message took to a test queue on a remote computer. There can be only one report queue for each computer.

All report queues must have the following label and queue type identifier:

• Label: MQReport Queue
  
  
• Queue type identifier:
  
  

  {55EE8F32-CCE9-11CF-B108-0020AFD61CE9}

The Message Queuing administrator typically creates report queues by using Active Directory Users and Computers. However, an application can also generate them, if the correct label and queue type identifier are specified when the queue is created. Message Queuing uses the label and queue type identifier to locate and open the appropriate queue when sending report messages.