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 IndexChallenge ForumChallenge Question - 08 / 2008

This forum is locked: you cannot post, reply to, or edit topics.This topic is locked: you cannot edit posts or make replies. Goto page 1, 2  Next
Challenge Question - 08 / 2008 View previous topic :: View next topic
Author Message
Challenger
PostPosted: Fri Aug 01, 2008 2:12 am Post subject: Challenge Question - 08 / 2008 Reply with quote

Centurion

Joined: 31 Mar 2008
Posts: 115

The August Challenger is taking a new approach presenting his challenge!

As with most everybody, the company you work for is running a mixture of old and new applications, some purchased, some homegrown. For a few you have access to the source code, for most of them you don’t.

The company has several hundreds retail stores of it’s own, also an important number of independent agents who sell; plus since a few years orders can also be placed via the website, and just since last month, the new “mobile” application went live where customers can simply enter their orders from their mobile phone. All order requests ultimately end up on a single MQ 6.x queue on some back-end big server machine where the inventory is checked, and the order quantity is (temporarily) reserved if stock is adequate, or backordered and/or rejected if not…


Early this morning, the business manager comes into your office and says: “Wouldn’t it be great if we could favor orders from our premium customers”?

“Hmmm”, you say, “what do you mean”?


“Well”, says the business guy (who strangely enough seems quite versed in MQ), “we have these orders coming in from all these places, and if we could ensure that our most “beloved ones” always end up first on the reservation queue, their chance of getting a confirmation will increase…”

You say “right … but how do you want me to favor one over another?”


“Quite simple…” replies Mr. Business Manager, “prioritize the reservation messages according to the Sales Channel (own sales office, agent, internet, mobile phone) AND Customer Rating (Frequent, Occasional, First time)”

"Easy-peasy” you reply…


Right !


Challenge Question: What is your suggested way to write/implement this ‘favoring the beloved ones’ piece of code that can be used across the board and apply to all your various in-house written and purchased applications?


For simplicity sake: Every Sales Channel ultimately produces an identically formatted message that includes the Channel and Customer Rating at a fixed position in the message, before it reaches the backend server.

Good luck.
Back to top
View user's profile Send private message
zpat
PostPosted: Fri Aug 01, 2008 2:19 am Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
Location: UK

Write a message exit to change the MQMD.Priority value?
Back to top
View user's profile Send private message
Challenger
PostPosted: Fri Aug 01, 2008 6:29 am Post subject: Reply with quote

Centurion

Joined: 31 Mar 2008
Posts: 115

That was quick, and certainly one of the 2 appropriate approaches that were considered. The other being MQ API Exit(s) . I can say that the company opted to use the API Exit approach.

Now that the first August Challenge steps has been taken, I would like to offer and encourage an interactive dialogue on the Pros and Cons of API Exits vs Channel Exits.

When and Why would you use, or not use, one or the other?
Back to top
View user's profile Send private message
mqjeff
PostPosted: Fri Aug 01, 2008 6:42 am Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

You can only use Channel Exits when messages are passing over a channel...

So you can't adjust messages being PUT to local queues.

It would be better for the receiving application to do this sorting themselves, using perhaps a staging table of some kind.

Message Priority is only useful if it is *extremely* tightly controlled from an enterprise scope. Otherwise all app teams will set their messages to the highest priority - because clearly they have to.

Using MQ Exits at all means that you are trying to do something that the product doesn't support. You are probably better off finding a different way of doing it - because the maintenance on Exits requires a very specialized set of skills and use of exits decreases the reliability of the queue manager.
Back to top
View user's profile Send private message
zpat
PostPosted: Fri Aug 01, 2008 7:03 am Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
Location: UK

The reason I would choose the message exit is that it could be installed ONCE on a receiver channel for the QM which hosted the queues for the application consuming the messages.

Whereas the API exit would need to be installed everywhere messages were being produced. This is against the MQ decoupled approach. Also there is no API exit for mainframes (other than CICS).
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Fri Aug 01, 2008 8:12 am Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

Without the need for any exit:

Have your application consume from Q B.
All your messages eventually land on Q A.

Have Queue A triggered and the application reading from QA does nothing else but inspect the message and set adequate priority before putting the message on Q B.

Advantage: no need to restart the qmgr should the rules change.

Enjoy
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
George Carey
PostPosted: Fri Aug 01, 2008 8:16 am Post subject: dp usage Reply with quote

Knight

Joined: 29 Jan 2007
Posts: 500
Location: DC

How about instead of exits use the Datapower XI50 as your rules and transfomation engine.

Have a frontend QM that is the input stream catcher. Associate sales channels and frequencies with Qs on this QM.

(eg. AGENT.FREQ, AGENT.OCAS, AGENT.FRST, etc . )

Use DP XI50 to read these queues and have associated rules to transform and format message exactly the same for all backend app servers placing sales channel and freq code where you want it and use rule based on combo of channel and freg code to stuff priority in MQMD and put on XI50 backend Qs of XI50 Backend QM that is seen and can be processed by all backend apps. Easy Peasy. Just Money Woney!!
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding")
Back to top
View user's profile Send private message Visit poster's website AIM Address
zpat
PostPosted: Sun Aug 03, 2008 11:44 pm Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
Location: UK

Of course, once you start to have hub processing then you might as well use Websphere Message Broker to perform the priority processing.

The best answer depends on what resources and skills are available and who has to maintain the solution long-term.
Back to top
View user's profile Send private message
Challenger
PostPosted: Mon Aug 04, 2008 1:21 am Post subject: Reply with quote

Centurion

Joined: 31 Mar 2008
Posts: 115

zpat wrote:
The reason I would choose the message exit is that it could be installed ONCE on a receiver channel for the QM which hosted the queues for the application consuming the messages.

Whereas the API exit would need to be installed everywhere messages were being produced. This is against the MQ decoupled approach. Also there is no API exit for mainframes (other than CICS).


I will reply to all responders one at a time, allowing some gap in response posting for further commentary by others.

starting with zpat: your answers are valid and accepted. Specially true is the point that there is no zOS API Exit and I had not clearly stated what kind of back-end big server was at play. We did not have zOS, so opted for the API way. that aside, one of the other main reasons that we chose the API Exit is that it runs at the producing end, allowing us to set the priority right at the start of the life cycle of the message.
Back to top
View user's profile Send private message
Challenger
PostPosted: Mon Aug 04, 2008 6:03 am Post subject: Reply with quote

Centurion

Joined: 31 Mar 2008
Posts: 115

now responding to mqjeff's points:

mqjeff wrote:
You can only use Channel Exits when messages are passing over a channel...

So you can't adjust messages being PUT to local queues

good point, thank you.

mqjeff wrote:
It would be better for the receiving application to do this sorting themselves, using perhaps a staging table of some kind
true but not all of our Appls had readily available source code.

mqjeff wrote:
Using MQ Exits at all means that you are trying to do something that the product doesn't support. You are probably better off finding a different way of doing it - because the maintenance on Exits requires a very specialized set of skills and use of exits decreases the reliability of the queue manager.

I accept the point and agree that Exits' use do carry some associated risks, maintenance considerations, special skills needed too. But we sometimes have to use them. Support Pacs are mostly in the same category too and I would venture a guess that a good many on this forum can't really do without them either.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Mon Aug 04, 2008 6:13 am Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

The really nice thing about MQ is that even where you don't have source code for an app, you can change the flow of messages into an app, by putting another queue in front of the app's input queue, and put another app that reads from that queue and outputs to the input queue.

The difference, in my mind, between Exits and SupportPacs is that SupportPacs do not run inside the application space of your queue manager processes (unless it's an Exit SupportPac)... so the risks of using a SupportPac is very different from the risk of using an Exit.

That said, I know some people who argue that you shouldn't use SupportPacs at all.
Back to top
View user's profile Send private message
George Carey
PostPosted: Mon Aug 04, 2008 9:36 am Post subject: hub or gateway? Reply with quote

Knight

Joined: 29 Jan 2007
Posts: 500
Location: DC

Quote:
"Of course, once you start to have hub processing then you might as well use Websphere Message Broker to perform the priority processing.

The best answer depends on what resources and skills are available and who has to maintain the solution long-term."
..., that's kind of a given isn't it, in the real world ... do the best with what you got? Thought this was kind of, if you could do any what would be the best ?

XI50 is less monies and less skills intensive than the WS Message Broker and likely only slightly more expensive and much more easily enhanceable, scalable, and deployable as fjb_saper custom code solution.
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding")
Back to top
View user's profile Send private message Visit poster's website AIM Address
SAFraser
PostPosted: Mon Aug 04, 2008 9:40 am Post subject: Reply with quote

Shaman

Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA

What an interesting discussion!

Is there a predictable difference in overhead between an API exit and a channel exit? (Yes, I know that it depends upon what processing the exit does.)

But in this case, for example, where the same thing is trying to be accomplished.... The Challenger has stated that, from an administration point, the channel exit is much easier to maintain. I am curious about runtime overhead.
Back to top
View user's profile Send private message
mq_developer
PostPosted: Mon Aug 04, 2008 3:42 pm Post subject: Reply with quote

Voyager

Joined: 18 Feb 2002
Posts: 82

As others have chimed in , problem calls for a broker functionality - content based routing (using routing loosely for assigning priority - more below). This is what i would propose

1) Design a App that would interrogate decision fields (since data comes in fixed format , it makes it much more easier to code) Channel and Customer Rating.

2) Now instead of setting priority within code , map this to a alias queue name (you can also opt to construct Queunames from the message fields - explained below) and set the priority at alias queue level.

Above approach gives you so much flexibility interms of extensibility and manageability with loose coupling - no hard coding whatsoever .

For instance for a message with Channel = 1 , Customer Rating = 2 , let us say prioirty should be 3. (Business logic for our implementation)
Just route this message by constructing a queue name (based on how robust app will be coded - involves some exception handling) CHANNEL.1.CUSTOMER.2 , define this as a alias with DEFPRTY set to 3 .

Now we have Content Based Routing Program , all it maintains is business logic.This app can be written in JAVA/C/C++ in a day , in Message broker in few hours (some might quote couple of minutes ) .

Speaking of Exits , I feel they are too low level , and for this requirement , it "tightly integrates" routing logic to the MQ subsystem - beyond that it is far easier to maintain an App than an exit.

This requirement calls for a CBR/Broker functionality ,MQ Exits definitely aren't for these reasons.

-Ram
Back to top
View user's profile Send private message
Challenger
PostPosted: Mon Aug 11, 2008 12:10 am Post subject: Reply with quote

Centurion

Joined: 31 Mar 2008
Posts: 115

SAFraser wrote:
I am curious about runtime overhead.


George Carey wrote:
XI50 is less monies and less skills intensive than the WS Message Broker and likely only slightly more expensive and much more easily enhanceable, scalable, and deployable as fjb_saper custom code solution.


mq_developer wrote:
As others have chimed in , problem calls for a broker functionality - content based routing ........, all it maintains is business logic. This app can be written in JAVA/C/C++ in a day , in Message broker in few hours (some might quote couple of minutes). Speaking of Exits , I feel they are too low level , and for this requirement , it "tightly integrates" routing logic to the MQ subsystem - beyond that it is far easier to maintain an App than an exit.

It seems that some would prefer to route/re-route traffic by having something in between to handle the business requirement (via broker, special App, hardware box) VS using a smart filtering of sorts via an Exit on the front end that could offer not only a decent solution but possibly also with less overhead and little to none new added budgetary capital expense.

Let me throw a couple final questions into the mix and maybe we can get a clearer picture to conclude this challenge up

- First of all, what if a few million incoming messages per day need to be looked at before being processed, does the overhead of any routing/re-routing not be a serious consideration?
- Second, that DataPower box talked about used to be around $50K-75K, how much is it these days? If one does not have Broker, does it not cost money? The Exits are there, free.

Looking forward to a few more heated entries.
Back to top
View user's profile Send private message
Display posts from previous:
This forum is locked: you cannot post, reply to, or edit topics.This topic is locked: you cannot edit posts or make replies. Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum IndexChallenge ForumChallenge Question - 08 / 2008
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.