Integrating MagooClient with WebSphereMQ (1)
Introduction
MagooClient offers a choice of transports for connecting to WebSphereMQ. Connection can either be made using the native Base classes or alternatively via the JMS/JNDI model. The native transport only caters for Queues whereas the JMS approach faciliates connection to Queues or Topics but does require the extra administrative overhead of setting up JNDI based on a File System Context Provider. The following blueprint works through both scenarios
Setup
Due to licensing restrictions, the required IBM MQ client JAR files cannot be shipped with MagooClient. Therefore it is necessary to have them available on the installation machine before attempting to configure an MQ transport. The JARs are typically located in the java/lib directory of a WebSphereMQ installation. Transports are configured by selecting the Transports... menu entry in the Configure menu of MagooClient or the Transports tab in the MagooServer Console.
Using the Native Transport
The configuration dialog for WebSphereMQ Native transport on a host named PARSIFAL is shown below - this can either be the local host or a remote WebSphere MQ server. This example uses the default MQ settings for the port, QueueManager and Channel based on that hostname. All that needs to be supplied is the physical Queue name postcard on which the transport is to listen. The postcard queue is automatically setup by WebSphereMQ for demonstration purposes so no additional WebSphereMQ administration is required.
Sending a Message
Once the transport has been configured, an XML message can be sent to validate correct operation. To create a message, select the New from File... from the Message menu in the main MagooClient window. In this case a sample FpML message is used - the FpML schema has been registed in the Message Type Catalog so that messages can be automatically validated (edit/send/receive) against it.
To put the message on a native WebSphere MQ queue use the destination format webspheremq:<queue_name>. Therefore on the To: line enter the destination websphere:postcard and click on Send. The message will be put on the postcard queue. As the Native Queue postcard transport is listening on queue postcard, it will pick up the message from the queue, automatically apply validation, and it should then immediately appear in the inbox:
Note that when sending using the native tranport, the queue name entered on the To: line must be that of a physical queue for the configured QueueManager. This means that if no physical queue exists then an error condition will occur and the message will remain in the outbox. For example, if an attempt is made to send to a non-existent queue e.g. destination webspheremq:notthere then the message should be visible in the outbox as follows:
The WebSphereMQ Native Queue postcard transport will flag an error condition and will continue to attempt a re-send of the message every 60 seconds pending availability of a queue matching that specified on sending (notthere). This can be checked via the transport log:
