The PROPID_M_CLASS property indicates message type. A message can be a normal Message Queuing message, a positive or negative (arrival and read) acknowledgment message, or a report message. For negative acknowledgment messages, the value of this property can indicate why the message did not arrive or was not retrieved. Typically this property is set by Message Queuing when it sends the message, however it can also be set by a connector application when the connector application sends a message.
Normal messages (all messages created by your application):
A normal Message Queuing message.
Positive arrival acknowledgment message (typically generated by Message Queuing):
The original message reached its destination queue.
Negative arrival acknowledgment messages (typically generated by Message Queuing):
The access rights for placing messages in the destination queue are not allowed for the sending application.
The destination queue is not available to the sending application.
The destination queue manager could not decrypt a private (encrypted) message (see PROPID_M_PRIV_LEVEL).
Message Queuing could not authenticate the original message. The digital signature attached to the original message is not valid.
The source queue manager could not encrypt a private message (PROPID_M_PRIV_LEVEL).
The hop count of the original message is exceeded.
A nontransactional message was sent to a transactional queue.
A transactional message was sent to a nontransactional queue.
The message was purged before reaching the destination queue.
The destination queue of the original message is full.
Either the time-to-reach-queue or time-to-be-received timer expired before the original message could reach the destination queue.
For transactional messages, this is an in-doubt negative acknowledgment. For example, the local queue manager will set this class when the message timer expires, even though a positive confirmation may be in route from the remote queue manager.
The source computer joined a domain or moved to a new forest while the transactional message was waiting in an outgoing queue to be delivered to its destination. As a result, the source computer has a new msmq (MSMQ-Configuration) object with a new GUID, so the message was moved to the transactional dead-letter queue or discarded to prevent a possible duplicate message from reaching the destination queue.
The destination queue manager does not have the enhanced (128-bit) cryptographic provider installed.
Positive read acknowledgment message (typically generated by Message Queuing):
The original message was retrieved by the receiving application.
Negative read acknowledgment messages (typically generated by Message Queuing):
The queue was deleted before the message could be read from the queue.
The queue was purged, and the message no longer exists.
The original message was not removed from the queue before its time-to-be-received timer expired.
For transactional message, the remote queue manager has indicated that the message was not retrieved. This is the only negative acknowledgment that can be trusted to indicate the message was not retrieved.
For transactional messages only. The local queue manager has indicated that the original message was not removed from the queue before its time-to-be-received timer expired.
This class is an in-doubt negative acknowledgment. For example, the local queue manager will set this class when the time-to-be-received timer expires, even though a positive confirmation may be in route from the remote queue manager.
Report messages (typically generated by Message Queuing):
Sent each time the message enters or leaves a Message Queuing server.
Acknowledgment messages are typically generated by Message Queuing whenever the sending application requests them. The acknowledgment message is returned to the administration queue that is specified by the sending application.
|Acknowledgment messages can also be created by connector applications. When the connector application creates an acknowledgment message, it must set PROPID_M_CLASS and PROPID_M_CONNECTOR_TYPE.|
Transactional messages can have two in-doubt negative acknowledgments: MQMSG_CLASS_NACK_REACH_QUEUE_TIMEOUT and MQMSG_CLASS_NACK_RECEIVE_TIMEOUT_AT_SENDER. These two classes are considered in doubt because they can be set by the local queue manager even though a confirmation notification may be in route from the remote queue manager. The only trusted negative acknowledgment is MQMSG_CLASS_NACK_RECEIVE_TIMEOUT, because this class is set by the remote queue manager.
Report messages are typically generated by Message Queuing whenever a report queue is defined at the source queue manager. For information on report queues, see Report Queues.
To retrieve the class of the message, specify PROPID_M_CLASS in the MQMSGPROPS structure. Then call MQReceiveMessage or MQReceiveMessageByLookupId and examine the returned value. The type indicator of this property can be set to VT_UI2 or VT_NULL. If you set the type indicator to VT_NULL, Message Queuing automatically changes the type indicator to VT_UI2 during the function call.
When reading messages in an administration queue or dead-letter queue, retrieve PROPID_M_CLASS to find out why the message was sent to the queue.
Equivalent COM Property
With COM components, the equivalent property for retrieving the message class is MSMQMessage.MsgClass.
|For information on||See|
What is in acknowledgment messages.
The type of queues used as administration queues
How dead-letter queues are used
The following code fragment shows how PROPID_M_CLASS is specified in arrays that can be used to initialize an MQMSGPROPS structure to ascertain the message class:
aMsgPropID[i] = PROPID_M_CLASS; //Property ID aMsgPropVar[i].vt = VT_NULL; //Type indicator
The following examples are included in Using Message Queuing.
|For an example of||See|
Filtering messages in an administration queue according to the acknowledgment class of the messages
Setting the acknowledgment class when an acknowledgment message is sent at the request of a connector application