One of the first things I wanted to do with my new IBM Cloud Queue Manager was to make channels to/from another queue manager on my own machine. Here are some tips that I learned from doing that. Screenshots below show the MQ Console making MQ objects, but of course you can also use all your favourite tools to manage your IBM Cloud queue manager.
Inbound Channel to an IBM Cloud Queue Manager
So I defined a sender channel and transmission queue on the queue manager on my own machine, thus:-
DEFINE CHANNEL(MORAG.TO.MQG1) CHLTYPE(SDR) TRPTYPE(TCP) + CONNAME('mqg1-xxxx.qm.beta.mqcloud.ibm.com(nnnnn)') + XMITQ(MQG1) DEFINE QLOCAL(MQG1) USAGE(XMITQ)
And defined a receiver channel on my IBM Cloud queue manager, thus:-
Starting the sender channel on my own machine, targeting my IBM Cloud queue manager failed with:-
AMQ9558: The remote channel 'MORAG.TO.MQG1' .. is not currently available.
Turns out you also need to allow this receiver channel through CHLAUTH. IBM Cloud queue managers come with a back-stop rule already in place, unlike any queue manager you have created yourself using crtmqm. Once you know this, it is a simple matter to get the channel running.
I created a CHLAUTH rule on my IBM Cloud queue manager. I chose to make a Queue Manager Map and not to put an Address filter on it because of all the network translation that goes on between you and your IBM Cloud queue manager. Perhaps later I’ll look into the address the queue manager thinks I’m connecting in from to add an Address filter to my inbound check.
And then my inbound channel was able to run successfully
Outbound channel from an IBM Cloud Queue Manager
If you have an external IP address for your own machine then you should be able to just plug it into the CONNAME of a sender channel on your IBM Cloud queue manager and get going as you might expect.
If you’re trying this out from home, you may well be behind a router, and using the ipconfig command (or equivalent) will only tell you the IP address assigned to your machine internally, e.g. if it’s a 192.168.* address it’s an internal private address and external connections such as the channels coming out from your IBM Cloud queue manager cannot see it.
One way around this is to use a VPN – if you have one for dialing into work when you are working from home that may well be enough. If you run it and then try the ipconfig command (or equivalent) again, you’ll see that you now have an external IP address. It’s likely that your IBM Cloud queue manager can see that address.
Without a VPN
One of the reasons I decided to write this part of the blog post, is that I think IBM Cloud queue managers may mean that more people are trying to connect between them and a ‘home’ address. Trying out MQ in the cloud is free at the moment, and may well encourage lots of people to try it out.
If you don’t have a VPN, and you are behind a router with a 192.168.* address, you do still have an external IP address, and you can find out what it is by asking google (or using a variety of other websites that will also be listed by this search).
If using your external IP address and queue manager’s port number still don’t work, this is likely because you are behind a router that doesn’t know what to do with this inbound connection. It doesn’t know to send it to your computer rather than any other computer on the internal private network.
You’re better off to have a static IP address for your machine when doing the following to save you having to continually make changes to this configuration every time the DHCP server gives you a new IP address, but it is not absolutely essential. My internal IP address in the following examples is 192.168.1.113. You need to configure your router to tell it where to send connections that come in on the port in question, in the following examples, my queue manager is listening on port 2222.
All routers are different, but you’ll find some kind of section, probably in an advanced setup section, that mentions NAT Forwarding. In that section look for something like Virtual Servers, and then add in configuration that tells the router when it sees traffic on your external IP address and the port your queue manager is listening (2222 in my example), to send that on to the machine with internal IP address 192.168.1.113. You can change the port number at the same time, but I’ve kept it simple and used the same port internally and externally.
Now when I start my sender channel from my IBM Cloud queue manager to the queue manager on my own machine, it connects successfully.
Since you’ve opened up a port to the outside world to get your channel running into your own machine from the IBM Cloud, you’ll now be able to see the IP address it comes in from. You may want to add an IP address filter with a CHLAUTH rule so that only your cloud queue manager can make that connection.
The next thing I’d like to see from the MQ on IBM Cloud team is how to use SSL/TLS on my channels.