Browse DevX
Sign up for e-mail newsletters from DevX


Automate MSMQ Object Creation : Page 3

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

Finally, if desired, parameters can be passed to the method of our COM component by setting the value of the Parameters property.  Table 2 contains a listing of Rule parameter statements and the equivalent format to be used within the queuelist.ini file.  In our example, we are passing the Message Queue Pathname to the ProcessMessage method of the MessageProcessor.CProcessMessage component as:


Use commas to separate multiple parameter values just as was done with rule condition values.  Keep in mind however, the order in which you pass the parameters is the order they will be received by the method of your COM component.  It is also important to pay attention to the data type of the parameter being passed.  For example, two parameters can be used to return message body data, $MSG_BODY and $MSG_BODY_AS_STRING.  The first returns the message body information as a variant and the second as a string.  As subtle as this is, it is an important point to keep in mind.


Rule Parameter

Queuelist.ini Format

Data Type

Message ID $MSG_ID Variant
Message Label $MSG_LABEL String
Message Body as Variant $MSG_BODY Variant
Message Body as String $MSG_BODY_AS_STRING String
Message Priority $MSG_PRIORITY Number
Message Correlation ID $MSG_CORRELATION_ID Variant
Queue Path Name $MSG_QUEUE_PATHNAME String
Queue Format Name $MSG_QUEUE_FORMATNAME String
Response Queue Format Name $MSG_RESPONSE_QUEUE_FORMATNAME String
Admin Queue Format Name $MSG_ADMIN_QUEUE_FORMATNAME String
Message App Specific Number $MSG_APPSPECIFIC Integer
Message Sent Time $MSG_SENTTIME Variant (date)
Message Arrived Time $MSG_ARRIVEDTIME Variant (date)
Message Source Machine $MSG_SRCMACHINEID String
Trigger Name $TRIGGER_NAME String
Trigger ID $TRIGGER_ID String


The sample code provided with this article will create and remove MSMQ objects defined in the queuelist.ini file.  Queues are created first, followed by our rule and the triggers.  Finally the rule is bound to the triggers to tie everything together.  Begin by creating an instance of the MSMQ.MSMQQueueInfo class.  All we need to do to create the queue is set pathname property and call the Create method of the MSMQQueueInfo object:

oQueueInfo.PathName = ".\Private$\MyQueue1" 

On Error Goto Next
On Error Goto 0

The Pathname property is actually a composite of three items, the name of the computer on which the queue is to be created, the scope and the name of the queue.  The local computer name is abbreviated by using the period character.  If a queue is being referenced on a computer other than the local machine, the computer name needs to be explicitly referenced.  For example, assuming that the name of the local computer is named MyServer, we could have easily created the queue follows:

oQueueInfo.PathName = "MyServer\Private$\MyQueue1"

Queues may either be public or private in scope.  The queue we are creating is a private queue.  If we were creating a public queue, we would have eliminated "Private$\" from the Pathname.  Finally, note that error handling is disabled when creating the queue to prevent an error if the queue already exists.

Rules are created by setting an object reference to the MSMQRuleSet class of the MSMQTriggerObjects Type library.  Start by initializing the RuleSet object with the name of the computer where the rule will be created:

oRule.Init "MyServer"

The rule is then created by calling the Add method of the RuleSet object.  Each rule is assigned a unique ID when it is created.  This ID, which is returned as a parameter of the Add method, is used when attaching a rule to a trigger.

With udtRuleDef
Rule.Add .Name, .Description, .Condition, .Action, _
    .ImplementationID, .ShowWindow, .RuleID
End With

In order to simplify things, I have created a user-defined-type to hold all of the rule properties.  A procedure called LoadRuleProperties is responsible for formatting and populating the UDT properties.  Most of the properties are simply read directly from the values in the ini file.  The Action parameter of the UDT is unique since it consists of the Mode, ProgramID, Method and Parameter ini values.  Special formatting is neccessary to prepare these values for the MSMQRuleSet.Add method. Study this routine and you will have a good idea how the RuleSet Add method parameters are formatted.

It is a good idea to check if a rule already exists before attempting to add it.  As indicated earlier, rules may be identified by their unique ID.  If you create two rules with the same name, you will get just that, two distinct rules with the same name.  Since it is easier to remember the rule by name rather than its ID, check if the rule exists using its name.  I have created a routine called IsRuleNameUnique to perform this task for you.

Finally, we can create the triggers.  Creating triggers is similar to creating rules.  An object reference is set to the MSMQTriggerSet class, properties are initialized and the trigger is added.  However, there is an additional step required when creating a trigger - attaching a rule.  Existing rules may be attached to a trigger by calling the AttachRule method of the TriggerSet object. 

oTrigger.Init "MyServer"

With udtTrigDef
Trigger.AddTrigger .Name, .Queue, .SystemQueue, _
    .Enabled, .Serialized, .TriggerID 
  oTrigger.AttachRule .TriggerID, RuleID, 0
End With

Again, a UDT is used to help manage the initialization of the trigger properties.  Just as when the rule was created, an ID is returned when the trigger is created.  This trigger ID uniquely identifies the trigger and is used in conjunction with the rule ID to attach a rule to the trigger.  The last parameter of the AttachRule method indicates the priority of the rule.  Think of this as the position in a list.  A priority of zero indicates the top-most rule in the list and would be activated first when the trigger is fired.


The sample code for this article will create a pair of queues and triggers and one rule. Load and run the project in the Visual Basic IDE to see how easy it is to create MSMQ objects using the techniques outlined in this article.  Click on the Create Queues button on the sample code form to create the MSMQ objects.  After doing so, open MSMQ Explorer to view them.  You can easily delete the objects by clicking the Delete Queues button.

Keep in mind that Microsoft Message Queuing and the MSMQ Triggers Service must be installed and running on your system in order for the code to function properly. Remember, you will get the same results if you create your MSMQ objects manually using the MSMQ Explorer. However, by taking advantage of functionality that is inherent to MSMQ, you can greatly improve the speed and reliability at which you create your MSMQ objects.

Marc Mueller works full-time as a senior consultant for marchFIRST in Charlotte, NC. Marc holds an MCSD, MCSE and is working towards his MCDBA. Reach Marc at marc.mueller@marchfirst.com.
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