Washington, September 15-18, 1999 – London, November 21-24, 1999

Microsoft Message Queues (MSMQ)

Brian Francis

What is Message Queuing

Message queuing is a system that allows different applications to communicate with each other. These applications can be on the same or different physical platforms. The platforms can be located in the same room, on the same LAN, or at any locations that are electronically connected. The connection does not even need to be permanent. The platforms can even be running different operating systems.

This sounds like a very heterogeneous system. Different applications, wide geographic locations, different connection types, and different operating systems are all characteristics of the Internet-connected world that we are living in today. Being able to move data between these systems has always been a goal of those who preach about connectivity.

Technologies such as SQL, ODBC, FTP, and HTTP all provided different mechanisms for data to be moved between systems in this heterogeneous environment. The only drawback is that the applications on each end have to both understand the exact same protocol for the way the data is transmitted. While large numbers of systems have been created using these systems, that doesn't mean that a more efficient method of communication doesn't exist.

The next step is to let different applications exchange application information, which can be characterized as a richer set of information than just plain data. There are some competing technologies that are available today that perform these functions: COM, the Component Object Model, and CORBA, the Common Object Request Broker Architecture. These technologies both provide mechanisms for applications and their components to communicate with one another. But, for this communication to take place, both applications must be running, and the connection between the two of them must be intact.

While for many applications, this constraint is not a problem. But what happens if one of the systems is not available, or the connection between the two of them is not active? Neither COM nor CORBA can handle this situation. There needs to be something between the two applications that can manage the communications and deal with these problems. One type of system that does this is a message queuing system.

Brian Francis Brian Francis is the technical evangelist for NCR's Self Service Solutions. From his office in Duluth, Georgia, Brian is responsible for enlightening NCR and their customers in the technologies and tools used for Self Service Applications. Brian also uses the tools he evangelizes in developing solutions for NCR's customers. His tools of choice include Visual Basic, Visual C++, Java and all of the Microsoft Internet Products. He is the author/co-author of numerous Wrox books including Professional ASP 2.0, Beginning ASP 2.0, Professional IE4 Programming and ASP Programmer's Reference.

Why use Message Queuing

Now that we better understand what message queuing is, we need to look at why systems of today require their use. What other technologies exist that play the same role as message queuing, and when should message queuing be used over another technology. To do this, we need to look at the changing architectures of systems today. We also need to look at the tradeoffs that selecting message queuing over another technology will present to us.

Distributed Systems

In the early days of computing, there was one machine, and everybody had to go to that machine to do their processing. As machines became less expensive, and the systems that ran on them more powerful, you found multiple machines, each performing a different task. To access these machines, maybe you logged in using a dumb terminal. Pretty soon, these systems were connected together, and your PC client could access data from any of these systems from anywhere on the network.

As more and more applications were being developed, and as different types of computers were running these applications, the systems evolved from a centralized storehouse of business information to a more distributed system. As the processing and the data in a system was distributed, you had to start worrying about how the systems were connected together. In many instances, the connection may not be permanent. You may have to dial-up or dock your machine in order to connect and exchange information. Or, the system that you are trying to communicate with is not active when you want to communicate with it. It is these types of distributed systems where message queuing can provide great advantages.

A user can perform certain tasks with an application server that requires the services of another system, which is not currently available. This unavailability can be the result of a network disconnection, or due to the fact that the system is only available at certain times. That application server can queue messages for delivery to the other application until that system is again available. When that system becomes available, the queued messages can be sent and processed. This support for distributed applications makes message queuing technology an important technology in creating tomorrow's business applications.

Communication Speed

At first glance, it would seem that this is a slow way to communicate between applications. Isn't it faster just to open up a TCP socket on another machine and let my applications exchange information that way? Or maybe using a named pipe, or some other communication method? Well, in a narrow view of things, yes that is faster. But if you are in a connected environment that supports these communication methods, then express delivery of message queue messages gives nearly similar performance. But what happens if the system is not connected using a high-speed, relatively inexpensive link?

If your application is relying on communication protocols that require a permanent connection, then in order for that application to work, the connection has to be in place. This can mean always having your system connected to the network, via LAN, WAN, phone, or by some other means. When the means of connection is not inexpensive, this method of communication ceases to be effective for running a distributed application. If the application supports queuing, then all that needs to happen during a connected state is an exchange of messages. All of the other work can take place off-line, when connect charges are not being incurred.

MSMQ vs. COM

So then,should I always use message queuing to communicate between applications? This isn't the case either. If your business environment requires some activities be carried out synchronously, then a communication method such as DCOM or CORBA is better suited to perform this type of processing. If everybody using the application is always connected to the LAN, and all of the application servers are connected over fast, local, reliable links, then messaging may not be the answer either. And for many developers, message queuing is a new and unfamiliar technology that they may not be willing to investment in.

A few short guidelines of when to use message queuing can help to clarify the decision to use it or not:

Ø        If the application you are communicating with is not running at the same time as your application, use message queuing…

Ø        If the message is important and will cause problems if it is lost, use message queuing…

Ø        If your application is not always connected to receiver application, but still needs to be functional, use message queuing...

Ø        And if you perform many communication tasks with other applications asynchronously, and may or may not care about their response, use message queuing…

Working with Queues and Messages

It is surprising how easy it is to support message queues in your components, given the power and flexibility that MSMQ provides. There are two primary operations that you can do with a message queue.

Ø        You can open or close the queue

Ø        You can send or receive a message.

There are other methods that allow you to search for a queue, create or delete queues, and manage the properties of existing queues. There are two ways that the ActiveX objects that encapsulate the functionality of MSMQ can be used. These can be directly created in ASP pages, using the Server.CreateObject method. They can also be created in VB Active Server Components by using the ObjectContext.CreateInstance method.

MSMQ Object Model

There is a set of COM objects that you can use from within your ASP components to interact with the MSMQ system. These objects allow you to lookup queues from MSMQ servers, manage the messages for those queues, and administer those queues as well. There are objects that also allow you to work with messages themselves.

Object	Usage
MSMQQuery	Used to locate a collection of queues
MSMQQueueInfos	Collection of information about queues returned by the MSMQQuery object
MSMQQueueInfo	Information about a single queue in the MSMQQueueInfos collection
MSMQQueue	Object allowing you to interact with a specific queue itself
MSMQMessage	Object corresponding to a message in a queue

Next, we will look at how to use these object to perform the basic interactions with MSMQ that you need to deal with messages.

Find a Queue

The first thing that you will need to do is find the queue to send your messages to. There are two ways to find a queue to work with. If the queue exists, then you can locate it. If it doesn't exist then you can create it. The object MSMQQueueInfo allows you to manipulate information about a queue. To create a new queue, you will use this object's Create method. Prior to calling Create, you will need to set some information about the queue. This information at least has to include the location of the queue.

The location of a queue is called its path name. This path name indicates three things about the queue:

Ø        The machine it is located on

Ø        Whether it is public or private

Ø        The name of the queue

The format of the queue name is machinename\queuename for a public queue or .\PRIVATE$\queuename for a private queue. Private queues can only be created on the local machine, so a machine name is not needed. To set the pathname you could use:

Dim qinfo as MSMQQueueInfo

Set qinfo = GetObjectContext().CreateInstance("MSMQ.MSMQQueueInfo")

qinfo.PathName = "NT4_Server\TestQueue"

Once the queue has been named, other properties can be set. The pathname parameter is the only required parameter.

To create the queue, all you now need to do is call its create method:

qinfo.Create

We now have a reference to a valid queue that can be used in our next step: opening the queue.

If you know that the queue you are interested in already exists, but do not know the exact name if it, you can lookup a reference to the queue. Using the LookupQueue method of the MSMQQuery object does this. This is the only method of this object, and will return a collection of queues based on criteria that you set. This collection will be in the form of an instance if the MSMQQueueInfos object. For the criteria, you can choose from one or more of the following properties of the queue:

Parameter – Optional	Type	Value
QueueGuid	String	Identifier of queue.
ServiceTypeGuid	String	Type of service provided by the queue.
Label	String	Label of queue.
CreateTime	Variant Date	Time when queue was created.
ModifyTime	Variant Date	Time when queue properties were last set (both when the queue was created and the last time Update was called).

Since these parameters only allow you to set a single value for the parameter, to make the query more effective, you can also set a Boolean operation for each parameter. In other words, when you enter a parameter value, say for Label, the method will only return those queues that exactly match the value you entered. By setting the relationship parameter, you can specify that the value you are entering has a certain relationship to the search value.

To call the LookupQueue method, you would do something like the following:

Dim query As MSMQQuery

Set query = GetObjectContext().CreateInstance("MSMQ.MSMQQuery")

Dim qinfos As MSMQQueueInfos

Dim qinfo As MSMQQueueInfo

Set qinfos = query.LookupQueue(Label:="Bill")

This will return a collection of queues, all of which have a Label value of 'Bill'. While this return value is a collection, it is not navigable using the same methods as other collections. To navigate, there is a Reset method to move in front of the beginning of the collection, and a Next method to get the next entry in the collection. To navigate through each entry in the collection, you can use this:

qinfos.Reset  

Set qinfo = qinfos.Next  

Do While Not qinfo Is Nothing

'     Do something with this queue

      Set qinfo = qinfos.Next  

Loop

This gives you two methods to retrieve a queue. Once you have retrieved a reference to the queue that you want, the next step is to open the queue.

Open a Queue

The MSMQQueueInfo object that was returned when you created a queue or found one using LookupQueue is merely information about a queue. To actually work with a queue - that is, use it to send and receive messages - you have to open it. When you open a queue, you call the Open method of the MSMQQueueInfo object and are returned an MSMQQueue object. It is this object that you will subsequently use in working with the queue. To open a queue, you first need to set two parameters. The first parameter will determine what you are doing with the queue and the second will determine what others can do with it while you have it open.

When you have an open queue in your application, there are three operations that you can perform on it. You can:

Ø        Send messages to the queue,

Ø        Retrieve messages from the queue,

Ø        or Peek at messages in the queue.

Reading and writing messages are self-explanatory. Peeking at a message in the queue means to look at the contents of a message in the queue without removing it from the queue.

You also need to set how other people can interact with the queue when you have it open. If you have opened the queue for sending or peeking, then the only valid setting for this parameter is to allow others to fully interact with the queue. If you have opened the queue for receiving, then you can either allow other full access to the queue, or you can prevent others from receiving messages from the queue as well.  Even if you set this flag, other applications can still send messages to the queue and peek at messages in the queue.

Once you have determined the parameter settings for your queue, you can issue the open call. The format for this call is:

Open(accessmethod, sharemode)

To open a queue for sending messages to it, you would:

qInfo.Open(MQ_SEND_ACCESS, MQ_DENY_NONE)

Now that you have a queue open for writing, the next step that you need to follow is to create a message that can be sent to that queue.

Create a Message

To send a message, you will need to create an instance of the MSMQMessage object. This object encapsulates all of the data and methods that you need to create and send a message. There are a number of properties that you can set when sending a message. Some of these parameters are considered core properties, such as the body of the message. Others allow you to modify certain characteristics about how the message is delivered, or other characteristics.

The primary parameter for the MSMQMessage object is the Body parameter. This holds the actual contents of the message. This value can be a string, or any type of binary object.

Lets take a look at an example that will create a message, set its properties, and set its content. This will be everything that needs to be done to get the message ready to send.

Dim msgSent As MSMQMessage

Set msgSent = GetObjectContext().CreateInstance("MSMQ.MSMQMessage")

msgSent.Label = "My Message"

msgSent.Body = "Test message with acknowledgment."

msgSent.Ack = QMSG_ACKNOWLEDGMENT_FULL_RECEIVE

msgSent.MaxTimeToReceive = 60  

Set msgSent.AdminQueueInfo = qinfoAdmin

This will create a new message object and set its Label and Body. This message will send an acknowledgement when it is retrieved from its destination queue. This acknowledgement will be send to the qinfoAdmin queue. This parameter is a reference to an MSMQQueueInfo object that points to the acknowledgement queue. If the message is not retrieved within 60 seconds, it will be deleted from the destination queue, and a negative acknowledgement will be sent.

The last step in sending the message is to send it to its destination queue.

Send a Message

To send a message, you will need both a queue that is open for sending and a message object that has been properly configured. The Send method is actually a method of the message object, not the queue. The destination queue is passed as a parameter to the Send method. To send this message to the queue that we have already opened, you would:

msgSent.Send qInfo

The message is now on its way to its destination queue. Once it arrives there, it will wait for 60 seconds. If no application retrieves it within that time, it will delete itself from the queue.

Retrieving a Message

Now that there is a message sitting in this queue, we need to be able to retrieve it and use its contents in another application. There are two methods that can be used to retrieve messages from a queue:

Ø        A queue can be read synchronously, wherein all program execution will be blocked until a message is available in the queue, or a timeout value is reached.

Ø        A queue can also be read asynchronously, where a queue will fire events as messages arrive, and these events can be handled by the application.

In the web-based application world, the majority of message retrieval will be done using synchronous reads. While this sounds like it may adversely impact system performance, we can first check to see if there is a message waiting before we actually do the read.

In the previous examples, we sent the message to the queue with the label of 'Bill'. We can now use exactly the same steps as were used in steps 1 through 3 above, except now we will open the queue for read.

Dim query As MSMQQuery

Set query = GetObjectContext().CreateInstance("MSMQ.MSMQQuery")

Dim qinfos As MSMQQueueInfos

Dim qinfo As MSMQQueueInfo

Set qinfos = query.LookupQueue(Label:="Bill")

qinfos.Reset  

Set qinfo = qinfos.Next  

Do While Not qinfo Is Nothing

Set qinfo = qinfos.Next  

Loop

qInfo.Open(MQ_RECEIVE_ACCESS, MQ_DENY_NONE)

In the Open method, we specified that this queue will be used to retrieve messages. This mode will also allow us to peek at messages that may be waiting in the queue. To peek at a message in the queue, you would:

Dim msgDest as MSMQMessage

Set msgDest = qInfo.Peek(ReceiveTimeout:=100)

This will check to see if there are any messages in the queue. If after 100 milliseconds, or 1/10th of a second, there are no messages, then this method will return. To check to see if a message was found, you will check to see if msgDest properly references an object. If it is set to Nothing, then no message was waiting in the queue.

If a message is found in the queue, then it can be retrieved. There could be more than one message waiting in the queue. If there is, then the message that will be retrieved will be the first one in the queue. This is the message with the highest priority, or if more than one message has the same priority, then the one that has been in the queue the longest will be retrieved. To retrieve this message, you could use:

Set msgDest = qDest.Receive(ReceiveTimeout:=10)

This will put the contents of the message that was in the queue into the msgDest object. You can then get the information that this message contained by examining the contents of its body. Once you have read this message from the queue, you can close the queue. This will free up the resources used by the MSMQQueue object. The message object that you retrieved will still be valid, even after you close the queue. To close the queue, you could use:

qInfo.Close()

Sample MSMQ System

In this application, we will be using the PUBS database to hold the list of books that can be purchased. We will track orders and other information using MSMQ. This will allow us to route the appropriate information to the appropriate application. It allows gives us that MSMQ advantage of inter-application communication without both applications active at one time. At each step in the process, we will generate an MSMQ message based on information from the user (and possibly combined with information from the previous step as sent in another message) and send it to the appropriate queue. The next step will retrieve that information from the queue and perform its processing.

MSMQ from ASP Pages

Microsoft Message Queue Server provides a number of key benefits to developers because of its close integration with other Microsoft technologies. We have already touched on one key benefit, which is the integration of MSMQ and ActiveX. The use of the MSMQ ActiveX components allow any application development environment that supports ActiveX to use the features of message queuing in their applications. These development environments include Visual C++, Visual Basic, Visual J++, and VBScript hosts. It is this ability to use MSMQ from VBScript that allows for integration with Active Server Pages.

Integration with ASP

By using the ActiveX controls for accessing MSMQ, you can have your Active Server Pages applications use all of the features of message queuing. This is actually a very efficient way to deploy message queuing applications. Each of the clients that are accessing the application needs to only have a browser on their system. They do not need a copy of the MSMQ client, as the true MSMQ client is the ASP script itself.

The steps that an ASP application goes through to use MSMQ is pretty straightforward. As with any ASP application, the browser client makes a request to an Active Server Pages script file. Within this script file, there are calls to the MSMQ ActiveX objects. These objects can then be used to send or receive messages, manage queues, or monitor the status of queues. The information that these objects provide can then be displayed back on the client with a dynamically created HTML page.

Order Status ASP Page

As the orders flow through the system of queues that make up this application, it would be nice to have a way to view the status of all of the orders at once. To do this, we need to display information about the items in each of the queues in the application. This information could be retrieved at any time, and should not affect the contents of the queue when doing so.

Declare our variables

<%

    Option Explicit

    Dim query

    Set query = Server.CreateObject("MSMQ.MSMQQuery")

    Dim qinfos

    Dim qinfo

    Dim queue

    Dim msg

    Dim arQueues

    arQueues = Array("OrderReady", "PackingSlip", "PendingOrder", "OrderPicking")

    Dim strQueueName

Loop through the Queues

    Response.Write "<TABLE WIDTH="95%"><TR>"

    For Each strQueueName In arQueues

        Response.Write "<TD valign=top><TABLE BORDER=1><TR><TH>" & strQueueName & "</TH></TR>" & vbCrLf

       set qinfos = query.LookupQueue(,,strQueueName)

        qinfos.Reset

        Set qinfo = qinfos.Next

        If IsObject(qinfo) Then

Peek at the first message

             Set queue = qinfo.Open(MQ_PEEK_ACCESS, MQ_DENY_NONE)

             Set msg = queue.PeekCurrent(100, False, False)

             If msg Is Nothing Then

                 Response.Write "<TR><TD>Queue Empty</TD></TR>" & vbCrLf

             Else

                 Do While Not (msg Is Nothing)

Display its Label

                     Response.Write "<TR><TD>" & msg.Label & "</TD></TR>" & vbCrLf

Peek for the next message until done

                     Set msg = queue.PeekNext(50, False, False)

                 Loop

             End If

        End If

Move on to the next queue

        Response.Write "</TABLE></TD>" & vbCrLf

    Next

    Response.Write "</TR></TABLE>" & vbCrLf

%>

MSMQ VB Component Example

The Order Validation component is responsible for retrieving the orders from the PendingOrder queue and displaying them for the user. This component would be called from an ASP page that is used by associates responsible for the validation of orders that have been placed by customers. After the associate reviews and approves the order, the component is then responsible for passing the order information on. There are two branches in the next step in the order process. The order needs to be sent to the warehouse, so that the items in the order can be picked from stock. The order also needs to be sent to the shipping department so that a shipping manifest can be generated.

Option Explicit

Implements ObjectControl

Private oObjectContext As ObjectContext

Private Sub ObjectControl_Activate()

    Set oObjectContext = Nothing

End Sub

Private Function ObjectControl_CanBePooled() As Boolean

    ObjectControl_CanBePooled = True

End Function

Private Sub ObjectControl_Deactivate()

    Set oObjectContext = Nothing

End Sub

The components in this application will be MTS-aware components. To support MTS, we are going to implement the ObjectControl interface. This interface will be called by MTS when activating and deactivating the component. We will also keep a global reference to the current ObjectContext reference. To make sure that this reference is correct for each instance of the component, we will delete the reference whenever the component is activated or deactivated. This will ensure that in order to use the reference, the code in the component must retrieve it explicitly.

Private Function PostQueueMessage(strQueue As String, orderNum As Variant, strXML As Variant) As String

One action that we will need to carry out in multiple places in this component, as well as in other components in this example, is the sending of a message to a queue. We have taken the common code to do this and put it into a private function. The only specific pieces of information needed to use this function are the order number and XML data, as well as the name of the queue that we are sending the information to. These values are passed as parameters to this function

    Set oObjectContext = GetObjectContext()

    On Error GoTo errorPostQueueMessage

   

    Dim query As MSMQQuery

    Dim qinfos As MSMQQueueInfos

    Dim qinfo As MSMQQueueInfo

    Dim queue As MSMQQueue

    Dim msgOrder As MSMQMessage

    Set query = oObjectContext.CreateInstance("MSMQ.MSMQQuery")

    Set msgOrder = oObjectContext.CreateInstance("MSMQ.MSMQMessage")

       

Our next step is to send the order information as an MSMQ message to the appropriate message queue. In order to find this queue, we will need to find it first. Finding a queue requires the use of a series of MSMQ ActiveX objects. These are declared using the Dim statements. The majority of these objects will be returned as the result of other method calls. There are two objects that need to be explicitly created. The MSMQQuery and MSMQMessage objects are created by using the CreateInstance method of the ObjectContext. This is done so that these components, as well as any components that they create, will be created within the same context as our component.

    Set qinfos = query.LookupQueue(Label:=strQueue)

    qinfos.Reset

    Set qinfo = qinfos.Next

We need to locate the queue whose name matches the value stored in the strQueue variable. This is accomplished by using the LookupQueue method of the MSMQQuery object. Remember that this method returns a collection of MSMQQueueInfo objects, but the collection cannot be iterated through standard means. We need to reset the pointer to the first object in the queue with the Reset method, then retrieve a reference to it with the Next method.

    If Not IsObject(qinfo) Then

        PostQueueMessage = cQueueNotFound

        Exit Function

    End If

Rather than returning a true or false indicating success or failure, we will be returning descriptive strings to indicate what happened. The descriptive strings are actually stored as constants. These are stored in a module file, which is then included into all of the components in this application.

    Set queue = qinfo.Open(MQ_SEND_ACCESS, MQ_DENY_NONE)

   

    msgOrder.Label = CStr(orderNum)

    msgOrder.Body = strXML

    msgOrder.Send queue

   

    PostQueueMessage = cQueueOK

    Exit Function

errorPostQueueMessage:

    PostQueueMessage = cQueueError & " " & Err.Description

End Function

Once we have a valid queue, we can open it by using the Open method. This method will return a reference to a MSMQQueue object. Since we are adding messages to this queue, we want to open it with MQ_SEND_ACCESS. Since we also want to allow other users to add information to the queue, we are opening it with MQ_DENY_NONE access.

With the queue properly opened, we can now set to work with the message itself. We will need to set the label for the message, as well as the contents of its body. The message label will correspond to the order number for this order. The body will contain the XML information that was created earlier. Once the information in the message is set correctly, we can then send it to the queue that was opened earlier.

Public Function CreatePickSlip(xmlOrder As Variant, orderNum As Variant) As Variant

   

    CreatePickSlip = PostQueueMessage("OrderPicking", orderNum, xmlOrder)

  

End Function

Public Function CreatePackingSlip(xmlOrder As Variant, orderNum As Variant) As Variant

    

    CreatePackingSlip = PostQueueMessage("PackingSlip", orderNum, xmlOrder)

   

End Function

This component exposes two public methods that are used to transmit order information to various queues. The CreatePickSlip method will send the order information to the OrderPicking queue. The CreatePackingSlip method will send the order information to the PackingSlip queue. You can see that by using a helper function like PostQueueMessage makes these public methods very short and straightforward. It also means that if you want to change the mechanism by which you post messages to a queue, you can change it in one place, and have the changed automatically used by both methods.

Public Function PullNextOrder(ByRef strXML As Variant, ByRef orderNum As Variant) As Variant

    On Error GoTo errorPullNextOrder

   

    Set oObjectContext = GetObjectContext()

    Dim query As MSMQQuery

    Dim qinfos As MSMQQueueInfos

    Dim qinfo As MSMQQueueInfo

    Dim queue As MSMQQueue

The other public method of this component will retrieve an order from the PendingOrder queue and return it to the ASP page for processing. The value returned by the PullNextOrder method will be used to indicate the success or failure of the method. The information will actually be returned via the two parameters that are passed by reference. In passing by reference, the method receives a pointer to the actual data location, rather than a copy of the data. Any changes it makes to the data using this reference will be automatically reflected in the data in the calling application.

    Set query = oObjectContext.CreateInstance("MSMQ.MSMQQuery")

       

    Set qinfos = query.LookupQueue(Label:="PendingOrder")

    qinfos.Reset

    Set qinfo = qinfos.Next

   

    If Not IsObject(qinfo) Then

        PullNextOrder = cQueueError

        Exit Function

    End If

   

    Set queue = qinfo.Open(MQ_RECEIVE_ACCESS, MQ_DENY_NONE)

The first thing that we need to do is find the queue that we are interested in retrieving messages. The queue is located using the same steps as if we are going to send a message to it. The difference comes in the way that the queue is opened. Since we are going to be retrieving messages from the queue, we need to open it for receive access by passing the MQ_RECEIVE_ACCESS parameter.

    Dim msgDest As MSMQMessage

    Set msgDest = queue.Peek(ReceiveTimeout:=100, WantBody:=False)

    If msgDest Is Nothing Then

        PullNextOrder = cQueueEmpty

        Exit Function

    End If

Before trying to retrieve a message from the queue, we need to make sure that there is actually one there. This can be done by using the Peek method of the MSMQQueue object. When calling this method, we tell it how long we should look for a message in the queue. In this example, we have selected a 100-millisecond wait time. Depending on the load on your system, you may want this timeout to be longer or shorter.

Since all we are interested in is the presence of a message, we can set the WantBody parameter to false. This will speed up the Peek method, since it does not have to copy the contents of the message body back to our component. If the Peek message returns nothing, we know that the queue is empty. Given that, we return an error string to the calling application to indicate this.

    Set msgDest = queue.Receive(ReceiveTimeout:=10)

    orderNum = msgDest.Label

    strXML = msgDest.Body

   

    PullNextOrder = cQueueOK

    Exit Function

Now that we know that a message is waiting for us, we can retrieve it using the Receive method. Once the message is retrieved, we can pass the label of the message to variable for the order number and the body of the message to the variable for the XML information. After doing this, we can indicate that the message was successful by setting the cQueueOK value for the return and exiting the function.

errorPullNextOrder:

    PullNextOrder = cQueueError & Err.Description

End Function

Finally, we need to deal with any errors that occur in the processing of the method. We set up an error handler at the beginning of the method that directed any errors to this label. In this error handler, we will be passing more detailed information back to the calling application. We will be combining the cQueueError error string along with the Visual Basic error message that is contained in the Err.Description property.

---