ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General IBM MQ Support » Looking for ideas for sending messages via one QM to another

Post new topic  Reply to topic
 Looking for ideas for sending messages via one QM to another « View previous topic :: View next topic » 
Author Message
Lepiota
PostPosted: Sun Nov 27, 2016 8:58 pm    Post subject: Looking for ideas for sending messages via one QM to another Reply with quote

Newbie

Joined: 02 Jun 2015
Posts: 5

The specific question(s) are a bit lower down.

First some background:

For what I'd call "historical reasons" we've been using an "uncomfortable" WMQ topology, with one Queue Manager to which both our application and our small number (< 10) of external partners connect.

Our application uses WMQ client connections. Our partners connect with Server/Receiver channel pairs. We use Remote Queue Definitions to "address" our partners queues, and they do the same to address ours.

The networks connecting us to our partners are secure, and we have close business and IT relationships with them, so the technical risk is not quite as high as it sounds. OTOH it's definitely not a good setup, so we're going to start using two Queue Managers: a "gateway" QM and an "application" QM (see below for a little more info).

Initially we can't change any of the channel names to/from our partners, the queue manager name or queue names they use, nor the queue names our applications use. We'll be able to make such changes later, but we have make this "QM split" first.

We can't move to WMQ clustering in one step, though we'll almost certainly do this some time in the next 12 months.

Our current objective is to interact with our partners via a "Gateway Queue Manager" with the same name as the current one. Our applications will use a new QM with a new name. The "Gateway" won't have any "application" queues - it will only be used for routing. We think it's necessary that we "reuse" the current QM name as the Gateway QM - see the "more relevant details" list at the end.

We initially decided to route messages via Remote Queue Definitions for every (some in the Application QM, some in the Gateway QM). Depending on how you see it, this is quite a lot of new queue definitions, but we're reusing the names of existing queues, the definitions are all standardized, and there are under 100 queues at present, so it's practical.

On second thoughts it looks like the routing from our Application QM to our partners' QM's can be done using the current definitions almost unchanged: the existing RQD's can be reimplemented on the new "Application QM", but with the XMIT queue set to direct messages to the "Gateway QM". As i understand it, we can then use a QM Alias on the Gateway QM for each Partner QM to have WMQ route the message correctly for us.
This would save a lot of definitions, which would be nice.

Of course this got me thinking about doing the same thing in the other direction. My experience with QM Aliases (which was a while ago) was IIRC that we used them as explained in the paragraph above: to keep a Queue Name unchanged, but change the QM Name and have MQ automatically route the messages.
Used exactly like this, I don't see how to apply that approach to messages coming to our gateway from partners' QM's, since they have the name of the target QM (our Gateway QM) in their RQD, and hence their transmission header. On the other hand, this is a "many to one" case: so if I could use a QM Alias to change every incoming message from partner QMs to our application QM name I'd only need one QM Alias for all queues ....
... unless it also modified the QM Name for messages coming from our Application QM to the Gateway QM, in which case nothing would get to our partners.


So my questions:

1. Is the use of QM Aliases as described a couple of paragraphs above the best way to route from our Application QM, through the Gateway QM, to our (several) Partner QMs?

2. Could we achieve a similar result in the other direction (Partner QMs to Gateway QM to Application QM), where we map the actual QM name of the receiving QM (the Gateway) to the Application QM, but only for messages coming from Partner QMs (and never for messages coming from our Application QM)?

3. If we use normal RQD's (e.g. if the answer to (2) is "no"), is there anything we have to consider concerning recoverability if we get a technical problem (e.g. H/W failure of the machine the QM runs on)?
My understanding is that messages will arrive, get a new transmission header using the information in the RQD, be put to the outgoing XMIT Queue, and then confirmed back to the sending QM - i.e. no gap for messages to mysteriously disappear. But if the approach isn't reliable, we need a new plan :)


A few more relevant details:


    * This is a 24-hour system, but currently allows scheduled downtime for SysAdmin. That will change to real 24/365 with no windows for scheduled downtime (but probably not 99.99% availability) within the next 12-24 months
    * The WMQ Server(s) run on Intel hardware, Linux on VMWare software
    * There's failover capability in place (based on VMWare, a "SAN", and Network Appliances). Neither Multi-Instance QMs nor WMQ Clustering is in general use (yet), but later we will implement clustering so we have at least two active instances of each QM
    * There's one exception to "no clustering at all": we're in a WMQ cluster with one of our partners. This is a factor in why we're reluctant to change the "partner-visible" QM name
    * Our application has multiple server instances - about 20 connected to the queue manager
    * The application is completely reliant on WMQ, so even small changes have to be tested. It's not currently easy for us to schedule "end to end" testing, but this will improve after the "QM split"
    * We can't change the application interfaces (our own or our partners) easily or quickly. We're currently using WMQ Aliases for the application queues though
    * There's a moderately interesting non-technical background story here of course, but I can't share it.


Last edited by Lepiota on Mon Nov 28, 2016 1:47 am; edited 2 times in total
Back to top
View user's profile Send private message
smdavies99
PostPosted: Sun Nov 27, 2016 11:18 pm    Post subject: Reply with quote

Jedi Council

Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.

It really is IMHO time for you to do a POC and setup the new environment and look at the things for yourself. You will learn more about the whole thing in a shorter time than waiting for us to respond to your general questions.

So, do the POC and come back with specific questions about the issues etc you encounter.

I've done this myself and when I did it I really didn't have a clue but a few hours of trying and testing and searching for answers solved all the problems.
Just make sure that you use build scripts in your POC then when you get it wrong, you can stop and delete everything and build a new environment in a minute or so.

Then you can go further and look at how you would go on to use WMQ Clustering as the next phase.

go on, try it for yourself. MQ does not bite you know.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995

Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions.
Back to top
View user's profile Send private message
zpat
PostPosted: Sun Nov 27, 2016 11:37 pm    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
Location: UK

First thing to do is use a low authority id for the MCAUSER of the external receiver channels. Make sure this id can only access relevant queues.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General IBM MQ Support » Looking for ideas for sending messages via one QM to another
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.