MSMQT Observations…

by | Aug 25, 2004 | BizTalk Community Blogs via Syndication | 0 comments

A lot has been said regarding the MSMQT adapter for BizTalk 2004 already, but below
are a few recent observations that may be of help to you. 

When people ask me what MSMQT is, my short answer goes something like this: “MSMQT
is the name of the BizTalk 2004 adapter that implements the MSMQ network protocol
directly within BizTalk.  It allows BizTalk 2004 to send/receive MSMQ messages
directly, and move messages to/from the MessageBox very quickly – without external
(DTC) transaction coordination.  Only private queues are supported for receives.”

Using the MSMQT adapter you can:

  • Use Send Ports to send to public or private queues on remote machines – but the
    queues must be transactional.

  • Use Send Ports to send to local queues, which will be private since that
    is all MSMQT supports.

  • Use Receive Locations to receive from locally defined queues, which will be private since
    that is all MSMQT supports.  These queues can be either transactional or non-transactional. 
    You cannot monitor remote queues (i.e. receive locations can’t reference remote queues.)

You cannot using the System.Messaging MSMQ APIs/COM MSMQ APIs/MSMQ C Libraries or
the MSMQ MMC console on a BizTalk 2004 machine that is running the MSMQT adapter! 
This is because these all rely on the native MSMQ Service running.

You can use the aforementioned APIs (though not the MMC console) from remote machines
(that are not running the MSMQT adapter) to put messages in MSMQT-defined queues.

To test MSMQT queues on the BizTalk 2004 server where they are defined, you can:

  1. Create a Receive Port and a File Receive Location that will monitor a particular directory…

  2. Create a static one-way Send Port that specifies MSMQT & the queue you want to
    test as the destination.  In the “Filters” portion of the Send Port configuration,
    define BTS.ReceivePortName = ReceivePortNameFromStep1

Now, when we you drop a file on your directory, it will be routed to your queue. 
The receive location could also use HTTP posts, in which case the WFETCH tool from
the IIS Resource Kit (or a similar tool) will let you easily get test messages to
the queue.

Note: If you have existing applications that used to send to public MSMQ queues, but
will now be sending to MSMQT queues, the most common problem is that they are referencing
those queues via the PathName property, rather than the FormatName property (with
‘DIRECT=OS:machine\private$\qname’ syntax.)  This is only a problem for users
of the COM/C-Library APIs – the System.Messaging.MessageQueue class actually allows
format names to be used with the Path property.

See this Microsoft
Support discussion for lots of additional insight into MSMQT.

Submit a Comment