Testing the MSMQ-MQSeries Bridge Setup

A number of test tools are supplied with the MSMQ-MQSeries bridge. These tools help validate the setup of the bridge and are run from the command line. You'll use these tools to first validate the MSMQ to WebSphere MQ bridging options, and then to validate the reverse.

Testing MSMQ to WebSphere MQ Connectivity

To test while still within a command prompt on the bridge server, run the following command:

 MQSRRECV STQM LOCAL.STOCKPURCHASES 

This tool actively listens to incoming queue messages on the WebSphere MQ server. The parameters specify the name of the queue manager and the local queue name . This tool and the others you'll use for testing in this section can be found in the C:\Program Files\Host Integration Server\System directory, in case this directory isn't on the System PATH .

If successful, the following message should be displayed:

 Use <CTL-C> to stop ! 

If you don't receive this message, check that the channel definitions and scripts have been configured as outlined in this chapter. Also, ensure that the WebSphere MQ server is up and running and that the queue manager has been started.

If this is successful, open the MSMQ-MQSeries Bridge Manager. If not already running, start the service by right-clicking the Bridge Service and selecting Start. Do the same for the CN (WMQ_CN) site. Ensure that the two message pipes (MQS->MSMQ and MSMQ->MQS) are started. This is indicated with a green "play button" icon next to the service, as shown in Figure 10.21.

Figure 10.21: The two message pipes running within the MSMQ- MQSeries Bridge Manager.

Now that the test tool is listening for incoming messages on the queue, open another command prompt window. From there, type the following command:

 MSMQSEND STQM\LOCAL.STOCKPURCHASES 

This will send 10 test messages with the same name to the MSMQ queue. The following should be displayed in this window. (Note that the time information will be different.)

 Test Message 0  20:18:02 Test Message 1  20:18:02 Test Message 2  20:18:02 Test Message 3  20:18:02 Test Message 4  20:18:02 Test Message 5  20:18:02 Test Message 6  20:18:02 Test Message 7  20:18:02 Test Message 8  20:18:02 Test Message 9  20:18:02 

Now switch to the other command prompt window running the MQSRRECV command. If the bridge was able to successfully route these messages, this same text will appear in this window too.

Testing WebSphere MQ to MSMQ Connectivity

To reverse the test (sending from WebSphere MQ to MSMQ), perform the following steps. Stop the MQSRRECV command by pressing CTRL+C. In this window, type the following command, replacing MQBRIDGE1 with the name of your bridge server:

 MSMQRECV MQBRIDGE1\LOCAL.STOCKSALES 

This will enable your machine to listen to the incoming MSMQ queue. Now switch to the other command prompt window (used to send the messages earlier) and type:

 MQSRSEND STQM STQM LOCAL.STOCKSALES 

If all is successful, the test should now display messages that have been transferred the other way, such as these:

 Test Message 0  20:23:15 Test Message 1  20:23:15 Test Message 2  20:23:15 Test Message 3  20:23:15 Test Message 4  20:23:15 Test Message 5  20:23:15 Test Message 6  20:23:15 Test Message 7  20:23:15 Test Message 8  20:23:15 Test Message 9  20:23:15 

If the tests are unsuccessful , revisit the setup instructions to validate that you performed them correctly. The MSMQ-MQSeries bridge contains a tracing tool that can be used to debug messages that aren't correctly sent between the two queuing products and writes numerous events to the Event Log. Tracing can be enabled by using the Trace Initiator and Trace Viewer, two tools in the Applications And Tools folder of the Host Integration Server 2000 Programs Group.

If these tests are successful, congratulations are in order! The bridge is now fully configured to route messages. Before proceeding, stop the MSMQRECV process by pressing CTRL+C in the appropriate command prompt window.

Testing the Bridge with Previous Code Samples

To further show how the MSMQ-MQSeries bridge works, you can take the code samples shown in Chapters 8 and 9 and apply them to this setup. This will show how a client using the Microsoft .NET Messaging namespace ( System.Messaging ) and a client using IBM's libraries for Java can be used to exchange messages.

The sample code to show this can be found in the C:\Interoperability\Samples\Resource\MSMQBridge directory. This directory contains two subdirectories, dotNET and Java.

In the .NET client, notice how the queues are configured by using the queues available in Active Directory. (Also, note that you'll have to modify the code to replace all instances of example server names with the names of the servers in your actual setup.)

 MessageQueue purchasesMQ      = new MessageQueue(@"STQM\LOCAL.STOCKPURCHASES"); MessageQueue salesMQ      = new MessageQueue(@"MQBRIDGE1\LOCAL.STOCKSALES"); 

Because this code references queues in Active Directory, the client machine that runs this sample should also reside within Active Directory. To facilitate this, these tests can be run on the bridge.

For the Java client, a number of properties are configured to reference the queue on the WMQ1 server, as shown here. (Again, you'll need to change this name to the corresponding server name in your setup.)

 String hostName = "WMQ1"; int port = 1414; String channel = "SYSTEM.DEF.SVRCONN"; String qmName = "STQM"; String purchasesQName = "LOCAL.STOCKPURCHASES";   String salesQName = "LOCAL.STOCKSALES";   Hashtable props = new Hashtable(); props.put(MQC.HOST_NAME_PROPERTY,hostName); props.put(MQC.PORT_PROPERTY,new Integer(port)); props.put(MQC.CHANNEL_PROPERTY,channel); 

If you're accessing the queue remotely (and not running the sample code on the WebSphere MQ box), ensure that the WebSphere MQ client is installed on the client machine.

Build and run the .NET client sample code. Enter nant at a command prompt within the dotNET subdirectory to build the sample, and enter client to run it. Upon running, the .NET client will display the following:

 Test message has been placed on the purchases queue. This should be bridged to Websphere MQ 

The .NET client places a message on the local purchases queue, which uses MSMQ and will then pause. The MSMQ-MQSeries bridge delivers this message to the corresponding queue on the WebSphere MQ server. Now run the Java client in a separate command prompt window. Enter ant run at a command prompt within the Java subdirectory to build and run the Java client. If successful, you should notice a number of operations.

Note

When running the sample code, if an error is generated with reason code 2009 (or if the Java client hangs when opening the connection to the queue), create a system environment variable named MQNOREMPOOL on the client and set the value to 1. This is a known TCP channel bug with JDK 1.4.1 and the WebSphere MQ client.

First, the Java client places a new message on the local sales queue, which uses WebSphere MQ:

 Test message has been placed on the sales queue. This should be bridged to MSMQ 

The MSMQ-MQSeries bridge will take this message and deliver it to the corresponding MSMQ queue.

Next, the Java client picks up the message that has been delivered by the bridge from the .NET client:

 Message delivered by MSMQ-MQSeries Bridge: <?xml version="1.0"?> <string>     This is a test purchase, sent using a .NET System.Messaging client! </string> 

Notice how the message is encapsulated in an XML document. We'll get to the reasoning behind this shortly.

Before we do, switch back to the command prompt window that's running the .NET client. You should observe that the message that was sent by the Java client has been picked up (by the bridge moving it from the WebSphere MQ queue to MSMQ):

 Message delivered by MSMQ-MQSeries Bridge: This is a test sale, sent using a Websphere MQ client! 

As shown, the test sale sent by the Java client was successfully received.

So, why the XML? Recall that in Chapter 8 you saw how the System.Messaging namespace was used by a .NET client to send a message to an instance of MSMQ. You might remember how messages sent to an MSMQ queue can be formatted either with an XML formatter or a binary formatter ”similar to the formatting options available in Microsoft .NET Remoting.

With this example, we also must choose one of these options to send the message across the MSMQ-MQSeries bridge. Because there's no binary formatter on the Java 2 platform that's compatible ”see Chapter 3, "Exchanging Data Between .NET and Java," for more details ”the XML formatter is used. By specifying this formatter, the text string message that the .NET client sends is serialized into an XML document, which is the result displayed when the Java client reads the message.

For returning a message in an equivalent XML format, the Java client uses the following line:

 msg.writeString("<?xml version=\"1.0\"?><string>This is a test sale,"     +"sent using a Websphere MQ client!</string>"); 

As you can see, the string message is simply contained within an XML document.

Although this is fine for our test string message, in a production environment you'll want to avoid constructing your own XML documents in strings. One way for the Java client to create messages that the .NET client can understand is to use the XML serialization techniques, as discussed in Chapter 3. Because the .NET client is using the XmlSerializer classes to construct messages, the XML classes within the GLUE toolkit allow the messages to be deserialized to objects that the Java platform can understand. When sending messages back to the .NET client, the same libraries can be used to construct an XML document in the correct format.