Share via


Tracking messages and routes

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Tracking messages and routes

You can track the passage of messages from a source computer to a target queue by sending test messages. You can also track the route taken in your network by test messages or all messages sent from the source computer to test queues on remote computers by enabling the message route tracking feature. Neither of these features is enabled by default following Message Queuing installation. For instructions on enabling these features, see Enable route tracking and test messages.

Sending a test message

You can send a test message from an independent client or a Message Queuing server to a test queue on any other independent client or Message Queuing server within the same Windows forest. To do so, after you have enabled test messages, you must first create a test queue, or change the type ID of an existing queue, so that you can send test messages to the test queue on the destination computer. For more information, see Sending test messages.

Report messages, which track the routes of messages through your network, are always sent to the report queue specified by the source computer for test messages if message tracking is enabled on the source computer.

For information on how to send a test message, see Send test messages.

Message route tracking

You can use the message route tracking feature to track the route that messages take through your network. When all the conditions for route tracking are satisfied, a report message is sent to the report queue for the source computer when the message leaves its source computer, when it arrives at its destination computer, and whenever the message arrives at or leaves a Message Queuing server with routing enabled.

After message route tracking is enabled, there are two basic requirements for its use. First, you must enable message route tracking and create or specify a report queue for the source computer. Second, the route tracking flag (property) in the message must be set programmatically by the sending application. In addition, only messages sent to a remote computer are tracked, and messages sent over HTTP/HTTPS transport as well as messages sent to multiple destinations using IP multicast, distribution lists, or multiple-element format names cannot be tracked in the current version of Message Queuing.

For information on message route tracking, see Track message routing. For information on setting properties programmatically, refer to the Message Queuing Software Development Kit (SDK).

Only one queue can be specified in the header of a message as the report queue for that message. If a route-tracked message with a report queue specified in its header subsequently passes through a Message Queuing server with routing enabled that also has message route tracking enabled, Message Queuing sends a conflict report message to the report queue for that server when the message leaves it.

For example, consider three computers, called A, B, and C, where message route tracking is enabled for computer A. In this example, the Message Queuing application on computer A sends a message to computer C through out-routing server B. If the report queue for computer A is called QA, a report message is sent to QA when the following events occur:

  • The message leaves computer A.

  • The message arrives at out-routing server B.

  • The message leaves out-routing server B.

  • The message arrives at computer C.

If out-routing server B is also configured with message route tracking enabled, with report messages being sent to QB, this queue receives a conflict report message when the message leaves out-routing server B. The original source queue QA, however, continues to receive the regular tracking messages.

In a second example, computer A does not have message route tracking enabled, but route tracking is enabled on computers B and C. In this case, the message starts reporting its movements when it leaves out-routing server B. A total of two report messages are sent to QB (when the message leaves computer B and when the message arrives at computer C), but no conflict report messages are sent.

In a third example, neither computer A nor computer B has message route tracking enabled, but route tracking is enabled on computer C. In this case, no report messages are sent before the message reaches the destination computer, but one report message is sent to QC when the message arrives at its destination. No conflict report messages are sent.

Report messages consist of a label and a body. The label has the following format:

gggg:dddd:hh sent from <computer> to <address> at <time>

gggg:dddd:hh received by <computer> to <address> at <time>

where gggg is the first four hexadecimal digits of the globally unique identifier (GUID) of the source queue, dddd is the internal message identifier, and hh is the hop count.

The internal message identifier is the message sequence number, which is part of the entire message identifier. The message identifier is not used in its entirety because it is too big to be easily read. It is a 16-byte source GUID and a 4-byte sequence number.

When conflict report messages are sent, the labels contain the string "Report Message Conflict."

The body of a regular report message contains the ID of the message, the target queue, the destination of the next hop (if any), and the hop count in an XML format. For example, the body of the report message sent to QA when the message leaves the out-routing server in the first example will have the following form:

<MESSAGE ID>message_ID</MESSAGE ID>

<TARGET QUEUE>format_name_of_target_queue_on_computer_C</TARGET QUEUE>

<NEXT HOP>IP_address_of_computer_C</NEXT HOP>

<HOP COUNT>1</HOP COUNT>

The body of a conflict report message contains has an additional line containing the original source queue. For example, the body of the "Report Message Conflict" message sent to QB when the report message just described is sent to QA in the first example will have the following form:

<ORIGINAL QUEUE>format_name_of_QA</ORIGINAL QUEUE>

<MESSAGE ID>message_ID</MESSAGE ID>

<TARGET QUEUE>format_name_of_target_queue_on_computer_C</TARGET QUEUE>

<NEXT HOP>IP_address_of_computer_C</NEXT HOP>