Browse DevX
Sign up for e-mail newsletters from DevX


Automate MSMQ Object Creation : Page 2

By taking advantage of the functionality of two Microsoft Message Queuing libraries, you can minimize the time it takes to create MSMQ objects during testing or deployment of your messaging application. This article shows how to automatically create MSMQ objects using the Microsoft Message Queue 1.0 Object and the MSMQTriggerObjects 1.0 Type libraries. It starts by giving a brief overview of MSMQ objects and how they are traditionally created, then discusses a technique to automatically create these objects using the two Microsoft libraries.




Building the Right Environment to Support AI, Machine Learning and Deep Learning


In order to understand the relationship MSMQ objects have with one another, think of queues as objects, triggers as events and rules as methods.  When a message arrives in a queue that has an associated trigger, the trigger will fire.  If there is a rule bound to the trigger, that rule will be activated.  To illustrate, consider the following code for a textbox named Text1:

Private Sub Text1_Change()
  Text1.Text = UCase(Text1.Text)
End Sub

When the text property changes, the Change event fires and the UCase method is run.  In this example, a queue can be thought of as the Text1 object, a trigger as the Text1_Change event and a rule as the UCase method.

This example is further illustrated in Figure 1.  Client application A sends a message to a queue named MyQueue1 where the trigger named trgMyQueue1 fires.  This trigger has a rule bound to it named rulProcessMsg1, which invokes a COM component called MyComponent.  A method in the component performs some message processing and passes the message to a second queue called MyQueue2.  A second trigger fires and causes a rule to invoke the COM component once again.  The end result is that the converted message is passed to receiving Client Application B.


MSMQ queues, triggers and rules are typically created using the tools made available as a result of installing the MSMQ services.  If you are running under Windows NT 4.0, you will use the MSMQ Explorer.  For those of you using Windows 2000, Message Queuing appears under the MMC Computer Management snap-in Services and Applications node.  The Explorer-like interface of both tools makes it easy to add new queues, triggers and rules.  Normally you would begin by creating your queues.  These can be either public or private in scope.  If your computer is connected to a workgroup, you will be restricted to private queues.  Rules are created next and require information about the COM component or executable that will be launched when the rule is activated.  Triggers are created last since they logically are positioned between the queues and the rules.  When the trigger is created, it is associated with exactly one queue. One or more rules are then bound to the trigger.

Setting up your messaging environment is a snap if you only need to perform these tasks once.  However, if you are testing a design and are continually rebuilding MSMQ objects or are delegating this task to a user during installation of your software, this may seem a bit overwhelming, not to mention time-consuming.


Let’s take a different approach to MSMQ object creation by looking at two Microsoft Message Queuing libraries.  The Message Queue 1.0 Object Library is responsible for queue creation.  Triggers and rules are created using the MSMQTriggerObjects 1.0 Type Library.  Remember, until you install the Trigger Service, the MSMQTriggerObjects Type library will not be available.  For those of you running on Windows 2000, keep in mind that both versions 1.0 and 2.0 of the Message Queue Object Library are installed.  The earlier version is included for backward-compatibility with applications written on Windows NT 4.0 platforms.  For purposes of this discussion, we will limit the focus to the 1.0 version of the Message Queue Object Library.

To keep things simple, let’s create two queues, a trigger for each of the queues and one rule.  The sample code included with this article contains a file called queuelist.ini.  This file holds all of the information about the MSMQ objects we intend to create.  The ini file consists of two sections, Queues and Rules.  Beneath each section are keys, which identify properties of either a queue or a rule.  Below is a listing of the queuelist.ini file:


Description=MSMQ Trigger Rule - Process Message

The first thing you will notice is that there is no section for triggers.  Remember that for every queue, there can be only one trigger, so we can simply use the list of queues to create our triggers.  The layout of the Queues section is fairly straightforward.  For each queue that will be created, there is a key and the name of the queue.  Each key begins with an index and is incremented for every succeeding queue.

The Rules section on the other hand, requires a bit more information.  The first two items under the Rules section, Name and Description, identify the name and a brief description of the rule to be created.  The Condition property lists the conditions under which the rule will fire.  To enter multiple conditions, simply separate them by commas. In our example, we have only one condition that needs to be satisfied in order for the rule to fire:


If you were creating this rule using the MSMQ Explorer, the above statement would represent the selection Message Priority Equals in the Rules Properties dialog.

The table below contains a listing of rule conditional statements, as they would appear in MSMQ Explorer and the equivalent format to be used within the queuelist.ini file.

Rule Condition

Queuelist.ini Format

Message Label Contains $MSG_LABEL_CONTAINS
Message Label Does Not Contain $MSG_LABEL_DOES_NOT_CONTAIN
Message Body Contains $MSG_BODY_CONTAINS
Message Body Does Not Contain $MSG_BODY_DOES_NOT_CONTAIN
Message Priority Equals $MSG_PRIORITY_EQUALS
Message Priority Not Equal $MSG_PRIORITY_NOT_EQUAL
Message Priority Greater Than $MSG_PRIORITY_GREATER_THAN
Message Priority Less Than $MSG_PRIORITY_LESS_THAN
Message AppSpecific Equals $MSG_APPSPECIFIC_EQUALS
Message AppSpecific Not Equal $MSG_APPSPECIFIC_NOT_EQUAL
Message AppSpecific Greater Than $MSG_APPSPECIFIC_GREATER_THAN
Message AppSpecific Less Than $MSG_APPSPECIFIC_LESS_THAN
Message Source Machine ID Equals $MSG_SRCMACHINEID_EQUALS
Message Source Machine ID Not Equal $MSG_SRCMACHINEID_NOT_EQUAL

The Mode property indicates which type of application will launch when our rule is fired.  A rule can either invoke a COM component (Mode = COM) or start a standalone executable (Mode = EXE).  In our case, we will be invoking the COM component called MessageProcessor.CProcessMessage as identified by the ProgramID property.  If we were launching a standalone executable, the ProgramID would identify the full path of the executable file to be run.  If we were invoking an EXE, we could choose to display the window by setting the value of the ShowWindow property to either 0 (hide window) or 1 (show window).  The value of ShowWindow should always be set to zero when invoking COM components.  The Method property is used to identify the name of the method our rule will be calling of the invoked COM component.  In this case, we will be calling the ProcessMessage method of our COM component.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date