You are currently browsing the category archive for the ‘API’ category.

We’ve just brought out a new SupportPac that allows access to WebSphere MQ using HTTP: MA0Y: IBM WebSphere MQ Bridge For HTTP.

There is no client involved here – just connect using whatever method you like Ajax, C++, Java, anything that can make a socket connection and send HTTP! This makes it the first zero-footprint client to WMQ.

We’ve defined a bunch of HTTP headers that encapsulate the message headers and the body of the message is sent as the HTTP body.

The support enables three of the standard HTTP verbs:

  • GET – browse (get with browse) the currently highest message on the queue.
  • DELETE – delete (destructive get) the currently highest message on the queue or topic.
  • POST – post (put) a message to the queue or topic.

Read the rest of this entry »

Advertisements

Here are some simple sample applications for WebSphere MQ JMS that you may find useful. You may use them to verify your installation or to learn more about WebSphere MQ JMS semantics.

Both applications use client bindings rather than local bindings; and do not make use of JNDI for simplicity. They can be run as standalone J2SE/JSE programs.

Note: Applications need minor tweak in the config section and destination names according to your setup.

Author: Saket Rungta, wastedmonkeys.com

Read the rest of this entry »

Update (13/12/2007): The contents of this post have since been largely superseded by the release of PowerShell cmdlets for WebSphere MQ.

A better way to do filtering

A follow-on post from WebSphere MQ scripting using PowerShell – part 2

In hindsight, my approach to filtering was too restrictive (filtering by name only). Instead, it would be better for the function to just return queue objects, and let the user use the built-in functions to filter on them as they want.

Display objects…

  • Choose which attributes you want to be outputted
  • Apply filters – return queues whose parameter(s) match certain filters (supporting complex queries with AND and OR)
  • Sort by a parameter

And do this for local or remote queue managers.

I’m leaving Display-WMQQueues as it is, and have started a new function – Get-WMQQueues – to do this.

This is much much better:

PS-WMQ DALE >  Get-WMQQueues | Select Name, CurrentDepth

Name                                                   CurrentDepth
----                                                   ------------
SYSTEM.ADMIN.ACCOUNTING.QUEUE                                     0
SYSTEM.ADMIN.ACTIVITY.QUEUE                                       0
SYSTEM.ADMIN.CHANNEL.EVENT                                        0
SYSTEM.ADMIN.COMMAND.QUEUE                                        0
SYSTEM.ADMIN.LOGGER.EVENT                                         0
SYSTEM.ADMIN.PERFM.EVENT                                          0
SYSTEM.ADMIN.QMGR.EVENT                                           1
SYSTEM.ADMIN.STATISTICS.QUEUE                                     0
SYSTEM.ADMIN.TRACE.ROUTE.QUEUE                                    0
SYSTEM.AUTH.DATA.QUEUE                                           54
SYSTEM.CHANNEL.INITQ                                              0
SYSTEM.CHANNEL.SYNCQ                                              0
SYSTEM.CICS.INITIATION.QUEUE                                      0
SYSTEM.CLUSTER.COMMAND.QUEUE                                      0
SYSTEM.CLUSTER.REPOSITORY.QUEUE                                   1
SYSTEM.CLUSTER.TRANSMIT.QUEUE                                     0
SYSTEM.DEAD.LETTER.QUEUE                                          0
SYSTEM.DEFAULT.INITIATION.QUEUE                                   0
SYSTEM.DEFAULT.LOCAL.QUEUE                                        0
SYSTEM.PENDING.DATA.QUEUE                                         0
TINY_QUEUE                                                       12

.

PS-WMQ DALE >  Get-WMQQueues | Select Name, CurrentDepth | Where { $_.CurrentDepth -gt 0 }

Name                                                   CurrentDepth
----                                                   ------------
SYSTEM.ADMIN.QMGR.EVENT                                           1
SYSTEM.AUTH.DATA.QUEUE                                           54
SYSTEM.CLUSTER.REPOSITORY.QUEUE                                   1
TINY_QUEUE                                                       12

Read the rest of this entry »

I needed to write a small C WebSphere MQ app today which made MQGET calls in a number of places. In all of these, it was likely that the initial message buffer would be too small for the message, and would need to be able to handle MQRC_TRUNCATED_MSG_FAILED.

So, I wrote a quick common function wrapping MQGET, that would free the message buffer in these cases and allocate a bigger one (using the size indicated by the DataLength field returned – see the Application Programming Guide for more detail if you’ve not done this before).

It looked something like this:

 void MQGETwithGrowingBuffer(MQHCONN Hconn, MQHOBJ Hobj,          
                             PMQVOID pMsgDesc, PMQVOID pGetMsgOpts,   
                             PMQLONG BufferLength, PMQVOID* ppBuffer, 
                             PMQLONG pDataLength, 
                             PMQLONG pCompCode, PMQLONG pReason)
 {
     MQGET(Hconn, Hobj, pMsgDesc, pGetMsgOpts, 
           *BufferLength, *ppBuffer, pDataLength, 
           pCompCode, pReason);

     if(*pReason == MQRC_TRUNCATED_MSG_FAILED)
     {
         free(*ppBuffer);

         *BufferLength = *pDataLength;
         *ppBuffer = (char*) malloc(*pDataLength);

         MQGET(Hconn, Hobj, pMsgDesc, pGetMsgOpts, 
               *BufferLength, *ppBuffer, pDataLength, 
               pCompCode, pReason);
     }
 }

If you’re writing a C++ application, you can let WMQ handle this for you – automatic buffer management is an option in the WMQ C++ API. (When you do a ‘get’ call in C++ with automatic buffer management, the WMQ C++ libraries do something fairly similar to what I’ve done above – see Using C++ for a description).

But when wouldn’t this work?

Read the rest of this entry »

Refresh Pack 6.0.2.0 added some new plugins to the Eclipse-based WebSphere MQ Explorer. One of these is the “Tests plug-in”. The idea of the Tests plugin is to use the Eclipse ‘Problems View’ to display feedback about your WMQ configuration.

The “Tests plug-in” can itself be extended with user-written tests. This allows you to customize the WMQ Explorer so that it displays messages in response to any situation that you are interested in.

In this post, I’ll give a bit of background to the Tests plug-in, and walkthrough the steps involved in adding a new Test to the WMQ Explorer.

Read the rest of this entry »

Using IronPython and XMS .NET under-the-covers. Works like a charm for Point-to-point messaging and Publish/Subscribe messaging using WebSphere MQ.

And, you can change five lines and connect to WebSphere Platform Messaging (WebSphere Application Server, WebSphere ESB and WebSphere Process Server) or connect to WebSphere Brokers using the Real-time transport!

xmsconsumer xmsproducer

Read the rest of this entry »

Update (13/12/2007): The contents of this post have since been largely superseded by the release of PowerShell cmdlets for WebSphere MQ.

PowerShell is Microsoft’s new command line. Released last year, it introduced a number of enhancements over the traditional Windows Command Prompt, including a novel object-oriented approach.

I won’t go into the background about PowerShell – if you’re interested, a quick search will turn up masses of information, everything from detailed guides to the first impressions of obscure bloggers!

One of the more interesting features is the ability to access the .NET API – directly from the command line. So I thought it would be interesting to point out that with PowerShell, the .NET bindings available for WebSphere MQ means that you can interact with queue managers from the command line.

Read the rest of this entry »