| Author |
Message
|
| fatherjack |
 Posted: Tue Jun 22, 2010 1:28 pm Post subject: Re: channel exits for content-based routing |
 |
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
You never did answer Vitor's question...
| Vitor wrote: |
| Given where a channel exit runs & what it can do, what makes you think it's possible to route messages with one? How (in an ideal world) would your exit work? |
Because isn't the answer to this the real reason why you wouldn't use an exit to do message routing?
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
 |
| RogerLacroix |
| Posted: Tue Jun 22, 2010 3:24 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
| warelock wrote: |
| Our business goal is to route messages to different queues depending on the content of the message. We don't want to use MQSI, and we do want to do this with MQ facilities. However, we are not blindly commited to doing this with channel exits - other approaches would be great ! |
| bruce2359 wrote: |
| Alter your queue definitions so that all (relevant) messages end up on a local queue called get_and_reroute. Write an application that gets each message, determines where the message should really go, mqput it to the queue where it belongs. |
Warelock, please have a look at the free open source project called: Message Router (MRTR).
http://www.capitalware.biz/mrtr_overview.html
It is free and its purpose is to route messages based on message content.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| warelock |
| Posted: Wed Jun 23, 2010 6:13 am Post subject: Re: channel exits for content-based routing |
|
|
Novice
Joined: 18 Jun 2010
Posts: 19
|
| fatherjack wrote: |
You never did answer Vitor's question...
| Vitor wrote: |
| Given where a channel exit runs & what it can do, what makes you think it's possible to route messages with one? How (in an ideal world) would your exit work? |
Because isn't the answer to this the real reason why you wouldn't use an exit to do message routing? |
LOL
My original question was whether this was possible. I did not at the time have an opinion about this ... or I would not have raised the question 
It turns out that this IS possible; we've been able to write this code in a channel exit (MSGEXIT). Whether it performs well and can be made reliable enough for production is something we'll have to look into now. I'll update this thread when we know more.
Thansk for all the responses guys !! |
|
| Back to top |
|
|
| warelock |
| Posted: Wed Jun 23, 2010 6:29 am Post subject: |
|
|
Novice
Joined: 18 Jun 2010
Posts: 19
|
| RogerLacroix wrote: |
| warelock wrote: |
| Our business goal is to route messages to different queues depending on the content of the message. We don't want to use MQSI, and we do want to do this with MQ facilities. However, we are not blindly commited to doing this with channel exits - other approaches would be great ! |
| bruce2359 wrote: |
| Alter your queue definitions so that all (relevant) messages end up on a local queue called get_and_reroute. Write an application that gets each message, determines where the message should really go, mqput it to the queue where it belongs. |
Warelock, please have a look at the free open source project called: Message Router (MRTR).
http://www.capitalware.biz/mrtr_overview.html
It is free and its purpose is to route messages based on message content.
Regards,
Roger Lacroix
Capitalware Inc. |
Thanks, Roger ! We will take a look. I see that you also have a Yearly Enterprise Support Subscription License, which is important for my company. |
|
| Back to top |
|
|
| fatherjack |
| Posted: Thu Jun 24, 2010 1:25 am Post subject: Re: channel exits for content-based routing |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| warelock wrote: |
| we've been able to write this code in a channel exit (MSGEXIT). |
Out of interest, just at a high level, what does your exit do?
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Thu Jun 24, 2010 4:07 pm Post subject: Re: channel exits for content-based routing |
|
|
Jedi
Joined: 25 Mar 2003
Posts: 2494
Location: Melbourne, Australia
|
| fatherjack wrote: |
| warelock wrote: |
| we've been able to write this code in a channel exit (MSGEXIT). |
Out of interest, just at a high level, what does your exit do? |
And how does it robustly handle error detection, recovery and transaction integrity? Who will be supporting the code in 5 or 10 years time?
_________________
Glenn |
|
| Back to top |
|
|
| warelock |
| Posted: Thu Jun 24, 2010 5:44 pm Post subject: Re: channel exits for content-based routing |
|
|
Novice
Joined: 18 Jun 2010
Posts: 19
|
| fatherjack wrote: |
| warelock wrote: |
| we've been able to write this code in a channel exit (MSGEXIT). |
Out of interest, just at a high level, what does your exit do? |
It parses the message payload data to extract a string of chars that dictate the desztination queue, then sets RemoteQName in the header to the appropriate queue. This seems to work, but since it is a first attempt we are mistrustrful of the error handling and robustness in general ... still, one must start somewhere, I suppose ! |
|
| Back to top |
|
|
| warelock |
| Posted: Thu Jun 24, 2010 5:57 pm Post subject: Re: channel exits for content-based routing |
|
|
Novice
Joined: 18 Jun 2010
Posts: 19
|
| gbaddeley wrote: |
| fatherjack wrote: |
| warelock wrote: |
| we've been able to write this code in a channel exit (MSGEXIT). |
Out of interest, just at a high level, what does your exit do? |
And how does it robustly handle error detection, recovery and transaction integrity? Who will be supporting the code in 5 or 10 years time? |
LOL that remains to be seen - I imagine we will learn from experience in these areas. I am hoping to get advice in this forum as well.
Indeed, it would not be bad if I were supporting the code in 10 years' time. Possibly the product will have changed beyond recognition by then ... I believe MQ 7 already has great improvements in this area. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jun 24, 2010 8:11 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| I believe MQ 7 already has great improvements in this area. |
Channel exits behaviors are completely and absolutely the responsibility of the exit developer.
I'm still puzzled (amazed, perplexed) that your organization has the Message Broker, yet doesn't want to use it for one of its major purposes - intelligent message routing.
Are you going to use the exit for all your channels? What will you do when the code inevitably fails (and kills the channel)?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Thu Jun 24, 2010 10:35 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
Its all about channel exit vs. an application solution.
All questions, that you raise here related to the channel exit (integrity, who will support in 10 years and so on) can be asked for the application program or a broker solution too.
I agree writhing a channel exit is more complex then a simple mqget - mqput application.
however, IMHO the exit has some advantages
- if you receive messages from different sources, which are destigned for different queues (which names you may or may not know) then the exit eliminates the need of putting these messages to one or more known queues for routing by application. the exit does not care about the original target queue, it puts in its own target.
- the exit does not have to care about putting errors. If any problem, the "standard" channel mechanisms will take care (e.g. putting message to DLQ, or stopping channel if message can not be delivered). If you write an application, you have to perform all that error handling on your own.
- changing an XHQ field in an exit depending on the message data is not very complex. although i agree the exit must be written properly .
- IMHO a broker solution is more complex, expensive, requires more skills then a channel message exit.
I do not like application work to be done in exits. I would still prefer the application routing version. i just want to point out that - depending on the situation - there are advantages for an exit solution too.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| fatherjack |
| Posted: Fri Jun 25, 2010 12:16 am Post subject: Re: channel exits for content-based routing |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| warelock wrote: |
| It parses the message payload data to extract a string of chars that dictate the desztination queue, then sets RemoteQName in the header to the appropriate queue. |
And if the destination queue is on a different queue manager?
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Fri Jun 25, 2010 12:58 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
i dont understand the question. for me it makes no difference. the exit can modify the queue name or leave it. the new target may apply to a local defined qlocal ueue, to a local definition of a remote queue or to a remote queue (in that case the qmgr must be known). that thats the same in every case, with or without exit.
there are may "and if" questions. as i wrote before, it depends on the situation. ... and in some situations i would use that exit solution. in some not.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jun 25, 2010 5:28 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
Exit or other solution. It's a choice.
Occam's Razor is at work here.
The OP offered an exit as the solution - apparently to the exclusion of all others. Of course, it was the OPs management that limited the choice of solution. This is one of the never-ending issues of those ill-equipped to make technical decisions making them anyway.
The simplest solution is one that (among other attributes) can be developed by the largest potential audience. Here, I'm thinking C programmers, with the least knowledge of WMQ internals - just the basic MQI calls. A simple C (or COBOL) app could write a get and filter application based on business rules. App failure would not affect channel operation, but might delay delivery of messages.
At the other end of the Razor would be an exit program, requiring extensive internals knowledge. Exit code failure could/would have broader impact.
WMB is a choice, requiring different skills - but more available than mq-internal skills.
I'm always leaning toward the keep-it-simple solution - until someone can demonstrate that something complicated (or very technical) is a better choice.
What technical requirements, if any, are there? Is it cost? Are you decommissioning WMB? Is throughput (speed) the issue?
Selecting an exit is NOT a requirement; rather, it is (apparently) the solution of choice here.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jun 25, 2010 6:11 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The main reason I run in terror anyone ever says "let's write a channel exit to do this" is that a channel exit can do wonderful things like abend the MCA if written poorly.
Or even worse, silently drop messages. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jun 25, 2010 6:15 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
Better to kill a channel (or all of them) from within a channel exit, than to have a plain-old batch application that accomplishes the same task.
When asked (by clients) about writing exits, I ask them how is your risk toleration?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
